[Mageia-dev] Freeze push: redmine 1.3.2
Hello, Could somebody pushing redmine 1.3.2 into cauldron? Redmine before 1.3.2 does not properly restrict the use of a hash to provide values for a model's attributes, which allows remote attackers to set attributes in the (1) Comment, (2) Document, (3) IssueCategory, (4) MembersController, (5) Message, (6) News, (7) TimeEntry, (8) Version, (9) Wiki, (10) UserPreference, or (11) Board model via a modified URL, related to a "mass assignment" vulnerability, a different vulnerability than CVE-2012-0327. Thanks.
Re: [Mageia-dev] Freeze push: drakx-installer-rescue
08.04.2012 03:51, Pascal Terjan skrev: > It fixes our modprobe to handle being called by the kernel (fixes mount > -t btrfs with module not yet loaded) pushed. -- Thomas
Re: [Mageia-dev] Freeze push: drakx-installer-binaries
On Sun, 08 Apr 2012, Pascal Terjan wrote: > It adds support for mounting btrfs from stage1 Submitted.
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Op zaterdag 07 april 2012 23:48:59 schreef Florian Hubold: > Am 07.04.2012 21:25, schrieb Maarten Vanraes: [...] > > otoh, "silence is acceptance" is one of my favourite sayings... > > Well, when i pointed out those branding issues before, > noone was interested either, here on this list ... guilty as charged...
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Am 07.04.2012 21:25, schrieb Maarten Vanraes: > Op zaterdag 07 april 2012 21:14:00 schreef Florian Hubold: >> Am 07.04.2012 20:59, schrieb Maarten Vanraes: >>> Op zaterdag 07 april 2012 20:50:03 schreef Florian Hubold: Am 05.04.2012 14:19, schrieb Romain d'Alverny: > On Thu, Apr 5, 2012 at 08:11, Maarten Vanraes wrote: >> Op woensdag 04 april 2012 22:59:30 schreef Florian Hubold: >>> As there was no real objection, and no other comments >>> or votes for iceape, i've dropped it from cauldron. FWIW i'm quite >>> unhappy with this. Related, i've also not got any reply yet to my >>> aforementioned inquiry about mozilla branding permissions. >> About the mozilla branding... >> >> Perhaps this should be a meeting point for packaging/council >> meeting... >> >> ie: someone assigned to this point so it's not forgotten. > Would have been good to raise this point in Council way sooner. No > other than the maintainers may answer both questions (about changes, > and about contact/permissions from Mozilla). For Firefox it's dmorgan > and for Thunderbird it's anssi. For thunderbird it's actually me, Anssi grabbed it on my behalf when i was still apprentice ;) >>> no offense, but if you're the thunderbird maintainer, why don't you ask >>> mozilla about it? tell them if we're not getting this official >>> permission we won't ship it and do the iceape thing instead... >> Did you read my previous mails? I've asked Kev Needham, >> mozilla distribution channel manager, about the approval >> process, sadly no answer yet. > ah, mea culpa, i must've missed a few > > and too bad though... > > you can ask a few more people and CC some of the "important people" (or ones > having good connections) like annael, stewb or such... > > otoh, "silence is acceptance" is one of my favourite sayings... > Well, when i pointed out those branding issues before, noone was interested either, here on this list ...
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Op zaterdag 07 april 2012 21:14:00 schreef Florian Hubold: > Am 07.04.2012 20:59, schrieb Maarten Vanraes: > > Op zaterdag 07 april 2012 20:50:03 schreef Florian Hubold: > >> Am 05.04.2012 14:19, schrieb Romain d'Alverny: > >>> On Thu, Apr 5, 2012 at 08:11, Maarten Vanraes wrote: > Op woensdag 04 april 2012 22:59:30 schreef Florian Hubold: > > As there was no real objection, and no other comments > > or votes for iceape, i've dropped it from cauldron. FWIW i'm quite > > unhappy with this. Related, i've also not got any reply yet to my > > aforementioned inquiry about mozilla branding permissions. > > About the mozilla branding... > > Perhaps this should be a meeting point for packaging/council > meeting... > > ie: someone assigned to this point so it's not forgotten. > >>> > >>> Would have been good to raise this point in Council way sooner. No > >>> other than the maintainers may answer both questions (about changes, > >>> and about contact/permissions from Mozilla). For Firefox it's dmorgan > >>> and for Thunderbird it's anssi. > >> > >> For thunderbird it's actually me, Anssi grabbed it on my behalf > >> when i was still apprentice ;) > > > > no offense, but if you're the thunderbird maintainer, why don't you ask > > mozilla about it? tell them if we're not getting this official > > permission we won't ship it and do the iceape thing instead... > > Did you read my previous mails? I've asked Kev Needham, > mozilla distribution channel manager, about the approval > process, sadly no answer yet. ah, mea culpa, i must've missed a few and too bad though... you can ask a few more people and CC some of the "important people" (or ones having good connections) like annael, stewb or such... otoh, "silence is acceptance" is one of my favourite sayings...
[Mageia-dev] [systemd] keyboard shortcut to show jobs during boot
in order to investigate hangs or slow boots or whatever, it would be useful to have some kind of key combination that lists the current systemd jobs and where it's hanging/waiting or whatever either that or detect a hang an spawn some kind of emergency login somewhere actually, if i'm really pulling out my want-to-have book, howabout a tty that (until it can actually get a tty), shows an top like watch of current jobs in systemd, where you can force some kind of process, ie: killing it, or letting all the dependant ones go through. perhaps that could be on the tty that would eventually always become a tty (as i remember we talked about) let's say that tty12 gets the kernel logging, then tty11 could show first dracut/udev stuff, then proceed with systemd jobs, and when it can get a tty, to be reserved for tty. (all the others could be reserved for graphicals then) that way, no matter what happens, you get some nice info/tty availability. ok, give all this nice-to-have... is there a way we can find out why a boot hangs? is there some logging we can check in a rescue or ...?
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Am 07.04.2012 20:59, schrieb Maarten Vanraes: > Op zaterdag 07 april 2012 20:50:03 schreef Florian Hubold: >> Am 05.04.2012 14:19, schrieb Romain d'Alverny: >>> On Thu, Apr 5, 2012 at 08:11, Maarten Vanraes wrote: Op woensdag 04 april 2012 22:59:30 schreef Florian Hubold: > As there was no real objection, and no other comments > or votes for iceape, i've dropped it from cauldron. FWIW i'm quite > unhappy with this. Related, i've also not got any reply yet to my > aforementioned inquiry about mozilla branding permissions. About the mozilla branding... Perhaps this should be a meeting point for packaging/council meeting... ie: someone assigned to this point so it's not forgotten. >>> Would have been good to raise this point in Council way sooner. No >>> other than the maintainers may answer both questions (about changes, >>> and about contact/permissions from Mozilla). For Firefox it's dmorgan >>> and for Thunderbird it's anssi. >> For thunderbird it's actually me, Anssi grabbed it on my behalf >> when i was still apprentice ;) > no offense, but if you're the thunderbird maintainer, why don't you ask > mozilla > about it? tell them if we're not getting this official permission we won't > ship > it and do the iceape thing instead... > Did you read my previous mails? I've asked Kev Needham, mozilla distribution channel manager, about the approval process, sadly no answer yet.
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Op zaterdag 07 april 2012 20:50:03 schreef Florian Hubold: > Am 05.04.2012 14:19, schrieb Romain d'Alverny: > > On Thu, Apr 5, 2012 at 08:11, Maarten Vanraes wrote: > >> Op woensdag 04 april 2012 22:59:30 schreef Florian Hubold: > >>> As there was no real objection, and no other comments > >>> or votes for iceape, i've dropped it from cauldron. FWIW i'm quite > >>> unhappy with this. Related, i've also not got any reply yet to my > >>> aforementioned inquiry about mozilla branding permissions. > >> > >> About the mozilla branding... > >> > >> Perhaps this should be a meeting point for packaging/council meeting... > >> > >> ie: someone assigned to this point so it's not forgotten. > > > > Would have been good to raise this point in Council way sooner. No > > other than the maintainers may answer both questions (about changes, > > and about contact/permissions from Mozilla). For Firefox it's dmorgan > > and for Thunderbird it's anssi. > > For thunderbird it's actually me, Anssi grabbed it on my behalf > when i was still apprentice ;) no offense, but if you're the thunderbird maintainer, why don't you ask mozilla about it? tell them if we're not getting this official permission we won't ship it and do the iceape thing instead...
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Am 05.04.2012 14:19, schrieb Romain d'Alverny: > On Thu, Apr 5, 2012 at 08:11, Maarten Vanraes wrote: >> Op woensdag 04 april 2012 22:59:30 schreef Florian Hubold: >>> As there was no real objection, and no other comments >>> or votes for iceape, i've dropped it from cauldron. FWIW i'm quite >>> unhappy with this. Related, i've also not got any reply yet to my >>> aforementioned inquiry about mozilla branding permissions. >> About the mozilla branding... >> >> Perhaps this should be a meeting point for packaging/council meeting... >> >> ie: someone assigned to this point so it's not forgotten. > Would have been good to raise this point in Council way sooner. No > other than the maintainers may answer both questions (about changes, > and about contact/permissions from Mozilla). For Firefox it's dmorgan > and for Thunderbird it's anssi. > For thunderbird it's actually me, Anssi grabbed it on my behalf when i was still apprentice ;)
Re: [Mageia-dev] painful discussion n°1: debloating
On Saturday 07 April 2012 18:47, Wolfgang Bornath wrote: > I'm using Firefox but totem-mozilla is one of those packages I unmark > everytime > in individual package selection without any regression for Firefox. I do the same, and likewise have no problems. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] painful discussion n°1: debloating
2012/4/7 Sander Lepik : > 07.04.2012 19:18, Thomas Spuhler kirjutas: >> >> On Saturday, April 07, 2012 08:38:39 AM Guillaume Rousse wrote: >>> >>> To summarize it: >>> - has anyone any opposition to remove the totem-mozilla - KDE >>> relationship in the installer ? >> >> I'd go for this. > > I'm not so sure about that. Are there any other alternatives for that? > Firefox may be gtk app but most people still use it under KDE too. If you > remove those plugins then i would say usability will be hit. totem-mozilla does not seem to be a dependency for Firefox. I'm using Firefox but totem-mozilla is one of those packages I unmark everytime in individual package selection without any regression for Firefox. -- wobo
Re: [Mageia-dev] painful discussion n°1: debloating
07.04.2012 19:18, Thomas Spuhler kirjutas: On Saturday, April 07, 2012 08:38:39 AM Guillaume Rousse wrote: To summarize it: - has anyone any opposition to remove the totem-mozilla - KDE relationship in the installer ? I'd go for this. I'm not so sure about that. Are there any other alternatives for that? Firefox may be gtk app but most people still use it under KDE too. If you remove those plugins then i would say usability will be hit. -- Sander
Re: [Mageia-dev] painful discussion n°1: debloating
On Saturday, April 07, 2012 08:38:39 AM Guillaume Rousse wrote: > If thos of you lucky enough to have missed the beginning of the story, > here are the importants parts: > - first round: bug #4357, still marked as release blocker (despite a bit > excessive IMHO) > - second round: discussion on -dev, archived here: > https://www.mageia.org/pipermail/mageia-dev/2012-March/013342.html > > The whole issue turns around the unfortunate consequence of adding new > dependencies, for various reasons, between packages and in installer: > bloated minimal installation. In this case, this is about a specific > *soft* dependency from gnome-keyring to seahorse, which has painful > consequences, as outline by TV in comment #5 of the original report. > > Suggestion sofar for this initial problem have been suggested: > 1) move the gnome-keyring -> seahorse soft dependency either in > task-gnome, or task-gnome-minimal > 2) turn the mandatory dependency between libgnome-keyring to > gnome-keyring into a soft dependency > 3) remove the dependency on a gnome component from the KDE category in > the installer > > But sofar, nothing was done AFAIK, the bug is still open. > > From my own personal and biased reading, solution #3, makes sense. > Actually, it would only adress a part of the problem, as installing the > distribution doesn't mandatorily means 'running the installer'. chroot > installation, for instance, or automated installations, are not affected > by rpmsrate, but still face side-effect of those nasty 'useful' > dependencies between packages. Of course, this only concern expert > users, who usually know about --no-suggest urpmi option. > > Solution #1 would also make some sense for me. As pointed out by TV, you > don't mandatorily install gnome-keyring because you need it, but because > you don't have the choice, and something else introduced it without > asking you. That's a bit difficult to argue in this case that you may > need seahorse to manage your keys, merely because you problably never > intended to store keys anyway. So I'd also implement this solution, > despite once again, if you really care, you may use --no-suggest also. > > Solution #2, tough, would introduce some precedent. AFAIK, all gnome > libs unfortunatly require their binaries to be installed alongside to be > used, for I can't remember technical reason. So, I'd rather reject it. > > To summarize it: > - has anyone any opposition to remove the totem-mozilla - KDE > relationship in the installer ? I'd go for this. > - Olav (or anyone else), do you have any objection to *also* move the > soft dependency from gnome-keyring to seahorse to either task-gnome or > task-gnome-minimal ? > > More generally, we still lack a clear view of interactions between > choice hardcoded in installer rpmsrate, and two different kind of > dependencies between packages. And a general policy on this kind of > issues, aiming a correct balance between 'avoinding poor users the pain > of installing additional stuff themselves' and 'keeping system minimal'. -- Best regards Thomas Spuhler
Re: [Mageia-dev] X + nvidia( + KDE & kwin) = major memory leak
2012/4/7 Sander Lepik : > For me this combination is causing pretty huge memory leak in X. At the same > time xrestop doesn't show anything. Anssi updated Nvidia's driver to the > latest but this doesn't seem to help much. > > So my question is: am i the only one or are there other people seeing this > too? It only seems to happen with nvidia cards. > > In 3 days my X was using 700+ MB of memory.. Can't confirm this with the same setup: Uptime: 10 days, 9:44 hrs Memory for X (VIRT RES SHR): 226m 136m 17m -- wobo
[Mageia-dev] painful discussion n°1: debloating
If thos of you lucky enough to have missed the beginning of the story, here are the importants parts: - first round: bug #4357, still marked as release blocker (despite a bit excessive IMHO) - second round: discussion on -dev, archived here: https://www.mageia.org/pipermail/mageia-dev/2012-March/013342.html The whole issue turns around the unfortunate consequence of adding new dependencies, for various reasons, between packages and in installer: bloated minimal installation. In this case, this is about a specific *soft* dependency from gnome-keyring to seahorse, which has painful consequences, as outline by TV in comment #5 of the original report. Suggestion sofar for this initial problem have been suggested: 1) move the gnome-keyring -> seahorse soft dependency either in task-gnome, or task-gnome-minimal 2) turn the mandatory dependency between libgnome-keyring to gnome-keyring into a soft dependency 3) remove the dependency on a gnome component from the KDE category in the installer But sofar, nothing was done AFAIK, the bug is still open. From my own personal and biased reading, solution #3, makes sense. Actually, it would only adress a part of the problem, as installing the distribution doesn't mandatorily means 'running the installer'. chroot installation, for instance, or automated installations, are not affected by rpmsrate, but still face side-effect of those nasty 'useful' dependencies between packages. Of course, this only concern expert users, who usually know about --no-suggest urpmi option. Solution #1 would also make some sense for me. As pointed out by TV, you don't mandatorily install gnome-keyring because you need it, but because you don't have the choice, and something else introduced it without asking you. That's a bit difficult to argue in this case that you may need seahorse to manage your keys, merely because you problably never intended to store keys anyway. So I'd also implement this solution, despite once again, if you really care, you may use --no-suggest also. Solution #2, tough, would introduce some precedent. AFAIK, all gnome libs unfortunatly require their binaries to be installed alongside to be used, for I can't remember technical reason. So, I'd rather reject it. To summarize it: - has anyone any opposition to remove the totem-mozilla - KDE relationship in the installer ? - Olav (or anyone else), do you have any objection to *also* move the soft dependency from gnome-keyring to seahorse to either task-gnome or task-gnome-minimal ? More generally, we still lack a clear view of interactions between choice hardcoded in installer rpmsrate, and two different kind of dependencies between packages. And a general policy on this kind of issues, aiming a correct balance between 'avoinding poor users the pain of installing additional stuff themselves' and 'keeping system minimal'. -- BOFH excuse #189: SCSI's too wide.
Re: [Mageia-dev] A note on autologin and startx
On Sat, Apr 07, 2012 at 09:50:15AM +0200, Wolfgang Bornath wrote: > Does GDM provide change of desktop as KDM does? Yeah, with a small note. You can select your desktop after you selected the user. This is when you enter the password. Side-effect: people with passwords can change their desktops, people without passwords just log in :P (it selects the default whatever that is, doesn't have to be GNOME) -- Regards, Olav
Re: [Mageia-dev] Release_blocker bugs
Le 06/04/2012 13:17, Anne nicolas a écrit : GNOME 3 --- 4553o...@vitters.nl Gnome 3 starts in fallback mode after boot, but Gnome Shell available after logout 4419o...@vitters.nl Change default background in gdm and default gnome-sessions (shell+fallback) 4357thierry.vign...@gmail.com [debloat] consider moving Suggests: seahorse to task-gnome 3774bugsq...@mageia.org GNOME3 on free DVD? (requires non-free drivers) Given the decision criteria given during the meeting (mainly "can't be fixed after the release"), I would only consider the last one (3774) as a release blocker. 4453 seems a past technical issue 4419 is purely a cosmetic issue, and probably easy to fix 4357 is not really a technical issue, and requires some discussion, but should not block the release if not properly fnished before 3774 just requires an (easy IMHO) decision to be made. -- BOFH excuse #47: Complete Transient Lockout
[Mageia-dev] freeze push: munin
rc2 -> rc4 change -- Fusible interfacings always fuse to the iron -- Murphy's Laws of Sewing n°1
[Mageia-dev] X + nvidia( + KDE & kwin) = major memory leak
For me this combination is causing pretty huge memory leak in X. At the same time xrestop doesn't show anything. Anssi updated Nvidia's driver to the latest but this doesn't seem to help much. So my question is: am i the only one or are there other people seeing this too? It only seems to happen with nvidia cards. In 3 days my X was using 700+ MB of memory.. -- Sander
Re: [Mageia-dev] nvidia
07.04.2012 03:41, Pascal Terjan skrev: > Hi, > > regarding http://check.mageia.org/cauldron/tmb/dependencies.html do you > know if nvidia173/kmod-nvidia173 and nvidia-96xx/kmod-nvidia96xx should > be obsoleted by something (nouveau?)? > Well, kmod-nvidia96xx/173 and the matching nvidia*kernel*latest can simply be nuked from the repos as they are Cauldron only packages So it leaves theese: dkms-nvidia96xx nvidia96xx-devel nvidia96xx-doc-html x11-driver-video-nvidia96xx dkms-nvidia173 nvidia173-cuda nvidia173-devel nvidia173-doc-html x11-driver-video-nvidia173 I guess the dkms-nvidia96xx/173 packages should be obsoleted by kernel, and the x11-driver-video-nvidia96xx/173 should be obsoleted by x11-driver-video-nouveau. Hmmm, do we need triggers to handle gl.conf for nvidia like we need for fglrx ? Anssi, wdyt ? > I don't know anything about nvidia but internet says 173 and 96xx are > not compatible with x11-server 1.11 > Compatibility with 1.10 was added in the latest version, in August last > year, 6 months after 1.10 was released, and a week before 1.11 was > released. It has now been more than 6 months since 1.11 was released, > 1.12 was released last month, so should we still expect 1.11 (and recent > kernels) support to happen? It does not really seem like nVidia will support them, but I can be wrong... Anssi ? -- Thomas
Re: [Mageia-dev] Freeze push: compiz 0.9.7.6
Le Fri, 6 Apr 2012 21:58:09 +0200, Julien a écrit : > Hi, > > please push compiz 0.9.7.6 which contains several bugfix and performance > optimizations > Thanks > > Regards > Julien ping ?
Re: [Mageia-dev] Freeze push: webkit 1.8.0
On Sat, 07 Apr 2012, Funda Wang wrote: > Hello, > > Could somebody push webkit 1.8.0 into cauldron? We are aiming at 1.8.0 > stable in mga2, while we current have 1.7.92 unstable for cauldron. Submitted.
Re: [Mageia-dev] Freeze push: drakxtools and drakx-installer-stage2
On Sat, 07 Apr 2012, Pascal Terjan wrote: > For drakx-installer-stage2: > > - Mageia 2 beta 3 banner > - diskdrake: > o fix partition numbering on GPT (mga#3091) > > For drakxtools: > > - diskdrake: > o fix partition numbering on GPT (mga#3091) Submitted.
Re: [Mageia-dev] Freeze push: lightdm
On Sat, 07 Apr 2012, Funda Wang wrote: > Hello, > > Could somebody push lightdm 1.0.11 into cauldron? It fixes a security > problem usn-1382-1: Light Display Manager would allow unintended > access to file descriptors. Submitted.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release perl-Dist-Zilla-PluginBundle-Author-JQUELIN-2.120.970-1.mga2
On Sat, Apr 7, 2012 at 08:51, Jerome Quelin wrote: > On 12/04/07 00:58 +0100, Pascal Terjan wrote: > > On Fri, Apr 6, 2012 at 11:02, jquelin > wrote: > > > Name: perl-Dist-Zilla-PluginBundle-Author-JQUELIN Relocations: > > > (not relocatable) > > > Version : 2.120.970 Vendor: Mageia.Org > > > Release : 1.mga2Build Date: Fri Apr 6 > > > 11:59:56 2012 > > > Install Date: (not installed) Build Host: > jonund.mageia.org > > > Group : Development/Perl Source RPM: (none) > > > Size: 19350License: GPL+ or > Artistic > > > Signature : (none) > > > Packager: jquelin > > > URL : > > > http://search.cpan.org/dist/Dist-Zilla-PluginBundle-Author-JQUELIN > > > Summary : Build & release a distribution like jquelin > > > Description : > > > This is a plugin bundle to load all dist-zilla plugins that jq is > using. > > > > > > jquelin 2.120.970-1.mga2: > > > + Revision: 228900 > > > - update to 2.120970 > > > - dist renamed upstream > > > > but upstream did not update Task-Dist-Zilla, bad upstream ! :) > > yeah, bad upstream. task::dist::zilla is really outdated, i need to > update it. anyway, i fixed this particular requires: > > thanks!
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release perl-Dist-Zilla-PluginBundle-Author-JQUELIN-2.120.970-1.mga2
On 12/04/07 00:58 +0100, Pascal Terjan wrote: > On Fri, Apr 6, 2012 at 11:02, jquelin wrote: > > Name: perl-Dist-Zilla-PluginBundle-Author-JQUELIN Relocations: > > (not relocatable) > > Version : 2.120.970 Vendor: Mageia.Org > > Release : 1.mga2Build Date: Fri Apr 6 > > 11:59:56 2012 > > Install Date: (not installed) Build Host: jonund.mageia.org > > Group : Development/Perl Source RPM: (none) > > Size: 19350License: GPL+ or Artistic > > Signature : (none) > > Packager: jquelin > > URL : > > http://search.cpan.org/dist/Dist-Zilla-PluginBundle-Author-JQUELIN > > Summary : Build & release a distribution like jquelin > > Description : > > This is a plugin bundle to load all dist-zilla plugins that jq is using. > > > > jquelin 2.120.970-1.mga2: > > + Revision: 228900 > > - update to 2.120970 > > - dist renamed upstream > > but upstream did not update Task-Dist-Zilla, bad upstream ! :) yeah, bad upstream. task::dist::zilla is really outdated, i need to update it. anyway, i fixed this particular requires: jérôme
Re: [Mageia-dev] A note on autologin and startx
2012/4/7 Jose Jorge : > Le 06/04/2012 22:53, Colin Guthrie a écrit : > >> Couldn't agree more. I'd say we can happily provide a tool to configure >> autologin, but if that is configured, it basically just sets the DM to >> gdm, and lets' it do the autologin. >> >> The fact that gdm is used should be mostly hidden from users. >> >> > From what I've seen, gdm seems to be the best implementation of the >> whole pam and authentication stuff, so this would be my personal >> favourite. >> >> Col > > Please note that autologin is lightweight and fast, so I use it for very old > systems, where even the 30Mb of RAM eaten by gdm count. > But I just can agree that if no one has time to fix it, we can drop it. I'll > be away from computers for 15 days ... Does GDM provide change of desktop as KDM does? My scenario: I have KDE and Gnome and Xfce installed. For system start I have autologin set to start KDE. But when I am in a KDE session I sometimes logout and use the upcoming KDM to start a Gnome or Xfce session or even a session on a vt. Does this work with GDM as well? If so I'm all in. -- wobo
