Mailing List Archive: more kde-sunset upgrade notes

Recently, I've updated to Gnome 2.32.1 on the same system that is also
running KDE 3 from sunset. Keeping the two together on a machine that
uses KDM 3.5.10 as a login manager is getting interesting.

Here are some notes for those who may be in a similar situation:

Recently, Gentoo decided to phase out Hal completely. Hal has been
deprecated for some time, but now that pretty much all software that's
officially supported from Gentoo's main package pool has been migrated
to use Udev-based mechanisms, Gentoo decided to pull the plug on Hal.
(Watching 2001 for the nth time might have caused them some anxiety
about keeping Hal around any longer too...) Currently, Hal is still in
Portage, but probably won't be much longer. I think someone mentioned
pulling it into the kde-sunset overlay if it becomes necessary for KDE's
sake.

I've run into some issues on both the KDE 3 and the Gnome sides, which
I'll mention separately.

KDE 3 issues:

The first trouble you'll have is that when Gentoo deprecated Hal, they
also got rid of its USE flag, which means even from the kde-sunset
overlay, KDE will build without Hal support, even if Hal is installed,
and even if you have it enabled in your own USE flags. This will make
removable media detection not work, even if hald is running.

As it turns out, you can contradict the profile yourself by doing "-hal"
again yourself in /etc/portage/profile/package.use.mask. The "-hal"
from Gentoo and your own "-hal" cancel eachother out to effectively
equal "hal" enabled. It's goofy, but it works. There are two packages
in KDE that need it, so put this in that file:

kde-base/kdebase-kioslaves -hal
app-cdr/k3b -hal

You should be able to keep your media detection in KDE now.

Gnome issues:

It should be mentioned at the start that 90% (if not all) of the issues
below are caused by not using GDM as a login manager. Probably KDM 4
would work too, since it is receiving current support.

However, XDM, KDM (3.x), and Slim will all have issues running Gnome
now. Details follow...

Recent versions of Gnome introduced us to PolicyKit, ConsoleKit, and
lots of other assorted "kits" that run daemons we never had before,
create lots of really ugly messages in syslog about DBus events nobody
wants to know about (even on fully working systems that have only Gnome
and no deviances), and provide services that nobody I know was asking
for. In other words, desktop Linux evolution as usual...

In the current version of Gnome though, PolicyKit and ConsoleKit have
become serious. It's now necessary for PAM to run a module on every
login called pam_ck_connector.so. This lets console-kit-daemon know
you're logged in. Normally (for systems using GDM or KDM 4), the line
in /etc/pam.d/system-login that does this contains the "nox11"
parameter, because GDM is itself fully ConsoleKit-aware, and will
provide its own plug to the console-kit-daemon without help from PAM.
Thus, the "nox11" parameter inhibits the PAM plugin from working for
cases of X logins, and makes it cover only TTY's:

session optional pam_ck_connector.so nox11

(You probably got this line in your PAM config as part of an update, so
it's probably already there. It's not necessary to do anything with it
yourself, at least for normal systems.) However, the assumption that
we're running a login manager that plugs into console-kit-daemon itself
is false if we're running anything but GDM. (It's a Gnome world!)

First, take the "nox11" part out of that line in
/etc/pam.d/system-login. Then, since KDM has its own PAM config that
doesn't source the system-login file at all (and thus is missing two
needed lines), add the following to the bottom of /etc/pam.d/kde:

session optional pam_loginuid.so
session optional pam_ck_connector.so

Ah, but we're not done. Now you need to modify the file that provides
the login profile in KDM's session menu to choose Gnome. Normally, it
just runs "gnome-session", but we need it to run "ck-launch-session
gnome-session", so the Gnome launch gets connected to the session in
ConsoleKit. (Isn't this nice?) This is not needed for any other window
manager I use besides Gnome, so that's the only profile you'll need to
adjust this way. Here's my adjusted /usr/share/xsessions/gnome.desktop:

[Desktop Entry]
Name=GNOME
Comment=This session logs you into GNOME
Exec=ck-launch-session gnome-session
TryExec=ck-launch-session
Icon=
Type=Application

If you do all of this, you should be able to type "ck-list-sessions" in
Gnome and see your login listed as an x11 session, and most importantly,
flagged as "active". Mounting removable media should work, though now
via udev and udisks-daemon rather than hald. Oddly though, there still
must be some magic that GDM would give me that KDM is not providing,
because gnome-screensaver now cannot ever detect when the display has
been idle long enough to start the screensaver on its own. If I lock
the display myself, it works. The display even falls asleep on its own
if left idle long enough, so power management is working -- although
unlocked, and with no screensaver. It just turns off. A different
system which also runs KDE 3 (from sunset) alongside modern Gnome does
not have this problem. The difference between them is that it uses GDM
for its login manager. GDM seems to do more here than meets the eye.

The telltale error in syslog is:

gnome-session[14487]: WARNING: GSIdleMonitor: Unable to initialize Sync
extension

There is nothing in Google about this other than a reference to the
actual line in the code that generates the message. Basically,
gnome-session is not able to connect to the X11 extension that tells how
long the display has been idle. I have no idea why, or what GDM would
ordinarily do that sets up this connection. The result though is that
the screensaver will never kick in on its own, only under user control.

PARTING THOUGHTS:

Gnome is getting too complicated for its own good, and about to jump the
shark that KDE just fell off of when 4.x came out. Obviously, the
intent of all of this is to tie services to the user who is actually at
the console. But why?

Is it really a problem if my removable media is mounted by a remote
user? Who says it is? Many times, I have left a DVD in my drive only
to access the files on it from somewhere else, logged in on a shell via
SSH. It's nice to not have to su to root to access that DVD. It's also
nice to not assume I'm on a Gnome desktop using udev,
pam_ck_connector.so, console-kit-daemon, ck-launch-session, and Nautilus
to see that DVD. It used to be as simple as putting a line in
/etc/fstab that allows that mount by regular users.

Oh! But that was before they made it so that udev would not be able to
automatically provide desktop icons or automounting in Gnome if you had
such lines in your fstab. For awhile now, it's been necessary to remove
lines for DVD's or USB flashdrives if you want Gnome desktop
automounting to work. So we've gone from being able to mount a DVD from
a bare shell as a regular user, to needing to be on a Gnome desktop, and
from there to needing to be on a Gnome desktop that was launched in a
ConsoleKit environment with a PAM connector module. Otherwise, you need
to be root to mount a DVD.

It's long been practice of the GNU Project to make versions of
historically standard UNIX tools that have more features than the
original did. Their tar is a super-tar, their ps is a super-ps, and so
on. If we really needed more functionality for detecting who is logged
in and from where, couldn't we have just revamped /var/log/wtmp, 'who',
'last', and related commands and programs to provide whatever was
missing at the UNIX level, to benefit the whole system? Rather than
just making more obtuse daemons that seem to be trying to make the whole
system into one big platform to run Gnome? And if we need finer
permissions to control mounting of media, here's a novel idea: Posix
groups! Whoo! Why not just control who can mount with a group, and
have the users who can do that controlled by some kind of group policy?
Nah, too simple.

You know, one of the big things that always stood in the way of FreeBSD
being a decent desktop platform (even for technically oriented users)
was that its fstab syntax has no equivalent to Linux's "users" option.
There is only one even approaching-decent way to allow non-root users to
mount media in FreeBSD, and that's to set up the Berkeley automounter
("amd" daemon) to do it for you with an automounter map. And as anyone
who's ever dealt with the automounter knows, that's a fickle and
tempermental solution sure to drive anyone crazy. You don't want to do
that? Drop to a shell, and mount your disc as root! That's removable
media in the world of FreeBSD on the desktop.

Now, in Linux, thanks to the fact that Gnome/udev will not automount
discs unless the fstab entry is *missing*, and thanks to the fact that
Gnome further requires a PolicyKit/ConsoleKit environment to automount
media also, even Linux machines with Gnome now have no option to mount
removable media without resorting to some form of root access, via su,
sudo, or hell why don't we just do what the BSD people do and run an
automounter daemon? It's all taken care of if you're in Gnome or modern
KDE (4.x), but that's now become an assumption. You can't even be just
running a console anymore.

It'd be nice if the people working on all these desktop technologies
would remember that most things always were provided with basic UNIX
tools, and if those tools aren't doing what's needed, they can usually
just be given new features, like the GNU Project did with most of the
standard userland. We don't need more daemons to interact with the
other new daemons that we got because we needed to run more daemons.

--
+ Brent A. Busby +
+ Sr. UNIX Systems Admin + Vote for Cthulhu.
+ University of Chicago +
+ James Franck Institute + Why settle for the lesser evil?

Brent Busby posted on Thu, 14 Apr 2011 14:20:47 -0500 as excerpted:

> Recently, Gentoo decided to phase out Hal completely. Hal has been
> deprecated for some time, but now that pretty much all software that's
> officially supported from Gentoo's main package pool has been migrated
> to use Udev-based mechanisms, Gentoo decided to pull the plug on Hal.
> (Watching 2001 for the nth time might have caused them some anxiety
> about keeping Hal around any longer too...) Currently, Hal is still in
> Portage, but probably won't be much longer. I think someone mentioned
> pulling it into the kde-sunset overlay if it becomes necessary for KDE's
> sake.

Interesting post. I appreciate your thoughts, as kde4 (my desktop
environment of choice, tho at least I don't have your complications of
others as I don't have them installed, nor of *DM, since I strongly prefer
logging in at the CLI and running startx to start kde as the user I'm
logged in as, from there) uses some of the same tools gnome does, and as
it switched away from hal to udev with kde 4.6, as well. The fact that an
fstab listing is incompatible with automounting is especially frustrating,
altho I prefer much more limited automounting that some, so it's not as
bad here as it can be for others.

But the reason I'm replying has to do with the above quoted bit.

FWIW, hal will apparently remain around in portage for a bit longer.

According to a recent post on the dev list, the gentoo/kde project had
intended to try to stabilize kde 4.6.2, thus eliminating the hal
dependency for stable kde4, clearing the way for its removal from portage.

But, spanner in the sprockets! That plan doesn't appear to be viable, and
while I've not seen anything official from the gentoo/kde folks indicating
this, my own experience with 4.6.2 now has me questioning whether any of
the 4.6s will be stabilization material. It may well be kde 4.7
(presumably at least 4.7.1, with 4.7.0 due for August release and 4.7.1
due a month later, with a month for standard Gentoo stabilization... that
could EASILY mean October or later for a stable non-hal kde4). Tho it's
still possible a later 4.6 will get things together enough to be
stabilized, just looking less likely, now.

Again from that recent gentoo/kde post to the dev list, they had planned
on stabilizing a kde 4.6 release. But 4.6.0 was a .0 feature release and
thus brought with it a few new bugs, as first-feature releases tend to
do. As such, it wasn't really stabilization material, but that was
expected.

Here's where that spanner enters the sprockets, however. Still from that
post (tho the spanner analogy is mine), KDE upstream is in the midst of
converting from their former svn repo to git, one sub-project at a time,
and the process has evidently not been particularly smooth. While the
monthly micro-releases (4.6.x) are intended to be bugfix releases on the
semi-annual feature minors (4.x), and arguably until 4.6 had been just
that, 4.6.1 was a notable regression from 4.6.0, due to confusion from the
svn -> git transition, with the wrong head pulled in a number of cases,
resulting in code being pulled into the release tarballs that wasn't ready
nor intended in that form for them.

That post was a few days prior to the 4.6.2 release and linked to the kde
release list archive discussion of the coming 4.6.2 release, where they
were trying to coordinate in an effort to prevent the same sort of issue
happening for 4.6.2.

Meanwhile, 4.6.2 has actually been released. Of course this is now beyond
that post, so it's my evaluation from here. If 4.6.1 was a bit of a
regression, as from that post it evidently was, for me it was fine. NOT
SO 4.6.2! It has a couple nasty regressions that affect me personally,
with others affecting other folks, some of which are posting to the kde
user lists I follow -- WAY more than they did for the 4.6.1 upgrade.
Based both on posts to the kde lists and my own experience, 4.6.2 is
anything BUT a stable candidate!

Given that and in the context of the previous post to gentoo-dev from the
gentoo/kde folks, it's going to be some time before a non-hal kde4
stabilizes, meaning it's going to be some time before hal can be pulled
from the main tree, however much it's disrupting nicely laid plans to lay
it to rest.

(I know I won't be missing hal! One fight with obtuse *.fdi format config
files was one too many! I'm on 4.6 and no longer have hal to deal with,
GOOD RIDDANCE! Despite the problems, I wouldn't consider going back to
it. I've considered reverting to 4.6.0 which was fine at least here, but
don't intent to revert further back and have hal to worry about again as a
result.)

What's worse, until 4.6, every kde4 release, feature or bugfix, was
arguably better, often MUCH better, than the one before. With 4.6, that's
been turned on its head, and while 4.6.1 was arguably an exception, 4.6.2
is looking WAY too much like a trend! Yes, we know at least one of the
reasons, the continuing upstream svn -> git migration. But it's still a
nasty problem and a reversal of the previous very nice trend.

Given the serious problems with 4.6.1 and now 4.6.2, I'm not sure what'll
happen for the remaining monthly 4.6.x releases, 4.6.3 thru 4.6.5. It's
looking quite possible now that 4.6.0 will remain the best of the 4.6
series and even if they fix the problems with 4.6.1 and 4.6.2, nothing in
the 4.6 series will reach stabilization level, as they continue to migrate
more bits of kde over and get used to git.

That would leave 4.7 as the next possibility, tho /maybe/ they can work
things out by 4.6.5. If it's 4.7, and the usual 4.7.0 feature release is
as usual not considered a stabilization candidate, that means 4.7.1 or
later, which as I said above, means October at the earliest.

Meanwhile, the 4.4 series stable they have now is looking rather long in
the tooth. It's quite dated from upstream's perspective, and from my own
personal experience, 4.5.4 or so (4.5.0 for me personally, but there were
some significant graphics bugs only fixed in 4.5.3 or 4.5.4, that were bad
for many users) was the first version I would have considered a proper
upgrade from the later 3.5 series. Since 4.4 is previous to that, it
should be obvious that I consider Gentoo's current stable 4.4.x a
substandard experience, and that I believe a later 4.5 should have been
stabilized.

But, 4.5 is still hal-dependent, so it makes little or no sense to try to
stabilize it now, when they're trying to dump hal.

The other /possible/ alternative would be taking 4.6.0, cherry-picking
specific patches from the later 4.6 series to apply on top, and
stabilizing that, probably still calling it 4.6.0, but carrying more
patches on top than Gentoo traditionally does, altho they /do/ happen to
have been applied upstream. If kde were already fully switched to git,
that'd be a rather easy process indeed, since git has been specifically
designed to allow this sort of cherry-picking, and indeed, has a command
called cherry-pick designed to implement it.

Unfortunately, the conversion svn -> git makes this a challenging option
as well, tho if I were on the gentoo/kde project it's something I'd
certainly be examining. It's a bad option, certainly, but that doesn't
mean it can't still be the best among many bad options. (Hmm, English
gets awkward with that many negatives in a sentence! Does that say what I
intended it to say?)

So I don't know what's going to happen. But whatever it might be, due to
all these kde 4.6 issues, hal looks to be safe in the tree for a /few/
more months, yet. If 4.6.1 wasn't considered stabilization material, it
would seem clear to me at least, that 4.6.2 is even worse, so whatever
they decide to do, hal has to stick around until it's finished and the
latest gentoo/stable kde is no longer hal dependent. Whatever it is they
do, it's going to take some time.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman