I surrender -> gdm shutdown bugs etc.

[Remco Lubbers]

On Fri, 06 May 2005 22:20:50 +0200, Auke Kok said:

> Remco Lubbers wrote:
>  > More and more flaws in moonbase make my users/clients unhappy, which
>  > does keep me up at night (trying to fix things). Most recent problem:
>  > cups/gs stopped working after a 'lunar update', that ended up looping
>  > on the alias-problem. Another new one: gdm is no longer able to shut
>  > down the system. Those combined with the nfs-not-mounting-at-boottime
>  > and the tacky runlevel-switcher no longer make lunar useable as a
>  > workstation-OS.
>  
>  I'm not gonna startup a huge discussion now but I'll report on on thing 
>  at a time: the gdm issue was reported upstream by me and was confirmed as 
>  a genuine bug in the latest gdm release (yes, really). I just added a fix 
>  to moonbase. I'm sorry about not doing this earlier... but in all 
>  honesty, it's not up to me to maintain gnome as well, and this is clearly 
>  a point where developers need to test their code better, and do something 
>  about it.

Agreed! And that's my point exactly: and not so well tested version (of
any software) should be in moonbase! The GDM problem could easily have
been spotted if there was a beta-release and should not have been
submitted to the stable-release, since it does not function fully. The
GDM problem is merely an example of course...

>  The cups issue is a new one to me. If you have more detailed information 
>  then please report.

I'll do that tomorrow then. There's two workstations in the office that
have this problem and I gave up on updating the other systems after
detecting this problem. It's very probable that it is caused by 'lunar
fix' that does not finish correctly because of the alias-loop. I'll
have to check whether or not the emacs-trick will bypass the loop and I
hope that cups will start working after that again. What I did try
already and was not succesful was recompiling cups, espgs, gimp-print
and ghostscript.

What happens as soon as cups want's to start printing is that gs starts
to consume about 50% of the cpu-resources. killing of gs gives a nice
black page on the printer....

I'll have to check version, settings and drivers tomorrow.

>  I've seen your nfs mounts report and am clueless. The init.d order of 
>  portmap (11) and netmount (15) is correct. If these match with the 
>  chkconfig order on your system, then possily a kernel nfs version 
>  mismatch might be happening. 

Rather strange, because it does mount in about 20% of the boots. Doing
the nfs-mount manually AFTER boottime always works flawlessly. I use
nfs v3 in all the kernels and the only 2 systems having this problem
are the lunar-workstations. The MDK stations don't have any problem
mounting the NFS shares, which are on a lunar server BTW.

>  > On the server-side there's mainly the php-compile problem using the
>  > with-readline option (which is standard in the php4-BUILD).
>  
>  I believe that openssl also linked against readline and that this leads 
>  to a tangle of readline symbols and versions, I know it's a mess, and 
>  this is where a source distro as lunar will probably never get things 
>  right since we always link against active libraries, and not to ones in a 
>  buildjail.

It's still strange. I have a few systems that do not have this problem
and all my servers have exactly the same configuration and package
selection. The only difference is the time that they were installed.
The problem has been around since php v 3.4.9 and I have not been able
to figure out how to get php to build correctly, other than removing
the with-readline option. I use apache v 1.3 and have tried installing
apache-mod_ssl and recompile everything that might stand in the way of
the php compile: readline, mysql, db, ncurses....

>   > But Perl is another problem (rather anoying).
>  
>  And Python had almost joined the club. Well, it has actually. These two 
>  languages keep a mess of local modules in between system-wide 
>  from-the-base-package. The Python module should be reasonably cleaned up 
>  right now, but in order to fix the perl module, some more magic is 
>  needed. One of the required changes for this was a code enhancement in 
>  the core that I needed for something else. With a bit of luck I can 
>  incorporate this in the perl module and automate (some of) the upgrades a 
>  lot better.
>  
>  one bug at a time...

Sure, but why not keep an older, working, version of some stuff for the
'stable release', untill all problems with a new version have been
resolved? IE, why not keep Perl on v 5.8.5 untill we've made sure that
v 5.8.6 works flawlessly?

Maybe have some pear-like system in lunar for setting the preferred
state of the machine your working on: 'lunar set preferred_state
stable' would install packages that have been thoroughly tested and
approved and 'lunar set preferred_state beta' would install the latest
packages, that need some more testing (of dependancies and on various
installs) before being approved and bumped to stable?

Remco