Subject: sb build a 2.3.28 release please (with text)

From: Dominik Vogt <[email-masked]>
Date: Wed, 17 Jan 2001 01:42:07 +0100

If the active icon patch I comitted works for Dan, can somebody
please remove the debug fprintfs in events.c, icons.c and
add_window.c and build the 2.3.28 release today?

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Tue, 16 Jan 2001 20:02:18 -0500

> add_window.c and build the 2.3.28 release today?

I think we stand a better chance of getting stable releases if
we let a few days go by.

Its not clear to me why we create these releases.  They aren't
any different than the nightly snapshots.

I believe we could just label the source tree and ask Jason copy the
latest snapshot to the release area.

Of course I could be wrong.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: "Paul D. Smith" <[email-masked]>
Date: 16 Jan 2001 21:35:33 -0500

Well, they have some use as they allow people to (a) know when a new "we
think it works well enough to give to people who want to play with
cutting edge, but not bleeding edge, stuff" release is done, and (b)
install said release in a new area that doesn't overwrite the old one.

The usefulness of (B) is somewhat lessened by the fact that it always
installs a non-versioned fvwm2... bummer :(

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>    HASMAT--HA Software Methods & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Tue, 16 Jan 2001 22:26:50 -0500

"Paul D. Smith" <[email-masked]> writes:
> cutting edge, but not bleeding edge, stuff" release is done,

You're right.  I didn't express myself very well.
Let me take back that sentence.

> and (b)

Its not too hard to version fvwm during the configure step.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 17 Jan 2001 11:24:20 +0100

> cutting edge, but not bleeding edge, stuff" release is done,

Well, that's exactly where Dan is right.  In the past month I
built these releases from time to time just to have a release.
Most of the time I build them after a long debuggins session and
therefore they are often broken.

I suggest in the furture I will avoid building the releases myself
but ask others to do it.  This will give us some time to discover
the most blatant bugs.  For a start I'd like to ask Dan to make
next release.  This is very simple nowadays.  Just cd into the
fvwm directory and type

  $ utils/make_fvwmdist.sh -r

The script will ask a few questions which can be suppressed by
setting environment variables.  There are even variables that can
be fed with shell commands that bring the network up or down.
The script will update the NEWS and ChangeLog files, tag the
sources and commit the changes.  All that is left to do is to
upload the tarballs, send a mail and update fvwm-web.

A stable release should be built on a system with all options in
the configure summary enabled, but that's not this important for
the betas.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Wed, 17 Jan 2001 09:51:46 -0500

Dominik Vogt <[email-masked]> writes:
> next release.  This is very simple nowadays.

OK, I've disabled, but not removed, the icon debugging since it seems
like it might get adjusted again.  CFLAGS=-DICON_DBG will turn it back on.

After we've gone a few days without anything changing,
I'll create 2.3.28.

---

From: [email-masked]
Date: Wed, 17 Jan 2001 10:06:09 -0500 (EST)

> After we've gone a few days without anything changing,

Will this release have the fix for TiledPixmaps?  I don't recall
seeing any recent checkins of code into borders.c...

-- 
Larry Gensch                                          [email-masked]

              Working for COMPAQ since the turn of the century

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 17 Jan 2001 16:16:22 +0100

On Wed, Jan 17, 2001 at 10:06:09AM -0500, [email-masked] wrote:
> Will this release have the fix for TiledPixmaps?

Yes.

> I don't recall seeing any recent checkins of code into
> borders.c...

Keep your eyes wide open.  It was there :-)  The corresponding
messages are not necessarily in the subject of the commit
message.  You may have to open it to see it.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Thu, 25 Jan 2001 19:49:15 -0500

>   $ utils/make_fvwmdist.sh -r

Seems like we've stopped changing things so this looks like a good
time for a release.

The err_exit function in make_fvwmdist.sh isn't portable,
functions aren't allowed in Sun's /bin/sh.

The syntax

 elif ! grep "$CHECK_STRING1" "$CHECK_FILE" ; then

isn't allowed either.  I think it wants some []s.

I changed #!/bin/sh to #!/bin/ksh and move the file to /tmp.
That works up until it tries to do "make clean".

At the make clean step I get:

fork> make clean
Making clean in .
Making clean in tests
Making clean in sample.fvwmrc
Making clean in rpm
Making clean in docs
Making clean in utils
mksh: Fatal error in reader: = missing from replacement macro reference
Current working directory /u/tools/dane/fvwm/version-2_3_28/utils
*** Error code 1
make: Fatal error: Command failed for target `clean-recursive'

OK, I see, I need "gnumake clean".
I changed make_fvwmdist.sh to use gnumake.

Seems to be running now...Oops, no, not yet.

Since I haven't exported CC=gcc like I normally do, the CFLAGS
of "-g -O2 -Wall -Werror" aren't any good.

Adding:

export CC=gcc
export CXX=g++

gets it a little farther, but -Werror isn't going to do it either.
Sun's X header files generate way too many warnings.  Should have
warned me that this is a Linux only procedure...Looks like the
-Werror has to go.

Anyway, expect 2.3.28 sometime soon.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 26 Jan 2001 11:16:37 +0100

> functions aren't allowed in Sun's /bin/sh.

*Sigh*  Isn't /bin/sh standardised?  I thought that bash was sh
compatible when called as /bin/sh :-(

> I changed #!/bin/sh to #!/bin/ksh and move the file to /tmp.

That's probably the best solution with ksh being POSIXised.

> I changed make_fvwmdist.sh to use gnumake.

Of course there is no gnumake executable on the average Linux
system.  It's called "gmake" there.

> Sun's X header files generate way too many warnings.

Can we disable warnings for system header files with gcc?

> Should have warned me that this is a Linux only procedure...

I didn't intended it to be Linux only, but of course I didn't test
it extensively.  The script simply does most of the steps
described in doc/DEVELOPERS.  The same problems would occur when
building manually.

Bye

Dominik ^_^  ^_^

---

From: "Paul D. Smith" <[email-masked]>
Date: 26 Jan 2001 10:06:26 -0500

>> functions aren't allowed in Sun's /bin/sh.

  dv> *Sigh*  Isn't /bin/sh standardised?  I thought that bash was sh
  dv> compatible when called as /bin/sh :-(

There's a POSIX standard for sh.  The POSIX standard definitely requires
shell functions; I've never seen a shell that didn't support them.  They
are definitely portable to any remotely modern system (certainly to any
system we'd want to build a distribution on :).

Also, the err_exit function works fine on my Solaris box.

  >> isn't allowed either.  I think it wants some []s.

Right; the "!" is very handy, but not portable to older shells.

However, you can't just add "[]"; that's not the same thing at all.

  >> I changed #!/bin/sh to #!/bin/ksh and move the file to /tmp.

  dv> That's probably the best solution with ksh being POSIXised.

I disagree.  Ksh is a proprietary program and doesn't appear on any free
UNIX system, like Linux, FreeBSD, etc.  There is a free reimplementation
but I'm not sure how compatible it is, and most systems don't ship with
it.

We should avoid requiring ksh, just as we avoid requiring bash.

  >> I changed make_fvwmdist.sh to use gnumake.

  dv> Of course there is no gnumake executable on the average Linux
  dv> system.  It's called "gmake" there.

On Linux, it's just called "make" since GNU make is the only make there
is.

Often you'll see people name it "gmake" on other systems to avoid
conflicts with the system make (although I don't bother; who wants the
system make anyway :)?

I think we should have a way of handling this.  The script can try to
find a GNU make, perhaps like this:

  make=
  for x in make gmake gnumake; do
    ver=`(echo 'all:;@echo $(MAKE_VERSION)' | $x -f -) 2>/dev/null`
    case $ver in
      3.*) make=$x; break 2 ;;
    esac
  done

  case $make in
    ?*) : OK, found one ;;
    *)  echo "Can't find GNU make on the PATH!"; exit 1 ;;
  esac

  >> Sun's X header files generate way too many warnings.

  dv> Can we disable warnings for system header files with gcc?

No.

---

From: Dan Espen <[email-masked]>
Date: Fri, 26 Jan 2001 10:30:39 -0500

> Also, the err_exit function works fine on my Solaris box.

Mine too, guess all the other problems I ran into confused me.

> We should avoid requiring ksh, just as we avoid requiring bash.

I agree that using /bin/sh is the best way to go, but
we install "pdksh" on our Linux systems.
We use ksh as our login shell, and in most of our
shell scripts.  It (pdksh) seems to do the trick.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 27 Jan 2001 16:34:59 +0100

>   for x in make gmake gnumake; do

The ordering is wrong.  gmake and gnumake have to appear before
make.

>     ver=`(echo 'all:;@echo $(MAKE_VERSION)' | $x -f -) 2>/dev/null`

Is there any particular reason to check only for major version 3?

>     *)  echo "Can't find GNU make on the PATH!"; exit 1 ;;

I'll put this in the script.  Looks good to me.

Bye

Dominik ^_^  ^_^

---

From: "Paul D. Smith" <[email-masked]>
Date: 27 Jan 2001 19:45:15 -0500

>> for x in make gmake gnumake; do

  dv> The ordering is wrong.  gmake and gnumake have to appear before
  dv> make.

Not really.  The idea is that only GNU make will respond with the
proper value for MAKE_VERSION (no other make I know even sets it), so it
doesn't matter which one comes first.  If "make" isn't GNU make, it
won't match anyway.

It doesn't matter, though, to me.

  >> ver=`(echo 'all:;@echo $(MAKE_VERSION)' | $x -f -) 2>/dev/null`

  dv> Is there any particular reason to check only for major version 3?

Because as far as I know there is no version of GNU make in existence
anymore with any other major version numer... and I don't plan on
changing that anytime in the forseeable future :).

You could use [3-9].* if you wanted, I guess.