From sundaram at fedoraproject.org Tue Sep 1 19:56:32 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 Sep 2009 01:26:32 +0530 Subject: PackageKit command line plugin In-Reply-To: <15e53e180908311230rc4af505rba5b018b5079edd9@mail.gmail.com> References: <4A9C2194.7000307@fedoraproject.org> <15e53e180908311230rc4af505rba5b018b5079edd9@mail.gmail.com> Message-ID: <4A9D7C70.8040004@fedoraproject.org> On 09/01/2009 01:00 AM, Richard Hughes wrote: > 2009/8/31 Rahul Sundaram : >> This is not really going to be a good first impression. Since this >> plugin is now by default in Rawhide, I was wondering if there was any >> plans to fix or workaround the problem. > > Yum has been fixed upstream. The next yum release will have this fix. > See https://bugzilla.redhat.com/show_bug.cgi?id=519264 for all the > details. Tested the yum update today and it indeed does work much better. Nice work. Rahul From rakesh.pandit at gmail.com Wed Sep 2 05:03:49 2009 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Wed, 2 Sep 2009 10:33:49 +0530 Subject: GNOME Shell support in desktop-effects In-Reply-To: <1251084960.1145.147.camel@localhost.localdomain> References: <1251084960.1145.147.camel@localhost.localdomain> Message-ID: 2009/8/24 Owen Taylor wrote: [..] > UI suggestions, small and large, appreciated. > > The dialog will be split out of the compiz-gnome package ?into a > separate package required by both compiz-gnome and gnome-shell. > > If compiz-gnome or gnome-shell is not installed the option is simply > not shown. It would be neat to instead have a [..] This is wonderful work. I did some testing and found just one bug: If one is in gnome-shell and wants to go to Compiz: after opening the desktop-effects window selecting compiz on first go never works (fails with usual message "Failed to start compiz. Reverting back to previous settings") But if you use same window again (not yet closed) it works. In case one presses close and again retries it is reproducible. It short: shifting to compiz from gnome-shell on first click in "desktop effects" always fails but using the same window again makes it happen. [rakesh at rocky ~]$ rpm -qa gnome-shell gnome-shell-2.27.1-4.x86_64 [rakesh at rocky ~]$ rpm -qa desktop-effects desktop-effects-0.8.1-1.fc12.x86_64 [rakesh at rocky ~]$ -- Rakesh Pandit From mclasen at redhat.com Fri Sep 4 13:14:21 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 04 Sep 2009 09:14:21 -0400 Subject: Fit and Finish test day coming up Message-ID: <1252070061.1731.5.camel@planemask> We will look at sharing of files, music and desktops in the next Fit and Finish test day, which is coming up very soon, 2009-09-08, which is the coming Tuesday. Read all about it at http://fedoraproject.org/wiki/Test_Day:2009-09-08_Fit_and_Finish:Sharing Join us on Tuesday in #fedora-fit-and-finish on Freenode.e Matthias From wwoods at redhat.com Wed Sep 9 13:51:57 2009 From: wwoods at redhat.com (Will Woods) Date: Wed, 09 Sep 2009 09:51:57 -0400 Subject: Question regarding "About this computer" for gnome-system-monitor In-Reply-To: <4AA79DA5.3070401@redhat.com> References: <4AA70EFA.8070902@redhat.com> <4AA79DA5.3070401@redhat.com> Message-ID: <1252504317.2716.15.camel@metroid> On Wed, 2009-09-09 at 17:50 +0530, Ankitkumar Rameshchandra Patel wrote: > I remember Will Woods tried helping us during Fedora 9 release. we have added > translations on the wiki page > > After going through the couple of related bugs, I think it's a Fedora > (not Gnome) issue and needs to bring an attention to the package maintainer for > gnome-system-monitor for Fedora. > > Added Will in the CC list, who can probably give us a direction since he knows > this better. Correct - patches were submitted upstream[1] but only the first one was accepted. I haven't had time to rework/resubmit the patches. Until that happens, the translations get put directly into about-this-computer.desktop, which lives in the gnome-system-monitor package: http://cvs.fedoraproject.org/viewvc/rpms/gnome-system-monitor/devel/about-this-computer.desktop?revision=1.7&view=markup Add translations there[2] and I'll try to get someone to help me upstream the other patches so we can get this string translated normally. -w [1] See the following bugs: https://bugzilla.gnome.org/show_bug.cgi?id=522988 (accepted) https://bugzilla.gnome.org/show_bug.cgi?id=534413 https://bugzilla.gnome.org/show_bug.cgi?id=534538 [2] g-s-m allows checkins from provenpackager, so there are quite a few people who can make the change for you if you can't do it yourself. From mclasen at redhat.com Wed Sep 9 15:14:41 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 09 Sep 2009 11:14:41 -0400 Subject: Question regarding "About this computer" for gnome-system-monitor In-Reply-To: <1252504317.2716.15.camel@metroid> References: <4AA70EFA.8070902@redhat.com> <4AA79DA5.3070401@redhat.com> <1252504317.2716.15.camel@metroid> Message-ID: <1252509281.1749.0.camel@planemask> On Wed, 2009-09-09 at 09:51 -0400, Will Woods wrote: > On Wed, 2009-09-09 at 17:50 +0530, Ankitkumar Rameshchandra Patel wrote: > > > I remember Will Woods tried helping us during Fedora 9 release. we have added > > translations on the wiki page > > > > After going through the couple of related bugs, I think it's a Fedora > > (not Gnome) issue and needs to bring an attention to the package maintainer for > > gnome-system-monitor for Fedora. > > > > Added Will in the CC list, who can probably give us a direction since he knows > > this better. > > Correct - patches were submitted upstream[1] but only the first one was > accepted. I haven't had time to rework/resubmit the patches. > > Until that happens, the translations get put directly into > about-this-computer.desktop, which lives in the gnome-system-monitor > package: > > http://cvs.fedoraproject.org/viewvc/rpms/gnome-system-monitor/devel/about-this-computer.desktop?revision=1.7&view=markup > > Add translations there[2] and I'll try to get someone to help me > upstream the other patches so we can get this string translated > normally. > > -w > > [1] See the following bugs: > https://bugzilla.gnome.org/show_bug.cgi?id=522988 (accepted) > https://bugzilla.gnome.org/show_bug.cgi?id=534413 > https://bugzilla.gnome.org/show_bug.cgi?id=534538 > > [2] g-s-m allows checkins from provenpackager, so there are quite a few > people who can make the change for you if you can't do it yourself. > I've rebuilt the package with current wiki contents, this morning. From ankit at redhat.com Fri Sep 11 07:48:45 2009 From: ankit at redhat.com (Ankit Patel) Date: Fri, 11 Sep 2009 13:18:45 +0530 Subject: Question regarding "About this computer" for gnome-system-monitor In-Reply-To: <1252509281.1749.0.camel@planemask> References: <4AA70EFA.8070902@redhat.com> <4AA79DA5.3070401@redhat.com> <1252504317.2716.15.camel@metroid> <1252509281.1749.0.camel@planemask> Message-ID: <4AAA00DD.9000700@redhat.com> Matthias Clasen wrote: > > I've rebuilt the package with current wiki contents, this morning. > gnome-system-monitor-2.27.4-4.fc12 includes this fix. Thanks Matthias. -- Regards, Ankit Patel http://www.indianoss.org/ http://www.ankit644.com/ From aditya at adityapatawari.com Sun Sep 13 16:37:46 2009 From: aditya at adityapatawari.com (Aditya Patawari) Date: Sun, 13 Sep 2009 22:07:46 +0530 Subject: Introduction to a new SIG for creation of Live DVD Message-ID: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> I was just reading the mails about the Fedora print magazine. There Paul Frields said that "In the longer term we really do want to move away from the Install DVD to a Live DVD that has more relevant applications and content". We didn't had any SIG for creating Live DVD and Live DVD spin. So I have started the same. The main motive of the SIG will be to roll out one live DVD per fedora release which will have all the packages of live cd and other packages as suggested by the community. For this to be a success, community support is very much required. Interested contributors please join the SIG at https://fedoraproject.org/wiki/SIGs/LiveDVD . Any kind of suggestions or pointers are most welcome. -- Aditya Patawari Birla Institute Of Technology, Mesra http://blog.adityapatawari.com/ https://fedoraproject.org/wiki/User:Adimania India -------------- next part -------------- An HTML attachment was scrubbed... URL: From stickster at gmail.com Mon Sep 14 12:34:43 2009 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 14 Sep 2009 08:34:43 -0400 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> Message-ID: <20090914123443.GU28498@localhost.localdomain> On Sun, Sep 13, 2009 at 10:07:46PM +0530, Aditya Patawari wrote: > I was just reading the mails about the Fedora print magazine. There > Paul Frields said that "In the longer term we really do want to move > away from the Install DVD to a Live DVD that has more > relevant applications and content". We didn't had any SIG for creating > Live DVD and Live DVD spin. So I have started the same. The main motive of > the SIG will be to roll out one live DVD per fedora release which will > have all the packages of live cd and other packages as suggested by the > community. For this to be a success, community support is very much > required. Interested contributors please join the SIG at > [1]https://fedoraproject.org/wiki/SIGs/LiveDVD .? Any kind of suggestions > or pointers are most > welcome. To clarify, what I was talking about was the fact that the Installation DVD is really just a continuation of what has shipped since time immemorial in Red Hat Linux many years ago. It doesn't have any particular target. At the same time, our Live CDs are highly constrained by a combination of (1) the 700 MB limit, and (2) our desire -- a worthy one, IMHO -- to keep them usable in as many languages as possible. So whenever we talk about media that includes a bunch of applications that users do really want, but we can't include on a CD-sized medium, we fall back to the DVD, which loses much of the appeal of the Live image. I think the Desktop SIG has already been discussing the need for a larger image due to constantly having to bump out useful applications to stay under the CD size limit. At the same time, the Installation DVD does provide a helpful testing bed for Anaconda. Mainly, I was just interested in the idea of existing SIGs feeling empowered to produce their Live spins for larger media, rather than everyone needing more applications having to fall back to the Installation DVD. I'm not sure what an equally untargeted generic Live spin really achieves, but at the same time, if there are contributors interested in producing one, our spin process certainly permits it. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From aditya at adityapatawari.com Mon Sep 14 12:49:12 2009 From: aditya at adityapatawari.com (Aditya Patawari) Date: Mon, 14 Sep 2009 18:19:12 +0530 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: <20090914123443.GU28498@localhost.localdomain> References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914123443.GU28498@localhost.localdomain> Message-ID: <2d4fa6320909140549s66aff386r910276f033a63b23@mail.gmail.com> Initially I was also thinking of producing a larger image to include more packages but after reading Colin's view I also thinking that instead of creating a large image with all pre-installed stuff, a large image with an internal repository can be created. It will reduce the user's need of accessing external repository without having a lot of stuff installed which a new user might find confusing and cluttered. It will leave the basic "try before use" feature of the live cd will remain as it is. On Mon, Sep 14, 2009 at 6:04 PM, Paul W. Frields wrote: > To clarify, what I was talking about was the fact that the > Installation DVD is really just a continuation of what has shipped > since time immemorial in Red Hat Linux many years ago. It doesn't > have any particular target. At the same time, our Live CDs are highly > constrained by a combination of (1) the 700 MB limit, and (2) our > desire -- a worthy one, IMHO -- to keep them usable in as many > languages as possible. > > So whenever we talk about media that includes a bunch of applications > that users do really want, but we can't include on a CD-sized medium, > we fall back to the DVD, which loses much of the appeal of the Live > image. I think the Desktop SIG has already been discussing the need > for a larger image due to constantly having to bump out useful > applications to stay under the CD size limit. At the same time, the > Installation DVD does provide a helpful testing bed for Anaconda. > > Mainly, I was just interested in the idea of existing SIGs feeling > empowered to produce their Live spins for larger media, rather than > everyone needing more applications having to fall back to the > Installation DVD. I'm not sure what an equally untargeted generic > Live spin really achieves, but at the same time, if there are > contributors interested in producing one, our spin process certainly > permits it. > > -- > Paul W. Frields http://paul.frields.org/ > gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 > http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ > irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-desktop-list > -- Aditya Patawari Join Live DVD SIG : https://fedoraproject.org/wiki/SIGs/LiveDVD http://blog.adityapatawari.com/ https://fedoraproject.org/wiki/User:Adimania India -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbarnes at redhat.com Mon Sep 14 13:41:57 2009 From: mbarnes at redhat.com (Matthew Barnes) Date: Mon, 14 Sep 2009 08:41:57 -0500 Subject: Redirecting ABRT spam Message-ID: <1252935717.2662.10.camel@localhost.localdomain> Now that Fedora's ABRT system has begun spewing random Evolution crash reports at me, I have to spend more time manually forwarding the stack traces upstream to our BugBuddyBugs component that we designated for this kind of thing. So far the flow of incoming reports is a mere trickle, but I expect this to become much more time consuming once Fedora 12 is released. Bug Buddy was able to read X-GNOME-Bugzilla-* keys from the application's .desktop file, allowing maintainers -some- control over where crash reports were directed. Does ABRT have some kind of similar feature that would allow me to redirect crash reports to GNOME Bugzilla instead of Red Hat Bugzilla? Matthew Barnes From walters at verbum.org Mon Sep 14 14:32:20 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 14 Sep 2009 14:32:20 +0000 Subject: Redirecting ABRT spam In-Reply-To: <1252935717.2662.10.camel@localhost.localdomain> References: <1252935717.2662.10.camel@localhost.localdomain> Message-ID: On Mon, Sep 14, 2009 at 1:41 PM, Matthew Barnes wrote: > Now that Fedora's ABRT system has begun spewing random Evolution crash > reports at me, I have to spend more time manually forwarding the stack > traces upstream to our BugBuddyBugs component that we designated for > this kind of thing. ?So far the flow of incoming reports is a mere > trickle, but I expect this to become much more time consuming once > Fedora 12 is released. The way I very strongly think this should work is that crashes should not be Bugzilla bugs, but submitted anonymously and maintainers can then go and look at a custom UI to see the top crashes for a package. http://www.redhat.com/archives/rhl-devel-list/2009-August/msg01439.html Doing this is waiting on Fedora infrastructure. From mclasen at redhat.com Mon Sep 14 14:35:21 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 14 Sep 2009 10:35:21 -0400 Subject: Redirecting ABRT spam In-Reply-To: <1252935717.2662.10.camel@localhost.localdomain> References: <1252935717.2662.10.camel@localhost.localdomain> Message-ID: <1252938921.1663.5.camel@planemask> On Mon, 2009-09-14 at 08:41 -0500, Matthew Barnes wrote: > Now that Fedora's ABRT system has begun spewing random Evolution crash > reports at me, I have to spend more time manually forwarding the stack > traces upstream to our BugBuddyBugs component that we designated for > this kind of thing. So far the flow of incoming reports is a mere > trickle, but I expect this to become much more time consuming once > Fedora 12 is released. > > Bug Buddy was able to read X-GNOME-Bugzilla-* keys from the > application's .desktop file, allowing maintainers -some- control over > where crash reports were directed. > > Does ABRT have some kind of similar feature that would allow me to > redirect crash reports to GNOME Bugzilla instead of Red Hat Bugzilla? > > Matthew Barnes > The abrt bugzilla plugin lets you configure what bugzilla to use. But that's user configuration, not something you can tweak on a per-package basis. It would be nice to have a checkbox there, maybe [ ] Use the bugzilla instance that is recommended by the package Another thing that would be good to prevent and F12 bug flood is to make duplicate catching work better. I've had to manually mark a number of abrt reports with very similar stacktraces as dupes. I would have expected abrt to figure that out by itself. Matthias From a.badger at gmail.com Mon Sep 14 14:39:39 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Sep 2009 07:39:39 -0700 Subject: Redirecting ABRT spam In-Reply-To: References: <1252935717.2662.10.camel@localhost.localdomain> Message-ID: <4AAE55AB.1060908@gmail.com> On 09/14/2009 07:32 AM, Colin Walters wrote: > The way I very strongly think this should work is that crashes should > not be Bugzilla bugs, but submitted anonymously and maintainers can > then go and look at a custom UI to see the top crashes for a package. > > http://www.redhat.com/archives/rhl-devel-list/2009-August/msg01439.html > > Doing this is waiting on Fedora infrastructure. > Actually... no one in Fedora Infrastructure is working on the server for this. So it's waiting on someone who would want to write it to volunteer and touch base with us about what the requirements would be. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From walters at verbum.org Mon Sep 14 14:44:25 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 14 Sep 2009 14:44:25 +0000 Subject: Redirecting ABRT spam In-Reply-To: <1252938921.1663.5.camel@planemask> References: <1252935717.2662.10.camel@localhost.localdomain> <1252938921.1663.5.camel@planemask> Message-ID: On Mon, Sep 14, 2009 at 2:35 PM, Matthias Clasen wrote: > Another thing that would be good to prevent and F12 bug flood is to make > duplicate catching work better. I've had to manually mark a number of > abrt reports with very similar stacktraces as dupes. I would have > expected abrt to figure that out by itself. Duplicate catching is only part of the problem. I have a few arguments: 1) At a very fundamental level, the generating at least one email to a developer per crash *does not scale*. Crashes can happen for an amazing number of reasons totally unrelated to the software that crashed. We CANNOT create a developer task per crash by default. 2) We won't actually get the data because of Bugzilla login hurdles. Right now only people really willing to jump through a lot of hoops will be able to successfully file a bug. This drastically reduces the crash data we get and radically distorts it. 3) Associating a crash by default with an email address (as Bugzilla requires) is wrong. They may contain private data in the stack arguments, and ideally (if we had a sane storage system) we'd be able to accept the full core file (suitably compressed for transfer, and with a privacy note)> From walters at verbum.org Mon Sep 14 14:50:32 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 14 Sep 2009 14:50:32 +0000 Subject: Redirecting ABRT spam In-Reply-To: <4AAE55AB.1060908@gmail.com> References: <1252935717.2662.10.camel@localhost.localdomain> <4AAE55AB.1060908@gmail.com> Message-ID: On Mon, Sep 14, 2009 at 2:39 PM, Toshio Kuratomi wrote: > On 09/14/2009 07:32 AM, Colin Walters wrote: > >> The way I very strongly think this should work is that crashes should >> not be Bugzilla bugs, but submitted anonymously and maintainers can >> then go and look at a custom UI to see the top crashes for a package. >> >> http://www.redhat.com/archives/rhl-devel-list/2009-August/msg01439.html >> >> Doing this is waiting on Fedora infrastructure. >> > > Actually... no one in Fedora Infrastructure is working on the server for > this. ?So it's waiting on someone who would want to write it to > volunteer and touch base with us about what the requirements would be. That's what I mean; I filed a ticket where I was asking for design/feedback, let me see... https://fedorahosted.org/fedora-infrastructure/ticket/1651 From mclasen at redhat.com Mon Sep 14 14:53:58 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 14 Sep 2009 10:53:58 -0400 Subject: Redirecting ABRT spam In-Reply-To: References: <1252935717.2662.10.camel@localhost.localdomain> <1252938921.1663.5.camel@planemask> Message-ID: <1252940038.1663.7.camel@planemask> On Mon, 2009-09-14 at 14:44 +0000, Colin Walters wrote: > On Mon, Sep 14, 2009 at 2:35 PM, Matthias Clasen wrote: > > > Another thing that would be good to prevent and F12 bug flood is to make > > duplicate catching work better. I've had to manually mark a number of > > abrt reports with very similar stacktraces as dupes. I would have > > expected abrt to figure that out by itself. > > Duplicate catching is only part of the problem. I have a few arguments: > > 1) At a very fundamental level, the generating at least one email to a > developer per crash *does not scale*. Crashes can happen for an > amazing number of reasons totally unrelated to the software that > crashed. We CANNOT create a developer task per crash by default. > 2) We won't actually get the data because of Bugzilla login hurdles. > Right now only people really willing to jump through a lot of hoops > will be able to successfully file a bug. This drastically reduces the > crash data we get and radically distorts it. > 3) Associating a crash by default with an email address (as Bugzilla > requires) is wrong. They may contain private data in the stack > arguments, and ideally (if we had a sane storage system) we'd be able > to accept the full core file (suitably compressed for transfer, and > with a privacy note)> All this might be true. But as long as abrt does dump crashes into bugzilla, I'd really rather have it identify dupes, than having to do it myself. From a.badger at gmail.com Mon Sep 14 15:02:50 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Sep 2009 08:02:50 -0700 Subject: Redirecting ABRT spam In-Reply-To: References: <1252935717.2662.10.camel@localhost.localdomain> <4AAE55AB.1060908@gmail.com> Message-ID: <4AAE5B1A.6060206@gmail.com> On 09/14/2009 07:50 AM, Colin Walters wrote: > On Mon, Sep 14, 2009 at 2:39 PM, Toshio Kuratomi wrote: >> Actually... no one in Fedora Infrastructure is working on the server for >> this. So it's waiting on someone who would want to write it to >> volunteer and touch base with us about what the requirements would be. > > That's what I mean; I filed a ticket where I was asking for > design/feedback, let me see... > > https://fedorahosted.org/fedora-infrastructure/ticket/1651 > If you could join #fedora-admin and ask questions that would probably move this along to the "We can host this" "We can't host this" stage quicker. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From notting at redhat.com Mon Sep 14 16:29:47 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 Sep 2009 12:29:47 -0400 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> Message-ID: <20090914162947.GB10030@nostromo.devel.redhat.com> Aditya Patawari (aditya at adityapatawari.com) said: > I was just reading the mails about the Fedora print magazine. There > Paul Frields said that "In the longer term we really do want to move > away from the Install DVD to a Live DVD that has more > relevant applications and content". We didn't had any SIG for creating > Live DVD and Live DVD spin. So I have started the same. The main motive of > the SIG will be to roll out one live DVD per fedora release which will have > all the packages of live cd and other packages as suggested by the > community. For this to be a success, community support is very much > required. Interested contributors please join the SIG at > https://fedoraproject.org/wiki/SIGs/LiveDVD . Any kind of suggestions or > pointers are most > welcome. How would this be different from each LiveCD group just targeting a DVD size and changing their spin appropriately? Bill From aditya at adityapatawari.com Mon Sep 14 17:20:23 2009 From: aditya at adityapatawari.com (Aditya Patawari) Date: Mon, 14 Sep 2009 22:50:23 +0530 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: <20090914162947.GB10030@nostromo.devel.redhat.com> References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> Message-ID: <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> On Mon, Sep 14, 2009 at 9:59 PM, Bill Nottingham wrote: > How would this be different from each LiveCD group just targeting > a DVD size and changing their spin appropriately? > Actually instead of increasing the size and getting a cluttered install, I am planning to include an internal repository. After installation end user will get the normal live cd stuff and an inbuilt repo which can be used to install packages as per the need. It will reduce the need of internet and will also increase the package installation speed. -- Aditya Patawari Join Live DVD SIG : https://fedoraproject.org/wiki/SIGs/LiveDVD http://blog.adityapatawari.com/ https://fedoraproject.org/wiki/User:Adimania India -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Mon Sep 14 18:03:31 2009 From: drago01 at gmail.com (drago01) Date: Mon, 14 Sep 2009 20:03:31 +0200 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> Message-ID: On Mon, Sep 14, 2009 at 7:20 PM, Aditya Patawari wrote: > > On Mon, Sep 14, 2009 at 9:59 PM, Bill Nottingham wrote: >> >> How would this be different from each LiveCD group just targeting >> a DVD size and changing their spin appropriately? > > Actually instead of increasing the size and getting a cluttered install, I > am planning to include an internal repository. After installation end user > will get the normal live cd stuff and an inbuilt repo which can be used to > install packages as per the need. It will reduce the need of internet and > will also increase the package installation speed. We should not make the install more complicated buy adding extra questions "do you want to install foo, bar and baz?" We should just move away from a CD where it makes sense, a spin targeted for slower / older hardware can be CD size limited, but that should not mean that we should live with the artificial CD limit forever. Also using a DVD does not necessary mean that we must fill a full DL disk, but it will allow us to move above the 700MB limit where it makes sense (adding stuff like OO.org or translations for the KDE spin etc.) But well I doubt that we will do this anytime soon, even though it makes a lot of sense IMHO. From notting at redhat.com Mon Sep 14 18:03:16 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 Sep 2009 14:03:16 -0400 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> Message-ID: <20090914180315.GA13938@nostromo.devel.redhat.com> Aditya Patawari (aditya at adityapatawari.com) said: > > How would this be different from each LiveCD group just targeting > > a DVD size and changing their spin appropriately? > > Actually instead of increasing the size and getting a cluttered install, I > am planning to include an internal repository. After installation end user > will get the normal live cd stuff and an inbuilt repo which can be used to > install packages as per the need. It will reduce the need of internet and > will also increase the package installation speed. ... how is that significantly different than what we have now? Now: - user downloads DVD iso - user picks from arbitrary set of software - additional software can be selected from network - user installs New: - user downloads DVD live iso - user partitions, has to include space for all other software on DVD (!) - user installs - user reboots - user can pick from arbitary set of software to add on - additional software can be selected from network How is this better? Bill From walters at verbum.org Mon Sep 14 18:07:25 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 14 Sep 2009 18:07:25 +0000 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: <20090914180315.GA13938@nostromo.devel.redhat.com> References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> <20090914180315.GA13938@nostromo.devel.redhat.com> Message-ID: On Mon, Sep 14, 2009 at 6:03 PM, Bill Nottingham wrote: > > New: > - user downloads DVD live iso > - user partitions, has to include space for all other software on DVD (!) > - user installs > - user reboots > - user can pick from arbitary set of software to add on > - additional software can be selected from network Because in the future we will we have a better UI than the current Add/Remove applications for installing desktop software at least, and this way Anaconda doesn't need to maintain a package selection UI. From notting at redhat.com Mon Sep 14 18:08:47 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 Sep 2009 14:08:47 -0400 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> <20090914180315.GA13938@nostromo.devel.redhat.com> Message-ID: <20090914180847.GB13938@nostromo.devel.redhat.com> Colin Walters (walters at verbum.org) said: > > New: > > - user downloads DVD live iso > > - user partitions, has to include space for all other software on DVD (!) > > - user installs > > - user reboots > > - user can pick from arbitary set of software to add on > > - additional software can be selected from network > > Because in the future we will we have a better UI than the current > Add/Remove applications for installing desktop software at least, and > this way Anaconda doesn't need to maintain a package selection UI. We've been describing that future for a while. In the meantime, having to actually install uninstalled versions of random software seems inefficient. Bill From walters at verbum.org Mon Sep 14 18:18:32 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 14 Sep 2009 18:18:32 +0000 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: <20090914180847.GB13938@nostromo.devel.redhat.com> References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> <20090914180315.GA13938@nostromo.devel.redhat.com> <20090914180847.GB13938@nostromo.devel.redhat.com> Message-ID: On Mon, Sep 14, 2009 at 6:08 PM, Bill Nottingham wrote: > > We've been describing that future for a while. In the meantime, having > to actually install uninstalled versions of random software seems > inefficient. Well, there are a few other virtues to having a larger image, namely: * Can use web browser to find out more information about applications (and in general, use other live tools) * De-duplicates the install path, allowing us to focus on streamlining one single path From aditya at adityapatawari.com Mon Sep 14 18:19:20 2009 From: aditya at adityapatawari.com (Aditya Patawari) Date: Mon, 14 Sep 2009 23:49:20 +0530 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> Message-ID: <2d4fa6320909141119v6e07bf38m2112fc1f659ad5f2@mail.gmail.com> On Mon, Sep 14, 2009 at 11:33 PM, drago01 wrote: > > We should not make the install more complicated buy adding extra > questions "do you want to install foo, bar and baz?" > That is the whole point. It won't ask. It's like a local repository. If you need a package just use the Add/Remove UI or yum. -- Aditya Patawari Join Live DVD SIG : https://fedoraproject.org/wiki/SIGs/LiveDVD http://blog.adityapatawari.com/ https://fedoraproject.org/wiki/User:Adimania India -------------- next part -------------- An HTML attachment was scrubbed... URL: From aditya at adityapatawari.com Mon Sep 14 18:24:16 2009 From: aditya at adityapatawari.com (Aditya Patawari) Date: Mon, 14 Sep 2009 23:54:16 +0530 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: <20090914180315.GA13938@nostromo.devel.redhat.com> References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> <20090914180315.GA13938@nostromo.devel.redhat.com> Message-ID: <2d4fa6320909141124n7945cd14n64ae56a1438132e1@mail.gmail.com> On Mon, Sep 14, 2009 at 11:33 PM, Bill Nottingham wrote: > > New: > - user downloads DVD live iso > - user partitions, has to include space for all other software on DVD (!) > - user installs > - user reboots > - user can pick from arbitary set of software to add on > - additional software can be selected from network > > How is this better? > > I agree that it will take up more space but its a price which most of us will be ready to pay. Bad Internet connection is more common than smaller hard disks. Also if someone is concern about the disk space so much than he'll be using live cd than dvd. Primarily Live DVD is to help those who do not have internet access or a bad connection. -- Aditya Patawari Join Live DVD SIG : https://fedoraproject.org/wiki/SIGs/LiveDVD http://blog.adityapatawari.com/ https://fedoraproject.org/wiki/User:Adimania India -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Mon Sep 14 18:28:37 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 Sep 2009 14:28:37 -0400 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> <20090914180315.GA13938@nostromo.devel.redhat.com> <20090914180847.GB13938@nostromo.devel.redhat.com> Message-ID: <20090914182837.GD13938@nostromo.devel.redhat.com> Colin Walters (walters at verbum.org) said: > * De-duplicates the install path, allowing us to focus on streamlining > one single path Given the requirements for server installs (kickstart, etc.) I don't know that you can ever go to live-only (unless you really *shrink* the live image.) Bill From notting at redhat.com Mon Sep 14 18:29:54 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 Sep 2009 14:29:54 -0400 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: <2d4fa6320909141119v6e07bf38m2112fc1f659ad5f2@mail.gmail.com> References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> <2d4fa6320909141119v6e07bf38m2112fc1f659ad5f2@mail.gmail.com> Message-ID: <20090914182953.GE13938@nostromo.devel.redhat.com> Aditya Patawari (aditya at adityapatawari.com) said: > > We should not make the install more complicated buy adding extra > > questions "do you want to install foo, bar and baz?" > > That is the whole point. It won't ask. It's like a local repository. If you > need a package just use the Add/Remove UI or yum. Actually... how does this save you bandwidth in the long run if it's obsolete 3 weeks after release (as many packages are.) Bill From drago01 at gmail.com Mon Sep 14 18:33:10 2009 From: drago01 at gmail.com (drago01) Date: Mon, 14 Sep 2009 20:33:10 +0200 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: <20090914182953.GE13938@nostromo.devel.redhat.com> References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> <2d4fa6320909141119v6e07bf38m2112fc1f659ad5f2@mail.gmail.com> <20090914182953.GE13938@nostromo.devel.redhat.com> Message-ID: On Mon, Sep 14, 2009 at 8:29 PM, Bill Nottingham wrote: > Aditya Patawari (aditya at adityapatawari.com) said: >> > We should not make the install more complicated buy adding extra >> > questions "do you want to install foo, bar and baz?" >> >> That is the whole point. It won't ask. It's like a local repository. If you >> need a package just use the Add/Remove UI or yum. > > Actually... how does this save you bandwidth in the long run if it's > obsolete 3 weeks after release (as many packages are.) deltarpms From walters at verbum.org Mon Sep 14 18:37:44 2009 From: walters at verbum.org (Colin Walters) Date: Mon, 14 Sep 2009 18:37:44 +0000 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: <20090914182837.GD13938@nostromo.devel.redhat.com> References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> <20090914180315.GA13938@nostromo.devel.redhat.com> <20090914180847.GB13938@nostromo.devel.redhat.com> <20090914182837.GD13938@nostromo.devel.redhat.com> Message-ID: On Mon, Sep 14, 2009 at 6:28 PM, Bill Nottingham wrote: > Colin Walters (walters at verbum.org) said: >> * De-duplicates the install path, allowing us to focus on streamlining >> one single path > > Given the requirements for server installs (kickstart, etc.) I don't know > that you can ever go to live-only (unless you really *shrink* the live > image.) I'd imagine that running the "live Anaconda" UI from inside the GDM X session wouldn't take significantly more resources than the Anaconda OS after creating an image that doesn't have games, etc. From walters at verbum.org Wed Sep 16 15:16:20 2009 From: walters at verbum.org (Colin Walters) Date: Wed, 16 Sep 2009 15:16:20 +0000 Subject: Introduction to a new SIG for creation of Live DVD In-Reply-To: References: <2d4fa6320909130937i22803858l77928960678a614c@mail.gmail.com> <20090914162947.GB10030@nostromo.devel.redhat.com> <2d4fa6320909141020u693545aqcf3bf54a9576fc5c@mail.gmail.com> <20090914180315.GA13938@nostromo.devel.redhat.com> <20090914180847.GB13938@nostromo.devel.redhat.com> <20090914182837.GD13938@nostromo.devel.redhat.com> Message-ID: On Wed, Sep 16, 2009 at 10:06 AM, Benny Amorsen wrote: > Colin Walters writes: > >> I'd imagine that running the "live Anaconda" UI from inside the GDM X >> session wouldn't take significantly more resources than the Anaconda >> OS after creating an image that doesn't have games, etc. > > Images sound significantly more difficult to create and maintain than > kickstart-files. > > I would really hate to lose kickstart. No one's suggesting replacing kickstart, actually I think we way undersell it. What I'm talking about is the mode where the image boots directly into Anaconda as a complete OS should instead be a live image with Anaconda as an application, which for the most part would be the same except you'd gain the ability to run say Firefox (or any other app; games), or do "yum install" during the install. From mandreiana.lists at gmail.com Fri Sep 18 18:41:53 2009 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Fri, 18 Sep 2009 21:41:53 +0300 Subject: A less cluttered desktop In-Reply-To: References: <1248299783.1588.17.camel@planemask> <1248458989.3119.47.camel@metroid> <1248461347.16860.2.camel@planemask> <1248571032.1432.1.camel@planemask> <1248706315.3119.55.camel@metroid> <1248712492.1535.30.camel@planemask> Message-ID: <4bcf41a00909181141l15f3a88erc79e57e4b62f965a@mail.gmail.com> On Mon, Jul 27, 2009 at 7:55 PM, drago01 wrote: > Yes and my suggestion was a separate key for this to make it less > confusing,but still preserve the option to have icons for those who > want them. But please leave the icons on by default. We are on the desktop list, right? You know, colours and icons and stuff :) As another person asked, what is the rationale for this change? -- Marius Andreiana From mandreiana.lists at gmail.com Fri Sep 18 19:08:31 2009 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Fri, 18 Sep 2009 22:08:31 +0300 Subject: kill Preferences -> GL Desktop? Message-ID: <4bcf41a00909181208w65696d5fl5157dac14ba1193f@mail.gmail.com> Didn't know what GL Desktop is, so I clicked it. I was already using compiz, with preferences set in Compiz Settings Manager (ccsm). On start, GL Desktop says An error occurred while loading or saving configuration information for gnome-compiz-preferences. Some of your configuration settings may not work properly. Seems it has a subset of Compiz Settings Manager options. Why does GL Desktop still need to be kept? Thanks, -- Marius Andreiana From mandreiana.lists at gmail.com Fri Sep 18 19:19:30 2009 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Fri, 18 Sep 2009 22:19:30 +0300 Subject: NetworkManager & keyring Message-ID: <4bcf41a00909181219l38530222tf847710b2b5ee580@mail.gmail.com> After a few days of using a fresh F11 setup, upon login I was told nm-applet wants to access default keyring, but it's locked. Enter password. Hm. Don't know what password. Tried my account and root password, no luck. Searched help for how to change keyring password, nope. Ah, found Preferences -> Encryption and Keyrings, that will help. Uhm... no. Tried a restart, same question. Tried to add another network connection to get my net working, but still NM wants to know the default keyring password. I want that too :) Finally I tried my initial account password used on install (which I changed a few days later), that was it! Could this behaviour be changed to: when a keyring needs to be setup, prompt user with a dialog explaining what a keyring is and ask for a password. (about my recent posts - I've been influenced in the last 2 years by working together with a few professional UX folks. However, I'm not a person with UX studies/certifications. I just hope to show you the experience of a new Linux user) -- Marius Andreiana From bnocera at redhat.com Fri Sep 18 21:40:02 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 18 Sep 2009 22:40:02 +0100 Subject: NetworkManager & keyring In-Reply-To: <4bcf41a00909181219l38530222tf847710b2b5ee580@mail.gmail.com> References: <4bcf41a00909181219l38530222tf847710b2b5ee580@mail.gmail.com> Message-ID: <1253310002.18963.4758.camel@localhost.localdomain> On Fri, 2009-09-18 at 22:19 +0300, Marius Andreiana wrote: > After a few days of using a fresh F11 setup, upon login I was told > nm-applet wants to access default keyring, but it's locked. Enter > password. > > Hm. Don't know what password. Tried my account and root password, no > luck. Searched help for how to change keyring password, nope. > Ah, found Preferences -> Encryption and Keyrings, that will help. Uhm... no. > > Tried a restart, same question. Tried to add another network > connection to get my net working, but still NM wants to know the > default keyring password. I want that too :) Finally I tried my > initial account password used on install (which I changed a few days > later), that was it! That means there was a problem with your installation. Changing the user's password is supposed to change the default GNOME keyring password to match as well. in /etc/pam.d/passwd: -password optional pam_gnome_keyring.so So, how did you change your password? > Could this behaviour be changed to: when a keyring needs to be setup, > prompt user with a dialog explaining what a keyring is and ask for a > password. Huh. > (about my recent posts - I've been influenced in the last 2 years by > working together with a few professional UX folks. However, I'm not a > person with UX studies/certifications. I just hope to show you the > experience of a new Linux user) From bnocera at redhat.com Fri Sep 18 21:40:52 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 18 Sep 2009 22:40:52 +0100 Subject: kill Preferences -> GL Desktop? In-Reply-To: <4bcf41a00909181208w65696d5fl5157dac14ba1193f@mail.gmail.com> References: <4bcf41a00909181208w65696d5fl5157dac14ba1193f@mail.gmail.com> Message-ID: <1253310052.18963.4761.camel@localhost.localdomain> On Fri, 2009-09-18 at 22:08 +0300, Marius Andreiana wrote: > Didn't know what GL Desktop is, so I clicked it. I was already using > compiz, with preferences set in Compiz Settings Manager (ccsm). > > On start, GL Desktop says > An error occurred while loading or saving configuration information > for gnome-compiz-preferences. Some of your configuration settings may > not work properly. > > Seems it has a subset of Compiz Settings Manager options. Why does GL > Desktop still need to be kept? We don't ship it by default. If we do, it's a packaging error. Cheers From mandreiana.lists at gmail.com Sat Sep 19 09:44:42 2009 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Sat, 19 Sep 2009 12:44:42 +0300 Subject: kill Preferences -> GL Desktop? In-Reply-To: <1253310052.18963.4761.camel@localhost.localdomain> References: <4bcf41a00909181208w65696d5fl5157dac14ba1193f@mail.gmail.com> <1253310052.18963.4761.camel@localhost.localdomain> Message-ID: <4bcf41a00909190244h448df692se4de6ec918f5f892@mail.gmail.com> On Sat, Sep 19, 2009 at 12:40 AM, Bastien Nocera wrote: > On Fri, 2009-09-18 at 22:08 +0300, Marius Andreiana wrote: >> Seems it has a subset of Compiz Settings Manager options. Why does GL >> Desktop still need to be kept? > > We don't ship it by default. If we do, it's a packaging error. Then I must have installed it as part of a howto Available Packages gnome-compiz-manager.i586 0.10.4-8.fc11 fedora -- Marius Andreiana From drago01 at gmail.com Sat Sep 19 09:46:40 2009 From: drago01 at gmail.com (drago01) Date: Sat, 19 Sep 2009 11:46:40 +0200 Subject: kill Preferences -> GL Desktop? In-Reply-To: <4bcf41a00909190244h448df692se4de6ec918f5f892@mail.gmail.com> References: <4bcf41a00909181208w65696d5fl5157dac14ba1193f@mail.gmail.com> <1253310052.18963.4761.camel@localhost.localdomain> <4bcf41a00909190244h448df692se4de6ec918f5f892@mail.gmail.com> Message-ID: On Sat, Sep 19, 2009 at 11:44 AM, Marius Andreiana wrote: > On Sat, Sep 19, 2009 at 12:40 AM, Bastien Nocera wrote: >> On Fri, 2009-09-18 at 22:08 +0300, Marius Andreiana wrote: >>> Seems it has a subset of Compiz Settings Manager options. Why does GL >>> Desktop still need to be kept? >> >> We don't ship it by default. If we do, it's a packaging error. > Then I must have installed it as part of a howto > Available Packages > gnome-compiz-manager.i586 ? ? ? ? ? ? ? ? ?0.10.4-8.fc11 ? ? ? ? ? ? ? ? ?fedora This package has do die, it does not support current compiz builds and did not do this for a while now, also it seems dead upstream. From mandreiana.lists at gmail.com Sat Sep 19 09:47:08 2009 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Sat, 19 Sep 2009 12:47:08 +0300 Subject: NetworkManager & keyring In-Reply-To: <1253310002.18963.4758.camel@localhost.localdomain> References: <4bcf41a00909181219l38530222tf847710b2b5ee580@mail.gmail.com> <1253310002.18963.4758.camel@localhost.localdomain> Message-ID: <4bcf41a00909190247g4cc593besb0c49f8dc659e9e9@mail.gmail.com> >> Tried a restart, same question. Tried to add another network >> connection to get my net working, but still NM wants to know the >> default keyring password. I want that too :) Finally I tried my >> initial account password used on install (which I changed a few days >> later), that was it! > > That means there was a problem with your installation. Changing the > user's password is supposed to change the default GNOME keyring password > to match as well. > > in /etc/pam.d/passwd: > -password ? optional ? ?pam_gnome_keyring.so > > So, how did you change your password? as root: passwd user So why not ask (or hint about) your account password, rather than default keyring password? >> Could this behaviour be changed to: when a keyring needs to be setup, >> prompt user with a dialog explaining what a keyring is and ask for a >> password. > > Huh. -- Marius Andreiana From mandreiana.lists at gmail.com Sun Sep 20 12:46:46 2009 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Sun, 20 Sep 2009 15:46:46 +0300 Subject: logging out from keyboard / logout UX In-Reply-To: <4bcf41a00909181156u456aee2aw1b61f14e59d2a15e@mail.gmail.com> References: <4bcf41a00909181156u456aee2aw1b61f14e59d2a15e@mail.gmail.com> Message-ID: <4bcf41a00909200546s283dbe3ci8dd615a00b20d745@mail.gmail.com> Hi, Trying to log out from the default keyboard shortcut, but can't :) (see attached). Besides the Log out dialog not having a Log out button, I don't know what Cancel does in the middle of the other choices. I also attached the Win 7 ctrl+alt+del dialog, their UX is quite good this time (will send as a separate attach, my initial message still awaits moderator approval). Could it be used as an inspiration? PS: While processing the image with GIMP, on a save dialog I also saw Cancel in the middle of other choices. I've been away from Linux for 2 years, hope this isn't the new standard. -- Marius Andreiana -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.jpg Type: image/jpeg Size: 83905 bytes Desc: not available URL: From mandreiana.lists at gmail.com Mon Sep 21 12:54:32 2009 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Mon, 21 Sep 2009 15:54:32 +0300 Subject: logging out from keyboard / logout UX In-Reply-To: <4bcf41a00909181156u456aee2aw1b61f14e59d2a15e@mail.gmail.com> References: <4bcf41a00909181156u456aee2aw1b61f14e59d2a15e@mail.gmail.com> Message-ID: <4bcf41a00909210554q6939fca6kf14e03affb587259@mail.gmail.com> Hi, Trying to log out from the default keyboard shortcut, but can't :) see http://tinypic.com/r/29gbvc/4 Besides the Log out dialog not having a Log out button, I don't know what Cancel does in the middle of the other choices. I also attached the Win 7 ctrl+alt+del dialog, their UX is quite good this time: http://tinypic.com/r/w7cvn8/4 Could it be used as an inspiration? PS: While processing the image with GIMP, on a save dialog I also saw Cancel in the middle of other choices. I've been away from Linux for 2 years, is this a new standard? -- Marius Andreiana -- Marius Andreiana From mandreiana.lists at gmail.com Mon Sep 21 12:57:50 2009 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Mon, 21 Sep 2009 15:57:50 +0300 Subject: GDM Login Screen In-Reply-To: <4A70556A.7040108@gmail.com> References: <4A700C9A.9000009@gmail.com> <1248867824.1533.1.camel@planemask> <4A7053C0.9060908@hi.is> <4A70551F.7060101@nicubunu.ro> <4A70556A.7040108@gmail.com> Message-ID: <4bcf41a00909210557k4bda593fg85a86316bde6ad3a@mail.gmail.com> On Wed, Jul 29, 2009 at 4:58 PM, Frank Murphy wrote: > On 29/07/09 14:56, Nicu Buculei wrote: >> > >>> >>> How many users do you think exist on a desktop installed from a livecd I >>> would say no more than four ( parents + 2 children ) more realistic >>> sample only 2 persons or single account ( an couple/individual ) So why >>> not get rid of "other" and show always all created user account.. >> >> Maybe not "always", but when the created accounts are less than 4, it >> make sense to get rid of "other", which is confusing in those cases. >> > > +1 Nicu, will you please fill an ER with this in bugzilla, in order to get implemented? -- Marius Andreiana From nicu_fedora at nicubunu.ro Mon Sep 21 13:25:25 2009 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 21 Sep 2009 16:25:25 +0300 Subject: GDM Login Screen In-Reply-To: <4bcf41a00909210557k4bda593fg85a86316bde6ad3a@mail.gmail.com> References: <4A700C9A.9000009@gmail.com> <1248867824.1533.1.camel@planemask> <4A7053C0.9060908@hi.is> <4A70551F.7060101@nicubunu.ro> <4A70556A.7040108@gmail.com> <4bcf41a00909210557k4bda593fg85a86316bde6ad3a@mail.gmail.com> Message-ID: <4AB77EC5.9030307@nicubunu.ro> On 09/21/2009 03:57 PM, Marius Andreiana wrote: > On Wed, Jul 29, 2009 at 4:58 PM, Frank Murphy wrote: >> On 29/07/09 14:56, Nicu Buculei wrote: >>>> How many users do you think exist on a desktop installed from a livecd I >>>> would say no more than four ( parents + 2 children ) more realistic >>>> sample only 2 persons or single account ( an couple/individual ) So why >>>> not get rid of "other" and show always all created user account.. >>> >>> Maybe not "always", but when the created accounts are less than 4, it >>> make sense to get rid of "other", which is confusing in those cases. >> >> +1 > Nicu, will you please fill an ER with this in bugzilla, in order to > get implemented? The place for such a feature request is not Fedora bugzilla, but upstream GNOME, that is the right place to ask for it. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ From notting at redhat.com Mon Sep 21 15:09:12 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 Sep 2009 11:09:12 -0400 Subject: kill Preferences -> GL Desktop? In-Reply-To: References: <4bcf41a00909181208w65696d5fl5157dac14ba1193f@mail.gmail.com> <1253310052.18963.4761.camel@localhost.localdomain> <4bcf41a00909190244h448df692se4de6ec918f5f892@mail.gmail.com> Message-ID: <20090921150912.GB5770@nostromo.devel.redhat.com> drago01 (drago01 at gmail.com) said: > >> We don't ship it by default. If we do, it's a packaging error. > > Then I must have installed it as part of a howto > > Available Packages > > gnome-compiz-manager.i586 ? ? ? ? ? ? ? ? ?0.10.4-8.fc11 ? ? ? ? ? ? ? ? ?fedora > > This package has do die, it does not support current compiz builds and > did not do this for a while now, also it seems dead upstream. Send mail to rel-eng? Bill From mclasen at redhat.com Mon Sep 21 17:17:13 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 21 Sep 2009 13:17:13 -0400 Subject: A less cluttered desktop In-Reply-To: <4bcf41a00909181141l15f3a88erc79e57e4b62f965a@mail.gmail.com> References: <1248299783.1588.17.camel@planemask> <1248458989.3119.47.camel@metroid> <1248461347.16860.2.camel@planemask> <1248571032.1432.1.camel@planemask> <1248706315.3119.55.camel@metroid> <1248712492.1535.30.camel@planemask> <4bcf41a00909181141l15f3a88erc79e57e4b62f965a@mail.gmail.com> Message-ID: <1253553433.1725.24.camel@planemask> On Fri, 2009-09-18 at 21:41 +0300, Marius Andreiana wrote: > > As another person asked, what is the rationale for this change? There are too many icons. That makes it much harder for artists to provide complete, consistent themes. It also gives the desktop a cluttered, overloaded appearance. From mandreiana.lists at gmail.com Wed Sep 23 13:04:58 2009 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Wed, 23 Sep 2009 16:04:58 +0300 Subject: GDM Login Screen In-Reply-To: <4AB77EC5.9030307@nicubunu.ro> References: <4A700C9A.9000009@gmail.com> <1248867824.1533.1.camel@planemask> <4A7053C0.9060908@hi.is> <4A70551F.7060101@nicubunu.ro> <4A70556A.7040108@gmail.com> <4bcf41a00909210557k4bda593fg85a86316bde6ad3a@mail.gmail.com> <4AB77EC5.9030307@nicubunu.ro> Message-ID: <4bcf41a00909230604p787eae9by49118416dcce6c34@mail.gmail.com> On Mon, Sep 21, 2009 at 4:25 PM, Nicu Buculei wrote: > On 09/21/2009 03:57 PM, Marius Andreiana wrote: >> On Wed, Jul 29, 2009 at 4:58 PM, Frank Murphy wrote: >>> On 29/07/09 14:56, Nicu Buculei wrote: >>>>> How many users do you think exist on a desktop installed from a livecd I >>>>> would say no more than four ( parents + 2 children ) more realistic >>>>> sample only 2 persons or single account ( an couple/individual ) So why >>>>> not get rid of "other" and show always all created user account.. >>>> >>>> Maybe not "always", but when the created accounts are less than 4, it >>>> make sense to get rid of "other", which is confusing in those cases. >>> >>> +1 >> Nicu, will you please fill an ER with this in bugzilla, in order to >> get implemented? > > The place for such a feature request is not Fedora bugzilla, but > upstream GNOME, that is the right place to ask for it. Is somebody (Nicu?) volunteering to drive this? E.g. put an ER in GNOME bugzilla or write to a specific GNOME list The solution found above sounds good to all this list, we also need to make sure it gets implemented. -- Marius Andreiana From mclasen at redhat.com Fri Sep 25 00:48:54 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 24 Sep 2009 20:48:54 -0400 Subject: A new notification theme Message-ID: <1253839734.1690.51.camel@planemask> Tomorrows rawhide will have a new notification theme for Gnome. The aim of this new theme is to integrate well with the theming in the rest of the desktop (which wasn't really the case with nodoka bubbles and a clearlooks desktop). Let me know how the new bubbles work for you; this is the initial release, so there is probably some fine-tuning left to do. In other bubble news, the amount of notifications that get emitted by NM, g-p-m and packagekit should be noticeably reduced, compared to F11. Matthias From walters at verbum.org Fri Sep 25 00:55:07 2009 From: walters at verbum.org (Colin Walters) Date: Thu, 24 Sep 2009 20:55:07 -0400 Subject: A new notification theme In-Reply-To: <1253839734.1690.51.camel@planemask> References: <1253839734.1690.51.camel@planemask> Message-ID: On Thu, Sep 24, 2009 at 8:48 PM, Matthias Clasen wrote: > > In other bubble news, the amount of notifications that get emitted by > NM, g-p-m and packagekit should be noticeably reduced, compared to F11. \o/ Is all I have to say. From tiagomatos at gmail.com Fri Sep 25 08:23:37 2009 From: tiagomatos at gmail.com (=?UTF-8?Q?Rui_Tiago_Ca=C3=A7=C3=A3o_Matos?=) Date: Fri, 25 Sep 2009 09:23:37 +0100 Subject: A new notification theme In-Reply-To: <1253839734.1690.51.camel@planemask> References: <1253839734.1690.51.camel@planemask> Message-ID: 2009/9/25 Matthias Clasen : > Tomorrows rawhide will have a new notification theme for Gnome. > > The aim of this new theme is to integrate well with the theming in the > rest of the desktop (which wasn't really the case with nodoka bubbles > and a clearlooks desktop). I'll have to try it later. One thing that the F11 theme didn't get right is that when using a GTK+ theme with text (dark themes) it is unreadable due to the bubble's light yellow background. Anyway, if there are less notifications it's not much of a problem anymore :-) Rui From martin.sourada at gmail.com Fri Sep 25 09:04:41 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Fri, 25 Sep 2009 11:04:41 +0200 Subject: A new notification theme In-Reply-To: References: <1253839734.1690.51.camel@planemask> Message-ID: <1253869481.2257.7.camel@pc-notebook.kolej.mff.cuni.cz> On Fri, 2009-09-25 at 09:23 +0100, Rui Tiago Ca??o Matos wrote: > 2009/9/25 Matthias Clasen : > > Tomorrows rawhide will have a new notification theme for Gnome. > > > > The aim of this new theme is to integrate well with the theming in the > > rest of the desktop (which wasn't really the case with nodoka bubbles > > and a clearlooks desktop). > Do you have a screen-shot anywhere? I hope it's not a step back to the original ugly plain-color engine which does not fit with Clearlooks any better than the Nodoka one does... I cannot check for myself since I'm still unable to install Rawhide on my machine :( > I'll have to try it later. One thing that the F11 theme didn't get > right is that when using a GTK+ theme with text (dark themes) it is > unreadable due to the bubble's light yellow background. > This has been fixed in rawhide already (see rhbz 498422), but I haven't pushed it back to sable releases because it also changes the colour for default theme and I don't have any idea how to fix that... > Anyway, if there are less notifications it's not much of a problem anymore :-) > > Rui Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From martin.sourada at gmail.com Fri Sep 25 09:31:12 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Fri, 25 Sep 2009 11:31:12 +0200 Subject: A new notification theme In-Reply-To: <1253839734.1690.51.camel@planemask> References: <1253839734.1690.51.camel@planemask> Message-ID: <1253871073.2257.20.camel@pc-notebook.kolej.mff.cuni.cz> On Thu, 2009-09-24 at 20:48 -0400, Matthias Clasen wrote: > Tomorrows rawhide will have a new notification theme for Gnome. > > The aim of this new theme is to integrate well with the theming in the > rest of the desktop (which wasn't really the case with nodoka bubbles > and a clearlooks desktop). > > Let me know how the new bubbles work for you; this is the initial > release, so there is probably some fine-tuning left to do. Ok, so some observation from installing it on F11 (I have newer gtk already there because I need it for new webkitgtk, so no problem...): it inverts colours (the engine itself, not via theme gtkrc, that's understandable though, given that it seems impossible [or at least I don't know how] to target specifically the notify bubbles in theme gtkrc...), while it looks nice for bright themes on darkish desktop, it would look at least odd with dark themes. Also the bright clearlooks close button clashes with other buttons design and the overal dark theme. Now for some functional problems: the position is wrong if "displayed with arrow". Instead of repositioning correctly with respect to screen, it is placed with it's top-left corner where the imaginary arrow should start and thus usually ends up out of screen when the arrow starts at notification area. Also it ignores urgency. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Fri Sep 25 10:17:48 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 25 Sep 2009 11:17:48 +0100 Subject: A new notification theme In-Reply-To: <1253871073.2257.20.camel@pc-notebook.kolej.mff.cuni.cz> References: <1253839734.1690.51.camel@planemask> <1253871073.2257.20.camel@pc-notebook.kolej.mff.cuni.cz> Message-ID: <1253873868.2093.2100.camel@localhost.localdomain> On Fri, 2009-09-25 at 11:31 +0200, Martin Sourada wrote: > Now for some functional problems: the position is wrong if "displayed > with arrow". Instead of repositioning correctly with respect to screen, > it is placed with it's top-left corner where the imaginary arrow should > start and thus usually ends up out of screen when the arrow starts at > notification area. Update the notification-daemon for that to work. Cheers From martin.sourada at gmail.com Fri Sep 25 11:45:13 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Fri, 25 Sep 2009 13:45:13 +0200 Subject: A new notification theme In-Reply-To: <1253873868.2093.2100.camel@localhost.localdomain> References: <1253839734.1690.51.camel@planemask> <1253871073.2257.20.camel@pc-notebook.kolej.mff.cuni.cz> <1253873868.2093.2100.camel@localhost.localdomain> Message-ID: <1253879113.2257.23.camel@pc-notebook.kolej.mff.cuni.cz> On Fri, 2009-09-25 at 11:17 +0100, Bastien Nocera wrote: > On Fri, 2009-09-25 at 11:31 +0200, Martin Sourada wrote: > > > Now for some functional problems: the position is wrong if "displayed > > with arrow". Instead of repositioning correctly with respect to screen, > > it is placed with it's top-left corner where the imaginary arrow should > > start and thus usually ends up out of screen when the arrow starts at > > notification area. > > Update the notification-daemon for that to work. > Indeed, updating n-d to f12 version fixes this and surprisingly does not break the case when the arrow is actually present (like in nodoka or standard engine)... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Fri Sep 25 15:27:25 2009 From: poelstra at redhat.com (John Poelstra) Date: Fri, 25 Sep 2009 08:27:25 -0700 Subject: A new notification theme In-Reply-To: <1253839734.1690.51.camel@planemask> References: <1253839734.1690.51.camel@planemask> Message-ID: <4ABCE15D.2090900@redhat.com> Matthias Clasen said the following on 09/24/2009 05:48 PM Pacific Time: > Tomorrows rawhide will have a new notification theme for Gnome. > > The aim of this new theme is to integrate well with the theming in the > rest of the desktop (which wasn't really the case with nodoka bubbles > and a clearlooks desktop). > > Let me know how the new bubbles work for you; this is the initial > release, so there is probably some fine-tuning left to do. > I confess up front to not understanding the full ramifications or risks of changing notifications at this point in the release cycle. Why are we making this change now (right before the final freeze) when Feature freeze was almost two months ago. Why can't this wait for Fedora 13? John From mclasen at redhat.com Fri Sep 25 17:10:57 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 25 Sep 2009 13:10:57 -0400 Subject: A new notification theme In-Reply-To: <4ABCE15D.2090900@redhat.com> References: <1253839734.1690.51.camel@planemask> <4ABCE15D.2090900@redhat.com> Message-ID: <1253898658.1743.1.camel@planemask> On Fri, 2009-09-25 at 08:27 -0700, John Poelstra wrote: > Matthias Clasen said the following on 09/24/2009 05:48 PM Pacific Time: > > Tomorrows rawhide will have a new notification theme for Gnome. > > > > The aim of this new theme is to integrate well with the theming in the > > rest of the desktop (which wasn't really the case with nodoka bubbles > > and a clearlooks desktop). > > > > Let me know how the new bubbles work for you; this is the initial > > release, so there is probably some fine-tuning left to do. > > > > > I confess up front to not understanding the full ramifications or risks > of changing notifications at this point in the release cycle. Why are > we making this change now (right before the final freeze) when Feature > freeze was almost two months ago. Why can't this wait for Fedora 13? We are making it before the beta freeze. We are changing a theme, so this is relatively low risk. And we are changing it now because we want F12 to look polished. From stickster at gmail.com Sat Sep 26 12:33:31 2009 From: stickster at gmail.com (Paul Frields) Date: Sat, 26 Sep 2009 08:33:31 -0400 Subject: A new notification theme In-Reply-To: <1253898658.1743.1.camel@planemask> References: <1253839734.1690.51.camel@planemask> <4ABCE15D.2090900@redhat.com> <1253898658.1743.1.camel@planemask> Message-ID: On Fri, Sep 25, 2009 at 1:10 PM, Matthias Clasen wrote: > On Fri, 2009-09-25 at 08:27 -0700, John Poelstra wrote: >> Matthias Clasen said the following on 09/24/2009 05:48 PM Pacific Time: >> > Tomorrows rawhide will have a new notification theme for Gnome. >> > >> > The aim of this new theme is to integrate well with the theming in the >> > rest of the desktop (which wasn't really the case with nodoka bubbles >> > and a clearlooks desktop). >> > >> > Let me know how the new bubbles work for you; this is the initial >> > release, so there is probably some fine-tuning left to do. >> > >> >> >> I confess up front to not understanding the full ramifications or risks >> of changing notifications at this point in the release cycle. ?Why are >> we making this change now (right before the final freeze) when Feature >> freeze was almost two months ago. ?Why can't this wait for Fedora 13? > > We are making it before the beta freeze. We are changing a theme, so > this is relatively low risk. And we are changing it now because we want > F12 to look polished. It does seem like a pretty minor change and very low risk. But all black? Really? OK, it does get my attention faster, so I'll give you that one. However, the interactive bits (buttons in a bubble) are inconsistent. https://bugzilla.redhat.com/show_bug.cgi?id=525864 Also, there doesn't seem to be any difference between low, normal, and critical urgency notifications any longer. https://bugzilla.redhat.com/show_bug.cgi?id=525867 Paul From christoph.wickert at googlemail.com Tue Sep 29 13:00:21 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Tue, 29 Sep 2009 15:00:21 +0200 Subject: A new notification theme In-Reply-To: <1253839734.1690.51.camel@planemask> References: <1253839734.1690.51.camel@planemask> Message-ID: <1254229221.2884.157.camel@localhost> Am Donnerstag, den 24.09.2009, 20:48 -0400 schrieb Matthias Clasen: > Tomorrows rawhide will have a new notification theme for Gnome. > > The aim of this new theme is to integrate well with the theming in the > rest of the desktop (which wasn't really the case with nodoka bubbles > and a clearlooks desktop). After I have seen them now I can say I think they are horrible. We could really argue if the Nodoka bubbles matched the rest of Nodoka, but this definitely matches even less. I think such changes shouldn't been done as a solo action without previous notice. Has the design team been aked about this? (No, Matthias and Jon, you are *not* the design team, sorry). Or people from the desktop SIG? How about other contributors? IMHO this change is also very ungrateful to Martin, who does an amazing job with the Nodoka theme. Regards, Christoph From mclasen at redhat.com Tue Sep 29 13:20:18 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 29 Sep 2009 09:20:18 -0400 Subject: A new notification theme In-Reply-To: <1254229221.2884.157.camel@localhost> References: <1253839734.1690.51.camel@planemask> <1254229221.2884.157.camel@localhost> Message-ID: <1254230418.1671.12.camel@planemask> On Tue, 2009-09-29 at 15:00 +0200, Christoph Wickert wrote: > Am Donnerstag, den 24.09.2009, 20:48 -0400 schrieb Matthias Clasen: > > Tomorrows rawhide will have a new notification theme for Gnome. > > > > The aim of this new theme is to integrate well with the theming in the > > rest of the desktop (which wasn't really the case with nodoka bubbles > > and a clearlooks desktop). > > After I have seen them now I can say I think they are horrible. We could > really argue if the Nodoka bubbles matched the rest of Nodoka, but this > definitely matches even less. > > I think such changes shouldn't been done as a solo action without > previous notice. Has the design team been aked about this? (No, Matthias > and Jon, you are *not* the design team, sorry). Or people from the > desktop SIG? How about other contributors? The design team is busy doing backgrounds. We _are_ doing the design of the desktop spin, whether you like it or not. Just like I expect you to do the design of the Xfce spin, and the KDE team to do the design of their product. > IMHO this change is also very ungrateful to Martin, who does an amazing > job with the Nodoka theme. Yes, he is doing a great job with the Nodoka theme. How does that imply that we are ungrateful by not sticking with it forever ? From martin.sourada at gmail.com Tue Sep 29 14:19:47 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Tue, 29 Sep 2009 16:19:47 +0200 Subject: A new notification theme In-Reply-To: <1254230418.1671.12.camel@planemask> References: <1253839734.1690.51.camel@planemask> <1254229221.2884.157.camel@localhost> <1254230418.1671.12.camel@planemask> Message-ID: <1254233987.23359.109.camel@pc-notebook.kolej.mff.cuni.cz> On Tue, 2009-09-29 at 09:20 -0400, Matthias Clasen wrote: > The design team is busy doing backgrounds. The design team is doing more than just backgrounds and not everyone there is busy with doing the backgrounds. The design team is also helping with the websites design, various UI designs,... Please do not oversimplify what the design team actually does ;-) > We _are_ doing the design of the desktop spin, whether you like it or > not. Just like I expect you to do the design of the Xfce spin, and the > KDE team to do the design of their product. > I expect you to do the final selections, not the design itself -- you have the design team (the fedora one and the one at upstream) to help with that and it would be nice if you at least consulted with us when you are doing changes that are diverging from upstream defaults (I can accept that when you decide to stick with upstream defaults you don't need to hear fedora design team opinion about that). > > IMHO this change is also very ungrateful to Martin, who does an amazing > > job with the Nodoka theme. > > Yes, he is doing a great job with the Nodoka theme. > > How does that imply that we are ungrateful by not sticking with it > forever ? Yup, I don't feel that what Jon and you have done is being ungrateful to me. I've made the needed first step with providing actually good looking alternative to the bland default engine (speaking now about the notification-daemon only) and I am actually grateful that its being replaced by something that is nice, instead of reverting back to the ugly defaults. From time to time, changes are good thing. But come to thing of it, now that the alternatives are starting to "pile up", it would be actually great to have means to select the theme (other way than via whole-gnome-desktop-theme or gconf). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Tue Sep 29 14:28:17 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 29 Sep 2009 10:28:17 -0400 Subject: A new notification theme In-Reply-To: <1254233987.23359.109.camel@pc-notebook.kolej.mff.cuni.cz> References: <1253839734.1690.51.camel@planemask> <1254229221.2884.157.camel@localhost> <1254230418.1671.12.camel@planemask> <1254233987.23359.109.camel@pc-notebook.kolej.mff.cuni.cz> Message-ID: <1254234497.1654.7.camel@planemask> On Tue, 2009-09-29 at 16:19 +0200, Martin Sourada wrote: > On Tue, 2009-09-29 at 09:20 -0400, Matthias Clasen wrote: > > The design team is busy doing backgrounds. > The design team is doing more than just backgrounds and not everyone > there is busy with doing the backgrounds. The design team is also > helping with the websites design, various UI designs,... Please do not > oversimplify what the design team actually does ;-) Yeah, sorry. I was oversimplifying here. > > But come to thing of it, now that the alternatives are starting to "pile > up", it would be actually great to have means to select the theme (other > way than via whole-gnome-desktop-theme or gconf). You mean individual theme components in general, or notification themes, specifically ? For individual theme components, the appearance capplet has the "Customize" dialog which lets you change various components individually. That doesn't include notification themes though. The notification daemon includes a separate theme-switching dialog, which we don't include in our package, because it is not really worth a separate menuitem. If somebody feels inclined to work on it, it is probably doable to add a notification tab to the Customize dialog. I don't think it is a high priority though. And with gnome-shell, separate notification themes may go away altogether. Matthias From martin.sourada at gmail.com Tue Sep 29 14:48:14 2009 From: martin.sourada at gmail.com (Martin Sourada) Date: Tue, 29 Sep 2009 16:48:14 +0200 Subject: A new notification theme In-Reply-To: <1254234497.1654.7.camel@planemask> References: <1253839734.1690.51.camel@planemask> <1254229221.2884.157.camel@localhost> <1254230418.1671.12.camel@planemask> <1254233987.23359.109.camel@pc-notebook.kolej.mff.cuni.cz> <1254234497.1654.7.camel@planemask> Message-ID: <1254235694.23359.119.camel@pc-notebook.kolej.mff.cuni.cz> On Tue, 2009-09-29 at 10:28 -0400, Matthias Clasen wrote: > On Tue, 2009-09-29 at 16:19 +0200, Martin Sourada wrote: > > But come to thing of it, now that the alternatives are starting to "pile > > up", it would be actually great to have means to select the theme (other > > way than via whole-gnome-desktop-theme or gconf). > > You mean individual theme components in general, or notification themes, > specifically ? > The notification themes specifically. > For individual theme components, the appearance capplet has the > "Customize" dialog which lets you change various components > individually. > Yup, I know ;-) > That doesn't include notification themes though. The notification daemon > includes a separate theme-switching dialog, which we don't include in > our package, because it is not really worth a separate menuitem. If > somebody feels inclined to work on it, it is probably doable to add a > notification tab to the Customize dialog. I don't think it is a high > priority though. And with gnome-shell, separate notification themes may > go away altogether. > Aah, I read something about that at gnome planet but didn't know where to actually find it. In the appearance capplet it would be probably better off. As about the gnome-shell -- I'm still a bit sceptic whether it's a step a forward or just a hindrance (I haven't tried it myself yet and available screen-casts are suggesting the later...), but to stay on topic, I don't like the idea of notify bubbles being inthemable, or am I misunderstanding and the bubbles will be themable as a part of some bigger component? Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From drago01 at gmail.com Tue Sep 29 15:06:06 2009 From: drago01 at gmail.com (drago01) Date: Tue, 29 Sep 2009 17:06:06 +0200 Subject: A new notification theme In-Reply-To: <1254235694.23359.119.camel@pc-notebook.kolej.mff.cuni.cz> References: <1253839734.1690.51.camel@planemask> <1254229221.2884.157.camel@localhost> <1254230418.1671.12.camel@planemask> <1254233987.23359.109.camel@pc-notebook.kolej.mff.cuni.cz> <1254234497.1654.7.camel@planemask> <1254235694.23359.119.camel@pc-notebook.kolej.mff.cuni.cz> Message-ID: On Tue, Sep 29, 2009 at 4:48 PM, Martin Sourada wrote: > On Tue, 2009-09-29 at 10:28 -0400, Matthias Clasen wrote: >> On Tue, 2009-09-29 at 16:19 +0200, Martin Sourada wrote: >> > But come to thing of it, now that the alternatives are starting to "pile >> > up", it would be actually great to have means to select the theme (other >> > way than via whole-gnome-desktop-theme or gconf). >> >> You mean individual theme components in general, or notification themes, >> specifically ? >> > The notification themes specifically. > >> For individual theme components, the appearance capplet has the >> "Customize" dialog which lets you change various components >> individually. >> > Yup, I know ;-) > >> That doesn't include notification themes though. The notification daemon >> includes a separate theme-switching dialog, which we don't include in >> our package, because it is not really worth a separate menuitem. If >> somebody feels inclined to work on it, it is probably doable to add a >> notification tab to the Customize dialog. I don't think it is a high >> priority though. And with gnome-shell, separate notification themes may >> go away altogether. >> > Aah, I read something about that at gnome planet but didn't know where > to actually find it. In the appearance capplet it would be probably > better off. As about the gnome-shell -- I'm still a bit sceptic whether > it's a step a forward or just a hindrance (I haven't tried it myself yet > and available screen-casts are suggesting the later...), but to stay on > topic, I don't like the idea of notify bubbles being inthemable, or am I > misunderstanding and the bubbles will be themable as a part of some > bigger component? http://blogs.gnome.org/mccann/2009/07/05/getting-the-message/ From william.jon.mccann at gmail.com Tue Sep 29 15:13:58 2009 From: william.jon.mccann at gmail.com (William Jon McCann) Date: Tue, 29 Sep 2009 11:13:58 -0400 Subject: A new notification theme In-Reply-To: <1254229221.2884.157.camel@localhost> References: <1253839734.1690.51.camel@planemask> <1254229221.2884.157.camel@localhost> Message-ID: <939dd5750909290813v371b8bd0h80905cd5cd5d080c@mail.gmail.com> Hi Christoph, On Tue, Sep 29, 2009 at 9:00 AM, Christoph Wickert wrote: > Am Donnerstag, den 24.09.2009, 20:48 -0400 schrieb Matthias Clasen: >> Tomorrows rawhide will have a new notification theme for Gnome. >> >> The aim of this new theme is to integrate well with the theming in the >> rest of the desktop (which wasn't really the case with nodoka bubbles >> and a clearlooks desktop). > > After I have seen them now I can say I think they are horrible. We could > really argue if the Nodoka bubbles matched the rest of Nodoka, but this > definitely matches even less. > > I think such changes shouldn't been done as a solo action without > previous notice. Has the design team been aked about this? (No, Matthias > and Jon, you are *not* the design team, sorry). Or people from the > desktop SIG? How about other contributors? > > IMHO this change is also very ungrateful to Martin, who does an amazing > job with the Nodoka theme. So, this message is clearly a troll but I'd like to respond to a few things anyway. If you have any substantial and specific critique of the theme I'd love to hear it. We are the people involved in designing the desktop product. Anyone may contribute to that but there is no magic design team that needs to be consulted before we make changes. There are people that I think are very good at what they do and I consult them as much as possible. In this case in particular, there were a few different people I consulted. But if you wish to put labels on things - yes we are the desktop design team. I have no idea why anyone would think that we're ungrateful to Martin because of this. I'm pretty sure Martin wouldn't think this either. However, he probably doesn't prefer the new design over his - why would he? There are going to be differences in opinion like this. It is only natural. He has been notably constructive in his messages so far. At the end of the day we need to stand up and take responsibility for the end result. To make sure things fit together coherently. That doesn't mean that these decisions occur in a vacuum or that we don't need a heck of a lot of help. Nothing is ever final. For now, Matthias and I have assumed the (often difficult) responsibility of trying to fit all our shit together in a way that doesn't totally suck. We *do* need your help to do that. But that doesn't mean that we're going to avoid making the often difficult choices - it is critical that we do. So, let's try to keep focus on what we are all trying to achieve here. By the way have you tried the latest Ubuntu nightly? It isn't half bad. Snow Leopard? Doesn't suck. Windows 7 - yeah I could use that. Jon From notting at redhat.com Tue Sep 29 18:12:52 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 29 Sep 2009 14:12:52 -0400 Subject: long running sessions, restarts, etc. Message-ID: <20090929181250.GA17613@nostromo.devel.redhat.com> With the move to more mobile devices (laptops, etc.), we're more likely to have very long-running sessions that are just suspended and resumed, as opposed to a workstation that is logged out every day. This means that for me on rawhide, my session is often much longer-lived than my software set, as I'll have a two-week session that is running older code that I've long since upgraded past. Even for those on an actual release, this can be an issue given our update stream. For system-level services, we have the idea of try-restart on upgrades; if the service is running, we automatically restart it on upgrade. How can we implement this sanely for session/desktop services? For example, in my session I see: gvfsd obex-client/obex-data-server evolution-data-server packagekitd notification-daemon any number of status icons (volume control, gpk, g-p-m, etc.) ... and more I'm forgetting ... Since very few of these have state, can't we implement a framework where they automatically get restarted on upgrade? Bill From drago01 at gmail.com Tue Sep 29 18:24:42 2009 From: drago01 at gmail.com (drago01) Date: Tue, 29 Sep 2009 20:24:42 +0200 Subject: long running sessions, restarts, etc. In-Reply-To: <20090929181250.GA17613@nostromo.devel.redhat.com> References: <20090929181250.GA17613@nostromo.devel.redhat.com> Message-ID: On Tue, Sep 29, 2009 at 8:12 PM, Bill Nottingham wrote: > With the move to more mobile devices (laptops, etc.), we're more likely to > have very long-running sessions that are just suspended and resumed, as > opposed to a workstation that is logged out every day. > > This means that for me on rawhide, my session is often much longer-lived than my > software set, as I'll have a two-week session that is running older code > that I've long since upgraded past. Even for those on an actual release, > this can be an issue given our update stream. > > For system-level services, we have the idea of try-restart on upgrades; if > the service is running, we automatically restart it on upgrade. How can > we implement this sanely for session/desktop services? For example, in > my session I see: > > gvfsd Wouldn't this affect current mounts? From dmalcolm at redhat.com Tue Sep 29 18:33:51 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 29 Sep 2009 14:33:51 -0400 Subject: long running sessions, restarts, etc. In-Reply-To: <20090929181250.GA17613@nostromo.devel.redhat.com> References: <20090929181250.GA17613@nostromo.devel.redhat.com> Message-ID: <1254249231.21201.65.camel@radiator.bos.redhat.com> On Tue, 2009-09-29 at 14:12 -0400, Bill Nottingham wrote: > With the move to more mobile devices (laptops, etc.), we're more likely to > have very long-running sessions that are just suspended and resumed, as > opposed to a workstation that is logged out every day. > > This means that for me on rawhide, my session is often much longer-lived than my > software set, as I'll have a two-week session that is running older code > that I've long since upgraded past. Even for those on an actual release, > this can be an issue given our update stream. > > For system-level services, we have the idea of try-restart on upgrades; if > the service is running, we automatically restart it on upgrade. How can > we implement this sanely for session/desktop services? For example, in > my session I see: > > gvfsd > obex-client/obex-data-server > evolution-data-server > packagekitd > notification-daemon > any number of status icons (volume control, gpk, g-p-m, etc.) > ... and more I'm forgetting ... > > Since very few of these have state, can't we implement a framework where > they automatically get restarted on upgrade? Brainstorming: perhaps when rpm updates/deletes a file it could look at what processes are mapping that file (in particular ELF files), and thus build a list for a transaction of all PIDs that now have stale data (e.g. using old versions of a .so file that now has a security fix in the new on-disk version). No idea how to pass this information up through yum/PackageKit in a useful way though. Hope this is helpful Dave From skvidal at fedoraproject.org Tue Sep 29 18:40:25 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 29 Sep 2009 14:40:25 -0400 (EDT) Subject: long running sessions, restarts, etc. In-Reply-To: <1254249231.21201.65.camel@radiator.bos.redhat.com> References: <20090929181250.GA17613@nostromo.devel.redhat.com> <1254249231.21201.65.camel@radiator.bos.redhat.com> Message-ID: On Tue, 29 Sep 2009, David Malcolm wrote: >> gvfsd >> obex-client/obex-data-server >> evolution-data-server >> packagekitd >> notification-daemon >> any number of status icons (volume control, gpk, g-p-m, etc.) >> ... and more I'm forgetting ... >> >> Since very few of these have state, can't we implement a framework where >> they automatically get restarted on upgrade? > > Brainstorming: perhaps when rpm updates/deletes a file it could look at > what processes are mapping that file (in particular ELF files), and thus > build a list for a transaction of all PIDs that now have stale data > (e.g. using old versions of a .so file that now has a security fix in > the new on-disk version). > > No idea how to pass this information up through yum/PackageKit in a > useful way though. > at the risk of getting myself in trouble - you don't have to do it at the rpm layer... You could do it in yum or in a yum plugin and then not have to worry about propagating it up the stack. -sv From notting at redhat.com Tue Sep 29 18:42:17 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 29 Sep 2009 14:42:17 -0400 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> <1254249231.21201.65.camel@radiator.bos.redhat.com> Message-ID: <20090929184217.GA18841@nostromo.devel.redhat.com> Seth Vidal (skvidal at fedoraproject.org) said: > at the risk of getting myself in trouble - you don't have to do it > at the rpm layer... You could do it in yum or in a yum plugin and > then not have to worry about propagating it up the stack. The alternative is to have apps set inotify watches on their own binaries, I suppose. (There was something in Fedora that used to do this.) Bill From skvidal at fedoraproject.org Tue Sep 29 18:44:29 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 29 Sep 2009 14:44:29 -0400 (EDT) Subject: long running sessions, restarts, etc. In-Reply-To: <20090929184217.GA18841@nostromo.devel.redhat.com> References: <20090929181250.GA17613@nostromo.devel.redhat.com> <1254249231.21201.65.camel@radiator.bos.redhat.com> <20090929184217.GA18841@nostromo.devel.redhat.com> Message-ID: On Tue, 29 Sep 2009, Bill Nottingham wrote: > Seth Vidal (skvidal at fedoraproject.org) said: >> at the risk of getting myself in trouble - you don't have to do it >> at the rpm layer... You could do it in yum or in a yum plugin and >> then not have to worry about propagating it up the stack. > > The alternative is to have apps set inotify watches on their own > binaries, I suppose. (There was something in Fedora that used to > do this.) wow, that would be, umm, special. How well does inotify cope with THOUSANDS of watches? -sv From drago01 at gmail.com Tue Sep 29 18:46:24 2009 From: drago01 at gmail.com (drago01) Date: Tue, 29 Sep 2009 20:46:24 +0200 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> <1254249231.21201.65.camel@radiator.bos.redhat.com> <20090929184217.GA18841@nostromo.devel.redhat.com> Message-ID: On Tue, Sep 29, 2009 at 8:44 PM, Seth Vidal wrote: > > > On Tue, 29 Sep 2009, Bill Nottingham wrote: > >> Seth Vidal (skvidal at fedoraproject.org) said: >>> >>> at the risk of getting myself in trouble - you don't have to do it >>> at the rpm layer... You could do it in yum or in a yum plugin and >>> then not have to worry about propagating it up the stack. >> >> The alternative is to have apps set inotify watches on their own >> binaries, I suppose. (There was something in Fedora that used to >> do this.) > > wow, that would be, umm, special. > > How well does inotify cope with THOUSANDS of watches? There is a 8k limit for non root users, besides that sounds racy (what if the binary changed but some lib is still not updated and the soname got bumped?) so it will restart itself while the upgrade process is still running an fail. From walters at verbum.org Tue Sep 29 18:46:54 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 29 Sep 2009 18:46:54 +0000 Subject: long running sessions, restarts, etc. In-Reply-To: <20090929181250.GA17613@nostromo.devel.redhat.com> References: <20090929181250.GA17613@nostromo.devel.redhat.com> Message-ID: On Tue, Sep 29, 2009 at 6:12 PM, Bill Nottingham wrote: > > This means that for me on rawhide, my session is often much longer-lived > than my > software set, as I'll have a two-week session that is running older code > that I've long since upgraded past. Even for those on an actual release, > this can be an issue given our update stream. > Note we should optimize the system for the main release, not rawhide. Not that a good rawhide experience isn't useful, but it's a rather extreme case. For system-level services, we have the idea of try-restart on upgrades; if > the service is running, we automatically restart it on upgrade. How does that work? Obviously you can't restart packagekitd while it's in the middle of upgrading. Another one you obviously can't just kill and restart is libvirtd. > How can > we implement this sanely for session/desktop services? For example, in > my session I see: I think this ends up being a case by case thing. If someone wants to implement things so that a live upgrade works, that's all well and good. The default state though must be reliable; so any generic mechanism that kills processes blindly is just not going to work. If someone wanted to work on this, packagekit may already have a signal for when things are upgraded, and it could make sense to just listen to that. The live replace files on disk part of upgrade is also problematic, and is actually the most broken thing relating to updates we have right now. For this reason among others I think we should move to installing updates immediately before logout/reboot. -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Tue Sep 29 18:51:29 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 29 Sep 2009 14:51:29 -0400 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> Message-ID: <20090929185129.GA18941@nostromo.devel.redhat.com> Colin Walters (walters at verbum.org) said: > For system-level services, we have the idea of try-restart on upgrades; if > > the service is running, we automatically restart it on upgrade. > > > How does that work? Obviously you can't restart packagekitd while it's in > the middle of upgrading. Another one you obviously can't just kill and > restart is libvirtd. Actually, libvirtd does restart on upgrade. It's implemented in the init scripts. > The live replace files on disk part of upgrade is also problematic, and is > actually the most broken thing relating to updates we have right now. For > this reason among others I think we should move to installing updates > immediately before logout/reboot. Really? I think we're moving more towards a model on mobile devices where there *is* no logout/reboot except by accident in a large number of cases. Bill From drago01 at gmail.com Tue Sep 29 18:51:45 2009 From: drago01 at gmail.com (drago01) Date: Tue, 29 Sep 2009 20:51:45 +0200 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> Message-ID: On Tue, Sep 29, 2009 at 8:46 PM, Colin Walters wrote: > The live replace files on disk part of upgrade is also problematic, and is > actually the most broken thing relating to updates we have right now. ?For > this reason among others I think we should move to installing updates > immediately before logout/reboot. We could just do: 1) switch to brtfs 2) have a separte /home by default When updating: 1) create a snapshot of / 2) mount it 3) update stuff there 4) prompt for reboot 5) on reboot switch to the new snapshot We could even keep the last one for rollback reasons. From kanarip at kanarip.com Tue Sep 29 18:08:19 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 29 Sep 2009 20:08:19 +0200 Subject: long running sessions, restarts, etc. In-Reply-To: <20090929185129.GA18941@nostromo.devel.redhat.com> References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> Message-ID: On Tue, 29 Sep 2009 14:51:29 -0400, Bill Nottingham wrote: > Really? I think we're moving more towards a model on mobile devices where > there *is* no logout/reboot except by accident in a large number of cases. > I think the mobility argument is a very valid one, but it isn't truly specific to mobile devices. I log out/log back in on my desktop or laptop about as much as my phone runs out of juice, sorta speak (unless I forget my phone in Rheinfelden, that is). What we have to remember is the type of security issue you would want to require a reboot/restart for. If it's a memory leak, for instance, then hey all of a sudden my device isn't going to work the way I want it. I'll restart the application myself, or reboot my device. Either one is pretty much intuitive to a no-know, including my girlfriend (in fact it's the first thing she does and *then* she calls me her PC was sooooo slow, and she's glad a reboot solved the problem *sigh*). If it's a majorly important "you-are-going-to-be-hacked-standing-too-close-to-starfucks" type of security issue, then hey... your call drops, your application restarts, and maybe you lose a session where you had this amazing one-liner with all kinds of ifs and fors and whiles and awks and seds. There's a price either way for these kinds of bugs, right? -- Jeroen From walters at verbum.org Tue Sep 29 19:19:01 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 29 Sep 2009 19:19:01 +0000 Subject: long running sessions, restarts, etc. In-Reply-To: <20090929185129.GA18941@nostromo.devel.redhat.com> References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> Message-ID: On Tue, Sep 29, 2009 at 6:51 PM, Bill Nottingham wrote: > Colin Walters (walters at verbum.org) said: > > For system-level services, we have the idea of try-restart on upgrades; > if > > > the service is running, we automatically restart it on upgrade. > > > > > > How does that work? Obviously you can't restart packagekitd while it's > in > > the middle of upgrading. Another one you obviously can't just kill and > > restart is libvirtd. > > Actually, libvirtd does restart on upgrade. It's implemented in the > init scripts. > But...hm, ok, so all of the state is in the config data/cache, and child qemu processes I guess. The real point here is the qemu processes. > The live replace files on disk part of upgrade is also problematic, and is > > actually the most broken thing relating to updates we have right now. > For > > this reason among others I think we should move to installing updates > > immediately before logout/reboot. > > Really? I think we're moving more towards a model on mobile devices where > there *is* no logout/reboot except by accident in a large number of cases. The update system should prompt to start installing updates and automatically do a logout/reboot as necessary. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidz at redhat.com Tue Sep 29 19:20:01 2009 From: davidz at redhat.com (David Zeuthen) Date: Tue, 29 Sep 2009 15:20:01 -0400 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> Message-ID: <1254252001.1775.10.camel@localhost.localdomain> On Tue, 2009-09-29 at 18:46 +0000, Colin Walters wrote: > For this reason among others I think we should move to installing > updates immediately before logout/reboot. Completely agree. FWIW, this is what most mobile "computers" such as the iPhone and Android does. And, for the record, how OS X works too (unless the only update is for an application like iTunes). They can of course do this because they don't issue updates almost _every day_ (or what feels like every day, anyway) like we do in Fedora. So I segwayed nicely into this: I think another huge (and, I think, well-known too) problem, which is related to this, is that we issue updates way too often. A cause and/or effect of this is that our updates (and main release) aren't really well-tested, at least not in my experience. Another problem is that we're very militant in Fedora and other distros with dynamic linking - while this sounds great on paper (especially in 1990 when RAM was scarce), it does mean that if you update a shared library you end up breaking many applications. There are other downsides too, e.g. app folders. So it puts even more load on QA that we don't really have. Sorry if what I said sounds ranty and insulting to the Fedora community. If it did, I didn't mean it. But I really really think that "how can we make daemons survive lots of updates?" is the wrong question. The right question, IMO, is "how can we ship software that doesn't need many updates?". Which, of course, is harder to solve (the solution may include a longer, more realistic release-cycle). But solving it brings other benefits too. These are tough questions. Not flamebait. Thanks. David From skvidal at fedoraproject.org Tue Sep 29 19:23:16 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 29 Sep 2009 15:23:16 -0400 (EDT) Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> Message-ID: On Tue, 29 Sep 2009, Colin Walters wrote: > On Tue, Sep 29, 2009 at 6:51 PM, Bill Nottingham wrote: > Colin Walters (walters at verbum.org) said: > > For system-level services, we have the idea of try-restart on upgrades; if > > > the service is running, we automatically restart it on upgrade. > > > > > > How does that work? ?Obviously you can't restart packagekitd while it's in > > the middle of upgrading. ?Another one you obviously can't just kill and > > restart is libvirtd. > > Actually, libvirtd does restart on upgrade. It's implemented in the > init scripts. > > > But...hm, ok, so all of the state is in the config data/cache, and child qemu processes I guess. ?The real point here is > the qemu processes. > > > The live replace files on disk part of upgrade is also problematic, and is > > actually the most broken thing relating to updates we have right now. ?For > > this reason among others I think we should move to installing updates > > immediately before logout/reboot. > > Really? I think we're moving more towards a model on mobile devices where > there *is* no logout/reboot except by accident in a large number of cases. > > > The update system should prompt to start installing updates and automatically do a logout/reboot as necessary. > And I think what Bill is saying is that a lot of users will not want to logout. They will want to just restart the app in question, if they are told which apps are impacted. I don't expect to have to reboot just b/c of an issue in the sound server. -sv From walters at verbum.org Tue Sep 29 19:28:22 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 29 Sep 2009 19:28:22 +0000 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> Message-ID: On Tue, Sep 29, 2009 at 7:23 PM, Seth Vidal wrote: > > And I think what Bill is saying is that a lot of users will not want to > logout. They will want to just restart the app in question, if they are told > which apps are impacted. > This is what I meant in saying it's case by case, not something where one policy applies to all software. If you just updated Firefox, then yes, we can and should have a system which knows how to restart just that application. The discussion started about infrastructure bits, like: > I don't expect to have to reboot just b/c of an issue in the sound server. > Not reboot for this one but relogin. Well, you can choose not to of course, but the point of an update is to actually update what's running on people's computers. If the system doesn't reliably get us there it's not working.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Tue Sep 29 19:32:19 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 29 Sep 2009 15:32:19 -0400 (EDT) Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> Message-ID: On Tue, 29 Sep 2009, Colin Walters wrote: > On Tue, Sep 29, 2009 at 7:23 PM, Seth Vidal wrote: > > And I think what Bill is saying is that a lot of users will not want to logout. They will want to just restart the > app in question, if they are told which apps are impacted. > > > This is what I meant in saying it's case by case, not something where one policy applies to all software. ?If you just > updated Firefox, then yes, we can and should have a system which knows how to restart just that application. > > The discussion started about infrastructure bits, like: > ? > I don't expect to have to reboot just b/c of an issue in the sound server. > > > Not reboot for this one but relogin. ?Well, you can choose not to of course, but the point of an update is to actually > update what's running on people's computers. ?If the system doesn't reliably get us there it's not working.. > So what was suggested by dmalcolm was tracking down which programs in use are being updated/changed and telling the user 'this application that is currently in use by [userid] needs to be restarted to take advantage of this update'. I was suggesting we could get that info in yum and make it available. -sv From walters at verbum.org Tue Sep 29 19:45:48 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 29 Sep 2009 19:45:48 +0000 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> Message-ID: On Tue, Sep 29, 2009 at 7:32 PM, Seth Vidal wrote: > > So what was suggested by dmalcolm was tracking down which programs in use > are being updated/changed and telling the user 'this application that is > currently in use by [userid] needs to be restarted to take advantage of this > update'. > By program do you mean package, or .desktop file? There's a big difference, in that we expect all desktop users to know roughly what the things are named by .desktop, but if we have a UI with packages it's going to contain incomprehensible stuff (what is gvfs? what is pulseaudio? What is...). All of this should basically all be grouped under "Operating System" with a "Details |>" expander to see the packages for power users. We could probably implement generic application restart using http://live.gnome.org/GnomeShell/ApplicationBased by sending a close event to the app's windows. It wouldn't be awful to backport this to GNOME 2. But there's just no way you can have some generic system for the infrastructure, and we need the logout/reboot system for that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Tue Sep 29 19:46:22 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 29 Sep 2009 15:46:22 -0400 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> Message-ID: <20090929194621.GA20044@nostromo.devel.redhat.com> Colin Walters (walters at verbum.org) said: > > I don't expect to have to reboot just b/c of an issue in the sound server. > > Not reboot for this one but relogin. How so? PA could in theory restart itself at some point when all streams are idle, could it not? Bill From drago01 at gmail.com Tue Sep 29 19:48:58 2009 From: drago01 at gmail.com (drago01) Date: Tue, 29 Sep 2009 21:48:58 +0200 Subject: long running sessions, restarts, etc. In-Reply-To: <20090929194621.GA20044@nostromo.devel.redhat.com> References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> <20090929194621.GA20044@nostromo.devel.redhat.com> Message-ID: On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham wrote: > Colin Walters (walters at verbum.org) said: >> > I don't expect to have to reboot just b/c of an issue in the sound server. >> >> Not reboot for this one but relogin. > > How so? PA could in theory restart itself at some point when all streams > are idle, could it not? The apps would have to reconnect to pa. From walters at verbum.org Tue Sep 29 19:50:24 2009 From: walters at verbum.org (Colin Walters) Date: Tue, 29 Sep 2009 19:50:24 +0000 Subject: long running sessions, restarts, etc. In-Reply-To: <20090929194621.GA20044@nostromo.devel.redhat.com> References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> <20090929194621.GA20044@nostromo.devel.redhat.com> Message-ID: On Tue, Sep 29, 2009 at 7:46 PM, Bill Nottingham wrote: > Colin Walters (walters at verbum.org) said: > > > I don't expect to have to reboot just b/c of an issue in the sound > server. > > > > Not reboot for this one but relogin. > > How so? PA could in theory restart itself at some point when all streams > are idle, could it not? Sure. Though how long do you wait? Is it conditional on update urgency? And pulse has a similar problem in that the stream source identification needs the same infrastructure we're doing for the shell, so it could tell you what applications are using it. This is highly specific to pulse, which gets back to my point: If someone wants to work on case-by-case for individual daemons I think that's great. However, it's not a substitute for a default-reliable update system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wwoods at redhat.com Tue Sep 29 19:57:58 2009 From: wwoods at redhat.com (Will Woods) Date: Tue, 29 Sep 2009 15:57:58 -0400 Subject: long running sessions, restarts, etc. In-Reply-To: <1254252001.1775.10.camel@localhost.localdomain> References: <20090929181250.GA17613@nostromo.devel.redhat.com> <1254252001.1775.10.camel@localhost.localdomain> Message-ID: <1254254278.2706.327.camel@metroid> On Tue, 2009-09-29 at 15:20 -0400, David Zeuthen wrote: > On Tue, 2009-09-29 at 18:46 +0000, Colin Walters wrote: > > For this reason among others I think we should move to installing > > updates immediately before logout/reboot. > > Completely agree. FWIW, this is what most mobile "computers" such as the > iPhone and Android does. And, for the record, how OS X works too (unless > the only update is for an application like iTunes). They can of course > do this because they don't issue updates almost _every day_ (or what > feels like every day, anyway) like we do in Fedora. One of the things Those Other OSes do is to batch updates into larger Service Pack / point-release updates, and only offer the individual pieces as "hotfixes" to those who really, really need (or want) them. If we were just trying to improve the *perception* that there's too many updates (and they're not that useful), the simplest solution would be to batch updates and release them as point-release updates along with release notes and an appropriate amount of fanfare about new features and fixes. > A cause and/or effect of this is that our updates > (and main release) aren't really well-tested, at least not in my > experience. Well, batching updates would also mean that they'd spend more *required* time in the testing repository. Which is a necessary step to get better manual QA on updates. It's not sufficient to guarantee better QA - "spends time in the testing repo" does not necessarily imply "has been tested" - but it can't really hurt. Furthermore, while it's obvious simpler to test a single package than a whole load of 250 packages, it's *much* easier to test one large update payload than each possible combination of 250 individual updates. [snip] > So it puts even more load on QA that we don't really have. > Sorry if what I said sounds ranty and insulting to the Fedora community. > If it did, I didn't mean it. But I really really think that "how can we > make daemons survive lots of updates?" is the wrong question. The right > question, IMO, is "how can we ship software that doesn't need many > updates?". Which, of course, is harder to solve (the solution may > include a longer, more realistic release-cycle). But solving it brings > other benefits too. No, I totally agree - making the daemons survive updates better is probably not the most pressing problem with the Fedora update system. On the other hand, it's a problem that can be solved with code rather than needing long bikesheddy discussions and policy arguments. And I think we all know that, as a group, we're way better with code than talk. Still, I think it's worth trying to get some *data* about what the *actual* problems are with the update system and see if we can't have some good, productive discussions that lead to actual positive change. So, uh, let's.. just.. go ahead and do that, then. -w From dmalcolm at redhat.com Tue Sep 29 20:05:25 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 29 Sep 2009 16:05:25 -0400 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> Message-ID: <1254254725.21201.77.camel@radiator.bos.redhat.com> On Tue, 2009-09-29 at 15:32 -0400, Seth Vidal wrote: > > On Tue, 29 Sep 2009, Colin Walters wrote: > > > On Tue, Sep 29, 2009 at 7:23 PM, Seth Vidal wrote: > > > > And I think what Bill is saying is that a lot of users will not want to logout. They will want to just restart the > > app in question, if they are told which apps are impacted. > > > > > > This is what I meant in saying it's case by case, not something where one policy applies to all software. If you just > > updated Firefox, then yes, we can and should have a system which knows how to restart just that application. > > > > The discussion started about infrastructure bits, like: > > > > I don't expect to have to reboot just b/c of an issue in the sound server. > > > > > > Not reboot for this one but relogin. Well, you can choose not to of course, but the point of an update is to actually > > update what's running on people's computers. If the system doesn't reliably get us there it's not working.. > > > > So what was suggested by dmalcolm was tracking down which programs in use > are being updated/changed and telling the user 'this application that is > currently in use by [userid] needs to be restarted to take advantage of > this update'. > > I was suggesting we could get that info in yum and make it available. > My thought was to do it at the level of ELF files i.e. both binaries and the libraries consuming them. That way, if e.g. there's a libldap update, you know which PIDs are still mapping the old implementation of that file on disk. FWIW, here's some python code that tells you files per PID and PIDs per file; this code also spots e.g. .mo files, shared fontconfig caches, etc: import os import re from pprint import pprint pids_per_file = {} print "Files per PID:" for pid in os.listdir('/proc'): if re.match('([0-9]+)', pid): pid = int(pid) files = set() for line in open(os.path.join('/proc', str(pid), 'maps')): # Expect lines of the form: # '00101000-0023e000 r-xp 00000000 fd:00 1835017 /lib/libc-2.5.so' fields = line.split() if len(fields) > 5: file = fields[5] if file.startswith('/'): files.add(file) if file in pids_per_file: pids_per_file[file].append(pid) else: pids_per_file[file] = [pid] print pid, files print print "PIDS per file:" pprint(pids_per_file) From abo at root.snowtree.se Tue Sep 29 20:42:40 2009 From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Tue, 29 Sep 2009 22:42:40 +0200 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> <1254249231.21201.65.camel@radiator.bos.redhat.com> <20090929184217.GA18841@nostromo.devel.redhat.com> Message-ID: <1254256960.6284.39217.camel@tempo.alexander.bostrom.net> tis 2009-09-29 klockan 20:46 +0200 skrev drago01: > There is a 8k limit for non root users, besides that sounds racy (what > if the binary changed but some lib is still not updated and the soname > got bumped?) so it will restart itself while the upgrade process is > still running an fail. Hmm, true. When rpm is done with a transaction, it provides a list of files it modified. The next step is to send a signal to all processes that has any of those files open and has indicated that it is capable of dealing with such signals, so that the process can take appropriate action. That should catch the binary and all loaded libraries. Should be enough, right? Maybe DBus is the right way to broadcast that list of files? Either send the whole list to all recipients that asks for it or filter it for each process based on its open files. In the case of shared roots, you want to do this on each machine that has this filesystem mounted. Can't it just be a program that takes a list of paths on stdin and broadcasts it? Normally run directly by rpm or yum but in some cases triggered by other means, like manually when the sysadmin released an update to the shared root? /abo From jkeating at redhat.com Tue Sep 29 20:43:13 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 29 Sep 2009 13:43:13 -0700 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> <20090929194621.GA20044@nostromo.devel.redhat.com> Message-ID: <1254256993.2303.16.camel@localhost.localdomain> On Tue, 2009-09-29 at 21:48 +0200, drago01 wrote: > On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham wrote: > > Colin Walters (walters at verbum.org) said: > >> > I don't expect to have to reboot just b/c of an issue in the sound server. > >> > >> Not reboot for this one but relogin. > > > > How so? PA could in theory restart itself at some point when all streams > > are idle, could it not? > > The apps would have to reconnect to pa. > Which they manage to do every time I have to killall -9 pulseaudio when it gets wedged. Seems like we already have support for pulse going away and coming back. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From drago01 at gmail.com Tue Sep 29 20:46:18 2009 From: drago01 at gmail.com (drago01) Date: Tue, 29 Sep 2009 22:46:18 +0200 Subject: long running sessions, restarts, etc. In-Reply-To: <1254256993.2303.16.camel@localhost.localdomain> References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> <20090929194621.GA20044@nostromo.devel.redhat.com> <1254256993.2303.16.camel@localhost.localdomain> Message-ID: On Tue, Sep 29, 2009 at 10:43 PM, Jesse Keating wrote: > On Tue, 2009-09-29 at 21:48 +0200, drago01 wrote: >> On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham wrote: >> > Colin Walters (walters at verbum.org) said: >> >> > I don't expect to have to reboot just b/c of an issue in the sound server. >> >> >> >> Not reboot for this one but relogin. >> > >> > How so? PA could in theory restart itself at some point when all streams >> > are idle, could it not? >> >> The apps would have to reconnect to pa. >> > > Which they manage to do every time I have to killall -9 pulseaudio when > it gets wedged. ?Seems like we already have support for pulse going away > and coming back. well the volume-applet in F11 sure does not do that which is annoying as hell (fixed in F12 though). From hughsient at gmail.com Tue Sep 29 20:56:58 2009 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 29 Sep 2009 21:56:58 +0100 Subject: long running sessions, restarts, etc. In-Reply-To: <20090929181250.GA17613@nostromo.devel.redhat.com> References: <20090929181250.GA17613@nostromo.devel.redhat.com> Message-ID: <15e53e180909291356rb4edff3n54f925b1c16fada9@mail.gmail.com> 2009/9/29 Bill Nottingham : > packagekitd packagekitd and gpk-update-icon already restart themselves in a sane way when the binary changes. Richard. From kanarip at kanarip.com Tue Sep 29 19:57:03 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 29 Sep 2009 21:57:03 +0200 Subject: long running sessions, restarts, etc. In-Reply-To: <1254252001.1775.10.camel@localhost.localdomain> References: <20090929181250.GA17613@nostromo.devel.redhat.com> <1254252001.1775.10.camel@localhost.localdomain> Message-ID: On Tue, 29 Sep 2009 15:20:01 -0400, David Zeuthen wrote: > On Tue, 2009-09-29 at 18:46 +0000, Colin Walters wrote: >> For this reason among others I think we should move to installing >> updates immediately before logout/reboot. > > Completely agree. FWIW, this is what most mobile "computers" such as the > iPhone and Android does. And, for the record, how OS X works too (unless > the only update is for an application like iTunes). They can of course > do this because they don't issue updates almost _every day_ (or what > feels like every day, anyway) like we do in Fedora. > The major difference obviously being, that OS X is not a version of rawhide with a release number attached to it. It is more like, dare I say it, RHEL (in that aspect). The ultimate problem though is not the number of updates. One can cron a yum -y update every 5 minutes without it (euh, the updates being applied) interrupting (m)any of the services or applications running on the system (as long as they are running, that is). The ultimate challenge is; how, if at all, can we make sure a running daemon picks up the new blobs so that we can seamlessly update/upgrade, especially with regards to "i'm in ur board eating your keez" security issues. Making the release cycle longer (including the development cycle) works two ways; 1) you have more time to perform QA 2) everytime you perform QA the amount of changes is going to be bigger (53 features in 6 months anyone?) Also, the militant attitude of Fedora against static linking works two ways; 1) my blob runs on its own 1a) ignoring updates (security fixes anyone?) to the statically linked other blobs. Weeeee! 1b) putting the load on all packagers of blobs depending on blob, and/or vice-versa 2) my blob runs with the help of other blobs And, to not continue on why it would be bad, how much RAM does your Android have? Your iPhone? Your HTC X7500? Your HTC Touch? Is it... scarse? Still though, the interesting question is how we can ship software that doesn't need as many updates... like you said ;-) -- Jeroen From abo at root.snowtree.se Tue Sep 29 21:19:36 2009 From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Tue, 29 Sep 2009 23:19:36 +0200 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> <1254252001.1775.10.camel@localhost.localdomain> Message-ID: <1254259176.6284.39627.camel@tempo.alexander.bostrom.net> tis 2009-09-29 klockan 21:57 +0200 skrev Jeroen van Meeuwen: > > And, to not continue on why it would be bad, how much RAM does your > Android > have? Your iPhone? Your HTC X7500? Your HTC Touch? Is it... scarse? It is definitely scarce on my N810. I don't understand why dynamic linking is a problem in this context, if that's what you're saying. /abo From mclasen at redhat.com Tue Sep 29 21:44:35 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 29 Sep 2009 17:44:35 -0400 Subject: long running sessions, restarts, etc. In-Reply-To: <1254259176.6284.39627.camel@tempo.alexander.bostrom.net> References: <20090929181250.GA17613@nostromo.devel.redhat.com> <1254252001.1775.10.camel@localhost.localdomain> <1254259176.6284.39627.camel@tempo.alexander.bostrom.net> Message-ID: <1254260675.1670.9.camel@planemask> On Tue, 2009-09-29 at 23:19 +0200, Alexander Bostr?m wrote: > > I don't understand why dynamic linking is a problem in this context, if > that's what you're saying. It is not a problem per se, but it a major source of our deeply nested dependencies graphs, which make updating, installing and removing applications harder than it would be with, say, an appfolder-like approach. Of course, that has its own downsides... From william.jon.mccann at gmail.com Wed Sep 30 03:38:01 2009 From: william.jon.mccann at gmail.com (William Jon McCann) Date: Tue, 29 Sep 2009 23:38:01 -0400 Subject: long running sessions, restarts, etc. In-Reply-To: <20090929185129.GA18941@nostromo.devel.redhat.com> References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> Message-ID: <939dd5750909292038x2587bc9wadf5a0b47fed332d@mail.gmail.com> Hey Bill, On Tue, Sep 29, 2009 at 2:51 PM, Bill Nottingham wrote: > Colin Walters (walters at verbum.org) said: >> For system-level services, we have the idea of try-restart on upgrades; if >> > the service is running, we automatically restart it on upgrade. >> >> >> How does that work? ?Obviously you can't restart packagekitd while it's in >> the middle of upgrading. ?Another one you obviously can't just kill and >> restart is libvirtd. > > Actually, libvirtd does restart on upgrade. It's implemented in the > init scripts. > >> The live replace files on disk part of upgrade is also problematic, and is >> actually the most broken thing relating to updates we have right now. ?For >> this reason among others I think we should move to installing updates >> immediately before logout/reboot. > > Really? I think we're moving more towards a model on mobile devices where > there *is* no logout/reboot except by accident in a large number of cases. Yes and no. My (linux based) phone, for example, reboots automatically as part of the update process. However, the OS update is bundled and occurs, so far, only once a month. Personally, I've been advocating for our next generation update system to do something similar. Jon From william.jon.mccann at gmail.com Wed Sep 30 05:07:27 2009 From: william.jon.mccann at gmail.com (William Jon McCann) Date: Wed, 30 Sep 2009 01:07:27 -0400 Subject: Thoughts on updates Message-ID: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> Hi, Since it has come up recently, I figured I'd briefly mention that some people in the desktop team, QE, and release engineering had a few lunchtime chats about our update process. I tried to write down some of what we talked about: https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience I later found out that there are a number of different initiatives underway that may help with this problem. So, that is good news. Interested to hear your thoughts. Thanks, Jon From nicu_fedora at nicubunu.ro Wed Sep 30 08:39:03 2009 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 30 Sep 2009 11:39:03 +0300 Subject: Thoughts on updates In-Reply-To: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> References: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> Message-ID: <4AC31927.1050809@nicubunu.ro> On 09/30/2009 08:07 AM, William Jon McCann wrote: > Since it has come up recently, I figured I'd briefly mention that some > people in the desktop team, QE, and release engineering had a few > lunchtime chats about our update process. I tried to write down some > of what we talked about: > https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience > > I later found out that there are a number of different initiatives > underway that may help with this problem. So, that is good news. > > Interested to hear your thoughts. Here is my biggest annoyance with updates: I get usually asked about them right after I start the computer and have other important things to do. I check the total size and if it is small enough, I apply it but if is large (for example including an openoffice.org update), I postpone the update, as I need the full bandwidth (for cheeking mails, reading news, whatever). Good thing we have Delta RPMS, and the size is usually much smaller than reported... If the update needs a restart, I *never* do it right away: I started the computer because I have things to do with it, not waste a couple of minutes with a reboot. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ my Fedora stuff: http://fedora.nicubunu.ro/ From drago01 at gmail.com Wed Sep 30 09:26:04 2009 From: drago01 at gmail.com (drago01) Date: Wed, 30 Sep 2009 11:26:04 +0200 Subject: Thoughts on updates In-Reply-To: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> References: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> Message-ID: On Wed, Sep 30, 2009 at 7:07 AM, William Jon McCann wrote: > Hi, > > Since it has come up recently, I figured I'd briefly mention that some > people in the desktop team, QE, and release engineering had a few > lunchtime chats about our update process. ?I tried to write down some > of what we talked about: > https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience > > I later found out that there are a number of different initiatives > underway that may help with this problem. ?So, that is good news. > > Interested to hear your thoughts. "# System updates must fix critical bugs or security vulnerabilities only " Well there should be one exception for this: Adding support for new hardware (ie. kernel rebase). The reason is that if we don't do that the user have to either wait until the next release to be able to use the his/her hardware or go googling for how to compile the specifi driver by hand. Both aren't really a great user expirence. From drago01 at gmail.com Wed Sep 30 09:27:24 2009 From: drago01 at gmail.com (drago01) Date: Wed, 30 Sep 2009 11:27:24 +0200 Subject: Thoughts on updates In-Reply-To: <4AC31927.1050809@nicubunu.ro> References: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> <4AC31927.1050809@nicubunu.ro> Message-ID: On Wed, Sep 30, 2009 at 10:39 AM, Nicu Buculei wrote: > On 09/30/2009 08:07 AM, William Jon McCann wrote: > [...] > If the update needs a restart, I *never* do it right away: I started the > computer because I have things to do with it, not waste a couple of > minutes with a reboot. Exactly I never reboot just because PK tells me "please reboot". From nicu_fedora at nicubunu.ro Wed Sep 30 09:34:58 2009 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 30 Sep 2009 12:34:58 +0300 Subject: Thoughts on updates In-Reply-To: References: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> <4AC31927.1050809@nicubunu.ro> Message-ID: <4AC32642.7010501@nicubunu.ro> On 09/30/2009 12:27 PM, drago01 wrote: > On Wed, Sep 30, 2009 at 10:39 AM, Nicu Buculei wrote: >> On 09/30/2009 08:07 AM, William Jon McCann wrote: >> [...] >> If the update needs a restart, I *never* do it right away: I started the >> computer because I have things to do with it, not waste a couple of >> minutes with a reboot. > > Exactly I never reboot just because PK tells me "please reboot". Well, never was a bit too strong... the system may get acting so weird so ultimately you *have* to reboot :p -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ From drago01 at gmail.com Wed Sep 30 09:57:23 2009 From: drago01 at gmail.com (drago01) Date: Wed, 30 Sep 2009 11:57:23 +0200 Subject: Thoughts on updates In-Reply-To: <4AC32642.7010501@nicubunu.ro> References: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> <4AC31927.1050809@nicubunu.ro> <4AC32642.7010501@nicubunu.ro> Message-ID: On Wed, Sep 30, 2009 at 11:34 AM, Nicu Buculei wrote: > On 09/30/2009 12:27 PM, drago01 wrote: >> On Wed, Sep 30, 2009 at 10:39 AM, Nicu Buculei wrote: >>> On 09/30/2009 08:07 AM, William Jon McCann wrote: >>> [...] >>> If the update needs a restart, I *never* do it right away: I started the >>> computer because I have things to do with it, not waste a couple of >>> minutes with a reboot. >> >> Exactly I never reboot just because PK tells me "please reboot". > > Well, never was a bit too strong... the system may get acting so weird > so ultimately you *have* to reboot :p The only thing that acts weird is firefox, but I always close it before updating it. From sundaram at fedoraproject.org Wed Sep 30 11:32:22 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 30 Sep 2009 17:02:22 +0530 Subject: Thoughts on updates In-Reply-To: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> References: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> Message-ID: <4AC341C6.7040504@fedoraproject.org> On 09/30/2009 10:37 AM, William Jon McCann wrote: > Hi, > > Since it has come up recently, I figured I'd briefly mention that some > people in the desktop team, QE, and release engineering had a few > lunchtime chats about our update process. I tried to write down some > of what we talked about: > https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience > > I later found out that there are a number of different initiatives > underway that may help with this problem. So, that is good news. > > Interested to hear your thoughts. One thing I would really like is for PackageKit to download updates in the background (detecting whether I am on a low bandwidth connection) and only prompt me for updates when it is ready to install. Another constant annoyance is that soon after a yum operation in the command line, PackageKit insists on updating some metadata immediately thereby locking out the subsequent commands for sometime (can be a considerable delay). I would prefer it to wait for a few mins and not interrupt me. Filed and closed WONTFIX however. Rahul From drago01 at gmail.com Wed Sep 30 11:40:18 2009 From: drago01 at gmail.com (drago01) Date: Wed, 30 Sep 2009 13:40:18 +0200 Subject: Thoughts on updates In-Reply-To: <4AC341C6.7040504@fedoraproject.org> References: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> <4AC341C6.7040504@fedoraproject.org> Message-ID: On Wed, Sep 30, 2009 at 1:32 PM, Rahul Sundaram wrote: > On 09/30/2009 10:37 AM, William Jon McCann wrote: >> Hi, >> >> Since it has come up recently, I figured I'd briefly mention that some >> people in the desktop team, QE, and release engineering had a few >> lunchtime chats about our update process. ?I tried to write down some >> of what we talked about: >> https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience >> >> I later found out that there are a number of different initiatives >> underway that may help with this problem. ?So, that is good news. >> >> Interested to hear your thoughts. > > One thing I would really like is for PackageKit to download updates in > the background (detecting whether I am on a low bandwidth connection) > and only prompt me for updates when it is ready to install. > > Another constant annoyance is that soon after a yum operation in the > command line, PackageKit insists on updating some metadata immediately > thereby locking out the subsequent commands for sometime (can be a > considerable delay). I would prefer it to wait for a few mins and not > interrupt me. Filed and closed WONTFIX however. Just disable the packagekit yum plugin or do yum remove PackageKit-yum-plugin From hughsient at gmail.com Wed Sep 30 11:49:10 2009 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 30 Sep 2009 12:49:10 +0100 Subject: Thoughts on updates In-Reply-To: <4AC341C6.7040504@fedoraproject.org> References: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> <4AC341C6.7040504@fedoraproject.org> Message-ID: <15e53e180909300449q2dd8c5c6te9b1da4137f63d68@mail.gmail.com> 2009/9/30 Rahul Sundaram : > One thing I would really like is for PackageKit to download updates in > the background (detecting whether I am on a low bandwidth connection) > and only prompt me for updates when it is ready to install. It already detects what kind of connection you are on. When the idle-bandwidth changes are done we can do things like this without upsetting people actually using the connection. > Another constant annoyance is that soon after a yum operation in the > command line, PackageKit insists on updating some metadata immediately > thereby locking out the subsequent commands for sometime (can be a > considerable delay). I would prefer it to wait for a few mins and not > interrupt me. Filed and closed WONTFIX however. Sure, remove PackageKit-yum-plugin or blacklist it in the yum configuration. There's also now configuration for this value in the systemwide config file, /etc/PackageKit/PackageKit.conf: # The time in seconds to wait when we get the StateHasChanged method # # This should be used when a native tool has been used, and the update UIs # should be updated to reflect reality. # # default=5 StateChangedTimeoutPriority=5 Change this to something like 2400 and if should do pretty much what you want. Richard. From sundaram at fedoraproject.org Wed Sep 30 11:57:15 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 30 Sep 2009 17:27:15 +0530 Subject: Thoughts on updates In-Reply-To: <15e53e180909300449q2dd8c5c6te9b1da4137f63d68@mail.gmail.com> References: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> <4AC341C6.7040504@fedoraproject.org> <15e53e180909300449q2dd8c5c6te9b1da4137f63d68@mail.gmail.com> Message-ID: <4AC3479B.9060307@fedoraproject.org> On 09/30/2009 05:19 PM, Richard Hughes wrote: > 2009/9/30 Rahul Sundaram : >> One thing I would really like is for PackageKit to download updates in >> the background (detecting whether I am on a low bandwidth connection) >> and only prompt me for updates when it is ready to install. > > It already detects what kind of connection you are on. When the > idle-bandwidth changes are done we can do things like this without > upsetting people actually using the connection. I know it detects the connection but would like to have a preference option that downloads updates in the background. I think that is what Mac OS X does by default but I might be misremembering that. >> Another constant annoyance is that soon after a yum operation in the >> command line, PackageKit insists on updating some metadata immediately >> thereby locking out the subsequent commands for sometime (can be a >> considerable delay). I would prefer it to wait for a few mins and not >> interrupt me. Filed and closed WONTFIX however. > > Sure, remove PackageKit-yum-plugin or blacklist it in the yum > configuration. There's also now configuration for this value in the > systemwide config file, /etc/PackageKit/PackageKit.conf: Why would I remove PackgeKit yum plugin? I want to use PackageKit and yum interchangeably. There are particular things yum makes easier and there are particular things PackageKit makes it easier for me. I think it is a common enough use case that I want it to just work without having to tweak configuration files. IMO, the default state change timeout value should be higher but I have done that for now. Thanks. Rahul From hughsient at gmail.com Wed Sep 30 12:04:46 2009 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 30 Sep 2009 13:04:46 +0100 Subject: Thoughts on updates In-Reply-To: <4AC3479B.9060307@fedoraproject.org> References: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> <4AC341C6.7040504@fedoraproject.org> <15e53e180909300449q2dd8c5c6te9b1da4137f63d68@mail.gmail.com> <4AC3479B.9060307@fedoraproject.org> Message-ID: <15e53e180909300504o599a20dj4e987add27775ccf@mail.gmail.com> 2009/9/30 Rahul Sundaram : > Why would I remove PackgeKit yum plugin? I want to use PackageKit and > yum interchangeably. Maybe confusingly, there are two yum subpackages for PackageKit. PackageKit-yum contains the yum backend and all the code for packagekitd to talk to yum and pass data. PackageKit-yum-plugin is a simple yum plugin that pokes PackageKit to drop internal caches and reload update lists (if an application is open) after the user has done a command wuth yum on the CLI that might change the state, like updating a package or enabling a repo. So, it's pretty safe to remove PackageKit-yum-plugin if you don't mind the GUI's occasionally being out of sync with reality, but you really, really don't want to remove PackageKit-yum. Richard. From william.jon.mccann at gmail.com Wed Sep 30 14:17:18 2009 From: william.jon.mccann at gmail.com (William Jon McCann) Date: Wed, 30 Sep 2009 10:17:18 -0400 Subject: Thoughts on updates In-Reply-To: References: <939dd5750909292207v688afb42qfbc1c2e42862d288@mail.gmail.com> Message-ID: <939dd5750909300717x71203e70oee888f2a5c6ca526@mail.gmail.com> Hi, On Wed, Sep 30, 2009 at 5:26 AM, drago01 wrote: > On Wed, Sep 30, 2009 at 7:07 AM, William Jon McCann > wrote: >> Hi, >> >> Since it has come up recently, I figured I'd briefly mention that some >> people in the desktop team, QE, and release engineering had a few >> lunchtime chats about our update process. ?I tried to write down some >> of what we talked about: >> https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience >> >> I later found out that there are a number of different initiatives >> underway that may help with this problem. ?So, that is good news. >> >> Interested to hear your thoughts. > > "# ?System updates must fix critical bugs or security vulnerabilities only " > > Well there should be one exception for this: Adding support for new > hardware (ie. kernel rebase). > The reason is that if we don't do that the user have to either wait > until the next release to be able to use the his/her hardware or go > googling for how to compile the specifi driver by hand. > > Both aren't really a great user expirence. Yeah, that makes sense. I've added that. Thanks, Jon From bnocera at redhat.com Wed Sep 30 14:47:11 2009 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 30 Sep 2009 15:47:11 +0100 Subject: long running sessions, restarts, etc. In-Reply-To: References: <20090929181250.GA17613@nostromo.devel.redhat.com> <20090929185129.GA18941@nostromo.devel.redhat.com> <20090929194621.GA20044@nostromo.devel.redhat.com> <1254256993.2303.16.camel@localhost.localdomain> Message-ID: <1254322031.2093.18490.camel@localhost.localdomain> On Tue, 2009-09-29 at 22:46 +0200, drago01 wrote: > On Tue, Sep 29, 2009 at 10:43 PM, Jesse Keating wrote: > > On Tue, 2009-09-29 at 21:48 +0200, drago01 wrote: > >> On Tue, Sep 29, 2009 at 9:46 PM, Bill Nottingham wrote: > >> > Colin Walters (walters at verbum.org) said: > >> >> > I don't expect to have to reboot just b/c of an issue in the sound server. > >> >> > >> >> Not reboot for this one but relogin. > >> > > >> > How so? PA could in theory restart itself at some point when all streams > >> > are idle, could it not? > >> > >> The apps would have to reconnect to pa. > >> > > > > Which they manage to do every time I have to killall -9 pulseaudio when > > it gets wedged. Seems like we already have support for pulse going away > > and coming back. > > well the volume-applet in F11 sure does not do that which is annoying > as hell (fixed in F12 though). It's also fixed in F-11, seeing as it ships the same version as F-12... From christoph.wickert at googlemail.com Wed Sep 30 23:15:50 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 01 Oct 2009 01:15:50 +0200 Subject: A new notification theme In-Reply-To: <939dd5750909290813v371b8bd0h80905cd5cd5d080c@mail.gmail.com> References: <1253839734.1690.51.camel@planemask> <1254229221.2884.157.camel@localhost> <939dd5750909290813v371b8bd0h80905cd5cd5d080c@mail.gmail.com> Message-ID: <1254352550.2816.264.camel@localhost> Am Dienstag, den 29.09.2009, 11:13 -0400 schrieb William Jon McCann: > Hi Christoph, > > On Tue, Sep 29, 2009 at 9:00 AM, Christoph Wickert > wrote: > > Am Donnerstag, den 24.09.2009, 20:48 -0400 schrieb Matthias Clasen: > >> Tomorrows rawhide will have a new notification theme for Gnome. > >> > >> The aim of this new theme is to integrate well with the theming in the > >> rest of the desktop (which wasn't really the case with nodoka bubbles > >> and a clearlooks desktop). > > > > After I have seen them now I can say I think they are horrible. We could > > really argue if the Nodoka bubbles matched the rest of Nodoka, but this > > definitely matches even less. > > > > I think such changes shouldn't been done as a solo action without > > previous notice. Has the design team been aked about this? (No, Matthias > > and Jon, you are *not* the design team, sorry). Or people from the > > desktop SIG? How about other contributors? > > > > IMHO this change is also very ungrateful to Martin, who does an amazing > > job with the Nodoka theme. > > So, this message is clearly a troll but I'd like to respond to a few > things anyway. > > If you have any substantial and specific critique of the theme I'd > love to hear it. Hi Jon, I think I already lined out my critique in the previous post. In case you didn't get it: * The new theme doesn't fit to the rest of the desktop. * Fedora is and always has been blue. Blue is our brand. While yellow is the complementary color to blue, what exactly is the relation from black to blue? * Changes like this shouldn't happen so late in the development cycle. * Changes like this shouldn't happen without asking for feedback *first*. Pushing a change and asking afterwards is not the way. * It's not the first time Matthias makes/wants to make a change like this in a solo action. This is not how a community project works. Please be so kind as to reply to these points one by one instead of just calling it trolling. > We are the people involved in designing the desktop product. Anyone > may contribute to that but there is no magic design team that needs to > be consulted before we make changes. If you really think so, I'm sorry for you, because you still have not understood that Fedora is a community project. The days where Red Hat employees were to decide everything inside of RH (hopefully) are over. > There are people that I think > are very good at what they do and I consult them as much as possible. > In this case in particular, there were a few different people I > consulted. But if you wish to put labels on things - yes we are the > desktop design team. Would you name some names please? I was talking of the design team which is lead by Mairin. and who is doing much more than just wallpapers. These people are not necessarily developers, but brilliant artists. Not asking them for assistance is missing a great opportunity. Or think of the desktop SIG. How many of it's 12 members were actually involved in this decision? > I have no idea why anyone would think that we're ungrateful to Martin > because of this. I'm pretty sure Martin wouldn't think this either. Then please take a look at Martin's reply to Matthias or the recent "Default theme for F12" thread. Reading between the lines you can clearly see Martins disappointment when he asks "I have been wondering what "we" stands for here... The discussion seems to mostly happen off-list." > However, he probably doesn't prefer the new design over his - why > would he? There are going to be differences in opinion like this. It > is only natural. He has been notably constructive in his messages so > far. > > At the end of the day we need to stand up and take responsibility for > the end result. To make sure things fit together coherently. Which IMO simply is not the case. According to the comments on Paul's blog article I'm not the only one who thinks so. > That > doesn't mean that these decisions occur in a vacuum or that we don't > need a heck of a lot of help. Nothing is ever final. Ok, why push something a day before development freeze without asking for feedback first then? Smells a little funny to me. > For now, Matthias and I have assumed the (often difficult) > responsibility of trying to fit all our shit together in a way that > doesn't totally suck. We *do* need your help to do that. Again: If you need help or feedback, why not ask? And why not ask *first*? > But that > doesn't mean that we're going to avoid making the often difficult > choices - it is critical that we do. > > So, let's try to keep focus on what we are all trying to achieve here. > By the way have you tried the latest Ubuntu nightly? It isn't half > bad. Snow Leopard? Doesn't suck. Windows 7 - yeah I could use that. I don't get what you are trying to tell me with this. We are not Ubuntu, we are not MacOS or Window ether. We are Fedora, a project "maintained and driven by the community and sponsored by Red Hat." Or is the wiki wrong? > Jon Regards, Christoph P.S.: I have CC'ed Max. Call me a squealer, but I think your attitude towards the involvement of the community is something that IMO really should be discussed. From christoph.wickert at googlemail.com Wed Sep 30 23:23:42 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Thu, 01 Oct 2009 01:23:42 +0200 Subject: A new notification theme In-Reply-To: <1254230418.1671.12.camel@planemask> References: <1253839734.1690.51.camel@planemask> <1254229221.2884.157.camel@localhost> <1254230418.1671.12.camel@planemask> Message-ID: <1254353023.2816.279.camel@localhost> Am Dienstag, den 29.09.2009, 09:20 -0400 schrieb Matthias Clasen: > On Tue, 2009-09-29 at 15:00 +0200, Christoph Wickert wrote: > > Am Donnerstag, den 24.09.2009, 20:48 -0400 schrieb Matthias Clasen: > > > Tomorrows rawhide will have a new notification theme for Gnome. > > > > > > The aim of this new theme is to integrate well with the theming in the > > > rest of the desktop (which wasn't really the case with nodoka bubbles > > > and a clearlooks desktop). > > > > After I have seen them now I can say I think they are horrible. We could > > really argue if the Nodoka bubbles matched the rest of Nodoka, but this > > definitely matches even less. > > > > I think such changes shouldn't been done as a solo action without > > previous notice. Has the design team been aked about this? (No, Matthias > > and Jon, you are *not* the design team, sorry). Or people from the > > desktop SIG? How about other contributors? > > The design team is busy doing backgrounds. You are busy, the design team is busy. What's the difference? We are all busy at this time of the development cycle I guess. > We _are_ doing the design of the desktop spin, whether you like it or > not. Just like I expect you to do the design of the Xfce spin, and the > KDE team to do the design of their product. I do the design of the Xfce Spin, but I do it different. I'm not making changes without asking for feedback and announcing the changes. When I introduced Nodoka for xfwm4, I did that because I was asked to do it. I posted the result to the mailing lists and *then* made the change. This is a fundamentally different from your solo actions. The order DOES matter, even if Jon says that nothing ever is final. > > IMHO this change is also very ungrateful to Martin, who does an amazing > > job with the Nodoka theme. > > Yes, he is doing a great job with the Nodoka theme. > > How does that imply that we are ungrateful by not sticking with it > forever ? By making a decision without asking the people involved. And Martin definitely is one of these people. Please give him and the rest of the community a chance respond to the problems you have with his/their work. Thanks, Christoph From stickster at gmail.com Wed Sep 30 23:49:12 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 30 Sep 2009 19:49:12 -0400 Subject: A new notification theme In-Reply-To: <939dd5750909290813v371b8bd0h80905cd5cd5d080c@mail.gmail.com> References: <1253839734.1690.51.camel@planemask> <1254229221.2884.157.camel@localhost> <939dd5750909290813v371b8bd0h80905cd5cd5d080c@mail.gmail.com> Message-ID: <20090930234912.GN17146@localhost.localdomain> On Tue, Sep 29, 2009 at 11:13:58AM -0400, William Jon McCann wrote: > At the end of the day we need to stand up and take responsibility for > the end result. To make sure things fit together coherently. That > doesn't mean that these decisions occur in a vacuum or that we don't > need a heck of a lot of help. Nothing is ever final. > > For now, Matthias and I have assumed the (often difficult) > responsibility of trying to fit all our shit together in a way that > doesn't totally suck. We *do* need your help to do that. But that > doesn't mean that we're going to avoid making the often difficult > choices - it is critical that we do. Where's the source? If I was interested in looking at the source, to learn a little about what you're doing, I wouldn't know where to find it. Google only brings me the same link in the RPM information: http://cgit.freedesktop.org/~mccann/notification-daemon-engine-slider The top-level index doesn't show it either. Help? -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug