From bnocera at redhat.com Sat Dec 1 00:33:56 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Sat, 01 Dec 2007 00:33:56 +0000 Subject: automatic unlocking of keyring In-Reply-To: <1196458982.6900.5.camel@localhost.localdomain> References: <1196440726.4562.6.camel@localhost.localdomain> <1196457924.6750.2.camel@oneill.fubar.dk> <1196458982.6900.5.camel@localhost.localdomain> Message-ID: <1196469236.3227.170.camel@cookie.hadess.net> On Fri, 2007-11-30 at 16:43 -0500, Matthias Clasen wrote: > On Fri, 2007-11-30 at 16:25 -0500, David Zeuthen wrote: > > ? 1. Logging in via fingerprint auth; doesn't work.. but that's expected > > That'll work once you engrave your password on your fingertip, I guess. Or have the password updated in the fingerprint blob... From jon.nettleton at gmail.com Sat Dec 1 00:51:31 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 30 Nov 2007 19:51:31 -0500 Subject: automatic unlocking of keyring In-Reply-To: <1196469236.3227.170.camel@cookie.hadess.net> References: <1196440726.4562.6.camel@localhost.localdomain> <1196457924.6750.2.camel@oneill.fubar.dk> <1196458982.6900.5.camel@localhost.localdomain> <1196469236.3227.170.camel@cookie.hadess.net> Message-ID: <1196470291.2424.103.camel@birkoff.charles.net> On Sat, 2007-12-01 at 00:33 +0000, Bastien Nocera wrote: > On Fri, 2007-11-30 at 16:43 -0500, Matthias Clasen wrote: > > On Fri, 2007-11-30 at 16:25 -0500, David Zeuthen wrote: > > > > ? 1. Logging in via fingerprint auth; doesn't work.. but that's expected > > > > That'll work once you engrave your password on your fingertip, I guess. > > Or have the password updated in the fingerprint blob... > That is how it was addressed when I first took over pam_keyring. Pam_bio_api (relying on unix permissions for secrecy) had an embedded pass-phrase in the BIR. This allowed their pam-module to authenticate on finger-print scan then populate the AUTHTOKEN of the pam stack with the passphrase and pass it along to other pam modules. Could be implemented better, but has the correct idea. Jon From walters at redhat.com Sun Dec 2 19:48:01 2007 From: walters at redhat.com (Colin Walters) Date: Sun, 02 Dec 2007 14:48:01 -0500 Subject: Firefox 3 feature Message-ID: <1196624881.23681.6.camel@space-ghost.verbum.private> Hi, I tossed up a Feature page for Fx3: http://fedoraproject.org/wiki/Releases/FeatureFirefox3 I put my and Chris' name on it. Tentatively thinking of making a branch in CVS where we could collaborate on it and do koji scratch builds from; any opinions on that? From davidz at redhat.com Sun Dec 2 22:19:42 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 02 Dec 2007 17:19:42 -0500 Subject: Firefox 3 feature In-Reply-To: <1196624881.23681.6.camel@space-ghost.verbum.private> References: <1196624881.23681.6.camel@space-ghost.verbum.private> Message-ID: <1196633982.7278.24.camel@oneill.fubar.dk> On Sun, 2007-12-02 at 14:48 -0500, Colin Walters wrote: > Hi, > > I tossed up a Feature page for Fx3: > > http://fedoraproject.org/wiki/Releases/FeatureFirefox3 > > I put my and Chris' name on it. Tentatively thinking of making a branch > in CVS where we could collaborate on it and do koji scratch builds from; > any opinions on that? I, for one, would like to see this; there's so much good stuff in FF3. Are you also planning to land Prism? Or is that a separate feature? Thanks! David From mclasen at redhat.com Mon Dec 3 00:16:34 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 02 Dec 2007 19:16:34 -0500 Subject: Firefox 3 feature In-Reply-To: <1196633982.7278.24.camel@oneill.fubar.dk> References: <1196624881.23681.6.camel@space-ghost.verbum.private> <1196633982.7278.24.camel@oneill.fubar.dk> Message-ID: <1196640994.3665.3.camel@localhost.localdomain> On Sun, 2007-12-02 at 17:19 -0500, David Zeuthen wrote: > On Sun, 2007-12-02 at 14:48 -0500, Colin Walters wrote: > > Hi, > > > > I tossed up a Feature page for Fx3: > > > > http://fedoraproject.org/wiki/Releases/FeatureFirefox3 > > > > I put my and Chris' name on it. Tentatively thinking of making a branch > > in CVS where we could collaborate on it and do koji scratch builds from; > > any opinions on that? > > I, for one, would like to see this; there's so much good stuff in FF3. > Are you also planning to land Prism? Or is that a separate feature? > Thanks! Chris is on top of this, I believe. He said they'd start looking into FF3 as soon as the xulrunner conversion is done. From caillon at redhat.com Mon Dec 3 12:14:56 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 03 Dec 2007 13:14:56 +0100 Subject: Firefox 3 feature In-Reply-To: <1196624881.23681.6.camel@space-ghost.verbum.private> References: <1196624881.23681.6.camel@space-ghost.verbum.private> Message-ID: <4753F340.10906@redhat.com> On 12/02/2007 08:48 PM, Colin Walters wrote: > Hi, > > I tossed up a Feature page for Fx3: > > http://fedoraproject.org/wiki/Releases/FeatureFirefox3 > > I put my and Chris' name on it. Tentatively thinking of making a branch > in CVS where we could collaborate on it and do koji scratch builds from; > any opinions on that? Help with rebuilding the stack against xulrunner. As soon as we're no longer relying on firefox 2 for our apps, and built against xulrunner, we'll simply rebase. No need for branches. From mcepl at redhat.com Mon Dec 3 12:24:44 2007 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 03 Dec 2007 13:24:44 +0100 Subject: Firefox 3 feature References: <1196624881.23681.6.camel@space-ghost.verbum.private> Message-ID: On Sun, 02 Dec 2007 14:48:01 -0500, Colin Walters scripst: > Hi, > > I tossed up a Feature page for Fx3: > > http://fedoraproject.org/wiki/Releases/FeatureFirefox3 > > I put my and Chris' name on it. Tentatively thinking of making a branch > in CVS where we could collaborate on it and do koji scratch builds from; > any opinions on that? That it is useless IMHO -- FF3 is very high on the Chris' and Martin's TODO list. Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From walters at redhat.com Mon Dec 3 15:03:31 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 03 Dec 2007 10:03:31 -0500 Subject: Firefox 3 feature In-Reply-To: References: <1196624881.23681.6.camel@space-ghost.verbum.private> Message-ID: <1196694211.4398.5.camel@space-ghost.verbum.private> On Mon, 2007-12-03 at 13:24 +0100, Matej Cepl wrote: > On Sun, 02 Dec 2007 14:48:01 -0500, Colin Walters scripst: > > > Hi, > > > > I tossed up a Feature page for Fx3: > > > > http://fedoraproject.org/wiki/Releases/FeatureFirefox3 > > > > I put my and Chris' name on it. Tentatively thinking of making a branch > > in CVS where we could collaborate on it and do koji scratch builds from; > > any opinions on that? > > That it is useless IMHO -- FF3 is very high on the Chris' and Martin's > TODO list. Having the feature is useless? Or a branch? The reason I created it is because it isn't actually as trivial as just changing everything to XulRunner and updating the Firefox package - we do ship Firefox extensions (at least in Mugshot, perhaps elsewhere) and plugins (e.g. Totem) that will require testing and possibly porting. Actually I know Mugshot will need a bit of porting to pick up the new cookie file format (http://bugzilla.mugshot.org/show_bug.cgi?id=1307). From drago01 at gmail.com Mon Dec 3 15:48:55 2007 From: drago01 at gmail.com (drago01) Date: Mon, 03 Dec 2007 16:48:55 +0100 Subject: Firefox 3 feature In-Reply-To: <1196694211.4398.5.camel@space-ghost.verbum.private> References: <1196624881.23681.6.camel@space-ghost.verbum.private> <1196694211.4398.5.camel@space-ghost.verbum.private> Message-ID: <47542567.6040903@gmail.com> Colin Walters wrote: > On Mon, 2007-12-03 at 13:24 +0100, Matej Cepl wrote: > >> On Sun, 02 Dec 2007 14:48:01 -0500, Colin Walters scripst: >> >> >>> Hi, >>> >>> I tossed up a Feature page for Fx3: >>> >>> http://fedoraproject.org/wiki/Releases/FeatureFirefox3 >>> >>> I put my and Chris' name on it. Tentatively thinking of making a branch >>> in CVS where we could collaborate on it and do koji scratch builds from; >>> any opinions on that? >>> >> That it is useless IMHO -- FF3 is very high on the Chris' and Martin's >> TODO list. >> > > Having the feature is useless? Or a branch? > > The reason I created it is because it isn't actually as trivial as just > changing everything to XulRunner and updating the Firefox package - we > do ship Firefox extensions (at least in Mugshot, perhaps elsewhere) afaik beagle too From fedora at leemhuis.info Mon Dec 3 16:09:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 03 Dec 2007 17:09:30 +0100 Subject: Firefox 3 feature In-Reply-To: <1196694211.4398.5.camel@space-ghost.verbum.private> References: <1196624881.23681.6.camel@space-ghost.verbum.private> <1196694211.4398.5.camel@space-ghost.verbum.private> Message-ID: <47542A3A.1060801@leemhuis.info> On 03.12.2007 16:03, Colin Walters wrote: > The reason I created it is because it isn't actually as trivial as just > changing everything to XulRunner and updating the Firefox package - we > do ship Firefox extensions (at least in Mugshot, perhaps elsewhere) I don't think we ship any besides Mugshot -- and if I'm wrong on that I'm sure they are very rare because we have no guidelines for packaging them. Some packages with extensions were put up for review but they iirc got stuck. Which brings me to my question: Does anyone know if Firefox 3 makes it easier to package extensions (that was planed iirc)? Should we prepare guidelines for packaging extensions? CU knurd From walters at redhat.com Mon Dec 3 16:39:33 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 03 Dec 2007 11:39:33 -0500 Subject: Firefox 3 feature In-Reply-To: <47542A3A.1060801@leemhuis.info> References: <1196624881.23681.6.camel@space-ghost.verbum.private> <1196694211.4398.5.camel@space-ghost.verbum.private> <47542A3A.1060801@leemhuis.info> Message-ID: <1196699973.4398.28.camel@space-ghost.verbum.private> On Mon, 2007-12-03 at 17:09 +0100, Thorsten Leemhuis wrote: > On 03.12.2007 16:03, Colin Walters wrote: > > The reason I created it is because it isn't actually as trivial as just > > changing everything to XulRunner and updating the Firefox package - we > > do ship Firefox extensions (at least in Mugshot, perhaps elsewhere) > > I don't think we ship any besides Mugshot -- drago01 pointed out Beagle. As an aside, we need a search-across-all-package-content system. > Which brings me to my question: Does anyone know if Firefox 3 makes it > easier to package extensions (that was planed iirc)? Should we prepare > guidelines for packaging extensions? I don't think there were any changes to the extension mechanism specifically for this (I could be wrong though), but if we do work on this would make a lot of sense to design the system in the context of upstream. Realistically the Firefox binary has to be aware of the distinction between system managed and per-user extensions. I don't think it is right now, because at least currently it seems that Firefox tries to find updates to all the localization packages we install, which is wrong because they're managed by the system. (Incidentally this also seems to be part of the reason Firefox is so slow to start the first time). There would need to be UI changes in the addon manager to mark which are system managed vs not, etc. From bnocera at redhat.com Mon Dec 3 16:51:07 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 03 Dec 2007 16:51:07 +0000 Subject: Firefox 3 feature In-Reply-To: <1196694211.4398.5.camel@space-ghost.verbum.private> References: <1196624881.23681.6.camel@space-ghost.verbum.private> <1196694211.4398.5.camel@space-ghost.verbum.private> Message-ID: <1196700667.3227.219.camel@cookie.hadess.net> On Mon, 2007-12-03 at 10:03 -0500, Colin Walters wrote: > On Mon, 2007-12-03 at 13:24 +0100, Matej Cepl wrote: > > On Sun, 02 Dec 2007 14:48:01 -0500, Colin Walters scripst: > > > > > Hi, > > > > > > I tossed up a Feature page for Fx3: > > > > > > http://fedoraproject.org/wiki/Releases/FeatureFirefox3 > > > > > > I put my and Chris' name on it. Tentatively thinking of making a branch > > > in CVS where we could collaborate on it and do koji scratch builds from; > > > any opinions on that? > > > > That it is useless IMHO -- FF3 is very high on the Chris' and Martin's > > TODO list. > > Having the feature is useless? Or a branch? > > The reason I created it is because it isn't actually as trivial as just > changing everything to XulRunner and updating the Firefox package - we > do ship Firefox extensions (at least in Mugshot, perhaps elsewhere) and > plugins (e.g. Totem) that will require testing and possibly porting. > Actually I know Mugshot will need a bit of porting to pick up the new > cookie file format (http://bugzilla.mugshot.org/show_bug.cgi?id=1307). Plugins should "just work". They should work for both XulRunner-based apps and FF3 once compiled against XulRunner. Otherwise porting to XulRunner is a bit pointless... Totem in rawhide is already compiled against XulRunner. It's just the extensions that would have problems. From caillon at redhat.com Mon Dec 3 17:02:03 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 03 Dec 2007 18:02:03 +0100 Subject: Firefox 3 feature In-Reply-To: <47542A3A.1060801@leemhuis.info> References: <1196624881.23681.6.camel@space-ghost.verbum.private> <1196694211.4398.5.camel@space-ghost.verbum.private> <47542A3A.1060801@leemhuis.info> Message-ID: <4754368B.4040101@redhat.com> On 12/03/2007 05:09 PM, Thorsten Leemhuis wrote: > On 03.12.2007 16:03, Colin Walters wrote: >> The reason I created it is because it isn't actually as trivial as just >> changing everything to XulRunner and updating the Firefox package - we >> do ship Firefox extensions (at least in Mugshot, perhaps elsewhere) > > I don't think we ship any besides Mugshot -- and if I'm wrong on that > I'm sure they are very rare because we have no guidelines for packaging > them. Some packages with extensions were put up for review but they iirc > got stuck. > > Which brings me to my question: Does anyone know if Firefox 3 makes it > easier to package extensions (that was planed iirc)? Should we prepare > guidelines for packaging extensions? Once we get closer to having Firefox v3 (or rather a pre-release of it) in rawhide, I'll draft them. From fedora at leemhuis.info Mon Dec 3 17:53:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 03 Dec 2007 18:53:21 +0100 Subject: Firefox 3 feature In-Reply-To: <4754368B.4040101@redhat.com> References: <1196624881.23681.6.camel@space-ghost.verbum.private> <1196694211.4398.5.camel@space-ghost.verbum.private> <47542A3A.1060801@leemhuis.info> <4754368B.4040101@redhat.com> Message-ID: <47544291.2050504@leemhuis.info> On 03.12.2007 18:02, Christopher Aillon wrote: > On 12/03/2007 05:09 PM, Thorsten Leemhuis wrote: >> On 03.12.2007 16:03, Colin Walters wrote: >>> The reason I created it is because it isn't actually as trivial as just >>> changing everything to XulRunner and updating the Firefox package - we >>> do ship Firefox extensions (at least in Mugshot, perhaps elsewhere) >> I don't think we ship any besides Mugshot -- and if I'm wrong on that >> I'm sure they are very rare because we have no guidelines for packaging >> them. Some packages with extensions were put up for review but they iirc >> got stuck. >> Which brings me to my question: Does anyone know if Firefox 3 makes it >> easier to package extensions (that was planed iirc)? Should we prepare >> guidelines for packaging extensions? > Once we get closer to having Firefox v3 (or rather a pre-release of it) > in rawhide, I'll draft them. thx caillon! CU knurd From detonated at o2.pl Tue Dec 4 00:26:23 2007 From: detonated at o2.pl (=?UTF-8?Q?a3ukasz_Peb3szynski_?=) Date: Tue, 04 Dec 2007 01:26:23 +0100 Subject: fedora 9 kernel Message-ID: <3cbd2c69.62d92b10.47549eaf.8ae7c@o2.pl> Hi! I wonder why fedora kernel's stack is 4 kb. 8kb stack works as good as 4kb and there's ability to install ndiswrapper straight from livna-repo. (atheros drivers crash on 4 kb stack) Maybe there should be 8kb stack in fedora 9 kernel ? Greetings Lukasz From ivanquirino1928 at gmail.com Tue Dec 4 00:31:28 2007 From: ivanquirino1928 at gmail.com (Ivan Quirino) Date: Mon, 3 Dec 2007 21:31:28 -0300 Subject: fedora 9 kernel In-Reply-To: <3cbd2c69.62d92b10.47549eaf.8ae7c@o2.pl> References: <3cbd2c69.62d92b10.47549eaf.8ae7c@o2.pl> Message-ID: this is not a question for the fedora usability project On Dec 3, 2007 9:26 PM, a3ukasz Peb3szynski wrote: > Hi! > > I wonder why fedora kernel's stack is 4 kb. > 8kb stack works as good as 4kb and there's ability to install ndiswrapper > straight from livna-repo. > (atheros drivers crash on 4 kb stack) > Maybe there should be 8kb stack in fedora 9 kernel ? > > Greetings > Lukasz > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrb at redhat.com Tue Dec 4 03:07:10 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Mon, 03 Dec 2007 22:07:10 -0500 Subject: Making the Live CD slicker Message-ID: <1196737630.4259.131.camel@localhost.localdomain> Hey, Having just taken a look at the live CD, here are a couple of specific changes that would make that experience better. - The initial gdm screen is a bit of a hack. The message that you can click on the Fedora feels ugly. If we must have the GDM screen for keyboard or language, we might want to go through firstboot or something. - While signing up for a wireless network, it gnome-keyring prompts me for a keyring password. - nautilus shows the Live CD on the desktop, and lets you try to eject/unmount it. - Just as a minor annoyance, not all the default applications are installed (dasher is missing) Any other suggestions? Thanks, -Jonathan From mclasen at redhat.com Tue Dec 4 03:34:48 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 03 Dec 2007 22:34:48 -0500 Subject: Making the Live CD slicker In-Reply-To: <1196737630.4259.131.camel@localhost.localdomain> References: <1196737630.4259.131.camel@localhost.localdomain> Message-ID: <1196739288.12429.37.camel@localhost.localdomain> On Mon, 2007-12-03 at 22:07 -0500, Jonathan Blandford wrote: > Hey, > > Having just taken a look at the live CD, here are a couple of specific > changes that would make that experience better. > > - The initial gdm screen is a bit of a hack. The message that you can > click on the Fedora feels ugly. If we must have the GDM screen for > keyboard or language, we might want to go through firstboot or > something. > > - While signing up for a wireless network, it gnome-keyring prompts me > for a keyring password. > > - nautilus shows the Live CD on the desktop, and lets you try to > eject/unmount it. > > - Just as a minor annoyance, not all the default applications are > installed (dasher is missing) > > Any other suggestions? > What you mentioned earlier (but forgot to add to this email, apparently): the live cd contains a number of system-config utilities that we would rather not see in the menus of a polished desktop spin, such as system-config-rootpassword. Most of them are dragged in by anaconda/firstboot. From bnocera at redhat.com Tue Dec 4 14:42:46 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 04 Dec 2007 14:42:46 +0000 Subject: Packaging work? Message-ID: <1196779366.3227.248.camel@cookie.hadess.net> Heya, I was wondering if anyone was interested in packaging up libepc for Fedora. This would allow me to enable the "Publish" plugin in Totem: http://taschenorakel.de/mathias/2007/12/03/totem-playlist-sharing/ libepc 0.3 has just been released: http://taschenorakel.de/mathias/2007/12/04/libepc-0-3-released/ Cheers From dcbw at redhat.com Tue Dec 4 14:51:19 2007 From: dcbw at redhat.com (Dan Williams) Date: Tue, 04 Dec 2007 09:51:19 -0500 Subject: fedora 9 kernel In-Reply-To: <3cbd2c69.62d92b10.47549eaf.8ae7c@o2.pl> References: <3cbd2c69.62d92b10.47549eaf.8ae7c@o2.pl> Message-ID: <1196779879.26155.12.camel@localhost.localdomain> On Tue, 2007-12-04 at 01:26 +0100, a3ukasz Peb3szynski wrote: > Hi! > > I wonder why fedora kernel's stack is 4 kb. > 8kb stack works as good as 4kb and there's ability to install ndiswrapper straight from livna-repo. > (atheros drivers crash on 4 kb stack) > Maybe there should be 8kb stack in fedora 9 kernel ? Better to redirect this question to fedora-devel. But the short answer is that 4k stacks are quite beneficial for many other reasons (see http://lwn.net/Articles/150580/ ). If you just need to use your Atheros card, there are open drivers that work with 4k stacks, like madwifi and ath5k. I'd suggest trying one of those out. Dan From davidz at redhat.com Tue Dec 4 15:12:23 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 04 Dec 2007 10:12:23 -0500 Subject: Making the Live CD slicker In-Reply-To: <1196737630.4259.131.camel@localhost.localdomain> References: <1196737630.4259.131.camel@localhost.localdomain> Message-ID: <1196781143.15715.12.camel@oneill.fubar.dk> On Mon, 2007-12-03 at 22:07 -0500, Jonathan Blandford wrote: > Hey, > > Having just taken a look at the live CD, here are a couple of specific > changes that would make that experience better. Great, this is exactly what we need. The Live CD is pretty slick but there's still a lot of low hanging fruit... > - The initial gdm screen is a bit of a hack. The message that you can > click on the Fedora feels ugly. If we must have the GDM screen for > keyboard or language, we might want to go through firstboot or > something. Euw, gods no. Please. I don't want to click many times on a task driven interface just to get started whenever I boot the live CD. Perhaps if you could qualify a bit more why the gdm screen "is a bit of a hack" it would be useful. Either way, gdm _needs_ this functionality (think shared computer with users having varying language preferences); punting this to Fedora specific tools is in my view a much greater hack. This is the old mantra: do the work upstream etc. etc. Another reason for gdm is if you ship a live image with both GNOME and KDE. Then you'd have several faces to click on. The alternative is to have language/keyboard selection in the boot loader (isolinux); to be honest I prefer that to firstboot any day of the week. As an added bonus it means that we would booth straight into the desktop without gdm. Still, I think gdm is a much much better solution. > - While signing up for a wireless network, it gnome-keyring prompts me > for a keyring password. This is a good point, maybe the live cd initscript should set a blank password for the fedora users keyring. Even better, perhaps the gnome-keyring bits can detect a blank password (probably harder since it would require to init the pam stack and check the conversation is empty). > - nautilus shows the Live CD on the desktop, and lets you try to > eject/unmount it. By design. The idea is that the Live CD itself can contain promo / information / foreign apps that is also visible when mounting it on foreign OS's (Windows, Macs). We just haven't used this feature (we should). Further, having the icon is a good indicator for people they're running a live OS. Maybe the eject/unmount should be greyed out; then again, you can't actually unmount/eject it; you are given an error message if you try. > - Just as a minor annoyance, not all the default applications are > installed (dasher is missing) > > Any other suggestions? Yes. Anaconda pulls in a lot of the system-config-* tools that are not very useful neither on the live cd nor on the installed system. There's also like three SELinux icons or something in the menus. All of them really needs to go on the desktop live cd. David From katzj at redhat.com Tue Dec 4 15:18:25 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Dec 2007 10:18:25 -0500 Subject: Making the Live CD slicker In-Reply-To: <1196737630.4259.131.camel@localhost.localdomain> References: <1196737630.4259.131.camel@localhost.localdomain> Message-ID: <1196781506.3300.70.camel@localhost.localdomain> On Mon, 2007-12-03 at 22:07 -0500, Jonathan Blandford wrote: > - The initial gdm screen is a bit of a hack. The message that you can > click on the Fedora feels ugly. If we must have the GDM screen for > keyboard or language, we might want to go through firstboot or > something. GDM also gives us the benefit of being able to enable a11y. I don't feel very strongly one way or the other, but davidz did at one point > - While signing up for a wireless network, it gnome-keyring prompts me > for a keyring password. Once we have an ability to make changes that you've made (especially including your home directory) persist by storing them to a USB stick or similar, this will make more sense to be able to do probably. But the dialog could use some love > - nautilus shows the Live CD on the desktop, and lets you try to > eject/unmount it. I thought this got fixed at one point in hal > - Just as a minor annoyance, not all the default applications are > installed (dasher is missing) dasher isn't a default app [katzj at aglarond comps]$ grep dasher comps-f8.xml.in dasher Jeremy From katzj at redhat.com Tue Dec 4 15:19:50 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Dec 2007 10:19:50 -0500 Subject: Making the Live CD slicker In-Reply-To: <1196739288.12429.37.camel@localhost.localdomain> References: <1196737630.4259.131.camel@localhost.localdomain> <1196739288.12429.37.camel@localhost.localdomain> Message-ID: <1196781590.3300.72.camel@localhost.localdomain> On Mon, 2007-12-03 at 22:34 -0500, Matthias Clasen wrote: > What you mentioned earlier (but forgot to add to this email, > apparently): the live cd contains a number of system-config utilities > that we would rather not see in the menus of a polished desktop spin, > such as system-config-rootpassword. Most of them are dragged in by > anaconda/firstboot. How do you propose that anaconda/firstboot have the functionality without having to bring their own copy of tools in? Jeremy From davidz at redhat.com Tue Dec 4 15:23:33 2007 From: davidz at redhat.com (David Zeuthen) Date: Tue, 04 Dec 2007 10:23:33 -0500 Subject: Making the Live CD slicker In-Reply-To: <1196781590.3300.72.camel@localhost.localdomain> References: <1196737630.4259.131.camel@localhost.localdomain> <1196739288.12429.37.camel@localhost.localdomain> <1196781590.3300.72.camel@localhost.localdomain> Message-ID: <1196781813.15715.17.camel@oneill.fubar.dk> On Tue, 2007-12-04 at 10:19 -0500, Jeremy Katz wrote: > On Mon, 2007-12-03 at 22:34 -0500, Matthias Clasen wrote: > > What you mentioned earlier (but forgot to add to this email, > > apparently): the live cd contains a number of system-config utilities > > that we would rather not see in the menus of a polished desktop spin, > > such as system-config-rootpassword. Most of them are dragged in by > > anaconda/firstboot. > > How do you propose that anaconda/firstboot have the functionality > without having to bring their own copy of tools in? By using conditional dependencies. E.g. anaconda itself shouldn't pull in system-config-keyboard on the live CD (the keyboard is assumed to already be configured through gdm). However, for non-live-cd anaconda use you probably want to pull it in and use it. That's fine. In a similar fashion, anaconda/firstboot shouldn't automatically pull in system-config-rootpassword. Because that's not needed for Live CD's that are configured to not have a root password at all (Ubuntu, Mac OS X style). Does it make more sense now? David From caillon at redhat.com Tue Dec 4 15:34:14 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 04 Dec 2007 16:34:14 +0100 Subject: fedora 9 kernel In-Reply-To: <1196779879.26155.12.camel@localhost.localdomain> References: <3cbd2c69.62d92b10.47549eaf.8ae7c@o2.pl> <1196779879.26155.12.camel@localhost.localdomain> Message-ID: <47557376.8030903@redhat.com> On 12/04/2007 03:51 PM, Dan Williams wrote: > On Tue, 2007-12-04 at 01:26 +0100, a3ukasz Peb3szynski wrote: >> Hi! >> >> I wonder why fedora kernel's stack is 4 kb. >> 8kb stack works as good as 4kb and there's ability to install ndiswrapper straight from livna-repo. >> (atheros drivers crash on 4 kb stack) >> Maybe there should be 8kb stack in fedora 9 kernel ? > > Better to redirect this question to fedora-devel. Or to http://www.redhat.com/mailman/listinfo/fedora-kernel-list From bpepple at fedoraproject.org Tue Dec 4 16:28:13 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 04 Dec 2007 11:28:13 -0500 Subject: Packaging work? In-Reply-To: <1196779366.3227.248.camel@cookie.hadess.net> References: <1196779366.3227.248.camel@cookie.hadess.net> Message-ID: <1196785693.4414.12.camel@nixon> On Tue, 2007-12-04 at 14:42 +0000, Bastien Nocera wrote: > I was wondering if anyone was interested in packaging up libepc for > Fedora. This would allow me to enable the "Publish" plugin in Totem: > http://taschenorakel.de/mathias/2007/12/03/totem-playlist-sharing/ I'll go ahead and package this up. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Tue Dec 4 19:27:39 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 04 Dec 2007 14:27:39 -0500 Subject: Packaging work? In-Reply-To: <1196779366.3227.248.camel@cookie.hadess.net> References: <1196779366.3227.248.camel@cookie.hadess.net> Message-ID: <1196796459.4414.14.camel@nixon> On Tue, 2007-12-04 at 14:42 +0000, Bastien Nocera wrote: > I was wondering if anyone was interested in packaging up libepc for > Fedora. This would allow me to enable the "Publish" plugin in Totem: > http://taschenorakel.de/mathias/2007/12/03/totem-playlist-sharing/ > > libepc 0.3 has just been released: > http://taschenorakel.de/mathias/2007/12/04/libepc-0-3-released/ Ok, got it packaged and ready for review. If anyone is interested in reviewing it, you can find it here: https://bugzilla.redhat.com/show_bug.cgi?id=410901 Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jrb at redhat.com Wed Dec 5 04:25:10 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Tue, 04 Dec 2007 23:25:10 -0500 Subject: Making the Live CD slicker In-Reply-To: <1196781143.15715.12.camel@oneill.fubar.dk> References: <1196737630.4259.131.camel@localhost.localdomain> <1196781143.15715.12.camel@oneill.fubar.dk> Message-ID: <1196828710.4259.190.camel@localhost.localdomain> On Tue, 2007-12-04 at 10:12 -0500, David Zeuthen wrote: > > - The initial gdm screen is a bit of a hack. The message that you can > > click on the Fedora feels ugly. If we must have the GDM screen for > > keyboard or language, we might want to go through firstboot or > > something. > > Euw, gods no. Please. I don't want to click many times on a task driven > interface just to get started whenever I boot the live CD. Perhaps if > you could qualify a bit more why the gdm screen "is a bit of a hack" it > would be useful. Surely we can get it to once per task, no? Anyway, the current gdm screen does feel like a hack to me. I think it's the "click on the fedora icon to log in" aspect. It would be nice to see a screen that's dedicated to the Live CD here. > Either way, gdm _needs_ this functionality (think shared computer with > users having varying language preferences); punting this to Fedora > specific tools is in my view a much greater hack. This is the old > mantra: do the work upstream etc. etc. My fault. I was jumping ahead in my head to the brave new world of gdm where firstboot and gdm are integrated, and language/accessibility are part of the environment. I'm basically proposing an extra mode to GDM just for that. > Another reason for gdm is if you ship a live image with both GNOME and > KDE. Then you'd have several faces to click on. Hrm. Is that enough in the cards that we should design for it? > > - While signing up for a wireless network, it gnome-keyring prompts me > > for a keyring password. > > This is a good point, maybe the live cd initscript should set a blank > password for the fedora users keyring. Even better, perhaps the > gnome-keyring bits can detect a blank password (probably harder since it > would require to init the pam stack and check the conversation is > empty). Yeah. You're bound to trigger that dialog one way or another during the session. > > - nautilus shows the Live CD on the desktop, and lets you try to > > eject/unmount it. > > By design. The idea is that the Live CD itself can contain promo / > information / foreign apps that is also visible when mounting it on > foreign OS's (Windows, Macs). We just haven't used this feature (we > should). Can't we just have the promo appear as part of the image? Also, isn't the user name on the f-u-s applet 'Fedora Live'? As implemented right now, the CD is strange. > Further, having the icon is a good indicator for people they're running > a live OS. Maybe the eject/unmount should be greyed out; then again, you > can't actually unmount/eject it; you are given an error message if you > try. I would vote to make it insensitive at a minimum. > Yes. Anaconda pulls in a lot of the system-config-* tools that are not > very useful neither on the live cd nor on the installed system. There's > also like three SELinux icons or something in the menus. All of them > really needs to go on the desktop live cd. Agree, though I think you mean go _from_ the live CD. (-; Thanks, -Jonathan From jrb at redhat.com Wed Dec 5 04:25:14 2007 From: jrb at redhat.com (Jonathan Blandford) Date: Tue, 04 Dec 2007 23:25:14 -0500 Subject: Making the Live CD slicker In-Reply-To: <1196781506.3300.70.camel@localhost.localdomain> References: <1196737630.4259.131.camel@localhost.localdomain> <1196781506.3300.70.camel@localhost.localdomain> Message-ID: <1196828714.4259.192.camel@localhost.localdomain> On Tue, 2007-12-04 at 10:18 -0500, Jeremy Katz wrote: > On Mon, 2007-12-03 at 22:07 -0500, Jonathan Blandford wrote: > > - The initial gdm screen is a bit of a hack. The message that you can > > click on the Fedora feels ugly. If we must have the GDM screen for > > keyboard or language, we might want to go through firstboot or > > something. > > GDM also gives us the benefit of being able to enable a11y. I don't > feel very strongly one way or the other, but davidz did at one point [ Commented in the other post ] > > - While signing up for a wireless network, it gnome-keyring prompts me > > for a keyring password. > > Once we have an ability to make changes that you've made (especially > including your home directory) persist by storing them to a USB stick or > similar, this will make more sense to be able to do probably. But the > dialog could use some love Oh, interesting. Are we going to password enable those USB sticks at all? > > - Just as a minor annoyance, not all the default applications are > > installed (dasher is missing) > > dasher isn't a default app > [katzj at aglarond comps]$ grep dasher comps-f8.xml.in > dasher It's selected as the default mobility device in the Preferred applications dialog. As I said, minor annoyance. Thanks, -Jonathan From katzj at redhat.com Wed Dec 5 04:53:53 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Dec 2007 23:53:53 -0500 Subject: Making the Live CD slicker In-Reply-To: <1196828714.4259.192.camel@localhost.localdomain> References: <1196737630.4259.131.camel@localhost.localdomain> <1196781506.3300.70.camel@localhost.localdomain> <1196828714.4259.192.camel@localhost.localdomain> Message-ID: <1196830433.7206.19.camel@localhost.localdomain> On Tue, 2007-12-04 at 23:25 -0500, Jonathan Blandford wrote: > On Tue, 2007-12-04 at 10:18 -0500, Jeremy Katz wrote: > > On Mon, 2007-12-03 at 22:07 -0500, Jonathan Blandford wrote: > > > - While signing up for a wireless network, it gnome-keyring prompts me > > > for a keyring password. > > > > Once we have an ability to make changes that you've made (especially > > including your home directory) persist by storing them to a USB stick or > > similar, this will make more sense to be able to do probably. But the > > dialog could use some love > > Oh, interesting. Are we going to password enable those USB sticks at > all? It's definitely something that should be an option. Exactly how persistence is going to work is still a bit hand-wavy, unfortunately as all the options kind of suck :-/ > > > - Just as a minor annoyance, not all the default applications are > > > installed (dasher is missing) > > > > dasher isn't a default app > > [katzj at aglarond comps]$ grep dasher comps-f8.xml.in > > dasher > > It's selected as the default mobility device in the Preferred > applications dialog. As I said, minor annoyance. Then we should install it by default! :-) Committed the appropriate comps change Jeremy From mcepl at redhat.com Thu Dec 6 13:49:37 2007 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 06 Dec 2007 14:49:37 +0100 Subject: fedora 9 kernel References: <3cbd2c69.62d92b10.47549eaf.8ae7c@o2.pl> Message-ID: On Tue, 04 Dec 2007 01:26:23 +0100, Lukasz Peb3szynski scripst: > I wonder why fedora kernel's stack is 4 kb. 8kb stack works as good as > 4kb and there's ability to install ndiswrapper straight from livna-repo. > (atheros drivers crash on 4 kb stack) Maybe there should be 8kb stack in > fedora 9 kernel ? Most likely not -- I was asking this couple of times and after wonderful enlighting discussion with Jakub Jelinek about this, it was pretty clear to me a) it will never happen, b) most of the problems ndiswrapper/ madwifi/et al. have should be solvable even with 4k stack. Just somebody needs to know how (and I am certainly not the one, in case you would like to ask me). Mat?j -- The content of this message is licensed under a Creative Commons Attribution 3.0 License, Some Rights Reserved. http://creativecommons.org/licenses/by/3.0/us/ From bnocera at redhat.com Thu Dec 6 19:46:11 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 06 Dec 2007 19:46:11 +0000 Subject: More packaging work Message-ID: <1196970371.26210.41.camel@cookie.hadess.net> Heya, I've just filed a review request for totem-pl-parser, which is necessary for the new devel Totem: https://bugzilla.redhat.com/show_bug.cgi?id=414721 Anybody fancy reviewing this small library? Cheers From bpepple at fedoraproject.org Thu Dec 6 19:51:35 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 06 Dec 2007 14:51:35 -0500 Subject: More packaging work In-Reply-To: <1196970371.26210.41.camel@cookie.hadess.net> References: <1196970371.26210.41.camel@cookie.hadess.net> Message-ID: <1196970695.19462.0.camel@nixon> On Thu, 2007-12-06 at 19:46 +0000, Bastien Nocera wrote: > I've just filed a review request for totem-pl-parser, which is necessary > for the new devel Totem: > https://bugzilla.redhat.com/show_bug.cgi?id=414721 > > Anybody fancy reviewing this small library? I should have some time later tonight to work on it, if no one gets to it before then. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Thu Dec 6 20:10:16 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 06 Dec 2007 20:10:16 +0000 Subject: More packaging work In-Reply-To: <1196970695.19462.0.camel@nixon> References: <1196970371.26210.41.camel@cookie.hadess.net> <1196970695.19462.0.camel@nixon> Message-ID: <1196971816.26210.45.camel@cookie.hadess.net> On Thu, 2007-12-06 at 14:51 -0500, Brian Pepple wrote: > On Thu, 2007-12-06 at 19:46 +0000, Bastien Nocera wrote: > > I've just filed a review request for totem-pl-parser, which is necessary > > for the new devel Totem: > > https://bugzilla.redhat.com/show_bug.cgi?id=414721 > > > > Anybody fancy reviewing this small library? > > I should have some time later tonight to work on it, if no one gets to > it before then. You're a star From rstrode at redhat.com Thu Dec 6 22:35:34 2007 From: rstrode at redhat.com (Ray Strode) Date: Thu, 6 Dec 2007 17:35:34 -0500 Subject: More packaging work In-Reply-To: <1196970371.26210.41.camel@cookie.hadess.net> References: <1196970371.26210.41.camel@cookie.hadess.net> Message-ID: <20071206173534.66b9190d@halfline-d630.boston.devel.redhat.com> Hi, > I've just filed a review request for totem-pl-parser, which is > necessary for the new devel Totem: > https://bugzilla.redhat.com/show_bug.cgi?id=414721 > > Anybody fancy reviewing this small library? I bet you could do swapsies with Matthias (we has a pending libbeagle request, I believe) -Ray From mclasen at redhat.com Thu Dec 6 22:50:23 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 06 Dec 2007 17:50:23 -0500 Subject: More packaging work In-Reply-To: <20071206173534.66b9190d@halfline-d630.boston.devel.redhat.com> References: <1196970371.26210.41.camel@cookie.hadess.net> <20071206173534.66b9190d@halfline-d630.boston.devel.redhat.com> Message-ID: <1196981423.3564.0.camel@localhost.localdomain> On Thu, 2007-12-06 at 17:35 -0500, Ray Strode wrote: > Hi, > > I've just filed a review request for totem-pl-parser, which is > > necessary for the new devel Totem: > > https://bugzilla.redhat.com/show_bug.cgi?id=414721 > > > > Anybody fancy reviewing this small library? > I bet you could do swapsies with Matthias (we has a pending libbeagle > request, I believe) That has been handled by ajax already. From caillon at redhat.com Fri Dec 7 13:34:03 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 07 Dec 2007 14:34:03 +0100 Subject: [Fwd: DBus Bindings for Javascript] Message-ID: <47594BCB.9090908@redhat.com> Figured I'd forward this over here, as it's pretty interesting stuff... -------------- next part -------------- An embedded message was scrubbed... From: Eric Butler Subject: DBus Bindings for Javascript Date: Mon, 03 Dec 2007 14:30:55 -0800 Size: 6024 URL: From skvidal at fedoraproject.org Fri Dec 7 13:45:05 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 07 Dec 2007 08:45:05 -0500 Subject: [Fwd: DBus Bindings for Javascript] In-Reply-To: <47594BCB.9090908@redhat.com> References: <47594BCB.9090908@redhat.com> Message-ID: <1197035105.26280.1.camel@cutter> On Fri, 2007-12-07 at 14:34 +0100, Christopher Aillon wrote: > Figured I'd forward this over here, as it's pretty interesting stuff... > > > email message attachment (DBus Bindings for Javascript.eml) > I've been working on writing DBUS bindings for Mozilla > Javscript. The goal of this project is to make it possible for > XUL and extension developers to integrate with the Linux > desktop. > If this ever gets into fedora it defaults to off and comes with giant flashing warnings when you turn it on. The last thing I want is some arbitrary javascript being able to escape the browser and send messages to the rest of my system. -sv From caillon at redhat.com Fri Dec 7 13:51:56 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 07 Dec 2007 14:51:56 +0100 Subject: [Fwd: DBus Bindings for Javascript] In-Reply-To: <1197035105.26280.1.camel@cutter> References: <47594BCB.9090908@redhat.com> <1197035105.26280.1.camel@cutter> Message-ID: <47594FFC.6070009@redhat.com> On 12/07/2007 02:45 PM, seth vidal wrote: > On Fri, 2007-12-07 at 14:34 +0100, Christopher Aillon wrote: >> Figured I'd forward this over here, as it's pretty interesting stuff... >> >> >> email message attachment (DBus Bindings for Javascript.eml) > > >> I've been working on writing DBUS bindings for Mozilla >> Javscript. The goal of this project is to make it possible for >> XUL and extension developers to integrate with the Linux >> desktop. >> > > If this ever gets into fedora it defaults to off and comes with giant > flashing warnings when you turn it on. The last thing I want is some > arbitrary javascript being able to escape the browser and send messages > to the rest of my system. This is for the JavaScript that runs as part of the browser, or in installed extensions. With system (local user) privileges. It already has full power to do whatever you can, including manually invoking dbus-send, or emailing your password information to bad guys. Of course, nobody would install an extension that would do these evil things, right? From skvidal at fedoraproject.org Fri Dec 7 14:15:53 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 07 Dec 2007 09:15:53 -0500 Subject: [Fwd: DBus Bindings for Javascript] In-Reply-To: <47594FFC.6070009@redhat.com> References: <47594BCB.9090908@redhat.com> <1197035105.26280.1.camel@cutter> <47594FFC.6070009@redhat.com> Message-ID: <1197036953.26280.3.camel@cutter> On Fri, 2007-12-07 at 14:51 +0100, Christopher Aillon wrote: > On 12/07/2007 02:45 PM, seth vidal wrote: > > On Fri, 2007-12-07 at 14:34 +0100, Christopher Aillon wrote: > >> Figured I'd forward this over here, as it's pretty interesting stuff... > >> > >> > >> email message attachment (DBus Bindings for Javascript.eml) > > > > > >> I've been working on writing DBUS bindings for Mozilla > >> Javscript. The goal of this project is to make it possible for > >> XUL and extension developers to integrate with the Linux > >> desktop. > >> > > > > If this ever gets into fedora it defaults to off and comes with giant > > flashing warnings when you turn it on. The last thing I want is some > > arbitrary javascript being able to escape the browser and send messages > > to the rest of my system. > > > This is for the JavaScript that runs as part of the browser, or in > installed extensions. With system (local user) privileges. It already > has full power to do whatever you can, including manually invoking > dbus-send, or emailing your password information to bad guys. Of > course, nobody would install an extension that would do these evil > things, right? I knew there was a reason I turn javascript off in most cases. :) -sv From walters at redhat.com Fri Dec 7 17:27:08 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 07 Dec 2007 12:27:08 -0500 Subject: [Fwd: DBus Bindings for Javascript] In-Reply-To: <1197036953.26280.3.camel@cutter> References: <47594BCB.9090908@redhat.com> <1197035105.26280.1.camel@cutter> <47594FFC.6070009@redhat.com> <1197036953.26280.3.camel@cutter> Message-ID: <1197048428.5229.3.camel@space-ghost.verbum.private> On Fri, 2007-12-07 at 09:15 -0500, seth vidal wrote: > I knew there was a reason I turn javascript off in most cases. :) Turning off JavaScript for the web has no effect on chrome level code - if it did, the whole browser would stop working. But yeah, bottom line is this has no security impact, it's just a nicer API for extensions and for Firefox itself to integrate better. From johnp at redhat.com Fri Dec 7 20:59:54 2007 From: johnp at redhat.com (John (J5) Palmieri) Date: Fri, 07 Dec 2007 15:59:54 -0500 Subject: [Fwd: DBus Bindings for Javascript] In-Reply-To: <1197048428.5229.3.camel@space-ghost.verbum.private> References: <47594BCB.9090908@redhat.com> <1197035105.26280.1.camel@cutter> <47594FFC.6070009@redhat.com> <1197036953.26280.3.camel@cutter> <1197048428.5229.3.camel@space-ghost.verbum.private> Message-ID: <1197061194.17336.5.camel@localhost.localdomain> On Fri, 2007-12-07 at 12:27 -0500, Colin Walters wrote: > On Fri, 2007-12-07 at 09:15 -0500, seth vidal wrote: > > > I knew there was a reason I turn javascript off in most cases. :) > > Turning off JavaScript for the web has no effect on chrome level code - > if it did, the whole browser would stop working. > > But yeah, bottom line is this has no security impact, it's just a nicer > API for extensions and for Firefox itself to integrate better. I'm all for it. Ya local code will always have dangers involved but that is not something D-Bus adds... I hope it is hard for local javascript modules to be exported to the external javascript side. I would hate if someone accidentally linked them up and some script kiddy could thrash my computer by sending play-sound A:\haxzored.wav. Oh wait that's AOL not Mozilla. -- John (J5) Palmieri From detonated at o2.pl Sat Dec 15 14:25:07 2007 From: detonated at o2.pl (=?UTF-8?Q?a3ukasz_Peb3szynski?=) Date: Sat, 15 Dec 2007 15:25:07 +0100 Subject: hot to participate in testing Message-ID: <38c58061.64d39862.4763e3c3.3db20@o2.pl> Hi, I marked testing repository in pirut and how should I report possible bugs? Is there any fedora-tool to do such a thing ? Greetings From mark.bidewell at alumni.clemson.edu Sat Dec 15 22:42:01 2007 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Sat, 15 Dec 2007 14:42:01 -0800 Subject: KDE4 notes/problems Message-ID: I don't know if these are know problems, or if KDE4 is to the point of filing bugzillas but I noticed two things after updating to KDE4 ( rawhide today) 1) /bin/dbus-daemon has selinux issues. Running in enforcing mode yields "permission denied". permissive mode works fine. 2) after the splash screen, I get no desktop. Mark Bidewell -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmus at tmus.dk Sun Dec 16 01:26:12 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sat, 15 Dec 2007 22:26:12 -0300 Subject: automatic unlocking of keyring In-Reply-To: <1196440726.4562.6.camel@localhost.localdomain> References: <1196440726.4562.6.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > As some may remember, we turned automatic unlocking of > keyrings at login time off at a late time in the F8 schedule, > since it was not working properly with our pam configuration. > > pam has meanwhile gained a new feature that will hopefully > allow this to work reliably (substack). I have built > gdm-2.21.2-0.2007.11.20.4.fc9 and gnome-keyring-2.20.2-2.fc9 > in rawhide with this turned on. > > Please try it and tell me if it works for you. > > > Matthias > This is actually working for me on F8 using: gdm-2.20.2-2.fc8 and gnome-keyring-2.20.2-1.fc8 The only thing I think I changed was to move pam_gnome_keyring.so above the system-auth line in /etc/pam.d/gdm. If this is not supposed to work, what am I missing? I definitely unlocks the keyring for nm_applet, evolution and various server connections. /Thomas From sundaram at fedoraproject.org Sun Dec 16 09:16:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 16 Dec 2007 14:46:39 +0530 Subject: hot to participate in testing In-Reply-To: <38c58061.64d39862.4763e3c3.3db20@o2.pl> References: <38c58061.64d39862.4763e3c3.3db20@o2.pl> Message-ID: <4764ECF7.5000602@fedoraproject.org> a3ukasz Peb3szynski wrote: > Hi, I marked testing repository in pirut and how should I report possible bugs? > Is there any fedora-tool to do such a thing ? There is no Fedora specific tool to do this. There are tools like Bug Buddy in GNOME which helps report bugs to upstream bugzilla but for Fedora issues you can just go to http://bugzilla.redhat.com and report the problems. Alternatively Bodhi, the Fedora updates system allows anonymous comments on updates in testing repository too https://admin.fedoraproject.org/updates. More information at http://fedoraproject.org/wiki/Testing. Refer From sundaram at fedoraproject.org Sun Dec 16 09:18:52 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 16 Dec 2007 14:48:52 +0530 Subject: KDE4 notes/problems In-Reply-To: References: Message-ID: <4764ED7C.8060608@fedoraproject.org> Mark Bidewell wrote: > I don't know if these are know problems, or if KDE4 is to the point of > filing bugzillas but I noticed two things after updating to KDE4 ( > rawhide today) > > 1) /bin/dbus-daemon has selinux issues. Running in enforcing mode > yields "permission denied". permissive mode works fine. > 2) after the splash screen, I get no desktop. Fedora-test list would be more appropriate for discussing issues in rawhide/updates testing repository. Report problems to bugzilla. For the SELinux issue, the avc denied messages from /var/log/audit (if you have audit daemon enabled) or /var/log/messages would be helpful. Rahul From mclasen at redhat.com Mon Dec 17 04:52:05 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 16 Dec 2007 23:52:05 -0500 Subject: What should the desktop spin for F9 look like ? Message-ID: <1197867125.2962.31.camel@localhost.localdomain> Jonathan tried to kick off this discussion earlier, with some success. I think we should revive the desktop SIG and start to work out some concrete goals for what we want to improve in the desktop spin for F9. Here are some things that we might want to discuss: - menus + switch from "generic name" style to "name - generic name" ? + "too much" - what to get rid of in the menus, and how - login screen + can we make the special live-cd situation more intuitive ? - bootup + should we look at the nm dispatcher work by jon nettleton ? - content + people have proposed to add some free content to the cd - anything else people want to see improved Matthias From ivanquirino1928 at gmail.com Mon Dec 17 08:40:54 2007 From: ivanquirino1928 at gmail.com (Ivan Quirino) Date: Mon, 17 Dec 2007 05:40:54 -0300 Subject: What should the desktop spin for F9 look like ? In-Reply-To: <1197867125.2962.31.camel@localhost.localdomain> References: <1197867125.2962.31.camel@localhost.localdomain> Message-ID: It's really needed to improve the liveCD. Remove some services, like sshd and httpd, these things just take space in the liveCD. Put OpenOffice.orgint the CD is a great deal. There should be no login screen in the liveCD. Some content would be nice too. Make the fedora liveCD like the ubuntu liveCD is not a bad idea. Ubuntu doesnt have server services, has openoffice.org, and auto-login in the liveCD. And Anaconda should ask if you want to restart or continue with the liveCD On Dec 17, 2007 1:52 AM, Matthias Clasen wrote: > Jonathan tried to kick off this discussion earlier, with some success. > I think we should revive the desktop SIG and start to work out some > concrete goals for what we want to improve in the desktop spin for F9. > > > Here are some things that we might want to discuss: > > - menus > + switch from "generic name" style to "name - generic name" ? > + "too much" - what to get rid of in the menus, and how > > - login screen > + can we make the special live-cd situation more intuitive ? > > - bootup > + should we look at the nm dispatcher work by jon nettleton ? > > - content > + people have proposed to add some free content to the cd > > - anything else people want to see improved > > > Matthias > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexl at redhat.com Mon Dec 17 10:49:43 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 17 Dec 2007 11:49:43 +0100 Subject: automatic unlocking of keyring In-Reply-To: References: <1196440726.4562.6.camel@localhost.localdomain> Message-ID: <1197888583.20190.11.camel@dhcp-208-188.arn.redhat.com> On Sat, 2007-12-15 at 22:26 -0300, Thomas M Steenholdt wrote: > Matthias Clasen wrote: > > As some may remember, we turned automatic unlocking of > > keyrings at login time off at a late time in the F8 schedule, > > since it was not working properly with our pam configuration. > > > > pam has meanwhile gained a new feature that will hopefully > > allow this to work reliably (substack). I have built > > gdm-2.21.2-0.2007.11.20.4.fc9 and gnome-keyring-2.20.2-2.fc9 > > in rawhide with this turned on. > > > > Please try it and tell me if it works for you. > > > > > > Matthias > > > > This is actually working for me on F8 using: > > gdm-2.20.2-2.fc8 and gnome-keyring-2.20.2-1.fc8 > > The only thing I think I changed was to move pam_gnome_keyring.so above > the system-auth line in /etc/pam.d/gdm. > > If this is not supposed to work, what am I missing? I definitely unlocks > the keyring for nm_applet, evolution and various server connections. That "works", but is not ideal, as it means the keyring pam daemon will ask for the password instead of using the cached result from the system-auth result. This is clearly a problem if you mistype you password... The solution is to fix the system-auth so that it runs and then runs the pam modules after it. This is fixed in rawhide with the pam-stacks supports i believe. From mark.bidewell at alumni.clemson.edu Mon Dec 17 15:01:09 2007 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Mon, 17 Dec 2007 10:01:09 -0500 Subject: What should the desktop spin for F9 look like ? In-Reply-To: References: <1197867125.2962.31.camel@localhost.localdomain> Message-ID: httpd I can agree with, but I think sshd should stay. Sometimes getting remote access through a LiveCD is useful. Mark Bidewell On 12/17/07, Ivan Quirino wrote: > > It's really needed to improve the liveCD. Remove some services, like sshd > and httpd, these things just take space in the liveCD. Put OpenOffice.orgint the CD is a great deal. There should be no login screen in the liveCD. > Some content would be nice too. Make the fedora liveCD like the ubuntu > liveCD is not a bad idea. Ubuntu doesnt have server services, has > openoffice.org, and auto-login in the liveCD. And Anaconda should ask if > you want to restart or continue with the liveCD > > On Dec 17, 2007 1:52 AM, Matthias Clasen < mclasen at redhat.com> wrote: > > > Jonathan tried to kick off this discussion earlier, with some success. > > I think we should revive the desktop SIG and start to work out some > > concrete goals for what we want to improve in the desktop spin for F9. > > > > > > Here are some things that we might want to discuss: > > > > - menus > > + switch from "generic name" style to "name - generic name" ? > > + "too much" - what to get rid of in the menus, and how > > > > - login screen > > + can we make the special live-cd situation more intuitive ? > > > > - bootup > > + should we look at the nm dispatcher work by jon nettleton ? > > > > - content > > + people have proposed to add some free content to the cd > > > > - anything else people want to see improved > > > > > > Matthias > > > > -- > > Fedora-desktop-list mailing list > > Fedora-desktop-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > > > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanquirino1928 at gmail.com Mon Dec 17 15:06:43 2007 From: ivanquirino1928 at gmail.com (Ivan Quirino) Date: Mon, 17 Dec 2007 12:06:43 -0300 Subject: What should the desktop spin for F9 look like ? In-Reply-To: References: <1197867125.2962.31.camel@localhost.localdomain> Message-ID: but sshd is the daemon, the server. what should stay is the client. the liveCD should be the 'client' spin. On Dec 17, 2007 12:01 PM, Mark Bidewell wrote: > httpd I can agree with, but I think sshd should stay. Sometimes getting > remote access through a LiveCD is useful. > > Mark Bidewell > > > On 12/17/07, Ivan Quirino wrote: > > > > It's really needed to improve the liveCD. Remove some services, like > > sshd and httpd, these things just take space in the liveCD. Put > > OpenOffice.org int the CD is a great deal. There should be no login > > screen in the liveCD. Some content would be nice too. Make the fedora liveCD > > like the ubuntu liveCD is not a bad idea. Ubuntu doesnt have server > > services, has openoffice.org, and auto-login in the liveCD. And Anaconda > > should ask if you want to restart or continue with the liveCD > > > > On Dec 17, 2007 1:52 AM, Matthias Clasen < mclasen at redhat.com> wrote: > > > > > Jonathan tried to kick off this discussion earlier, with some success. > > > > > > I think we should revive the desktop SIG and start to work out some > > > concrete goals for what we want to improve in the desktop spin for F9. > > > > > > > > > Here are some things that we might want to discuss: > > > > > > - menus > > > + switch from "generic name" style to "name - generic name" ? > > > + "too much" - what to get rid of in the menus, and how > > > > > > - login screen > > > + can we make the special live-cd situation more intuitive ? > > > > > > - bootup > > > + should we look at the nm dispatcher work by jon nettleton ? > > > > > > - content > > > + people have proposed to add some free content to the cd > > > > > > - anything else people want to see improved > > > > > > > > > Matthias > > > > > > -- > > > Fedora-desktop-list mailing list > > > Fedora-desktop-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > > > > > > > > > -- > > Fedora-desktop-list mailing list > > Fedora-desktop-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > > > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.nettleton at gmail.com Mon Dec 17 19:08:56 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Mon, 17 Dec 2007 20:08:56 +0100 Subject: What should the desktop spin for F9 look like ? In-Reply-To: References: <1197867125.2962.31.camel@localhost.localdomain> Message-ID: <1197918536.2070.26.camel@averatec> On Mon, 2007-12-17 at 12:06 -0300, Ivan Quirino wrote: > but sshd is the daemon, the server. what should stay is the client. > the liveCD should be the 'client' spin. Both should stay. Ssh/sftp setup with Avahi makes a nice secure way to point and click transfer files around a network. That does remind me that would should make sure to have nss-mdns setup and running properly, as well as proper firewall rules. I don't have my list handy right now, but if things are going to get rolling I will get it all together. Jon > > On Dec 17, 2007 12:01 PM, Mark Bidewelli > wrote: > httpd I can agree with, but I think sshd should stay. > Sometimes getting remote access through a LiveCD is useful. > > Mark Bidewell > > > > On 12/17/07, Ivan Quirino wrote: > It's really needed to improve the liveCD. Remove some > services, like sshd and httpd, these things just take > space in the liveCD. Put OpenOffice.org int the CD is > a great deal. There should be no login screen in the > liveCD. Some content would be nice too. Make the > fedora liveCD like the ubuntu liveCD is not a bad > idea. Ubuntu doesnt have server services, has > openoffice.org, and auto-login in the liveCD. And > Anaconda should ask if you want to restart or continue > with the liveCD > > > On Dec 17, 2007 1:52 AM, Matthias Clasen < > mclasen at redhat.com> wrote: > Jonathan tried to kick off this discussion > earlier, with some success. > I think we should revive the desktop SIG and > start to work out some > concrete goals for what we want to improve in > the desktop spin for F9. > > > Here are some things that we might want to > discuss: > > - menus > + switch from "generic name" style to "name - > generic name" ? > + "too much" - what to get rid of in the > menus, and how > > - login screen > + can we make the special live-cd situation > more intuitive ? > > - bootup > + should we look at the nm dispatcher work by > jon nettleton ? > > - content > + people have proposed to add some free > content to the cd > > - anything else people want to see improved > > > Matthias > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list From tmus at tmus.dk Mon Dec 17 20:03:35 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 17 Dec 2007 17:03:35 -0300 Subject: automatic unlocking of keyring In-Reply-To: <1197888583.20190.11.camel@dhcp-208-188.arn.redhat.com> References: <1196440726.4562.6.camel@localhost.localdomain> <1197888583.20190.11.camel@dhcp-208-188.arn.redhat.com> Message-ID: Alexander Larsson wrote: > > That "works", but is not ideal, as it means the keyring pam daemon will > ask for the password instead of using the cached result from the > system-auth result. This is clearly a problem if you mistype you > password... > > The solution is to fix the system-auth so that it runs and then runs the > pam modules after it. This is fixed in rawhide with the pam-stacks > supports i believe. > Hi I'm only asked to enter the password once (on login by gdm). Even if I typed the password incorrectly, that wouldn't mean problems, since I wouldn't be logged in in the first place, so how could it be causing problems. Once I enter my password correctly, it caches the correct password and uses that to unlock the keyring. Although I agree that fixing system-auth is the right thing to do anyways (because it makes local mods so much easier), this actually appear to be working fine just the same. Perhaps I misunderstand you, please enlighten me if you feel that I do. Thanks. /Thomas From ivanquirino1928 at gmail.com Mon Dec 17 21:05:32 2007 From: ivanquirino1928 at gmail.com (Ivan Quirino) Date: Mon, 17 Dec 2007 18:05:32 -0300 Subject: What should the desktop spin for F9 look like ? In-Reply-To: <1197918536.2070.26.camel@averatec> References: <1197867125.2962.31.camel@localhost.localdomain> <1197918536.2070.26.camel@averatec> Message-ID: the clients should stay, but the servers should be off the liveCD. We can have more space for other user aplications On Dec 17, 2007 4:08 PM, Jon Nettleton wrote: > On Mon, 2007-12-17 at 12:06 -0300, Ivan Quirino wrote: > > but sshd is the daemon, the server. what should stay is the client. > > the liveCD should be the 'client' spin. > > Both should stay. Ssh/sftp setup with Avahi makes a nice secure way to > point and click transfer files around a network. > > That does remind me that would should make sure to have nss-mdns setup > and running properly, as well as proper firewall rules. > > I don't have my list handy right now, but if things are going to get > rolling I will get it all together. > > Jon > > > > > On Dec 17, 2007 12:01 PM, Mark Bidewelli > > wrote: > > httpd I can agree with, but I think sshd should stay. > > Sometimes getting remote access through a LiveCD is useful. > > > > Mark Bidewell > > > > > > > > On 12/17/07, Ivan Quirino wrote: > > It's really needed to improve the liveCD. Remove some > > services, like sshd and httpd, these things just take > > space in the liveCD. Put OpenOffice.org int the CD is > > a great deal. There should be no login screen in the > > liveCD. Some content would be nice too. Make the > > fedora liveCD like the ubuntu liveCD is not a bad > > idea. Ubuntu doesnt have server services, has > > openoffice.org, and auto-login in the liveCD. And > > Anaconda should ask if you want to restart or continue > > with the liveCD > > > > > > On Dec 17, 2007 1:52 AM, Matthias Clasen < > > mclasen at redhat.com> wrote: > > Jonathan tried to kick off this discussion > > earlier, with some success. > > I think we should revive the desktop SIG and > > start to work out some > > concrete goals for what we want to improve in > > the desktop spin for F9. > > > > > > Here are some things that we might want to > > discuss: > > > > - menus > > + switch from "generic name" style to "name - > > generic name" ? > > + "too much" - what to get rid of in the > > menus, and how > > > > - login screen > > + can we make the special live-cd situation > > more intuitive ? > > > > - bootup > > + should we look at the nm dispatcher work by > > jon nettleton ? > > > > - content > > + people have proposed to add some free > > content to the cd > > > > - anything else people want to see improved > > > > > > Matthias > > > > -- > > Fedora-desktop-list mailing list > > Fedora-desktop-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > > > > > > > > -- > > Fedora-desktop-list mailing list > > Fedora-desktop-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > > > > > > > > -- > > Fedora-desktop-list mailing list > > Fedora-desktop-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > > > > -- > > Fedora-desktop-list mailing list > > Fedora-desktop-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mclasen at redhat.com Mon Dec 17 21:31:19 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 17 Dec 2007 16:31:19 -0500 Subject: What should the desktop spin for F9 look like ? In-Reply-To: <1197918536.2070.26.camel@averatec> References: <1197867125.2962.31.camel@localhost.localdomain> <1197918536.2070.26.camel@averatec> Message-ID: <1197927079.2924.11.camel@localhost.localdomain> On Mon, 2007-12-17 at 20:08 +0100, Jon Nettleton wrote: > > That does remind me that would should make sure to have nss-mdns setup > and running properly, as well as proper firewall rules. > Yes. Lennart told me that he knows what he needs to do now to make nss-mdns generally acceptable, after talking to Uli at foss.in. From alexl at redhat.com Wed Dec 19 08:49:01 2007 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 19 Dec 2007 09:49:01 +0100 Subject: automatic unlocking of keyring In-Reply-To: References: <1196440726.4562.6.camel@localhost.localdomain> <1197888583.20190.11.camel@dhcp-208-188.arn.redhat.com> Message-ID: <1198054141.28149.23.camel@dhcp-208-188.arn.redhat.com> On Mon, 2007-12-17 at 17:03 -0300, Thomas M Steenholdt wrote: > Alexander Larsson wrote: > > > > That "works", but is not ideal, as it means the keyring pam daemon will > > ask for the password instead of using the cached result from the > > system-auth result. This is clearly a problem if you mistype you > > password... > > > > The solution is to fix the system-auth so that it runs and then runs the > > pam modules after it. This is fixed in rawhide with the pam-stacks > > supports i believe. > > > > Hi > > I'm only asked to enter the password once (on login by gdm). Even if I > typed the password incorrectly, that wouldn't mean problems, since I > wouldn't be logged in in the first place, so how could it be causing > problems. Once I enter my password correctly, it caches the correct > password and uses that to unlock the keyring. The problem is not that you need to enter the password multiple times, that password is saved and reused for later pam modules. In fact this is how pam-keyring is meant to work, system-auth asks for the password, its saved and then pam-keyring reads this and uses it to try to unlock the keyring. However, if pam-keyring is run first then it is the one asking for the password instead of system-auth, and system-auth is the part using the saved password. This is a problem, because pam-keyring can't do things like verifying the password you entered is correct, or ask again if it is not. I'm not sure what the exact result will be in this case, but its not ideal. From mclasen at redhat.com Wed Dec 19 15:22:03 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 19 Dec 2007 10:22:03 -0500 Subject: metacity compositor in rawhide Message-ID: <1198077723.2809.10.camel@localhost.localdomain> Just thought I should mention that todays metacity build, 2.21.5-1.fc9, includes a new compositor. It is xrender-based (derived from xcompmgr) and thus works on systems where compiz doesn't. It certainly still has kinks, therefor it is not turned on by default yet. To play around with it, set the gconf key: /apps/metacity/general/compositing_manager Matthias From jon.nettleton at gmail.com Wed Dec 19 17:15:21 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 19 Dec 2007 18:15:21 +0100 Subject: metacity compositor in rawhide In-Reply-To: <1198077723.2809.10.camel@localhost.localdomain> References: <1198077723.2809.10.camel@localhost.localdomain> Message-ID: <1198084521.4070.29.camel@averatec> On Wed, 2007-12-19 at 10:22 -0500, Matthias Clasen wrote: > Just thought I should mention that todays metacity build, > 2.21.5-1.fc9, > includes a new compositor. It is xrender-based (derived from xcompmgr) > and thus works on systems where compiz doesn't. > > It certainly still has kinks, therefor it is not turned on by default > yet. > > To play around with it, set the gconf key: > /apps/metacity/general/compositing_manager > That is great to hear. I have been holding off submitting my patches upstream until this happened. Here is the list if anyone wants to give input. Some of them are very similar to what xfwm4 already has. 1) User configurable transparencies for windows when moved, and also drop down menus. 2) Drag and drop "windows" also become translucent. It was brought up on IRC that cursors are already ARGB, so can theoretically be transparent causing a problem. I think this is a setting that should be desktop-wide, so I prefer having it in the window manager. I am open for discussion on this. I just like being able to grab a bunch of text or large icon and actually see where I am dropping it. 3) Changes to the metacity capplet that also includes a checkbox to turn on compositing. 4) Unredirected fullscreen overlays. I know this should be handled with the new Xorg stuff. I haven't followed up how far along the new memory management code is. I understand this should also be brought up with the metacity team, and it will be. I am more interested in what the fedora desktop team thinks should be included in a base compositing desktop. I would love to be able to ship metacity with composite in F9, with the ability to turn on 3d compositing for more advanced effects. Jon From hp at redhat.com Wed Dec 19 17:33:07 2007 From: hp at redhat.com (Havoc Pennington) Date: Wed, 19 Dec 2007 12:33:07 -0500 Subject: metacity compositor in rawhide In-Reply-To: <1198084521.4070.29.camel@averatec> References: <1198077723.2809.10.camel@localhost.localdomain> <1198084521.4070.29.camel@averatec> Message-ID: <476955D3.3070608@redhat.com> Hi, Jon Nettleton wrote: > > That is great to hear. I have been holding off submitting my patches > upstream until this happened. Here is the list if anyone wants to give > input. Some of them are very similar to what xfwm4 already has. > > 1) User configurable transparencies for windows when moved, and also > drop down menus. > 2) Drag and drop "windows" also become translucent. It was brought up > on IRC that cursors are already ARGB, so can theoretically be > transparent causing a problem. I think this is a setting that should be > desktop-wide, so I prefer having it in the window manager. I am open > for discussion on this. I just like being able to grab a bunch of text > or large icon and actually see where I am dropping it. > 3) Changes to the metacity capplet that also includes a checkbox to > turn on compositing. > 4) Unredirected fullscreen overlays. I know this should be handled > with the new Xorg stuff. I haven't followed up how far along the new > memory management code is. > > I understand this should also be brought up with the metacity team, and > it will be. Don't be shy on this - bugzilla or metacity-devel is fine. A thought, I imagine the bias will be toward putting the detailed tuning of visual effects in the theme rather than in gconf. A direction you might consider. If we see tuning visual effects as something end users want to do with a GUI, a theme editor might be a nice way to go on that. For turning on compositing, perhaps that should be in the "desktop effects" dialog that Fedora has now? Remember that in the UI, there is no metacity, or metacity capplet. The metacity prefs are spread over a number of control panels (Theme, Keyboard Shortcuts, Windows). The fact that metacity implements these prefs is not supposed to be something users have to worry about. In fact the words "metacity" and "window manager" are never in the UI at all (or if they are, it's a bug). Havoc From mclasen at redhat.com Wed Dec 19 17:46:56 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 19 Dec 2007 12:46:56 -0500 Subject: metacity compositor in rawhide In-Reply-To: <1198084521.4070.29.camel@averatec> References: <1198077723.2809.10.camel@localhost.localdomain> <1198084521.4070.29.camel@averatec> Message-ID: <1198086416.19270.8.camel@localhost.localdomain> On Wed, 2007-12-19 at 18:15 +0100, Jon Nettleton wrote: > That is great to hear. I have been holding off submitting my patches > upstream until this happened. Here is the list if anyone wants to give > input. Some of them are very similar to what xfwm4 already has. > > 1) User configurable transparencies for windows when moved, and also > drop down menus. > 2) Drag and drop "windows" also become translucent. It was brought up > on IRC that cursors are already ARGB, so can theoretically be > transparent causing a problem. I think this is a setting that should be > desktop-wide, so I prefer having it in the window manager. I am open > for discussion on this. I just like being able to grab a bunch of text > or large icon and actually see where I am dropping it. > 3) Changes to the metacity capplet that also includes a checkbox to > turn on compositing. > 4) Unredirected fullscreen overlays. I know this should be handled > with the new Xorg stuff. I haven't followed up how far along the new > memory management code is. > > I understand this should also be brought up with the metacity team, and > it will be. I am more interested in what the fedora desktop team thinks > should be included in a base compositing desktop. I would love to be > able to ship metacity with composite in F9, with the ability to turn on > 3d compositing for more advanced effects. My take on this is that compositing in metacity should be just like window management in metacity: working as smoothly and unintrusively as possible. After a few minutes of using it, you should not notice it anymore. All of the things you have mentioned sound perfectly compatible with that goal... Matthias From rstrode at redhat.com Wed Dec 19 18:33:51 2007 From: rstrode at redhat.com (Ray Strode) Date: Wed, 19 Dec 2007 13:33:51 -0500 Subject: metacity compositor in rawhide In-Reply-To: <476955D3.3070608@redhat.com> References: <1198077723.2809.10.camel@localhost.localdomain> <1198084521.4070.29.camel@averatec> <476955D3.3070608@redhat.com> Message-ID: <20071219133351.061d4c29@halfline-d630.boston.devel.redhat.com> Hi, > For turning on compositing, perhaps that should be in the "desktop > effects" dialog that Fedora has now? Why would we ever want the user to be in an environment where compositing isn't available? I mean, why do we want an off button? If COMPOSITE is found, I think metacity should leverage it (at least do automatic compositing at a minimum). Even for remote X it probably makes sense to have compositing on I think (less redraws). --Ray From hp at redhat.com Wed Dec 19 18:51:00 2007 From: hp at redhat.com (Havoc Pennington) Date: Wed, 19 Dec 2007 13:51:00 -0500 Subject: metacity compositor in rawhide In-Reply-To: <20071219133351.061d4c29@halfline-d630.boston.devel.redhat.com> References: <1198077723.2809.10.camel@localhost.localdomain> <1198084521.4070.29.camel@averatec> <476955D3.3070608@redhat.com> <20071219133351.061d4c29@halfline-d630.boston.devel.redhat.com> Message-ID: <47696814.6020904@redhat.com> Hi, Ray Strode wrote: >> For turning on compositing, perhaps that should be in the "desktop >> effects" dialog that Fedora has now? > Why would we ever want the user to be in an environment where > compositing isn't available? I mean, why do we want an off button? > If COMPOSITE is found, I think metacity should leverage it (at least > do automatic compositing at a minimum). > > Even for remote X it probably makes sense to have > compositing on I think (less redraws). > My assumption here is that we don't have a way to automatically know if compositing works and is fast enough. I definitely agree that when we do have that info, which we should, it would be unacceptable to have a config option. Basically I think the config option means "test out beta window manager and X server" - at the point that we think the stuff really works and is not just a beta, the config option is silly. There might still be options for whether to have drop shadows, transparency, etc., I don't know, but we wouldn't have an option for whether to use the COMPOSITE extension. Havoc From rstrode at redhat.com Wed Dec 19 19:47:22 2007 From: rstrode at redhat.com (Ray Strode) Date: Wed, 19 Dec 2007 14:47:22 -0500 Subject: metacity compositor in rawhide In-Reply-To: <47696814.6020904@redhat.com> References: <1198077723.2809.10.camel@localhost.localdomain> <1198084521.4070.29.camel@averatec> <476955D3.3070608@redhat.com> <20071219133351.061d4c29@halfline-d630.boston.devel.redhat.com> <47696814.6020904@redhat.com> Message-ID: <20071219144722.3a9211df@halfline-d630.boston.devel.redhat.com> Hi, > >> For turning on compositing, perhaps that should be in the "desktop > >> effects" dialog that Fedora has now? > > Why would we ever want the user to be in an environment where > > compositing isn't available? I mean, why do we want an off button? > > If COMPOSITE is found, I think metacity should leverage it (at least > > do automatic compositing at a minimum). > > > > Even for remote X it probably makes sense to have > > compositing on I think (less redraws). > Basically I think the config option means "test out beta window > manager and X server" - at the point that we think the stuff really > works and is not just a beta, the config option is silly. I guess that's kind of what "Desktop Effects" is for compiz. > There might still be options for whether to have drop shadows, > transparency, etc., I don't know, but we wouldn't have an option for > whether to use the COMPOSITE extension. I'd kind of envision Desktop Effects on -> compiz, Desktop Effects off -> metacity with automatic compositing (or a minimum, non-customizable set of compositing operations that the user wouldn't consider "effects") I don't think it ever makes sense to have two compositing managers available in the UI each with overlapping / different toggleable effects. Or were you suggesting make Desktop Effects on -> metacity with iain's cm, and Desktop Effects off -> metacity with no cm (and compiz just taken out of the picture) ? --Ray From hp at redhat.com Wed Dec 19 19:57:17 2007 From: hp at redhat.com (Havoc Pennington) Date: Wed, 19 Dec 2007 14:57:17 -0500 Subject: metacity compositor in rawhide In-Reply-To: <20071219144722.3a9211df@halfline-d630.boston.devel.redhat.com> References: <1198077723.2809.10.camel@localhost.localdomain> <1198084521.4070.29.camel@averatec> <476955D3.3070608@redhat.com> <20071219133351.061d4c29@halfline-d630.boston.devel.redhat.com> <47696814.6020904@redhat.com> <20071219144722.3a9211df@halfline-d630.boston.devel.redhat.com> Message-ID: <4769779D.7010008@redhat.com> Hi, Ray Strode wrote: > I'd kind of envision Desktop Effects on -> compiz, Desktop Effects off > -> metacity with automatic compositing (or a minimum, non-customizable > set of compositing operations that the user wouldn't consider > "effects") > > I don't think it ever makes sense to have two compositing managers > available in the UI each with overlapping / different toggleable > effects. > > Or were you suggesting make Desktop Effects on -> metacity with iain's > cm, and Desktop Effects off -> metacity with no cm (and compiz just > taken out of the picture) ? I was thinking something like "Desktop Effects is kind of a bogus thing that's just there short-term / for testing, so it may as well have a 3-way choice compiz/metacity-cm/metacity-no-cm, or at least that's better than putting metacity CM in the Windows control panel" In the long term surely the only sane plan is to nuke the Desktop Effects control panel, and to pick only one WM and fix that one WM up to address its shortcomings vs. the other one. Everything else is some kind of bad-hack stopgap... Havoc From drago01 at gmail.com Wed Dec 19 19:56:54 2007 From: drago01 at gmail.com (drago01) Date: Wed, 19 Dec 2007 20:56:54 +0100 Subject: metacity compositor in rawhide In-Reply-To: <1198077723.2809.10.camel@localhost.localdomain> References: <1198077723.2809.10.camel@localhost.localdomain> Message-ID: On Dec 19, 2007 4:22 PM, Matthias Clasen wrote: > Just thought I should mention that todays metacity build, 2.21.5-1.fc9, > includes a new compositor. It is xrender-based (derived from xcompmgr) > and thus works on systems where compiz doesn't. why not use glx_tfp when available and fall back to xrender when not available? its faster and metacity already had the support for it in the past. From mclasen at redhat.com Sat Dec 22 05:54:22 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 22 Dec 2007 00:54:22 -0500 Subject: gvfs in rawhide Message-ID: <1198302862.8961.1.camel@localhost.localdomain> Hey, I have put the From mclasen at redhat.com Sat Dec 22 06:01:46 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 22 Dec 2007 01:01:46 -0500 Subject: gvfs in rawhide Message-ID: <1198303306.8961.8.camel@localhost.localdomain> Hey, in gnome 2.22, gio and gvfs will start replacing gnome-vfs as the vfs layer of gnome. gio is part of glib, gvfs is a standalone module. I have now completed the builds of glib2, gvfs, eel2, nautilus and libgnomeui that bring gio and gvfs into rawhide. Note that a few things are not working yet, e.g. authentication for remote filesystems, and the http/webdav backend is not there yet. If you want to try gvfs in the file chooser, change /desktop/gnome/interface/file_chooser_backend to "gvfs". Happy holidays, Matthias From jspaleta at gmail.com Sat Dec 22 23:09:41 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Dec 2007 14:09:41 -0900 Subject: gvfs in rawhide In-Reply-To: <1198303306.8961.8.camel@localhost.localdomain> References: <1198303306.8961.8.camel@localhost.localdomain> Message-ID: <604aa7910712221509p136608d7y4c5810cd30bb6f6e@mail.gmail.com> On Dec 21, 2007 9:01 PM, Matthias Clasen wrote: > If you want to try gvfs in the file chooser, > change /desktop/gnome/interface/file_chooser_backend to "gvfs". Is gvfs a big enough change in terms of capabilities to make it notable for release notes and general "new cool crap" in f9? -jef From drago01 at gmail.com Sat Dec 22 23:20:44 2007 From: drago01 at gmail.com (drago01) Date: Sun, 23 Dec 2007 00:20:44 +0100 Subject: gvfs in rawhide In-Reply-To: <604aa7910712221509p136608d7y4c5810cd30bb6f6e@mail.gmail.com> References: <1198303306.8961.8.camel@localhost.localdomain> <604aa7910712221509p136608d7y4c5810cd30bb6f6e@mail.gmail.com> Message-ID: On Dec 23, 2007 12:09 AM, Jeff Spaleta wrote: > On Dec 21, 2007 9:01 PM, Matthias Clasen wrote: > > If you want to try gvfs in the file chooser, > > change /desktop/gnome/interface/file_chooser_backend to "gvfs". > > > Is gvfs a big enough change in terms of capabilities to make it > notable for release notes and general "new cool crap" in f9? yes ;) but its part of gnome 2.22 so it should already be in gnome's release notes From drago01 at gmail.com Sat Dec 22 23:44:21 2007 From: drago01 at gmail.com (drago01) Date: Sun, 23 Dec 2007 00:44:21 +0100 Subject: gvfs in rawhide In-Reply-To: <1198303306.8961.8.camel@localhost.localdomain> References: <1198303306.8961.8.camel@localhost.localdomain> Message-ID: > If you want to try gvfs in the file chooser, > change /desktop/gnome/interface/file_chooser_backend to "gvfs". is this going to be enabled by default or is it just not ready for gnome 2.22 / F9 ? From mclasen at redhat.com Sun Dec 23 01:08:15 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 22 Dec 2007 20:08:15 -0500 Subject: gvfs in rawhide In-Reply-To: References: <1198303306.8961.8.camel@localhost.localdomain> Message-ID: <1198372095.12930.9.camel@localhost.localdomain> On Sun, 2007-12-23 at 00:44 +0100, drago01 wrote: > > If you want to try gvfs in the file chooser, > > change /desktop/gnome/interface/file_chooser_backend to "gvfs". > > is this going to be enabled by default > or is it just not ready for gnome 2.22 / F9 ? I would expect it to be enabled by default. But why don't you try it and find out by yourself if it is ready for F9 ? If I don't hear any major screams after the holidays, I'm probably going to turn it on for test1. From drago01 at gmail.com Sun Dec 23 01:12:21 2007 From: drago01 at gmail.com (drago01) Date: Sun, 23 Dec 2007 02:12:21 +0100 Subject: gvfs in rawhide In-Reply-To: <1198372095.12930.9.camel@localhost.localdomain> References: <1198303306.8961.8.camel@localhost.localdomain> <1198372095.12930.9.camel@localhost.localdomain> Message-ID: On Dec 23, 2007 2:08 AM, Matthias Clasen wrote: > > > On Sun, 2007-12-23 at 00:44 +0100, drago01 wrote: > > > If you want to try gvfs in the file chooser, > > > change /desktop/gnome/interface/file_chooser_backend to "gvfs". > > > > is this going to be enabled by default > > or is it just not ready for gnome 2.22 / F9 ? > > I would expect it to be enabled by default. > But why don't you try it and find out by yourself if it is ready for > F9 ? If I don't hear any major screams after the holidays, I'm probably > going to turn it on for test1. where did I say that I am not going to test it ? ;) I just wondered why its off by default... I am planning to create a new rawhide install (my current one is pre f8) and play with it in the next days. From jspaleta at gmail.com Sun Dec 23 02:46:46 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Dec 2007 17:46:46 -0900 Subject: gvfs in rawhide In-Reply-To: References: <1198303306.8961.8.camel@localhost.localdomain> <604aa7910712221509p136608d7y4c5810cd30bb6f6e@mail.gmail.com> Message-ID: <604aa7910712221846q6d1afd03j90044a76522ad3b7@mail.gmail.com> On Dec 22, 2007 2:20 PM, drago01 wrote: > yes ;) > but its part of gnome 2.22 so it should already be in gnome's release notes Aren't all new features in a fedora release ultimately in the underlying component's release notes? The question is... is this specific technology change important enough to shout about in F9 as part of our distribution notes. Just saying we have gnome 2.22 or repeating gnome 2.22's release notes verbatim isn't a particular good idea. We have to cherry-pick specific technology changes to be verbose about. Among all the changes going into the gnome stack.. is gvfs a bean enough deal to get some print space in our fedora specific release materials? If so, probablly needs a feature page in the wiki -jef From mclasen at redhat.com Mon Dec 24 04:54:06 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 23 Dec 2007 23:54:06 -0500 Subject: nautilus extensions Message-ID: <1198472046.3745.5.camel@localhost.localdomain> I noticed that nautilus 2.21 also changes the extension api slightly (the only changes seem to be in nautilus-file-info.h). Also, nautilus looks for extensions in /usr/lib/nautilus/extensions-2.0 now. Packages which install nautilus extensions will at least have to be rebuilt and possibly need some porting. Here is a list of affected packages: nautilus-share eiciel nautilus-python nautilus-actions nautilus-image-converter nautilus-sendto nautilus-flac-converter totem nautilus-cd-burner file-roller evince nautilus-extensions control-center seahorse gnome-mount-nautilus-properties nautilus-search-tool nautilus-open-terminal From bpepple at fedoraproject.org Mon Dec 24 14:29:15 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 24 Dec 2007 09:29:15 -0500 Subject: nautilus extensions In-Reply-To: <1198472046.3745.5.camel@localhost.localdomain> References: <1198472046.3745.5.camel@localhost.localdomain> Message-ID: <1198506555.11051.0.camel@nixon> On Sun, 2007-12-23 at 23:54 -0500, Matthias Clasen wrote: > I noticed that nautilus 2.21 also changes the extension api slightly > (the only changes seem to be in nautilus-file-info.h). Also, nautilus > looks for extensions in /usr/lib/nautilus/extensions-2.0 now. Packages > which install nautilus extensions will at least have to be rebuilt and > possibly need some porting. > > Here is a list of affected packages: > nautilus-image-converter > nautilus-flac-converter Thanks for the heads up. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From drago01 at gmail.com Tue Dec 25 11:47:04 2007 From: drago01 at gmail.com (drago01) Date: Tue, 25 Dec 2007 12:47:04 +0100 Subject: gvfs in rawhide In-Reply-To: <1198372095.12930.9.camel@localhost.localdomain> References: <1198303306.8961.8.camel@localhost.localdomain> <1198372095.12930.9.camel@localhost.localdomain> Message-ID: <4770EDB8.2020706@gmail.com> Matthias Clasen wrote: > On Sun, 2007-12-23 at 00:44 +0100, drago01 wrote: > >>> If you want to try gvfs in the file chooser, >>> change /desktop/gnome/interface/file_chooser_backend to "gvfs". >>> >> is this going to be enabled by default >> or is it just not ready for gnome 2.22 / F9 ? >> > > I would expect it to be enabled by default. > But why don't you try it and find out by yourself if it is ready for > F9 ? Ok installed and have a question... is ftp supposed to work? it says "invalid mount spec" what does work to test with? smb? ssh? From drago01 at gmail.com Wed Dec 26 11:46:23 2007 From: drago01 at gmail.com (drago01) Date: Wed, 26 Dec 2007 12:46:23 +0100 Subject: gvfs in rawhide In-Reply-To: <1198372095.12930.9.camel@localhost.localdomain> References: <1198303306.8961.8.camel@localhost.localdomain> <1198372095.12930.9.camel@localhost.localdomain> Message-ID: <47723F0F.9020003@gmail.com> also computer:/// does not work ... known or should I fill it? local file I/O seems to work fine From valent.turkovic at gmail.com Fri Dec 28 10:03:40 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 28 Dec 2007 11:03:40 +0100 Subject: How to remove some mounted partition icons? Message-ID: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> Hi, I have Fedora 8 and on the gnome desktop I see some icons from my partitions that I don't wan't on my gnome desktop. I don't have a problem with having my storage partition on my desktop but I also have also 4 other linux distos on my laptop and I see all of their system partitions on my desktop! I know that there is a way to disable ALL partition shortcuts but then I wouldn't see my usb drives on desktop when I plug in usb flash drives and I don't want that. So how do I remove only the shortcuts I don't want from my desktop? I saw an Ubuntu (which obviously also uses Gnome) trick which doesn't work on fedora On ubuntu only drives that are in /media are shown on the gnome desktop. I edited /etc/fstab so that partitions I don't want on desktop are mounted in /mnt - that worked on my Ubuntu but it didn't work in Fedora And ideas? Thank you -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From tiagomatos at gmail.com Fri Dec 28 12:06:46 2007 From: tiagomatos at gmail.com (Rui Tiago Matos) Date: Fri, 28 Dec 2007 12:06:46 +0000 Subject: How to remove some mounted partition icons? In-Reply-To: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> Message-ID: On 28/12/2007, Valent Turkovic wrote: > Hi, > I have Fedora 8 and on the gnome desktop I see some icons from my > partitions that I don't wan't on my gnome desktop. Yes, this is a problem on Fedora 8 due to, I think, policykit. It seems that after you've given authorization to always mount a partition there is no way (in the GUI at least) to say "I want to revoke the authorization I gave to mount this partition". Rui From valent.turkovic at gmail.com Fri Dec 28 13:15:22 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 28 Dec 2007 14:15:22 +0100 Subject: How to remove some mounted partition icons? In-Reply-To: References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> Message-ID: <64b14b300712280515q63182caam59720f94aee11167@mail.gmail.com> On 12/28/07, Rui Tiago Matos wrote: > On 28/12/2007, Valent Turkovic wrote: > > Hi, > > I have Fedora 8 and on the gnome desktop I see some icons from my > > partitions that I don't wan't on my gnome desktop. > > Yes, this is a problem on Fedora 8 due to, I think, policykit. It > seems that after you've given authorization to always mount a > partition there is no way (in the GUI at least) to say "I want to > revoke the authorization I gave to mount this partition". > > Rui I don't mind mounting all partition, I don't have problem with that, I just don't want to see icons of all mounted partition on my desktop, only those I choose. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Fri Dec 28 13:53:10 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 28 Dec 2007 14:53:10 +0100 Subject: How to remove some mounted partition icons? In-Reply-To: References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> Message-ID: <64b14b300712280553g47b9d718ub8279b903a3fd8dc@mail.gmail.com> On 12/28/07, Rui Tiago Matos wrote: > On 28/12/2007, Valent Turkovic wrote: > > Hi, > > I have Fedora 8 and on the gnome desktop I see some icons from my > > partitions that I don't wan't on my gnome desktop. > > Yes, this is a problem on Fedora 8 due to, I think, policykit. It > seems that after you've given authorization to always mount a > partition there is no way (in the GUI at least) to say "I want to > revoke the authorization I gave to mount this partition". > > Rui I found an relevant forum post: http://forums.fedoraforum.org/forum/showthread.php?p=931284 and I posted RFE to Redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=426907 Hope this helps sort this issue... Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Fri Dec 28 14:00:43 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 28 Dec 2007 15:00:43 +0100 Subject: How to remove some mounted partition icons? In-Reply-To: <64b14b300712280553g47b9d718ub8279b903a3fd8dc@mail.gmail.com> References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> <64b14b300712280553g47b9d718ub8279b903a3fd8dc@mail.gmail.com> Message-ID: <64b14b300712280600q8f3d2abx953911f81d29ddde@mail.gmail.com> On 12/28/07, Valent Turkovic wrote: > On 12/28/07, Rui Tiago Matos wrote: > > On 28/12/2007, Valent Turkovic wrote: > > > Hi, > > > I have Fedora 8 and on the gnome desktop I see some icons from my > > > partitions that I don't wan't on my gnome desktop. > > > > Yes, this is a problem on Fedora 8 due to, I think, policykit. It > > seems that after you've given authorization to always mount a > > partition there is no way (in the GUI at least) to say "I want to > > revoke the authorization I gave to mount this partition". > > > > Rui > > I found an relevant forum post: > http://forums.fedoraforum.org/forum/showthread.php?p=931284 > > and I posted RFE to Redhat bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=426907 > > Hope this helps sort this issue... > > Valent. And now the correct link :) http://forums.fedoraforum.org/forum/showpost.php?p=897548&postcount=13 -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From davidz at redhat.com Mon Dec 31 04:14:46 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 30 Dec 2007 23:14:46 -0500 Subject: How to remove some mounted partition icons? In-Reply-To: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> Message-ID: <1199074486.17788.99.camel@oneill.fubar.dk> On Fri, 2007-12-28 at 11:03 +0100, Valent Turkovic wrote: > I don't have a problem with having my storage partition on my desktop > but I also have also 4 other linux distos on my laptop and I see all > of their system partitions on my desktop! > > I know that there is a way to disable ALL partition shortcuts but then > I wouldn't see my usb drives on desktop when I plug in usb flash > drives and I don't want that. > > So how do I remove only the shortcuts I don't want from my desktop? If this is the biggest problem we have in Fedora, I think we're doing pretty good. Anyway, I there are two solutions 1. Add yet another gconf key to /apps/nautilus/desktop 2. Tell such users to use comment=hidden in /etc/fstab entries for such drives and make gvfs honor this so a mount point is hidden if it matches such an /etc/fstab entry. Since this affects only the kind of people who have > 1 Linux distro installed (for dual- or tripple-booting with Windows and Mac OS X you actually want this. IMO ditto for dual booting with other Linux installations but apparently others don't think so), I think we should go for 2. Alex? David From jspaleta at gmail.com Mon Dec 31 04:35:48 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 30 Dec 2007 19:35:48 -0900 Subject: How to remove some mounted partition icons? In-Reply-To: <1199074486.17788.99.camel@oneill.fubar.dk> References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> <1199074486.17788.99.camel@oneill.fubar.dk> Message-ID: <604aa7910712302035t17025962jbf22580d02290fc5@mail.gmail.com> On Dec 30, 2007 7:14 PM, David Zeuthen wrote: > 2. Tell such users to use comment=hidden in /etc/fstab entries for > such drives and make gvfs honor this so a mount point is hidden > if it matches such an /etc/fstab entry. > > Since this affects only the kind of people who have > 1 Linux distro > installed (for dual- or tripple-booting with Windows and Mac OS X you > actually want this. IMO ditto for dual booting with other Linux > installations but apparently others don't think so), I think we should > go for 2. Alex? Is hiding all things defined in fstab not sufficient? Do we need a a new comment=hidden syntax? Are there reasonable usage cases where you want things which are defined in fstab to be displayed in the user UI? I would have thought anything listed in fstab would be preferred to be hidable in the general case. -jef From davidz at redhat.com Mon Dec 31 05:01:46 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 31 Dec 2007 00:01:46 -0500 Subject: How to remove some mounted partition icons? In-Reply-To: <604aa7910712302035t17025962jbf22580d02290fc5@mail.gmail.com> References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> <1199074486.17788.99.camel@oneill.fubar.dk> <604aa7910712302035t17025962jbf22580d02290fc5@mail.gmail.com> Message-ID: <1199077306.17788.106.camel@oneill.fubar.dk> On Sun, 2007-12-30 at 19:35 -0900, Jeff Spaleta wrote: > On Dec 30, 2007 7:14 PM, David Zeuthen wrote: > > 2. Tell such users to use comment=hidden in /etc/fstab entries for > > such drives and make gvfs honor this so a mount point is hidden > > if it matches such an /etc/fstab entry. > > > > Since this affects only the kind of people who have > 1 Linux distro > > installed (for dual- or tripple-booting with Windows and Mac OS X you > > actually want this. IMO ditto for dual booting with other Linux > > installations but apparently others don't think so), I think we should > > go for 2. Alex? > > Is hiding all things defined in fstab not sufficient? Don't think so and no need to make that assumption. > Do we need a a > new comment=hidden syntax? The comment option is not exactly new: man 5 fstab > Are there reasonable usage cases where you > want things which are defined in fstab to be displayed in the user UI? Yes. One example is the use of persistent device names (e.g. the device links /dev/disk/by-*) to specify mount options that unprivileged wouldn't be allowed to specify themselves (e.g. 'dev' or 'suid') or to force a mount point outside /media. > I would have thought anything listed in fstab would be preferred to > be hidable in the general case. Then you'd just get complaints from people who disagree with that. Everyone's a critic. David From jspaleta at gmail.com Mon Dec 31 05:24:35 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 30 Dec 2007 20:24:35 -0900 Subject: How to remove some mounted partition icons? In-Reply-To: <1199077306.17788.106.camel@oneill.fubar.dk> References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> <1199074486.17788.99.camel@oneill.fubar.dk> <604aa7910712302035t17025962jbf22580d02290fc5@mail.gmail.com> <1199077306.17788.106.camel@oneill.fubar.dk> Message-ID: <604aa7910712302124m2c33ed6xd070fb11b7e4f141@mail.gmail.com> On Dec 30, 2007 8:01 PM, David Zeuthen wrote: > The comment option is not exactly new: man 5 fstab I meant instead of using a specific comment string to mean hide versus some pre-existing option that would be interpreted as unhide if present. noauto has been suggested by others. But I'm sure you are right the comment option makes more sense. Can you have multiple comment options defined? > > I would have thought anything listed in fstab would be preferred to > > be hidable in the general case. > > Then you'd just get complaints from people who disagree with that. > Everyone's a critic. Sorry I meant, hide by default, and use an fstab option to unhide for specific entries you don't want hidden. The question was meant as which makes the best default policy with respect to fstab entries. Opt-out of hide or Opt-in of hide. Naively, I would think it would think hiding all fstab entries by default and using an option to unhide would be the more prominent desire. We are talking about manually added entries so it's probably a coin flip in reality. I'm not going to press the point. If comment=hide does end up being the syntax to hide, would it be possible to add boilerplate to the fstab file generated at fedora install time to indicate that option can be used to hide partitions in addition to updating the fstab manpage? It might save a lot of additional discussion if admins going into fstab for manual editting see a simple boilerplate notice annoucing the new comment=hide parsing. -jef From davidz at redhat.com Mon Dec 31 06:08:17 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 31 Dec 2007 01:08:17 -0500 Subject: How to remove some mounted partition icons? In-Reply-To: <604aa7910712302124m2c33ed6xd070fb11b7e4f141@mail.gmail.com> References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> <1199074486.17788.99.camel@oneill.fubar.dk> <604aa7910712302035t17025962jbf22580d02290fc5@mail.gmail.com> <1199077306.17788.106.camel@oneill.fubar.dk> <604aa7910712302124m2c33ed6xd070fb11b7e4f141@mail.gmail.com> Message-ID: <1199081297.17788.119.camel@oneill.fubar.dk> On Sun, 2007-12-30 at 20:24 -0900, Jeff Spaleta wrote: > On Dec 30, 2007 8:01 PM, David Zeuthen wrote: > > The comment option is not exactly new: man 5 fstab > > I meant instead of using a specific comment string to mean hide versus > some pre-existing option that would be interpreted as unhide if > present. noauto has been suggested by others. > But I'm sure you are right the comment option makes more sense. Can > you have multiple comment options defined? Well, you could have tried this yourself instead of tricking me into trying it out to found out. FWIW, the answer is yes $ cat /etc/fstab |grep /dev/disk/by-path/pci-0000:00:1d.1-usb-0:2:1.0-scsi-0:0:0:0-part1 /dev/disk/by-path/pci-0000:00:1d.1-usb-0:2:1.0-scsi-0:0:0:0-part1 /mnt/foo auto defaults,users,dev,suid,exec,comment=hidden,comment=foobar 0 0 $ mount /dev/disk/by-path/pci-0000:00:1d.1-usb-0:2:1.0-scsi-0:0:0:0-part1 $ cat /etc/mtab |grep /dev/sdb1 /dev/sdb1 /mnt/foo vfat rw 0 0 $ cat /proc/mounts |grep /dev/sdb1 /dev/sdb1 /mnt/foo vfat rw,relatime,uid=500,gid=500,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii,utf8 0 0 > Sorry I meant, hide by default, and use an fstab option to unhide for > specific entries you don't want hidden. The question was meant as > which makes the best default policy with respect to fstab entries. > Opt-out of hide or Opt-in of hide. Naively, I would think it would > think hiding all fstab entries by default and using an option to > unhide would be the more prominent desire. We are talking about > manually added entries so it's probably a coin flip in reality. I'm > not going to press the point. ?Keep in mind that we hide partitions which are mere OS implementation details; e.g. mounts on /, /usr, /var and other FHS2.3 locations as well as /var/tmp, /var/audit since some security guidance documents say it's a good idea to have these on separate file systems. ?Personally I think people who wants some non-OS implementation file systems hidden are geeky control freaks with 8 different distros installed on the same hard drive; e.g. a system that is too customized for their own good. I don't think normal people will ever run into these issues. Frankly, it's certainly not such kind of users I want to optimize GNOME for. That being said, I don't want to make things impossible for them hence why I'm suggesting this approach. So I think it's like this: Most people with a lot of partitions on a useful system (e.g. one where they don't test drive 8 distros at the same time) either a) don't really use the desktop (it's a server); or b) if they do use the desktop, they just find it's convenient to have the icons on the desktop (because they have useful data on the partitions instead of just different flavors of Linux). Then again, everyone's a critic when it comes to how the UI should behave and look. > If comment=hide does end up being the syntax to hide, would it be > possible to add boilerplate to the fstab file generated at fedora > install time to indicate that option can be used to hide partitions > in addition to updating the fstab manpage? It might save a lot of > additional discussion if admins going into fstab for manual editting > see a simple boilerplate notice annoucing the new comment=hide > parsing. That would be a layering violation (a lower layer mentioning how a higher layer works) to mention this in /etc/fstab. And it probably wouldn't apply to KDE or whatever desktop someone is using. David From jspaleta at gmail.com Mon Dec 31 06:33:33 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 30 Dec 2007 21:33:33 -0900 Subject: How to remove some mounted partition icons? In-Reply-To: <1199081297.17788.119.camel@oneill.fubar.dk> References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> <1199074486.17788.99.camel@oneill.fubar.dk> <604aa7910712302035t17025962jbf22580d02290fc5@mail.gmail.com> <1199077306.17788.106.camel@oneill.fubar.dk> <604aa7910712302124m2c33ed6xd070fb11b7e4f141@mail.gmail.com> <1199081297.17788.119.camel@oneill.fubar.dk> Message-ID: <604aa7910712302233v46f1ca8dg84fc5cdf63cc20cb@mail.gmail.com> On Dec 30, 2007 9:08 PM, David Zeuthen wrote: > Well, you could have tried this yourself instead of tricking me into > trying it out to found out. FWIW, the answer is yes I was actually trying to trick Valent into doing it. > That would be a layering violation (a lower layer mentioning how a > higher layer works) to mention this in /etc/fstab. And it probably > wouldn't apply to KDE or whatever desktop someone is using. Making this a GNOME specific thing via a comment option was sort of the concern motivating the multiple comment option question above. If this is going to start out as a GNOME specific implementation, then we run risk of having different desktops requiring different comment strings as hide hints...worst case scenario. Would this be fodder for standardization through a freedekstop discussion? On the other handing building the hiding parsing into hal somehow gives us desktop agnostic functionality. But your the expert there, so I'm assuming you've got a good reason to think the doing this at a higher level makes more sense. We'll need to make some special effort in our distributions release notes to communicate that the comment=hide syntax is actually heeded specifically in GNOME and ignored in other desktops, if we include this and want people to make use of it appropriately. -jef From davidz at redhat.com Mon Dec 31 07:33:55 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 31 Dec 2007 02:33:55 -0500 Subject: How to remove some mounted partition icons? In-Reply-To: <604aa7910712302233v46f1ca8dg84fc5cdf63cc20cb@mail.gmail.com> References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> <1199074486.17788.99.camel@oneill.fubar.dk> <604aa7910712302035t17025962jbf22580d02290fc5@mail.gmail.com> <1199077306.17788.106.camel@oneill.fubar.dk> <604aa7910712302124m2c33ed6xd070fb11b7e4f141@mail.gmail.com> <1199081297.17788.119.camel@oneill.fubar.dk> <604aa7910712302233v46f1ca8dg84fc5cdf63cc20cb@mail.gmail.com> Message-ID: <1199086435.17788.142.camel@oneill.fubar.dk> Hi, Maybe I wasn't clear, but what I was trying to say in my earlier mail that the issue at hand isn't really a big deal; if you think about it it's a quite absurd discussion isn't it? We're talking about people who wants to hide mounted partitions from the desktop. I'd like to think that if you have a dedicated partition that you actually go through the trouble of mounting at a non-standard mount point, then it's because you have data on it that you want to access. If you want to access the data, then you should get an icon on the desktop. Now, you (or rather, the people with 8 linux distros on their system) can argue that you didn't mount the partition yourself; that damn GNOME did that for you automatically. So maybe the answer is that we need more fine grained control of what gets automounted and what doesn't [1]. Maybe it means adding an option so this dialog ?http://people.freedesktop.org/~david/pk-gnome-mount.png looks like this [ ] Remember authorization [ ] For this session only [ ] For this volume only Yay, more options. But fear not. The desktop live cd for F9 and onwards will come configured to never show the users such stupid annoying dialogs (note: only I may call them annoying and stupid because I wrote them :-) hehe) because we'll grant the user this authorization by default (we can make assumptions about how the desktop live cd is used since it's, uhm, targeted for desktops). And all the people with 8 linux distros on their system can then just use polkit-gnome-authorization or whatever to tweak the authorizations such that the file systems they want hidden aren't mounted. David [1] : And that's in the PolicyKit road map already; basically what needs to be done is the ability to tie authorizations with object paths; e.g. being able to answer questions like "can $PROGRAM do $ACTION on $OBJECT" rather than just "can $PROGRAM do $ACTION" as it is today. From jspaleta at gmail.com Mon Dec 31 08:41:55 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 30 Dec 2007 23:41:55 -0900 Subject: How to remove some mounted partition icons? In-Reply-To: <1199086435.17788.142.camel@oneill.fubar.dk> References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> <1199074486.17788.99.camel@oneill.fubar.dk> <604aa7910712302035t17025962jbf22580d02290fc5@mail.gmail.com> <1199077306.17788.106.camel@oneill.fubar.dk> <604aa7910712302124m2c33ed6xd070fb11b7e4f141@mail.gmail.com> <1199081297.17788.119.camel@oneill.fubar.dk> <604aa7910712302233v46f1ca8dg84fc5cdf63cc20cb@mail.gmail.com> <1199086435.17788.142.camel@oneill.fubar.dk> Message-ID: <604aa7910712310041veb9e6f7pb535b3419d332688@mail.gmail.com> On Dec 30, 2007 10:33 PM, David Zeuthen wrote: > I'd like to think that if you have a dedicated partition that you > actually go through the trouble of mounting at a non-standard mount > point, then it's because you have data on it that you want to access. If > you want to access the data, then you should get an icon on the desktop. For the simple user desktop case, I would agree with you. But there are non-trivial multiuse scenarios that aren't easily planned for that end up being a hybrid of desktop and server. Personally ive been using the 99-redhat file to hide internal partitions on the machines at home from desktop users which are mounted on demand by services that make use of the storage area. Doing it at the hal layer makes it hide everywhere in the Gnome interface: Computer, Desktop, and disk mounter applet, which makes more sense to me. Having all partitions show up in computer window as mountable but only having some appear on the Desktop as mounted, doesn't make sense to me either. Being able to turn off disk icons as a group in the desktop, I understand, but selectively its difficult to see why you want them to still be mountable but not show up on the Desktop when mounted. I don't really understand why Valent wants a solution so high up in the software stack and just worrying about hiding already mounted partitions selectively. I'm trying real hard to understand the reasoning to just hide the mounted systems on an individual basis. If we were going to hide things, I would think we'd want to hide them from the Gnome desktop everywhere and that means doing it in the Hal layer so they don't show up in the Computer window as a mountable partition. Maybe Valent doesn't really means what he thinks he means. -jef From tiagomatos at gmail.com Mon Dec 31 10:39:39 2007 From: tiagomatos at gmail.com (Rui Tiago Matos) Date: Mon, 31 Dec 2007 10:39:39 +0000 Subject: How to remove some mounted partition icons? In-Reply-To: <1199086435.17788.142.camel@oneill.fubar.dk> References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> <1199074486.17788.99.camel@oneill.fubar.dk> <604aa7910712302035t17025962jbf22580d02290fc5@mail.gmail.com> <1199077306.17788.106.camel@oneill.fubar.dk> <604aa7910712302124m2c33ed6xd070fb11b7e4f141@mail.gmail.com> <1199081297.17788.119.camel@oneill.fubar.dk> <604aa7910712302233v46f1ca8dg84fc5cdf63cc20cb@mail.gmail.com> <1199086435.17788.142.camel@oneill.fubar.dk> Message-ID: On 31/12/2007, David Zeuthen wrote: > Hi, > > Maybe I wasn't clear, but what I was trying to say in my earlier mail > that the issue at hand isn't really a big deal; if you think about it > it's a quite absurd discussion isn't it? We're talking about people who > wants to hide mounted partitions from the desktop. Some people, like me, would just expect that said partitions after being explicitly unmounted didn't get automounted next time they login. I have no issue with them being listed on computer:// I just would like policykit to forget the authorization I gave the first time that dialog came up if I explicitly unmount. > I'd like to think that if you have a dedicated partition that you > actually go through the trouble of mounting at a non-standard mount > point, then it's because you have data on it that you want to access. If > you want to access the data, then you should get an icon on the desktop. Agreed. > Now, you (or rather, the people with 8 linux distros on their system) > can argue that you didn't mount the partition yourself; that damn GNOME > did that for you automatically. So maybe the answer is that we need more > fine grained control of what gets automounted and what doesn't [1]. > Maybe it means adding an option so this dialog > > http://people.freedesktop.org/~david/pk-gnome-mount.png > > looks like this > > [ ] Remember authorization > [ ] For this session only > [ ] For this volume only I think the first option is enough if the unmount worked as I described above. And the last one, I actually would expect it to be always checked, i.e. I'd assume that dialog is already tied to a single volume. But that seems to be a current policykit shortcoming as you explain later. > Yay, more options. But fear not. The desktop live cd for F9 and onwards > will come configured to never show the users such stupid annoying > dialogs (note: only I may call them annoying and stupid because I wrote > them :-) hehe) because we'll grant the user this authorization by > default (we can make assumptions about how the desktop live cd is used > since it's, uhm, targeted for desktops). > > And all the people with 8 linux distros on their system can then just > use polkit-gnome-authorization or whatever to tweak the authorizations > such that the file systems they want hidden aren't mounted. Several laptops come with one or more "system partitions". Mine currently shows up in my desktop because I gave that authorization. I'd like to remove it from the desktop. This isn't a geeky use case I think. Rui From nphilipp at redhat.com Mon Dec 31 11:37:48 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 31 Dec 2007 12:37:48 +0100 Subject: How to remove some mounted partition icons? In-Reply-To: <1199074486.17788.99.camel@oneill.fubar.dk> References: <64b14b300712280203t285e265eta173fc9863f1d90c@mail.gmail.com> <1199074486.17788.99.camel@oneill.fubar.dk> Message-ID: <1199101068.8488.59.camel@gibraltar.str.redhat.com> On Sun, 2007-12-30 at 23:14 -0500, David Zeuthen wrote: > On Fri, 2007-12-28 at 11:03 +0100, Valent Turkovic wrote: > > I don't have a problem with having my storage partition on my desktop > > but I also have also 4 other linux distos on my laptop and I see all > > of their system partitions on my desktop! > > > > I know that there is a way to disable ALL partition shortcuts but then > > I wouldn't see my usb drives on desktop when I plug in usb flash > > drives and I don't want that. > > > > So how do I remove only the shortcuts I don't want from my desktop? > > If this is the biggest problem we have in Fedora, I think we're doing > pretty good. Anyway, I there are two solutions > > 1. Add yet another gconf key to /apps/nautilus/desktop > > 2. Tell such users to use comment=hidden in /etc/fstab entries for > such drives and make gvfs honor this so a mount point is hidden > if it matches such an /etc/fstab entry. > > Since this affects only the kind of people who have > 1 Linux distro > installed (for dual- or tripple-booting with Windows and Mac OS X you > actually want this. IMO ditto for dual booting with other Linux > installations but apparently others don't think so), I think we should > go for 2. Alex? I'm still not convinced that ordinary users need (or want) these automatic icons for fixed partitions. There are people who are interested in things as mundane as "partitions"(*) and people who aren't. I'd guess that often the former (administrator types) haven't much use for these cluttering the desktop and that most of the latter (Aunt Tilly types) aren't interested in the fact that their "shared photos" folder is on an obscure "/data" partition (set up by their nephew). (*): It's odd that the desktop treats physical partitions differently than logical volumes when ordinary users shouldn't be interested in the difference. If I were a user ;-) I would find it sensible to have (automatic) icons for: - computer, home, trash - (partitions on) removable media, cameras, etc. I would find it quite strange to have automatic icons on the desktop which point to directories on which I can't even write. The chance for a read-only (mounted) directory on a fixed physical partition (or even logical volume) to be interesting to a normal user seems rather remote to me. If such a partition contained a writable directory for this user (e.g. for shared somethings), then I wouldn't see how icons on the desktop could be created automatically in a sensible way (recursively scanning the tree underneath doesn't count). As such directories would surely be manually created by some administrator type and would be long-lived, any desktop icons for them could easily be created as symlinks in the desktop directories of the users without much additional work. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011