From jwboyer at jdub.homelinux.org Wed Jun 1 02:09:49 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 31 May 2005 21:09:49 -0500 Subject: Fedora Extras 4/Fedora Extras Development In-Reply-To: <1117576862.18404.62.camel@cutter> References: <1117576862.18404.62.camel@cutter> Message-ID: <1117591789.3107.19.camel@yoda.jdub.homelinux.org> On Tue, 2005-05-31 at 18:01 -0400, seth vidal wrote: > Ok Folks, > The Extras 4 tree has been made and development is now for builds for > to-be-FC5 in the buildsystem. > > I wonder what will break. :) Things seem to be working fine for me. I had builds on FC-3, FC-4, and devel all complete successfully. Thanks and again, the work is appreciated! josh From skvidal at phy.duke.edu Wed Jun 1 20:42:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Jun 2005 16:42:02 -0400 Subject: mailing list weirdness and new builds Message-ID: <1117658522.31018.47.camel@cutter> hey folks, mailing list has been flaky today so I thought I'd say this again: you can go ahead and request new builds again for extras remember: FC4 dir for fedora extras 4 FC3 dir for fedora extras 3 development dir for fedora extras development/rawhide. thanks -sv From skvidal at phy.duke.edu Fri Jun 3 06:47:10 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Jun 2005 02:47:10 -0400 Subject: Buildsystem changes for FE4 builds Message-ID: <1117781230.3488.37.camel@cutter> hi, until just a few minutes ago the only set of packages the buildsystem was using for FE4 builds was drawing from rawhide. With this mornings updates in rawhide rawhide no longer targeted FC4 but FC5 so we ran into a few problems with some packages getting built on a system that looked more like an extremely early FC5/Rawhide than FC4. This was due to the fact that no such set of packages existed that looked like FC4. I've gotten access to the set of packages Elliot is considering FC4-ish so that is now what FE4 requested builds are being built from. I just wanted to give everyone a heads up and to tell you that if you think a build you requested for FE4 was affected by this to make a new build request and we'll get the new package in. Sorry for any problem this caused. -sv From notting at redhat.com Fri Jun 3 17:02:42 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Jun 2005 13:02:42 -0400 Subject: Fedora Core 4 delayed until June 13 Message-ID: <20050603170242.GC6057@nostromo.devel.redhat.com> Due to some unforseen complications, Fedora Core 4 is now scheduled for general availability on June 13. We apologize for the inconvenience. Bill From jwboyer at jdub.homelinux.org Sun Jun 5 21:11:30 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 05 Jun 2005 16:11:30 -0500 Subject: Development areas for Fedora Core/Extras 5 Message-ID: <1118005890.3107.141.camel@yoda.jdub.homelinux.org> Hi All, I went through the "What's next" thread on the fedora-devel list this weekend and tried to pick out some of the ideas that are both feasible and sane. The Wiki page below is my attempt at documenting these and trying to get some focus on them. This is _not_ a complete list in any way, shape, or form but it's at least a start. http://www.fedoraproject.org/wiki/FC5Future Your mission as maintainers, should you choose to accept it [1], is to look over this Wiki page and add, enhance, and think about exactly what we should focus on for Fedora 5. I think it's a mission worth accepting. So lets get to it ;). josh [1] Unfortunately, this message will not self-destruct. So you can't play dumb and say you never saw it :). From mitr at redhat.com Sun Jun 5 22:57:58 2005 From: mitr at redhat.com (Miloslav Trmac) Date: Mon, 6 Jun 2005 00:57:58 +0200 Subject: "I plan to work on..." for FC5 Message-ID: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> Hello world, (Apparently I don't know any better than to send this, which could start another long-lived "future of FC5" thread. Apologies to all if that happens.) Josh's great list has "??" in most "Developer(s)" collumns, let's try to do something about it. The idea is that all e-mails in this thread should start with "I plan to work on ...". This basic filter should separate the doable projects from the obviously impossible. - It is okay to ask for help from other people, as long as you are planning to work on implementing the feature. - It is okay if it turns out that the plan can't be finished; we can't predict the future. - The project in question does not have to be on the current list. - Further discussion about the proposed projects is of course welcome; please change the subject line and try to start a new thread so that violations of the "I plan to work on ..." rule can be easily spotted. Let's see how this will work out. Mirek From mitr at redhat.com Sun Jun 5 23:18:42 2005 From: mitr at redhat.com (Miloslav Trmac) Date: Mon, 6 Jun 2005 01:18:42 +0200 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> Message-ID: <20050605231842.GB3080@amilo.kolej.mff.cuni.cz> On Mon, Jun 06, 2005 at 12:57:58AM +0200, Miloslav Trmac wrote: > The idea is that all e-mails in this thread should start with "I plan to > work on ...". I plan to work on fixing the "resource-hungry cron jobs run when laptop is on battery" problem. My current plan is to do two things: - First, separate the system cron jobs to "should run on schedule" (e. g. logwatch) and "can be delayed" (e.g. prelink), probably by creating /etc/cron.delayed.{daily,weekly,monthly}. This is policy, independent of the cron mechansim; replace cron by something newer and greater for all I care. Then glue this into the current cron/anacron combination so that the cron.delayed jobs are not run on battery, and scheduled to run when the laptop is plugged in. - Second, replace slocate by something smarter. E.g. it should be possible to just record (ctime, mtime) of all scanned directories and use the preexisting database to avoid reading unchanged directories each time: on my system this would reduce the amount of data updatedb has to read from the filesystem from 70 MB to 3.6 MB. Bill Nottingham has proposed a daemon using the audit subystem to watch for filesystem chages. Mirek From skvidal at phy.duke.edu Sun Jun 5 23:48:09 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 19:48:09 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> Message-ID: <1118015289.19379.24.camel@cutter> On Mon, 2005-06-06 at 00:57 +0200, Miloslav Trmac wrote: > Hello world, > (Apparently I don't know any better than to send this, which could start > another long-lived "future of FC5" thread. Apologies to all if that > happens.) > I plan to work on: - helping purge core of duplicate packages and getting the duplicates picked up into extras - making better/more interesting package groups for extras - doing whatever I can to help with anaconda to add yum support for depsolving. - pushing for more of an extended development cycle :) - deploying the second generation of the fedora extras buildsystem - using the extras buildsys code to do a parallel build of core as a way of testing how good the buildsystem code is. - Adding CD support into the repodata creator (createrepo) and teaching yum how to deal with removable media - Helping to make the errata/update announcements be more automated and providing the content in the announcements in such a way as to allow yum and pup access to the notices in runtime. - Getting rid of the ugly-ass fedoraproject.org main page and making the fedora project pages more informative and useful. That's my list for the moment. I'm sure other things will come up. -sv From skvidal at phy.duke.edu Sun Jun 5 23:56:51 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 19:56:51 -0400 Subject: Development areas for Fedora Core/Extras 5 In-Reply-To: <1118005890.3107.141.camel@yoda.jdub.homelinux.org> References: <1118005890.3107.141.camel@yoda.jdub.homelinux.org> Message-ID: <1118015811.19379.32.camel@cutter> On Sun, 2005-06-05 at 16:11 -0500, Josh Boyer wrote: > Hi All, > > I went through the "What's next" thread on the fedora-devel list this > weekend and tried to pick out some of the ideas that are both feasible > and sane. The Wiki page below is my attempt at documenting these and > trying to get some focus on them. This is _not_ a complete list in any > way, shape, or form but it's at least a start. > > http://www.fedoraproject.org/wiki/FC5Future > > Your mission as maintainers, should you choose to accept it [1], is to > look over this Wiki page and add, enhance, and think about exactly what > we should focus on for Fedora 5. I think it's a mission worth > accepting. So lets get to it ;). > Thanks for putting this list together, Josh. I think it will help keep us organized a bit. -sv From skvidal at phy.duke.edu Mon Jun 6 00:06:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 20:06:13 -0400 Subject: heads up for wiki users Message-ID: <1118016373.19379.35.camel@cutter> Hey, I'm going to be messing with the wiki some tonight so if things seem a bit broken, that's why. I'll make a backup of all the data before I blow it up too badly. :) -sv From jwboyer at jdub.homelinux.org Mon Jun 6 00:10:39 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 05 Jun 2005 19:10:39 -0500 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> Message-ID: <1118016639.3107.148.camel@yoda.jdub.homelinux.org> On Mon, 2005-06-06 at 00:57 +0200, Miloslav Trmac wrote: > Hello world, > (Apparently I don't know any better than to send this, which could start > another long-lived "future of FC5" thread. Apologies to all if that > happens.) > > Josh's great list has "??" in most "Developer(s)" collumns, let's try > to do something about it. > > The idea is that all e-mails in this thread should start with "I plan to > work on ...". This basic filter should separate the doable projects from > the obviously impossible. Great idea! > > - It is okay to ask for help from other people, as long as you are planning > to work on implementing the feature. > > - It is okay if it turns out that the plan can't be finished; we can't > predict the future. > > - The project in question does not have to be on the current list. Absolutely correct. Feel free to add projects to the list too. And if you want to work on one that is already listed, put your name in the "Developer(s)" list. Once we get some interest in the projects, the developers working on it can come up with a due date. Btw, if someone feels the page could have better formatting that's cool too. My wiki skillz aren't the best ;) josh From jgarzik at redhat.com Mon Jun 6 02:58:15 2005 From: jgarzik at redhat.com (Jeff Garzik) Date: Sun, 5 Jun 2005 22:58:15 -0400 Subject: FC4 looking good Message-ID: <20050606025815.GA30746@devserv.devel.redhat.com> Kudos too all involved, FC4 is looking good. The regressions from FC2 I found in FC4.re0603.2: * If you use "startx", ssh-agent is not started. * Backspace doesn't work in vim, in xterm. Must use Ctrl-H. And one installer bug: * If you do an HD install, there is no way in the installer to add the install source to /etc/fstab. From davej at redhat.com Mon Jun 6 03:22:40 2005 From: davej at redhat.com (Dave Jones) Date: Sun, 5 Jun 2005 23:22:40 -0400 Subject: FC4 looking good In-Reply-To: <20050606025815.GA30746@devserv.devel.redhat.com> References: <20050606025815.GA30746@devserv.devel.redhat.com> Message-ID: <20050606032240.GA30632@redhat.com> On Sun, Jun 05, 2005 at 10:58:15PM -0400, Jeff Garzik wrote: > > Kudos too all involved, FC4 is looking good. > > > The regressions from FC2 I found in FC4.re0603.2: > > * If you use "startx", ssh-agent is not started. > > * Backspace doesn't work in vim, in xterm. Must use Ctrl-H. Works for me, though I've had.. imap ^? ^? cmap ^? ^? in my ~/.vimrc since I can remember, possibly because something like this happened some time ago ;-) Dave From wtogami at redhat.com Mon Jun 6 06:00:34 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 05 Jun 2005 20:00:34 -1000 Subject: FC4 looking good In-Reply-To: <20050606025815.GA30746@devserv.devel.redhat.com> References: <20050606025815.GA30746@devserv.devel.redhat.com> Message-ID: <42A3E682.7080907@redhat.com> Jeff Garzik wrote: > Kudos too all involved, FC4 is looking good. > > > The regressions from FC2 I found in FC4.re0603.2: > > * If you use "startx", ssh-agent is not started. > What environment starts with your startx? Warren From jgarzik at redhat.com Mon Jun 6 06:04:45 2005 From: jgarzik at redhat.com (Jeff Garzik) Date: Mon, 6 Jun 2005 02:04:45 -0400 Subject: FC4 looking good In-Reply-To: <42A3E682.7080907@redhat.com> References: <20050606025815.GA30746@devserv.devel.redhat.com> <42A3E682.7080907@redhat.com> Message-ID: <20050606060445.GA28777@devserv.devel.redhat.com> On Sun, Jun 05, 2005 at 08:00:34PM -1000, Warren Togami wrote: > Jeff Garzik wrote: > >Kudos too all involved, FC4 is looking good. > > > > > >The regressions from FC2 I found in FC4.re0603.2: > > > >* If you use "startx", ssh-agent is not started. > > > > What environment starts with your startx? KDE. Jeff From jgarzik at redhat.com Mon Jun 6 06:15:34 2005 From: jgarzik at redhat.com (Jeff Garzik) Date: Mon, 6 Jun 2005 02:15:34 -0400 Subject: FC4 looking good In-Reply-To: <20050606025815.GA30746@devserv.devel.redhat.com> References: <20050606025815.GA30746@devserv.devel.redhat.com> Message-ID: <20050606061534.GA29965@devserv.devel.redhat.com> On Sun, Jun 05, 2005 at 10:58:15PM -0400, Jeff Garzik wrote: > > Kudos too all involved, FC4 is looking good. > > > The regressions from FC2 I found in FC4.re0603.2: > > * If you use "startx", ssh-agent is not started. > > * Backspace doesn't work in vim, in xterm. Must use Ctrl-H. Another late-breaking one: Thunderbird crashed while trying to import my Mozilla Mail folders and data. Each attempt at starting Thunderbird would result in a segfault, after that. Removing ~/.thunderbird and -not- importing Mozilla data allowed me to start TBird and manually import folders. TBird is working fine for me this way -- just DON'T do an import from Mozilla. Jeff From wtogami at redhat.com Mon Jun 6 06:25:48 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 05 Jun 2005 20:25:48 -1000 Subject: FC4 looking good In-Reply-To: <20050606061534.GA29965@devserv.devel.redhat.com> References: <20050606025815.GA30746@devserv.devel.redhat.com> <20050606061534.GA29965@devserv.devel.redhat.com> Message-ID: <42A3EC6C.4000705@redhat.com> Jeff Garzik wrote: > On Sun, Jun 05, 2005 at 10:58:15PM -0400, Jeff Garzik wrote: > >>Kudos too all involved, FC4 is looking good. >> >> >>The regressions from FC2 I found in FC4.re0603.2: >> >>* If you use "startx", ssh-agent is not started. >> >>* Backspace doesn't work in vim, in xterm. Must use Ctrl-H. > > > Another late-breaking one: > > Thunderbird crashed while trying to import my Mozilla Mail folders and > data. Each attempt at starting Thunderbird would result in a segfault, > after that. > > Removing ~/.thunderbird and -not- importing Mozilla data allowed me to > start TBird and manually import folders. > > TBird is working fine for me this way -- just DON'T do an import from > Mozilla. > Can you use a new user and attempt to create a small test-case that we are able to submit upstream for this? Warren From wtogami at redhat.com Mon Jun 6 06:28:10 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 05 Jun 2005 20:28:10 -1000 Subject: FC4 looking good In-Reply-To: <42A3EC6C.4000705@redhat.com> References: <20050606025815.GA30746@devserv.devel.redhat.com> <20050606061534.GA29965@devserv.devel.redhat.com> <42A3EC6C.4000705@redhat.com> Message-ID: <42A3ECFA.7080902@redhat.com> Warren Togami wrote: >> >> Removing ~/.thunderbird and -not- importing Mozilla data allowed me to >> start TBird and manually import folders. >> >> TBird is working fine for me this way -- just DON'T do an import from >> Mozilla. >> > > Can you use a new user and attempt to create a small test-case that we > are able to submit upstream for this? > > Warren > debuginfo and traceback would be helpful too... but submit it upstream. Warren From j.w.r.degoede at hhs.nl Mon Jun 6 07:57:51 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 06 Jun 2005 09:57:51 +0200 Subject: FC4 looking good In-Reply-To: <20050606025815.GA30746@devserv.devel.redhat.com> References: <20050606025815.GA30746@devserv.devel.redhat.com> Message-ID: <42A401FF.9090307@hhs.nl> Jeff Garzik wrote: > Kudos too all involved, FC4 is looking good. > > > The regressions from FC2 I found in FC4.re0603.2: > > * Backspace doesn't work in vim, in xterm. Must use Ctrl-H. > I already predicted this see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155538 Regards, Hans From jgarzik at redhat.com Mon Jun 6 08:16:52 2005 From: jgarzik at redhat.com (Jeff Garzik) Date: Mon, 6 Jun 2005 04:16:52 -0400 Subject: FC4 looking good In-Reply-To: <42A401FF.9090307@hhs.nl> References: <20050606025815.GA30746@devserv.devel.redhat.com> <42A401FF.9090307@hhs.nl> Message-ID: <20050606081652.GB29965@devserv.devel.redhat.com> On Mon, Jun 06, 2005 at 09:57:51AM +0200, Hans de Goede wrote: > Jeff Garzik wrote: > >Kudos too all involved, FC4 is looking good. > > > > > >The regressions from FC2 I found in FC4.re0603.2: > > > >* Backspace doesn't work in vim, in xterm. Must use Ctrl-H. > > > > I already predicted this see: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155538 hrm. Well screwing up backspace in the -default- configuration is pretty ugly. Jeff From blizzard at redhat.com Mon Jun 6 13:55:27 2005 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 06 Jun 2005 09:55:27 -0400 Subject: Development areas for Fedora Core/Extras 5 In-Reply-To: <1118015811.19379.32.camel@cutter> References: <1118005890.3107.141.camel@yoda.jdub.homelinux.org> <1118015811.19379.32.camel@cutter> Message-ID: <42A455CF.90000@redhat.com> On the Directory Server component, we do have admin tools and will be open sourcing them soon (they are included in the binary package, just not as source yet.) --Chris seth vidal wrote: > On Sun, 2005-06-05 at 16:11 -0500, Josh Boyer wrote: > >>Hi All, >> >>I went through the "What's next" thread on the fedora-devel list this >>weekend and tried to pick out some of the ideas that are both feasible >>and sane. The Wiki page below is my attempt at documenting these and >>trying to get some focus on them. This is _not_ a complete list in any >>way, shape, or form but it's at least a start. >> >>http://www.fedoraproject.org/wiki/FC5Future >> >>Your mission as maintainers, should you choose to accept it [1], is to >>look over this Wiki page and add, enhance, and think about exactly what >>we should focus on for Fedora 5. I think it's a mission worth >>accepting. So lets get to it ;). >> > > > Thanks for putting this list together, Josh. I think it will help keep > us organized a bit. > > -sv > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From blizzard at redhat.com Mon Jun 6 13:57:30 2005 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 06 Jun 2005 09:57:30 -0400 Subject: FC4 looking good In-Reply-To: <20050606025815.GA30746@devserv.devel.redhat.com> References: <20050606025815.GA30746@devserv.devel.redhat.com> Message-ID: <42A4564A.6090206@redhat.com> I dunno - sound is pretty hosed on my laptop. I imagine that others are suffering as well. Apps like rhythmbox and xmms will sometimes just start playing garbage, skipping through to the end of a song very quickly. --Chris Jeff Garzik wrote: > Kudos too all involved, FC4 is looking good. > > > The regressions from FC2 I found in FC4.re0603.2: > > * If you use "startx", ssh-agent is not started. > > * Backspace doesn't work in vim, in xterm. Must use Ctrl-H. > > > And one installer bug: > > * If you do an HD install, there is no way in the installer to add the > install source to /etc/fstab. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From jwboyer at jdub.homelinux.org Tue Jun 7 02:00:29 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 06 Jun 2005 21:00:29 -0500 Subject: Development areas for Fedora Core/Extras 5 In-Reply-To: <42A455CF.90000@redhat.com> References: <1118005890.3107.141.camel@yoda.jdub.homelinux.org> <1118015811.19379.32.camel@cutter> <42A455CF.90000@redhat.com> Message-ID: <1118109629.3107.157.camel@yoda.jdub.homelinux.org> On Mon, 2005-06-06 at 09:55 -0400, Christopher Blizzard wrote: > On the Directory Server component, we do have admin tools and will be > open sourcing them soon (they are included in the binary package, just > not as source yet.) Cool. Care to list yourself as a Developer? (or I can do it if needs be...) josh From twaugh at redhat.com Wed Jun 8 09:53:50 2005 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 8 Jun 2005 10:53:50 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> Message-ID: <20050608095350.GV8706@redhat.com> I plan to work on: * ghostscript - switch our ghostscript package to ESP Ghostscript - upgrade to 8.15 (new major version) - avoid regressions compared to the FC4 package * HPLIP - package, based on Mandriva spec file - replace hpoj/hpijs - might include foomatic work - possible to migrate hpoj config? * Foomatic - update to latest database - work on PPD storage/retrieval * Gutenprint - package - replace gimp-print - includes system-config-printer work (updateconf) * CUPS 1.2.x work? - not sure what the upstream release schedule is Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gbenson at redhat.com Wed Jun 8 10:22:56 2005 From: gbenson at redhat.com (Gary Benson) Date: Wed, 8 Jun 2005 11:22:56 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> Message-ID: <20050608102255.GB4874@redhat.com> I plan to work on getting JOnAS into FC5. Cheers, Gary From pjones at redhat.com Wed Jun 8 13:14:24 2005 From: pjones at redhat.com (Peter Jones) Date: Wed, 08 Jun 2005 09:14:24 -0400 Subject: FC4 looking good In-Reply-To: <20050606025815.GA30746@devserv.devel.redhat.com> References: <20050606025815.GA30746@devserv.devel.redhat.com> Message-ID: <1118236464.8818.0.camel@localhost.localdomain> On Sun, 2005-06-05 at 22:58 -0400, Jeff Garzik wrote: > And one installer bug: > > * If you do an HD install, there is no way in the installer to add the > install source to /etc/fstab. Well, there's always %post in kickstart. It's not a good answer for interactive installs, though. -- Peter From pmatilai at laiskiainen.org Wed Jun 8 15:22:16 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 08 Jun 2005 18:22:16 +0300 Subject: FC4 looking good In-Reply-To: <1118236464.8818.0.camel@localhost.localdomain> References: <20050606025815.GA30746@devserv.devel.redhat.com> <1118236464.8818.0.camel@localhost.localdomain> Message-ID: <1118244136.15436.1.camel@weasel.laiskiainen.org> On Wed, 2005-06-08 at 09:14 -0400, Peter Jones wrote: > On Sun, 2005-06-05 at 22:58 -0400, Jeff Garzik wrote: > > > And one installer bug: > > > > * If you do an HD install, there is no way in the installer to add the > > install source to /etc/fstab. > > Well, there's always %post in kickstart. It's not a good answer for > interactive installs, though. Well you can always use an "interactive" kickstart, which just asks you all the questions which you'd normally get in anaconda but has defaults from the ks.cfg and then as an added bonus you can run stuff from %post. I've found that plenty useful at work... - Panu - From thomas at apestaart.org Wed Jun 8 18:45:38 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Wed, 08 Jun 2005 20:45:38 +0200 Subject: FC4 looking good In-Reply-To: <42A4564A.6090206@redhat.com> References: <20050606025815.GA30746@devserv.devel.redhat.com> <42A4564A.6090206@redhat.com> Message-ID: <1118256338.23431.7.camel@www.fluendo.com.local> Hi, On Mon, 2005-06-06 at 09:57 -0400, Christopher Blizzard wrote: > I dunno - sound is pretty hosed on my laptop. I imagine that others are > suffering as well. Apps like rhythmbox and xmms will sometimes just > start playing garbage, skipping through to the end of a song very quickly. this is dmix. dmix is hosed for a lot of people currently. On my laptop, it can do any of the following after a short time (say, 5 min) of music playing: a) scramble the sound completely (similar to what you just said) b) stop playing, use no CPU c) stop playing, use 100% CPU Other people I've polled on this using FC3 and FC4 test releases have had the same issues - though not necessarily all three. I've discussed this with some people directly on IRC. I've discussed this with some people at GUADEC as well, but I can't figure out if FC4 is going to ship with dmix turned on by default. I don't really know for sure either who is "responsible" at redhat for this part of the stack - though I have some likely suspects I maybe should target :) Anyway, here is a strong warning against it - it is just not ready yet for a lot of drivers. Stuff needs to be fixed first, and clueful people need to look at the problem. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Welcome to Hits City, Jeff K - Population: you <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From notting at redhat.com Wed Jun 8 20:01:34 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 8 Jun 2005 16:01:34 -0400 Subject: FC4 looking good In-Reply-To: <1118256338.23431.7.camel@www.fluendo.com.local> References: <20050606025815.GA30746@devserv.devel.redhat.com> <42A4564A.6090206@redhat.com> <1118256338.23431.7.camel@www.fluendo.com.local> Message-ID: <20050608200134.GA28658@nostromo.devel.redhat.com> Thomas Vander Stichele (thomas at apestaart.org) said: > this is dmix. dmix is hosed for a lot of people currently. On my > laptop, it can do any of the following after a short time (say, 5 min) > of music playing: > > a) scramble the sound completely (similar to what you just said) > b) stop playing, use no CPU > c) stop playing, use 100% CPU > > Other people I've polled on this using FC3 and FC4 test releases have > had the same issues - though not necessarily all three. Hm, with current code, I'm not seeing any issues with dmix as long as I don't use ESD. I suppose that could depend based on driver, though. > I've discussed this with some people directly on IRC. I've discussed > this with some people at GUADEC as well, but I can't figure out if FC4 > is going to ship with dmix turned on by default. Yes, it is. Bill From caillon at redhat.com Wed Jun 8 20:06:11 2005 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 08 Jun 2005 16:06:11 -0400 Subject: FC4 looking good In-Reply-To: <20050606061534.GA29965@devserv.devel.redhat.com> References: <20050606025815.GA30746@devserv.devel.redhat.com> <20050606061534.GA29965@devserv.devel.redhat.com> Message-ID: <42A74FB3.7040307@redhat.com> Jeff Garzik wrote: > Another late-breaking one: > > Thunderbird crashed while trying to import my Mozilla Mail folders and > data. Each attempt at starting Thunderbird would result in a segfault, > after that. > > Removing ~/.thunderbird and -not- importing Mozilla data allowed me to > start TBird and manually import folders. > > TBird is working fine for me this way -- just DON'T do an import from > Mozilla. Perhaps this is https://bugzilla.mozilla.org/show_bug.cgi?id=285305 If you try the workaround noted in comment 1 there, does it work for you Jeff? From mharris at www.linux.org.uk Wed Jun 8 21:39:59 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Wed, 08 Jun 2005 17:39:59 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050526215928.43e908b1.bugs.michael@gmx.net> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <42960A4F.3080502@www.linux.org.uk> <20050526215928.43e908b1.bugs.michael@gmx.net> Message-ID: <42A765AF.1070304@www.linux.org.uk> Michael Schwendt wrote: >>>>>>Is there a reason not to leave such bugs in NEEDINFO state forever? >>>> >>>>>Yes. Then there are 100000 bugs open forever, that will never >>>>>be addressed. >>>> >>>>Fair enough. What about adding a resolution category "closed for lack >>>>of information", which we could use if something stays in NEEDINFO >>>>too long? Or I suppose we could use WORKSFORME ... >>> >>> >>>NEEDINFO -> no reply -> WONTFIX : that really is the most true >>>resolution. Without feedback, the bug won't be fixed because it won't be >>>examined further. Just explain that when closing the ticket. Keep in mind >>>that the reporter can reopen the ticket as soon as new feedback is >>>provided. >> >>I disagree. There are different ways to say the same thing, and >>while "WONTFIX" is very much true, it is NOT the best way of saying >>it. Or should I say instead - There are better ways of saying >>"WONTFIX" that are more positive and friendly. >> >>One could argue GO_TO_HELL is a "true" resolution for some bugs, >>but is it "friendly"? Is it "proactive"? Does it give the >>reporter a warm feeling in their stomach? >> >>No. > > > Well, bugzilla.fedora.us has RESOLVED/REMIND -- if the plan is to add new > resolutions or rename existing ones, I'm all for doing that. I only > thought that a WONTFIX cannot look negative if the added comment gives > the rationale. In my experience, that line of thought is false. Overall, the mass populace is reactive in nature. By using negative/reactive language, it just breeds more of the same in response. If you use a positive/proactive word instead, then the mood is set "positive" from the outset, and an additional explanation can clarify it further if desired/deemed necessary. Using an all-caps negative word, and trying to explain "why" with some rationale, the person has already had the mood set from the "WONTFIX", and you then must struggle to come up with some overly long explanation with which to hope they aren't offended. It's a losing ballgame no matter how you slice it, as long as negative/reactive terminology is used. From mharris at www.linux.org.uk Wed Jun 8 21:48:36 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Wed, 08 Jun 2005 17:48:36 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050527180412.GA16193@jadzia.bu.edu> References: <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <604aa79105052509045957fa84@mail.gmail.com> <4295E522.7060406@www.linux.org.uk> <20050526155921.GA1841@jadzia.bu.edu> <604aa79105052609406d7c8278@mail.gmail.com> <42960C56.8090907@www.linux.org.uk> <20050527180412.GA16193@jadzia.bu.edu> Message-ID: <42A767B4.2000200@www.linux.org.uk> Matthew Miller wrote: > On Thu, May 26, 2005 at 01:50:14PM -0400, Mike A. Harris wrote: > >>The psychological effects of saying "WONT", "CANT", "DONT", >>"NOT*" are to stimulate a negative experience in the mind >>of the reader, and should be avoided if at all possible. > > > This would lend support to using "DEFERRED". > > Anyway, thanks everyone for your comments. For right now, I'm going to leave > all the bugs in NEEDINFO state while I reflect on everything. I disagree. DEFERRED == PROCRASTINATED_WITH_NO_ACTUAL_TARGET If something is going to be done, it should be left open, and assigned to an active target tracking bug, such as FC4Target, FC5Target, etc. and an explicit "goal" defined for that target. Example: Target: FC5Target Goal: Examine this issue during FC5 development and make a further decision as to wether to dump it, or do it. If the decision is made at that time to "do it", a solid decisive plan will be made with timelines. "DEFERRED" essentially amounts to "indefinitely procrastinated with no goal or solid decision being made". Our team have specifically been avoiding such indecision as much as possible for the last 6 months or so, trying to make solid decisions with each phase of a bug's life, to both reduce the active bug list, and to reduce the lifespan of bugs to a minimum. If we know we are going to do something, or feel that it is something plausible, we should be able to give it a specific target - even if that target is just for the purpose of determining what is next. On the other side, if we know we are -not- going to do something, we've decided to close the issue ASAP, with a reasonably worded comment. This has worked rather well in practice for our team at least to date. Negative customer/user response has been almost nonexistant, which leads me to believe what we're doing is fairly successful in reaching our goal. YMMV of course... From mharris at www.linux.org.uk Wed Jun 8 21:55:28 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Wed, 08 Jun 2005 17:55:28 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <80d7e409050528220078cb9b35@mail.gmail.com> References: <20050524225412.GA24363@jadzia.bu.edu> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> Message-ID: <42A76950.7060705@www.linux.org.uk> Stephen J. Smoogen wrote: >>NEEDINFO -> no reply -> WONTFIX : that really is the most true >>resolution. Without feedback, the bug won't be fixed because it won't be >>examined further. Just explain that when closing the ticket. Keep in mind >>that the reporter can reopen the ticket as soon as new feedback is >>provided. > > > Actually a better resolution would be > > CANTFIX_WO_INFO (resting). > > or just > > CANTFIX > > This is a better answer in some cases to WONTFIX... but leads to even > more bugzilla choices... (Some anthropologist looking at this in 100 > years will say "Bugzilla users like eskimos had 200 ways of saying > CLOSED.) This is a perfect example of what I was refering to as negative/reactive versus positive/proactive. CANT/WONT/DONT/NOT are reactive/negative words, so if you say "CANTFIX_WITHOUT_INFO", you're really saying a negatively worded form of what can be stated more proactively as: "CANFIX_ONCE_INFO_IS_SUPPLIED". However, "CANFIX" implies that you (or someone) "can" actually fix the issue, which in reality may not be true. As such, I would refrain from using CANFIX. Proactivity focuses on stating what you will do, so I would use something like: WILL_REVIEW_ONCE_REQUESTED_INFO_IS_SUPPLIED Again, some may argue pedantics here, but there is sound scientific evidence of the psychology behind this stuff. I've directly seen a change in response from users/customers by changing the language used in response to bug reports to be much more proactive, and it does very much pay off. The easy thing to do is instead of telling the person what we can not do, or will not do - but to focus on what we _WILL_ do, and when/how/why/etc. It is sometimes a bit challenging to word things in this manner if one is used to using reactionary language a lot, but it gets easier over time. ;o) From mattdm at mattdm.org Wed Jun 8 23:40:59 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Jun 2005 19:40:59 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <42A76950.7060705@www.linux.org.uk> References: <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42A76950.7060705@www.linux.org.uk> Message-ID: <20050608234059.GA1357@jadzia.bu.edu> On Wed, Jun 08, 2005 at 05:55:28PM -0400, Mike A. Harris wrote: > However, "CANFIX" implies that you (or someone) "can" actually > fix the issue, which in reality may not be true. As such, I would > refrain from using CANFIX. Proactivity focuses on stating what > you will do, so I would use something like: > WILL_REVIEW_ONCE_REQUESTED_INFO_IS_SUPPLIED I think this is a great idea provided we can somehow condense it down to, like, 12 letters :) and, crucially, if someone _does_ provide info, they get some kind of reaction. (Which I understand is hard.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From mharris at www.linux.org.uk Wed Jun 8 23:52:17 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Wed, 08 Jun 2005 19:52:17 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050608234059.GA1357@jadzia.bu.edu> References: <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42A76950.7060705@www.linux.org.uk> <20050608234059.GA1357@jadzia.bu.edu> Message-ID: <42A784B1.6070005@www.linux.org.uk> Matthew Miller wrote: > On Wed, Jun 08, 2005 at 05:55:28PM -0400, Mike A. Harris wrote: > >>However, "CANFIX" implies that you (or someone) "can" actually >>fix the issue, which in reality may not be true. As such, I would >>refrain from using CANFIX. Proactivity focuses on stating what >>you will do, so I would use something like: >>WILL_REVIEW_ONCE_REQUESTED_INFO_IS_SUPPLIED > > > I think this is a great idea provided we can somehow condense it down to, > like, 12 letters :) and, crucially, if someone _does_ provide info, they get > some kind of reaction. (Which I understand is hard.) AWAITING_INFO or PENDING_INFO. When a bug is in any "closed" state, and someone supplies more info, it is their responsibility to set the state back to "REOPENED" so that the issue is reactivated as an open issue however. Then it should get added to queues as appropriate, depending on how each team handles bugs, as this is still a team specific handling issue, and in most cases, an individual developer bug handling issue. Ultimately, both users and developers would benefit more from global bug handling methodology consistency, but that's a long way off IMHO. From mattdm at mattdm.org Wed Jun 8 23:53:36 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Jun 2005 19:53:36 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <42A767B4.2000200@www.linux.org.uk> References: <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <604aa79105052509045957fa84@mail.gmail.com> <4295E522.7060406@www.linux.org.uk> <20050526155921.GA1841@jadzia.bu.edu> <604aa79105052609406d7c8278@mail.gmail.com> <42960C56.8090907@www.linux.org.uk> <20050527180412.GA16193@jadzia.bu.edu> <42A767B4.2000200@www.linux.org.uk> Message-ID: <20050608235336.GB1357@jadzia.bu.edu> On Wed, Jun 08, 2005 at 05:48:36PM -0400, Mike A. Harris wrote: > >This would lend support to using "DEFERRED". > >Anyway, thanks everyone for your comments. For right now, I'm going to > >leave all the bugs in NEEDINFO state while I reflect on everything. > I disagree. DEFERRED == PROCRASTINATED_WITH_NO_ACTUAL_TARGET Well, to be blunt, as not- at -redhat, that kinda feels like the honest thing to be saying for a lot of these bugs. > If something is going to be done, it should be left open, and > assigned to an active target tracking bug, such as FC4Target, > FC5Target, etc. and an explicit "goal" defined for that target. This would clearly be *better*, but are there resources to do it? Or the commitment? [...] > "DEFERRED" essentially amounts to "indefinitely procrastinated > with no goal or solid decision being made". Our team have > specifically been avoiding such indecision as much as possible > for the last 6 months or so, trying to make solid decisions > with each phase of a bug's life, to both reduce the active bug > list, and to reduce the lifespan of bugs to a minimum. And if I remember right without doing a bunch of bugzilla searches right now, there are few if any pre-FC3 xorg.org or xgl-maint at redhat.com-assigned bugs in open or "limbo" states. And only a handful for FC3. So assuming that's the team you're talking about, awesome job -- and it lends a lot of credibility to what you're saying. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From blizzard at redhat.com Thu Jun 9 00:14:25 2005 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 08 Jun 2005 20:14:25 -0400 Subject: FC4 looking good In-Reply-To: <1118256338.23431.7.camel@www.fluendo.com.local> References: <20050606025815.GA30746@devserv.devel.redhat.com> <42A4564A.6090206@redhat.com> <1118256338.23431.7.camel@www.fluendo.com.local> Message-ID: <42A789E1.6010306@redhat.com> Yeah, I see all those symptoms as well. --Chris Thomas Vander Stichele wrote: > Hi, > > On Mon, 2005-06-06 at 09:57 -0400, Christopher Blizzard wrote: > >>I dunno - sound is pretty hosed on my laptop. I imagine that others are >>suffering as well. Apps like rhythmbox and xmms will sometimes just >>start playing garbage, skipping through to the end of a song very quickly. > > > this is dmix. dmix is hosed for a lot of people currently. On my > laptop, it can do any of the following after a short time (say, 5 min) > of music playing: > > a) scramble the sound completely (similar to what you just said) > b) stop playing, use no CPU > c) stop playing, use 100% CPU > > Other people I've polled on this using FC3 and FC4 test releases have > had the same issues - though not necessarily all three. > > I've discussed this with some people directly on IRC. I've discussed > this with some people at GUADEC as well, but I can't figure out if FC4 > is going to ship with dmix turned on by default. I don't really know > for sure either who is "responsible" at redhat for this part of the > stack - though I have some likely suspects I maybe should target :) > > Anyway, here is a strong warning against it - it is just not ready yet > for a lot of drivers. Stuff needs to be fixed first, and clueful people > need to look at the problem. > > Thomas > > > Dave/Dina : future TV today ! - http://www.davedina.org/ > <-*- thomas (dot) apestaart (dot) org -*-> > Welcome to Hits City, Jeff K - Population: you > <-*- thomas (at) apestaart (dot) org -*-> > URGent, best radio on the net - 24/7 ! - http://urgent.fm/ > > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From mharris at www.linux.org.uk Thu Jun 9 00:24:39 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Wed, 08 Jun 2005 20:24:39 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050608235336.GB1357@jadzia.bu.edu> References: <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <604aa79105052509045957fa84@mail.gmail.com> <4295E522.7060406@www.linux.org.uk> <20050526155921.GA1841@jadzia.bu.edu> <604aa79105052609406d7c8278@mail.gmail.com> <42960C56.8090907@www.linux.org.uk> <20050527180412.GA16193@jadzia.bu.edu> <42A767B4.2000200@www.linux.org.uk> <20050608235336.GB1357@jadzia.bu.edu> Message-ID: <42A78C47.9030805@www.linux.org.uk> Matthew Miller wrote: > On Wed, Jun 08, 2005 at 05:48:36PM -0400, Mike A. Harris wrote: > >>>This would lend support to using "DEFERRED". >>>Anyway, thanks everyone for your comments. For right now, I'm going to >>>leave all the bugs in NEEDINFO state while I reflect on everything. >> >>I disagree. DEFERRED == PROCRASTINATED_WITH_NO_ACTUAL_TARGET > > > Well, to be blunt, as not- at -redhat, that kinda feels like the honest thing > to be saying for a lot of these bugs. I'm of the opinion that every single bug report that comes in, should have an initial "triage" which consists of at least one person reviewing the bug, updating the status to request more information if necessary, and deciding wether to close the bug, or to keep it open. If "keep it open" is the decision, then the "next step" should be decided, and a target of some sort given to the bug - either data based, or milestone based. The goal of the target is not necessarily to "fix the bug" or "solve the problem", but it can and often will be. Other possibilities include merely "reviewing" the issue, or digging into it deeper and performing another decision making step to determine what is "next" in the life of the bug. Right now, a lot of bugs are just left open forever with no definite decision made, because it appears that there is no solid decision that can be made, or because there aren't enough hours in a day, or one of many other reasons which vary from package to package, release to release, developer to developer, and problem category to problem category. Nonetheless, having concrete decisions of some kind helps to keep the total list of issues cleaned up. A perpetually increasing list of "things to do when we get around to it" just ends up being a list of things that will never get done - ever. There might be the odd exception here and there I'm sure, but the exception does not make the rule of course. It's better to make a solid decision which later turns out to be a bad decision, than to be indecisive IMHO. Bad decisions cause learning experiences, and often can be corrected later anyway, which creates a better net result in the long run. >>If something is going to be done, it should be left open, and >>assigned to an active target tracking bug, such as FC4Target, >>FC5Target, etc. and an explicit "goal" defined for that target. > > This would clearly be *better*, but are there resources to do it? Or the > commitment? Bugzilla bug handling is a per-developer thing. There are general guidlines, but not really any strict policies adhered to across all of engineering. I personally believe that it is an area that we should focus on in the future, to strive for consistency, but I'm not aware of any specific resources allotted to this at this point in time. I have helped develop a methodology for our team (X Engineering), which we've been using for a while now with good results, but this is limited in scope right now to 4 developers. Wether there are resources to do it, or commitment to do it would be up to someone in higher level management, and only likely if the problem was considered big enough to both make it on radar, and also to not be buried under higher priority things that such resources would be better spent on. I don't know the answer to that however, which is why our team developed our own guidelines rather than waiting for a larger effort to form. Perhaps our methodology can be extended and used by other groups. It's something to start with at least. >>"DEFERRED" essentially amounts to "indefinitely procrastinated >>with no goal or solid decision being made". Our team have >>specifically been avoiding such indecision as much as possible >>for the last 6 months or so, trying to make solid decisions >>with each phase of a bug's life, to both reduce the active bug >>list, and to reduce the lifespan of bugs to a minimum. > > > And if I remember right without doing a bunch of bugzilla searches right > now, there are few if any pre-FC3 xorg.org or xgl-maint at redhat.com-assigned > bugs in open or "limbo" states. And only a handful for FC3. So assuming > that's the team you're talking about, awesome job -- and it lends a lot of > credibility to what you're saying. Correct. In the last 12 months roughly, I have personally went through every single bug in bugzilla assigned to myself and/or xgl-maint, and applied the new methodology to it, while also evolving the methodology as was deemed necessary to solve problems that arose. The goals our team decided were important were to work towards what we termed "steady state", which roughly is described as: 1) Every bug filed in bugzilla, gets an initial triage/review by someone within n days. The value of n initially would be a larger number, with a goal of reducing n over time as processes refine. The initial value of n was to aim for 7 days minimum initial response time, 21 day maximum response time. This is something that is still evolving. 2) Once a bug has been triaged, it immediately moves to another state. If kept open, it must be moved to ASSIGNED or NEEDINFO as appropriate. If closed, an appropriate comment is supplied for the reason for closing/resolving the bug, and if the issue is fixed, an indication of where it was fixed (ie: in Rawhide, errata, etc.) 3) If a bug is open, and has enough information supplied already that no additional info is required from reporter, etc. - then it is put into ASSIGNED state, and assigned to a target bug (ie: FC5Target) Over time, lists of bugs are reviewed for processing. "NEW" bugs, bugs in "NEEDINFO" for n days with no response, "UPSTREAM" flagged bugs being tracked are reviewed every n days, and bugs not assigned to a target are reviewed every so often to assign them to a target, request more info, upstream them, or close them. Additionally, locating bugs that are not Red Hat OS specific, and having the reporter report them to the horse's mouth upstream project is a goal for many classes of bugs, in particular bugs that are hardware specific that we don't have the hardware for, or for things like the "nv" driver or other issues that require hardware or hardware knowledge that only upstream people have for a given area. That cuts down on a LOT of issues, and also has proven to be a faster way of seeing certain classes of bugs actually get fixed - once the upstream folks responsible for an area of code are made aware there is a problem. Additionally, it was a goal to go through all bugs previously marked as "DEFERRED", and pass them through this more solid decision making process, either closing them outright, or moving them to an appropriate state. It took a long time, spread over about a year to get it to what it is now, but we went from almost 600 open bugs, down to about 80 open bugs now. It's much easier to see what the higher priority issues are, and to get on top of things now, than it was wading through 600 bugs before. ;o) There's still a lot of room for improvement, both to our process, and to bugzilla itself, but the current method our team is using, works pretty well within the existing confines. I aim to get the steady-state bug count down below 50 by the time FC4 sails. Hope this is useful info. ;) From jspaleta at gmail.com Thu Jun 9 01:09:04 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 8 Jun 2005 21:09:04 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <42A78C47.9030805@www.linux.org.uk> References: <20050525030418.GA31087@jadzia.bu.edu> <604aa79105052509045957fa84@mail.gmail.com> <4295E522.7060406@www.linux.org.uk> <20050526155921.GA1841@jadzia.bu.edu> <604aa79105052609406d7c8278@mail.gmail.com> <42960C56.8090907@www.linux.org.uk> <20050527180412.GA16193@jadzia.bu.edu> <42A767B4.2000200@www.linux.org.uk> <20050608235336.GB1357@jadzia.bu.edu> <42A78C47.9030805@www.linux.org.uk> Message-ID: <604aa79105060818093f1d606f@mail.gmail.com> On 6/8/05, Mike A. Harris wrote: > I'm of the opinion that every single bug report that comes in, > should have an initial "triage" which consists of at least one > person reviewing the bug, updating the status to request more > information if necessary, and deciding wether to close the bug, > or to keep it open. If "keep it open" is the decision, then > the "next step" should be decided, and a target of some sort > given to the bug - either data based, or milestone based. Distro wide... thats really tough. I failed at making any sort of appreciable dent at this as a community based effort. If we were talking about just gnome+apps or just kde+apps or just x even you could probably build up a small team of community who as the gained experience become better at dealing with bug reports in that area of the distro. But distro wide its hard to capture enough initial interest from enough people with enough experience to cover all the bases. Even if there were enough monkeys to go around.. how do you train them all? We might get somewhere focusing on a corner of the fedora bugzilla space.. creating a small group of package shepards and then moving on to another corner every release. -jef From tgl at redhat.com Thu Jun 9 06:46:38 2005 From: tgl at redhat.com (Tom Lane) Date: Thu, 09 Jun 2005 02:46:38 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <604aa79105060818093f1d606f@mail.gmail.com> References: <20050525030418.GA31087@jadzia.bu.edu> <604aa79105052509045957fa84@mail.gmail.com> <4295E522.7060406@www.linux.org.uk> <20050526155921.GA1841@jadzia.bu.edu> <604aa79105052609406d7c8278@mail.gmail.com> <42960C56.8090907@www.linux.org.uk> <20050527180412.GA16193@jadzia.bu.edu> <42A767B4.2000200@www.linux.org.uk> <20050608235336.GB1357@jadzia.bu.edu> <42A78C47.9030805@www.linux.org.uk> <604aa79105060818093f1d606f@mail.gmail.com> Message-ID: <7949.1118299598@sss.pgh.pa.us> Jeff Spaleta writes: > ... Even if there were enough monkeys to go around.. how do you > train them all? The medical community knows very well that triage is a high-grade skill --- you don't send junior personnel out to do it. Mike's evidently been doing triage for X-related bugs himself, and I'm sure that has something to do with the success level he's reporting. I'm not sure how we transfer this ancient medical technique into our setting, but for sure it requires a pretty decent skill level at the initial triage review. For most of the packages we "own", I believe there is only one developer assigned and so only one pair of eyeballs available --- if that person doesn't know the code pretty well then there's no hope anyway. (Unless we can suck in an upstream developer to help us review bug reports, which seems like a good idea to me...) For packages where there's actually a fair amount of expertise in-house, I think the lesson here is that the initial triage should be done by a more senior person not a more junior one. regards, tom lane From jorton at redhat.com Thu Jun 9 12:32:29 2005 From: jorton at redhat.com (Joe Orton) Date: Thu, 9 Jun 2005 13:32:29 +0100 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050608234059.GA1357@jadzia.bu.edu> References: <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42A76950.7060705@www.linux.org.uk> <20050608234059.GA1357@jadzia.bu.edu> Message-ID: <20050609123229.GA10251@redhat.com> On Wed, Jun 08, 2005 at 07:40:59PM -0400, Matthew Miller wrote: > On Wed, Jun 08, 2005 at 05:55:28PM -0400, Mike A. Harris wrote: > > However, "CANFIX" implies that you (or someone) "can" actually > > fix the issue, which in reality may not be true. As such, I would > > refrain from using CANFIX. Proactivity focuses on stating what > > you will do, so I would use something like: > > WILL_REVIEW_ONCE_REQUESTED_INFO_IS_SUPPLIED > > I think this is a great idea provided we can somehow condense it down to, > like, 12 letters :) and, crucially, if someone _does_ provide info, they get > some kind of reaction. (Which I understand is hard.) If we want to leave the bugs "awaiting more info" and avoid upsetting anyone by providing a "negative" resolution we can just leave them open forever in NEEDINFO, that's no big deal. But... news flash... *we are not going to fix FC2 bugs any more*. That is the policy of this project -- no more FC2 updates, ergo no more FC2 bugs fixed. If the bugs also exist in later releases the reporters can refile appropriate, your text already clearly explains that. So I think it's better to just be honest and WONTFIX them. Yes, it's negative, yes, it might upset a few people, no, it's not a big deal, it's just a bug tracking system. joe From dwmw2 at infradead.org Thu Jun 9 13:39:00 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 09 Jun 2005 14:39:00 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050608095350.GV8706@redhat.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <20050608095350.GV8706@redhat.com> Message-ID: <1118324341.25956.140.camel@hades.cambridge.redhat.com> On Wed, 2005-06-08 at 10:53 +0100, Tim Waugh wrote: > I plan to work on: <...lots of printing stuff...> Is any of that likely to include actually getting feedback from printers? Hence getting accurate progress measurements, error reports, ink levels,... -- dwmw2 From twaugh at redhat.com Thu Jun 9 14:24:09 2005 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 9 Jun 2005 15:24:09 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118324341.25956.140.camel@hades.cambridge.redhat.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <20050608095350.GV8706@redhat.com> <1118324341.25956.140.camel@hades.cambridge.redhat.com> Message-ID: <20050609142409.GJ8706@redhat.com> On Thu, Jun 09, 2005 at 02:39:00PM +0100, David Woodhouse wrote: > On Wed, 2005-06-08 at 10:53 +0100, Tim Waugh wrote: > > I plan to work on: <...lots of printing stuff...> > > Is any of that likely to include actually getting feedback from > printers? Hence getting accurate progress measurements, error reports, > ink levels,... I'm afraid not, unless CUPS 1.2.x has anything new in that area. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Thu Jun 9 18:32:51 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 09 Jun 2005 14:32:51 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050609123229.GA10251@redhat.com> References: <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42A76950.7060705@www.linux.org.uk> <20050608234059.GA1357@jadzia.bu.edu> <20050609123229.GA10251@redhat.com> Message-ID: <1118341971.3175.54.camel@localhost> On Thu, 2005-06-09 at 13:32 +0100, Joe Orton wrote: > On Wed, Jun 08, 2005 at 07:40:59PM -0400, Matthew Miller wrote: > > On Wed, Jun 08, 2005 at 05:55:28PM -0400, Mike A. Harris wrote: > > > However, "CANFIX" implies that you (or someone) "can" actually > > > fix the issue, which in reality may not be true. As such, I would > > > refrain from using CANFIX. Proactivity focuses on stating what > > > you will do, so I would use something like: > > > WILL_REVIEW_ONCE_REQUESTED_INFO_IS_SUPPLIED > > > > I think this is a great idea provided we can somehow condense it down to, > > like, 12 letters :) and, crucially, if someone _does_ provide info, they get > > some kind of reaction. (Which I understand is hard.) > > If we want to leave the bugs "awaiting more info" and avoid upsetting > anyone by providing a "negative" resolution we can just leave them open > forever in NEEDINFO, that's no big deal. > > But... news flash... *we are not going to fix FC2 bugs any more*. That > is the policy of this project -- no more FC2 updates, ergo no more FC2 > bugs fixed. If the bugs also exist in later releases the reporters can > refile appropriate, your text already clearly explains that. > > So I think it's better to just be honest and WONTFIX them. Yes, it's > negative, yes, it might upset a few people, no, it's not a big deal, > it's just a bug tracking system. I hate to say anything as I'm not going to contribute anything new but the impression left on reporters from the bugzilla system is *VERY* important. Bugzilla is the primary means that users interact with the developers. Moreover, this is interaction with users who care enough to report problems and could potentially end up caring enough to learn to make useful bug reports or submit patches. WONTFIX is a horrible name for a resoluion. It doesn't imply "WONT be able to FIX this." It implies "I WONT FIX this." It isn't just a negative reply, it also passes a personal judgement on the bug. WONTFIX says, there may be a problem here but it is beneath my dignity to try to deal with it. WONTFIX leaves bug filers feeling disenfranchised because it places a burden on them to prove their bug and their judgement are valuable before even beginning to address how to fix the bug. A NEEDINFO close state is what we want. That leaves the bug reporter with the feeling that we care about the bug but are unable to do anything more about it without more information. If they care about the bug they can keep the dialog alive by providing the requested information. To let the reporter know that we won't be addressing the bug in the bug-targetted version of FC we can specify that we need to know if it still occurs on the present release. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Fri Jun 10 11:51:16 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 12:51:16 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> Message-ID: <1118404276.2934.7.camel@localhost.localdomain> I plan to work on... Top of the list would probably be NetworkManager. It's quite nice now, but needs to learn about Bluetooth networking and dialup so it can actually handle _all_ the common connectivity requirements for my laptop rather than only some of them. I'll also try to make something mergeable out of the hacks I have at the moment to effectively authenticate via Bluetooth at boot time -- I have gdm set to autologin, and my GNOME session checks via Bluetooth for the presence of my phone and runs 'xscreensaver -lock' if it's not found. I'll probably make this happen on resume from sleep too, which is probably more useful since the laptop spends far more time asleep than it does turned off. -- dwmw2 From dwmw2 at infradead.org Fri Jun 10 14:35:23 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 15:35:23 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <200506102150.57994.symbiont@berlios.de> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <200506102150.57994.symbiont@berlios.de> Message-ID: <1118414123.3454.0.camel@localhost.localdomain> On Fri, 2005-06-10 at 21:50 +0800, Jeff Pitman wrote: > While you're at it, get hotplug to run "/etc/init.d/bluetooth start" > after it detects an external usb bluetooth. That chicken and egg > always nabbed me when starting up kdebluetooth services. Nah. If hcid is running, it'll bring up the new device when it appears. Just make sure it _is_ running by default. Maybe with the new init setup we can have services started and stopped on demand in a more cunning way, but I don't really like starting it from hotplug like the above. -- dwmw2 From davidz at redhat.com Fri Jun 10 14:44:20 2005 From: davidz at redhat.com (David Zeuthen) Date: Fri, 10 Jun 2005 10:44:20 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118404276.2934.7.camel@localhost.localdomain> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> Message-ID: <1118414660.3932.27.camel@daxter.boston.redhat.com> On Fri, 2005-06-10 at 12:51 +0100, David Woodhouse wrote: > I'll also try to make something mergeable out of the hacks I have at the > moment to effectively authenticate via Bluetooth at boot time -- I have > gdm set to autologin, and my GNOME session checks via Bluetooth for the > presence of my phone and runs 'xscreensaver -lock' if it's not found. > I'll probably make this happen on resume from sleep too, which is > probably more useful since the laptop spends far more time asleep than > it does turned off. Sounds good, however, we should just lock the screen when the machine is suspended so it is locked when we resume. So, in other words, I don't think you need to worry about suspend. See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155613 for the proposed suspend scripts. David From dwmw2 at infradead.org Fri Jun 10 15:05:32 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 16:05:32 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118414660.3932.27.camel@daxter.boston.redhat.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <1118414660.3932.27.camel@daxter.boston.redhat.com> Message-ID: <1118415932.4823.1.camel@localhost.localdomain> On Fri, 2005-06-10 at 10:44 -0400, David Zeuthen wrote: > Sounds good, however, we should just lock the screen when the machine > is suspended so it is locked when we resume. It still needs to check for the presence of my mobile phone at _resume_ time, and unlock if it's found, surely? -- dwmw2 From dwmw2 at infradead.org Fri Jun 10 15:40:26 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 16:40:26 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <200506102339.48959.symbiont@berlios.de> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <200506102150.57994.symbiont@berlios.de> <1118414123.3454.0.camel@localhost.localdomain> <200506102339.48959.symbiont@berlios.de> Message-ID: <1118418026.4823.21.camel@localhost.localdomain> On Fri, 2005-06-10 at 23:39 +0800, Jeff Pitman wrote: > Currently, /etc/init.d/bluetooth start don't work unless I have the > usb plugged in. But, when you plug it in, sdp, et al don't start. > There's gotta be a way around this. That's strange. hcid and sdpd ought to be running before you connect the usb device. Are they? What do they do when you plug the device in? What happens if you kill hcid, then run it from a terminal with '-n'? What does it do when you plug the device in? -- dwmw2 From davidz at redhat.com Fri Jun 10 16:26:28 2005 From: davidz at redhat.com (David Zeuthen) Date: Fri, 10 Jun 2005 12:26:28 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118415932.4823.1.camel@localhost.localdomain> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <1118414660.3932.27.camel@daxter.boston.redhat.com> <1118415932.4823.1.camel@localhost.localdomain> Message-ID: <1118420788.12844.0.camel@daxter.boston.redhat.com> On Fri, 2005-06-10 at 16:05 +0100, David Woodhouse wrote: > On Fri, 2005-06-10 at 10:44 -0400, David Zeuthen wrote: > > Sounds good, however, we should just lock the screen when the machine > > is suspended so it is locked when we resume. > > It still needs to check for the presence of my mobile phone at _resume_ > time, and unlock if it's found, surely? > Well, it needs to do that every time you want to unlock the screen saver so I don't really see a need to special case it? David From dwmw2 at infradead.org Fri Jun 10 16:29:10 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 17:29:10 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118420788.12844.0.camel@daxter.boston.redhat.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <1118414660.3932.27.camel@daxter.boston.redhat.com> <1118415932.4823.1.camel@localhost.localdomain> <1118420788.12844.0.camel@daxter.boston.redhat.com> Message-ID: <1118420951.4823.27.camel@localhost.localdomain> On Fri, 2005-06-10 at 12:26 -0400, David Zeuthen wrote: > Well, it needs to do that every time you want to unlock the screen > saver so I don't really see a need to special case it? The idea is that if I boot or resume the machine while my phone is nearby, the screen shouldn't become locked in the first place. I don't want it to lock whenever I walk away from it; I want it to lock only at {boot,resume} time if my phone isn't present _then_. -- dwmw2 From davej at redhat.com Fri Jun 10 17:13:55 2005 From: davej at redhat.com (Dave Jones) Date: Fri, 10 Jun 2005 13:13:55 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118404276.2934.7.camel@localhost.localdomain> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> Message-ID: <20050610171354.GE20255@redhat.com> On Fri, Jun 10, 2005 at 12:51:16PM +0100, David Woodhouse wrote: > I'll also try to make something mergeable out of the hacks I have at the > moment to effectively authenticate via Bluetooth at boot time -- I have > gdm set to autologin, and my GNOME session checks via Bluetooth for the > presence of my phone and runs 'xscreensaver -lock' if it's not found. So all I have to do is steal your laptop and phone, and I've got access to all your data ? The auto-login bit scares me a little. Having it lock the screen if you wander off I like the sound of though. Whilst I remember, who was working on encrypted homedirs ? davidz ? Any progress on that ? Dave From dwmw2 at infradead.org Fri Jun 10 17:36:40 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 18:36:40 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050610171354.GE20255@redhat.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <20050610171354.GE20255@redhat.com> Message-ID: <1118425001.4823.36.camel@localhost.localdomain> On Fri, 2005-06-10 at 13:13 -0400, Dave Jones wrote: > So all I have to do is steal your laptop and phone, and I've got > access to all your data ? The auto-login bit scares me a little. > Having it lock the screen if you wander off I like the sound of > though. Who runs a password-protected bootloader? You steal my laptop and you've got access to all my data anyway. Besides, about the only time my laptop and phone are ever in the bag together are when they're on an airplane, and if you manage to steal them then you're _still_ fairly unlikely to try booting the laptop while the phone is turned on, so you don't gain much. -- dwmw2 From alan at redhat.com Fri Jun 10 23:36:43 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 10 Jun 2005 19:36:43 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118425001.4823.36.camel@localhost.localdomain> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <20050610171354.GE20255@redhat.com> <1118425001.4823.36.camel@localhost.localdomain> Message-ID: <20050610233643.GK18279@devserv.devel.redhat.com> On Fri, Jun 10, 2005 at 06:36:40PM +0100, David Woodhouse wrote: > Who runs a password-protected bootloader? You steal my laptop and you've > got access to all my data anyway. Paranoid companies run password protected bios which unlocks the password protected disk which loads the protected bootloader. Its easy to do with an IBM thinkpad From jwboyer at jdub.homelinux.org Fri Jun 10 23:46:08 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 10 Jun 2005 18:46:08 -0500 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050610233643.GK18279@devserv.devel.redhat.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <20050610171354.GE20255@redhat.com> <1118425001.4823.36.camel@localhost.localdomain> <20050610233643.GK18279@devserv.devel.redhat.com> Message-ID: <1118447168.3329.2.camel@yoda.jdub.homelinux.org> On Fri, 2005-06-10 at 19:36 -0400, Alan Cox wrote: > On Fri, Jun 10, 2005 at 06:36:40PM +0100, David Woodhouse wrote: > > Who runs a password-protected bootloader? You steal my laptop and you've > > got access to all my data anyway. > > Paranoid companies run password protected bios which unlocks the password > protected disk which loads the protected bootloader. Its easy to do with an > IBM thinkpad Yes, it is. And it's really, really annoying sometimes :). josh From chris at cnpbagwell.com Sat Jun 11 04:34:04 2005 From: chris at cnpbagwell.com (Chris Bagwell) Date: Fri, 10 Jun 2005 23:34:04 -0500 Subject: Using ALSA device driver directly Message-ID: <42AA69BC.5070104@cnpbagwell.com> Hi all, I'm looking for some feedback on enhancing ALSA support in the SoX package. Specifically, I'd like to allow the Fedora SoX RPM package to include support for both ALSA and OSS drivers. Currently, it only supports OSS driver. The SoX package has had an ALSA driver for playing/recording audio for years now but it wasn't until Redhat/Fedora started including ALSA drivers that I really became interested in developing it further. The original author of the SoX ALSA driver chose to directly access the kernel device driver instead of the alsa-devel library. The may reason was because it seemed like bloatware to wrap such simple ioctl() calls. The main problem with using ALSA ioctl's is that compared to OSS audio device, its been a nightmare supporting the ever changing ALSA device header files. Its even harder trying to get it to compile on a Fedora. Here some issues with packages that access ALSA device drivers directly: 1) OSS's interface is defined in sys/soundcard.h which is in the glibc-headers package. Chances are great that you can compile against it. The equivalent file for ALSA is sound/asound.h but this is not distributed in any convient package like glibc-headers. Anyone know if this will ever be distributed in glibc-headers? 2) sound/asound.h is available from /lib/modules/*/build/include/ though. Is it OK for a RPM to BuildRequires: kernel? The current rawhide package of SoX has a patch to remove a hack I added to point to kernel headers to get ALSA to compile. So I'm guessing its not a preferred approach then? 3) If your package uses the kernel sound/asound.h file, it won't compile most likely. Thats because the header eventually includes linux/compiler.h. Include path order will grab /usr/include/linux/compiler.h first which doesn't define __user or __kernel. The linux kernel version of sound/asound.h references that extensively. Whats the easiest way around include path ordering so that it prefers the kernels compiler.h? 4) Should I drop all this and just use alsa-lib instead? Chris (SoX mantainer) From davej at redhat.com Sat Jun 11 05:13:08 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 11 Jun 2005 01:13:08 -0400 Subject: Using ALSA device driver directly In-Reply-To: <42AA69BC.5070104@cnpbagwell.com> References: <42AA69BC.5070104@cnpbagwell.com> Message-ID: <20050611051307.GB26587@redhat.com> On Fri, Jun 10, 2005 at 11:34:04PM -0500, Chris Bagwell wrote: > 4) Should I drop all this and just use alsa-lib instead? Yes. This is the only way you can guarantee that an app will work on multiple kernel versions. The kernel<->userspace interface changes regularly. alsa-lib shields you from this madness. Dave From ivazquez at ivazquez.net Sat Jun 11 05:20:31 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 11 Jun 2005 01:20:31 -0400 Subject: Using ALSA device driver directly In-Reply-To: <42AA69BC.5070104@cnpbagwell.com> References: <42AA69BC.5070104@cnpbagwell.com> Message-ID: <1118467231.23142.15.camel@ignacio.ignacio.lan> On Fri, 2005-06-10 at 23:34 -0500, Chris Bagwell wrote: > 4) Should I drop all this and just use alsa-lib instead? My personal recommendation would be yes. It may seem like bloatware, but in the long run (and probably even in the short run) it'll be easier. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From janina at rednote.net Sat Jun 11 14:46:52 2005 From: janina at rednote.net (Janina Sajka) Date: Sat, 11 Jun 2005 10:46:52 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118015289.19379.24.camel@cutter> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118015289.19379.24.camel@cutter> Message-ID: <20050611144652.GA28484@rednote.net> Would it be useful to have yum NOT fail when one repo happens to be offline? Even if the best/newest version of a package should happen to be in that repo, I would find it helpful to get the best available at the moment knowing that the latest and greatest version will be picked up later on 'yum update,' etc. Just a suggestion. seth vidal writes: > On Mon, 2005-06-06 at 00:57 +0200, Miloslav Trmac wrote: > > Hello world, > > (Apparently I don't know any better than to send this, which could start > > another long-lived "future of FC5" thread. Apologies to all if that > > happens.) > > > > I plan to work on: > - helping purge core of duplicate packages and getting the duplicates > picked up into extras > - making better/more interesting package groups for extras > - doing whatever I can to help with anaconda to add yum support for > depsolving. > - pushing for more of an extended development cycle :) > - deploying the second generation of the fedora extras buildsystem > - using the extras buildsys code to do a parallel build of core as a > way of testing how good the buildsystem code is. > - Adding CD support into the repodata creator (createrepo) and teaching > yum how to deal with removable media > - Helping to make the errata/update announcements be more automated and > providing the content in the announcements in such a way as to allow yum > and pup access to the notices in runtime. > - Getting rid of the ugly-ass fedoraproject.org main page and making > the fedora project pages more informative and useful. > > > That's my list for the moment. I'm sure other things will come up. > > -sv > > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more. From skvidal at phy.duke.edu Sat Jun 11 14:53:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 11 Jun 2005 10:53:26 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050611144652.GA28484@rednote.net> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118015289.19379.24.camel@cutter> <20050611144652.GA28484@rednote.net> Message-ID: <1118501606.14986.8.camel@cutter> On Sat, 2005-06-11 at 10:46 -0400, Janina Sajka wrote: > Would it be useful to have yum NOT fail when one repo happens to be > offline? Even if the best/newest version of a package should happen to > be in that repo, I would find it helpful to get the best available at > the moment knowing that the latest and greatest version will be picked > up later on 'yum update,' etc. very dangerous behavior, actually. Especially when you have a local repo that has specifically needed versions of some packages. -sv From mattdm at mattdm.org Sun Jun 12 14:43:50 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 12 Jun 2005 10:43:50 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118501606.14986.8.camel@cutter> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118015289.19379.24.camel@cutter> <20050611144652.GA28484@rednote.net> <1118501606.14986.8.camel@cutter> Message-ID: <20050612144350.GA29738@jadzia.bu.edu> On Sat, Jun 11, 2005 at 10:53:26AM -0400, seth vidal wrote: > On Sat, 2005-06-11 at 10:46 -0400, Janina Sajka wrote: > > Would it be useful to have yum NOT fail when one repo happens to be > > offline? Even if the best/newest version of a package should happen to > > be in that repo, I would find it helpful to get the best available at > > the moment knowing that the latest and greatest version will be picked > > up later on 'yum update,' etc. > very dangerous behavior, actually. Especially when you have a local repo > that has specifically needed versions of some packages. Instead, if one fails and you *know* it's okay, --disablerepo it and try again. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 82 degrees Fahrenheit. From jgarzik at redhat.com Mon Jun 13 02:27:05 2005 From: jgarzik at redhat.com (Jeff Garzik) Date: Sun, 12 Jun 2005 22:27:05 -0400 Subject: Using ALSA device driver directly In-Reply-To: <42AA69BC.5070104@cnpbagwell.com> References: <42AA69BC.5070104@cnpbagwell.com> Message-ID: <20050613022705.GA8101@devserv.devel.redhat.com> On Fri, Jun 10, 2005 at 11:34:04PM -0500, Chris Bagwell wrote: > 4) Should I drop all this and just use alsa-lib instead? Yes. alsa-lib is basically libc for sound. Apps don't use direct syscalls normally (nor should they!), they use a lib to help buffer kernel changes. Jeff From byte at aeon.com.my Mon Jun 13 12:41:10 2005 From: byte at aeon.com.my (Colin Charles) Date: Mon, 13 Jun 2005 22:41:10 +1000 Subject: OT: Planet feeds Message-ID: <1118666471.3544.446.camel@arena.soho.bytebot.net> Hi all maintainers, We have Fedora People (Planet fedora?) sitting at: http://fedoraproject.org/planet/ or even http://planet.fedoraproject.org/ Now, all you hackers/maintainers deserve your place there too, so please feel free to send: * hackergotchi (64x64 is preferred) - barring one, a relatively hi-res image so one can be made for you * RSS feed to your blog No, don't post it to list, but send it to both Seth and me so we attend to it in a timely fashion Regards -- Colin Charles, http://www.bytebot.net/ FUDCon II @ LinuxTag June 24-25, 2005 in Karlsruhe, Germany http://fedoraproject.com/fudcon/ From janina at rednote.net Mon Jun 13 16:54:35 2005 From: janina at rednote.net (Janina Sajka) Date: Mon, 13 Jun 2005 12:54:35 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050612144350.GA29738@jadzia.bu.edu> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118015289.19379.24.camel@cutter> <20050611144652.GA28484@rednote.net> <1118501606.14986.8.camel@cutter> <20050612144350.GA29738@jadzia.bu.edu> Message-ID: <20050613165435.GD28484@rednote.net> Matthew Miller writes: > On Sat, Jun 11, 2005 at 10:53:26AM -0400, seth vidal wrote: > > On Sat, 2005-06-11 at 10:46 -0400, Janina Sajka wrote: > > > Would it be useful to have yum NOT fail when one repo happens to be > > > offline? Even if the best/newest version of a package should happen to > > > be in that repo, I would find it helpful to get the best available at > > > the moment knowing that the latest and greatest version will be picked > > > up later on 'yum update,' etc. > > very dangerous behavior, actually. Especially when you have a local repo > > that has specifically needed versions of some packages. > > Instead, if one fails and you *know* it's okay, --disablerepo it and try > again. > I do exactly that, but the list of --disablerepo switches gets a tad tedious to build. I suppose I should note that I have non Fedora repos such as Dag, Freshrpms, PlanetCCRMA, Gstreamer, and a few more. Currently running an FC3 to FC4 upgrade via Yum on my x86_64 system. Fingers crossed. > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > Current office temperature: 82 degrees Fahrenheit. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more. From jspaleta at gmail.com Mon Jun 13 16:59:23 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 13 Jun 2005 12:59:23 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050613165435.GD28484@rednote.net> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118015289.19379.24.camel@cutter> <20050611144652.GA28484@rednote.net> <1118501606.14986.8.camel@cutter> <20050612144350.GA29738@jadzia.bu.edu> <20050613165435.GD28484@rednote.net> Message-ID: <604aa7910506130959706f4bf0@mail.gmail.com> On 6/13/05, Janina Sajka wrote: > I do exactly that, but the list of --disablerepo switches gets a tad > tedious to build. The new yum update in fc3 should help with this... globs now allowed in the enable and disable switches so the changelog snippet in the announcement says -jef From janina at rednote.net Mon Jun 13 17:14:43 2005 From: janina at rednote.net (Janina Sajka) Date: Mon, 13 Jun 2005 13:14:43 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <604aa7910506130959706f4bf0@mail.gmail.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118015289.19379.24.camel@cutter> <20050611144652.GA28484@rednote.net> <1118501606.14986.8.camel@cutter> <20050612144350.GA29738@jadzia.bu.edu> <20050613165435.GD28484@rednote.net> <604aa7910506130959706f4bf0@mail.gmail.com> Message-ID: <20050613171443.GF28484@rednote.net> Jeff Spaleta writes: > On 6/13/05, Janina Sajka wrote: > > I do exactly that, but the list of --disablerepo switches gets a tad > > tedious to build. > > The new yum update in fc3 should help with this... globs now allowed > in the enable and disable switches so the changelog snippet in the > announcement says Cool. Thanks for the pointer. > > -jef > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more. From pnasrat at redhat.com Mon Jun 13 20:16:24 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Mon, 13 Jun 2005 16:16:24 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050613165435.GD28484@rednote.net> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118015289.19379.24.camel@cutter> <20050611144652.GA28484@rednote.net> <1118501606.14986.8.camel@cutter> <20050612144350.GA29738@jadzia.bu.edu> <20050613165435.GD28484@rednote.net> Message-ID: <1118693785.3191.9.camel@enki.eridu> On Mon, 2005-06-13 at 12:54 -0400, Janina Sajka wrote: > Matthew Miller writes: > > On Sat, Jun 11, 2005 at 10:53:26AM -0400, seth vidal wrote: > > > On Sat, 2005-06-11 at 10:46 -0400, Janina Sajka wrote: > > > > Would it be useful to have yum NOT fail when one repo happens to be > > > > offline? Even if the best/newest version of a package should happen to > > > > be in that repo, I would find it helpful to get the best available at > > > > the moment knowing that the latest and greatest version will be picked > > > > up later on 'yum update,' etc. > > > very dangerous behavior, actually. Especially when you have a local repo > > > that has specifically needed versions of some packages. > > > > Instead, if one fails and you *know* it's okay, --disablerepo it and try > > again. > > > > I do exactly that, but the list of --disablerepo switches gets a tad > tedious to build. It supports globbing: yum --disablerepo \* --enablerepo base Paul From jspaleta at gmail.com Mon Jun 13 21:26:19 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 13 Jun 2005 17:26:19 -0400 Subject: OT: Planet feeds In-Reply-To: <1118666471.3544.446.camel@arena.soho.bytebot.net> References: <1118666471.3544.446.camel@arena.soho.bytebot.net> Message-ID: <604aa79105061314264b732d7a@mail.gmail.com> On 6/13/05, Colin Charles wrote: > Hi all maintainers, > > We have Fedora People (Planet fedora?) sitting at: > http://fedoraproject.org/planet/ or even > http://planet.fedoraproject.org/ One small hiccup the planet url doesn't seem to be showing the hackergotchi's while the older fedorapeople url is. -jef From skvidal at phy.duke.edu Mon Jun 13 21:31:27 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 13 Jun 2005 17:31:27 -0400 Subject: OT: Planet feeds In-Reply-To: <604aa79105061314264b732d7a@mail.gmail.com> References: <1118666471.3544.446.camel@arena.soho.bytebot.net> <604aa79105061314264b732d7a@mail.gmail.com> Message-ID: <1118698288.24314.19.camel@cutter> On Mon, 2005-06-13 at 17:26 -0400, Jeff Spaleta wrote: > On 6/13/05, Colin Charles wrote: > > Hi all maintainers, > > > > We have Fedora People (Planet fedora?) sitting at: > > http://fedoraproject.org/planet/ or even > > http://planet.fedoraproject.org/ > > One small hiccup > the planet url doesn't seem to be showing the hackergotchi's > while the older fedorapeople url is. > images subdir I bet I'll fix it. -sv From skvidal at phy.duke.edu Mon Jun 13 21:38:54 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 13 Jun 2005 17:38:54 -0400 Subject: OT: Planet feeds In-Reply-To: <1118698288.24314.19.camel@cutter> References: <1118666471.3544.446.camel@arena.soho.bytebot.net> <604aa79105061314264b732d7a@mail.gmail.com> <1118698288.24314.19.camel@cutter> Message-ID: <1118698734.24314.21.camel@cutter> On Mon, 2005-06-13 at 17:31 -0400, seth vidal wrote: > On Mon, 2005-06-13 at 17:26 -0400, Jeff Spaleta wrote: > > On 6/13/05, Colin Charles wrote: > > > Hi all maintainers, > > > > > > We have Fedora People (Planet fedora?) sitting at: > > > http://fedoraproject.org/planet/ or even > > > http://planet.fedoraproject.org/ > > > > One small hiccup > > the planet url doesn't seem to be showing the hackergotchi's > > while the older fedorapeople url is. > > > > images subdir I bet > > I'll fix it. fixed at next refresh, i think. -sv From smooge at gmail.com Wed Jun 15 14:03:12 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 15 Jun 2005 08:03:12 -0600 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <1118341971.3175.54.camel@localhost> References: <20050525030418.GA31087@jadzia.bu.edu> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42A76950.7060705@www.linux.org.uk> <20050608234059.GA1357@jadzia.bu.edu> <20050609123229.GA10251@redhat.com> <1118341971.3175.54.camel@localhost> Message-ID: <80d7e409050615070336ccf7b2@mail.gmail.com> On 6/9/05, Toshio Kuratomi wrote: > On Thu, 2005-06-09 at 13:32 +0100, Joe Orton wrote: > > On Wed, Jun 08, 2005 at 07:40:59PM -0400, Matthew Miller wrote: > > > On Wed, Jun 08, 2005 at 05:55:28PM -0400, Mike A. Harris wrote: > > > > However, "CANFIX" implies that you (or someone) "can" actually > > A NEEDINFO close state is what we want. That leaves the bug reporter > with the feeling that we care about the bug but are unable to do > anything more about it without more information. If they care about the > bug they can keep the dialog alive by providing the requested > information. To let the reporter know that we won't be addressing the > bug in the bug-targetted version of FC we can specify that we need to > know if it still occurs on the present release. Having gone and stuck a lot of NEEDINFO's into bugs without getting any feedback on them.. it is a two way street. I think that the system should be set up as NEEDINFO (auto-close within 60 days) with a polite email saying that if the questions can't be answered within 60 days this ticket will be closed as FORECLOSED or some such thing. Bugzilla is a two way street with the reporter needing to answer the questions that the reviewer needs. On the other hand... having had lots of bugs that have never been changed from NEW to ASSIGNED or some such... the bugzilla needs to be maintained on its side also. -- Stephen J Smoogen. CSIRT/Linux System Administrator From toshio at tiki-lounge.com Wed Jun 15 18:18:11 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 15 Jun 2005 14:18:11 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <80d7e409050615070336ccf7b2@mail.gmail.com> References: <20050525030418.GA31087@jadzia.bu.edu> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42A76950.7060705@www.linux.org.uk> <20050608234059.GA1357@jadzia.bu.edu> <20050609123229.GA10251@redhat.com> <1118341971.3175.54.camel@localhost> <80d7e409050615070336ccf7b2@mail.gmail.com> Message-ID: <1118859491.22776.4.camel@localhost> On Wed, 2005-06-15 at 08:03 -0600, Stephen J. Smoogen wrote: > On 6/9/05, Toshio Kuratomi wrote: > > A NEEDINFO close state is what we want. That leaves the bug reporter > > with the feeling that we care about the bug but are unable to do > > anything more about it without more information. If they care about the > > bug they can keep the dialog alive by providing the requested > > information. To let the reporter know that we won't be addressing the > > bug in the bug-targetted version of FC we can specify that we need to > > know if it still occurs on the present release. > > Having gone and stuck a lot of NEEDINFO's into bugs without getting > any feedback on them.. it is a two way street. I think that the system > should be set up as NEEDINFO (auto-close within 60 days) with a polite > email saying that if the questions can't be answered within 60 days > this ticket will be closed as FORECLOSED or some such thing. Bugzilla > is a two way street with the reporter needing to answer the questions > that the reviewer needs. On the other hand... having had lots of bugs > that have never been changed from NEW to ASSIGNED or some such... the > bugzilla needs to be maintained on its side also. > I'm not saying to leave bugs open-NEEDINFO. But we need a close state that expresses the same thing. (The rest of my mail was why WONTFIX does not satisfy that criteria). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Thu Jun 16 18:06:36 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 16 Jun 2005 11:06:36 -0700 Subject: Fedora Booth and BOF instead of FUDCon3 for SF? Message-ID: <1118945196.25568.11.camel@localhost.localdomain> Seems that with FUDCon2 being just before, and budgets being rather flat, and Aug being bad for universities, should we scrap the idea of FUDCon3, and instead focus on the Fedora Booth for LWCE and a BOF? We can still do some presentations IN the Fedora booth, with limited attendees (: I'd still very much like to be a part of this. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Thu Jun 16 18:15:49 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 16 Jun 2005 11:15:49 -0700 Subject: Fedora Booth and BOF instead of FUDCon3 for SF? In-Reply-To: <1118945196.25568.11.camel@localhost.localdomain> References: <1118945196.25568.11.camel@localhost.localdomain> Message-ID: <42B1C1D5.70607@redhat.com> Jesse Keating wrote: > Seems that with FUDCon2 being just before, and budgets being rather > flat, and Aug being bad for universities, should we scrap the idea of > FUDCon3, and instead focus on the Fedora Booth for LWCE and a BOF? We > can still do some presentations IN the Fedora booth, with limited > attendees (: > > I'd still very much like to be a part of this. I agree it should be a booth and BOF. It would also be relatively cheap for me to attend given my proximity. Warren Togami wtogami at redhat.com From jkeating at j2solutions.net Thu Jun 16 18:18:36 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 16 Jun 2005 11:18:36 -0700 Subject: Fedora Booth and BOF instead of FUDCon3 for SF? In-Reply-To: <1118945196.25568.11.camel@localhost.localdomain> References: <1118945196.25568.11.camel@localhost.localdomain> Message-ID: <1118945916.25568.15.camel@localhost.localdomain> On Thu, 2005-06-16 at 11:06 -0700, Jesse Keating wrote: > Seems that with FUDCon2 being just before, and budgets being rather > flat, and Aug being bad for universities, should we scrap the idea of > FUDCon3, and instead focus on the Fedora Booth for LWCE and a BOF? We > can still do some presentations IN the Fedora booth, with limited > attendees (: > > I'd still very much like to be a part of this. Please disregard this, wrong list. If you're interested in this subject, follow it in fedora-marketing-list -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nalin at redhat.com Fri Jun 17 20:52:10 2005 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 17 Jun 2005 16:52:10 -0400 Subject: The recent redhat-rpm-config change and you Message-ID: <20050617205210.GF13260@redhat.com> As you've probably noticed [1], redhat-rpm-config-8.0.35 and later have started using the brp-python-bytecompile script to byte-compile python scripts at the end of %install. What does this mean for your package? If your package specifies a buildroot, after the %install phase completes, rpmbuild will now find .pyc and .pyo files sitting alongside any .py files which were installed under $RPM_BUILD_ROOT. If your package's %files list doesn't mention these files, you'll need to update it to get the package to build successfully without tripping the unpackaged-files-in-buildroot sanity check. The procedure is similar to what we all needed to do when we started compressing man pages by default, tedious but simple: either change every instance of ".py" to ".py*", or add the .pyc and .pyo files to the %files list individually. If your package was explicitly byte-compiling modules in the %install scriptlet, you can now, at your option, stop it from doing so. If your package uses distutils to build an RPM (specifically, if it calls "python setup.py install" with the "--record" option to generate its %files list), then you'll need to add the "-O1" flag to the command to get a correct list. Yes, this makes the packages larger. How much larger is entirely dependent on how much python code the package contains. [2] HTH, Nalin [1] http://www.redhat.com/archives/fedora-devel-list/2005-June/msg01043.html [2] You can filter the "rpm -qlv" output through awk 'BEGIN{size=1;pyosize=0;pycsize=0;pysize=0}/\.py$/{pysize=pysize+$5}/\.pyc$/{pycsize=pycsize+$5}/\.pyo$/{pyosize=pyosize+$5}{size=size+$5}END{printf ".py:%7.2f%%\n",pysize*100/size;printf ".pyc:%6.2f%%\n",pycsize*100/size;printf ".pyo:%6.2f%%\n",pyosize*100/size}' to get a breakdown of how much space python files take up in a package. From shahms at shahms.com Fri Jun 17 20:56:13 2005 From: shahms at shahms.com (Shahms King) Date: Fri, 17 Jun 2005 13:56:13 -0700 Subject: The recent redhat-rpm-config change and you In-Reply-To: <20050617205210.GF13260@redhat.com> References: <20050617205210.GF13260@redhat.com> Message-ID: <42B338ED.7070206@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nalin Dahyabhai wrote: | | If your package's %files list doesn't mention these files, you'll need | to update it to get the package to build successfully without tripping | the unpackaged-files-in-buildroot sanity check. The procedure is | similar to what we all needed to do when we started compressing man | pages by default, tedious but simple: either change every instance of | ".py" to ".py*", or add the .pyc and .pyo files to the %files list | individually. Should we start including .pyo files, rather than %ghost'ing them? - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCszjs/qs2NkWy11sRAsViAKDRal8SMzZ3d78YrJa686cWUBl8bgCePPF8 oao+yFiDi8yyoe6Gg4r7gDg= =SErH -----END PGP SIGNATURE----- From nalin at redhat.com Fri Jun 17 21:05:38 2005 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 17 Jun 2005 17:05:38 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <42B338ED.7070206@shahms.com> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> Message-ID: <20050617210538.GG13260@redhat.com> On Fri, Jun 17, 2005 at 01:56:13PM -0700, Shahms King wrote: > Nalin Dahyabhai wrote: > > | If your package's %files list doesn't mention these files, you'll need > | to update it to get the package to build successfully without tripping > | the unpackaged-files-in-buildroot sanity check. The procedure is > | similar to what we all needed to do when we started compressing man > | pages by default, tedious but simple: either change every instance of > | ".py" to ".py*", or add the .pyc and .pyo files to the %files list > | individually. > > Should we start including .pyo files, rather than %ghost'ing them? Given that the change was made to fix #129025 [1], and %ghost'ing .pyo files would bypass the fix, I'd say yes. Nalin [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129025 From skvidal at phy.duke.edu Sat Jun 18 02:20:58 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 17 Jun 2005 22:20:58 -0400 Subject: repoclosure and rawhide Message-ID: <1119061258.7160.2.camel@cutter> Hey, Would anyone be interested in working on using the xmlrpc interface to bugzilla to automatically file bugs against packages that appear to have broken deps from a run of repoclosure against rawhide? This way we could hopefully keep rawhide a bit more usable and users more notified about it. yes, no, maybe? -sv From notting at redhat.com Sat Jun 18 02:25:35 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 17 Jun 2005 22:25:35 -0400 Subject: repoclosure and rawhide In-Reply-To: <1119061258.7160.2.camel@cutter> References: <1119061258.7160.2.camel@cutter> Message-ID: <20050618022535.GA18026@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > Would anyone be interested in working on using the xmlrpc interface to > bugzilla to automatically file bugs against packages that appear to have > broken deps from a run of repoclosure against rawhide? > > This way we could hopefully keep rawhide a bit more usable and users > more notified about it. > > yes, no, maybe? Actually, a little bit of scripting can have the rawhide process autospam people (bugs is a little trickier, but if someone's got the script, go for it. Bill From skvidal at phy.duke.edu Sat Jun 18 03:32:42 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 17 Jun 2005 23:32:42 -0400 Subject: repoclosure and rawhide In-Reply-To: <20050618022535.GA18026@nostromo.devel.redhat.com> References: <1119061258.7160.2.camel@cutter> <20050618022535.GA18026@nostromo.devel.redhat.com> Message-ID: <1119065562.7160.5.camel@cutter> On Fri, 2005-06-17 at 22:25 -0400, Bill Nottingham wrote: > seth vidal (skvidal at phy.duke.edu) said: > > Would anyone be interested in working on using the xmlrpc interface to > > bugzilla to automatically file bugs against packages that appear to have > > broken deps from a run of repoclosure against rawhide? > > > > This way we could hopefully keep rawhide a bit more usable and users > > more notified about it. > > > > yes, no, maybe? > > Actually, a little bit of scripting can have the rawhide process > autospam people (bugs is a little trickier, but if someone's > got the script, go for it. yah that's what I was looking for a way to auto-file bugs. But if there's a way to just email the package maintainer automatically that'd be a nice annoyance feature, too. -sv From toshio at tiki-lounge.com Sat Jun 18 05:00:06 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 18 Jun 2005 01:00:06 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <20050617210538.GG13260@redhat.com> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> Message-ID: <1119070807.2997.5.camel@localhost> On Fri, 2005-06-17 at 17:05 -0400, Nalin Dahyabhai wrote: > On Fri, Jun 17, 2005 at 01:56:13PM -0700, Shahms King wrote: > > > > Should we start including .pyo files, rather than %ghost'ing them? > > Given that the change was made to fix #129025 [1], and %ghost'ing .pyo > files would bypass the fix, I'd say yes. > > Nalin > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129025 What's a simple test case for this? I don't have a USB printer but I tried /usr ro on boot with no .pyo files. This does not cause cups to crash.... Starting other programs which have no .pyo files with PYTHON_OPTIMIZE set also causes no problems. Is the bug really only about SELinux and not a ro partition? Does this only happen with cups and USB printers? Being an anti-pyo person, I'd like to understand this problem so I can be converted :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From janina at rednote.net Mon Jun 20 14:28:06 2005 From: janina at rednote.net (Janina Sajka) Date: Mon, 20 Jun 2005 10:28:06 -0400 Subject: repoclosure and rawhide In-Reply-To: <1119061258.7160.2.camel@cutter> References: <1119061258.7160.2.camel@cutter> Message-ID: <20050620142806.GB5848@rednote.net> seth vidal writes: > Hey, > Would anyone be interested in working on using the xmlrpc interface to > bugzilla to automatically file bugs against packages that appear to have > broken deps from a run of repoclosure against rawhide? > > This way we could hopefully keep rawhide a bit more usable and users > more notified about it. > I'm not qualified for the work, but would sure appreciate the result. > yes, no, maybe? > -sv > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more. From nalin at redhat.com Mon Jun 20 17:44:53 2005 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 20 Jun 2005 13:44:53 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119070807.2997.5.camel@localhost> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> Message-ID: <20050620174453.GC19618@redhat.com> On Sat, Jun 18, 2005 at 01:00:06AM -0400, Toshio Kuratomi wrote: > On Fri, 2005-06-17 at 17:05 -0400, Nalin Dahyabhai wrote: > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129025 > > What's a simple test case for this? I don't have a USB printer but I > tried /usr ro on boot with no .pyo files. This does not cause cups to > crash.... Starting other programs which have no .pyo files with > PYTHON_OPTIMIZE set also causes no problems. Is the bug really only > about SELinux and not a ro partition? Does this only happen with cups > and USB printers? > > Being an anti-pyo person, I'd like to understand this problem so I can > be converted :-) I can't speak to the specifics of cups and printing, but the problem cases in which I'm interested are: * Install a package with .py scripts. Use parts of the package as a user who can write to the files, and you generate .pyc files. These new files are not owned by any package, and RPM does not remove them if you remove the package. * If you can't write to them, and you were denied access by SELinux permission checks (for example, you *were* root, but you were running the script in an execution domain which wouldn't be allowed write access), then you get a log message, either in syslog or in the audit log. This leads to at least 40 unnecessary panic attacks, resulting in no less than four separate posts to fedora-test-list within the same day, which increases incoming traffic enough to finally kill the mailing list servers. Please, think of the mailing list servers. Seriously, though, it's preventable. The usefulness of .pyo files over .pyc files is marginal [1], but if we're trying to avoid problems which crop up when a script only gets byte-compiled on an installed system, I think we have to account for them as well. Cheers, Nalin [1] http://www.python.org/doc/2.4.1/tut/node8.html#SECTION008120000000000000000 From toshio at tiki-lounge.com Mon Jun 20 23:38:25 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 20 Jun 2005 19:38:25 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <20050620174453.GC19618@redhat.com> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> Message-ID: <1119310705.7322.23.camel@localhost> On Mon, 2005-06-20 at 13:44 -0400, Nalin Dahyabhai wrote: > On Sat, Jun 18, 2005 at 01:00:06AM -0400, Toshio Kuratomi wrote: > > On Fri, 2005-06-17 at 17:05 -0400, Nalin Dahyabhai wrote: > > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129025 > > > > What's a simple test case for this? I don't have a USB printer but I > > tried /usr ro on boot with no .pyo files. This does not cause cups to > > crash.... Starting other programs which have no .pyo files with > > PYTHON_OPTIMIZE set also causes no problems. Is the bug really only > > about SELinux and not a ro partition? Does this only happen with cups > > and USB printers? > > > > Being an anti-pyo person, I'd like to understand this problem so I can > > be converted :-) > > I can't speak to the specifics of cups and printing, but the problem > cases in which I'm interested are: > * Install a package with .py scripts. Use parts of the package as a > user who can write to the files, and you generate .pyc files. These > new files are not owned by any package, and RPM does not remove them > if you remove the package. > * If you can't write to them, and you were denied access by SELinux > permission checks (for example, you *were* root, but you were running > the script in an execution domain which wouldn't be allowed write > access), then you get a log message, either in syslog or in the audit > log. This leads to at least 40 unnecessary panic attacks, resulting > in no less than four separate posts to fedora-test-list within the > same day, which increases incoming traffic enough to finally kill the > mailing list servers. Please, think of the mailing list servers. > Seriously, though, it's preventable. > > The usefulness of .pyo files over .pyc files is marginal [1], but if > we're trying to avoid problems which crop up when a script only gets > byte-compiled on an installed system, I think we have to account for > them as well. > If I read this right, 1) is also solved by ghosting pyo files. 2) is the tradeoff -- either we have the nearly useless pyo's taking up space on the filesystem or we get SELinux messages giving false alarms. More (much more?) work for little gain, but likely the correct solution would be to configure SELinux policy to recognize a python program trying to write a pyo file and allow that to pass. (Coupled with % ghosting.) Now that I have a new laptop with a decent sized hard drive I suppose I'll just have to let go of my .pyo disgruntlement :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tmraz at redhat.com Tue Jun 21 11:06:17 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 21 Jun 2005 13:06:17 +0200 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119310705.7322.23.camel@localhost> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> Message-ID: <1119351978.5303.5.camel@perun.redhat.usu> > More (much more?) work for little gain, but likely the correct solution > would be to configure SELinux policy to recognize a python program > trying to write a pyo file and allow that to pass. (Coupled with % > ghosting.) No, that wouldn't be secure. The written .pyo file could be arbitrary code which if run again for example from a different security context could exploit your system even more. -- Tomas Mraz From notting at redhat.com Tue Jun 21 17:00:58 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Jun 2005 13:00:58 -0400 Subject: incoming: dependency warnings Message-ID: <20050621170058.GA9231@nostromo.devel.redhat.com> Starting later today or tomorrow, the build system will start sending mail when there are broken dependencies in the development tree. Mail will be sent to the package owner, and those who may be responsible. Consider yourself warned. I suppose it will be about two days until all of these are procmailed to /dev/null. Bill From pjones at redhat.com Tue Jun 21 17:20:08 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 21 Jun 2005 13:20:08 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119351978.5303.5.camel@perun.redhat.usu> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> <1119351978.5303.5.camel@perun.redhat.usu> Message-ID: <1119374408.1366.8.camel@localhost.localdomain> On Tue, 2005-06-21 at 13:06 +0200, Tomas Mraz wrote: > > More (much more?) work for little gain, but likely the correct solution > > would be to configure SELinux policy to recognize a python program > > trying to write a pyo file and allow that to pass. (Coupled with % > > ghosting.) > > No, that wouldn't be secure. The written .pyo file could be arbitrary > code which if run again for example from a different security context > could exploit your system even more. Just to be sure, is this really a problem at all? We're not shipping python set up to generate the .pyc and .pyo files by default, AFAIK, we're merely making rpm run the .pyc's through python -O. So if you log in as root and run some random python program that has a bunch of .py's in /usr/lib/python2.4/site-packages/, that shouldn't be generating .pyc's and .pyo's. This is _just_ /usr/lib/rpm/brp-redhat running brp-python-bytecompile, which in turn uses python -O to make .pyc's. It's not something at runtime. -- Peter From skvidal at phy.duke.edu Tue Jun 21 17:25:51 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 21 Jun 2005 13:25:51 -0400 Subject: incoming: dependency warnings In-Reply-To: <20050621170058.GA9231@nostromo.devel.redhat.com> References: <20050621170058.GA9231@nostromo.devel.redhat.com> Message-ID: <1119374751.24920.20.camel@opus.phy.duke.edu> On Tue, 2005-06-21 at 13:00 -0400, Bill Nottingham wrote: > Starting later today or tomorrow, the build system will start > sending mail when there are broken dependencies in the development > tree. > > Mail will be sent to the package owner, and those who may be > responsible. Consider yourself warned. > > I suppose it will be about two days until all of these are procmailed > to /dev/null. > And you'll be sending a general report to the -devel list for everyone to see, right? -sv From notting at redhat.com Tue Jun 21 17:30:00 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Jun 2005 13:30:00 -0400 Subject: incoming: dependency warnings In-Reply-To: <1119374751.24920.20.camel@opus.phy.duke.edu> References: <20050621170058.GA9231@nostromo.devel.redhat.com> <1119374751.24920.20.camel@opus.phy.duke.edu> Message-ID: <20050621173000.GA9969@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > > I suppose it will be about two days until all of these are procmailed > > to /dev/null. > > And you'll be sending a general report to the -devel list for everyone > to see, right? With this change, general 'these deps are broken' notes should be in the normal rawhide mail. Bill From jspaleta at gmail.com Tue Jun 21 17:33:23 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 21 Jun 2005 13:33:23 -0400 Subject: incoming: dependency warnings In-Reply-To: <20050621173000.GA9969@nostromo.devel.redhat.com> References: <20050621170058.GA9231@nostromo.devel.redhat.com> <1119374751.24920.20.camel@opus.phy.duke.edu> <20050621173000.GA9969@nostromo.devel.redhat.com> Message-ID: <604aa791050621103337475ea8@mail.gmail.com> On 6/21/05, Bill Nottingham wrote: > With this change, general 'these deps are broken' notes should be in > the normal rawhide mail. Now to see how many people actually read those reports.... -jef From jdennis at redhat.com Tue Jun 21 17:41:24 2005 From: jdennis at redhat.com (John Dennis) Date: Tue, 21 Jun 2005 13:41:24 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119374408.1366.8.camel@localhost.localdomain> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> <1119351978.5303.5.camel@perun.redhat.usu> <1119374408.1366.8.camel@localhost.localdomain> Message-ID: <1119375684.8228.12.camel@chickadee.boston.redhat.com> On Tue, 2005-06-21 at 13:20 -0400, Peter Jones wrote: > On Tue, 2005-06-21 at 13:06 +0200, Tomas Mraz wrote: > > > More (much more?) work for little gain, but likely the correct solution > > > would be to configure SELinux policy to recognize a python program > > > trying to write a pyo file and allow that to pass. (Coupled with % > > > ghosting.) > > > > No, that wouldn't be secure. The written .pyo file could be arbitrary > > code which if run again for example from a different security context > > could exploit your system even more. > > Just to be sure, is this really a problem at all? We're not shipping > python set up to generate the .pyc and .pyo files by default, AFAIK, > we're merely making rpm run the .pyc's through python -O. > > So if you log in as root and run some random python program that has a > bunch of .py's in /usr/lib/python2.4/site-packages/, that shouldn't be > generating .pyc's and .pyo's. > > This is _just_ /usr/lib/rpm/brp-redhat running brp-python-bytecompile, > which in turn uses python -O to make .pyc's. It's not something at > runtime. I think Tomas's observation is correct. The python interpreter we ship does attempt to generate .pyc files when it executes a .py file if its non-existent or out of date. It can be a security issue if the .pyc or .pyo file is malicious. It might be malicious if the .py file was malicious, but that is less likely since .py files are installed by root. However, if you allow any user/process to write a .pyo file for later execution you do expose yourself malicious intent via a .pyc or .pyo which is not derived from the source .py. -- John Dennis From pjones at redhat.com Tue Jun 21 18:07:29 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 21 Jun 2005 14:07:29 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119375684.8228.12.camel@chickadee.boston.redhat.com> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> <1119351978.5303.5.camel@perun.redhat.usu> <1119374408.1366.8.camel@localhost.localdomain> <1119375684.8228.12.camel@chickadee.boston.redhat.com> Message-ID: <1119377250.1366.15.camel@localhost.localdomain> On Tue, 2005-06-21 at 13:41 -0400, John Dennis wrote: > On Tue, 2005-06-21 at 13:20 -0400, Peter Jones wrote: > > On Tue, 2005-06-21 at 13:06 +0200, Tomas Mraz wrote: > > > > More (much more?) work for little gain, but likely the correct solution > > > > would be to configure SELinux policy to recognize a python program > > > > trying to write a pyo file and allow that to pass. (Coupled with % > > > > ghosting.) > > > > > > No, that wouldn't be secure. The written .pyo file could be arbitrary > > > code which if run again for example from a different security context > > > could exploit your system even more. > > > > Just to be sure, is this really a problem at all? We're not shipping > > python set up to generate the .pyc and .pyo files by default, AFAIK, > > we're merely making rpm run the .pyc's through python -O. > > > > So if you log in as root and run some random python program that has a > > bunch of .py's in /usr/lib/python2.4/site-packages/, that shouldn't be > > generating .pyc's and .pyo's. > > > > This is _just_ /usr/lib/rpm/brp-redhat running brp-python-bytecompile, > > which in turn uses python -O to make .pyc's. It's not something at > > runtime. > > I think Tomas's observation is correct. The python interpreter we ship > does attempt to generate .pyc files when it executes a .py file if its > non-existent or out of date. vroomfondel:~$ cat > foo.py < #!/usr/bin/python > print "foo" > EOF vroomfondel:~$ chmod 0755 ./foo.py vroomfondel:~$ ./foo.py foo vroomfondel:~$ ls -l foo.* -rwxr-xr-x 1 pjones pjones 30 Jun 21 14:05 foo.py vroomfondel:~$ It does? I don't _think_ I've changed anything related to that... -- Peter From icon at linux.duke.edu Tue Jun 21 18:12:12 2005 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Tue, 21 Jun 2005 14:12:12 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119377250.1366.15.camel@localhost.localdomain> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> <1119351978.5303.5.camel@perun.redhat.usu> <1119374408.1366.8.camel@localhost.localdomain> <1119375684.8228.12.camel@chickadee.boston.redhat.com> <1119377250.1366.15.camel@localhost.localdomain> Message-ID: <1119377532.7373.5.camel@hagrid.phy.duke.edu> On Tue, 2005-06-21 at 14:07 -0400, Peter Jones wrote: > vroomfondel:~$ cat > foo.py < > #!/usr/bin/python > > print "foo" > > EOF > vroomfondel:~$ chmod 0755 ./foo.py > vroomfondel:~$ ./foo.py > foo > vroomfondel:~$ ls -l foo.* > -rwxr-xr-x 1 pjones pjones 30 Jun 21 14:05 foo.py > vroomfondel:~$ > > It does? I don't _think_ I've changed anything related to that... icon at hagrid:[~]$ cat > foo.py< #!/usr/bin/python > print "imported foo" > EOF icon at hagrid:[~]$ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import foo imported foo >>> icon at hagrid:[~]$ ls foo* foo.py foo.pyc icon at hagrid:[~]$ Regards, -- Konstantin ("Icon") Ryabitsev Duke University Physics Sysadmin From jdennis at redhat.com Tue Jun 21 18:18:20 2005 From: jdennis at redhat.com (John Dennis) Date: Tue, 21 Jun 2005 14:18:20 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119377250.1366.15.camel@localhost.localdomain> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> <1119351978.5303.5.camel@perun.redhat.usu> <1119374408.1366.8.camel@localhost.localdomain> <1119375684.8228.12.camel@chickadee.boston.redhat.com> <1119377250.1366.15.camel@localhost.localdomain> Message-ID: <1119377901.8228.14.camel@chickadee.boston.redhat.com> On Tue, 2005-06-21 at 14:07 -0400, Peter Jones wrote: > It does? I don't _think_ I've changed anything related to that... It depends on how the interpreter reads the file, imports are compiled. -- John Dennis From toshio at tiki-lounge.com Tue Jun 21 18:32:16 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 21 Jun 2005 14:32:16 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119374408.1366.8.camel@localhost.localdomain> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> <1119351978.5303.5.camel@perun.redhat.usu> <1119374408.1366.8.camel@localhost.localdomain> Message-ID: <1119378736.2920.16.camel@localhost> On Tue, 2005-06-21 at 13:20 -0400, Peter Jones wrote: > On Tue, 2005-06-21 at 13:06 +0200, Tomas Mraz wrote: > > > More (much more?) work for little gain, but likely the correct solution > > > would be to configure SELinux policy to recognize a python program > > > trying to write a pyo file and allow that to pass. (Coupled with % > > > ghosting.) > > > > No, that wouldn't be secure. The written .pyo file could be arbitrary > > code which if run again for example from a different security context > > could exploit your system even more. > > Just to be sure, is this really a problem at all? We're not shipping > python set up to generate the .pyc and .pyo files by default, AFAIK, > we're merely making rpm run the .pyc's through python -O. > > So if you log in as root and run some random python program that has a > bunch of .py's in /usr/lib/python2.4/site-packages/, that shouldn't be > generating .pyc's and .pyo's. > Python does generate .pyc's by default. If certain environment variables are set then it generates pyo's instead This is why pyc's and pyo's must either be included in the package or %ghost'd. > This is _just_ /usr/lib/rpm/brp-redhat running brp-python-bytecompile, > which in turn uses python -O to make .pyc's. It's not something at > runtime. The announcement is about the use of brp-python-bytecompile which makes both pyc's and pyo's in the package build step. This is good as it saves some spec file work to get right. These are then listed in the % files section. However, the pyos can either be listed as regular files there or as %ghost files. Shahms asked whether we should continue to %ghost and Nalin replied with a bug report which shows "failures" when pyc's and pyo's are not present. It looks like the "failure" is actually a SELinux log message warning that python is trying to write out the pyc/pyo file if it doesn't already exist. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pjones at redhat.com Tue Jun 21 18:36:51 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 21 Jun 2005 14:36:51 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119377901.8228.14.camel@chickadee.boston.redhat.com> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> <1119351978.5303.5.camel@perun.redhat.usu> <1119374408.1366.8.camel@localhost.localdomain> <1119375684.8228.12.camel@chickadee.boston.redhat.com> <1119377250.1366.15.camel@localhost.localdomain> <1119377901.8228.14.camel@chickadee.boston.redhat.com> Message-ID: <1119379011.1366.17.camel@localhost.localdomain> On Tue, 2005-06-21 at 14:18 -0400, John Dennis wrote: > On Tue, 2005-06-21 at 14:07 -0400, Peter Jones wrote: > > > It does? I don't _think_ I've changed anything related to that... > > It depends on how the interpreter reads the file, imports are compiled. So we probably want to think very hard about making it _not_ do that unless you try very hard. -- Peter From laroche at redhat.com Tue Jun 21 19:03:53 2005 From: laroche at redhat.com (Florian La Roche) Date: Tue, 21 Jun 2005 21:03:53 +0200 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119379011.1366.17.camel@localhost.localdomain> References: <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> <1119351978.5303.5.camel@perun.redhat.usu> <1119374408.1366.8.camel@localhost.localdomain> <1119375684.8228.12.camel@chickadee.boston.redhat.com> <1119377250.1366.15.camel@localhost.localdomain> <1119377901.8228.14.camel@chickadee.boston.redhat.com> <1119379011.1366.17.camel@localhost.localdomain> Message-ID: <20050621190353.GB6317@dudweiler.stuttgart.redhat.com> On Tue, Jun 21, 2005 at 02:36:51PM -0400, Peter Jones wrote: > On Tue, 2005-06-21 at 14:18 -0400, John Dennis wrote: > > On Tue, 2005-06-21 at 14:07 -0400, Peter Jones wrote: > > > > > It does? I don't _think_ I've changed anything related to that... > > > > It depends on how the interpreter reads the file, imports are compiled. > > So we probably want to think very hard about making it _not_ do that > unless you try very hard. Makes sense to me. Trying to save the byte-compile output by default is really asking for trouble. greetings, Florian La Roche From jdennis at redhat.com Tue Jun 21 19:06:40 2005 From: jdennis at redhat.com (John Dennis) Date: Tue, 21 Jun 2005 15:06:40 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119379011.1366.17.camel@localhost.localdomain> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> <1119351978.5303.5.camel@perun.redhat.usu> <1119374408.1366.8.camel@localhost.localdomain> <1119375684.8228.12.camel@chickadee.boston.redhat.com> <1119377250.1366.15.camel@localhost.localdomain> <1119377901.8228.14.camel@chickadee.boston.redhat.com> <1119379011.1366.17.camel@localhost.localdomain> Message-ID: <1119380800.8228.20.camel@chickadee.boston.redhat.com> On Tue, 2005-06-21 at 14:36 -0400, Peter Jones wrote: > On Tue, 2005-06-21 at 14:18 -0400, John Dennis wrote: > > On Tue, 2005-06-21 at 14:07 -0400, Peter Jones wrote: > > > > > It does? I don't _think_ I've changed anything related to that... > > > > It depends on how the interpreter reads the file, imports are compiled. > > So we probably want to think very hard about making it _not_ do that > unless you try very hard. Why do you want to defeat this feature? If python is properly packaged in the rpm and the security policy is aware of where the python files are and who can write them then I don't see a problem. I only see a problem when these constraints are violated (albeit too frequently). -- John Dennis From laroche at redhat.com Tue Jun 21 19:10:40 2005 From: laroche at redhat.com (Florian La Roche) Date: Tue, 21 Jun 2005 21:10:40 +0200 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119380800.8228.20.camel@chickadee.boston.redhat.com> References: <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> <1119351978.5303.5.camel@perun.redhat.usu> <1119374408.1366.8.camel@localhost.localdomain> <1119375684.8228.12.camel@chickadee.boston.redhat.com> <1119377250.1366.15.camel@localhost.localdomain> <1119377901.8228.14.camel@chickadee.boston.redhat.com> <1119379011.1366.17.camel@localhost.localdomain> <1119380800.8228.20.camel@chickadee.boston.redhat.com> Message-ID: <20050621191040.GA6568@dudweiler.stuttgart.redhat.com> On Tue, Jun 21, 2005 at 03:06:40PM -0400, John Dennis wrote: > On Tue, 2005-06-21 at 14:36 -0400, Peter Jones wrote: > > On Tue, 2005-06-21 at 14:18 -0400, John Dennis wrote: > > > On Tue, 2005-06-21 at 14:07 -0400, Peter Jones wrote: > > > > > > > It does? I don't _think_ I've changed anything related to that... > > > > > > It depends on how the interpreter reads the file, imports are compiled. > > > > So we probably want to think very hard about making it _not_ do that > > unless you try very hard. > > Why do you want to defeat this feature? If python is properly packaged > in the rpm and the security policy is aware of where the python files > are and who can write them then I don't see a problem. I only see a > problem when these constraints are violated (albeit too frequently). We don't control enough packages to have them all fixed. So this is more of a burden then help to get them compiled if they are missing. greetings, Florian La Roche From pjones at redhat.com Tue Jun 21 19:16:10 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 21 Jun 2005 15:16:10 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119380800.8228.20.camel@chickadee.boston.redhat.com> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> <1119351978.5303.5.camel@perun.redhat.usu> <1119374408.1366.8.camel@localhost.localdomain> <1119375684.8228.12.camel@chickadee.boston.redhat.com> <1119377250.1366.15.camel@localhost.localdomain> <1119377901.8228.14.camel@chickadee.boston.redhat.com> <1119379011.1366.17.camel@localhost.localdomain> <1119380800.8228.20.camel@chickadee.boston.redhat.com> Message-ID: <1119381370.1366.24.camel@localhost.localdomain> On Tue, 2005-06-21 at 15:06 -0400, John Dennis wrote: > On Tue, 2005-06-21 at 14:36 -0400, Peter Jones wrote: > > On Tue, 2005-06-21 at 14:18 -0400, John Dennis wrote: > > > On Tue, 2005-06-21 at 14:07 -0400, Peter Jones wrote: > > > > > > > It does? I don't _think_ I've changed anything related to that... > > > > > > It depends on how the interpreter reads the file, imports are compiled. > > > > So we probably want to think very hard about making it _not_ do that > > unless you try very hard. > > Why do you want to defeat this feature? If python is properly packaged > in the rpm and the security policy is aware of where the python files > are and who can write them then I don't see a problem. I only see a > problem when these constraints are violated (albeit too frequently). 1) it's trivially easy to create the .pyc/.pyo if you need to 2) in most cases they'll be there already, because with python's "everything is built in" model, most python modules will be packages on the system, and thus brp-python-bytecompile will have been run. 3) not doing automatic pycompile at runtime means we don't need to worry about security contexts and perms of generated files at all, even for things that aren't packaged... Maybe we should also drop one of the 2-line python bytecompile programs into /usr/bin, as a convenience for those that are running noticeable amounts of python that aren't packaged. (Really, though, I have fairly low amounts of sympathy for that usage model.) -- Peter From toshio at tiki-lounge.com Tue Jun 21 20:24:21 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 21 Jun 2005 16:24:21 -0400 Subject: The recent redhat-rpm-config change and you In-Reply-To: <1119375684.8228.12.camel@chickadee.boston.redhat.com> References: <20050617205210.GF13260@redhat.com> <42B338ED.7070206@shahms.com> <20050617210538.GG13260@redhat.com> <1119070807.2997.5.camel@localhost> <20050620174453.GC19618@redhat.com> <1119310705.7322.23.camel@localhost> <1119351978.5303.5.camel@perun.redhat.usu> <1119374408.1366.8.camel@localhost.localdomain> <1119375684.8228.12.camel@chickadee.boston.redhat.com> Message-ID: <1119385461.2920.50.camel@localhost> On Tue, 2005-06-21 at 13:41 -0400, John Dennis wrote: > > I think Tomas's observation is correct. The python interpreter we ship > does attempt to generate .pyc files when it executes a .py file if its > non-existent or out of date. It can be a security issue if the .pyc > or .pyo file is malicious. It might be malicious if the .py file was > malicious, but that is less likely since .py files are installed by > root. However, if you allow any user/process to write a .pyo file for > later execution you do expose yourself malicious intent via a .pyc > or .pyo which is not derived from the source .py. I would think SELinux could be configured to allow each particular python program to write the pyo's that belong to them and only them. As long as that's the case it wouldn't really be any arbitrary code which could overwrite the pyo's. If so, the exploit route is: a python program which takes user input and writes out files. It is also probably setuid otherwise the malicious user can't circumvent the UNIX permissions to write to it. Malicious user gives input to the program that tricks it into overwriting one of the pyo's present with some python bytecode that does something even worse. They then rerun the program, executing the new bytecode to do what they wish. It's better than running without SELinux but it isn't as secure as running with SELinux disallowing writes altogether. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jorton at redhat.com Wed Jun 22 08:54:42 2005 From: jorton at redhat.com (Joe Orton) Date: Wed, 22 Jun 2005 09:54:42 +0100 Subject: FC4 library symbol collision report Message-ID: <20050622085442.GA24506@redhat.com> After finding the first new PHP symbol collision for FC4, I thought I'd run my script to check for library symbol collisions. Output below shows places where more than one library defines a particular symbol: quite a few obviously dubious things here: Symbol clashes between libraries /usr/lib/php/modules/dom.so /usr/lib/php/modules/xsl.so: => dom_node_class_entry Symbol clashes between libraries /usr/lib/libgs.so.7 /usr/sbin/httpd: => main Symbol clashes between libraries /usr/lib/libkdecore.so.4 /usr/lib/libnetsnmp.so.5: => strlcpy Symbol clashes between libraries /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi/auto/PDL/GSL/DIFF/DIFF.so /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi/auto/PDL/GSL/INTEG/INTEG.so: => FUNC Symbol clashes between libraries /usr/lib/libnetsnmpagent.so.5 /usr/lib/libwrap.so.0: => deny_severity allow_severity Symbol clashes between libraries /usr/lib/libgssapi_krb5.so.2 /usr/lib/libk5crypto.so.3 /usr/lib/libkrb5.so.3 /usr/lib/libkrb5support.so.0: => HIDDEN Symbol clashes between libraries /usr/lib/libgs.so.7 /usr/lib/libpng12.so.0: => png_push_fill_buffer Symbol clashes between libraries /usr/lib/libodbcpsql.so.2 /usr/lib/libpq.so.4: => md5_hash EncryptMD5 Symbol clashes between libraries /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi/auto/DBD/mysql/mysql.so /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi/auto/DBD/Pg/Pg.so: => dbd_discon_all Symbol clashes between libraries /usr/lib/httpd/modules/mod_perl.so /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi/auto/ModPerl/Const/Const.so: => modperl_constants_lookup_modperl modperl_constants_group_lookup_apache2_const modperl_constants_lookup_apache2_const modperl_constants_group_lookup_apr_const modperl_constants_lookup_apr_const XS_modperl_const_compile modperl_const_compile modperl_constants_group_lookup_modperl Symbol clashes between libraries /usr/lib/php/modules/bcmath.so /usr/lib/php/modules/dba.so /usr/lib/php/modules/dom.so /usr/lib/php/modules/gd.so /usr/lib/php/modules/imap.so /usr/lib/php/modules/ldap.so /usr/lib/php/modules/mbstring.so /usr/lib/php/modules/mysqli.so /usr/lib/php/modules/mysql.so /usr/lib/php/modules/ncurses.so /usr/lib/php/modules/odbc.so /usr/lib/php/modules/pgsql.so /usr/lib/php/modules/snmp.so /usr/lib/php/modules/soap.so /usr/lib/php/modules/xmlrpc.so /usr/lib/php/modules/xsl.so: => get_module Symbol clashes between libraries /usr/lib/libodbcpsql.so.2 /usr/lib/libodbc.so.1: => SQLProcedures SQLFreeStmt SQLDescribeParam SQLSetStmtOption SQLBindCol SQLStatistics SQLTransact SQLExtendedFetch SQLNumParams SQLSetCursorName SQLSetPos SQLColAttributes SQLDriverConnect SQLExecute SQLTablePrivileges SQLPrimaryKeys SQLGetFunctions SQLAllocEnv SQLFreeEnv SQLParamData SQLMoreResults SQLAllocStmt SQLGetCursorName SQLColumnPrivileges SQLSetScrollOptions SQLPrepare SQLForeignKeys SQLBindParameter SQLProcedureColumns SQLSpecialColumns SQLDescribeCol SQLGetConnectOption SQLRowCount SQLGetInfo SQLNumResultCols SQLCancel SQLFreeConnect SQLNativeSql SQLExecDirect SQLTables SQLPutData SQLGetData SQLFetch SQLSetConnectOption SQLError SQLDisconnect SQLGetStmtOption SQLGetTypeInfo SQLColumns SQLParamOptions SQLAllocConnect SQLBrowseConnect SQLConnect Symbol clashes between libraries /usr/lib/libkdecore.so.4 /usr/lib/qt-3.3/lib/libqt-mt.so.3: => qt_qclipboard_bailout_hack Symbol clashes between libraries /usr/lib/httpd/modules/mod_perl.so /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi/auto/APR/APR.so: => modperl_bucket_sv_create modperl_trace_logfile_set modperl_trace_level_set modperl_debug_level modperl_trace modperl_hash_tied_object modperl_error_strerror modperl_croak modperl_hash_tie modperl_hash_tied_object_rv modperl_uri_new MP_debug_level modperl_perl_gensym modperl_perl_sv_setref_uv Symbol clashes between libraries /usr/lib/libkdecore.so.4 /usr/lib/libltdl.so.3: => lt_dlopen lt_dlloader_find lt_dlgetinfo lt_dlinit lt_dlcaller_get_data lt_dlseterror lt_dlmutex_register lt_dlcaller_set_data lt_dlpreload_default lt_dlcaller_register lt_dlisresident lt_dlmakeresident lt_dlclose lt_dlloader_name lt_dlhandle_next lt_dlloader_next lt_dlloader_remove lt_dlloader_data lt_dlloader_add lt_dlmalloc lt_dlpreload lt_dlforeach lt_dlopenext lt_dlexit lt_dlerror lt_dlfree lt_dlsetsearchpath lt_dladderror lt_dlgetsearchpath lt_dlsym lt_dladdsearchdir Symbol clashes between libraries /usr/lib/libgs.so.7 /usr/lib/libjpeg.so.62: => jpeg_mem_term jpeg_mem_available jpeg_free_small jpeg_get_small jpeg_get_large jpeg_open_backing_store jpeg_mem_init jpeg_free_large Symbol clashes between libraries /usr/X11R6/lib/libICE.so.6 /usr/X11R6/lib/libX11.so.6: => in6addr_any Symbol clashes between libraries /usr/lib/libcups.so.2 /usr/lib/libgs.so.7: => md5_init md5_append md5_finish From bugs.michael at gmx.net Wed Jun 29 10:16:03 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 29 Jun 2005 12:16:03 +0200 Subject: Attention: Extras CVS, FC-4 vs. devel Message-ID: <20050629121603.4fb760ef.bugs.michael@gmx.net> Just a heads up on EVR comparison of what's found in Fedora Extras CVS. This may turn out to be relevant when you update your package(s): Hermes 0:1.3.3-9.fc4 in FC-4 branch is newer than devel (0:1.3.3-8) cone 0:0.64-5 in FC-4 branch is newer than devel (0:0.64-4) directfb 0:0.9.22-1.fc4 in FC-4 branch is newer than devel (0:0.9.21-1) fluxconf 0:0.9.8-1.fc4 in FC-4 branch is newer than devel (0:0.9.7-2) fping 0:2.4b2-4.fc4 in FC-4 branch is newer than devel (0:2.4b2-3.fc5) gcfilms 0:5.2-1 in FC-4 branch is newer than devel (0:5.0-5) inadyn 0:1.90-11.fc4 in FC-4 branch is newer than devel (0:1.90-11) libkipi 0:0.1.1-1.2.fc4 in FC-4 branch is newer than devel (0:0.1.1-1.fc5) liboil 0:0.3.2-2.fc4 in FC-4 branch is newer than devel (0:0.3.2-1) octave 6:2.1.71-12.fc4 in FC-4 branch is newer than devel (6:2.1.71-11.fc5) octave-forge 0:2005.06.13-6.fc4 in FC-4 branch is newer than devel (0:2005.06.13-1.fc5) scons 0:0.96.1-1.fc4 in FC-4 branch is newer than devel (0:0.96-5) tktable 0:2.9-4 in FC-4 branch is newer than devel (0:2.9-3) yap 0:4.5.5-6.fc4 in FC-4 branch is newer than devel (0:4.5.5-3.fc5) From andreas.bierfert at lowlatency.de Wed Jun 29 10:59:08 2005 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Wed, 29 Jun 2005 12:59:08 +0200 Subject: Attention: Extras CVS, FC-4 vs. devel In-Reply-To: <20050629121603.4fb760ef.bugs.michael@gmx.net> References: <20050629121603.4fb760ef.bugs.michael@gmx.net> Message-ID: <42C27EFC.5050204@lowlatency.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > Just a heads up on EVR comparison of what's found in Fedora Extras CVS. > This may turn out to be relevant when you update your package(s): > [...] > fluxconf 0:0.9.8-1.fc4 in FC-4 branch is newer than devel (0:0.9.7-2) Thx... fixed. - -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 172 9789968 | mail preferred -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCwn78QEQyPsWM8csRAiuIAJ9LeBUy5w6u4v/+zLKOc3WkhTBZ9wCgrr1P RC+QjJwlsMsQ21zy1+e1N9E= =ffWg -----END PGP SIGNATURE----- From bugs.michael at gmx.net Wed Jun 29 21:02:19 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 29 Jun 2005 23:02:19 +0200 Subject: Fedora Extras: missing bugzilla components Message-ID: <20050629230219.20ef64b0.bugs.michael@gmx.net> Packages in Fedora Extras CVS which do not have a component entry in bugzilla: drivel epiphany-extensions gaim-otr gambas libannodex libcmml libesmtp liboggz libotr mod_annodex openvpn php-pecl-pdo-sqlite php-pecl-pdo scim-anthy spamass-milter What do you need to do? See if your package is on this list and if it is an approved package, request addition of a bugzilla component entry on this Wiki page: http://fedoraproject.org/wiki/Extras/BugzillaAdmin Offer: reply off-list and state package name(s) and bugzilla account e-mail address, and I request creation of the bugzilla component(s). The reason I cannot request creation of bugzilla entries for these packages instead of posting this is that I don't know who owns them or what every packager's bugzilla account e-mail address is. From wtogami at redhat.com Thu Jun 30 10:31:54 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 30 Jun 2005 12:31:54 +0200 Subject: Package Process for Discussion Message-ID: <42C3CA1A.8010709@redhat.com> Due to my screwed up sleep schedule while adjusting to another 12 hour timezone change, I have not yet had a chance to talk with Dave in real-time. These are a bunch of preliminary thoughts to expand on the package review states that we created during the FUDCON2 meeting. This design is heading towards the database driven package review process. Everything related to a package will be tracked in a ticket rather than scattered in the confusing mess that we have now. I pose some new ideas and questions below. I also wonder if all of this is possible with a custom bugzilla template. If you see anything missing please speak up. STATES FOR NEW PACKAGE REVIEW: ============================== - NEW new package submission, can be claimed - PENDING/REVIEW claimed, or reviewer must re-examine Warren: Reading this back after the meeting, this makes no sense to me. The other PENDING statuses mean "we're stuck until someone does something". For this reason I think it makes no sense to call this PENDING. Perhaps "REVIEW_UNDERWAY" better describes exactly what is happening? If the review is canceled or times out, should it go back to NEW or some other state that means NOT_NEW_BUT_NEEDS_REVIEW_AGAIN? If the reason for NEEDSWORK is fixed, should it go back to NEW or some other state that means NOT_NEW_BUT_NEEDS_REVIEW_AGAIN? I personally think it makes little sense to have a "NEW" state and another that have almost the same meaning, because they are both in an unclaimed state. Any thoughts? If you think we should have that other state, what should we call it? - PENDING/NEEDSWORK review has identified problems, packager must do work in order to proceed further. - PENDING/LEGAL review has identified potential legal issues, legal must research in order to proceed further - FAILED/LICENSE packager must fix license and reopen - FAILED/LEGAL packager must fix legal issues and reopen - FAILED/SEE-NOTE packager must fix whatever is mentioned in the note and reopen Warren: FAILED is a failure state where it would take a serious amount of work, like convincing upstream to change a license, or convincing a government to change a law, before the package is acceptable for Extras. - PASSED/DONE (CLOSED) (RESOLUTION) Warren: Passed is an indication of the package passing review, but should we also track if the build is complete, signed and pushed? It can be misleading to read "DONE" in a query when the package is not yet pushed. Dave, how do you think we should best represent Built/Signed/Pushed here? Built and Signed/Pushed could be represented as two states, since Build happens at a different time from Sign & Push which happen together. fedora.us used differnet Bugzilla resolution states for this, and it was convenient to query for and show up in rows of query results, but I am hoping there is a better way. Some other Misc. Thoughts ========================= 1) "Claimed" status must automatically timeout after a certain amount of time. Maybe 12 hours? 2) https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&format=extras-review This is the current submission interface. I think perhaps the Arch chooser is not ideal here. There is no way of saying for example "i386 and ppc but not x86-64". It may be better to instead hide the Arch field, and use flags for each arch? The form could have all supported archs checked by default, and the submitter could uncheck them explicitly if they want to be excluded. 3) There should be a field asking for only package name, while the Summary field is to describe the package in a one liner. The current "Help" for Summary doesn't encourage including the package name. Dave is it possible to then within a query display "packagename - Summary" automatically? 4) It appears that the form wants to submit to product "Fedora Extras" currently. Shouldn't it submit to its own product, so we can keep these bugs away from the bugs associated with actual packages with owners? 5) There are no "owners" of package requests, so there need to be various auto-mailers setup, like a mailing list for people to subscribe to watch new package submissions. Some people even want to see all QA traffic, so this would be a different list. It would be nice if we could use mailman's concept of sublists in order to automatically kill the potential for annoying duplication, but I'm not exactly sure how this would work in this case. 6) We want flags for target distribution. The flags would default checked for "4" and "devel", and the submitter can choose more target distributions if they wish. Warren Togami wtogami at redhat.com From ivazquez at ivazquez.net Thu Jun 30 11:32:25 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 30 Jun 2005 07:32:25 -0400 Subject: Package Process for Discussion In-Reply-To: <42C3CA1A.8010709@redhat.com> References: <42C3CA1A.8010709@redhat.com> Message-ID: <1120131145.4540.7.camel@ignacio.ignacio.lan> On Thu, 2005-06-30 at 12:31 +0200, Warren Togami wrote: > If the review is canceled or times out, should it go back to NEW or some > other state that means NOT_NEW_BUT_NEEDS_REVIEW_AGAIN? > > If the reason for NEEDSWORK is fixed, should it go back to NEW or some > other state that means NOT_NEW_BUT_NEEDS_REVIEW_AGAIN? > > I personally think it makes little sense to have a "NEW" state and > another that have almost the same meaning, because they are both in an > unclaimed state. Any thoughts? If you think we should have that other > state, what should we call it? REVISED? NEEDSREVISION? > Some other Misc. Thoughts > ========================= > 1) "Claimed" status must automatically timeout after a certain amount of > time. Maybe 12 hours? Works for me. It requires reviewers to be on the ball, but doesn't penalize them if something comes up in the meantime. > 2) > https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&format=extras-review > This is the current submission interface. I think perhaps the Arch > chooser is not ideal here. There is no way of saying for example "i386 > and ppc but not x86-64". It may be better to instead hide the Arch > field, and use flags for each arch? > > The form could have all supported archs checked by default, and the > submitter could uncheck them explicitly if they want to be excluded. Agreed. > 4) It appears that the form wants to submit to product "Fedora Extras" > currently. Shouldn't it submit to its own product, so we can keep these > bugs away from the bugs associated with actual packages with owners? Sounds like a plan. That may also simplify the notification logic. > 5) There are no "owners" of package requests, so there need to be > various auto-mailers setup, like a mailing list for people to subscribe > to watch new package submissions. Some people even want to see all QA > traffic, so this would be a different list. It would be nice if we > could use mailman's concept of sublists in order to automatically kill > the potential for annoying duplication, but I'm not exactly sure how > this would work in this case. The next revision of BZ is supposed to have RSS support IIRC. That could be another option. > 6) We want flags for target distribution. The flags would default > checked for "4" and "devel", and the submitter can choose more target > distributions if they wish. Another excellent idea. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Christian.Iseli at licr.org Thu Jun 30 12:00:13 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 30 Jun 2005 14:00:13 +0200 Subject: Package Process for Discussion In-Reply-To: Your message of "Thu, 30 Jun 2005 12:31:54 +0200." <42C3CA1A.8010709@redhat.com> Message-ID: <200506301200.j5UC0DpJ015198@ludwig-alpha.unil.ch> wtogami at redhat.com said: > https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&format=extras-review > This is the current submission interface. I like the form in general, but I agree a few changes would make it even better: - checkboxes for the various platforms, all on by default - checkboxes for the FC releases, default on for the latest release and devel - one field to enter the package name - maybe one field to enter the license type - it's not completely clear to me what should go in the Cc field. If I want to receive email notices about changes to the ticket, should I add myself when I create the ticket ? Or, as the ticket creator, do I automatically get those notices ? Cheers, Christian From j.w.r.degoede at hhs.nl Thu Jun 30 12:11:19 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 30 Jun 2005 14:11:19 +0200 Subject: Package Process for Discussion In-Reply-To: <200506301200.j5UC0DpJ015198@ludwig-alpha.unil.ch> References: <200506301200.j5UC0DpJ015198@ludwig-alpha.unil.ch> Message-ID: <42C3E167.3060405@hhs.nl> What about requests by users not capable todo packaging to create a package for something, is there a place to track those? Regards, Hans From wtogami at redhat.com Thu Jun 30 17:31:57 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 30 Jun 2005 19:31:57 +0200 Subject: Package Process for Discussion In-Reply-To: <42C3E167.3060405@hhs.nl> References: <200506301200.j5UC0DpJ015198@ludwig-alpha.unil.ch> <42C3E167.3060405@hhs.nl> Message-ID: <42C42C8D.8070506@redhat.com> Hans de Goede wrote: > What about requests by users not capable todo packaging to create a > package for something, is there a place to track those? > For now we need to focus our energies on people who actually take the time to make packages, then being able to meet them half-way, revise and accept those packages. We should not attempt to win all battles at once. Warren From fedora at leemhuis.info Thu Jun 30 17:50:20 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Jun 2005 19:50:20 +0200 Subject: Package Process for Discussion In-Reply-To: <42C42C8D.8070506@redhat.com> References: <200506301200.j5UC0DpJ015198@ludwig-alpha.unil.ch> <42C3E167.3060405@hhs.nl> <42C42C8D.8070506@redhat.com> Message-ID: <1120153820.3714.68.camel@notebook.thl.home> Am Donnerstag, den 30.06.2005, 19:31 +0200 schrieb Warren Togami: > Hans de Goede wrote: > > What about requests by users not capable todo packaging to create a > > package for something, is there a place to track those? > For now we need to focus our energies on people who actually take the > time to make packages, then being able to meet them half-way, revise and > accept those packages. We should not attempt to win all battles at once. Well there are already some Package Request in out bugzilla. Not sure if thats the right place. Maybe we should close those and add them to http://www.fedoraproject.org/wiki/WishlistExtras To cite: As a current contributor, if you know of projects that would be appropriate in Fedora Core or Fedora Extras but are unable to maintain yourself just drop them with a line here. This list can be used to give other contributors ideas on what to package next. Please be aware however that the number of high quality, well maintained packages that Extras can provide scales with the number of active contributors. It is just as important to encourage new contributors as it is to desire new packages. If you are not yet a contributor to the Extras packaging process, please look over this list and see if there are any projects you would be willing to maintain for the Fedora community. Please remember that new packages will be added to Extras first and go to Core if deemed suitable later by Core developers. -- Thorsten Leemhuis From jspaleta at gmail.com Thu Jun 30 18:45:02 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 30 Jun 2005 14:45:02 -0400 Subject: Package Process for Discussion In-Reply-To: <1120153820.3714.68.camel@notebook.thl.home> References: <200506301200.j5UC0DpJ015198@ludwig-alpha.unil.ch> <42C3E167.3060405@hhs.nl> <42C42C8D.8070506@redhat.com> <1120153820.3714.68.camel@notebook.thl.home> Message-ID: <604aa79105063011451089cbba@mail.gmail.com> On 6/30/05, Thorsten Leemhuis wrote: > Well there are already some Package Request in out bugzilla. Not sure if > thats the right place. Maybe we should close those and add them to > > http://www.fedoraproject.org/wiki/WishlistExtras Considering that I'm the one who wrote the bulk of that happy happy joy joy prose on that page, I want to strongly encourage you to NOT turn that page into a dumping ground for all possible package requests. Having one page list 300+ packages that "someone" wants "someone else" to maintain is irresponsible. In my absolutely supreme and undeniably logical opinion, that page should be used for highlighting a "small" collection of packages yet to be entered into extras to give the sense that there is still room for more contributors. -jef