Last week I learned about the newest
flamewar
in Debian mailing lists through the #debian-release IRC channel, while some
people were busy trying to tackle the last few RC bugs in the
sarge release. It seems
KDE, in non-default configurations, might pop up a screensaver that might
end up bringing some fresh pr0n to your monitor.
At the time I didn't even read the bug report, and quickly forgot about it,
but the other morning Sergio asked
me to come to see something at his work desk in office. He said it was
WebCollage, the screensaver in the middle of the storm. He demoed it
for me and soon enough we had a few interesting pictures in the screen:
a baby, a top-less woman, Nelson Mandela...
Thanks, flame warriors! After a few years using the "blank screen"
screensaver, I've found a new screensaver that brings some fun every now and
then. It's cool to walk back into office after our break and find a weird
composition of pics on the screen before you go back to work. :)
You
already know,
GNOME 2.10 has finally started to enter sid. As always, this kind of
transitions tend to break installability of GNOME in unstable during a few
days. Please don't file bug reports about this,
we
possibly
have
enough.
Unlike our previous transition, which ended up going
extremelly well,
this time the Debian GNOME team is facing a
problem
that is delaying a few packages that are deep in the dependency chain, like
gnome-menus or gnome-panel. The problem is, for
those who care, that both kdelibs-data and
gnome-menus provide the file
/etc/xdg/menus/applications.menu, which is part of the
freedesktop.org
Desktop Menu Specification.
After studying the specification and lots of discussion on IRC, we saw there
were three ways to address this conflict:
- Use
$XDG_CONFIG_DIRS in the user's session to look for the
menu files elsewhere. This has a big drawback: if someone is using KDE and uses
a menu editor to tweak their KDE menu, they will get a
~/.config/menus/applications.menu with a full KDE menu layout.
Now, if this user switches to GNOME, GNOME will read this menu in their home,
so they will get a KDE menu in GNOME, which is not so funny.
- Add a prefix to the GNOME-provided file, to make it read
gnome-applications.menu, and patch GNOME menu editors, the Panel
and other apps to look there. The big drawback is that third party apps with
menu-editing functionality, not provided by Debian, will not be aware of this
and will write custom menus in the wrong spot.
- Make gnome-menus (and effectively, all of the GNOME desktop) conflict with
KDE. This great idea was suggested by
dato, but at the time we had
to make the final decision, he was inexplicably quiet on IRC, so we had to
discard it.
In the end, after
changing
our
mind
we decided to go with the file renaming, as the "KDE in GNOME" (or viceversa)
issue is way too ugly. This may or may not be a big problem in the Desktop Menu
Specification, depending on who you ask. The spec was obviously written to have
just one applications.menu shared by all the desktops, but that's not feasible
today, as it depends on a ton of desktop files to add the
OnlyShowIn properties. When all or most desktop files in Debian
have this, we might bring this up again.
Anyway, with gnome-menus sorted, we are near to be able to upload the
final missing 2.10 core packages like the Panel or Nautilus. Most libraries
and a good number of other Desktop applications are already in unstable, at
least for i386. Other architectures will have to wait until the buildd's find
their way through the maze of FTBFS due to missing build dependencies. Please
be patient!
While all of this is going on, it's fun and nice to see
azeem going over all the
GNOME packages and quickly filing bugs about compile problems on
Debian GNU/Hurd. If all goes
well and the patches get applied on all the modules, GNOME 2.12 might have
Hurd support out of the box for the first time.
(yes, the third alternative was a joke, no need to flame me about
conflicting with KDE...)
