I've done some work on the Live CD kickstart images, available here:
http://submind.verbum.org/~walters/livecd.git/
(Until Jeremy returns from vacation and can review patches to be put in the main livecd git repository)
The most important change so far is to create "livecd-desktop-minimal.ks" which is then used as a basis for:
livecd-fedora-desktop.ks livecd-fedora-kde.ks livecd-online-desktop.ks
Rather than each thing duplicating a lot of code for the livecd init script, etc.
The online-desktop is just a stub right now while I fix up some issues, but I've booted the livecd-fedora-desktop successfully (livecd-desktop-minimal.ks also boots...into twm! Retro.).
Admittedly I haven't tested the KDE one, but moving forward this unforking should help us to identify changes common between them which seem like good candidates for comps or Fedora package changes.
Sebastian, since you were the last person to touch the KDE bits, could you have a look at these changes?
I also added a number of improvements to livecd-creator, the git log has the gory details.
Am Tue, 31 Jul 2007 18:19:09 -0400 schrieb Colin Walters walters@redhat.com:
I've done some work on the Live CD kickstart images, available here:
http://submind.verbum.org/~walters/livecd.git/
(Until Jeremy returns from vacation and can review patches to be put in the main livecd git repository)
The most important change so far is to create "livecd-desktop-minimal.ks" which is then used as a basis for:
livecd-fedora-desktop.ks livecd-fedora-kde.ks livecd-online-desktop.ks
Rather than each thing duplicating a lot of code for the livecd init script, etc.
The online-desktop is just a stub right now while I fix up some issues, but I've booted the livecd-fedora-desktop successfully (livecd-desktop-minimal.ks also boots...into twm! Retro.).
Admittedly I haven't tested the KDE one, but moving forward this unforking should help us to identify changes common between them which seem like good candidates for comps or Fedora package changes.
Sebastian, since you were the last person to touch the KDE bits, could you have a look at these changes?
livecd-fedora-kde.ks is working but installs too much more packages than the old config (and also some unwanted, eg. gnome-games). This is related to livecd-desktop-minimal.ks which includes more groups than the kde config. If the kde livecd should also use this config some groups should be removed. The size with livecd-desktop-minimal.ks is here (i386) 770 megs to 687 megs with the normal config.
And some small note: I've had to run livecd-creator from inside the config directory so that it could find livecd-desktop-minimal.ks.
Sebastian
On Thu, 2007-08-02 at 12:14 +0200, Sebastian Vahl wrote:
livecd-fedora-kde.ks is working but installs too much more packages than the old config (and also some unwanted, eg. gnome-games).
Awesome, thanks for taking a look at this.
This is related to livecd-desktop-minimal.ks which includes more groups than the kde config. If the kde livecd should also use this config some groups should be removed. The size with livecd-desktop-minimal.ks is here (i386) 770 megs to 687 megs with the normal config.
You should feel free to kill off stuff in -desktop-minimal; the intent is it just launches TWM. Are you going to have a chance to do any work on the KDE livecd soon?
Ideally this work would all go in the livecd repo, I'd just feel uncomfortable committing such a big patch without review from Jeremy.
Am Do 2.August 2007 schrieb Colin Walters:
On Thu, 2007-08-02 at 12:14 +0200, Sebastian Vahl wrote:
livecd-fedora-kde.ks is working but installs too much more packages than the old config (and also some unwanted, eg. gnome-games).
Awesome, thanks for taking a look at this.
This is related to livecd-desktop-minimal.ks which includes more groups than the kde config. If the kde livecd should also use this config some groups should be removed. The size with livecd-desktop-minimal.ks is here (i386) 770 megs to 687 megs with the normal config.
You should feel free to kill off stuff in -desktop-minimal; the intent is it just launches TWM. Are you going to have a chance to do any work on the KDE livecd soon?
I will not be at home over the weekend. But I try to test some changes on monday.
Sebastian
Am Fr 3.August 2007 schrieb Sebastian Vahl:
Am Do 2.August 2007 schrieb Colin Walters:
On Thu, 2007-08-02 at 12:14 +0200, Sebastian Vahl wrote:
livecd-fedora-kde.ks is working but installs too much more packages than the old config (and also some unwanted, eg. gnome-games).
Awesome, thanks for taking a look at this.
This is related to livecd-desktop-minimal.ks which includes more groups than the kde config. If the kde livecd should also use this config some groups should be removed. The size with livecd-desktop-minimal.ks is here (i386) 770 megs to 687 megs with the normal config.
You should feel free to kill off stuff in -desktop-minimal; the intent is it just launches TWM. Are you going to have a chance to do any work on the KDE livecd soon?
I will not be at home over the weekend. But I try to test some changes on monday.
Sebastian
Well, I didn't had much time. But these config is more closer to the normal one. I removed only @games from livecd-desktop-minimal.ks and removed the further not wanted packages in livecd-fedora-kde.ks. But the list is not complete yet.
Sebastian
On Tue, 2007-08-07 at 18:47 +0200, Sebastian Vahl wrote:
Well, I didn't had much time. But these config is more closer to the normal one. I removed only @games from livecd-desktop-minimal.ks and removed the further not wanted packages in livecd-fedora-kde.ks. But the list is not complete yet.
# remove some packages from dekstop-minimal.ks -scim* -system-config-printer* -gdm -authconfig-gtk -m17n* -xorg-x11-fonts-* -xorg-x11-twm -PolicyKit-gnome -libbeagle -yelp -firefox -desktop-backgrounds-basic -gnome-doc-utils-stylesheets
Almost all of this should go back into desktop-minimal; the goal there is basically just be gdm+twm+xterm; then this list would ideally just be -gdm +kdm
On Tue, 2007-08-07 at 15:37 -0400, Colin Walters wrote:
On Tue, 2007-08-07 at 18:47 +0200, Sebastian Vahl wrote:
Well, I didn't had much time. But these config is more closer to the normal one. I removed only @games from livecd-desktop-minimal.ks and removed the further not wanted packages in livecd-fedora-kde.ks. But the list is not complete yet.
# remove some packages from dekstop-minimal.ks -scim* -system-config-printer* -gdm -authconfig-gtk -m17n* -xorg-x11-fonts-* -xorg-x11-twm -PolicyKit-gnome -libbeagle -yelp -firefox -desktop-backgrounds-basic -gnome-doc-utils-stylesheets
Almost all of this should go back into desktop-minimal; the goal there is basically just be gdm+twm+xterm;
But with what sort of language support (that's the m17n and scim bits)
then this list would ideally just be -gdm +kdm
It also looks somewhat resolved out -- I bet that the list could be shrunk somewhat -- yelp is probably the cause for libbeagle, firefox and perhaps more. Will look closer once I get through mail hell
Jeremy
While we are busy removing stuff, can I also propose:
-ImageMagick -tcsh
Unless there are any hidden reasons for keeping these - I couldn't find any dependencies that would pull them in, and at least ImageMagick is not really small.
On Tue, 2007-08-07 at 15:43 -0400, Matthias Clasen wrote:
While we are busy removing stuff, can I also propose: -ImageMagick
Arguably, why is ImageMagick default anyway instead of optional in comps? The same could be asked for dcraw. Generally, graphics-support is graphical apps... the command line tools probably shouldn't be defaults.
-tcsh
IIRC, there is something which gets unhappy without it, although my mind is blanking on what at the moment.
Jeremy
Jeremy Katz (katzj@redhat.com) said:
On Tue, 2007-08-07 at 15:43 -0400, Matthias Clasen wrote:
While we are busy removing stuff, can I also propose: -ImageMagick
Arguably, why is ImageMagick default anyway instead of optional in comps? The same could be asked for dcraw. Generally, graphics-support is graphical apps... the command line tools probably shouldn't be defaults.
Fixed.
-tcsh
IIRC, there is something which gets unhappy without it, although my mind is blanking on what at the moment.
Then whatever it is should require it (also fixed).
Bill
Am Di 7.August 2007 schrieb Jeremy Katz:
On Tue, 2007-08-07 at 15:37 -0400, Colin Walters wrote:
On Tue, 2007-08-07 at 18:47 +0200, Sebastian Vahl wrote:
Well, I didn't had much time. But these config is more closer to the normal one. I removed only @games from livecd-desktop-minimal.ks and removed the further not wanted packages in livecd-fedora-kde.ks. But the list is not complete yet.
# remove some packages from dekstop-minimal.ks -scim* -system-config-printer* -gdm -authconfig-gtk -m17n* -xorg-x11-fonts-* -xorg-x11-twm -PolicyKit-gnome -libbeagle -yelp -firefox -desktop-backgrounds-basic -gnome-doc-utils-stylesheets
Almost all of this should go back into desktop-minimal; the goal there is basically just be gdm+twm+xterm;
But with what sort of language support (that's the m17n and scim bits)
then this list would ideally just be -gdm +kdm
It also looks somewhat resolved out -- I bet that the list could be shrunk somewhat -- yelp is probably the cause for libbeagle, firefox and perhaps more. Will look closer once I get through mail hell
It seems to be this way: anaconda -> zenity -> yelp -> firefox, libbeagle
Sebastian
On Tue, 2007-08-07 at 23:07 +0200, Sebastian Vahl wrote:
Am Di 7.August 2007 schrieb Jeremy Katz:
It also looks somewhat resolved out -- I bet that the list could be shrunk somewhat -- yelp is probably the cause for libbeagle, firefox and perhaps more. Will look closer once I get through mail hell
It seems to be this way: anaconda -> zenity -> yelp -> firefox, libbeagle
Aha, so due to anaconda's trying out zenity to see if it gives us a way for people to give feedback during %post. Although it's not clear to me why zenity now depends on yelp.
Jeremy
On Tue, 2007-08-07 at 17:41 -0400, Jeremy Katz wrote:
On Tue, 2007-08-07 at 23:07 +0200, Sebastian Vahl wrote:
Am Di 7.August 2007 schrieb Jeremy Katz:
It also looks somewhat resolved out -- I bet that the list could be shrunk somewhat -- yelp is probably the cause for libbeagle, firefox and perhaps more. Will look closer once I get through mail hell
It seems to be this way: anaconda -> zenity -> yelp -> firefox, libbeagle
Aha, so due to anaconda's trying out zenity to see if it gives us a way for people to give feedback during %post. Although it's not clear to me why zenity now depends on yelp.
Thats directory dependencies for you. Everything that installs help in /usr/share/gnome/help depends on yelp...
Matthias Clasen wrote:
On Tue, 2007-08-07 at 17:41 -0400, Jeremy Katz wrote:
On Tue, 2007-08-07 at 23:07 +0200, Sebastian Vahl wrote:
Am Di 7.August 2007 schrieb Jeremy Katz:
It also looks somewhat resolved out -- I bet that the list could be shrunk somewhat -- yelp is probably the cause for libbeagle, firefox and perhaps more. Will look closer once I get through mail hell
It seems to be this way: anaconda -> zenity -> yelp -> firefox, libbeagle
Aha, so due to anaconda's trying out zenity to see if it gives us a way for people to give feedback during %post. Although it's not clear to me why zenity now depends on yelp.
Thats directory dependencies for you. Everything that installs help in /usr/share/gnome/help depends on yelp...
This is not very sane. Can we get this package fixed? In reasonably cases, the ownership guideline can have exceptions.
Rahul
Am Mi 8.August 2007 schrieb Rahul Sundaram:
Matthias Clasen wrote:
On Tue, 2007-08-07 at 17:41 -0400, Jeremy Katz wrote:
On Tue, 2007-08-07 at 23:07 +0200, Sebastian Vahl wrote:
Am Di 7.August 2007 schrieb Jeremy Katz:
It also looks somewhat resolved out -- I bet that the list could be shrunk somewhat -- yelp is probably the cause for libbeagle, firefox and perhaps more. Will look closer once I get through mail hell
It seems to be this way: anaconda -> zenity -> yelp -> firefox, libbeagle
Aha, so due to anaconda's trying out zenity to see if it gives us a way for people to give feedback during %post. Although it's not clear to me why zenity now depends on yelp.
Thats directory dependencies for you. Everything that installs help in /usr/share/gnome/help depends on yelp...
This is not very sane. Can we get this package fixed? In reasonably cases, the ownership guideline can have exceptions.
Any progress here? I really would like to save some space on the kde livecd.
Sebastian
On Tue, 2007-07-31 at 18:19 -0400, Colin Walters wrote:
I've done some work on the Live CD kickstart images, available here: http://submind.verbum.org/~walters/livecd.git/
(Until Jeremy returns from vacation and can review patches to be put in the main livecd git repository)
I'm baaaccckkkkk :-)
The most important change so far is to create "livecd-desktop-minimal.ks" which is then used as a basis for:
At a glance, this part looks reasonable. Need to fix up %include so that it doesn't depend on the working directory. But that looks pretty trivial -- we just need to subclass KickstartParser and override readKickstart() with a method that finds the file. Otherwise, people will hit what svahl did.
I also added a number of improvements to livecd-creator, the git log has the gory details.
Patches to the actual creator code to fedora-livecd-list if you don't mind so that I can review them there. I don't necessarily disagree with them, but it becomes a bit easier to review them more as specific patches on the list.
Jeremy
On Tue, 2007-08-07 at 14:28 -0400, Jeremy Katz wrote:
At a glance, this part looks reasonable. Need to fix up %include so that it doesn't depend on the working directory. But that looks pretty trivial -- we just need to subclass KickstartParser and override readKickstart() with a method that finds the file. Otherwise, people will hit what svahl did.
Looks like you fixed this one. Should we try to iterate the changes to the kickstart files, or do you want to just look at the patches in the git repository?
On Thu, 2007-08-09 at 12:38 -0400, Colin Walters wrote:
On Tue, 2007-08-07 at 14:28 -0400, Jeremy Katz wrote:
At a glance, this part looks reasonable. Need to fix up %include so that it doesn't depend on the working directory. But that looks pretty trivial -- we just need to subclass KickstartParser and override readKickstart() with a method that finds the file. Otherwise, people will hit what svahl did.
Looks like you fixed this one. Should we try to iterate the changes to the kickstart files, or do you want to just look at the patches in the git repository?
Yeah, seemed like a fun thing to throw together a fix for.
As for the kickstart files, I was going to take a look hopefully a little later today or tomorrow and get them in. Iterating patches to them on fedora-livecd-list is, in general, less interesting (at least, imho).
Jeremy
Hi,
One thing we probably want on the desktop live cd, compared to mainline Fedora, is making sure that the user's home directory are world-executable, e.g. like this
$ ls -l /home/ drwx--x--x 21 bateman bateman 4096 2007-08-12 19:01 bateman drwx--x--x 22 bundy bundy 4096 2007-07-28 19:01 bundy drwx--x--x 21 charles charles 4096 2007-07-28 18:24 charles drwx--x--x 42 davidz davidz 4096 2007-08-13 10:39 davidz
With this, the ~/.face files should be readable by other users meaning that the fast-user-switch applet in a given session can read ~/.face from other users (this is because the "About Me" capplet specifically uses the rw-r--r-- permissions when creating that file). Which means you'll get a nice list with the appropriate icons
http://people.freedesktop.org/~david/f-u-s-all-faces.png
Changing the mode on newly created home directories can, I believe, be achieved by rewriting /etc/login.defs such that UMASK is set to 066 instead of 077 (I haven't tested this though). Probably worth adding some sed invocation in the %post of the live cd kickstart file. Jeremy, Colin?
Btw, in the same vein, we probably want ~/Public to be created with mode rwxr-xr-x as well; I believe that requires a patch to xdg-user-dirs such that the mode can be specified in /etc/xdg/user-dirs.defaults. Longer term we should probably make ~/Public of other users visible somewhere and integrate it into the file manager or whatever. Alex?
David
On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote:
One thing we probably want on the desktop live cd, compared to mainline Fedora, is making sure that the user's home directory are world-executable, e.g. like this
[snip]
Changing the mode on newly created home directories can, I believe, be achieved by rewriting /etc/login.defs such that UMASK is set to 066 instead of 077 (I haven't tested this though). Probably worth adding some sed invocation in the %post of the live cd kickstart file. Jeremy, Colin?
From a quick test, it looks like it works. And
sed -i 's/UMASK *077/UMASK 066/g' /etc/login.defs seems like a workable sed invocation. If no one sees a reason not to, I'll get this added later (hoping to get Colin's abstraction bits in first)
Jeremy
On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote:
Hi,
One thing we probably want on the desktop live cd, compared to mainline Fedora, is making sure that the user's home directory are world-executable, e.g. like this
It's less of a low-hanging fruit, but I would love to also see us give every new account a random icon by default. It would be much cooler to see that than the question-mark silhouette.
Thanks, -Jonathan
On Mon, 2007-08-13 at 15:38 -0400, Jonathan Blandford wrote:
On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote:
One thing we probably want on the desktop live cd, compared to mainline Fedora, is making sure that the user's home directory are world-executable, e.g. like this
It's less of a low-hanging fruit, but I would love to also see us give every new account a random icon by default. It would be much cooler to see that than the question-mark silhouette.
random requires useradd hacking... something other than the question mark just requires dropping something in /etc/skel...
Jeremy
On Mon, 2007-08-13 at 15:56 -0400, Jeremy Katz wrote:
On Mon, 2007-08-13 at 15:38 -0400, Jonathan Blandford wrote:
On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote:
One thing we probably want on the desktop live cd, compared to mainline Fedora, is making sure that the user's home directory are world-executable, e.g. like this
It's less of a low-hanging fruit, but I would love to also see us give every new account a random icon by default. It would be much cooler to see that than the question-mark silhouette.
random requires useradd hacking... something other than the question mark just requires dropping something in /etc/skel...
Ideally we'd just ask questions like these (plus preselecting a suitable random one) as part of the installation process including using GNOME Cheese / ktuberling / etc. style apps available. Other things I'd like to see is the ability to select the desktop background / color scheme / whatever. It's also a nice place to plug in migration tools to fetch this data from another OS / whatever.
Also, it's preferable to do this at install time rather than firstboot time. Because I'm not so sure firstboot makes a lot of sense for a desktop/laptop targeted OS (though I'm sure it's great for enterprise workstation deployments).
In addition, ideally the user can do this while the bits are being moved to his hard disk.
David
David Zeuthen (davidz@redhat.com) said:
On Mon, 2007-08-13 at 15:56 -0400, Jeremy Katz wrote:
On Mon, 2007-08-13 at 15:38 -0400, Jonathan Blandford wrote:
On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote:
One thing we probably want on the desktop live cd, compared to mainline Fedora, is making sure that the user's home directory are world-executable, e.g. like this
It's less of a low-hanging fruit, but I would love to also see us give every new account a random icon by default. It would be much cooler to see that than the question-mark silhouette.
random requires useradd hacking... something other than the question mark just requires dropping something in /etc/skel...
Ideally we'd just ask questions like these (plus preselecting a suitable random one) as part of the installation process including using GNOME Cheese / ktuberling / etc. style apps available. Other things I'd like to see is the ability to select the desktop background / color scheme / whatever. It's also a nice place to plug in migration tools to fetch this data from another OS / whatever.
Also, it's preferable to do this at install time rather than firstboot time. Because I'm not so sure firstboot makes a lot of sense for a desktop/laptop targeted OS (though I'm sure it's great for enterprise workstation deployments).
? Surely all the 'create user' bits (which are in firstboot) are where you'd do this. Unless you want to move those into anaconda itself.
Bill
On Mon, 2007-08-27 at 16:54 -0400, Bill Nottingham wrote:
Also, it's preferable to do this at install time rather than firstboot time. Because I'm not so sure firstboot makes a lot of sense for a desktop/laptop targeted OS (though I'm sure it's great for enterprise workstation deployments).
? Surely all the 'create user' bits (which are in firstboot) are where you'd do this. Unless you want to move those into anaconda itself.
I think what David is getting at is that we would like to have only one install experience for the user. Right now, we have two install experiences -- the first when you run anaconda, the second when you hit firstboot. In the managed desktop case (enterprise workstations) the install is split between the admin who does the install on the machine and the enduser does the 'install' by setting up accounts/timezones. David is proposing to merge those for the desktop spin.
It's a bit aspirational, and there's a lot that should be cleaned up in firstboot first. But I think it's a good experience, too.
Thanks, -Jonathan
Jonathan Blandford (jrb@redhat.com) said:
I think what David is getting at is that we would like to have only one install experience for the user. Right now, we have two install experiences -- the first when you run anaconda, the second when you hit firstboot. In the managed desktop case (enterprise workstations) the install is split between the admin who does the install on the machine and the enduser does the 'install' by setting up accounts/timezones. David is proposing to merge those for the desktop spin.
It's a bit aspirational, and there's a lot that should be cleaned up in firstboot first. But I think it's a good experience, too.
What confuses me is that I'm not sure firstboot makes sense for any sort of 'managed' desktop - surely things like authentication, timezone, and users (on the network) have already been set up by that point? Firstboot seems more targeted for the 'home user' (ugh) who is getting a preinstalled box from some OEM.
What may make sense (and also be completely unimplementable) is to structure things so that steps can be moved between firstboot and anaconda at will based on some sort of configuration.
Bill
On Tue, 28 Aug 2007 13:41:11 -0400 Bill Nottingham notting@redhat.com wrote:
What may make sense (and also be completely unimplementable) is to structure things so that steps can be moved between firstboot and anaconda at will based on some sort of configuration.
Or we just drop some things from firstboot all together, move some (user creation) into anaconda, and then leave firstboot there as a possibility to be turned on and ran with say --reconfig which makes sense from the OEM point of view.
On Tue, 2007-08-28 at 13:41 -0400, Bill Nottingham wrote:
Jonathan Blandford (jrb@redhat.com) said:
I think what David is getting at is that we would like to have only one install experience for the user. Right now, we have two install experiences -- the first when you run anaconda, the second when you hit firstboot. In the managed desktop case (enterprise workstations) the install is split between the admin who does the install on the machine and the enduser does the 'install' by setting up accounts/timezones. David is proposing to merge those for the desktop spin.
It's a bit aspirational, and there's a lot that should be cleaned up in firstboot first. But I think it's a good experience, too.
What confuses me is that I'm not sure firstboot makes sense for any sort of 'managed' desktop - surely things like authentication, timezone, and users (on the network) have already been set up by that point? Firstboot seems more targeted for the 'home user' (ugh) who is getting a preinstalled box from some OEM.
It depends a bit on the enterprise doing the managing. Some of them do set timezones/users in advance, but most don't bother. Enough let the end user do it that I stand by my generalization. (-: Additionally, a non-trivial number of people add their own firstboot modules to the mix to set up site-specific stuff.
What may make sense (and also be completely unimplementable) is to structure things so that steps can be moved between firstboot and anaconda at will based on some sort of configuration.
Yeah, though that's led to some of the awkward sharing of code and a few poor design. One thing we proposed doing is actually moving firstboot to be part of GDM, and letting things like the timezone and user accounts be modifiable from there.
Thanks, -Jonathan
On Mon, 13.08.07 15:56, Jeremy Katz (katzj@redhat.com) wrote:
On Mon, 2007-08-13 at 15:38 -0400, Jonathan Blandford wrote:
On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote:
One thing we probably want on the desktop live cd, compared to mainline Fedora, is making sure that the user's home directory are world-executable, e.g. like this
It's less of a low-hanging fruit, but I would love to also see us give every new account a random icon by default. It would be much cooler to see that than the question-mark silhouette.
random requires useradd hacking...
Does it? You could just create ~/.faces on first login if it doesn't exist and select a random face then. Should be trivial.
Lennart
On Mon, 2007-08-13 at 22:35 +0200, Lennart Poettering wrote:
On Mon, 13.08.07 15:56, Jeremy Katz (katzj@redhat.com) wrote:
random requires useradd hacking...
Does it? You could just create ~/.faces on first login if it doesn't exist and select a random face then. Should be trivial.
Duh. Some days, I think too hard :-)
Jeremy
On Mon, 2007-08-13 at 12:10 -0400, David Zeuthen wrote:
Btw, in the same vein, we probably want ~/Public to be created with mode rwxr-xr-x as well; I believe that requires a patch to xdg-user-dirs such that the mode can be specified in /etc/xdg/user-dirs.defaults. Longer term we should probably make ~/Public of other users visible somewhere and integrate it into the file manager or whatever. Alex?
Interesting idea. Seems sane to me.
desktop@lists.stg.fedoraproject.org
-
Alexander Larsson -
Bill Nottingham -
Colin Walters -
David Zeuthen -
Jeremy Katz -
Jesse Keating -
Jonathan Blandford -
Lennart Poettering -
Matthias Clasen -
Rahul Sundaram -
Sebastian Vahl