From bjorn at xn--rombobjrn-67a.se Mon Jun 1 00:07:08 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Mon, 1 Jun 2009 02:07:08 +0200 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: <1243793742.3037.181.camel@localhost.localdomain> References: <1243793742.3037.181.camel@localhost.localdomain> Message-ID: <200906010207.29651.bjorn@xn--rombobjrn-67a.se> Jesse Keating wrote: > Conceivably though you can have a scenario where if a suggested package > is present, you'll want to make use of it in the %pre section of the > suggesting package, and fail gracefully if it isn't there. So Suggests: > isn't enough, you'd need to order it so that if you choose to install > the suggestion, it gets installed prior to the suggesting package, hence > Suggests(post). You have to handle the situation where the user installs package A and then two months later installs package B. You also have to handle the situation where the user installs B and then later installs A. This is true for any two packages A and B as long as none of them has a hard requirement on the other. It seems to me that once you handle both of those cases correctly, it doesn't matter which order RPM chooses when the user installs both packages at once. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From oisin.feeley at gmail.com Mon Jun 1 01:04:41 2009 From: oisin.feeley at gmail.com (Oisin Feeley) Date: Sun, 31 May 2009 21:04:41 -0400 Subject: Fedora Weekly News seeks Beat Writer Message-ID: Hello, Fedora Weekly News is searching for someone interested in writing the weekly beat which covers this @fedora-devel list. Please contact fedora-news-list at redhat.comif you are interested after taking a look at the Join[1] and Workflow[2] pages. 1. http://fedoraproject.org/wiki/NewsProject/Join 2. http://fedoraproject.org/wiki/FWN/WorkFlow Best wishes, -- Oisin Feeley -------------- next part -------------- An HTML attachment was scrubbed... URL: From pasik at iki.fi Mon Jun 1 05:15:48 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Mon, 1 Jun 2009 08:15:48 +0300 Subject: F11: kernel/boot hangs at creating initial device nodes with 2.6.30-rc6 Message-ID: <20090601051548.GW24960@edu.joroinen.fi> Hello. Yesterday I installed latest F11/rawhide. The default installed kernel (2.6.29 something) works fine. I compiled custom 2.6.30-rc6 kernel, and created initrd for it, and tried booting it. Booting process gets stuck at "creating initial device nodes". Any ideas? I assume that's during initrd execution.. Something missing from my kernel config? Any tips would be appreciated. Thanks! -- Pasi From bernie at codewiz.org Mon Jun 1 05:32:56 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Mon, 01 Jun 2009 07:32:56 +0200 Subject: Unbootable machine Message-ID: <4A236808.1050106@codewiz.org> Hello Peter & Jeremy, I've found an ordinary desktop PC (with Phoenix Award BIOS 6.00PG) that won't boot off a USB stick created by livecd-tools-024 with syslinux (tested both versions 3.75 and 3.81). The boot process drops to the "boot:" prompt with an error message: could not find kernel image: linux The same USB stick boots fine on any other computer I could find. Does it seem like a syslinux bug? And if turns out to be a known BIOS bug, is there a good workaround? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From hpa at zytor.com Mon Jun 1 06:39:47 2009 From: hpa at zytor.com (H. Peter Anvin) Date: Sun, 31 May 2009 23:39:47 -0700 Subject: Unbootable machine In-Reply-To: <4A236808.1050106@codewiz.org> References: <4A236808.1050106@codewiz.org> Message-ID: <4A2377B3.8060309@zytor.com> Bernie Innocenti wrote: > Hello Peter & Jeremy, > > I've found an ordinary desktop PC (with Phoenix Award BIOS 6.00PG) that > won't boot off a USB stick created by livecd-tools-024 with syslinux > (tested both versions 3.75 and 3.81). > > The boot process drops to the "boot:" prompt with an error message: > > could not find kernel image: linux > > The same USB stick boots fine on any other computer I could find. > Does it seem like a syslinux bug? And if turns out to be a known BIOS > bug, is there a good workaround? > I need much more details; *all* Award BIOSes make in the past 10-12 years have version number 6.00PG. Also look for how you have configured your BIOS... some Award BIOSes have USB-ZIP, USB-HDD, USB-FDD configurations; you generally want USB-HDD. There are some BIOSes which will boot from USB *only* if it was formatted with 64 heads, 32 sectors; apparently due to some odd notion that only zipdrives would be USB. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. From rjones at redhat.com Mon Jun 1 08:53:47 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 1 Jun 2009 09:53:47 +0100 Subject: Fedora bittorrent tracker? Message-ID: <20090601085347.GA3561@amd.home.annexia.org> Do we offer a bittorrent tracker that FAS / fp.org users can use to host their own bittorrent content? (Obviously it'll be Fedora/free software-related content) Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html From mail at robertoragusa.it Mon Jun 1 08:54:06 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Mon, 01 Jun 2009 10:54:06 +0200 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> Message-ID: <4A23972E.2060805@robertoragusa.it> Mathieu Bridon (bochecha) wrote: > > Of course, it can't know why you installed them or even if something > outside of its scope (e.g. a program you compiled manually) still > needs one of those. IMHHHO, this is the first thing to address to get a reasonable behavior. Every installed rpm on the system should be marked with a bit "wanted by the user". Current systems just need a way to manually flag the packages already installed. I need firefox, not glibc, not libjpg. If I remove firefox and thunderbird and all the other stuff, libjpg can be removed too, from the point of view of the user. It is somewhat annoying when one installs a package which drags 10 dependencies, then removes the package and there is no easy way to cleanup all the libs and additional stuff. Best regards. -- Roberto Ragusa mail at robertoragusa.it From ricky at fedoraproject.org Mon Jun 1 09:00:54 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 1 Jun 2009 05:00:54 -0400 Subject: Fedora bittorrent tracker? In-Reply-To: <20090601085347.GA3561@amd.home.annexia.org> References: <20090601085347.GA3561@amd.home.annexia.org> Message-ID: <20090601090054.GB32470@alpha.rzhou.org> On 2009-06-01 09:53:47 AM, Richard W.M. Jones wrote: > Do we offer a bittorrent tracker that FAS / fp.org users can use to > host their own bittorrent content? > > (Obviously it'll be Fedora/free software-related content) You can always make a request to Infrastructure at https://fedorahosted.org/fedora-infrastructure/. We've hosted some Fedora-related things there before. No idea if we have any sort of policy on what goes there though. It'll probably depend on how much space we have and how long it needs to be there for, etc. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bochecha at fedoraproject.org Mon Jun 1 09:38:24 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Mon, 1 Jun 2009 11:38:24 +0200 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <4A23972E.2060805@robertoragusa.it> References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> <4A23972E.2060805@robertoragusa.it> Message-ID: <2d319b780906010238t77ebe521q133b6fea3503981e@mail.gmail.com> > It is somewhat annoying when one installs a package which drags > 10 dependencies, then removes the package and there is no > easy way to cleanup all the libs and additional stuff. Actually, there are two: - package-cleanup that I mentioned - yum-plugin-remove-with-leaves that Seth mentioned which is even easier ---------- Mathieu Bridon (bochecha) From mspevack at redhat.com Mon Jun 1 10:04:02 2009 From: mspevack at redhat.com (Max Spevack) Date: Mon, 1 Jun 2009 12:04:02 +0200 (CEST) Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <4A227206.9010601@fedoraproject.org> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> <4A2269C7.1010800@fedoraproject.org> <1243770864.26053.8.camel@localhost.localdomain> <4A227206.9010601@fedoraproject.org> Message-ID: On Sun, 31 May 2009, Rahul Sundaram wrote: > I don't see it recorded in > > https://fedoraproject.org/wiki/Trademark_licensees > > It doesn't fit the trademark guidelines either. While Red Hat can > legally grant a license to anyone and doesn't have to abide by the > guidelines, I would expect it to do so nevertheless. So why a special > exception for "Russian Fedora"? There shouldn't be a special case, and it's possible that Red Hat's distributor in Russia may have granted some sort of permision that (a) it shouldn't have, and (b) it didn't even have the authority to grant. The Russian-specific portions of this thread seem to have moved over here, where I responded to a similar thread. http://www.redhat.com/archives/fedora-ambassadors-list/2009-June/msg00000.html --Max From mnowak at redhat.com Mon Jun 1 10:24:50 2009 From: mnowak at redhat.com (Michal Nowak) Date: Mon, 1 Jun 2009 06:24:50 -0400 (EDT) Subject: Orphaned eclipse-pydev In-Reply-To: <927812054.3694091243851856775.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1709738315.3694111243851890236.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Orphaned eclipse-pydev, feel free to take it. Michal From choeger at cs.tu-berlin.de Mon Jun 1 10:43:12 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 01 Jun 2009 12:43:12 +0200 Subject: Orphaned eclipse-pydev In-Reply-To: <1709738315.3694111243851890236.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1709738315.3694111243851890236.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1243852992.2514.4.camel@choeger6> Isn't that this application with ads in it? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From dimitris at glezos.com Mon Jun 1 10:49:20 2009 From: dimitris at glezos.com (Dimitris Glezos) Date: Mon, 1 Jun 2009 13:49:20 +0300 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <1243358736.3144.23.camel@localhost.localdomain> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> Message-ID: <6d4237680906010349x7717518epc9000be2819ef299@mail.gmail.com> On Tue, May 26, 2009 at 8:25 PM, Jesse Keating wrote: > On Tue, 2009-05-26 at 21:10 +0400, Peter Lemenkov wrote: >> 2009/5/26 Bill Nottingham : >> >> >> Subj. As Debian folks did years ago. Such branching will be done very >> >> easy technically. >> > >> > Because all the builds and composition is done in the US, and the trademarks >> > are held by a US entity. >> >> Not a serious reason. Why not to relocate then in Europe? > > Find us a Company in Europe that is not based in the US that is willing > to fund with people and money as much as Red Hat is doing now. A new company acting as Fedora's primary sponsor isn't necessarily needed -- ie it's not "Either Fedora under Red Hat or Fedora under X". Red Hat has been investing in Fedora for many years, and I believe something like eg. founding a Fedora Foundation in Germany wouldn't stop Red Hat from continuing to paying Fedora people internationally and providing money for running our events. Yes, a foundation might have some challenges in running it. But 1. we are having challenges and limitations now too and 2. unless I hear specific show-stoppers for a non-profit in Europe (eg. Germany), I'll continue to believe it could be a viable solution. > Oh, Europe won't help much, there are just as many silly laws there as > there are in the US. Europe is a more multicultural organism, and one could argue that this theoretically leads to less stupid decisions (not necessarily to more wise ones, though). -? -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From rjones at redhat.com Mon Jun 1 12:13:19 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 1 Jun 2009 13:13:19 +0100 Subject: Agenda for the 2009-05-26 Packaging Committee meeting In-Reply-To: References: <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> Message-ID: <20090601121319.GA3522@amd.home.annexia.org> On Sat, May 30, 2009 at 12:53:07PM +0300, Panu Matilainen wrote: > Or consider "Recommends: B >= 1.2" - what exactly does this mean? The > package does something "better" if B is installed too, but what if we > only have B 1.0 installed/available. Does the package even work with B > 1.0? If it doesn't work with B 1.0, should rpm emit an error in such a > case? If the version doesn't match, should B be pulled in anyway? As far as I can tell, in Debian a versioned suggestion is still just a suggestion. If B = 1.0 were installed, it would be up to the package A to detect this and do the right thing. But I agree this is a nasty corner case which would need to be made explicit one way or another. RIch. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From pasik at iki.fi Mon Jun 1 13:03:11 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Mon, 1 Jun 2009 16:03:11 +0300 Subject: F11: kernel/boot hangs at creating initial device nodes with 2.6.30-rc6 In-Reply-To: <20090601051548.GW24960@edu.joroinen.fi> References: <20090601051548.GW24960@edu.joroinen.fi> Message-ID: <20090601130311.GA24960@edu.joroinen.fi> On Mon, Jun 01, 2009 at 08:15:48AM +0300, Pasi K?rkk?inen wrote: > Hello. > > Yesterday I installed latest F11/rawhide. The default installed kernel > (2.6.29 something) works fine. > > I compiled custom 2.6.30-rc6 kernel, and created initrd for it, and tried > booting it. > > Booting process gets stuck at "creating initial device nodes". > > Any ideas? I assume that's during initrd execution.. > Something missing from my kernel config? > > Any tips would be appreciated. Wondering if it's this bug: "kernel hangs while booting, after Creating initial device nodes": https://bugzilla.redhat.com/show_bug.cgi?id=487642 Or this one: "Boot hangs at Creating initial device nodes": https://bugzilla.redhat.com/show_bug.cgi?id=499057 -- Pasi From stickster at gmail.com Mon Jun 1 13:20:55 2009 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 1 Jun 2009 09:20:55 -0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <4A2276F5.7040904@fedoraproject.org> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> <4A2269C7.1010800@fedoraproject.org> <1243770864.26053.8.camel@localhost.localdomain> <4A227206.9010601@fedoraproject.org> <1243772287.26053.15.camel@localhost.localdomain> <4A2276F5.7040904@fedoraproject.org> Message-ID: <20090601132055.GL9001@localhost.localdomain> On Sun, May 31, 2009 at 05:54:21PM +0530, Rahul Sundaram wrote: > On 05/31/2009 05:48 PM, Alexey Torkhov wrote: > > On Sun, 2009-05-31 at 17:33 +0530, Rahul Sundaram wrote: > >> On 05/31/2009 05:24 PM, Alexey Torkhov wrote: > >>> On Sun, 2009-05-31 at 16:58 +0530, Rahul Sundaram wrote: > >> > >>> > >>> Usage of trademark was granted to Russian Fedora by agreement between > >>> Red Hat and other company that represent it here, AFAIK. > >>> Max Spevack was on presentation on Russian Fedora launch. > >> > >> I don't see it recorded in > >> > >> https://fedoraproject.org/wiki/Trademark_licensees > >> > >> It doesn't fit the trademark guidelines either. While Red Hat can > >> legally grant a license to anyone and doesn't have to abide by the > >> guidelines, I would expect it to do so nevertheless. So why a special > >> exception for "Russian Fedora"? > > > > I don't know the details of an agreement, ask legal team for that. > > I don't need to know the details of the agreement. If any such agreement > exists, it should follow the trademark guidelines that Fedora set for > rest of the community and not be given special exceptions. Can the > Fedora Board look into this? I'm already doing so with Max Spevack. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From rjones at redhat.com Mon Jun 1 13:23:26 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 1 Jun 2009 14:23:26 +0100 Subject: Fedora bittorrent tracker? In-Reply-To: <20090601090054.GB32470@alpha.rzhou.org> References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> Message-ID: <20090601132326.GB3522@amd.home.annexia.org> On Mon, Jun 01, 2009 at 05:00:54AM -0400, Ricky Zhou wrote: > On 2009-06-01 09:53:47 AM, Richard W.M. Jones wrote: > > Do we offer a bittorrent tracker that FAS / fp.org users can use to > > host their own bittorrent content? > > > > (Obviously it'll be Fedora/free software-related content) > You can always make a request to Infrastructure at > https://fedorahosted.org/fedora-infrastructure/. We've hosted some > Fedora-related things there before. No idea if we have any sort of > policy on what goes there though. It'll probably depend on how much > space we have and how long it needs to be there for, etc. Thanks - I also found this page: http://fedoraproject.org/wiki/Torrent_Releases_Infrastructure_SOP Not really the sort of open tracker I was looking for ... Opening the question a bit, does anyone know a good tracker hosting service for use by free software projects? http://legaltorrents.com/ seems mostly oriented towards media content (& is in a permanent state of beta). More 'mainstream' services like TPB might support it, but then my users would have to navigate through pictures of nekkid ladies, other content they might find objectionable, and may be blocked from those sites anyway. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From stickster at gmail.com Mon Jun 1 13:28:59 2009 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 1 Jun 2009 09:28:59 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: References: <1243630631.3037.149.camel@localhost.localdomain> Message-ID: <20090601132859.GM9001@localhost.localdomain> On Fri, May 29, 2009 at 05:48:44PM -0500, inode0 wrote: > On Fri, May 29, 2009 at 3:57 PM, Jesse Keating wrote: > > We're announcing a Fedora Activity day coming up very very soon > > (apologies for the short notice). ?This activity day is for maintainers, > > QA, and release engineering folks to meet and discuss ongoing issues > > with the Fedora Development Cycle and to create a proposal on how to fix > > many of the issues. ?Note, this is not an event to decide on a solution, > > it is an event to decide on a proposal, which will then be shared with > > the whole community for more input and work. > > > > ... snip ... > > Jesse, > > I just want to wish you guys a great and productive FAD. > > I hope it inspires other community members to look for opportunities > within the parts of the project they work on to organize their own > FADs in the future. > > If a group of folks in Docs or Art or Infra or whatever could get > something important done faster/better by getting together in the same > place please do it. If you think you have a good idea but are > uncertain how to make it happen feel free to ping your friendly > neighborhood ambassador and we'd be happy to help you get the ball > rolling. For instance, the Docs team is holding a FAD at the SELF conference in Clemson, SC in a couple weeks: https://fedoraproject.org/wiki/FAD_SELF_2009 -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From kevin.kofler at chello.at Mon Jun 1 13:49:36 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 01 Jun 2009 15:49:36 +0200 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> <4A23972E.2060805@robertoragusa.it> <2d319b780906010238t77ebe521q133b6fea3503981e@mail.gmail.com> Message-ID: Mathieu Bridon (bochecha) wrote: > Actually, there are two: > - package-cleanup that I mentioned > - yum-plugin-remove-with-leaves that Seth mentioned which is even easier But both are completely broken by design because they don't understand the difference between something being dragged in as a dependency or being explicitly installed. Applications can require other applications, remove-with-leaves will happily remove those even if you actually want them! package-cleanup --leaves even finds almost all applications, so it's entirely useless. Kevin Kofler From kevin.kofler at chello.at Mon Jun 1 13:53:05 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 01 Jun 2009 15:53:05 +0200 Subject: Agenda for the 2009-05-26 Packaging Committee meeting References: <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> <20090601121319.GA3522@amd.home.annexia.org> Message-ID: Richard W.M. Jones wrote: > As far as I can tell, in Debian a versioned suggestion is still just a > suggestion. If B = 1.0 were installed, it would be up to the package > A to detect this and do the right thing. But I agree this is a nasty > corner case which would need to be made explicit one way or another. IMHO, it's pretty clear what should happen: if suggestions are being honored, the package should be upgraded, if they aren't, it shouldn't. I don't see why this should be handled any differently than installing dependencies which are entirely not there. If A actually BREAKS when B = 1.0 is there, it needs a Conflicts: B < 1.2 in addition to the Suggests: B >= 1.2 (and with that Conflicts, yum will upgrade B together with A even without the soft dependency). Kevin Kofler From skvidal at fedoraproject.org Mon Jun 1 13:59:40 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 1 Jun 2009 09:59:40 -0400 (EDT) Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> <4A23972E.2060805@robertoragusa.it> <2d319b780906010238t77ebe521q133b6fea3503981e@mail.gmail.com> Message-ID: On Mon, 1 Jun 2009, Kevin Kofler wrote: > Mathieu Bridon (bochecha) wrote: >> Actually, there are two: >> - package-cleanup that I mentioned >> - yum-plugin-remove-with-leaves that Seth mentioned which is even easier > > But both are completely broken by design because they don't understand the > difference between something being dragged in as a dependency or being > explicitly installed. Applications can require other applications, > remove-with-leaves will happily remove those even if you actually want > them! package-cleanup --leaves even finds almost all applications, so it's > entirely useless. if you run: yum install foo-app and it drags in: bar-app and foo-lib Then you've not explicitly chosen to install bar-app. With the availability of the yumdb information we should be able to make remove-with-leaves know more about the intent. -sv From Juha.Tuomala at iki.fi Mon Jun 1 14:17:06 2009 From: Juha.Tuomala at iki.fi (Juha Tuomala) Date: Mon, 1 Jun 2009 17:17:06 +0300 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: References: Message-ID: <200906011717.06491.Juha.Tuomala@iki.fi> On Monday 01 June 2009 16:59:40 Seth Vidal wrote: > if you run: > yum install foo-app > and it drags in: > bar-app > and > foo-lib > > Then you've not explicitly chosen to install bar-app. > > With the availability of the yumdb information we should be able to make > remove-with-leaves know more about the intent. Why not store a for every pkg how it got installed, as a direct human request or as a dependency? I maintain such list manually and when reinstall my machine, use that as an argument list to the yum to get the needed apps back into system. It's never perfect but close enough to be useful. Another way to housekeep a system could be the stat's output and Access time, but i guess some prelinker or something else kills that brilliant idea. Tuju -- Better to have one, and not need it, than to need one and not have it. From skvidal at fedoraproject.org Mon Jun 1 14:41:32 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 1 Jun 2009 10:41:32 -0400 (EDT) Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <200906011717.06491.Juha.Tuomala@iki.fi> References: <200906011717.06491.Juha.Tuomala@iki.fi> Message-ID: On Mon, 1 Jun 2009, Juha Tuomala wrote: > > > > On Monday 01 June 2009 16:59:40 Seth Vidal wrote: >> if you run: >> yum install foo-app >> and it drags in: >> bar-app >> and >> foo-lib >> >> Then you've not explicitly chosen to install bar-app. >> >> With the availability of the yumdb information we should be able to make >> remove-with-leaves know more about the intent. > > Why not store a for every pkg how it got installed, as > a direct human request or as a dependency? Until recently we had no place to store that information. That's why. -sv From alsadi at gmail.com Mon Jun 1 14:52:27 2009 From: alsadi at gmail.com (Muayyad AlSadi) Date: Mon, 1 Jun 2009 17:52:27 +0300 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> <4A23972E.2060805@robertoragusa.it> <2d319b780906010238t77ebe521q133b6fea3503981e@mail.gmail.com> Message-ID: <385866f0906010752m23f8608dta48b0fb353f1570d@mail.gmail.com> the only usage for soft dependency in my opinion is to offer the user with choices in front ends like yumex and PK in other words they should be considered as does not depend when removing packages or doing a cleanup > yum-remove-with-leaves will happily remove those even if you actually want them! I filed a bug report about it, and devels added an option to make it works with libraries only I asked them to make it default, they refused but that's not a bug deal https://bugzilla.redhat.com/show_bug.cgi?id=481465 I liked the concept of flagging the packages as required by humans and installed for dependencies maintaining such database of why each package was added to the system after install will allow yum to make better cleanup decisions my suggestion 0. this database should be maintained by yum after installation 1. the database contains all the packages dragged for dependency 2. all libraries are dragged for dependency packages 3. installation does not touch that database (except libraries) 4. I'm very boring and talk is cheap :-) From kevin.kofler at chello.at Mon Jun 1 14:59:23 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 01 Jun 2009 16:59:23 +0200 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> <4A23972E.2060805@robertoragusa.it> <2d319b780906010238t77ebe521q133b6fea3503981e@mail.gmail.com> <385866f0906010752m23f8608dta48b0fb353f1570d@mail.gmail.com> Message-ID: Muayyad AlSadi wrote: > I filed a bug report about it, and devels added an option to make it > works with libraries only And how do you define "library"? There's no reliable way to distinguish them from applications. Kevin Kofler From skvidal at fedoraproject.org Mon Jun 1 15:07:31 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 1 Jun 2009 11:07:31 -0400 (EDT) Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> <4A23972E.2060805@robertoragusa.it> <2d319b780906010238t77ebe521q133b6fea3503981e@mail.gmail.com> <385866f0906010752m23f8608dta48b0fb353f1570d@mail.gmail.com> Message-ID: On Mon, 1 Jun 2009, Kevin Kofler wrote: > Muayyad AlSadi wrote: >> I filed a bug report about it, and devels added an option to make it >> works with libraries only > > And how do you define "library"? There's no reliable way to distinguish them > from applications. This is part of the problem. It would be nice to have all things which are strictly libraries add a "provides: Library something" and, of course, to have all libs split from all apps. -sv From skvidal at fedoraproject.org Mon Jun 1 15:53:12 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 1 Jun 2009 11:53:12 -0400 (EDT) Subject: Fedora bittorrent tracker? In-Reply-To: <20090601132326.GB3522@amd.home.annexia.org> References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> Message-ID: On Mon, 1 Jun 2009, Richard W.M. Jones wrote: >>> (Obviously it'll be Fedora/free software-related content) >> You can always make a request to Infrastructure at >> https://fedorahosted.org/fedora-infrastructure/. We've hosted some >> Fedora-related things there before. No idea if we have any sort of >> policy on what goes there though. It'll probably depend on how much >> space we have and how long it needs to be there for, etc. > > Thanks - I also found this page: > http://fedoraproject.org/wiki/Torrent_Releases_Infrastructure_SOP > Not really the sort of open tracker I was looking for ... > > Opening the question a bit, does anyone know a good tracker hosting > service for use by free software projects? http://legaltorrents.com/ > seems mostly oriented towards media content (& is in a permanent state > of beta). More 'mainstream' services like TPB might support it, but > then my users would have to navigate through pictures of nekkid > ladies, other content they might find objectionable, and may be > blocked from those sites anyway. What sort of content are we talking about and how often are you talking about adding/changing it? Thanks, -sv From valent.turkovic at gmail.com Mon Jun 1 15:56:11 2009 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 1 Jun 2009 17:56:11 +0200 Subject: Packaging Survey - May 2009 In-Reply-To: <4A1D24AC.4090802@fedoraproject.org> References: <4A1D24AC.4090802@fedoraproject.org> Message-ID: <64b14b300906010856kf3015f9xe724cc71476ac6a1@mail.gmail.com> On Wed, May 27, 2009 at 1:31 PM, Rahul Sundaram wrote: > Hi > > I did a quick survey from Fedora on what software Fedora users are using > that is not available in the repo. Here are the results. If you find > anything interesting, feel free to pick it up. > > https://fedoraproject.org/wiki/Packaging_Survey_May_2009 > > Rahul Here is my wishlist of packages I would LOVE to see in Fedora: - Songbird - XBMC (best media center for Linux) - Navit (GPS navigation) - Freemind (Mind mapping java app) - Boxee (XBMC + social aspect) - BackupNinja regarding XBMC: http://howtoforge.com/installing-xbmc-on-fedora-9-i386 regarding Songbird, Fedora RPM is here: http://wiki.songbirdnest.com/Developer/Articles/Builds/Contributed_Builds -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From rjones at redhat.com Mon Jun 1 16:02:29 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 1 Jun 2009 17:02:29 +0100 Subject: Fedora bittorrent tracker? In-Reply-To: References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> Message-ID: <20090601160229.GA19669@amd.home.annexia.org> On Mon, Jun 01, 2009 at 11:53:12AM -0400, Seth Vidal wrote: > On Mon, 1 Jun 2009, Richard W.M. Jones wrote: >>>> (Obviously it'll be Fedora/free software-related content) >>> You can always make a request to Infrastructure at >>> https://fedorahosted.org/fedora-infrastructure/. We've hosted some >>> Fedora-related things there before. No idea if we have any sort of >>> policy on what goes there though. It'll probably depend on how much >>> space we have and how long it needs to be there for, etc. >> >> Thanks - I also found this page: >> http://fedoraproject.org/wiki/Torrent_Releases_Infrastructure_SOP >> Not really the sort of open tracker I was looking for ... >> >> Opening the question a bit, does anyone know a good tracker hosting >> service for use by free software projects? http://legaltorrents.com/ >> seems mostly oriented towards media content (& is in a permanent state >> of beta). More 'mainstream' services like TPB might support it, but >> then my users would have to navigate through pictures of nekkid >> ladies, other content they might find objectionable, and may be >> blocked from those sites anyway. > > What sort of content are we talking about and how often are you talking > about adding/changing it? Large data sets derived from analysing the code in Fedora packages... I was hoping to save the announcement til later. For the purposes of this, big data files, derived from Fedora content so under a free license of some sort, probably up to 30GB in size. They would be regenerated once a month. RIch. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html From frankly3d at gmail.com Mon Jun 1 16:08:48 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Mon, 01 Jun 2009 17:08:48 +0100 Subject: Fedora bittorrent tracker? In-Reply-To: <20090601132326.GB3522@amd.home.annexia.org> References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> Message-ID: <4A23FD10.3060503@gmail.com> Richard W.M. Jones wrote: > Not really the sort of open tracker I was looking for ... > > Opening the question a bit, does anyone know a good tracker hosting > service for use by free software projects? h http://linuxtracker.org/ http://www.tuxdistro.com/ Not sure if that's what your after. Frank From skvidal at fedoraproject.org Mon Jun 1 16:07:45 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 1 Jun 2009 12:07:45 -0400 (EDT) Subject: Fedora bittorrent tracker? In-Reply-To: <20090601160229.GA19669@amd.home.annexia.org> References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> Message-ID: On Mon, 1 Jun 2009, Richard W.M. Jones wrote: > > Large data sets derived from analysing the code in Fedora packages... > I was hoping to save the announcement til later. > > For the purposes of this, big data files, derived from Fedora content > so under a free license of some sort, probably up to 30GB in size. > They would be regenerated once a month. 30GB once a month shouldn't be too much trouble, the biggest problems will be: 1. transferring the data in a timely-ish manner 2. keeping lots of those datasets around. Hopefully no more than 2 b/c 60GB is a big chunk of space -sv From rjones at redhat.com Mon Jun 1 16:29:05 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 1 Jun 2009 17:29:05 +0100 Subject: Fedora bittorrent tracker? In-Reply-To: References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> Message-ID: <20090601162905.GA19818@amd.home.annexia.org> On Mon, Jun 01, 2009 at 12:07:45PM -0400, Seth Vidal wrote: > > > On Mon, 1 Jun 2009, Richard W.M. Jones wrote: > >> >> Large data sets derived from analysing the code in Fedora packages... >> I was hoping to save the announcement til later. >> >> For the purposes of this, big data files, derived from Fedora content >> so under a free license of some sort, probably up to 30GB in size. >> They would be regenerated once a month. > > 30GB once a month shouldn't be too much trouble, the biggest problems > will be: > > 1. transferring the data in a timely-ish manner > 2. keeping lots of those datasets around. Hopefully no more than 2 b/c > 60GB is a big chunk of space The biggest problem is gonna be uploading it over my *$!* ADSL connection. I wasn't looking for hosting, just for somewhere to store the tracker. It's my understanding (possibly incorrect) that the initial seed and the tracker are separate things which don't need to be kept at the same location. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From rawhide at fedoraproject.org Mon Jun 1 16:29:35 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 1 Jun 2009 16:29:35 +0000 (UTC) Subject: rawhide report: 20090601 changes Message-ID: <20090601162935.34C401B8003@releng2.fedora.phx.redhat.com> Compose started at Mon Jun 1 06:15:04 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From mike at cchtml.com Mon Jun 1 16:31:05 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Mon, 01 Jun 2009 11:31:05 -0500 Subject: Fedora bittorrent tracker? In-Reply-To: <20090601162905.GA19818@amd.home.annexia.org> References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> <20090601162905.GA19818@amd.home.annexia.org> Message-ID: <4A240249.5070202@cchtml.com> Richard W.M. Jones wrote: > > I wasn't looking for hosting, just for somewhere to store the tracker. > It's my understanding (possibly incorrect) that the initial seed and > the tracker are separate things which don't need to be kept at the > same location. > You are correct. A tracker just funnels (initial) bittorrent traffic. A seeder funnels raw data. From skvidal at fedoraproject.org Mon Jun 1 16:30:44 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 1 Jun 2009 12:30:44 -0400 (EDT) Subject: Fedora bittorrent tracker? In-Reply-To: <20090601162905.GA19818@amd.home.annexia.org> References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> <20090601162905.GA19818@amd.home.annexia.org> Message-ID: On Mon, 1 Jun 2009, Richard W.M. Jones wrote: > On Mon, Jun 01, 2009 at 12:07:45PM -0400, Seth Vidal wrote: >> >> > > The biggest problem is gonna be uploading it over my *$!* ADSL > connection. > > I wasn't looking for hosting, just for somewhere to store the tracker. > It's my understanding (possibly incorrect) that the initial seed and > the tracker are separate things which don't need to be kept at the > same location. > They don't and if you want us to serve as the tracker but NOT as primary seed then I think that can be worked out, too. Essentially you'd make a .torrent file with our tracker info in it - send us the .torrent file. We'll drop it in the holding path for the tracker and, ultimately, for our seed. so we'd start downloading it, too. or, alternatively, I could see about setting up a tracker-only non-seed path for our current tracker so that we could just track but not seed. Provided your seed would be doing all the bit-pushing work :) -sv From hpa at zytor.com Mon Jun 1 16:38:23 2009 From: hpa at zytor.com (H. Peter Anvin) Date: Mon, 01 Jun 2009 09:38:23 -0700 Subject: [Sugar-devel] Unbootable machine In-Reply-To: References: <4A236808.1050106@codewiz.org> Message-ID: <4A2403FF.2020304@zytor.com> Caroline Meeks wrote: > Luke and Sasha are working on a new USB format that they feel will allow > more machines to boot and support VM + Stick > > http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/USB_format > > Perhaps the issue you are running into (which we have definitely seen > before) is related to some of the ones they are looking at and part of > why they need two boot partitions that are slightly different. > I don't understand why 128 heads. 64 heads is the more compatible version. I presume the notion of partition 1 and 4 is to deal with things that have an odd notion of zipdisks. I have personally not seen any devices which will only boot with partition 1 or only with partition 4, if you have any such information I would appreciate it. Part of me also wonders if using EXTLINUX might not be easier for you, too. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. From frankly3d at gmail.com Mon Jun 1 16:43:44 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Mon, 01 Jun 2009 17:43:44 +0100 Subject: Is The Devel Sig alive or Dead? In-Reply-To: <4A227AC9.3040903@fedoraproject.org> References: <4A227431.6040308@gmail.com> <4A22758F.2070704@fedoraproject.org> <4A22799F.4040306@gmail.com> <4A227AC9.3040903@fedoraproject.org> Message-ID: <4A240540.3040000@gmail.com> Rahul Sundaram wrote: > On 05/31/2009 06:05 PM, Frank Murphy (Frankly3d) wrote: >> Rahul Sundaram wrote: >>> On 05/31/2009 05:42 PM, Frank Murphy (Frankly3d) wrote: >>>> Lat meeting log seems to be: >>>> http://fedoraproject.org/wiki/SIGs/Development#Communication >>> It's not active anymore. The Fedora Development custom spin has also >>> been dropped. >>> >> >> Guessing lack of Interest? >> >> So what would be the best >> Install Desktop + what devel. Packages required. > > Yes and yes. > > Rahul > I may try with a bit of time to get this re-activated. As development is what interests me (along with 3D art). Would anyone mine if I added my name to the wiki page? Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From drago01 at gmail.com Mon Jun 1 17:07:15 2009 From: drago01 at gmail.com (drago01) Date: Mon, 1 Jun 2009 19:07:15 +0200 Subject: Orphaning some packages (gdhcpd, wxdfast, beagle) In-Reply-To: References: Message-ID: On Wed, May 27, 2009 at 4:59 PM, drago01 wrote: > Hi, > > I am looking for new maintainers for those packages: > > gdhcpd: > I do not really use it, upstream has released a new version a while > ago but the fedora package still is at the old version. > Bugs: https://admin.fedoraproject.org/pkgdb/packages/bugs/gdhcpd > > wxdfast: > Upstream is pretty much dead (no activity for years). > Bugs: https://admin.fedoraproject.org/pkgdb/packages/bugs/wxdfast > > beagle: > Package needs a lot of work and I don't really have time for it > (upstream is also quite busy so there is little activity there too). > Bugs: https://admin.fedoraproject.org/pkgdb/packages/bugs/beagle > > If someone wants to take (one of) them please reply to this mail. > OK, went ahead and orphaned them in pkgdb. From rjones at redhat.com Mon Jun 1 17:10:40 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 1 Jun 2009 18:10:40 +0100 Subject: Fedora bittorrent tracker? In-Reply-To: References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> <20090601162905.GA19818@amd.home.annexia.org> Message-ID: <20090601171040.GA20077@amd.home.annexia.org> On Mon, Jun 01, 2009 at 12:30:44PM -0400, Seth Vidal wrote: > On Mon, 1 Jun 2009, Richard W.M. Jones wrote: >> On Mon, Jun 01, 2009 at 12:07:45PM -0400, Seth Vidal wrote: >>> >>> >> >> The biggest problem is gonna be uploading it over my *$!* ADSL >> connection. >> >> I wasn't looking for hosting, just for somewhere to store the tracker. >> It's my understanding (possibly incorrect) that the initial seed and >> the tracker are separate things which don't need to be kept at the >> same location. >> > > They don't and if you want us to serve as the tracker but NOT as primary > seed then I think that can be worked out, too. > > Essentially you'd make a .torrent file with our tracker info in it - send > us the .torrent file. We'll drop it in the holding path for the tracker > and, ultimately, for our seed. > > so we'd start downloading it, too. > > or, alternatively, I could see about setting up a tracker-only non-seed > path for our current tracker so that we could just track but not seed. > > Provided your seed would be doing all the bit-pushing work :) Yes. Thanks. I'm going to do a bit more research on making a torrent file. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From notting at redhat.com Mon Jun 1 17:21:36 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 1 Jun 2009 13:21:36 -0400 Subject: Packaging Survey - May 2009 In-Reply-To: <64b14b300906010856kf3015f9xe724cc71476ac6a1@mail.gmail.com> References: <4A1D24AC.4090802@fedoraproject.org> <64b14b300906010856kf3015f9xe724cc71476ac6a1@mail.gmail.com> Message-ID: <20090601172136.GB24209@nostromo.devel.redhat.com> Valent Turkovic (valent.turkovic at gmail.com) said: > On Wed, May 27, 2009 at 1:31 PM, Rahul Sundaram > wrote: > > Hi > > > > I did a quick survey from Fedora on what software Fedora users are using > > that is not available in the repo. Here are the results. If you find > > anything interesting, feel free to pick it up. > > > > https://fedoraproject.org/wiki/Packaging_Survey_May_2009 > > > > Rahul > > Here is my wishlist of packages I would LOVE to see in Fedora: > ... > - XBMC (best media center for Linux) ... > - Boxee (XBMC + social aspect) > > regarding XBMC: http://howtoforge.com/installing-xbmc-on-fedora-9-i386 Given that, it's not going to be possible to include them in Fedora, due to the code they require to build against. Bill From notting at redhat.com Mon Jun 1 17:25:43 2009 From: notting at redhat.com (Bill Nottingham) Date: Mon, 1 Jun 2009 13:25:43 -0400 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> <4A23972E.2060805@robertoragusa.it> <2d319b780906010238t77ebe521q133b6fea3503981e@mail.gmail.com> <385866f0906010752m23f8608dta48b0fb353f1570d@mail.gmail.com> Message-ID: <20090601172543.GC24209@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > Muayyad AlSadi wrote: > > I filed a bug report about it, and devels added an option to make it > > works with libraries only > > And how do you define "library"? There's no reliable way to distinguish them > from applications. If a package installs a shared object with a SONAME in %{_libdir}, it is a reasonable assumption that it contains libraries. Bill From frankly3d at gmail.com Mon Jun 1 17:32:24 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Mon, 01 Jun 2009 18:32:24 +0100 Subject: Fedora bittorrent tracker? In-Reply-To: <20090601171040.GA20077@amd.home.annexia.org> References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> <20090601162905.GA19818@amd.home.annexia.org> <20090601171040.GA20077@amd.home.annexia.org> Message-ID: <4A2410A8.80409@gmail.com> Richard W.M. Jones wrote: > > > Thanks. I'm going to do a bit more research on making a torrent file. > > Rich. > http://www.createtorrent.com/ Frank From fedora at matbooth.co.uk Mon Jun 1 17:32:44 2009 From: fedora at matbooth.co.uk (Mat Booth) Date: Mon, 1 Jun 2009 18:32:44 +0100 Subject: Orphaned eclipse-pydev In-Reply-To: <1709738315.3694111243851890236.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <927812054.3694091243851856775.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <1709738315.3694111243851890236.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <9497e9990906011032g6b88ec86h51939e00dd9b4453@mail.gmail.com> On Mon, Jun 1, 2009 at 11:24 AM, Michal Nowak wrote: > Orphaned eclipse-pydev, feel free to take it. > > Michal > Looks like Alexander took ownership of the devel branch. -- Mat Booth www.matbooth.co.uk From silfreed at silfreed.net Mon Jun 1 17:33:33 2009 From: silfreed at silfreed.net (Douglas E. Warner) Date: Mon, 01 Jun 2009 13:33:33 -0400 Subject: Looking for help maintaining qgis Message-ID: <4A2410ED.4090908@silfreed.net> I'm looking for co-maintainers for qgis to help with testing and pushing out releases. If you're interested please shoot me an email off-list. It's currently a point release behind in all branches (need to package 1.0.2) and I'm not sure what best to do with the new branch they released (1.1.0). -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From fedora at leemhuis.info Mon Jun 1 17:49:44 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 01 Jun 2009 19:49:44 +0200 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1243630631.3037.149.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> Message-ID: <4A2414B8.2000907@leemhuis.info> On 29.05.2009 22:57, Jesse Keating wrote: > > Please feel free to use the discussion page on the wiki to express your > thoughts about the event and what problems you're having with the > development cycle. Even thoughts on the initial proposal I drew up at > the bottom of the wiki page would be welcome, although I do believe that > this event will result in a proposal different from what is currently > listed. Find a few random thoughts/suggestions I added to the wiki below. I send them here as well, because the page in the wiki feels to me like a place in a corner where nearly nobody looks -- thus it's unlikely that a real discussion evolves. - should we set an way earlier freezes date for things like anaconda, kernel, isolinux, grub and other crucial pieces to make sure they are in better shape a bit earlier and thus are less likely a reason for release slips? - do we need better communication/more detailed release schedule? I've seen you writing this in #fedora-kernel recently: > 18:52:18 < f13> | so here's the deal > 18:52:25 < f13> | I need a kernel today, that fixes those bugs on the blocker list > 18:52:34 < f13> | or we decide that those bugs are not worth fixing > 18:52:40 < f13> | or we slip the release, again. > 18:52:53 < f13> | and by "today" I mean building in the next hour or so >From the discussion after that it looked a whole lot like as if some important kernel developers where *not* aware that the kernel for the release was needed on that day, which I find quite alarming... (even if you got a proper kernel after you wrote the text quoted above) - how about reducing the number or zero day updates (which is ridiculous high for F11) by setting a different, later freeze date for all packages that are neither on the install DVD or on a Spin? - other distributions seems to manage a whole lot more test releases (e.g. alphas, beta, RC, milestones, ...) per devel cycle; is that something we should aim for as well? - at least it sometimes feels like "rawhide installation using boot.iso feels like broken for weeks or months". That annoying and confusing even for people like me. How about targetting "rawhide must be install-able using boot.iso every Friday; crazy new stuff (like a new python release) must get imported on Mondays with the goal to have things in a good shape by Friday" - how about doing something like a "cp -l development devel-snapshot" now and then (once a week) when we know rawhide is mostly working? - how can we reduce our time between finishing a (test) release and releasing it dramatically? It seems other distributions get new (test) release out to the users a lot quicker then the three to five days days we require, which seems a whole lot for a devel cycle that takes 180 days in total (and we all know how much rawhide can move on with a few days) - the anaconda storage rewrite was a bit bumpy and created lot of trouble this devel cycle; what will get taken to make things like that more smooth in the future? - I'd be glad if we could stick to our release targets a lot better. Delaying releases looks quite unprofessional. Delaying also creates trouble for those depending on our releases. Take computer magazines (which have hard deadlines for productions) that might want to ship with a new release on a CD or DVD together with the next issue -- due to our fame in missing deadlines it seems to me that we are a lot more unattractive than Ubuntu (which afaics is on the shelf's here in Germany with new computer magazines just a few days after it has been released) - why do we have to slip by a whole week most of the time? can't we find ways to slip just a day or two if there really is no way around a delay? - I like the idea to "keep rawhide (nearly) always moving" a lot - until a year or a bit more ago we had three test releases, now we have alpha, beta and preview -- were the changes done together with the renaming worth it (btw, for me it feels a lot like "not much changed" apart from the names). - I'd be glad if the final release directories (e.g. release/12/Everything" could be available earlier, even if what is in them is not yet what "12" actually will become CU knurd From mw_triad at users.sourceforge.net Mon Jun 1 18:10:10 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Mon, 01 Jun 2009 13:10:10 -0500 Subject: Unbootable machine In-Reply-To: <20090601175709.GB5224@twin.sascha.silbe.org> References: <4A236808.1050106@codewiz.org> <4A2403FF.2020304@zytor.com> <20090601175709.GB5224@twin.sascha.silbe.org> Message-ID: Sascha Silbe wrote: > BTW: How does Windows handle USB sticks with "unknown" > formatting? I'd guess it offers to format them for you. (I want to say I have seen this recently, which means it was probably some time I was using my ext2-formatted usb stick.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- 73% of all statistics are made up on the spot. From awilliam at redhat.com Mon Jun 1 18:14:52 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 01 Jun 2009 11:14:52 -0700 Subject: Plans for tomorrow's (20090529) FESCo meeting In-Reply-To: <20090530184713.GA4369@auslistsprd01.us.dell.com> References: <200905291033.20518.opensource@till.name> <20090529113607.GD3095@hansolo.jdub.homelinux.org> <20090529144920.GA31662@thinkpad.fab.redhat.com> <1243615672.2937.197.camel@adam.local.net> <4A201496.2070205@gmail.com> <1243618345.2937.210.camel@adam.local.net> <20090530184713.GA4369@auslistsprd01.us.dell.com> Message-ID: <1243880092.2937.268.camel@adam.local.net> On Sat, 2009-05-30 at 13:47 -0500, Matt Domsch wrote: > > Mandriva took DKMS and hacked it up so that it creates both pre-built > > binaries and 'source' packages (much like kmods and akmods in the kmod > > system), so that if you have a system without the build chain things > > will work as long as you're running a supported kernel and the updates > > are in sync, but if you have the whole build chain, the 'source' DKMS > > package covers you if you're running a different kernel or whatever. RPM > > Fusion does much the same by providing both kmods and akmods. > > I do wish MDV would send such patches upstream... I always had to go > hunting for patches. If they've not been, I'm not sure why; MDV usually likes upstreaming stuff because they're extremely under-resourced when it comes to developers, so everyone wants their life to be easier :). It may just be that they felt the patches were sufficiently extensive/hacky that Dell may not want them. Anyhoo, you can find this stuff in MDV SVN: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/dkms/current/ A good guy to talk to about MDV's changes to DKMS would be Olivier Blin, oblin at mandriva.com . I think he'd know most things you'd want to ask. Sending off list as we appear to be somewhat off topic :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jkeating at redhat.com Mon Jun 1 18:14:26 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 01 Jun 2009 11:14:26 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <4A2414B8.2000907@leemhuis.info> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> Message-ID: <1243880066.29188.20.camel@localhost.localdomain> On Mon, 2009-06-01 at 19:49 +0200, Thorsten Leemhuis wrote: > On 29.05.2009 22:57, Jesse Keating wrote: > > > > Please feel free to use the discussion page on the wiki to express your > > thoughts about the event and what problems you're having with the > > development cycle. Even thoughts on the initial proposal I drew up at > > the bottom of the wiki page would be welcome, although I do believe that > > this event will result in a proposal different from what is currently > > listed. > > Find a few random thoughts/suggestions I added to the wiki below. I send > them here as well, because the page in the wiki feels to me like a place > in a corner where nearly nobody looks -- thus it's unlikely that a real > discussion evolves. > > - should we set an way earlier freezes date for things like anaconda, > kernel, isolinux, grub and other crucial pieces to make sure they are in > better shape a bit earlier and thus are less likely a reason for release > slips? I've asked some of these groups to do that, but it's like asking any other upstream. A lot of the problem stems from things like anaconda using more and more of other bits in the distro, which change significantly right at the freeze date, breaking anaconda. So while we're waiting for anaconda, it's really because something else changed late. I tried to mitigate this by setting the feature freeze back a week from the beta freeze, so that the nasty changes land a week before we freeze for beta, giving folks like anaconda time to survive. It almost worked, and maybe we need to extend that back even farther. > - do we need better communication/more detailed release schedule? I've > seen you writing this in #fedora-kernel recently: > > > 18:52:18 < f13> | so here's the deal > > 18:52:25 < f13> | I need a kernel today, that fixes those bugs on the blocker list > > 18:52:34 < f13> | or we decide that those bugs are not worth fixing > > 18:52:40 < f13> | or we slip the release, again. > > 18:52:53 < f13> | and by "today" I mean building in the next hour or so > > >From the discussion after that it looked a whole lot like as if some > important kernel developers where *not* aware that the kernel for the > release was needed on that day, which I find quite alarming... (even if > you got a proper kernel after you wrote the text quoted above) That's a fair point. We don't well document or communicate the "points of no return" as it were. We've also had to discuss how we set those. In the past it was the last point at which we could compose and upload the bits to the master mirror in order to have enough mirrors synced at release day. Now it seems more that we have to make that decision within enough time to spin up (or down) the marketing machine, which looks to require more leadtime than the mirrors do. > - how about reducing the number or zero day updates (which is ridiculous > high for F11) by setting a different, later freeze date for all packages > that are neither on the install DVD or on a Spin? That's a bit hard to determine easily and programaticaly. I've all but given up on my quest to reduce the number of updates. It's just doesn't seem to be in line with the desires of the package maintainers, whether or not it's in line with the desires of (some of) the project leaders. > - other distributions seems to manage a whole lot more test releases > (e.g. alphas, beta, RC, milestones, ...) per devel cycle; is that > something we should aim for as well? If there was a way to do it without adding stress and work needed to teams like releng, installer, etc.. that would be possible, also if they were done without freezes. But the overwhelming requests I get are of /less/ of these test releases rather than more. If our release cycle were 9 months or even 12~24 months it would make a lot more sense to have more milestones. But with only a 6 month cycle it gets hard to find time to do development in between all the already existing milestones. > > - at least it sometimes feels like "rawhide installation using boot.iso > feels like broken for weeks or months". That annoying and confusing even > for people like me. How about targetting "rawhide must be install-able > using boot.iso every Friday; crazy new stuff (like a new python release) > must get imported on Mondays with the goal to have things in a good > shape by Friday" That's what we hoped to have with the post-beta snapshots. Hard to say if it's had any real impact, likely due to the short amount of time between beta and the final freeze/preview release. If we attempted to do snapshots leading up to the beta that might make it more noticeable, but then we're back in the realm of more milestones instead of less. > > - how about doing something like a "cp -l development devel-snapshot" > now and then (once a week) when we know rawhide is mostly working? > The rawhide trees for at least the past month are kept in the Fedora infrastructure and are even available by a public url. We haven't tagged any of them as "stable" though. > - how can we reduce our time between finishing a (test) release and > releasing it dramatically? It seems other distributions get new (test) > release out to the users a lot quicker then the three to five days days > we require, which seems a whole lot for a devel cycle that takes 180 > days in total (and we all know how much rawhide can move on with a few days) If we didn't care to let the mirrors sync up we could "release" it earlier. However what good does that do when nobody can /get/ to the release because none of the mirrors have it, and the ones that do can't help sync to those that don't because users are tying up all the bandwidth? > - the anaconda storage rewrite was a bit bumpy and created lot of > trouble this devel cycle; what will get taken to make things like that > more smooth in the future? > Less snapshots for them to worry about, taking time away from the development and bugfixing effort. Automated testing. Better bug management. > - I'd be glad if we could stick to our release targets a lot better. > Delaying releases looks quite unprofessional. Delaying also creates > trouble for those depending on our releases. Take computer magazines > (which have hard deadlines for productions) that might want to ship with > a new release on a CD or DVD together with the next issue -- due to our > fame in missing deadlines it seems to me that we are a lot more > unattractive than Ubuntu (which afaics is on the shelf's here in Germany > with new computer magazines just a few days after it has been released) What looks more unprofessional? Delaying the release, or hitting our date and releasing with bugs that eat people's data? Or releasing with broken graphics for large swaths of users? > - why do we have to slip by a whole week most of the time? can't we find > ways to slip just a day or two if there really is no way around a delay? The marketing machine has very strongly requested that we only do releases on Tuesdays. > - I like the idea to "keep rawhide (nearly) always moving" a lot > > - until a year or a bit more ago we had three test releases, now we have > alpha, beta and preview -- were the changes done together with the > renaming worth it (btw, for me it feels a lot like "not much changed" > apart from the names). At first the plan was just Alpha, Beta, and release. But people really wanted a final snapshot after the final freeze to base their tests on, so Preview came to be. Now we're talking about dropping Alpha because of it's dubious value at that point in the release cycle, which would reduce us back down to 2 major snapshots during the cycle, Beta and Preview. That's what the F12 schedule has right now. > > - I'd be glad if the final release directories (e.g. > release/12/Everything" could be available earlier, even if what is in > them is not yet what "12" actually will become You'll have to enumerate why that is. One reason I've avoided this is added confusion as to when the "release" happens. If we created that directory and put content in there, would we have then released Fedora 12? When does it become "released" and thus trusted? > > CU > knurd -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Mon Jun 1 18:23:43 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 1 Jun 2009 14:23:43 -0400 (EDT) Subject: Fedora bittorrent tracker? In-Reply-To: <20090601171040.GA20077@amd.home.annexia.org> References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> <20090601162905.GA19818@amd.home.annexia.org> <20090601171040.GA20077@amd.home.annexia.org> Message-ID: On Mon, 1 Jun 2009, Richard W.M. Jones wrote: > On Mon, Jun 01, 2009 at 12:30:44PM -0400, Seth Vidal wrote: >> On Mon, 1 Jun 2009, Richard W.M. Jones wrote: >>> On Mon, Jun 01, 2009 at 12:07:45PM -0400, Seth Vidal wrote: >>>> >>>> >>> >>> The biggest problem is gonna be uploading it over my *$!* ADSL >>> connection. >>> >>> I wasn't looking for hosting, just for somewhere to store the tracker. >>> It's my understanding (possibly incorrect) that the initial seed and >>> the tracker are separate things which don't need to be kept at the >>> same location. >>> >> >> They don't and if you want us to serve as the tracker but NOT as primary >> seed then I think that can be worked out, too. >> >> Essentially you'd make a .torrent file with our tracker info in it - send >> us the .torrent file. We'll drop it in the holding path for the tracker >> and, ultimately, for our seed. >> >> so we'd start downloading it, too. >> >> or, alternatively, I could see about setting up a tracker-only non-seed >> path for our current tracker so that we could just track but not seed. >> >> Provided your seed would be doing all the bit-pushing work :) > > Yes. > > Thanks. I'm going to do a bit more research on making a torrent file. > /usr/bin/maketorrent-console \ http://torrent.fedoraproject.org:6969/announce file_or_dir_to_torrent -sv From rjones at redhat.com Mon Jun 1 18:30:10 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 1 Jun 2009 19:30:10 +0100 Subject: Fedora bittorrent tracker? In-Reply-To: References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> <20090601162905.GA19818@amd.home.annexia.org> <20090601171040.GA20077@amd.home.annexia.org> Message-ID: <20090601183010.GA20366@amd.home.annexia.org> On Mon, Jun 01, 2009 at 02:23:43PM -0400, Seth Vidal wrote: > /usr/bin/maketorrent-console \ > http://torrent.fedoraproject.org:6969/announce > file_or_dir_to_torrent This is probably getting way off-topic, but how does it know where the initial seed(s) are? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From skvidal at fedoraproject.org Mon Jun 1 18:36:14 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 1 Jun 2009 14:36:14 -0400 (EDT) Subject: Fedora bittorrent tracker? In-Reply-To: <20090601183010.GA20366@amd.home.annexia.org> References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> <20090601162905.GA19818@amd.home.annexia.org> <20090601171040.GA20077@amd.home.annexia.org> <20090601183010.GA20366@amd.home.annexia.org> Message-ID: On Mon, 1 Jun 2009, Richard W.M. Jones wrote: > On Mon, Jun 01, 2009 at 02:23:43PM -0400, Seth Vidal wrote: >> /usr/bin/maketorrent-console \ >> http://torrent.fedoraproject.org:6969/announce >> file_or_dir_to_torrent > > This is probably getting way off-topic, but how does it know > where the initial seed(s) are? the seeds all have the .torrent file it doesn't care whether they are initial or not - all the seeds talk to the tracker to tell it what they have so it can tell other clients where to talk to. -sv From jspaleta at gmail.com Mon Jun 1 18:39:59 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 1 Jun 2009 10:39:59 -0800 Subject: Fedora bittorrent tracker? In-Reply-To: References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> <20090601162905.GA19818@amd.home.annexia.org> Message-ID: <604aa7910906011139i6d4553b1s9d0dbfc75d8bee5a@mail.gmail.com> On Mon, Jun 1, 2009 at 8:30 AM, Seth Vidal wrote: > or, alternatively, I could see about ?setting up a tracker-only non-seed > path for our current tracker so that we could just track but not seed. > > Provided your seed would be doing all the bit-pushing work :) Hmm if this works out well, this might be a useful service for contributors in a more general sense. Once you have the seedless tracker in place, it will be interesting to see if other people make requests to use it for other secondary content. -jef From matt at domsch.com Mon Jun 1 18:37:59 2009 From: matt at domsch.com (Matt Domsch) Date: Mon, 1 Jun 2009 13:37:59 -0500 Subject: Fedora Elections: Town Hall scheduling Message-ID: <20090601183758.GB24237@domsch.com> (resend fixing some addresses) Now that we have our fine slate of candidates for the Board and FESCo, I'd like to schedule two IRC Town Hall meetings for each of these groups, over the next week. Scheduling around 5 people (the Board candidates) is tricky. Scheduling around all 12 FESCo candidates will probably be impossible to get everyone at the same time. Furthermore, I want to schedule them at roughly opposite times of the day, to give an opportunity for as many Fedora members to join us at an hour they might be awake. With that said, here's my proposal. FESCo Candidate forum Wednesday, June 3, 1400 UTC (10am US Eastern Daylight Time, 7am US Pacific Daylight Time) FESCo Candiate forum Thursday, June 4, 0200 UTC (Wed night, 10pm US Eastern Daylight Time, 7pm US Pacific Daylight Time) Board Candidate forum Thursday, June 4, 1400 UTC (10am US Eastern Daylight Time, 7am US Pacific Daylight Time) Board Candidate forum Thursday, June 4, 0200 UTC (Wed night, 10pm US Eastern Daylight Time, 7pm US Pacific Daylight Time) An alternate slot for a FESCo forum, if needed, could be the latter half of the Friday June 5 regular FESCO meeting timeslot, so starting at 17:30UTC. Candidates, please indicate (to me) your (un)availability for these times. Thanks, Matt CalendarMaster -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From matt at domsch.com Mon Jun 1 18:47:50 2009 From: matt at domsch.com (Matt Domsch) Date: Mon, 1 Jun 2009 13:47:50 -0500 Subject: Fedora Elections: Town Hall scheduling In-Reply-To: <20090601183758.GB24237@domsch.com> References: <20090601183758.GB24237@domsch.com> Message-ID: <20090601184748.GC24237@domsch.com> On Mon, Jun 01, 2009 at 01:37:59PM -0500, Matt Domsch wrote: > (resend fixing some addresses) > > Now that we have our fine slate of candidates for the Board and FESCo, > I'd like to schedule two IRC Town Hall meetings for each of these groups, > over the next week. > > Scheduling around 5 people (the Board candidates) is tricky. Scheduling around > all 12 FESCo candidates will probably be impossible to get everyone at > the same time. Furthermore, I want to schedule them at roughly > opposite times of the day, to give an opportunity for as many Fedora > members to join us at an hour they might be awake. > > With that said, here's my proposal. > > > FESCo Candidate forum > Wednesday, June 3, 1400 UTC > (10am US Eastern Daylight Time, 7am US Pacific Daylight Time) > > FESCo Candiate forum > Thursday, June 4, 0200 UTC > (Wed night, 10pm US Eastern Daylight Time, 7pm US Pacific Daylight Time) > > Board Candidate forum > Thursday, June 4, 1400 UTC > (10am US Eastern Daylight Time, 7am US Pacific Daylight Time) > > the second Board forum should be Friday morning UTC, not Thursday morning, as that would conflict with FESCo. Cut-n-paste error on my part. Thanks to David Nalley for catching this. Board Candidate forum Friday, June 5, 0200 UTC (Thurs night, 10pm US Eastern Daylight Time, 7pm US Pacific Daylight Time) Thanks, Matt CalendarMaster (failing at such) From rjones at redhat.com Mon Jun 1 19:15:27 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 1 Jun 2009 20:15:27 +0100 Subject: Fedora bittorrent tracker? In-Reply-To: <604aa7910906011139i6d4553b1s9d0dbfc75d8bee5a@mail.gmail.com> References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> <20090601162905.GA19818@amd.home.annexia.org> <604aa7910906011139i6d4553b1s9d0dbfc75d8bee5a@mail.gmail.com> Message-ID: <20090601191527.GA20631@amd.home.annexia.org> On Mon, Jun 01, 2009 at 10:39:59AM -0800, Jeff Spaleta wrote: > On Mon, Jun 1, 2009 at 8:30 AM, Seth Vidal wrote: > > or, alternatively, I could see about ?setting up a tracker-only non-seed > > path for our current tracker so that we could just track but not seed. > > > > Provided your seed would be doing all the bit-pushing work :) > > Hmm if this works out well, this might be a useful service for > contributors in a more general sense. Once you have the seedless > tracker in place, it will be interesting to see if other people make > requests to use it for other secondary content. My thoughts precisely. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From mail at robertoragusa.it Mon Jun 1 19:21:23 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Mon, 01 Jun 2009 21:21:23 +0200 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> <4A23972E.2060805@robertoragusa.it> <2d319b780906010238t77ebe521q133b6fea3503981e@mail.gmail.com> <385866f0906010752m23f8608dta48b0fb353f1570d@mail.gmail.com> Message-ID: <4A242A33.2060502@robertoragusa.it> Seth Vidal wrote: > >> And how do you define "library"? There's no reliable way to >> distinguish them >> from applications. > > This is part of the problem. It would be nice to have all things which > are strictly libraries add a "provides: Library something" and, of > course, to have all libs split from all apps. Why should libraries be special? They are not. Libraries dragged as dependencies are candidate for removal when nothing currently installed is depending on them. Libraries installed explicitly by the user must not be removed (maybe I need them for a not-packaged or manually compiled app). s/Libraries/Apps -> same rules have to apply Apps dragged as dependencies could be volatile, apps the user decided to install must stay. Please do not limit the issue to lib/not-lib. Things are more complex (well, maybe they are actually simpler...) For example: a) wireshark-gnome (depends on wireshark) b) wireshark (depends on libpcap) c) libpcap (depends on libutilswhichsomedevelopersliketouse) d) libutilswhichsomedevelopersliketouse It makes a lot of difference if a user - has installed a) and dragged b) c) d) for dependencies (removing a) could try to remove everything) or - has installed c) and d) for own use/development, then some day installs a) which drags b) (removing a) should only try to remove b) ) - has installed c) and d) for own use/development, then some day installs b), then some day installs a) (removing a) should not try to remove anything else ) There is only one use case a little tricky: if I have a), which dragged b) c) and d), and now I want to mark b) as wanted, what should I do? maybe: # yum install b) To be installed: none To be updated: none To be marked as user-installed: b) Proceed? (y/n) y Operation complete. The semantics is simple and clear, we just need a good name for the "wanted" stuff. wanted? user-installed? pinned? Best regards. -- Roberto Ragusa mail at robertoragusa.it From awilliam at redhat.com Mon Jun 1 19:40:47 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 01 Jun 2009 12:40:47 -0700 Subject: Packaging Survey - May 2009 In-Reply-To: <64b14b300906010856kf3015f9xe724cc71476ac6a1@mail.gmail.com> References: <4A1D24AC.4090802@fedoraproject.org> <64b14b300906010856kf3015f9xe724cc71476ac6a1@mail.gmail.com> Message-ID: <1243885247.2937.270.camel@adam.local.net> On Mon, 2009-06-01 at 17:56 +0200, Valent Turkovic wrote: > Here is my wishlist of packages I would LOVE to see in Fedora: > > - Songbird > - XBMC (best media center for Linux) Both of these are horrible, horrible code bases. > - Navit (GPS navigation) I packaged this for MDV a few months back: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/navit/current/ hasn't been updated since then though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From skvidal at fedoraproject.org Mon Jun 1 19:38:30 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 1 Jun 2009 15:38:30 -0400 (EDT) Subject: Fedora bittorrent tracker? In-Reply-To: <604aa7910906011139i6d4553b1s9d0dbfc75d8bee5a@mail.gmail.com> References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> <20090601162905.GA19818@amd.home.annexia.org> <604aa7910906011139i6d4553b1s9d0dbfc75d8bee5a@mail.gmail.com> Message-ID: On Mon, 1 Jun 2009, Jeff Spaleta wrote: > On Mon, Jun 1, 2009 at 8:30 AM, Seth Vidal wrote: >> or, alternatively, I could see about ?setting up a tracker-only non-seed >> path for our current tracker so that we could just track but not seed. >> >> Provided your seed would be doing all the bit-pushing work :) > > Hmm if this works out well, this might be a useful service for > contributors in a more general sense. Once you have the seedless > tracker in place, it will be interesting to see if other people make > requests to use it for other secondary content. > No problem from me- I just don't think we've had requests for this kind of thing, yet - and we'll need to police it. -sv From awilliam at redhat.com Mon Jun 1 19:50:56 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 01 Jun 2009 12:50:56 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <4A2414B8.2000907@leemhuis.info> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> Message-ID: <1243885856.2937.271.camel@adam.local.net> On Mon, 2009-06-01 at 19:49 +0200, Thorsten Leemhuis wrote: > - should we set an way earlier freezes date for things like anaconda, > kernel, isolinux, grub and other crucial pieces to make sure they are > in > better shape a bit earlier and thus are less likely a reason for > release > slips? If you're basing this off the F11 cycle, it's worth noting that kernel and anaconda have not been 'reasons for release slips' in this cycle in that late changes were made to them which turned out to be bad ideas. It was simply that there were bugs in them all along which were critical enough to block the release. An earlier freeze date would not have helped at all. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From vonbrand at inf.utfsm.cl Mon Jun 1 19:51:39 2009 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 01 Jun 2009 15:51:39 -0400 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <4A242A33.2060502@robertoragusa.it> References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> <4A23972E.2060805@robertoragusa.it> <2d319b780906010238t77ebe521q133b6fea3503981e@mail.gmail.com> <385866f0906010752m23f8608dta48b0fb353f1570d@mail.gmail.com> <4A242A33.2060502@robertoragusa.it> Message-ID: <200906011951.n51JpdKi007715@laptop14.inf.utfsm.cl> Roberto Ragusa wrote: > Seth Vidal wrote: > > > >> And how do you define "library"? There's no reliable way to > >> distinguish them > >> from applications. > > > > This is part of the problem. It would be nice to have all things which > > are strictly libraries add a "provides: Library something" and, of > > course, to have all libs split from all apps. > > Why should libraries be special? They are not. > > Libraries dragged as dependencies are candidate for removal when > nothing currently installed is depending on them. > Libraries installed explicitly by the user must not be removed > (maybe I need them for a not-packaged or manually compiled app). > > s/Libraries/Apps -> same rules have to apply > > Apps dragged as dependencies could be volatile, apps the user > decided to install must stay. > > Please do not limit the issue to lib/not-lib. Things are more complex > (well, maybe they are actually simpler...) > > For example: > > a) wireshark-gnome (depends on wireshark) > b) wireshark (depends on libpcap) > c) libpcap (depends on libutilswhichsomedevelopersliketouse) > d) libutilswhichsomedevelopersliketouse > > It makes a lot of difference if a user > > - has installed a) and dragged b) c) d) for dependencies > (removing a) could try to remove everything) > > or > > - has installed c) and d) for own use/development, then some day > installs a) which drags b) > (removing a) should only try to remove b) ) > > - has installed c) and d) for own use/development, then some day > installs b), then some day installs a) > (removing a) should not try to remove anything else ) > > There is only one use case a little tricky: > if I have a), which dragged b) c) and d), and now I want to > mark b) as wanted, what should I do? maybe: > # yum install b) > To be installed: > none > To be updated: > none > To be marked as user-installed: > b) > Proceed? (y/n) > y > Operation complete. This means the overloaded user has to remember to mark as used the stuff she is using so it doesn't get pulled out from under her feet by deleting unrelated packages. What should now happen if, say, (c) gets updated, but nothing else in the stack? What if ethereal gets renamed to wireshark? What if (c) gets replaced upstream by a functionally equivalent, but different code base, package? What if the whole stack gets replaced by functionally equivalent, but API-wise completely different (and even divided into completely different layers), stuff? It seems to me that most of this nonsense is easy to get right with no further effort than just creating your own RPMs and installing those, instead of futzing around installing _systemwide_ from source. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From sundaram at fedoraproject.org Mon Jun 1 19:58:10 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 02 Jun 2009 01:28:10 +0530 Subject: Packaging Survey - May 2009 In-Reply-To: <64b14b300906010856kf3015f9xe724cc71476ac6a1@mail.gmail.com> References: <4A1D24AC.4090802@fedoraproject.org> <64b14b300906010856kf3015f9xe724cc71476ac6a1@mail.gmail.com> Message-ID: <4A2432D2.2040209@fedoraproject.org> On 06/01/2009 09:26 PM, Valent Turkovic wrote: > Here is my wishlist of packages I would LOVE to see in Fedora: > > - Songbird In review already. > - Freemind (Mind mapping java app) In the wiki page already. Rest of it, feel free to add it to the wiki directly. Rahul From jspaleta at gmail.com Mon Jun 1 19:59:04 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 1 Jun 2009 11:59:04 -0800 Subject: Fedora bittorrent tracker? In-Reply-To: References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> <20090601162905.GA19818@amd.home.annexia.org> <604aa7910906011139i6d4553b1s9d0dbfc75d8bee5a@mail.gmail.com> Message-ID: <604aa7910906011259k34d2876rf353647a8cb363f8@mail.gmail.com> On Mon, Jun 1, 2009 at 11:38 AM, Seth Vidal wrote: > No problem from me- ?I just don't think we've had requests for this kind of > thing, yet - and we'll need to police it. It maybe one of those things that ends up being requested only after people know its there to be used. Or it might not catch on all. I'm not saying do the integration work with FAS yet, and make it clickity easy for people to track torrents. But maybe have the seedless tracker look into a specific directory in the people spaces for .torrent files to track. Like how the planet picks up your feed info. That might lower the bar enough to make people think about using it for things. For example...If the new version of pitivi that's under development now is as good as the blogs make it out to be. Come F12 we could be shipping a reasonably good video editer tool as part of the distro. A seedless tracker might be a great way to foster a secondary community of raw dv video content like interviews and FAD events and screencasts...with the goal of other people being able to edit it down into usable clips in pitivi and producing theora encoded content of reasonable size. Without putting an initial burden on Fedora infrastructure to make space for all the raw content. torrents may not be good for packages, but its great as a way to spread stupidly large dv video clips. Policing it is another can of worms entirely. I imagine, a simple don't be an ass honor code would apply similar to the cvs commit access. -jef"I'm looking forward to seeing the datamined nuggets richard wants to distributed. He's such a tease."spaleta From stickster at gmail.com Mon Jun 1 20:03:04 2009 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 1 Jun 2009 16:03:04 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1243880066.29188.20.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> Message-ID: <20090601200304.GF3583@localhost.localdomain> On Mon, Jun 01, 2009 at 11:14:26AM -0700, Jesse Keating wrote: > On Mon, 2009-06-01 at 19:49 +0200, Thorsten Leemhuis wrote: [...snip...] > > From the discussion after that it looked a whole lot like as if > > some important kernel developers where *not* aware that the kernel > > for the release was needed on that day, which I find quite > > alarming... (even if you got a proper kernel after you wrote the > > text quoted above) > > That's a fair point. We don't well document or communicate the > "points of no return" as it were. We've also had to discuss how we > set those. In the past it was the last point at which we could > compose and upload the bits to the master mirror in order to have > enough mirrors synced at release day. Now it seems more that we > have to make that decision within enough time to spin up (or down) > the marketing machine, which looks to require more leadtime than the > mirrors do. And release day parties, moving translation deadlines for zero-day updates, and so on... There are a lot of moving parts to fit together. > > - other distributions seems to manage a whole lot more test > > releases (e.g. alphas, beta, RC, milestones, ...) per devel cycle; > > is that something we should aim for as well? > > If there was a way to do it without adding stress and work needed to > teams like releng, installer, etc.. that would be possible, also if > they were done without freezes. But the overwhelming requests I get > are of /less/ of these test releases rather than more. If our > release cycle were 9 months or even 12~24 months it would make a lot > more sense to have more milestones. But with only a 6 month cycle > it gets hard to find time to do development in between all the > already existing milestones. To what extent do these other distributions: (1) ...offer a set of tools by which anyone can produce something roughly equivalent to a milestone release, as I can do with pungi any day that the installer is working properly?* Honest question, not snark. (2) ...consume their content from another integrated packaging source upstream? * I realize that's a question unto itself, which Thorsten asked about later. Or rather, sooner: > > - at least it sometimes feels like "rawhide installation using > > boot.iso feels like broken for weeks or months". That annoying and > > confusing even for people like me. How about targetting "rawhide > > must be install-able using boot.iso every Friday; crazy new stuff > > (like a new python release) must get imported on Mondays with the > > goal to have things in a good shape by Friday" > > That's what we hoped to have with the post-beta snapshots. Hard to > say if it's had any real impact, likely due to the short amount of > time between beta and the final freeze/preview release. If we > attempted to do snapshots leading up to the beta that might make it > more noticeable, but then we're back in the realm of more milestones > instead of less. > > > - how about doing something like a "cp -l development > > devel-snapshot" now and then (once a week) when we know rawhide is > > mostly working? > > The rawhide trees for at least the past month are kept in the Fedora > infrastructure and are even available by a public url. We haven't > tagged any of them as "stable" though. I didn't even know this last part. But I think many people, including me, rel-eng and QA, are interested in having a more consistently testable Rawhide. > > - how can we reduce our time between finishing a (test) release > > and releasing it dramatically? It seems other distributions get > > new (test) release out to the users a lot quicker then the three > > to five days days we require, which seems a whole lot for a devel > > cycle that takes 180 days in total (and we all know how much > > rawhide can move on with a few days) > > If we didn't care to let the mirrors sync up we could "release" it > earlier. However what good does that do when nobody can /get/ to > the release because none of the mirrors have it, and the ones that > do can't help sync to those that don't because users are tying up > all the bandwidth? I'm getting out of my ken here, but could this be done in stages with I2 connected hosts getting the bits early/first and then moving on to others? [...snip...] > > - why do we have to slip by a whole week most of the time? can't we find > > ways to slip just a day or two if there really is no way around a delay? > > The marketing machine has very strongly requested that we only do > releases on Tuesdays. There is a group of resources inside Red Hat that we're able to call on for enhancing press coverage of our releases. They've given us their expert opinion that Tuesdays are the best day for that. While it's not a concrete requirement to make use of those services, we tend to listen to the experts. In quite a number of cases, though, a slip necessitates additional testing which itself takes a number of days. Putting in a bug fix and respinning can have its own undesired effects.... > > - I like the idea to "keep rawhide (nearly) always moving" a lot It will be interesting to hear the brainstorming around this at the FAD. I think many people would be happy if that moving Rawhide train ended up serving the dual purpose of decreasing late changes in a release cycle, but I'm not sure there's a 1:1 fit there. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From stickster at gmail.com Mon Jun 1 20:03:04 2009 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 1 Jun 2009 16:03:04 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1243880066.29188.20.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> Message-ID: <20090601200304.GF3583@localhost.localdomain> On Mon, Jun 01, 2009 at 11:14:26AM -0700, Jesse Keating wrote: > On Mon, 2009-06-01 at 19:49 +0200, Thorsten Leemhuis wrote: [...snip...] > > From the discussion after that it looked a whole lot like as if > > some important kernel developers where *not* aware that the kernel > > for the release was needed on that day, which I find quite > > alarming... (even if you got a proper kernel after you wrote the > > text quoted above) > > That's a fair point. We don't well document or communicate the > "points of no return" as it were. We've also had to discuss how we > set those. In the past it was the last point at which we could > compose and upload the bits to the master mirror in order to have > enough mirrors synced at release day. Now it seems more that we > have to make that decision within enough time to spin up (or down) > the marketing machine, which looks to require more leadtime than the > mirrors do. And release day parties, moving translation deadlines for zero-day updates, and so on... There are a lot of moving parts to fit together. > > - other distributions seems to manage a whole lot more test > > releases (e.g. alphas, beta, RC, milestones, ...) per devel cycle; > > is that something we should aim for as well? > > If there was a way to do it without adding stress and work needed to > teams like releng, installer, etc.. that would be possible, also if > they were done without freezes. But the overwhelming requests I get > are of /less/ of these test releases rather than more. If our > release cycle were 9 months or even 12~24 months it would make a lot > more sense to have more milestones. But with only a 6 month cycle > it gets hard to find time to do development in between all the > already existing milestones. To what extent do these other distributions: (1) ...offer a set of tools by which anyone can produce something roughly equivalent to a milestone release, as I can do with pungi any day that the installer is working properly?* Honest question, not snark. (2) ...consume their content from another integrated packaging source upstream? * I realize that's a question unto itself, which Thorsten asked about later. Or rather, sooner: > > - at least it sometimes feels like "rawhide installation using > > boot.iso feels like broken for weeks or months". That annoying and > > confusing even for people like me. How about targetting "rawhide > > must be install-able using boot.iso every Friday; crazy new stuff > > (like a new python release) must get imported on Mondays with the > > goal to have things in a good shape by Friday" > > That's what we hoped to have with the post-beta snapshots. Hard to > say if it's had any real impact, likely due to the short amount of > time between beta and the final freeze/preview release. If we > attempted to do snapshots leading up to the beta that might make it > more noticeable, but then we're back in the realm of more milestones > instead of less. > > > - how about doing something like a "cp -l development > > devel-snapshot" now and then (once a week) when we know rawhide is > > mostly working? > > The rawhide trees for at least the past month are kept in the Fedora > infrastructure and are even available by a public url. We haven't > tagged any of them as "stable" though. I didn't even know this last part. But I think many people, including me, rel-eng and QA, are interested in having a more consistently testable Rawhide. > > - how can we reduce our time between finishing a (test) release > > and releasing it dramatically? It seems other distributions get > > new (test) release out to the users a lot quicker then the three > > to five days days we require, which seems a whole lot for a devel > > cycle that takes 180 days in total (and we all know how much > > rawhide can move on with a few days) > > If we didn't care to let the mirrors sync up we could "release" it > earlier. However what good does that do when nobody can /get/ to > the release because none of the mirrors have it, and the ones that > do can't help sync to those that don't because users are tying up > all the bandwidth? I'm getting out of my ken here, but could this be done in stages with I2 connected hosts getting the bits early/first and then moving on to others? [...snip...] > > - why do we have to slip by a whole week most of the time? can't we find > > ways to slip just a day or two if there really is no way around a delay? > > The marketing machine has very strongly requested that we only do > releases on Tuesdays. There is a group of resources inside Red Hat that we're able to call on for enhancing press coverage of our releases. They've given us their expert opinion that Tuesdays are the best day for that. While it's not a concrete requirement to make use of those services, we tend to listen to the experts. In quite a number of cases, though, a slip necessitates additional testing which itself takes a number of days. Putting in a bug fix and respinning can have its own undesired effects.... > > - I like the idea to "keep rawhide (nearly) always moving" a lot It will be interesting to hear the brainstorming around this at the FAD. I think many people would be happy if that moving Rawhide train ended up serving the dual purpose of decreasing late changes in a release cycle, but I'm not sure there's a 1:1 fit there. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From jspaleta at gmail.com Mon Jun 1 20:18:21 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 1 Jun 2009 12:18:21 -0800 Subject: Packaging Survey - May 2009 In-Reply-To: <4A1D24AC.4090802@fedoraproject.org> References: <4A1D24AC.4090802@fedoraproject.org> Message-ID: <604aa7910906011318m78cfdde8s1e1e570c9493365@mail.gmail.com> On Wed, May 27, 2009 at 3:31 AM, Rahul Sundaram wrote: > Hi > > I did a quick survey from Fedora on what software Fedora users are using > that is not available in the repo. Here are the results. If you find > anything interesting, feel free to pick it up. > > https://fedoraproject.org/wiki/Packaging_Survey_May_2009 eucalyptus has a non-trivial list of java deps that we don't have packaged yet. I looked at the 1.5 pre-release tarballs in launchpad before ecualyptus opened up its bzr trees to the public. Ubuntu seems to have initially solved this problem in a way that our packaging review process would definitely not allow. They lumped a lot of individual java codebased together into a single package in order to streamline the effort to get eucalyptus into universe. http://packages.ubuntu.com/jaunty/eucalyptus-javadeps It would take a concerted effort of a number of contributors with reasonable java packaging experience to work together and coordinate package reviews to build up the complete set of java packages needed for full eucalyptus functionality. I would definitely not be among them. If people are serious about it. I really suggest they start forming up a team and start working on it now with F12 as a target release for the first full set of packages. -jef From kevin.kofler at chello.at Mon Jun 1 20:18:56 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 01 Jun 2009 22:18:56 +0200 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> <4A23972E.2060805@robertoragusa.it> <2d319b780906010238t77ebe521q133b6fea3503981e@mail.gmail.com> <385866f0906010752m23f8608dta48b0fb353f1570d@mail.gmail.com> <20090601172543.GC24209@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > If a package installs a shared object with a SONAME in %{_libdir}, it is > a reasonable assumption that it contains libraries. But there are lots of applications which contain libraries. Kevin Kofler From bjorn at xn--rombobjrn-67a.se Mon Jun 1 20:23:24 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Mon, 1 Jun 2009 22:23:24 +0200 Subject: RPM Soft dependencies In-Reply-To: <20090601172543.GC24209@nostromo.devel.redhat.com> References: <1243765101.2560.6.camel@localhost.localdomain> <20090601172543.GC24209@nostromo.devel.redhat.com> Message-ID: <200906012223.24679.bjorn@xn--rombobjrn-67a.se> Bill Nottingham wrote: > If a package installs a shared object with a SONAME in %{_libdir}, it is > a reasonable assumption that it contains libraries. And if it's a library of Python code? Or Perl, or PHP, or Scheme, or ... ? Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From awilliam at redhat.com Mon Jun 1 20:26:20 2009 From: awilliam at redhat.com (Adam Williamson) Date: Mon, 01 Jun 2009 13:26:20 -0700 Subject: hp-setup error (missing Qt4) In-Reply-To: <1243853595.2896.5.camel@worm> References: <1243853595.2896.5.camel@worm> Message-ID: <1243887980.2937.274.camel@adam.local.net> On Mon, 2009-06-01 at 11:53 +0100, Tim Waugh wrote: > On Sun, 2009-05-31 at 21:42 -0700, David L wrote: > > Is there a dependency problem with hplip? > > No. > > Use 'hp-setup -i' if you want to use it without Qt4 installed. > > The dependency that had been there was explicitly removed for the folk > who like 'hp-setup -i'. Sounds like a perfect case for a soft dependency! ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From atorkhov at gmail.com Mon Jun 1 20:30:48 2009 From: atorkhov at gmail.com (Alexey Torkhov) Date: Tue, 02 Jun 2009 00:30:48 +0400 Subject: Why not to create Fedora-us and Fedora-non-us branches? In-Reply-To: <20090601132055.GL9001@localhost.localdomain> References: <20090526170612.GJ9951@nostromo.devel.redhat.com> <1243358736.3144.23.camel@localhost.localdomain> <4A1C2961.70703@redhat.com> <4A2269C7.1010800@fedoraproject.org> <1243770864.26053.8.camel@localhost.localdomain> <4A227206.9010601@fedoraproject.org> <1243772287.26053.15.camel@localhost.localdomain> <4A2276F5.7040904@fedoraproject.org> <20090601132055.GL9001@localhost.localdomain> Message-ID: <1243888248.20709.18.camel@localhost.localdomain> On Mon, 2009-06-01 at 09:20 -0400, Paul W. Frields wrote: > On Sun, May 31, 2009 at 05:54:21PM +0530, Rahul Sundaram wrote: > > On 05/31/2009 05:48 PM, Alexey Torkhov wrote: > > > On Sun, 2009-05-31 at 17:33 +0530, Rahul Sundaram wrote: > > >> On 05/31/2009 05:24 PM, Alexey Torkhov wrote: > > >>> On Sun, 2009-05-31 at 16:58 +0530, Rahul Sundaram wrote: > > >> > > >>> > > >>> Usage of trademark was granted to Russian Fedora by agreement between > > >>> Red Hat and other company that represent it here, AFAIK. > > >>> Max Spevack was on presentation on Russian Fedora launch. > > >> > > >> I don't see it recorded in > > >> > > >> https://fedoraproject.org/wiki/Trademark_licensees > > >> > > >> It doesn't fit the trademark guidelines either. While Red Hat can > > >> legally grant a license to anyone and doesn't have to abide by the > > >> guidelines, I would expect it to do so nevertheless. So why a special > > >> exception for "Russian Fedora"? > > > > > > I don't know the details of an agreement, ask legal team for that. > > > > I don't need to know the details of the agreement. If any such agreement > > exists, it should follow the trademark guidelines that Fedora set for > > rest of the community and not be given special exceptions. Can the > > Fedora Board look into this? > > I'm already doing so with Max Spevack. There was mentioned in thread in ambassadors list that it should be actually called "Russian Fedora Remix". And it is officially called that. Russian Fedora is just a slang. Sorry for bringing in incorrect information. But they still use slightly modified fedora-logos package. Could you clarify logo guidelines about that package. Is it possible to use it unmodified in remix? Or all fedora logos should be replaced with fedora remix logos? Using generic-logos package would not be solution here, as, I?m sure, they will want to leave as much fedora branding as possible, without striping all logos. Alexey From bjorn at xn--rombobjrn-67a.se Mon Jun 1 20:26:41 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Mon, 1 Jun 2009 22:26:41 +0200 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <200906011951.n51JpdKi007715@laptop14.inf.utfsm.cl> References: <4A242A33.2060502@robertoragusa.it> <200906011951.n51JpdKi007715@laptop14.inf.utfsm.cl> Message-ID: <200906012226.41745.bjorn@xn--rombobjrn-67a.se> Horst H. von Brand wrote: > This means the overloaded user has to remember to mark as used the stuff > she is using so it doesn't get pulled out from under her feet by deleting > unrelated packages. She *could* look through the list that yum presents before she types "y". Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From mail at robertoragusa.it Mon Jun 1 22:22:01 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Tue, 02 Jun 2009 00:22:01 +0200 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <200906011951.n51JpdKi007715@laptop14.inf.utfsm.cl> References: <1243765101.2560.6.camel@localhost.localdomain> <2d319b780905310336x2cf9d0a2w57f7d10f007885ee@mail.gmail.com> <200905311448.45745.ville.skytta@iki.fi> <2d319b780905310532r49f0bd56neb1c9cc67fa2e60a@mail.gmail.com> <4A23972E.2060805@robertoragusa.it> <2d319b780906010238t77ebe521q133b6fea3503981e@mail.gmail.com> <385866f0906010752m23f8608dta48b0fb353f1570d@mail.gmail.com> <4A242A33.2060502@robertoragusa.it> <200906011951.n51JpdKi007715@laptop14.inf.utfsm.cl> Message-ID: <4A245489.8070808@robertoragusa.it> Horst H. von Brand wrote: > This means the overloaded user has to remember to mark as used the stuff > she is using so it doesn't get pulled out from under her feet by deleting > unrelated packages. Nobody said stuff has to be removed automatically. After you have a working infrastructure, you can decide the default behavior. # yum remove a) b) Packages to be removed: a) b) Proceed:(y/n) y 2 packages removed. # yum list --unused-deps The following packages were installed for dependencies but are currently not needed (use 'remove --unused-deps' to remove them): c) d) # yum remove --unused-deps Packages to be removed (unused deps): c) d) Proceed:(y/n) y 2 packages removed. (just fictional messages, of course) -- Roberto Ragusa mail at robertoragusa.it From Matt_Domsch at dell.com Mon Jun 1 22:22:17 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 1 Jun 2009 17:22:17 -0500 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <20090601200304.GF3583@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> Message-ID: <20090601222217.GA31066@auslistsprd01.us.dell.com> On Mon, Jun 01, 2009 at 04:03:04PM -0400, Paul W. Frields wrote: > I'm getting out of my ken here, but could this be done in stages with > I2 connected hosts getting the bits early/first and then moving on to > others? We need to move ~130GB to each of ~230 mirrors, in about 4 days. We already have in place a limited amount of "tiering". The Tier 0/1 mirrors get the bits first, then downstream mirrors pull from them. We have nearly all our "Tier 1" mirrors on I2 (all but the us.kernel.org). Right now it's not mandatory, but no "new" mirrors (those signed up in the last 18 months or so) have been granted ACL permissions to download from the masters. http://fedoraproject.org/wiki/Infrastructure/Mirroring/Tiering One of my hopes for the F12 cycle is that we will have increased use of tiering and push mirroring. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From bill at bfccomputing.com Mon Jun 1 22:28:06 2009 From: bill at bfccomputing.com (Bill McGonigle) Date: Mon, 01 Jun 2009 18:28:06 -0400 Subject: Fedora bittorrent tracker? In-Reply-To: <604aa7910906011139i6d4553b1s9d0dbfc75d8bee5a@mail.gmail.com> References: <20090601085347.GA3561@amd.home.annexia.org> <20090601090054.GB32470@alpha.rzhou.org> <20090601132326.GB3522@amd.home.annexia.org> <20090601160229.GA19669@amd.home.annexia.org> <20090601162905.GA19818@amd.home.annexia.org> <604aa7910906011139i6d4553b1s9d0dbfc75d8bee5a@mail.gmail.com> Message-ID: <4A2455F6.1060205@bfccomputing.com> On 06/01/2009 02:39 PM, Jeff Spaleta wrote: > Hmm if this works out well, this might be a useful service for > contributors in a more general sense. Once you have the seedless > tracker in place, it will be interesting to see if other people make > requests to use it for other secondary content. I've been thinking to myself, trying to do testing this round, that having nightly builds from rawhide of live cd's and such would be tremendously useful, but the traditional distribution method doesn't really support it. To digress, it's really hard to be a useful tester without running rawhide, and running rawhide can be really hard on typical users. But liveCD + liveusb-creator is pretty easy. I've done a bit of preliminary reading of protocols and .torrent structure, and haven't seen anything that necessarily precludes a torrent that changes over time. Whether any trackers or clients support this I'm not sure. I'm writing this without having done any experimentation, but this thread seemed like a good opportunity to chime in, and maybe get some advice. Should it prove to be possible, bittorrent may offer some unique advantages over traditional mirror methods. But that's thinking too far ahead. Anyway, it seems a dozen or so folks with pipes thinking a project is a good idea (and thus willing to seed) is enough to bootstrap distribution. And having a coordinated central tracker is a great idea so users can know what's real and what's not. There might be some ideas to be learned from git too - I dunno, I'm mostly thinking out loud. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill at bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From mail at robertoragusa.it Mon Jun 1 22:32:05 2009 From: mail at robertoragusa.it (Roberto Ragusa) Date: Tue, 02 Jun 2009 00:32:05 +0200 Subject: [Sugar-devel] Unbootable machine In-Reply-To: <4A2403FF.2020304@zytor.com> References: <4A236808.1050106@codewiz.org> <4A2403FF.2020304@zytor.com> Message-ID: <4A2456E5.5060704@robertoragusa.it> H. Peter Anvin wrote: > I presume the notion of partition 1 and 4 is to deal with things that > have an odd notion of zipdisks. I have personally not seen any devices > which will only boot with partition 1 or only with partition 4, if you > have any such information I would appreciate it. Just happened to me a few days ago. Tried to make a fedora live on a 1GB USB pen with the Fedora tools. Normal FAT on partition 1, apparently all OK: didn't boot on a Thinkpad (but booted OK with qemu). Found the "big ZIP drive" geometry hint on the web: tried that geometry and only one partition (4). It worked. I did not investigate further. -- Roberto Ragusa mail at robertoragusa.it From kevin.kofler at chello.at Mon Jun 1 22:45:32 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 02 Jun 2009 00:45:32 +0200 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > Now it seems more that we have to make that decision within enough time to > spin up (or down) the marketing machine, which looks to require more > leadtime than the mirrors do. [snip] > The marketing machine has very strongly requested that we only do > releases on Tuesdays. I think it's a bad idea to delay the releases more than necessary for marketing reasons. IMHO we should release as soon as technically feasible. > You'll have to enumerate why that is. One reason I've avoided this is > added confusion as to when the "release" happens. If we created that > directory and put content in there, would we have then released Fedora > 12? When does it become "released" and thus trusted? It means people can go from Rawhide to the release without service interruption. The way it is now, once the release is finalized, the mirror list redirect of the release tree to Rawhide gets turned off (because Rawhide moves on to the next release), but the Everything directory gets opened up only a few days later, on the official release day. That means people cannot install packages from the Everything repository (which can also affect updates because they can add dependencies) for a few days. It also seems natural that, if Rawhide moves on to F13 early, the F12 branch will get put directly into releases/12/Everything so the mirrors won't have to sync everything again once the release becomes official. It shall also be noted that a certain distribution with a 'U' even opens up the repository for the next release right after releasing the previous one, they don't call their development repository "development", "rawhide" or something like that, but with the release name of the next release. Kevin Kofler From jkeating at redhat.com Mon Jun 1 22:45:45 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 01 Jun 2009 15:45:45 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <20090601222217.GA31066@auslistsprd01.us.dell.com> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> Message-ID: <1243896345.29188.43.camel@localhost.localdomain> On Mon, 2009-06-01 at 17:22 -0500, Matt Domsch wrote: > > We need to move ~130GB to each of ~230 mirrors, in about 4 > days. > > We already have in place a limited amount of "tiering". The Tier 0/1 > mirrors get the bits first, then downstream mirrors pull from them. > We have nearly all our "Tier 1" mirrors on I2 (all but the > us.kernel.org). Right now it's not mandatory, but no "new" mirrors > (those signed up in the last 18 months or so) have been granted ACL > permissions to download from the masters. > > http://fedoraproject.org/wiki/Infrastructure/Mirroring/Tiering > > One of my hopes for the F12 cycle is that we will have increased use > of tiering and push mirroring. > One problem is that our master mirror is /not/ on I2. So when we put the content on PHX, we have to wait for non-I2 transfer to RDU which is on I2. Then our I2 hosts can get it. If we had I2 in PHX this would get a lot faster. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Mon Jun 1 22:45:07 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 01 Jun 2009 18:45:07 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1243896345.29188.43.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <1243896345.29188.43.camel@localhost.localdomain> Message-ID: <4A2459F3.8040300@redhat.com> On 06/01/2009 06:45 PM, Jesse Keating wrote: > If we had I2 in PHX this would get a lot faster. We just need to hold some classes and get the PHX datacenter certified as a University. ;) ~spot From jkeating at redhat.com Mon Jun 1 23:48:08 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 01 Jun 2009 16:48:08 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> Message-ID: <1243900088.29188.44.camel@localhost.localdomain> On Tue, 2009-06-02 at 00:45 +0200, Kevin Kofler wrote: > It means people can go from Rawhide to the release without service > interruption. The way it is now, once the release is finalized, the mirror > list redirect of the release tree to Rawhide gets turned off (because > Rawhide moves on to the next release), but the Everything directory gets > opened up only a few days later, on the official release day. That means > people cannot install packages from the Everything repository (which can > also affect updates because they can add dependencies) for a few days. > > It also seems natural that, if Rawhide moves on to F13 early, the F12 branch > will get put directly into releases/12/Everything so the mirrors won't have > to sync everything again once the release becomes official. > > It shall also be noted that a certain distribution with a 'U' even opens up > the repository for the next release right after releasing the previous one, > they don't call their development repository "development", "rawhide" or > something like that, but with the release name of the next release. This is one of the things we hope to come up with a proposal to fix at our Fedora Activity Day this month. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bernie at codewiz.org Tue Jun 2 00:40:38 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Tue, 02 Jun 2009 02:40:38 +0200 Subject: Unbootable machine In-Reply-To: <4A2377B3.8060309@zytor.com> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> Message-ID: <4A247506.4000304@codewiz.org> On 06/01/09 08:39, H. Peter Anvin wrote: > I need much more details; *all* Award BIOSes make in the past 10-12 > years have version number 6.00PG. Ouch, I no longer have access to it. I asked the owner to let me know. > Also look for how you have configured your BIOS... some Award BIOSes > have USB-ZIP, USB-HDD, USB-FDD configurations; you generally want USB-HDD. I booted from the BBS menu (F8), the item was labelled something like "USB HDD 2.0". > There are some BIOSes which will boot from USB *only* if it was > formatted with 64 heads, 32 sectors; apparently due to some odd notion > that only zipdrives would be USB. Good to know. Mine looks like this: bernie at giskard:~/src/kernel$ sudo fdisk -l /dev/sdb Disk /dev/sdb: 2055 MB, 2055208960 bytes 221 heads, 2 sectors/track, 9081 cylinders Units = cylinders of 442 * 512 = 226304 bytes Disk identifier: 0x000aa8c2 Device Boot Start End Blocks Id System /dev/sdb1 * 1 9082 2007006+ c W95 FAT32 (LBA) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From hpa at zytor.com Tue Jun 2 01:43:36 2009 From: hpa at zytor.com (H. Peter Anvin) Date: Mon, 01 Jun 2009 18:43:36 -0700 Subject: Unbootable machine In-Reply-To: <4A247506.4000304@codewiz.org> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> <4A247506.4000304@codewiz.org> Message-ID: <4A2483C8.7090706@zytor.com> Bernie Innocenti wrote: > Disk /dev/sdb: 2055 MB, 2055208960 bytes > 221 heads, 2 sectors/track, 9081 cylinders I don't know where fdisk, the Linux kernel, or whatever come up with these kinds of geometries. They're almost universally non-bootable. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. From bruno at wolff.to Tue Jun 2 01:56:39 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 1 Jun 2009 20:56:39 -0500 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1243896345.29188.43.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <1243896345.29188.43.camel@localhost.localdomain> Message-ID: <20090602015639.GA30712@wolff.to> On Mon, Jun 01, 2009 at 15:45:45 -0700, Jesse Keating wrote: > > One problem is that our master mirror is /not/ on I2. So when we put > the content on PHX, we have to wait for non-I2 transfer to RDU which is > on I2. Then our I2 hosts can get it. > > If we had I2 in PHX this would get a lot faster. What about hand carrying a disk drive over to RDU? Would that be faster than using an internet transfer? Do you hard link the new release files to the ones identical in rawhide so that rsync doesn't have to transfer them to places mirroring rawhide? From jkeating at redhat.com Tue Jun 2 03:19:30 2009 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 01 Jun 2009 20:19:30 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <20090602015639.GA30712@wolff.to> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <1243896345.29188.43.camel@localhost.localdomain> <20090602015639.GA30712@wolff.to> Message-ID: <1243912770.29188.50.camel@localhost.localdomain> On Mon, 2009-06-01 at 20:56 -0500, Bruno Wolff III wrote: > > What about hand carrying a disk drive over to RDU? Would that be faster > than using an internet transfer? Not really. > > Do you hard link the new release files to the ones identical in rawhide > so that rsync doesn't have to transfer them to places mirroring rawhide? Yes and no. We do use hardlinks, however the mechanism that gets it from PHX to Raleigh is Netapp snapmirror, which works at the block level. I don't know enough about snapmirror to know if it is helped by hardlinks or not. The individual files aren't the real problem, it's the isos, particularly the live isos. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bernie at codewiz.org Tue Jun 2 03:27:14 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Tue, 02 Jun 2009 05:27:14 +0200 Subject: Unbootable machine In-Reply-To: <4A2483C8.7090706@zytor.com> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> <4A247506.4000304@codewiz.org> <4A2483C8.7090706@zytor.com> Message-ID: <4A249C12.2060708@codewiz.org> On 06/02/09 03:43, H. Peter Anvin wrote: > Bernie Innocenti wrote: >> Disk /dev/sdb: 2055 MB, 2055208960 bytes >> 221 heads, 2 sectors/track, 9081 cylinders > > I don't know where fdisk, the Linux kernel, or whatever come up with > these kinds of geometries. They're almost universally non-bootable. Ok, I wiped mbr and made fdisk create a new one: Disk /dev/sdb: 2055 MB, 2055208960 bytes 64 heads, 62 sectors/track, 1011 cylinders Units = cylinders of 3968 * 512 = 2031616 bytes Disk identifier: 0xc3790b2f Device Boot Start End Blocks Id System /dev/sdb1 * 1 1011 2005793 c W95 FAT32 (LBA) I'll try it tomorrow. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From hpa at zytor.com Tue Jun 2 05:10:37 2009 From: hpa at zytor.com (H. Peter Anvin) Date: Mon, 01 Jun 2009 22:10:37 -0700 Subject: Unbootable machine In-Reply-To: <4A249C12.2060708@codewiz.org> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> <4A247506.4000304@codewiz.org> <4A2483C8.7090706@zytor.com> <4A249C12.2060708@codewiz.org> Message-ID: <4A24B44D.3070607@zytor.com> Bernie Innocenti wrote: > On 06/02/09 03:43, H. Peter Anvin wrote: >> Bernie Innocenti wrote: >>> Disk /dev/sdb: 2055 MB, 2055208960 bytes >>> 221 heads, 2 sectors/track, 9081 cylinders >> I don't know where fdisk, the Linux kernel, or whatever come up with >> these kinds of geometries. They're almost universally non-bootable. > > Ok, I wiped mbr and made fdisk create a new one: > > Disk /dev/sdb: 2055 MB, 2055208960 bytes > 64 heads, 62 sectors/track, 1011 cylinders ^^^^^^^^^^^^^^^^^^^^^^^^^^ Equally weird. The only "standard" ones are 64 heads, 32 sectors and 255 heads, 63 sectors. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. From bruno at wolff.to Tue Jun 2 06:17:49 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 2 Jun 2009 01:17:49 -0500 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> Message-ID: <20090602061749.GA14047@wolff.to> On Tue, Jun 02, 2009 at 00:45:32 +0200, Kevin Kofler wrote: > > I think it's a bad idea to delay the releases more than necessary for > marketing reasons. IMHO we should release as soon as technically feasible. I think the release is really a marketting event anyway. Assuming there wasn't an install or driver issue affecting you, people could have been running F11 since the preview without getting a much different experience than what you'll get with the release. And even then the release is going to be modified by the updates (there are around 900 updates available in stable, testing and pending for F11). > It means people can go from Rawhide to the release without service > interruption. The way it is now, once the release is finalized, the mirror > list redirect of the release tree to Rawhide gets turned off (because > Rawhide moves on to the next release), but the Everything directory gets > opened up only a few days later, on the official release day. That means > people cannot install packages from the Everything repository (which can > also affect updates because they can add dependencies) for a few days. I agree that using the same pattern for development releases would make transitioning between development and production. This helps those of us that don't continously track rawhide, but often switch to it at some point during the development cycle. It also makes working with mirror scripts easier as you can base things off the release version and not have to worry about the changes in mirror paths between releases and rawhide that currently exists. One downside would be people less familiar with Fedora accidentally grabbing stuff from the develpoment trees not realizing that they were development trees. But that seems like an unlikely path for people new to Fedora to get started. Another potential downside would be for people always wanting to track rawhide. But this might be handled by having a symlink from rawhide to the highest numbered release that gets changed everytime a new release is branched. From bashton at brennanashton.com Tue Jun 2 07:32:23 2009 From: bashton at brennanashton.com (Brennan Ashton) Date: Tue, 2 Jun 2009 00:32:23 -0700 Subject: Fedora Bugzilla Statistics 2009-05-26 - 2009-06-01 Message-ID: <981da310906020032o62dacc76u9a0d0a501f3e9f04@mail.gmail.com> As some of you may have heard over in Bugzappers we are developing some metrics applications for bugzilla to help us recognize testers, developers, and other contributors to the project. This is the first week that we are semi confident that the results are correct, although there is some concern we are missing some of the bugs causing the count to be low. If any of you see something that looks wrong let me know and I will try to track down the issue. Also if there is information that you would like in this report that is not in here already let me know and we can see about adding it. ==Top 5 Triagers== (score is the total number instances where the user has changed any one of these states: NEW, VERIFIED, MODIFIED, ASSIGNED, CLOSED, POST, needinfo?) Steven M. Parrish 133 Matej Cepl 62 Adam Williamson 16 Thomas Janssen 10 Jon Dufresne 4 Paul W. Frields 4 ==Top 5 Bug Closers== Steven M. Parrish 49 Chris Lumens 21 Jens Petersen 14 Michael Schwendt 13 Matej Cepl 12 Lillian Angel 12 ==Top 5 Bug Reporters== Rahul Sundaram 59 Vitezslav Crhonek 13 Gerry Reno 13 Xose Vazquez Perez 10 Tomas Hoger 10 Jussi Lehtola 10 ==Top 5 Components Closing Bugs== inn 18 kdemultimedia 11 avahi 9 sblim-cmpi-base 8 kdebase-workspace 7 Package Review 7 There is much more information that can be pulled via a turbogrears app we are running. But I am looking to see what is useful in terms of a weekly report. I have the date tuesday to tuesday as it matches up with the Bugzappers meeting time. Best Regards, Brennan Ashton From msuchy at redhat.com Tue Jun 2 09:38:33 2009 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Tue, 02 Jun 2009 11:38:33 +0200 Subject: RPM Soft dependencies (Was: Re: Agenda for the 2009-05-26 Packaging Committee meeting) In-Reply-To: <4A2216CE.5030900@gmail.com> References: <4A1B86A3.7040404@fedoraproject.org> <20090526081015.GB27381@amd.home.annexia.org> <4A1BABB3.6060306@fedoraproject.org> <4A1BC11C.5080505@fedoraproject.org> <4A1BCF4B.8050802@hhs.nl> <20090526213410.GA32719@amd.home.annexia.org> <4A1CCB52.4060103@googlemail.com> <20090527072531.GA2413@amd.home.annexia.org> <4A1D91D4.4080909@redhat.com> <200905301609.n4UG9G0M007345@laptop14.inf.utfsm.cl> <1243747391.2937.255.camel@adam.local.net> <4A2216CE.5030900@gmail.com> Message-ID: <4A24F319.2030209@redhat.com> Toshio Kuratomi wrote: > What is the behaviour when a package with soft deps on another package > is upgraded and the soft dependency is currently not installed? I do not know how Mandriva handle it, but in Debian it works like this: Old package A require nothing. New package A: Require B Suggest C $ apt-get upgrade Following package will be upgraded: A Suggested packages: C Following packages will be installed to satisfy dependecies: B Install [Y/n]: I.e. requires are automatically picked up. But suggested packages are not selected and you get only information about them. And if you install using some higher tool (aptitude, dselect), after you leave screen with package selection, then screen like this will appear: Installed/Selection Name Version Available Version yy A 1.0 2.0 _y B 1.0 __ C 1.0 And you may or may not select the suggested package. -- Miroslav Suchy Red Hat Satellite Engineering From mhlavink at redhat.com Tue Jun 2 09:47:19 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Tue, 2 Jun 2009 11:47:19 +0200 Subject: Fedora Bugzilla Statistics 2009-05-26 - 2009-06-01 In-Reply-To: <981da310906020032o62dacc76u9a0d0a501f3e9f04@mail.gmail.com> References: <981da310906020032o62dacc76u9a0d0a501f3e9f04@mail.gmail.com> Message-ID: <200906021147.20018.mhlavink@redhat.com> > There is much more information that can be pulled via a turbogrears > app we are running. But I am looking to see what is useful in terms > of a weekly report. I have the date tuesday to tuesday as it matches > up with the Bugzappers meeting time. > Hi, thanks for the stats. I'd like to see there additional stats for fedora 9, 10, rawhide: - overall number of opened bugs - number of new bugs in last x days - number of closed bugs in last x days Would it be possible? Michal From pm at datasphere.ch Tue Jun 2 09:44:30 2009 From: pm at datasphere.ch (Patrick MONNERAT) Date: Tue, 02 Jun 2009 11:44:30 +0200 Subject: Swapping reviews In-Reply-To: <4A202035.1060101@bachelot.org> References: <1243607900.27826.1.camel@linuxdev.datasphere.ch> <4A202035.1060101@bachelot.org> Message-ID: <1243935870.21969.2.camel@linuxdev.datasphere.ch> On Fri, 2009-05-29 at 19:49 +0200, Xavier Bachelot wrote: > > I have a webcalendar package I never submitted. You may want to take a > look and if you find anything you like, feel free to take. Thanks Xavier, I looked at your package, but it seems to suffer from the same weakness as mine: bundled modules :-( From mnowak at redhat.com Tue Jun 2 10:14:10 2009 From: mnowak at redhat.com (Michal Nowak) Date: Tue, 2 Jun 2009 06:14:10 -0400 (EDT) Subject: Orphaned eclipse-pydev In-Reply-To: <1243852992.2514.4.camel@choeger6> Message-ID: <1130437692.3805001243937650469.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> ----- "Christoph H?ger" wrote: > Isn't that this application with ads in it? Mmm, not aware of any... Not sure what you meant. From richardfearn at gmail.com Tue Jun 2 10:33:33 2009 From: richardfearn at gmail.com (Richard Fearn) Date: Tue, 2 Jun 2009 11:33:33 +0100 Subject: Orphaned eclipse-pydev In-Reply-To: <1130437692.3805001243937650469.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1243852992.2514.4.camel@choeger6> <1130437692.3805001243937650469.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <212718d80906020333o1cb00373oa65827d99430273e@mail.gmail.com> >> Isn't that this application with ads in it? > > Mmm, not aware of any... Not sure what you meant. If you use the evaluation version of Pydev Extensions (a different plugin to Pydev), it reminds you every so often to buy the full version. See: http://fabioz.com/pydev/ The basic Pydev doesn't have these popups. Rich From bernie at codewiz.org Tue Jun 2 11:48:47 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Tue, 02 Jun 2009 13:48:47 +0200 Subject: Unbootable machine In-Reply-To: <4A24B44D.3070607@zytor.com> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> <4A247506.4000304@codewiz.org> <4A2483C8.7090706@zytor.com> <4A249C12.2060708@codewiz.org> <4A24B44D.3070607@zytor.com> Message-ID: <4A25119F.9010909@codewiz.org> On 06/02/09 07:10, H. Peter Anvin wrote: > Bernie Innocenti wrote: >> Ok, I wiped mbr and made fdisk create a new one: >> >> Disk /dev/sdb: 2055 MB, 2055208960 bytes >> 64 heads, 62 sectors/track, 1011 cylinders > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Equally weird. The only "standard" ones are 64 heads, 32 sectors and > 255 heads, 63 sectors. Shouldn't fdisk guess these values automagically? And, more importantly, who are we going to blame if it doesn't? ;-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From bernie at codewiz.org Tue Jun 2 11:58:02 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Tue, 02 Jun 2009 13:58:02 +0200 Subject: Unbootable machine In-Reply-To: <4A25119F.9010909@codewiz.org> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> <4A247506.4000304@codewiz.org> <4A2483C8.7090706@zytor.com> <4A249C12.2060708@codewiz.org> <4A24B44D.3070607@zytor.com> <4A25119F.9010909@codewiz.org> Message-ID: <4A2513CA.1070703@codewiz.org> On 06/02/09 13:48, Bernie Innocenti wrote: > On 06/02/09 07:10, H. Peter Anvin wrote: >> Bernie Innocenti wrote: >>> Ok, I wiped mbr and made fdisk create a new one: >>> >>> Disk /dev/sdb: 2055 MB, 2055208960 bytes >>> 64 heads, 62 sectors/track, 1011 cylinders >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Equally weird. The only "standard" ones are 64 heads, 32 sectors and >> 255 heads, 63 sectors. > > Shouldn't fdisk guess these values automagically? > And, more importantly, who are we going to blame if it doesn't? ;-) For the record, GNU parted gets it right: bernie at giskard:~$ sudo dd if=/dev/zero of=/dev/sdb ^C5017+0 records in 5017+0 records out 2568704 bytes (2.6 MB) copied, 1.63415 s, 1.6 MB/s 130!bernie at giskard:~$ sudo parted /dev/sdb GNU Parted 1.8.8 Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mklabel New disk label type? msdos (parted) unit chs (parted) print Model: USB DISK 2.0 (scsi) Disk /dev/sdb: 249,220,34 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 249,255,63. Each cylinder is 8225kB. Partition Table: msdos Number Start End Type File system Flags (parted) mkpart File system type? [ext2]? fat32 Start? 0 End? 100% Warning: You requested a partition from 0,0,0 to 249,220,34. The closest location we can manage is 0,1,0 to 248,254,62. Is this still acceptable to you? Yes/No? y (parted) p Model: USB DISK 2.0 (scsi) Disk /dev/sdb: 249,220,34 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 249,255,63. Each cylinder is 8225kB. Partition Table: msdos Number Start End Type File system Flags 1 0,1,0 248,254,62 primary lba -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From guido.grazioli at gmail.com Tue Jun 2 12:36:57 2009 From: guido.grazioli at gmail.com (Guido) Date: Tue, 2 Jun 2009 14:36:57 +0200 Subject: awesfx package reinclusion Message-ID: <2f984ea00906020536q7c0b11cav2091ac69429e7916@mail.gmail.com> Hello i'm new to this list; i submitted a new review request: https://bugzilla.redhat.com/show_bug.cgi?id=490061 in order to re-include the awesfx package which was retired on apr 2008: http://fedoraproject.org/wiki/PackageMaintainers/RetiredPackages Could someone give me some hints on the procedure? Should i reverse actions described here: http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife or treat the package as a new one? thanks -- Guido Grazioli Via Parri 11 48011 - Alfonsine (RA) Mobile: +39 347 1017202 (10-18) Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278 Linked in: http://www.linkedin.com/in/guidograzioli -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnowak at redhat.com Tue Jun 2 12:59:25 2009 From: mnowak at redhat.com (Michal Nowak) Date: Tue, 2 Jun 2009 08:59:25 -0400 (EDT) Subject: Orphaned eclipse-pydev In-Reply-To: <1376895032.3814491243947424165.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <642002966.3814801243947565483.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> ----- "Richard Fearn" wrote: > >> Isn't that this application with ads in it? > > > > Mmm, not aware of any... Not sure what you meant. > > If you use the evaluation version of Pydev Extensions (a different > plugin to Pydev), it reminds you every so often to buy the full > version. See: > > http://fabioz.com/pydev/ > > The basic Pydev doesn't have these popups. > > Rich I see. Well, we use Pydev from SF.net [1] and no Pydev Extensions [2], so, no ads in Fedora. Michal -- [1] http://pydev.sourceforge.net/ [2] http://fabioz.com/pydev/ From hpa at zytor.com Tue Jun 2 13:45:58 2009 From: hpa at zytor.com (H. Peter Anvin) Date: Tue, 02 Jun 2009 06:45:58 -0700 Subject: Unbootable machine In-Reply-To: <4A25119F.9010909@codewiz.org> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> <4A247506.4000304@codewiz.org> <4A2483C8.7090706@zytor.com> <4A249C12.2060708@codewiz.org> <4A24B44D.3070607@zytor.com> <4A25119F.9010909@codewiz.org> Message-ID: <4A252D16.5090001@zytor.com> Bernie Innocenti wrote: >> >> Equally weird. The only "standard" ones are 64 heads, 32 sectors and >> 255 heads, 63 sectors. > > Shouldn't fdisk guess these values automagically? > And, more importantly, who are we going to blame if it doesn't? ;-) > I don't know. It might be an fdisk issue; Linux fdisk has *always* behaved in this way, but I haven't looked at that code at all. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. From hpa at zytor.com Tue Jun 2 13:49:43 2009 From: hpa at zytor.com (H. Peter Anvin) Date: Tue, 02 Jun 2009 06:49:43 -0700 Subject: [Sugar-devel] Unbootable machine In-Reply-To: <20090602072641.GC10710@jones.dk> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> <4A247506.4000304@codewiz.org> <20090602072641.GC10710@jones.dk> Message-ID: <4A252DF7.9000001@zytor.com> Jonas Smedegaard wrote: >> >>> Also look for how you have configured your BIOS... some Award BIOSes >>> have USB-ZIP, USB-HDD, USB-FDD configurations; you generally want USB-HDD. > > In my (older non-Sugar) experience, USB-HDD is best, then USB-ZIP, and > if none of those options are available then pick USB-FDD (which is then > most likely names something else). > This is absolutely the order of preference. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. From jspaleta at gmail.com Tue Jun 2 16:28:01 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 2 Jun 2009 08:28:01 -0800 Subject: Fedora Bugzilla Statistics 2009-05-26 - 2009-06-01 In-Reply-To: <981da310906020032o62dacc76u9a0d0a501f3e9f04@mail.gmail.com> References: <981da310906020032o62dacc76u9a0d0a501f3e9f04@mail.gmail.com> Message-ID: <604aa7910906020928g19880684u68e2f47838c7abe5@mail.gmail.com> On Mon, Jun 1, 2009 at 11:32 PM, Brennan Ashton wrote: > There is much more information that can be pulled via a turbogrears > app we are running. ?But I am looking to see what is useful in terms > of a weekly report. ?I have the date tuesday to tuesday as it matches > up with the Bugzappers meeting time. Are you geared up for component by component reporting or perhaps groups of components? How do triagers currently organize their time when picking components? Would component-by-component reporting help spread/grow triage manpower into hot spot areas of the repository? And the flipside, can you visualize how triage manpower is actually spread through the repository currently? Are our expert smoke jumpers landing near the hotspots without a lot of coordinated effort? or is triage being done mostly by maintainers, fighting the local fires in their back yards? And in the future I'd like to see weekly reporting feature by feature that gives a sense of progress on bugs loosely associated with a feature proposal. Can we visualize the effect that feature specific test days have on the bug lifecycle for that feature? Also reporting on tracking the aggregate progress on tracker/blocker bugs for the next release. Can you highlight work or drive interest in working on release target and blocker bugs in some way in the reporting? . -jef"Saw my first smoke jumpers in action like a mile away from me last weekend...hence the imagery"spaleta From dan at danny.cz Tue Jun 2 16:41:49 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Tue, 02 Jun 2009 18:41:49 +0200 Subject: access to a ppc64 machine for bigloo's upstream Message-ID: <1243960909.3755.115.camel@eagle.danny.cz> Hi, is here anybody that could give access to a ppc64 machine to bigloo's upstream? The builds of bigloo on ppc64 (and s390x) gets stuck and they are willing to debug/fix it, but need a ppc64 machine. their homepage is http://www-sop.inria.fr/mimosa/fp/Bigloo/ failing builds https://koji.fedoraproject.org/koji/taskinfo?taskID=1389648 (internal copy of gc) https://koji.fedoraproject.org/koji/taskinfo?taskID=1389647 (using packaged gc) thread on upstream mailing list http://thread.gmane.org/gmane.lisp.scheme.bigloo/4289 Thanks Dan From rawhide at fedoraproject.org Tue Jun 2 16:43:14 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 2 Jun 2009 16:43:14 +0000 (UTC) Subject: rawhide report: 20090602 changes Message-ID: <20090602164314.F0FAE1F8216@releng2.fedora.phx.redhat.com> Compose started at Tue Jun 2 06:15:08 UTC 2009 Updated Packages: anaconda-11.5.0.58-1.fc11 ------------------------- * Sun May 31 2009 David Lehman - 11.5.0.58-1 - Pass --force to lvresize so it doesn't ask for confirmation. (dlehman) - Fix a typo in action sorting for resize actions (fs vs. device). (#501000) (dlehman) - Sending translation for French (mrtom) mkinitrd-6.0.86-2.fc11 ---------------------- * Fri May 29 2009 Peter Jones - 6.0.86-2 - Require "kbd" package so keyboard settings will work right after initial installation. (#501584) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 2 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From awilliam at redhat.com Tue Jun 2 16:53:24 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 02 Jun 2009 09:53:24 -0700 Subject: Fedora Bugzilla Statistics 2009-05-26 - 2009-06-01 In-Reply-To: <604aa7910906020928g19880684u68e2f47838c7abe5@mail.gmail.com> References: <981da310906020032o62dacc76u9a0d0a501f3e9f04@mail.gmail.com> <604aa7910906020928g19880684u68e2f47838c7abe5@mail.gmail.com> Message-ID: <1243961604.2937.298.camel@adam.local.net> On Tue, 2009-06-02 at 08:28 -0800, Jeff Spaleta wrote: > On Mon, Jun 1, 2009 at 11:32 PM, Brennan Ashton > wrote: > > There is much more information that can be pulled via a turbogrears > > app we are running. But I am looking to see what is useful in terms > > of a weekly report. I have the date tuesday to tuesday as it matches > > up with the Bugzappers meeting time. > > Are you geared up for component by component reporting or perhaps > groups of components? Yes, we can do this. > How do triagers currently organize their time > when picking components? We have a page: https://fedoraproject.org/wiki/BugZappers/Components_and_Triagers which lists what we consider the most important components (they're basically the ones for which the most reports are filed). Triagers are encouraged to specialize in one or a few of these components, in order that they will have a good knowledge base for the issues they're triaging and won't just be doing 'drive-by triaging' of bugs they don't really understand. > Would component-by-component reporting help > spread/grow triage manpower into hot spot areas of the repository? It could do, but on the other hand, we're mostly getting to the point where the components that lack coverage are ones which need a triager who's already knowledgeable about that component: we can't just parachute someone in. (see e.g. anaconda and kernel). > And the flipside, can you visualize how triage manpower is actually > spread through the repository currently? Are our expert smoke jumpers > landing near the hotspots without a lot of coordinated effort? or is > triage being done mostly by maintainers, fighting the local fires in > their back yards? I'll leave this one mostly to Brennan, but I think the position is that we don't currently have a report that tracks this really well, but it could be done. > And in the future I'd like to see weekly reporting feature by feature > that gives a sense of progress on bugs loosely associated with a > feature proposal. Can we visualize the effect that feature specific > test days have on the bug lifecycle for that feature? It may be hard to use this system to specifically track test day-related bugs with any detail. James Laska and I are interested in doing better statistical tracking of the impact of test days; I did some preliminary stuff on this for the graphics test days for F11, we will try and do this in a more organized way, for more test days, for F12. > Also reporting on tracking the aggregate progress on tracker/blocker > bugs for the next release. Can you highlight work or drive interest > in working on release target and blocker bugs in some way in the > reporting? For the F12 cycle we should have the new severity assessment process in place, so we should be able to generate some numbers which take the severity rating of the bugs assigned by the Bugzappers team into account. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From jspaleta at gmail.com Tue Jun 2 17:08:28 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 2 Jun 2009 09:08:28 -0800 Subject: Fedora Bugzilla Statistics 2009-05-26 - 2009-06-01 In-Reply-To: <1243961604.2937.298.camel@adam.local.net> References: <981da310906020032o62dacc76u9a0d0a501f3e9f04@mail.gmail.com> <604aa7910906020928g19880684u68e2f47838c7abe5@mail.gmail.com> <1243961604.2937.298.camel@adam.local.net> Message-ID: <604aa7910906021008m31b79e60n9024986c0f413117@mail.gmail.com> On Tue, Jun 2, 2009 at 8:53 AM, Adam Williamson wrote: > It could do, but on the other hand, we're mostly getting to the point > where the components that lack coverage are ones which need a triager > who's already knowledgeable about that component: we can't just > parachute someone in. (see e.g. anaconda and kernel). How short is that list of components? Can you visualize that? Just identifying that finite list could help motivate exactly that sort of recruitment effort needed to fill the need. If we identify the short list accurately, can we then advertise the short list as a rewarding challenge to undertake? Our very own elite highly trained specialists..our 00's..our A-team. So highly prized they even get codenames and catch phrases. -jef From jwboyer at gmail.com Tue Jun 2 17:17:21 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 2 Jun 2009 13:17:21 -0400 Subject: access to a ppc64 machine for bigloo's upstream In-Reply-To: <1243960909.3755.115.camel@eagle.danny.cz> References: <1243960909.3755.115.camel@eagle.danny.cz> Message-ID: <20090602171721.GK3095@hansolo.jdub.homelinux.org> On Tue, Jun 02, 2009 at 06:41:49PM +0200, Dan Hor?k wrote: >Hi, > >is here anybody that could give access to a ppc64 machine to bigloo's >upstream? The builds of bigloo on ppc64 (and s390x) gets stuck and they >are willing to debug/fix it, but need a ppc64 machine. Email me an ssh pubkey and your preferred login and I'll give you an account on my G5 running rawhide josh From dan at danny.cz Tue Jun 2 17:44:50 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Tue, 02 Jun 2009 19:44:50 +0200 Subject: access to a ppc64 machine for bigloo's upstream In-Reply-To: <20090602171721.GK3095@hansolo.jdub.homelinux.org> References: <1243960909.3755.115.camel@eagle.danny.cz> <20090602171721.GK3095@hansolo.jdub.homelinux.org> Message-ID: <1243964690.3755.136.camel@eagle.danny.cz> Josh Boyer p??e v ?t 02. 06. 2009 v 13:17 -0400: > On Tue, Jun 02, 2009 at 06:41:49PM +0200, Dan Hor?k wrote: > >Hi, > > > >is here anybody that could give access to a ppc64 machine to bigloo's > >upstream? The builds of bigloo on ppc64 (and s390x) gets stuck and they > >are willing to debug/fix it, but need a ppc64 machine. > > Email me an ssh pubkey and your preferred login and I'll give you an account > on my G5 running rawhide Thanks, information forwarded. Dan From awilliam at redhat.com Tue Jun 2 18:14:57 2009 From: awilliam at redhat.com (Adam Williamson) Date: Tue, 02 Jun 2009 11:14:57 -0700 Subject: Fedora Bugzilla Statistics 2009-05-26 - 2009-06-01 In-Reply-To: <604aa7910906021008m31b79e60n9024986c0f413117@mail.gmail.com> References: <981da310906020032o62dacc76u9a0d0a501f3e9f04@mail.gmail.com> <604aa7910906020928g19880684u68e2f47838c7abe5@mail.gmail.com> <1243961604.2937.298.camel@adam.local.net> <604aa7910906021008m31b79e60n9024986c0f413117@mail.gmail.com> Message-ID: <1243966497.2937.310.camel@adam.local.net> On Tue, 2009-06-02 at 09:08 -0800, Jeff Spaleta wrote: > On Tue, Jun 2, 2009 at 8:53 AM, Adam Williamson wrote: > > It could do, but on the other hand, we're mostly getting to the point > > where the components that lack coverage are ones which need a triager > > who's already knowledgeable about that component: we can't just > > parachute someone in. (see e.g. anaconda and kernel). > > How short is that list of components? Can you visualize that? Just > identifying that finite list could help motivate exactly that sort of > recruitment effort needed to fill the need. If we identify the short > list accurately, can we then advertise the short list as a rewarding > challenge to undertake? Our very own elite highly trained > specialists..our 00's..our A-team. So highly prized they even get > codenames and catch phrases. Anything on the Components and Triagers page where there's no-one under "Active Triagers". :) (oh, and "Need help?" is not set to No). Currently that list is: PackageKit firstboot gdm glibc gtk2 mkinitrd upstart as I said, these are bits that you kinda need decent expertise on to be able to triage properly. PackageKit might be the lowest-hanging fruit on that list. you can add: pulseaudio anaconda kernel each of these currently isn't really being triaged by any triagers. Lennart is happy to have triage for PA, but only from someone who already knows what they're talking about when it comes to PA in quite some detail (which is quite a small pool). I'm currently working with the anaconda / kernel folks to see what we can do about setting down the requirements for triage for those components. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From fedora at leemhuis.info Tue Jun 2 19:09:24 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 02 Jun 2009 21:09:24 +0200 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1243880066.29188.20.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> Message-ID: <4A2578E4.3090808@leemhuis.info> On 01.06.2009 20:14, Jesse Keating wrote: > On Mon, 2009-06-01 at 19:49 +0200, Thorsten Leemhuis wrote: >> On 29.05.2009 22:57, Jesse Keating wrote: Thx for your reply and sorry, I didn't found time to answer earlier. Some more comments: [...] >> - how about reducing the number or zero day updates (which is ridiculous >> high for F11) by setting a different, later freeze date for all packages >> that are neither on the install DVD or on a Spin? > That's a bit hard to determine easily and programaticaly. I've all but > given up on my quest to reduce the number of updates. Just a general comment, not relevant for the "Announcing Fedora Activity Day". I'm glad that you gave up that quest, as "Fedora gets lot's of updates" is afaics a reason why a lot people actually use or contribute to Fedora. But that doesn't matter much. What I really want to say: I totally agree with this: > It's just doesn't > seem to be in line with the desires of the package maintainers, whether > or not it's in line with the desires of (some of) the project leaders. It IMHO shows a big and more and more pressing problem in Fedora: Packagers and leadership are not working towards the same direction. Anyway, back to topic: >> - other distributions seems to manage a whole lot more test releases >> (e.g. alphas, beta, RC, milestones, ...) per devel cycle; is that >> something we should aim for as well? > If there was a way to do it without adding stress and work needed to > teams like releng, installer, etc.. [...] One comment: *from a outside* it often looks a bit like - some (not all) people go crazy for weeks or months and ignore some of those bugs that are not pressing, but nevertheless pressing (e.g. kind of bugs that tend to land on target or blocker tracker bugs or already are there) - then you send a reminder "there will be a a test release next week" - people suddenly wake up and try to fix those bugs for the test release - they notice: arghh, serious things are broken, we need more time; can we please slip? - we slip Maybe more target dates where people should "get things into shape" might help to reduce the work for the real test/final releases. >> - how about doing something like a "cp -l development devel-snapshot" >> now and then (once a week) when we know rawhide is mostly working? > The rawhide trees for at least the past month are kept in the Fedora > infrastructure and are even available by a public url. We haven't > tagged any of them as "stable" though. They are afaics way to far away/way to slow to reach to do a proper network install in an acceptable period of time (at least from Germany). Is rsync available -- I'm not aware of it, so I doubt it? >> - how can we reduce our time between finishing a (test) release and >> releasing it dramatically? It seems other distributions get new (test) >> release out to the users a lot quicker then the three to five days days >> we require, which seems a whole lot for a devel cycle that takes 180 >> days in total (and we all know how much rawhide can move on with a few days) > If we didn't care to let the mirrors sync up we could "release" it > earlier. However what good does that do when nobody can /get/ to the > release because none of the mirrors have it, and the ones that do can't > help sync to those that don't because users are tying up all the > bandwidth? I didn't say to not care. But maybe shorten the time we wait for them and help to get the bits out more quickly; pushing users to use bittorrent more might help a lot as well. >> - I'd be glad if we could stick to our release targets a lot better. >> Delaying releases looks quite unprofessional. Delaying also creates >> trouble for those depending on our releases. Take computer magazines >> (which have hard deadlines for productions) that might want to ship with >> a new release on a CD or DVD together with the next issue -- due to our >> fame in missing deadlines it seems to me that we are a lot more >> unattractive than Ubuntu (which afaics is on the shelf's here in Germany >> with new computer magazines just a few days after it has been released) > What looks more unprofessional? Delaying the release, or hitting our > date and releasing with bugs that eat people's data? Or releasing with > broken graphics for large swaths of users? I think you drifted a bit way to far away and into a opposition without need. I for example nowhere said that we should not slip if there is a strong reason to. But my comment was quite open, so it's partly my fault; so let me rephrase: What is rel-eng doing in the next devel cycle to make sure we slip less then we used to in the past? Or does rel-eng think everything was fine and missing three and a half target dates (alpha, beta, release and the first slipped release target date) out of four is acceptable? >> - why do we have to slip by a whole week most of the time? can't we find >> ways to slip just a day or two if there really is no way around a delay? > The marketing machine has very strongly requested that we only do > releases on Tuesdays. Some reasons why Tuesdays are "must" instead of "good" would be way more helpful then a simple statement "they said so". So all I can say is: Yes, let's target Tuesdays if that is idea (which I agree), but if there is a slip then slip only a day, two or three if the problem can be fixed within that timeframe (which for example was not the case for the first release slip for the final, but maybe for the second). > [...] >> - I'd be glad if the final release directories (e.g. >> release/12/Everything" could be available earlier, even if what is in >> them is not yet what "12" actually will become > You'll have to enumerate why that is. Kevin outlined some of the reasons already in a reply: https://www.redhat.com/archives/fedora-devel-list/2009-June/msg00073.html > One reason I've avoided this is > added confusion as to when the "release" happens. If we created that > directory and put content in there, would we have then released Fedora > 12? When does it become "released" and thus trusted? As Kevin said as well: It seems to work quite well for Ubuntu and actually avoids a lot of confusion. I'd say their scheme even works better then our scheme. I'd also think most "normal" users don't ever look on the servers. BTW, one more general thing for the FAD: Would it make sense to make rawhide updates more than once a day in case something that bugs lot's of people can be fixed easily by a quick update? CU knurd From fedora at leemhuis.info Tue Jun 2 19:12:58 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 02 Jun 2009 21:12:58 +0200 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1243885856.2937.271.camel@adam.local.net> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243885856.2937.271.camel@adam.local.net> Message-ID: <4A2579BA.2070207@leemhuis.info> On 01.06.2009 21:50, Adam Williamson wrote: > On Mon, 2009-06-01 at 19:49 +0200, Thorsten Leemhuis wrote: >> - should we set an way earlier freezes date for things like anaconda, >> kernel, isolinux, grub and other crucial pieces to make sure they are >> in >> better shape a bit earlier and thus are less likely a reason for >> release >> slips? > If you're basing this off the F11 cycle, it's worth noting that kernel > and anaconda have not been 'reasons for release slips' in this cycle in > that late changes were made to them which turned out to be bad ideas. I know, but: > It > was simply that there were bugs in them all along which were critical > enough to block the release. An earlier freeze date would not have > helped at all. It might have helped to find the problem earlier -- I for example got the impression that a lot of people had problems with the storage rewrite and thus aborted their tests with Alpha or Beta. CU knurd From fedora at leemhuis.info Tue Jun 2 19:30:17 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 02 Jun 2009 21:30:17 +0200 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <20090601222217.GA31066@auslistsprd01.us.dell.com> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> Message-ID: <4A257DC9.5090703@leemhuis.info> On 02.06.2009 00:22, Matt Domsch wrote: > On Mon, Jun 01, 2009 at 04:03:04PM -0400, Paul W. Frields wrote: >> I'm getting out of my ken here, but could this be done in stages with >> I2 connected hosts getting the bits early/first and then moving on to >> others? > We need to move ~130GB to each of ~230 mirrors, in about 4 > days. I'd like to question these numbers. All the SRPMS (18 GByte) and RPMS (20 GByte per arch) of a new release are in the rawhide trees already -- thus if they are hardlinked properly then they can be transferred in a minute or two. The install CD and DVD images (~ 8 GByte each per arch?) are bigger, but if we get RC with the final name transferred to the mirrors ahead of time then they can be updated relative quickly as well, as only a few bit change. The spins that get compressed are a problem. But we only send Desktop and KDE spins to the mirrors for x86-32 and x86-64 afaics -- so roughly 3 GByte in total. So 3 GByte + some other random stuff that changed -- install.img, boot.iso, and some other things. Not sure how much that will sum up to, but can't sum up to that much -- maybe 3 or 5 more GByte. Let's say it are 10 GBtyte. It afaics shouldn't take more then a day if all mirrors look out for new stuff at least every 4 hours and have a link that isn't slow by todays standards. Or what am I missing? Cu knurd From bjorn at xn--rombobjrn-67a.se Tue Jun 2 20:01:24 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Tue, 2 Jun 2009 22:01:24 +0200 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1243912770.29188.50.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <20090602015639.GA30712@wolff.to> <1243912770.29188.50.camel@localhost.localdomain> Message-ID: <200906022201.38401.bjorn@xn--rombobjrn-67a.se> Jesse Keating wrote: > On Mon, 2009-06-01 at 20:56 -0500, Bruno Wolff III wrote: > > Do you hard link the new release files to the ones identical in rawhide > > so that rsync doesn't have to transfer them to places mirroring rawhide? > > Yes and no. We do use hardlinks, however the mechanism that gets it > from PHX to Raleigh is Netapp snapmirror, which works at the block > level. I don't know enough about snapmirror to know if it is helped by > hardlinks or not. The individual files aren't the real problem, it's > the isos, particularly the live isos. A program similar to Jigdo could speed this up. Transfer only the RPM packages (taking advantage of hard links) and information on what packages are in each ISO image, and then recreate the ISO images at the destination. That way each package would only be transferred once, regardless of how many ISO images it occurs in. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From mw_triad at users.sourceforge.net Tue Jun 2 20:02:13 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 02 Jun 2009 15:02:13 -0500 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <20090601222217.GA31066@auslistsprd01.us.dell.com> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> Message-ID: Matt Domsch wrote: > On Mon, Jun 01, 2009 at 04:03:04PM -0400, Paul W. Frields wrote: >> I'm getting out of my ken here, but could this be done in stages with >> I2 connected hosts getting the bits early/first and then moving on to >> others? > > We need to move ~130GB to each of ~230 mirrors, in about 4 > days. > > We already have in place a limited amount of "tiering". The Tier 0/1 > mirrors get the bits first, then downstream mirrors pull from them. > We have nearly all our "Tier 1" mirrors on I2 (all but the > us.kernel.org). Right now it's not mandatory, but no "new" mirrors > (those signed up in the last 18 months or so) have been granted ACL > permissions to download from the masters. > > http://fedoraproject.org/wiki/Infrastructure/Mirroring/Tiering > > One of my hopes for the F12 cycle is that we will have increased use > of tiering and push mirroring. What about dropping hierarchical mirroring altogether? Why hasn't someone developed a distributed (i.e. bittorrent-like) system for mass mirroring? :-) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Congratulations! You've won a free trip to the future! All you have to do to claim your prize is wait five minutes... From maxamillion at gmail.com Tue Jun 2 20:05:25 2009 From: maxamillion at gmail.com (Adam Miller) Date: Tue, 2 Jun 2009 15:05:25 -0500 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> Message-ID: On Tue, Jun 2, 2009 at 3:02 PM, Matthew Woehlke wrote: > Matt Domsch wrote: > > What about dropping hierarchical mirroring altogether? Why hasn't someone > developed a distributed (i.e. bittorrent-like) system for mass mirroring? > :-) > > -- > Matthew > Please do not quote my e-mail address unobfuscated in message bodies. > -- > Congratulations! You've won a free trip to the future! All you have to do to > claim your prize is wait five minutes... > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Why not? Might be an interesting idea to pursue. -Adam -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From mike at cchtml.com Tue Jun 2 20:13:14 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Tue, 02 Jun 2009 15:13:14 -0500 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <200906022201.38401.bjorn@xn--rombobjrn-67a.se> References: <1243630631.3037.149.camel@localhost.localdomain> <20090602015639.GA30712@wolff.to> <1243912770.29188.50.camel@localhost.localdomain> <200906022201.38401.bjorn@xn--rombobjrn-67a.se> Message-ID: <4A2587DA.6070300@cchtml.com> Bj?rn Persson wrote: > > A program similar to Jigdo could speed this up. Transfer only the RPM packages > (taking advantage of hard links) and information on what packages are in each > ISO image, and then recreate the ISO images at the destination. That way each > package would only be transferred once, regardless of how many ISO images it > occurs in. > Jigdo doesn't work in Fedora unless you want to implement a self-compiling jigdo creator. Why? 'Cause old Fedora updates are not kept on mirrors. A Jigdo file you create today may not work next week. Bad, bad, bad. k? From Matt_Domsch at dell.com Tue Jun 2 20:14:47 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 2 Jun 2009 15:14:47 -0500 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <4A257DC9.5090703@leemhuis.info> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <4A257DC9.5090703@leemhuis.info> Message-ID: <20090602201447.GA9836@auslistsprd01.us.dell.com> On Tue, Jun 02, 2009 at 09:30:17PM +0200, Thorsten Leemhuis wrote: > On 02.06.2009 00:22, Matt Domsch wrote: > > On Mon, Jun 01, 2009 at 04:03:04PM -0400, Paul W. Frields wrote: > >> I'm getting out of my ken here, but could this be done in stages with > >> I2 connected hosts getting the bits early/first and then moving on to > >> others? > > We need to move ~130GB to each of ~230 mirrors, in about 4 > > days. The 130GB is what we posted for F10. Of that, 48GB were ISOs, 93GB was the Everything/ tree which was hardlinked from rawhide, so yes, that would cut down on the transfer quite a bit. Honestly, I don't recall how the signing aspect went for F10. If the process involved signing, then copying the packages into the Everything tree, then there wouldn't be hardlinks to help. > I'd like to question these numbers. All the SRPMS (18 GByte) and RPMS > (20 GByte per arch) of a new release are in the rawhide trees already -- > thus if they are hardlinked properly then they can be transferred in a > minute or two. The install CD and DVD images (~ 8 GByte each per arch?) > are bigger, but if we get RC with the final name transferred to the > mirrors ahead of time then they can be updated relative quickly as well, > as only a few bit change. RCs with the final name haven't been posted for the mirrors ahead of time, yet. We could consider it for F12 though. > The spins that get compressed are a problem. But we only send Desktop > and KDE spins to the mirrors for x86-32 and x86-64 afaics -- so roughly > 3 GByte in total. Right. > So 3 GByte + some other random stuff that changed -- install.img, > boot.iso, and some other things. Not sure how much that will sum up to, > but can't sum up to that much -- maybe 3 or 5 more GByte. > > Let's say it are 10 GBtyte. It afaics shouldn't take more then a day if > all mirrors look out for new stuff at least every 4 hours and have a > link that isn't slow by todays standards. > > Or what am I missing? I think you're right, except that RC ISOs aren't published ahead of time for mirrors to sync, and signing of the RPMs that land in the Everything tree if they weren't signed, or were signed with a different key. I believe the signing process has changed for F11, so the packages in rawhide are signed with the F11 release key. I think that means at some point, either through a mass rebuild, or through a resigning, rawhide will then need to be re-signed with the F12 key. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mike at cchtml.com Tue Jun 2 20:16:02 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Tue, 02 Jun 2009 15:16:02 -0500 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> Message-ID: <4A258882.50001@cchtml.com> Matthew Woehlke wrote: > > What about dropping hierarchical mirroring altogether? Why hasn't > someone developed a distributed (i.e. bittorrent-like) system for mass > mirroring? :-) > Already discussed[1][2] on the fedora-test-list. [1] https://www.redhat.com/archives/fedora-test-list/2009-June/msg00032.html [2] https://www.redhat.com/archives/fedora-test-list/2009-June/msg00062.html From sgrubb at redhat.com Tue Jun 2 20:17:12 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 2 Jun 2009 16:17:12 -0400 Subject: Maintainer Responsibilities Message-ID: <200906021617.12122.sgrubb@redhat.com> Hello, I don't want to start a long thread, but just to ask a couple questions for my own clarification. Does a maintainer's responsibilities end with packaging bugs? IOW, if there is a problem in the package that is _broken code_ do they need to do something about it or is it acceptable for them to close the bug and say talk to upstream? Do we want those bugs open to track when the bug is fixed in the distro? I'll accept whatever the answer is, I'm just curious. Thanks, -Steve From limb at jcomserv.net Tue Jun 2 20:26:18 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 02 Jun 2009 15:26:18 -0500 Subject: Maintainer Responsibilities In-Reply-To: <200906021617.12122.sgrubb@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> Message-ID: <4A258AEA.6090602@jcomserv.net> Steve Grubb wrote: > Hello, > > I don't want to start a long thread, but just to ask a couple questions for my > own clarification. Does a maintainer's responsibilities end with packaging > bugs? IOW, if there is a problem in the package that is _broken code_ do they > need to do something about it or is it acceptable for them to close the bug > and say talk to upstream? Do we want those bugs open to track when the bug is > fixed in the distro? I'll accept whatever the answer is, I'm just curious. > > Thanks, > -Steve > > Not sure what's documented, but I consider it my responsibility to either patch and send it upstream, or document my pesterings of upstream in the BZ and keep it open. See https://bugzilla.redhat.com/show_bug.cgi?id=478634 -J -- in your fear, speak only peace in your fear, seek only love -d. bowie From jkeating at redhat.com Tue Jun 2 20:30:23 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 02 Jun 2009 13:30:23 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <4A257DC9.5090703@leemhuis.info> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <4A257DC9.5090703@leemhuis.info> Message-ID: <1243974623.29188.84.camel@localhost.localdomain> On Tue, 2009-06-02 at 21:30 +0200, Thorsten Leemhuis wrote: > but if we get RC with the final name transferred to the > mirrors ahead of time then they can be updated relative quickly as well, > as only a few bit change. We don't do this as it tends to lead to leaks, and confusion as to whether the release has been done or not. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Jun 2 20:46:29 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 02 Jun 2009 13:46:29 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <4A2579BA.2070207@leemhuis.info> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243885856.2937.271.camel@adam.local.net> <4A2579BA.2070207@leemhuis.info> Message-ID: <1243975589.29188.100.camel@localhost.localdomain> On Tue, 2009-06-02 at 21:12 +0200, Thorsten Leemhuis wrote: > It might have helped to find the problem earlier -- I for example got > the impression that a lot of people had problems with the storage > rewrite and thus aborted their tests with Alpha or Beta. > An earlier freeze would have just frozen the work unfinished. The rewrite was a massive undertaking and we knew it was going to take longer than the release cycle to finish. Freezing earlier wouldn't have helped. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Jun 2 20:49:19 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 02 Jun 2009 13:49:19 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <4A2578E4.3090808@leemhuis.info> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> Message-ID: <1243975759.29188.104.camel@localhost.localdomain> On Tue, 2009-06-02 at 21:09 +0200, Thorsten Leemhuis wrote: > Just a general comment, not relevant for the "Announcing Fedora Activity > Day". I'm glad that you gave up that quest, as "Fedora gets lot's of > updates" is afaics a reason why a lot people actually use or contribute > to Fedora. But that doesn't matter much. What I really want to say: > > I totally agree with this: > > > It's just doesn't > > seem to be in line with the desires of the package maintainers, whether > > or not it's in line with the desires of (some of) the project leaders. > > It IMHO shows a big and more and more pressing problem in Fedora: > Packagers and leadership are not working towards the same direction. Yes, that is a problem. In other projects, the contributions from folks who don't agree with where the project leaders are trying to take the project are often rejected or ignored. That isn't happening here, which is a good thing I suppose, but it is a point of contention that will have to be addressed. > > Anyway, back to topic: > > >> - other distributions seems to manage a whole lot more test releases > >> (e.g. alphas, beta, RC, milestones, ...) per devel cycle; is that > >> something we should aim for as well? > > If there was a way to do it without adding stress and work needed to > > teams like releng, installer, etc.. [...] > > One comment: *from a outside* it often looks a bit like > - some (not all) people go crazy for weeks or months and ignore some of > those bugs that are not pressing, but nevertheless pressing (e.g. kind > of bugs that tend to land on target or blocker tracker bugs or already > are there) > - then you send a reminder "there will be a a test release next week" > - people suddenly wake up and try to fix those bugs for the test release > - they notice: arghh, serious things are broken, we need more time; can > we please slip? > - we slip > > Maybe more target dates where people should "get things into shape" > might help to reduce the work for the real test/final releases. Yeah, I can see how that would be the case from the outside. From the inside, the more freeze points we have, the more times work in progress has to be stifled and beat into some sort of working shape, even if it's nothing like what the final product goal is, which results in a lot of wasted effort and testing which gets thrown out as development continues and changes everything that was "tested" earlier. > >> - how about doing something like a "cp -l development devel-snapshot" > >> now and then (once a week) when we know rawhide is mostly working? > > The rawhide trees for at least the past month are kept in the Fedora > > infrastructure and are even available by a public url. We haven't > > tagged any of them as "stable" though. > > They are afaics way to far away/way to slow to reach to do a proper > network install in an acceptable period of time (at least from Germany). > Is rsync available -- I'm not aware of it, so I doubt it? No, but the most important part of these are the boot.iso which has the anaconda and other code that anaconda needs. The repository that you point the boot.iso at to install packages matters a lot less at least so far as "completing the install". > >> - how can we reduce our time between finishing a (test) release and > >> releasing it dramatically? It seems other distributions get new (test) > >> release out to the users a lot quicker then the three to five days days > >> we require, which seems a whole lot for a devel cycle that takes 180 > >> days in total (and we all know how much rawhide can move on with a few days) > > If we didn't care to let the mirrors sync up we could "release" it > > earlier. However what good does that do when nobody can /get/ to the > > release because none of the mirrors have it, and the ones that do can't > > help sync to those that don't because users are tying up all the > > bandwidth? > > I didn't say to not care. But maybe shorten the time we wait for them > and help to get the bits out more quickly; pushing users to use > bittorrent more might help a lot as well. I honestly feel that trying to shorten the length will only lead to mistakes. We're short as it is, nearly too short, with extremely little time to recover from a mistake without slipping. > > >> - I'd be glad if we could stick to our release targets a lot better. > >> Delaying releases looks quite unprofessional. Delaying also creates > >> trouble for those depending on our releases. Take computer magazines > >> (which have hard deadlines for productions) that might want to ship with > >> a new release on a CD or DVD together with the next issue -- due to our > >> fame in missing deadlines it seems to me that we are a lot more > >> unattractive than Ubuntu (which afaics is on the shelf's here in Germany > >> with new computer magazines just a few days after it has been released) > > What looks more unprofessional? Delaying the release, or hitting our > > date and releasing with bugs that eat people's data? Or releasing with > > broken graphics for large swaths of users? > > I think you drifted a bit way to far away and into a opposition without > need. I for example nowhere said that we should not slip if there is a > strong reason to. But my comment was quite open, so it's partly my > fault; so let me rephrase: > > What is rel-eng doing in the next devel cycle to make sure we slip less > then we used to in the past? Or does rel-eng think everything was fine > and missing three and a half target dates (alpha, beta, > release and the first slipped release target date) out of four is > acceptable? I don't think it's acceptable, and what we're doing is taking a look at the problems with our development cycle, so that we can provide more time for development and bugfixing without getting in the way of maintainers, we're holding this FAD to investigate and brainstorm. > >> - why do we have to slip by a whole week most of the time? can't we find > >> ways to slip just a day or two if there really is no way around a delay? > > The marketing machine has very strongly requested that we only do > > releases on Tuesdays. > > Some reasons why Tuesdays are "must" instead of "good" would be way more > helpful then a simple statement "they said so". So all I can say is: > Yes, let's target Tuesdays if that is idea (which I agree), but if there > is a slip then slip only a day, two or three if the problem can be fixed > within that timeframe (which for example was not the case for the first > release slip for the final, but maybe for the second). It wouldn't have been. Nearly every time we tried to slip only for a couple days, we've had to slip for longer. Slipping usually means that we didn't have a GOLD set at the point of no return, which means we have to generate a fix for whatever is broken, re-create the release candidate, and re-validate it through our test matrix. It simply takes more time to do than what we could fit into a 2 or 3 day slip. > > [...] > >> - I'd be glad if the final release directories (e.g. > >> release/12/Everything" could be available earlier, even if what is in > >> them is not yet what "12" actually will become > > You'll have to enumerate why that is. > > Kevin outlined some of the reasons already in a reply: > https://www.redhat.com/archives/fedora-devel-list/2009-June/msg00073.html I don't want to make assumptions. If his reasons are yours, that's fine we'll take those issues as the problems to solve. What I'm not looking for is solutions looking for a problem, or pre-determined solutions that we'll try to make every problem fit into. I want to look at the problem set as a whole and /then/ work toward a solution. The proposal on the page is mostly a thought exercise to get people thinking about the scope of things that we could change. If we come out of this FAD with exactly my proposal, then we'll have likely wasted a lot of time and money. > > > One reason I've avoided this is > > added confusion as to when the "release" happens. If we created that > > directory and put content in there, would we have then released Fedora > > 12? When does it become "released" and thus trusted? > > As Kevin said as well: It seems to work quite well for Ubuntu and > actually avoids a lot of confusion. I'd say their scheme even works > better then our scheme. I'd also think most "normal" users don't ever > look on the servers. > > BTW, one more general thing for the FAD: Would it make sense to make > rawhide updates more than once a day in case something that bugs lot's > of people can be fixed easily by a quick update? Unfortunately with the addition of delta rpms, rawhide composes are back up to taking 8+ hours. There are places in the delta code paths were we can optimize, but the fact that we're dealing with 8500 packages to generate a lot more rpms across 4 arches, determining multilib on these, and then generating / validating deltas for all of these means that we're working on a scale that is very large, with a comparatively very small budget for hardware to deal with it, which means that our composes are not going to be quick. Particularly when we're trying to also push tonnes of updates for 3 other releases, which puts more stress on the same pieces of hardware. The scale is enormous, and only getting bigger, which means slower. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Jun 2 20:50:00 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 02 Jun 2009 13:50:00 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <200906022201.38401.bjorn@xn--rombobjrn-67a.se> References: <1243630631.3037.149.camel@localhost.localdomain> <20090602015639.GA30712@wolff.to> <1243912770.29188.50.camel@localhost.localdomain> <200906022201.38401.bjorn@xn--rombobjrn-67a.se> Message-ID: <1243975800.29188.105.camel@localhost.localdomain> On Tue, 2009-06-02 at 22:01 +0200, Bj?rn Persson wrote: > Jesse Keating wrote: > > On Mon, 2009-06-01 at 20:56 -0500, Bruno Wolff III wrote: > > > Do you hard link the new release files to the ones identical in rawhide > > > so that rsync doesn't have to transfer them to places mirroring rawhide? > > > > Yes and no. We do use hardlinks, however the mechanism that gets it > > from PHX to Raleigh is Netapp snapmirror, which works at the block > > level. I don't know enough about snapmirror to know if it is helped by > > hardlinks or not. The individual files aren't the real problem, it's > > the isos, particularly the live isos. > > A program similar to Jigdo could speed this up. Transfer only the RPM packages > (taking advantage of hard links) and information on what packages are in each > ISO image, and then recreate the ISO images at the destination. That way each > package would only be transferred once, regardless of how many ISO images it > occurs in. Unfortunately we don't have access/ability to use anything but snapmirror to get content from PHX into RDU where the I2 links are. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mw_triad at users.sourceforge.net Tue Jun 2 22:02:39 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 02 Jun 2009 17:02:39 -0500 Subject: Maintainer Responsibilities In-Reply-To: <200906021617.12122.sgrubb@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> Message-ID: Steve Grubb wrote: > I don't want to start a long thread, but just to ask a couple questions for my > own clarification. Does a maintainer's responsibilities end with packaging > bugs? IOW, if there is a problem in the package that is _broken code_ do they > need to do something about it or is it acceptable for them to close the bug > and say talk to upstream? Do we want those bugs open to track when the bug is > fixed in the distro? I'll accept whatever the answer is, I'm just curious. As far as: "Do we want those bugs open to track when the bug is fixed in the distro?" I would think the answer is "yes". Also tie the bug to the upstream bug if possible; if not, record in Fedora BZ a link to where the bug was reported (e.g. if upstream has only a mailing list). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Congratulations! You've won a free trip to the future! All you have to do to claim your prize is wait five minutes... From mw_triad at users.sourceforge.net Tue Jun 2 22:12:38 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 02 Jun 2009 17:12:38 -0500 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <4A258882.50001@cchtml.com> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <4A258882.50001@cchtml.com> Message-ID: Michael Cronenworth wrote: > Matthew Woehlke wrote: >> What about dropping hierarchical mirroring altogether? Why hasn't >> someone developed a distributed (i.e. bittorrent-like) system for mass >> mirroring? :-) >> > > Already discussed[1][2] on the fedora-test-list. > > [1] https://www.redhat.com/archives/fedora-test-list/2009-June/msg00032.html > [2] https://www.redhat.com/archives/fedora-test-list/2009-June/msg00062.html It's too bad fedora-test-list doesn't seem to be on gmane (or isn't named obviously; gmane.org is being too slow for me to ask about the mail address). In an idealized network (all servers have roughly the same speed links to all other servers), BT distribution should get everything to everyone in about 2x as long as to send everything to one server. In the worst case, it should take 2x as long as to send everything over the slowest link in the mesh, which if only care about when /all/ mirrors are fully synced (a very reasonable assumption in this type of scenario) is still pretty close to being an unconditional improvement. In practice, the actual result will be somewhere between 2x the time to transfer over the fastest link, and over the slowest link. In a generalized sense, the time-order to distribute via bittorrent in an idealized network is O(2 * K), where hierarchical systems are, at best I believe O(log(base N) K) for the furthest mirrors, and still O(N0 * K) for the tier-0 mirrors. That's an improvement of an entire order (O(log n) -> O(n)). The point about there not being tools currently is what would need to be addressed. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Congratulations! You've won a free trip to the future! All you have to do to claim your prize is wait five minutes... From kevin.kofler at chello.at Tue Jun 2 23:08:15 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 01:08:15 +0200 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > It IMHO shows a big and more and more pressing problem in Fedora: > Packagers and leadership are not working towards the same direction. The best solution for that is to change the leadership. :-) So don't vote for the same old hats for FESCo and FPB. > One comment: *from a outside* it often looks a bit like > - some (not all) people go crazy for weeks or months and ignore some of > those bugs that are not pressing, but nevertheless pressing (e.g. kind > of bugs that tend to land on target or blocker tracker bugs or already > are there) > - then you send a reminder "there will be a a test release next week" > - people suddenly wake up and try to fix those bugs for the test release > - they notice: arghh, serious things are broken, we need more time; can > we please slip? > - we slip > > Maybe more target dates where people should "get things into shape" > might help to reduce the work for the real test/final releases. Actually a better strategy is to just schedule the release a few weeks earlier than when you actually want to release, then the slips will make it hit the real target date very closely. :-) But I don't see those slips as a big issue in the first place. Kevin Kofler From kevin.kofler at chello.at Tue Jun 2 23:10:14 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 01:10:14 +0200 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243885856.2937.271.camel@adam.local.net> <4A2579BA.2070207@leemhuis.info> <1243975589.29188.100.camel@localhost.localdomain> Message-ID: Jesse Keating wrote: > An earlier freeze would have just frozen the work unfinished. The > rewrite was a massive undertaking and we knew it was going to take > longer than the release cycle to finish. Freezing earlier wouldn't have > helped. Then it should have been done in a work branch and targeted for a later release. Kevin Kofler From kevin.kofler at chello.at Tue Jun 2 23:29:35 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 01:29:35 +0200 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <4A258882.50001@cchtml.com> Message-ID: Matthew Woehlke wrote: > It's too bad fedora-test-list doesn't seem to be on gmane (or isn't > named obviously; gmane.org is being too slow for me to ask about the > mail address). gmane.linux.redhat.fedora.testers Kevin Kofler From kevin.kofler at chello.at Tue Jun 2 23:34:17 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 01:34:17 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> Message-ID: Steve Grubb wrote: > I don't want to start a long thread, but just to ask a couple questions > for my own clarification. Does a maintainer's responsibilities end with > packaging bugs? IOW, if there is a problem in the package that is _broken > code_ do they need to do something about it or is it acceptable for them > to close the bug and say talk to upstream? It's the reporter's job to report the bug upstream when asked to do so. Fixing bugs often requires two-way communication, so it's important for upstream to have a real reporter to talk to, I don't see why it should be the maintainer's job to play the relaying monkey. We're not carrier pigeons. We can't even CC the reporter on the upstream bug unless they register an account there, and at that point they can just as well file the bug themselves. Kevin Kofler From jwboyer at gmail.com Wed Jun 3 00:15:32 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 2 Jun 2009 20:15:32 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> Message-ID: <20090603001532.GN3095@hansolo.jdub.homelinux.org> On Wed, Jun 03, 2009 at 01:08:15AM +0200, Kevin Kofler wrote: >Thorsten Leemhuis wrote: >> It IMHO shows a big and more and more pressing problem in Fedora: >> Packagers and leadership are not working towards the same direction. > >The best solution for that is to change the leadership. :-) So don't vote >for the same old hats for FESCo and FPB. Honestly, that is pretty short-sighted. And Thorsten's statement isn't entirely accurate either. Entirely new FESCo and FPB would still be faced with the same problems we have today. Let's look at in a bit more detail. 1) I don't recall ever seeing FESCo or FPB state as a committee that they want fewer packages and updates. If you have a mailing list post to meeting minutes that say that, I would be happy to look at it. 2) The people that _have_ advocated for fewer updates have actual limitations they are facing that would make it desirable. As Jesse said in his reply earlier, it takes 8+ hours to mash rawhide now. It _also_ takes at least 8 hours to do an updates push. We are facing some real limitations on our turn around time for things at the moment and they are only going to get worse as we have newer releases that will get the delta rpms. At the same time, the same people are getting raked over the coals for not getting bits out fast enough. We are working on this from a rel-eng standpoint, but advocating for a bit of discretion on what should be pushed as an update is not entirely a bad thing. Personally, I would love it if package maintainers slowed down a bit. But it's not an end solution. So certainly the leadership, defined as FESCo and FPB, is not in conflict with the contributor's apparent direction. As far as I can see, they haven't made a statement either way. If there is a group that was pushing for something that ran contrary, it was Rel-Eng. And given that Jesse and I both just said we're going to basically stop begging people to slow down on updates, I think even that group is trying to figure out a way to make things better. Hell, that's partly what this FAD is all about. So, please. The rhetoric isn't really needed, it's not productive, and it's just going to stir things up more than necessary. >> Maybe more target dates where people should "get things into shape" >> might help to reduce the work for the real test/final releases. > >Actually a better strategy is to just schedule the release a few weeks >earlier than when you actually want to release, then the slips will make it >hit the real target date very closely. :-) Except our schedule is public and open. So whatever we say the date is, pretend or not, is the date that people will expect and target. josh From jwboyer at gmail.com Wed Jun 3 00:18:08 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 2 Jun 2009 20:18:08 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243885856.2937.271.camel@adam.local.net> <4A2579BA.2070207@leemhuis.info> <1243975589.29188.100.camel@localhost.localdomain> Message-ID: <20090603001808.GO3095@hansolo.jdub.homelinux.org> On Wed, Jun 03, 2009 at 01:10:14AM +0200, Kevin Kofler wrote: >Jesse Keating wrote: >> An earlier freeze would have just frozen the work unfinished. The >> rewrite was a massive undertaking and we knew it was going to take >> longer than the release cycle to finish. Freezing earlier wouldn't have >> helped. > >Then it should have been done in a work branch and targeted for a later >release. You have a point, but for something like anaconda you really need it to be installable and tested via installs. Simply branching the package isn't enough, since you need actual composes with the branched code in it. Not impossible to do, but when we have trouble getting people to test rawhide already I'm not sure diluting our test pool that way is a great answer. josh From matt at domsch.com Wed Jun 3 02:01:38 2009 From: matt at domsch.com (Matt Domsch) Date: Tue, 2 Jun 2009 21:01:38 -0500 Subject: Fedora Elections: Town Hall schedule set, beginning in 12 hours In-Reply-To: <20090601183758.GB24237@domsch.com> References: <20090601183758.GB24237@domsch.com> Message-ID: <20090603020135.GA18656@domsch.com> With each of the candidates noting they can attend at least one of the IRC Town Halls for their respective offices, the schedule I proposed is now set. Town Halls begin in about 12 hours. Each group participating in the election will host two Town Hall sessions on IRC. Each will last one hour, or less if there are no further questions. How to Join * Everyone should join #fedora-townhall on FreeNode (irc.freenode.net). Only candidates and a moderator may speak in this channel. * Non-candidates should also join #fedora-townhall-public on FreeNode (irc.freenode.net). Direct your questions for the candidates to the moderator. FESCo Candidate forum Wednesday, June 3, 1400 UTC (10am US Eastern Daylight Time, 7am US Pacific Daylight Time) Moderated by Max Spevack FESCo Candiate forum Thursday, June 4, 0200 UTC (Wed night, 10pm US Eastern Daylight Time, 7pm US Pacific Daylight Time) Moderated by Chris Tyler Board Candidate forum Thursday, June 4, 1400 UTC (10am US Eastern Daylight Time, 7am US Pacific Daylight Time) Moderated by Paul Frields Board Candidate forum Friday, June 5 0200 UTC (Thurs night, 10pm US Eastern Daylight Time, 7pm US Pacific Daylight Time) Moderated by John Rose (aka inode0) https://fedoraproject.org/wiki/Elections lists these now. I look forward to your participation, and hope these forums will more fully inform our electorate about the candidates. Thanks, Matt From notting at redhat.com Wed Jun 3 02:36:37 2009 From: notting at redhat.com (Bill Nottingham) Date: Tue, 2 Jun 2009 22:36:37 -0400 Subject: Maintainer Responsibilities In-Reply-To: <200906021617.12122.sgrubb@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> Message-ID: <20090603023637.GA21055@nostromo.devel.redhat.com> Steve Grubb (sgrubb at redhat.com) said: > I don't want to start a long thread, but just to ask a couple questions for my > own clarification. Does a maintainer's responsibilities end with packaging > bugs? IOW, if there is a problem in the package that is _broken code_ do they > need to do something about it or is it acceptable for them to close the bug > and say talk to upstream? Depends on the bug/issue. For security isses, I don't think CLOSED->UPSTREAM is appropriate, unless it requires a major architecture of the code base. Similarly, if an app is crashing immediately on startup, it's not something we necessarily want to just hope upstream will fix. Bill From rc040203 at freenet.de Wed Jun 3 03:09:49 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 03 Jun 2009 05:09:49 +0200 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> Message-ID: <4A25E97D.8000202@freenet.de> Kevin Kofler wrote: > Steve Grubb wrote: >> I don't want to start a long thread, but just to ask a couple questions >> for my own clarification. Does a maintainer's responsibilities end with >> packaging bugs? IOW, if there is a problem in the package that is _broken >> code_ do they need to do something about it or is it acceptable for them >> to close the bug and say talk to upstream? > > It's the reporter's job to report the bug upstream when asked to do so. I disagree. Reporters are "users" - "customers" if you like to. You can't expect them to do anything, nor demand them to do anything, nor force them to do anything. That said, I consider it to be a Fedora package's maintainer's job and duty to act as moderator/arbiter/coordinator to initiate appropriate communication/interaction between all different parties (reporter, packager, upstreams) "when necessary/if required". Ralf From jkeating at redhat.com Wed Jun 3 03:11:38 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 02 Jun 2009 20:11:38 -0700 Subject: Maintainer Responsibilities In-Reply-To: <4A25E97D.8000202@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> Message-ID: <1243998698.8792.22.camel@localhost.localdomain> On Wed, 2009-06-03 at 05:09 +0200, Ralf Corsepius wrote: > I disagree. Reporters are "users" - "customers" if you like to. > > You can't expect them to do anything, nor demand them to do anything, > nor force them to do anything. > > That said, I consider it to be a Fedora package's maintainer's job > and > duty to act as moderator/arbiter/coordinator to initiate appropriate > communication/interaction between all different parties (reporter, > packager, upstreams) "when necessary/if required". I agree with this. If it isn't clarified in maintainer's responsibility, perhaps it should be. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From smparrish at gmail.com Tue Jun 2 22:17:02 2009 From: smparrish at gmail.com (Steven M. Parrish) Date: Tue, 2 Jun 2009 18:17:02 -0400 Subject: Maintainer Responsibilities In-Reply-To: <200906021617.12122.sgrubb@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> Message-ID: <200906021817.04327.smparrish@gmail.com> > Hello, > > I don't want to start a long thread, but just to ask a couple questions for > my own clarification. Does a maintainer's responsibilities end with > packaging bugs? IOW, if there is a problem in the package that is _broken > code_ do they need to do something about it or is it acceptable for them to > close the bug and say talk to upstream? Do we want those bugs open to track > when the bug is fixed in the distro? I'll accept whatever the answer is, > I'm just curious. > > Thanks, > -Steve This is from the official Bugzappers page https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#Upstreaming **** The bug is not a packaging bug, the package maintainer has no plans to work on this in the near future, and there is an upstream bug tracking system other than the Red Hat Bugzilla. Thank you for the bug report. At the moment, the Fedora developers are busy fixing other issues and may not have time to work on this one. The best way to make sure your problem will get looked on is to report it to the authors of the program. Most upstream authors use a bug tracking system like Bugzilla, and more people who know the code will be looking at the bug report there. The upstream bug tracking system to use is: You are requested to add the bugzilla link here for tracking purposes. Please make sure the bug isn't already in the upstream bug tracker before filing it. **** Maintainers should be free to either fix it locally (time permitting) and upstream the patch or request that the bug be filed at the upstream projects tracker for the upstream developers to resolve it. If it is sent upstream the bug is closed as UPSTREAM and our local report is cross-referenced to the upstream one. That way the maintainer and all interested parties can follow its progress. SMP From fedora at leemhuis.info Wed Jun 3 07:10:46 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 03 Jun 2009 09:10:46 +0200 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1243974623.29188.84.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <4A257DC9.5090703@leemhuis.info> <1243974623.29188.84.camel@localhost.localdomain> Message-ID: <4A2621F6.6050407@leemhuis.info> On 02.06.2009 22:30, Jesse Keating wrote: > On Tue, 2009-06-02 at 21:30 +0200, Thorsten Leemhuis wrote: >> but if we get RC with the final name transferred to the >> mirrors ahead of time then they can be updated relative quickly as well, >> as only a few bit change. > > We don't do this as it tends to lead to leaks, and confusion as to > whether the release has been done or not. Then put it in a temporary folder that is rsynced from the mirror masters, but not exported it to the world. Later it's just a update to the file and a hardlink to a proper place. Or simply ignore that "there might be leaks" problem more -- the clientele that is huntin for leaks before something is announced is doing something wrong already in any case. And if the whole process from finishing to release would be a whole lot shorter then it shortens the time where something leaks. CU knurd From fedora at leemhuis.info Wed Jun 3 07:16:02 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 03 Jun 2009 09:16:02 +0200 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <20090602201447.GA9836@auslistsprd01.us.dell.com> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <4A257DC9.5090703@leemhuis.info> <20090602201447.GA9836@auslistsprd01.us.dell.com> Message-ID: <4A262332.2030904@leemhuis.info> On 02.06.2009 22:14, Matt Domsch wrote: > On Tue, Jun 02, 2009 at 09:30:17PM +0200, Thorsten Leemhuis wrote: >> On 02.06.2009 00:22, Matt Domsch wrote: >>> On Mon, Jun 01, 2009 at 04:03:04PM -0400, Paul W. Frields wrote: >>>> I'm getting out of my ken here, but could this be done in stages with >>>> I2 connected hosts getting the bits early/first and then moving on to >>>> others? >>> We need to move ~130GB to each of ~230 mirrors, in about 4 >>> days. > The 130GB is what we posted for F10. Of that, 48GB were ISOs, 93GB > was the Everything/ tree which was hardlinked from rawhide, so yes, > that would cut down on the transfer quite a bit. > > Honestly, I don't recall how the signing aspect went for F10. If the > process involved signing, then copying the packages into the > Everything tree, then there wouldn't be hardlinks to help. They would -- just copy the files two days ahead of signing somewhere (a temporary hidden place not exported to the world for example). When you sign later and put the files in the proper place then iirc just the signature of the files need to be updated, which rsync handles well. [...] >> Or what am I missing? > I think you're right, except that RC ISOs aren't published ahead of > time for mirrors to sync, Which shouldn't be to hard to do, or? > and signing of the RPMs that land in the > Everything tree if they weren't signed, or were signed with a > different key. I believe the signing process has changed for F11, so > the packages in rawhide are signed with the F11 release key. I think > that means at some point, either through a mass rebuild, or through a > resigning, rawhide will then need to be re-signed with the F12 key. Yeah, that's how I understood it as well. But it means it should be easy to hardlink the files in the target place when a test/final release happens, which is something quite easy for rsync afaics. CU knurd From denis at poolshark.org Wed Jun 3 07:20:54 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 03 Jun 2009 09:20:54 +0200 Subject: Orphaning some packages (brasero, transmission and more) Message-ID: <4A262456.9050203@poolshark.org> In an effort to focus more on FOSS upstream development, I am going to be orphaning some of my Fedora packages in the near future, starting with this first batch. brasero (high-maintenance) transmission k3d (fairly complex project, and it's actually a Gnome app) soundconverter gpredict grig gstreamer-python (used by soundconverter, pitivi) hamlib plotutils (inactive upstream, but used by inkscape) pstoedit (inactive upstream, but used by inkscape) dates (inactive upstream) ghasher (dead upstream) gimmage (inactive upstream) pam_keyring (should stay orphaned actually) From jreznik at redhat.com Wed Jun 3 07:25:16 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Wed, 3 Jun 2009 09:25:16 +0200 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> Message-ID: <200906030925.16669.jreznik@redhat.com> On Mi?rcoles 03 Junio 2009 01:34:17 Kevin Kofler escribi?: > Steve Grubb wrote: > > I don't want to start a long thread, but just to ask a couple questions > > for my own clarification. Does a maintainer's responsibilities end with > > packaging bugs? IOW, if there is a problem in the package that is _broken > > code_ do they need to do something about it or is it acceptable for them > > to close the bug and say talk to upstream? > > It's the reporter's job to report the bug upstream when asked to do so. > Fixing bugs often requires two-way communication, so it's important for > upstream to have a real reporter to talk to, I don't see why it should be > the maintainer's job to play the relaying monkey. We're not carrier > pigeons. We can't even CC the reporter on the upstream bug unless they > register an account there, and at that point they can just as well file the > bug themselves. +1! Jaroslav > Kevin Kofler From cooly at gnome.eu.org Wed Jun 3 07:33:33 2009 From: cooly at gnome.eu.org (Lucian Langa) Date: Wed, 03 Jun 2009 10:33:33 +0300 Subject: Orphaning some packages (brasero, transmission and more) In-Reply-To: <4A262456.9050203@poolshark.org> References: <4A262456.9050203@poolshark.org> Message-ID: <1244014413.24896.33.camel@mayday> On Wed, 2009-06-03 at 09:20 +0200, Denis Leroy wrote: > In an effort to focus more on FOSS upstream development, I am going to > be orphaning some of my Fedora packages in the near future, starting > with this first batch. I'm interested in taking over your hamradio related packages. > gpredict > grig > hamlib Thanks, --lucian From lxtnow at gmail.com Wed Jun 3 08:03:54 2009 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Wed, 3 Jun 2009 10:03:54 +0200 Subject: Orphaning some packages (brasero, transmission and more) In-Reply-To: <4A262456.9050203@poolshark.org> References: <4A262456.9050203@poolshark.org> Message-ID: <62bc09df0906030103j4d26acd2x97dbe9aa8043a744@mail.gmail.com> On Wed, Jun 3, 2009 at 9:20 AM, Denis Leroy wrote: > brasero (high-maintenance) > soundconverter > gstreamer-python (used by soundconverter, pitivi) I will request ownership on those one. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From mcepl at redhat.com Wed Jun 3 08:11:22 2009 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 3 Jun 2009 08:11:22 +0000 (UTC) Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <4A258882.50001@cchtml.com> Message-ID: Kevin Kofler, Wed, 03 Jun 2009 01:29:35 +0200: > gmane.linux.redhat.fedora.testers http://list.gmane.org/fedora-test-list at redhat.com From Juha.Tuomala at iki.fi Wed Jun 3 08:22:46 2009 From: Juha.Tuomala at iki.fi (Juha Tuomala) Date: Wed, 3 Jun 2009 11:22:46 +0300 Subject: Maintainer Responsibilities In-Reply-To: <4A25E97D.8000202@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> Message-ID: <200906031122.46545.Juha.Tuomala@iki.fi> On Wednesday 03 June 2009 06:09:49 Ralf Corsepius wrote: > I disagree. Reporters are "users" - "customers" if you like to. > > You can't expect them to do anything, nor demand them to do anything, > nor force them to do anything. I agree. Demanding them to take any responsibility on that report, even testing it again makes them just think twice next time to report anything. > That said, I consider it to be a Fedora package's maintainer's job and > duty to act as moderator/arbiter/coordinator to initiate appropriate > communication/interaction between all different parties (reporter, > packager, upstreams) "when necessary/if required". Exactly. If the reporter wants to take part to that communication, good. But that should not expected. More reports is better than more active reporters, those latter ones wont disapper anywhere anyway. Tuju -- Better to have one, and not need it, than to need one and not have it. From mcepl at redhat.com Wed Jun 3 08:21:19 2009 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 3 Jun 2009 08:21:19 +0000 (UTC) Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <20090603023637.GA21055@nostromo.devel.redhat.com> Message-ID: Bill Nottingham, Tue, 02 Jun 2009 22:36:37 -0400: > Depends on the bug/issue. For security isses, I don't think > CLOSED->UPSTREAM is appropriate, unless it requires a major architecture > of the code base. Similarly, if an app is crashing immediately on > startup, it's not something we necessarily want to just hope upstream > will fix. Depends also on maintainer ... we don't require packagers to be programmers and proficient in language their package is written. Mat?j From jreznik at redhat.com Wed Jun 3 08:47:26 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Wed, 3 Jun 2009 10:47:26 +0200 Subject: Maintainer Responsibilities In-Reply-To: <4A25E97D.8000202@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> Message-ID: <200906031047.26436.jreznik@redhat.com> On Mi?rcoles 03 Junio 2009 05:09:49 Ralf Corsepius escribi?: > Kevin Kofler wrote: > > Steve Grubb wrote: > >> I don't want to start a long thread, but just to ask a couple questions > >> for my own clarification. Does a maintainer's responsibilities end with > >> packaging bugs? IOW, if there is a problem in the package that is > >> _broken code_ do they need to do something about it or is it acceptable > >> for them to close the bug and say talk to upstream? > > > > It's the reporter's job to report the bug upstream when asked to do so. > > I disagree. Reporters are "users" - "customers" if you like to. > > You can't expect them to do anything, nor demand them to do anything, > nor force them to do anything. We are not forcing anyone to do anything but we think direct communication between user and developer is much more better - our "users/customers" are upstream's "users/customers" either, we are more reseller - distributor. But this doesn't mean we LEFT our users in such cases - we are still tracking this bug, we are communicating with upstream, helping our users to report it and if upstream have solution, we are trying to use it (in form of patches, suggestions etc.). To satisfy our needs, users needs, upstream needs... Jaroslav PS: I'm not saying to not report bugs to RH bugzilla, we can help then but lack of direct communication between user and developer is issue, back to propritetary software.... > > That said, I consider it to be a Fedora package's maintainer's job and > duty to act as moderator/arbiter/coordinator to initiate appropriate > communication/interaction between all different parties (reporter, > packager, upstreams) "when necessary/if required". > > Ralf From Juha.Tuomala at iki.fi Wed Jun 3 08:49:28 2009 From: Juha.Tuomala at iki.fi (Juha Tuomala) Date: Wed, 3 Jun 2009 11:49:28 +0300 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> Message-ID: <200906031149.28816.Juha.Tuomala@iki.fi> On Wednesday 03 June 2009 02:34:17 Kevin Kofler wrote: > It's the reporter's job to report the bug upstream when asked to do so. Would to make the report then if she says 'no'? :) > Fixing bugs often requires two-way communication, so it's important for > upstream to have a real reporter to talk to, I don't see why it should be > the maintainer's job to play the relaying monkey. We're not carrier > pigeons. We can't even CC the reporter on the upstream bug unless they > register an account there, and at that point they can just as well file the > bug themselves. It's a fact that knowledge increases when you move steps to upstream. And it also becomes more strange (debugging steps) to the regular user. Even finding the matching upstream bug can be quite impossible to the most users. In my experience, the bugzilla andvanced interface is way too confusing to someone who has never seen it before. If a packager don't have time to do that stuff, he would probably need a co-maintainer(s) or less packages. In case the reporter is able to do all that what package manintaers wish to off-load to her, she's probably already doing that without asking. But putting that as a policy and demand it is not the way to go imo. As amount of people grow when going down the stream, so does the communication. It takes time and less talk and more coding is what everyone wants. Thus the distro plays an important part as chocking point between the devs and vast userspace. Tuju -- Better to have one, and not need it, than to need one and not have it. From mschwendt at gmail.com Wed Jun 3 09:38:09 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Jun 2009 11:38:09 +0200 Subject: Maintainer Responsibilities In-Reply-To: <4A25E97D.8000202@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> Message-ID: <20090603113809.3ad3d992@faldor.intranet> On Wed, 03 Jun 2009 05:09:49 +0200, Ralf wrote: > Kevin Kofler wrote: > > Steve Grubb wrote: > >> I don't want to start a long thread, but just to ask a couple questions > >> for my own clarification. Does a maintainer's responsibilities end with > >> packaging bugs? IOW, if there is a problem in the package that is _broken > >> code_ do they need to do something about it or is it acceptable for them > >> to close the bug and say talk to upstream? > > > > It's the reporter's job to report the bug upstream when asked to do so. > > I disagree. Reporters are "users" - "customers" if you like to. Consumers. Consumers of a product. And the product (albeit developed by upstream) is offered by Fedora, as the Fedora packagers prepare and build the packages for the Fedora software environment. Added value, and as such it's normal for the packagers to stay at the front with regard to incoming problem reports. > You can't expect them to do anything, nor demand them to do anything, > nor force them to do anything. On the contrary, a packager at least ought to have an opinion about every Fedora bugzilla ticket that is opened for the package. An opinion about whether a problem is reproducible, whether it may be specific to Fedora, whether it can be patched for Fedora, whether it is grave enough to be in need of major rewrites in the upstream code base, whether the report is not helpful, and so on. The Fedora packager ought to be aware of what the package users think about how usable the packaged software is in the Fedora environment. > That said, I consider it to be a Fedora package's maintainer's job and > duty to act as moderator/arbiter/coordinator to initiate appropriate > communication/interaction between all different parties (reporter, > packager, upstreams) "when necessary/if required". This is particularly important when upstream doesn't have a bug tracking system, when it takes weeks till months for a new upstream release, when a problem requires the user to test unofficial updates (and patches that can be derived from SCM commits) where the Fedora packager may need to assist. From Juha.Tuomala at iki.fi Wed Jun 3 09:52:37 2009 From: Juha.Tuomala at iki.fi (Juha Tuomala) Date: Wed, 3 Jun 2009 12:52:37 +0300 Subject: Maintainer Responsibilities In-Reply-To: <200906031047.26436.jreznik@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031047.26436.jreznik@redhat.com> Message-ID: <200906031252.38232.Juha.Tuomala@iki.fi> On Wednesday 03 June 2009 11:47:26 Jaroslav Reznik wrote: > PS: I'm not saying to not report bugs to RH bugzilla, we can help then but > lack of direct communication between user and developer is issue, You're assuming that all those users are engineers and technical people. That might be true atm but at least I also would like to get the 'normal people' which are now ubuntu users. > back to propritetary software.... ....which is the reason why most 'normal people' use windows and among the numbers, they have the control of everything (hw support etc). I'd like to see a day that my new display adapter works out of the box. I'd like to see that day as a Fedora user/community member. Tuju -- Better to have one, and not need it, than to need one and not have it. From dwmw2 at infradead.org Wed Jun 3 10:25:39 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 03 Jun 2009 11:25:39 +0100 Subject: Maintainer Responsibilities In-Reply-To: <200906021617.12122.sgrubb@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> Message-ID: <1244024739.6512.9.camel@macbook.infradead.org> On Tue, 2009-06-02 at 16:17 -0400, Steve Grubb wrote: > > I don't want to start a long thread, but just to ask a couple questions for my > own clarification. Does a maintainer's responsibilities end with packaging > bugs? IOW, if there is a problem in the package that is _broken code_ do they > need to do something about it or is it acceptable for them to close the bug > and say talk to upstream? There are _some_ kinds of bug (feature requests, etc.) which it's reasonable for any decent maintainer to punt upstream. There are other kinds of bugs (crashes, security issues -- perhaps even _anything_ that's a real bug rather than an RFE) which the maintainer really _ought_ to deal with directly. Opinions vary on precisely where the boundary between those classes should be, but I'm fairly adamant it should be 'RFE vs. bug'. Any packager who _isn't_ capable of handling the latter class of bug probably shouldn't be maintaining the package without the assistance of a co-packager or their sponsor. Note that you don't _have_ to be able to code to handle a real bug in an acceptable fashion -- decent coordination with upstream can be perfectly sufficient, if upstream are responsive enough. But just closing the bug in our bugzilla as 'upstream' is rarely acceptable for a _real_ bug, IMHO. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From varekova at redhat.com Wed Jun 3 10:47:44 2009 From: varekova at redhat.com (Ivana Varekova) Date: Wed, 03 Jun 2009 12:47:44 +0200 Subject: uClibc orphaned Message-ID: <4A2654D0.7090306@redhat.com> Hello, I want to split uClibc from busybox package - is here a volunteer who is willing to take care about it? Ivana Hutarova Varekova From jreznik at redhat.com Wed Jun 3 11:01:01 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Wed, 3 Jun 2009 13:01:01 +0200 Subject: Maintainer Responsibilities In-Reply-To: <200906031252.38232.Juha.Tuomala@iki.fi> References: <200906021617.12122.sgrubb@redhat.com> <200906031047.26436.jreznik@redhat.com> <200906031252.38232.Juha.Tuomala@iki.fi> Message-ID: <200906031301.01385.jreznik@redhat.com> On Mi?rcoles 03 Junio 2009 11:52:37 Juha Tuomala escribi?: > On Wednesday 03 June 2009 11:47:26 Jaroslav Reznik wrote: > > PS: I'm not saying to not report bugs to RH bugzilla, we can help then > > but lack of direct communication between user and developer is issue, > > You're assuming that all those users are engineers and technical > people. That might be true atm but at least I also would like to get > the 'normal people' which are now ubuntu users. Most bugs are filled by quite technically skilled users. For average users it doesn't depend if it is RH bugzilla or upstream's bugzilla - it's too complicated for them. I know - it's another story... For these people forums are much more better. Maybe we lack some tool for users - without technical details, more collecting only tool... Some easy GUI for Abrt? New Dr. Konqui is nice but still too complicated for average users. They don't click on "send bug" button but "OK" buttons and accepting the fact of crash... > > back to propritetary software.... > > ....which is the reason why most 'normal people' use windows and > among the numbers, they have the control of everything (hw support etc). But if you observe bug or have some wish - there's no chance to talk to developer... > I'd like to see a day that my new display adapter works out of the > box. I'd like to see that day as a Fedora user/community member. I hope that day is close because I think it's worst problem of whole OSS Desktop :( > > Tuju > > -- > Better to have one, and not need it, than to need one and not have it. Jaroslav From sundaram at fedoraproject.org Wed Jun 3 11:00:36 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 03 Jun 2009 16:30:36 +0530 Subject: Orphaning some packages (brasero, transmission and more) In-Reply-To: <4A262456.9050203@poolshark.org> References: <4A262456.9050203@poolshark.org> Message-ID: <4A2657D4.7000706@fedoraproject.org> On 06/03/2009 12:50 PM, Denis Leroy wrote: > In an effort to focus more on FOSS upstream development, I am going to > be orphaning some of my Fedora packages in the near future, starting > with this first batch. > > transmission Taken this. Co-maintainers welcome. Rahul From pbrobinson at gmail.com Wed Jun 3 11:12:49 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 3 Jun 2009 12:12:49 +0100 Subject: Orphaning some packages (brasero, transmission and more) In-Reply-To: <4A262456.9050203@poolshark.org> References: <4A262456.9050203@poolshark.org> Message-ID: <5256d0b0906030412x7f5908b6se433dceae97e9c49@mail.gmail.com> > dates (inactive upstream) I'll take this one. Peter From pasik at iki.fi Wed Jun 3 11:14:11 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Wed, 3 Jun 2009 14:14:11 +0300 Subject: F11: kernel/boot hangs at creating initial device nodes with 2.6.30-rc6 In-Reply-To: <20090601051548.GW24960@edu.joroinen.fi> References: <20090601051548.GW24960@edu.joroinen.fi> Message-ID: <20090603111411.GE24960@edu.joroinen.fi> On Mon, Jun 01, 2009 at 08:15:48AM +0300, Pasi K?rkk?inen wrote: > Hello. > > Yesterday I installed latest F11/rawhide. The default installed kernel > (2.6.29 something) works fine. > > I compiled custom 2.6.30-rc6 kernel, and created initrd for it, and tried > booting it. > > Booting process gets stuck at "creating initial device nodes". > > Any ideas? I assume that's during initrd execution.. > Something missing from my kernel config? > > Any tips would be appreciated. Has anyone else seen this problem? -- Pasi From johannbg at hi.is Wed Jun 3 11:20:25 2009 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 03 Jun 2009 11:20:25 +0000 Subject: Maintainer Responsibility Policy In-Reply-To: <1210089261.2961.3.camel@kennedy> References: <1210035695.6297.25.camel@kennedy> <482056BE.90100@n-dimensional.de> <48206A93.7020807@gmail.com> <1210089261.2961.3.camel@kennedy> Message-ID: <4A265C79.7090609@hi.is> On 05/06/2008 03:54 PM, Brian Pepple wrote: > On Tue, 2008-05-06 at 07:26 -0700, Toshio Kuratomi wrote: > > >> Brian, we probably want to list the ways to deal with bug reports in the >> policy as many maintainers don't realize how many options there are for >> getting help fixing a bug. >> > Here's what I've got right now (from Kevin's suggestion) in the section > regarding bugs: > > "If you find yourself unable to handle the load of bugs from your > package(s), please ask for assistance on the fedora-devel and/or > fedora-test lists. Teaching triagers about how to triage your bugs or > getting help from other maintainers can not only reduce your load, but > improve Fedora. Consider reaching out for some (more) co-maintainers to > assist as well." > > Do we want to expand on that? > > FYI If bugs need (Re)testing or a component needs a speedup treatment in bodhi drop a testing request to fedora-test list and/or file a request in Fedora QA trac instance on https://fedorahosted.org/fedora-qa and we will take care of it. We also assisting in any test case creation, setup test day's etc. Dont hesitate to drop a mail to the test-list or open a ticktet in Fedora QA trac instance JBG -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 356 bytes Desc: not available URL: From jwboyer at gmail.com Wed Jun 3 11:48:02 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 3 Jun 2009 07:48:02 -0400 Subject: Orphaning some packages (brasero, transmission and more) In-Reply-To: <4A262456.9050203@poolshark.org> References: <4A262456.9050203@poolshark.org> Message-ID: <20090603114802.GQ3095@hansolo.jdub.homelinux.org> On Wed, Jun 03, 2009 at 09:20:54AM +0200, Denis Leroy wrote: > In an effort to focus more on FOSS upstream development, I am going to > be orphaning some of my Fedora packages in the near future, starting > with this first batch. > > brasero (high-maintenance) Wait... didn't we just make this the default CD/DVD buring application in the Fedora spin? http://fedoraproject.org/wiki/Features/Gnome2_26 And now it's orphaned? josh From sundaram at fedoraproject.org Wed Jun 3 11:52:01 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 03 Jun 2009 17:22:01 +0530 Subject: Orphaning some packages (brasero, transmission and more) In-Reply-To: <20090603114802.GQ3095@hansolo.jdub.homelinux.org> References: <4A262456.9050203@poolshark.org> <20090603114802.GQ3095@hansolo.jdub.homelinux.org> Message-ID: <4A2663E1.1010304@fedoraproject.org> On 06/03/2009 05:18 PM, Josh Boyer wrote: > On Wed, Jun 03, 2009 at 09:20:54AM +0200, Denis Leroy wrote: >> In an effort to focus more on FOSS upstream development, I am going to >> be orphaning some of my Fedora packages in the near future, starting >> with this first batch. >> >> brasero (high-maintenance) > > Wait... didn't we just make this the default CD/DVD buring application in > the Fedora spin? > > http://fedoraproject.org/wiki/Features/Gnome2_26 > > And now it's orphaned? Yep. Bad timing. Somebody should pick it up. Rahul From rc040203 at freenet.de Wed Jun 3 12:01:46 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 03 Jun 2009 14:01:46 +0200 Subject: Maintainer Responsibilities In-Reply-To: <200906031047.26436.jreznik@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031047.26436.jreznik@redhat.com> Message-ID: <4A26662A.9010802@freenet.de> Jaroslav Reznik wrote: > On Mi?rcoles 03 Junio 2009 05:09:49 Ralf Corsepius escribi?: >> Kevin Kofler wrote: >>> Steve Grubb wrote: >>>> I don't want to start a long thread, but just to ask a couple questions >>>> for my own clarification. Does a maintainer's responsibilities end with >>>> packaging bugs? IOW, if there is a problem in the package that is >>>> _broken code_ do they need to do something about it or is it acceptable >>>> for them to close the bug and say talk to upstream? >>> It's the reporter's job to report the bug upstream when asked to do so. >> I disagree. Reporters are "users" - "customers" if you like to. >> >> You can't expect them to do anything, nor demand them to do anything, >> nor force them to do anything. > > We are not forcing anyone to do anything but we think direct communication > between user and developer is much more better I consider maintainers redirecting arbitrary reporters to upstreams to be rude and hostile, because they are presuming the reporter to be * interested in tracking down bugs * interested in getting involved into upstreams * technically able to do so. This occasionally applies to developers - To normal users it usally doesn't apply, they want "to have their issue fixed". Ralf From limb at jcomserv.net Wed Jun 3 12:01:22 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 03 Jun 2009 07:01:22 -0500 Subject: Orphaning some packages (brasero, transmission and more) In-Reply-To: <4A2663E1.1010304@fedoraproject.org> References: <4A262456.9050203@poolshark.org> <20090603114802.GQ3095@hansolo.jdub.homelinux.org> <4A2663E1.1010304@fedoraproject.org> Message-ID: <4A266612.1030507@jcomserv.net> Rahul Sundaram wrote: > On 06/03/2009 05:18 PM, Josh Boyer wrote: > >> On Wed, Jun 03, 2009 at 09:20:54AM +0200, Denis Leroy wrote: >> >>> In an effort to focus more on FOSS upstream development, I am going to >>> be orphaning some of my Fedora packages in the near future, starting >>> with this first batch. >>> >>> brasero (high-maintenance) >>> >> Wait... didn't we just make this the default CD/DVD buring application in >> the Fedora spin? >> >> http://fedoraproject.org/wiki/Features/Gnome2_26 >> >> And now it's orphaned? >> > > Yep. Bad timing. Somebody should pick it up. > > Rahul > > Xavier Lamien said he'd pick it up, which I assume he'll do after Denis orphans it in pkgdb. -J -- in your fear, speak only peace in your fear, seek only love -d. bowie From rc040203 at freenet.de Wed Jun 3 12:06:45 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 03 Jun 2009 14:06:45 +0200 Subject: Maintainer Responsibilities In-Reply-To: <20090603113809.3ad3d992@faldor.intranet> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <20090603113809.3ad3d992@faldor.intranet> Message-ID: <4A266755.6080904@freenet.de> Michael Schwendt wrote: > On Wed, 03 Jun 2009 05:09:49 +0200, Ralf wrote: > >> Kevin Kofler wrote: >>> Steve Grubb wrote: >>>> I don't want to start a long thread, but just to ask a couple questions >>>> for my own clarification. Does a maintainer's responsibilities end with >>>> packaging bugs? IOW, if there is a problem in the package that is _broken >>>> code_ do they need to do something about it or is it acceptable for them >>>> to close the bug and say talk to upstream? >>> It's the reporter's job to report the bug upstream when asked to do so. >> I disagree. Reporters are "users" - "customers" if you like to. > > Consumers. Consumers of a product. No. I used the word "customers" on purpose. I consider users (esp. bug reporters) not to be "the dumb pigs eating the hog wash they get for free", or "clueless comsumer masses" aborbing anything they don't pay for with money, but them to be the foundation of your work and them to be valuable business partners, paying in immaterial payment (e.g. feedback, such as bug reports). Ralf From martin.marques at gmail.com Wed Jun 3 12:11:47 2009 From: martin.marques at gmail.com (=?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?=) Date: Wed, 3 Jun 2009 09:11:47 -0300 Subject: anaconda error with preupgrade to F11 (rawhide really) Message-ID: Can anyone check on this? https://bugzilla.redhat.com/show_bug.cgi?id=503830 I know that the bug reports get to the anaconda maintenance list, but I was worried that it might affect future fedora upgrades. -- Mart?n Marqu?s select 'martin.marques' || '@' || 'gmail.com' DBA, Programador, Administrador From denis at poolshark.org Wed Jun 3 12:16:18 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 03 Jun 2009 14:16:18 +0200 Subject: Orphaning some packages (brasero, transmission and more) In-Reply-To: <20090603114802.GQ3095@hansolo.jdub.homelinux.org> References: <4A262456.9050203@poolshark.org> <20090603114802.GQ3095@hansolo.jdub.homelinux.org> Message-ID: <4A266992.6070900@poolshark.org> On 06/03/2009 01:48 PM, Josh Boyer wrote: > On Wed, Jun 03, 2009 at 09:20:54AM +0200, Denis Leroy wrote: >> In an effort to focus more on FOSS upstream development, I am going to >> be orphaning some of my Fedora packages in the near future, starting >> with this first batch. >> >> brasero (high-maintenance) > > Wait... didn't we just make this the default CD/DVD buring application in > the Fedora spin? > > http://fedoraproject.org/wiki/Features/Gnome2_26 > > And now it's orphaned? I merely want to transfer ownership to somebody new. Matthias Clasen and Bastien Nocera are already acting co-maintainers, and so I'm waiting to hear from them before transferring ownership, in case one of them has a strong desire to take over the package... -denis From sgrubb at redhat.com Wed Jun 3 12:43:26 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 3 Jun 2009 08:43:26 -0400 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> Message-ID: <200906030843.26442.sgrubb@redhat.com> On Tuesday 02 June 2009 07:34:17 pm Kevin Kofler wrote: > Steve Grubb wrote: > > I don't want to start a long thread, but just to ask a couple questions > > for my own clarification. Does a maintainer's responsibilities end with > > packaging bugs? IOW, if there is a problem in the package that is _broken > > code_ do they need to do something about it or is it acceptable for them > > to close the bug and say talk to upstream? > > It's the reporter's job to report the bug upstream when asked to do so. And then should the bug be closed hoping that one day you pull in a package that solves the user's problem? > Fixing bugs often requires two-way communication, so it's important for > upstream to have a real reporter to talk to, I don't see why it should be > the maintainer's job to play the relaying monkey. Its real simple. In reporting the bug, people are asked how to reproduce the bug. If its reproducible by the maintainer, the user is no longer required to solve the problem and all you need to do is ask them to do a retest. If the bug is not reproducible, then things do get a little trickier. I would still take the bug report to upstream and see if it rings any bells, but I would not close the bug. -Steve From sgrubb at redhat.com Wed Jun 3 12:48:00 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 3 Jun 2009 08:48:00 -0400 Subject: Maintainer Responsibilities In-Reply-To: <4A25E97D.8000202@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> Message-ID: <200906030848.00617.sgrubb@redhat.com> On Tuesday 02 June 2009 11:09:49 pm Ralf Corsepius wrote: > Kevin Kofler wrote: > > Steve Grubb wrote: > >> I don't want to start a long thread, but just to ask a couple questions > >> for my own clarification. Does a maintainer's responsibilities end with > >> packaging bugs? IOW, if there is a problem in the package that is > >> _broken code_ do they need to do something about it or is it acceptable > >> for them to close the bug and say talk to upstream? > > > > It's the reporter's job to report the bug upstream when asked to do so. > > I disagree. Reporters are "users" - "customers" if you like to. > > You can't expect them to do anything, nor demand them to do anything, > nor force them to do anything. > > That said, I consider it to be a Fedora package's maintainer's job and > duty to act as moderator/arbiter/coordinator to initiate appropriate > communication/interaction between all different parties (reporter, > packager, upstreams) "when necessary/if required". For the record, I agree with this sentiment. If there's a bug in my packages, I want to fix it and not cause the reporter to have to get upstream bz accounts or join upstream mail lists just because they reported a problem. I will interact with the reporter until I see the problem myself. And then I can fix it or show upstream the problem. Thanks everybody for the opinions. I just wanted to raise awareness on this topic. -Steve From stickster at gmail.com Wed Jun 3 12:55:48 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 3 Jun 2009 08:55:48 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <20090603001532.GN3095@hansolo.jdub.homelinux.org> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> <20090603001532.GN3095@hansolo.jdub.homelinux.org> Message-ID: <20090603125548.GK3551@localhost.localdomain> On Tue, Jun 02, 2009 at 08:15:32PM -0400, Josh Boyer wrote: > We are facing some real limitations on our turn around time for > things at the moment and they are only going to get worse as we have > newer releases that will get the delta rpms. At the same time, the > same people are getting raked over the coals for not getting bits > out fast enough. > > We are working on this from a rel-eng standpoint, but advocating for > a bit of discretion on what should be pushed as an update is not > entirely a bad thing. Personally, I would love it if package > maintainers slowed down a bit. But it's not an end solution. > > So certainly the leadership, defined as FESCo and FPB, is not in > conflict with the contributor's apparent direction. As far as I can > see, they haven't made a statement either way. If there is a group > that was pushing for something that ran contrary, it was Rel-Eng. > And given that Jesse and I both just said we're going to basically > stop begging people to slow down on updates, I think even that group > is trying to figure out a way to make things better. Hell, that's > partly what this FAD is all about. If the FAD identifies some tangibles (hardware, etc.) that would help alleviate some of the time problems, I can tell you that Spot and I will do our best to procure them. From what I've heard others describe up until now, it doesn't seem like there's one clear roadblock in that regard -- just a huge mountain of tasks that our current systems have to chug through for composing, and no matter how you slice it, it takes a lot of time and I/O bandwidth. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From mschwendt at gmail.com Wed Jun 3 13:00:57 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Jun 2009 15:00:57 +0200 Subject: Maintainer Responsibilities In-Reply-To: <4A266755.6080904@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <20090603113809.3ad3d992@faldor.intranet> <4A266755.6080904@freenet.de> Message-ID: <20090603150057.7d9fc5db@faldor.intranet> On Wed, 03 Jun 2009 14:06:45 +0200, Ralf wrote: > I consider users (esp. bug reporters) not to be "the dumb pigs eating > the hog wash they get for free", or "clueless comsumer masses" aborbing > anything they don't pay for with money, but them to be the foundation of > your work and them to be valuable business partners, paying in > immaterial payment (e.g. feedback, such as bug reports). That's an idealistic [over-simplified] point of view which I don't want to agree with. There is no clear relationship, such as a seller and a purchaser (and the "customer is king" guideline doesn't apply), since the person who produces the packages may be the one to _give_ more than he _gets_ in return by the users. Or vice versa. All that's clear to me is that the packager fills the role of a "provider", providing packaging services, and certain feedback from some package users may help with improving the quality of the provided product. In turn the provider ought to have interest in such an improvement and in boosting the relationship with the package users. Preferably, users with strong interest in a particular Fedora package sign up at the Fedora Account System, so they can subscribe to a package's watchbugzilla and watchcommit channels. From jwboyer at gmail.com Wed Jun 3 13:01:34 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 3 Jun 2009 09:01:34 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <20090603125548.GK3551@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> <20090603001532.GN3095@hansolo.jdub.homelinux.org> <20090603125548.GK3551@localhost.localdomain> Message-ID: <20090603130134.GS3095@hansolo.jdub.homelinux.org> On Wed, Jun 03, 2009 at 08:55:48AM -0400, Paul W. Frields wrote: >On Tue, Jun 02, 2009 at 08:15:32PM -0400, Josh Boyer wrote: >> We are facing some real limitations on our turn around time for >> things at the moment and they are only going to get worse as we have >> newer releases that will get the delta rpms. At the same time, the >> same people are getting raked over the coals for not getting bits >> out fast enough. >> >> We are working on this from a rel-eng standpoint, but advocating for >> a bit of discretion on what should be pushed as an update is not >> entirely a bad thing. Personally, I would love it if package >> maintainers slowed down a bit. But it's not an end solution. >> >> So certainly the leadership, defined as FESCo and FPB, is not in >> conflict with the contributor's apparent direction. As far as I can >> see, they haven't made a statement either way. If there is a group >> that was pushing for something that ran contrary, it was Rel-Eng. >> And given that Jesse and I both just said we're going to basically >> stop begging people to slow down on updates, I think even that group >> is trying to figure out a way to make things better. Hell, that's >> partly what this FAD is all about. > >If the FAD identifies some tangibles (hardware, etc.) that would help >alleviate some of the time problems, I can tell you that Spot and I >will do our best to procure them. From what I've heard others >describe up until now, it doesn't seem like there's one clear >roadblock in that regard -- just a huge mountain of tasks that our >current systems have to chug through for composing, and no matter how >you slice it, it takes a lot of time and I/O bandwidth. Yep. As a simple test, We'd like to do some experiments to see if running updates pushes and rawhide composes on separate boxen makes things worse or better or about the same. I don't think we need additional procured hardware for that, just a cloned guest which I already have a ticket opened for. Oh, and time. Always need time. If you or spot could procure time, let me know ;) josh From rc040203 at freenet.de Wed Jun 3 13:46:08 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 03 Jun 2009 15:46:08 +0200 Subject: Maintainer Responsibilities In-Reply-To: <20090603150057.7d9fc5db@faldor.intranet> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <20090603113809.3ad3d992@faldor.intranet> <4A266755.6080904@freenet.de> <20090603150057.7d9fc5db@faldor.intranet> Message-ID: <4A267EA0.20600@freenet.de> Michael Schwendt wrote: > On Wed, 03 Jun 2009 14:06:45 +0200, Ralf wrote: > >> I consider users (esp. bug reporters) not to be "the dumb pigs eating >> the hog wash they get for free", or "clueless comsumer masses" aborbing >> anything they don't pay for with money, but them to be the foundation of >> your work and them to be valuable business partners, paying in >> immaterial payment (e.g. feedback, such as bug reports). > > That's an idealistic [over-simplified] point of view which I don't want to > agree with. Well, whether it's idealistic or not is irrelevant. It's one of the foundations of open source. Or less abstract: I stopped reporting bugs against Fedora's evolution, because its @RH maintainer preferred to close bugs and tried to push me around to upstream. Wrt. evolution, I was an ordinary user and am not interested in getting further involved. As simple as it is: I felt sufficiently pissed of by this guy to leave him and his upstream alone, ... so be it, he wanted it this way. There are other packages and packagers (noteworthy many of the @RH) who exhibit the same "push reporters around" behavior. So is still anybody wondering why Fedora is permanently lacking people? This is one cause. Now combine this with the "report bugs" phrases certain people tend to reiterate? ... Experiences, such as the one I encountered with the evolution maintainer, are the cause why at least some people sense a foul taste when listening to them. Ralf From mclasen at redhat.com Wed Jun 3 13:55:29 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 03 Jun 2009 09:55:29 -0400 Subject: Orphaning some packages (brasero, transmission and more) In-Reply-To: <4A266992.6070900@poolshark.org> References: <4A262456.9050203@poolshark.org> <20090603114802.GQ3095@hansolo.jdub.homelinux.org> <4A266992.6070900@poolshark.org> Message-ID: <1244037329.3470.0.camel@localhost.localdomain> On Wed, 2009-06-03 at 14:16 +0200, Denis Leroy wrote: > On 06/03/2009 01:48 PM, Josh Boyer wrote: > > On Wed, Jun 03, 2009 at 09:20:54AM +0200, Denis Leroy wrote: > >> In an effort to focus more on FOSS upstream development, I am going to > >> be orphaning some of my Fedora packages in the near future, starting > >> with this first batch. > >> > >> brasero (high-maintenance) > > > > Wait... didn't we just make this the default CD/DVD buring application in > > the Fedora spin? > > > > http://fedoraproject.org/wiki/Features/Gnome2_26 > > > > And now it's orphaned? > > I merely want to transfer ownership to somebody new. Matthias Clasen and > Bastien Nocera are already acting co-maintainers, and so I'm waiting to > hear from them before transferring ownership, in case one of them has a > strong desire to take over the package... I don't have a strong desire to own any package... but if nobody else picks it up, I will find an owner for it. From sgrubb at redhat.com Wed Jun 3 14:01:58 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 3 Jun 2009 10:01:58 -0400 Subject: Maintainer Responsibilities In-Reply-To: <200906021817.04327.smparrish@gmail.com> References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> Message-ID: <200906031001.58178.sgrubb@redhat.com> On Tuesday 02 June 2009 06:17:02 pm Steven M. Parrish wrote: > This is from the official Bugzappers page > https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#Upstreamin So, this raises the question about bugzappers. Should they be making the determination for maintainers that the reporter should have taken the issue upstream? Do bug zappers take into consideration the severity of the bug before pushing someone upstream? > The bug is not a packaging bug, the package maintainer has no plans to work > on this in the near future, and there is an upstream bug tracking system > other than the Red Hat Bugzilla. Is there communication between maintainer and bugzapper before doing this? > Maintainers should be free to either fix it locally (time permitting) and > upstream the patch or request that the bug be filed at the upstream > projects tracker for the upstream developers to resolve it. > > If it is sent upstream the bug is closed as UPSTREAM and our local report > is cross-referenced to the upstream one. That way the maintainer and all > interested parties can follow its progress. Not if its closed. How would I be notified that the fix is in Fedora? If the bug is severe enough, shouldn't the upstream commit be applied to Fedora's package and the package pushed out for testing? Is all this going to happen if the bug is closed? -Steve From rvinyard at cs.nmsu.edu Wed Jun 3 14:02:04 2009 From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.) Date: Wed, 3 Jun 2009 08:02:04 -0600 (MDT) Subject: welcome to fedora In-Reply-To: <385866f0905310939w3a9ed91co8b3dd1805cd81c39@mail.gmail.com> References: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> <4A225521.7020305@fedoraproject.org> <64b14b300905310447o1f001c58u36b43d61f1b269e6@mail.gmail.com> <385866f0905310939w3a9ed91co8b3dd1805cd81c39@mail.gmail.com> Message-ID: <54379.155.148.81.31.1244037724.squirrel@intranet.cs.nmsu.edu> Muayyad AlSadi wrote: > maybe a trivial pygtk script ? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > +1 I was just about to suggest that. And, if alot of the text items are not embedded directly (i.e. loaded from /usr/share/welcome/ or something) they can be made multi-lingual, changed easily on each release, and even changed by re-spins. From limb at jcomserv.net Wed Jun 3 14:09:34 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 03 Jun 2009 09:09:34 -0500 Subject: Orphaning some packages (brasero, transmission and more) In-Reply-To: <1244037329.3470.0.camel@localhost.localdomain> References: <4A262456.9050203@poolshark.org> <20090603114802.GQ3095@hansolo.jdub.homelinux.org> <4A266992.6070900@poolshark.org> <1244037329.3470.0.camel@localhost.localdomain> Message-ID: <4A26841E.4060604@jcomserv.net> Matthias Clasen wrote: > On Wed, 2009-06-03 at 14:16 +0200, Denis Leroy wrote: > >> On 06/03/2009 01:48 PM, Josh Boyer wrote: >> >>> On Wed, Jun 03, 2009 at 09:20:54AM +0200, Denis Leroy wrote: >>> >>>> In an effort to focus more on FOSS upstream development, I am going to >>>> be orphaning some of my Fedora packages in the near future, starting >>>> with this first batch. >>>> >>>> brasero (high-maintenance) >>>> >>> Wait... didn't we just make this the default CD/DVD buring application in >>> the Fedora spin? >>> >>> http://fedoraproject.org/wiki/Features/Gnome2_26 >>> >>> And now it's orphaned? >>> >> I merely want to transfer ownership to somebody new. Matthias Clasen and >> Bastien Nocera are already acting co-maintainers, and so I'm waiting to >> hear from them before transferring ownership, in case one of them has a >> strong desire to take over the package... >> > > I don't have a strong desire to own any package... but if nobody else > picks it up, I will find an owner for it. > > See my previous message re Xavier Lamien . . . -- in your fear, speak only peace in your fear, seek only love -d. bowie From jlaska at redhat.com Wed Jun 3 14:10:26 2009 From: jlaska at redhat.com (James Laska) Date: Wed, 03 Jun 2009 10:10:26 -0400 Subject: Fedora 11 Test Day survey Message-ID: <1244038226.19989.45.camel@flatline.devel.redhat.com> Greetings, The Fedora QA team would like your feedback on Fedora 11 Test Days. You may have seen Adam Williamson's planet post [1] kicking off Fedora 12 Test Day planning. We're interested in identifying areas for improvement to increase participation and improve effectiveness. Please take 10-15 minutes to answer any/all of the questions below. You may reply to the mailing list, or send feedback directly to me. Your responses to this survey are instrumental in making Fedora 12 Test Days successful. Many thanks to Chris Ward for his help in getting things moving with the survey questions! =================================== 1. How did you find out about Fedora Test Days? 2. Was sufficient documentation available to help you participate in a Fedora Test Day? If not, what did you find missing or in need of improvement? 3. Did you encounter any obstacles preventing participation in Fedora test Days? How might they have been avoided? Did you discover any workaround? 4. Were you able to locate and download installation media for testing? Did it function as expected? 5. What follow-up actions do you expect after the Test Day? Are your expectations currently being met? 6. Would you participate again in future Fedora Test Days? 7. Do you have any more general comments or any suggestions for improving future test days? =================================== Thanks, James [1] http://www.happyassassin.net/2009/06/02/whats-goin-on-f12-test-days/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From denis at poolshark.org Wed Jun 3 14:12:00 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 03 Jun 2009 16:12:00 +0200 Subject: Orphaning some packages (brasero, transmission and more) In-Reply-To: <1244037329.3470.0.camel@localhost.localdomain> References: <4A262456.9050203@poolshark.org> <20090603114802.GQ3095@hansolo.jdub.homelinux.org> <4A266992.6070900@poolshark.org> <1244037329.3470.0.camel@localhost.localdomain> Message-ID: <4A2684B0.8050008@poolshark.org> On 06/03/2009 03:55 PM, Matthias Clasen wrote: > On Wed, 2009-06-03 at 14:16 +0200, Denis Leroy wrote: >> On 06/03/2009 01:48 PM, Josh Boyer wrote: >>> On Wed, Jun 03, 2009 at 09:20:54AM +0200, Denis Leroy wrote: >>>> In an effort to focus more on FOSS upstream development, I am going to >>>> be orphaning some of my Fedora packages in the near future, starting >>>> with this first batch. >>>> >>>> brasero (high-maintenance) >>> Wait... didn't we just make this the default CD/DVD buring application in >>> the Fedora spin? >>> >>> http://fedoraproject.org/wiki/Features/Gnome2_26 >>> >>> And now it's orphaned? >> I merely want to transfer ownership to somebody new. Matthias Clasen and >> Bastien Nocera are already acting co-maintainers, and so I'm waiting to >> hear from them before transferring ownership, in case one of them has a >> strong desire to take over the package... > > I don't have a strong desire to own any package... but if nobody else > picks it up, I will find an owner for it. I've released ownership. Xavier is the new owner. From dpierce at redhat.com Wed Jun 3 14:14:44 2009 From: dpierce at redhat.com (Darryl L. Pierce) Date: Wed, 3 Jun 2009 10:14:44 -0400 Subject: Maintainer Responsibilities In-Reply-To: <200906031001.58178.sgrubb@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> Message-ID: <20090603141444.GB3477@mcpierce-laptop.rdu.redhat.com> On Wed, Jun 03, 2009 at 10:01:58AM -0400, Steve Grubb wrote: > Not if its closed. How would I be notified that the fix is in Fedora? If the bug > is severe enough, shouldn't the upstream commit be applied to Fedora's package > and the package pushed out for testing? Is all this going to happen if the bug > is closed? I might be saying something most people understand or accept, but it strikes me the flow should be: 1. User reports bug against Fedora component. 2. Maintainer reviews the BZ. 2a. If it's packaging related, then the bug's handled with an update. 3. A bug is opened upstream, and the BZ somehow references that ticket. 4a. The maintainer can also work on a fix and submit that patch upstream. 4b. The patch can be applied in Fedora in the interim to fix the problem. 5. When upstream releases a fixed version, then a new release is made in Fedora, and the patch discarded from CVS. The point being, the Fedora user shouldn't have to go outside of Fedora to report their bugs. IMO the package maintainer is the person who should be liaison between the user and upstream and should be actively aware and involved in those bug reports and fixes. In steps 2-5 the maintainer's always a part of what's going on upstream. They don't have to be actively involved in solving the bug, but they do need to be aware of reported bugs by Fedora users, as well as bugs reported by other distros so they can proactively alert Fedora users. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste n? B?arla cliste. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ngompa13 at gmail.com Wed Jun 3 14:21:15 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Wed, 3 Jun 2009 09:21:15 -0500 Subject: Fedora 11 Test Day survey In-Reply-To: <1244038226.19989.45.camel@flatline.devel.redhat.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> Message-ID: <8278b1b0906030721l7675f3e7h94c24f9397a19232@mail.gmail.com> On Wed, Jun 3, 2009 at 9:10 AM, James Laska wrote: > Greetings, > > The Fedora QA team would like your feedback on Fedora 11 Test Days. You > may have seen Adam Williamson's planet post [1] kicking off Fedora 12 > Test Day planning. We're interested in identifying areas for > improvement to increase participation and improve effectiveness. > > Please take 10-15 minutes to answer any/all of the questions below. You > may reply to the mailing list, or send feedback directly to me. Your > responses to this survey are instrumental in making Fedora 12 Test Days > successful. > > Many thanks to Chris Ward for his help in getting things moving with the > survey questions! > > =================================== > > 1. How did you find out about Fedora Test Days? > > 2. Was sufficient documentation available to help you participate in a > Fedora Test Day? If not, what did you find missing or in need of > improvement? > > 3. Did you encounter any obstacles preventing participation in Fedora > test Days? How might they have been avoided? Did you discover any > workaround? > > 4. Were you able to locate and download installation media for testing? > Did it function as expected? > > 5. What follow-up actions do you expect after the Test Day? Are your > expectations currently being met? > > 6. Would you participate again in future Fedora Test Days? > > 7. Do you have any more general comments or any suggestions for > improving future test days? > > =================================== > > Thanks, > James > > [1] http://www.happyassassin.net/2009/06/02/whats-goin-on-f12-test-days/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I'll answer these in order. 1. I got lucky when I looked in the mailing list. 2. Yes there was good enough docs for the test days to help me participate. 3. My biggest obstacle with test days was that they were not planned early enough. Most of the test days seemed to be planned less than 48 hours ahead of time. If test days were planned better, I could actually participate more. 4. Yes, I was able to download them. No, the media didn't work. It generally hung the computer, but that's not the fault of the test days. 5. I would expect a recap of the testing efforts so that Fedora people could analyze what the issues were, track them, and fix them. I suppose they are. The mailing list enabled them to do this, but there was no formal method of doing it. 6. If they were planned better, then maybe I would be able to set aside time to do them. I would like to participate in future Test Days. 7. Set up a reporting center just for Test Day feedback. Using the wiki is definitely not good enough. Additionally, Do not limit the test days to people subscribed to the mailing list. Take a page from Mozilla's books and announce those test days to the world. Unfortunately, to do that, test days need to be planned better. Hopefully this feedback helps :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From darrellpf at gmail.com Wed Jun 3 14:20:47 2009 From: darrellpf at gmail.com (darrell pfeifer) Date: Wed, 3 Jun 2009 07:20:47 -0700 Subject: Maintainer Responsibilities In-Reply-To: <4A267EA0.20600@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <20090603113809.3ad3d992@faldor.intranet> <4A266755.6080904@freenet.de> <20090603150057.7d9fc5db@faldor.intranet> <4A267EA0.20600@freenet.de> Message-ID: On Wed, Jun 3, 2009 at 06:46, Ralf Corsepius wrote: > Michael Schwendt wrote: > >> On Wed, 03 Jun 2009 14:06:45 +0200, Ralf wrote: >> >> I consider users (esp. bug reporters) not to be "the dumb pigs eating the >>> hog wash they get for free", or "clueless comsumer masses" aborbing anything >>> they don't pay for with money, but them to be the foundation of your work >>> and them to be valuable business partners, paying in immaterial payment >>> (e.g. feedback, such as bug reports). >>> >> >> That's an idealistic [over-simplified] point of view which I don't want to >> agree with. >> > Well, whether it's idealistic or not is irrelevant. It's one of the > foundations of open source. > > Or less abstract: > I stopped reporting bugs against Fedora's evolution, because its @RH > maintainer preferred to close bugs and tried to push me around to upstream. > Wrt. evolution, I was an ordinary user and am not interested in getting > further involved. > > As simple as it is: I felt sufficiently pissed of by this guy to leave him > and his upstream alone, ... so be it, he wanted it this way. > > There are other packages and packagers (noteworthy many of the @RH) who > exhibit the same "push reporters around" behavior. > > So is still anybody wondering why Fedora is permanently lacking people? > This is one cause. > > Now combine this with the "report bugs" phrases certain people tend to > reiterate? ... Experiences, such as the one I encountered with the evolution > maintainer, are the cause why at least some people sense a foul taste when > listening to them. > As a bug reported I've come to peace with the concept that maintainers and upstream have personalities too. Sometimes people are happy to see bug reports, sometimes they ignore them and sometimes they seem to go out of their way to be unhelpful. For the same reason it can be difficult to report bugs since different packages can have wide variations in the amount of information they want you to collect, and strange incantations and commands you've never seen before. (Often of the "gee I never knew that was even possible" variety). The ones that get to me are 1) Bugs return over and over again with each new latest and greatest version or rewrite of previously working code. A few years ago it was USB devices that would mount one day on the desktop, then not mount, then mount, etc. Today it might be screen display powers off (or doesn't), battery level is correct (or reports battery-critical), sound works (or doesn't), compiz works (or doesn't), boot with graphic boot (or nomodeset yet again). 2) Bugs that get no attention, not even an acknowledgement. 3) Bugs where the maintainer (or triager) seems to go out of their way to be completely unhelpful. I think it is easy to forget how difficult and time-consuming it can be to produce a really good bug report. I'd say that 9 out of 10 bugs that I report leave me feeling that the not much was accomplished. It is that tenth bug report, the one where there is a reasonable interaction, where a problem gets resolved (and doesn't seem to reappear) that keeps me doing them. darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at cchtml.com Wed Jun 3 14:28:00 2009 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 03 Jun 2009 09:28:00 -0500 Subject: Fedora 11 Test Day survey In-Reply-To: <1244038226.19989.45.camel@flatline.devel.redhat.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> Message-ID: <4A268870.9090904@cchtml.com> James Laska wrote: > > 1. How did you find out about Fedora Test Days? Mailing list posting. > > 2. Was sufficient documentation available to help you participate in a > Fedora Test Day? If not, what did you find missing or in need of > improvement? Yes, I found everything I needed on the corresponding wiki page. > > 3. Did you encounter any obstacles preventing participation in Fedora > test Days? How might they have been avoided? Did you discover any > workaround? Time. Test days are sometimes not announced early enough for me, or I do not have them marked on my calendar so I forget about them. > > 4. Were you able to locate and download installation media for testing? > Did it function as expected? Yes. Yes. > > 5. What follow-up actions do you expect after the Test Day? Are your > expectations currently being met? I expected an analysis of the data received either by a mailing list post or an update on the wiki page. I saw neither and thought my data was just thrown into the wind. My expectations were not met. > > 6. Would you participate again in future Fedora Test Days? Yes. > > 7. Do you have any more general comments or any suggestions for > improving future test days? > Please get the Fedora calendar server going. I'd love to subscribe Thunderbird/Lightning to the QA calendar. People would be able to know about and participate in test days (or any QA event) without a mailing list subscription or a 24/7 IRC connection as it seems some things are discussed solely on IRC. From tcallawa at redhat.com Wed Jun 3 14:38:45 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 03 Jun 2009 10:38:45 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <20090603130134.GS3095@hansolo.jdub.homelinux.org> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> <20090603001532.GN3095@hansolo.jdub.homelinux.org> <20090603125548.GK3551@localhost.localdomain> <20090603130134.GS3095@hansolo.jdub.homelinux.org> Message-ID: <4A268AF5.1030200@redhat.com> On 06/03/2009 09:01 AM, Josh Boyer wrote: > Oh, and time. Always need time. If you or spot could procure time, let me > know ;) Man, if I knew how to do that, I'd be a lot wealthier than I am now. ;) ~spot From rawhide at fedoraproject.org Wed Jun 3 14:43:15 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 3 Jun 2009 14:43:15 +0000 (UTC) Subject: rawhide report: 20090603 changes Message-ID: <20090603144315.44C351F8217@releng2.fedora.phx.redhat.com> Compose started at Wed Jun 3 06:15:03 UTC 2009 Updated Packages: anaconda-11.5.0.59-1.fc11 ------------------------- * Tue Jun 02 2009 Chris Lumens - 11.5.0.59-1 - Do not show disabled repos such as rawhide during the install (#503798). (jkeating) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 1 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From sundaram at fedoraproject.org Wed Jun 3 14:46:43 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 03 Jun 2009 20:16:43 +0530 Subject: Fedora 11 Test Day survey In-Reply-To: <1244038226.19989.45.camel@flatline.devel.redhat.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> Message-ID: <4A268CD3.2030704@fedoraproject.org> On 06/03/2009 07:40 PM, James Laska wrote: > 1. How did you find out about Fedora Test Days? > Mailing list, forum and blog posts > 2. Was sufficient documentation available to help you participate in a > Fedora Test Day? If not, what did you find missing or in need of > improvement? Generally, yes. It was sufficient. > 3. Did you encounter any obstacles preventing participation in Fedora > test Days? How might they have been avoided? Did you discover any > workaround? It went smoothly > 4. Were you able to locate and download installation media for testing? > Did it function as expected? Yes and yes > 5. What follow-up actions do you expect after the Test Day? Are your > expectations currently being met? Yes. Although I was hoping there would be a test day for Ext4. > 6. Would you participate again in future Fedora Test Days? Intend to > 7. Do you have any more general comments or any suggestions for > improving future test days? It would be useful to incorporate test days directly in the release schedule listed in the wiki so people can know well ahead of time what is the plan and participate accordingly. The last minute rush in some of the test days seems avoidable. Rahul From johannbg at hi.is Wed Jun 3 15:35:39 2009 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 03 Jun 2009 15:35:39 +0000 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <4A268AF5.1030200@redhat.com> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> <20090603001532.GN3095@hansolo.jdub.homelinux.org> <20090603125548.GK3551@localhost.localdomain> <20090603130134.GS3095@hansolo.jdub.homelinux.org> <4A268AF5.1030200@redhat.com> Message-ID: <4A26984B.9030206@hi.is> On 06/03/2009 02:38 PM, Tom "spot" Callaway wrote: > On 06/03/2009 09:01 AM, Josh Boyer wrote: > >> Oh, and time. Always need time. If you or spot could procure time, let me >> know ;) >> > Man, if I knew how to do that, I'd be a lot wealthier than I am now. ;) > > Extend the day to 36 hours Gosh feel like a millionaire already Sleep is overrated anyway. :) Johann "who get's enough sleep when he's dead" Gudmundsson -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 356 bytes Desc: not available URL: From smparrish at gmail.com Wed Jun 3 15:37:18 2009 From: smparrish at gmail.com (Steven M. Parrish) Date: Wed, 3 Jun 2009 11:37:18 -0400 Subject: Maintainer Responsibilities In-Reply-To: <200906031001.58178.sgrubb@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> Message-ID: <200906031137.19294.smparrish@gmail.com> > On Tuesday 02 June 2009 06:17:02 pm Steven M. Parrish wrote: > > This is from the official Bugzappers page > > https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#Upstream > >in > > So, this raises the question about bugzappers. Should they be making the > determination for maintainers that the reporter should have taken the issue > upstream? Do bug zappers take into consideration the severity of the bug > before pushing someone upstream? > > > The bug is not a packaging bug, the package maintainer has no plans to > > work on this in the near future, and there is an upstream bug tracking > > system other than the Red Hat Bugzilla. > > Is there communication between maintainer and bugzapper before doing this? I can only speak for myself and not the other triagers. I work solely on KDE issues because in addition to triage I also maintain several KDE packages and work closely with the other maintainers. The upstream method we use was discussed and agreed to as the best solution to make sure the issues get to where they need to be. I would suggest that any triager get to know the packages they triage and the maintainers and together agree to how the wish to handle this issue. > > > Maintainers should be free to either fix it locally (time permitting) and > > upstream the patch or request that the bug be filed at the upstream > > projects tracker for the upstream developers to resolve it. > > > > If it is sent upstream the bug is closed as UPSTREAM and our local report > > is cross-referenced to the upstream one. That way the maintainer and all > > interested parties can follow its progress. > > Not if its closed. How would I be notified that the fix is in Fedora? If > the bug is severe enough, shouldn't the upstream commit be applied to > Fedora's package and the package pushed out for testing? Is all this going > to happen if the bug is closed? > This is a good point. That is why we want the report filed upstream by the reporter. They are then cc'd to the upstream report and can follow it as it progresses. In the future I will work to make sure that the local BZ report is kept updated with the status in Fedora. Many people have mentioned that it is not right to ask the users to file their bug reports upstream. I ask why not? Obviously by reporting the issue to us they feel it is important and needs to be addressed. The took the time to open a RH bugzilla account to file the report, so I don't see why they can't take 60 seconds and open an upstream account as well. (Open-ID would solve that issue.) If the issue is important to them they will do it. If the reporter does not file it upstream and we feel we have enough information to go on, I will file it upstream to make sure the issue is addressed. This is an issue that needs to be addressed by the BugZappers group and a proposal taken before FESCO so an official policy can be agreed upon. I'll place this on the agenda for the next meeting. SMP From andreas at bawue.net Wed Jun 3 15:50:00 2009 From: andreas at bawue.net (Andreas Thienemann) Date: Wed, 3 Jun 2009 17:50:00 +0200 (CEST) Subject: Fedora 11 Test Day survey In-Reply-To: <1244038226.19989.45.camel@flatline.devel.redhat.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> Message-ID: On Wed, 3 Jun 2009, James Laska wrote: > =================================== > > 1. How did you find out about Fedora Test Days? Planet.fp.o > 2. Was sufficient documentation available to help you participate in a > Fedora Test Day? If not, what did you find missing or in need of > improvement? Sure. But I'm running rawhide anyway on several machines and am probably not really representing the average user. > 3. Did you encounter any obstacles preventing participation in Fedora > test Days? How might they have been avoided? Did you discover any > workaround? Feature rewrites such as the storage rewrite has made installation tests basically infeasable as the installer always broke during partitioning on my systems. Feedback from the developers was great and instant and we identified and fixed several of these problems on the same day. This can be considered a success of the test day but in my case, we never came around to testing later stages of anaconda. The live CD might help in some cases e.g. a nouveau test but would be mostly useless for installer-related tests. I guess more care should be taken into identifying "known-good" snapshots and testing with these where we made certain that there are no other, unrelated bugs interfering with the aim of the test day. > 4. Were you able to locate and download installation media for testing? > Did it function as expected? Never tried livecds but yeah, my PXE server is doing great for installs. Thank you for asking. *g* > 5. What follow-up actions do you expect after the Test Day? Are your > expectations currently being met? I'd like to see bugs fixed as the follow-up action. Some have been verified and put up as F11Blocker or F11Target with not much more happening. In some cases the Needinfo requests for rechecking or further info came up only a few days earlier and I haven't gotten around to them yet as the test systems are not always available to me. Faster turnaround times would be great there as I have easier access to the machines in question. Some of my bugs have not been fixed yet, but I have to admit that these are unusually difficult to track down or fix. :) > 6. Would you participate again in future Fedora Test Days? Sure, time permitting. > 7. Do you have any more general comments or any suggestions for > improving future test days? I strongly support the newfound focus on QA. I think I mentioned that to Adam on IRC repeatedly and wrote something about it in my FESCO nomination questionare as well but I'll repeat that: It has long been common opinion that Fedora is spending too much time on developing exciting new features while not spending any on ironing out the bugs. Certain show-stoppers have been persisting through 4 releases and more or some bugs "are now reaching the age where they should seriosly start thinking about attending kindergarden". While this is a great quote, due to its humourous value, it shows a real problem we're having. This has hurt our marketing tremendously. Seeing news about Test Days, revitalized QA etc. helps us fighting this impression. So thank you for your work. regards, andreas From jlaska at redhat.com Wed Jun 3 15:55:07 2009 From: jlaska at redhat.com (James Laska) Date: Wed, 03 Jun 2009 11:55:07 -0400 Subject: Fedora 11 Test Day survey In-Reply-To: <4A268CD3.2030704@fedoraproject.org> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> <4A268CD3.2030704@fedoraproject.org> Message-ID: <1244044507.2610.45.camel@flatline.devel.redhat.com> Thanks for the feedback! On Wed, 2009-06-03 at 20:16 +0530, Rahul Sundaram wrote: > > > 5. What follow-up actions do you expect after the Test Day? Are > your > > expectations currently being met? > > Yes. Although I was hoping there would be a test day for Ext4. I was too, but there were some schedule conflicts which kept it from happening on the QA side. In the end the only test day topic with focus on ext4 was around changing the anaconda default filesystem to ext4 (https://fedoraproject.org/wiki/QA/Test_Days/2009-02-05). Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mschwendt at gmail.com Wed Jun 3 15:59:19 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Jun 2009 17:59:19 +0200 Subject: [Bug 484862] GConf2-dbus : Conflicts with other packages In-Reply-To: <200906031545.n53FjRYb004944@bz-web2.app.phx.redhat.com> References: <200906031545.n53FjRYb004944@bz-web2.app.phx.redhat.com> Message-ID: <20090603175919.5a0f5d68@faldor.intranet> > https://bugzilla.redhat.com/show_bug.cgi?id=484862 > > > > > > --- Comment #2 from John (J5) Palmieri 2009-06-03 11:45:26 EDT --- > Of course it conflicts with GConf2. It is GConf2 with a patch. Pretty much > binary ABI compatible unless the two have diverged recently. It shouldn't be > used beyond OLPC and even there with the fact that they are getting more memory > and disk space they should just start using the Orbit2 dependency. It was a > hack to reduce dependencies while still letting GNOME packages run without > modification. > > DConf is the next generation DBus GConf and should be parallel installable once > it is released (and accepted by GNOME). Why are the relevant Obsoletes missing (commented out)? These packages are available to package management tools. The Fedora guidelines disallow implicit conflicts. From jspaleta at gmail.com Wed Jun 3 15:59:35 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 3 Jun 2009 07:59:35 -0800 Subject: welcome to fedora In-Reply-To: <64b14b300905310447o1f001c58u36b43d61f1b269e6@mail.gmail.com> References: <64b14b300905290413m222c25b1v4ab68cff9481d75b@mail.gmail.com> <4A225521.7020305@fedoraproject.org> <64b14b300905310447o1f001c58u36b43d61f1b269e6@mail.gmail.com> Message-ID: <604aa7910906030859g69b10c68w30e0899e0154e22c@mail.gmail.com> On Sun, May 31, 2009 at 3:47 AM, Valent Turkovic wrote: > Which tools would you recommend somebody uses to make this welcome screen? You should probably talk to the people who craft the Live Desktop image and the harddrive install that results from it. If the point of this is to target new users with little to no prior Fedora experience, then it will need to be incorporated into the live desktop experience as a priority. I wouldn't shoot for trying to figure out how to make it work everywhere for all possible install scenarios on the first attempt. Craft something that works for the Live Desktop image for F12, and then take what you learn from that and build something better for F13. -jef From sundaram at fedoraproject.org Wed Jun 3 16:13:40 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 03 Jun 2009 21:43:40 +0530 Subject: Fedora 11 Test Day survey In-Reply-To: <1244044507.2610.45.camel@flatline.devel.redhat.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> <4A268CD3.2030704@fedoraproject.org> <1244044507.2610.45.camel@flatline.devel.redhat.com> Message-ID: <4A26A134.6000602@fedoraproject.org> On 06/03/2009 09:25 PM, James Laska wrote: > Thanks for the feedback! > > On Wed, 2009-06-03 at 20:16 +0530, Rahul Sundaram wrote: >> >>> 5. What follow-up actions do you expect after the Test Day? Are >> your >>> expectations currently being met? >> >> Yes. Although I was hoping there would be a test day for Ext4. > > I was too, but there were some schedule conflicts which kept it from > happening on the QA side. In the end the only test day topic with focus > on ext4 was around changing the anaconda default filesystem to ext4 > (https://fedoraproject.org/wiki/QA/Test_Days/2009-02-05). With concerns over Ext4, I did my own testing and didn't find any issues and now run with Ext4 on this laptop except for /boot. However that is a key piece and it would have raised the confidence level to have a dedicated test day. Having test days built into the release schedule would help everyone provide more feedback and I (and likely others) would have raised this earlier than I did in that case. IMO, the most important thing the recent QA efforts including test days having brought in is a change in general mentality. Earlier when users would hit some regressions or new bugs, they would come up to the forum and get told by others to expect breakage since Fedora is meant to be that way. I found that a very dangerous stand point since it effectively means that over time, we will get lower quality with not enough people raising a concern since they have been told to live with it. Now with the QA efforts, even if users do hit bugs which I am sure they will, many would atleast be aware that a community is involved in helping to avoid them and fix them otherwise. We are more visibly concerned about quality now than ever before. Last week in distrowatch, there was a question raised on the Fedora release delays as to whether such delays are a strength or a weakness http://distrowatch.com/weekly.php?issue=20090601&mode=67#comments You can find a very consistent feedback from everyone that they appreciate the stand point of willing to delay a release if needed. While I think delays *are* a sign of a weakness at some level, it is good to prioritize critical fixes over a rigid schedule. Even without all the other benefits, the visibility in approach itself is worth all the effort you and others have put into this. Thanks. Rahul From mschwendt at gmail.com Wed Jun 3 16:37:08 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Jun 2009 18:37:08 +0200 Subject: chkrootkit looking for new maintainer Message-ID: <20090603183708.6cedfec0@faldor.intranet> I'm looking for somebody to become the "chkrootkit" package owner, preferably not anyone who just wants to increase the list of owned packages for some doubtful metrics. There are no open tickets for chkrootkit in Fedora. Last upstream release has been in Dec 2007. Upstream has been responsive, but not reliable with regard to merging non-Fedora-specific patches. -- Michael Schwendt Fedora release 10 (Cambridge) - Linux 2.6.27.24-170.2.68.fc10.i686 loadavg: 1.00 1.23 1.50 From jkeating at redhat.com Wed Jun 3 16:40:02 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 03 Jun 2009 09:40:02 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <20090603125548.GK3551@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> <20090603001532.GN3095@hansolo.jdub.homelinux.org> <20090603125548.GK3551@localhost.localdomain> Message-ID: <1244047202.8792.29.camel@localhost.localdomain> On Wed, 2009-06-03 at 08:55 -0400, Paul W. Frields wrote: > If the FAD identifies some tangibles (hardware, etc.) that would help > alleviate some of the time problems, I can tell you that Spot and I > will do our best to procure them. From what I've heard others > describe up until now, it doesn't seem like there's one clear > roadblock in that regard -- just a huge mountain of tasks that our > current systems have to chug through for composing, and no matter how > you slice it, it takes a lot of time and I/O bandwidth. Well upgrading all the buildsystem and storage system to 10gigE, and replacing the 10TB or so filer with something that has fantastically fast disks would certainly reduce the amount of I/O wait time, but that's going to cost a /lot/ of money. We are still trying to find where our bottlenecks are. We had a pretty good handle on things prior to delta rpms, but now we've gone from 3~ hour null composes (no changed packages) to nearly 9 hour null composes. There is obviously some optimization to be had here. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From limb at jcomserv.net Wed Jun 3 16:41:33 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 03 Jun 2009 11:41:33 -0500 Subject: chkrootkit looking for new maintainer In-Reply-To: <20090603183708.6cedfec0@faldor.intranet> References: <20090603183708.6cedfec0@faldor.intranet> Message-ID: <4A26A7BD.1020905@jcomserv.net> Michael Schwendt wrote: > I'm looking for somebody to become the "chkrootkit" package owner, > preferably not anyone who just wants to increase the list of owned > packages for some doubtful metrics. > > There are no open tickets for chkrootkit in Fedora. Last upstream release > has been in Dec 2007. Upstream has been responsive, but not reliable > with regard to merging non-Fedora-specific patches. > > I use it, and will take it if the co-maintainer isn't interested. -- in your fear, speak only peace in your fear, seek only love -d. bowie From fedora at camperquake.de Wed Jun 3 16:46:27 2009 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 3 Jun 2009 18:46:27 +0200 Subject: Orphaning Packages: audacious and dependencies Message-ID: <20090603184627.4297a25b@lain.camperquake.de> Hi. As I don't have the time to maintain audacious any more I'm orphaning the following packages: audacious audacious-plugins libmowgli mcs The last two are dependencies which, as far as I am aware, are used by nothing else. There is an accompanying package in the Voldemort Repository which contains the less free and more useful media codecs. That would be up for grabs, too, preferrably by the same person. There are several bugs open against the package, most of which will probably be fixed by the current upstream release. From choeger at cs.tu-berlin.de Wed Jun 3 17:01:25 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 03 Jun 2009 19:01:25 +0200 Subject: evolution header: Mime-version: 1.0 Message-ID: <1244048485.14565.10.camel@choeger6> Hi folks, I see a small problem with evolution when sending to mailinglists. Obviously evolution puts: Mime-version: 1.0 in the header, hypermail searches for MIME-version: and cannot find that string. So it adds it. In turn my mail provider bounces the return message that should be sent to me complaining about duplicate header field. So who is wrong here? Hypermail or evolution? Is non uppercase letter Mime-version allowed? Anyone knowing the answer? thanks christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From johannes at erdfelt.com Wed Jun 3 17:09:36 2009 From: johannes at erdfelt.com (Johannes Erdfelt) Date: Wed, 3 Jun 2009 10:09:36 -0700 Subject: evolution header: Mime-version: 1.0 In-Reply-To: <1244048485.14565.10.camel@choeger6> References: <1244048485.14565.10.camel@choeger6> Message-ID: <20090603170936.GH4742@sventech.com> On Wed, Jun 03, 2009, Christoph H?ger wrote: > I see a small problem with evolution when sending to mailinglists. > Obviously evolution puts: Mime-version: 1.0 in the header, hypermail > searches for MIME-version: and cannot find that string. So it adds it. > In turn my mail provider bounces the return message that should be sent > to me complaining about duplicate header field. > > So who is wrong here? Hypermail or evolution? Is non uppercase letter > Mime-version allowed? Anyone knowing the answer? Hypermail. Headers should be matched in a case insensitive manner. JE From lxtnow at gmail.com Wed Jun 3 17:28:36 2009 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Wed, 3 Jun 2009 19:28:36 +0200 Subject: mono-2.4 and ppc64 status In-Reply-To: <49ECEACA.1060304@gmail.com> References: <49ECEACA.1060304@gmail.com> Message-ID: <62bc09df0906031028t8915faei7ce16967e2d827b4@mail.gmail.com> On Mon, Apr 20, 2009 at 11:36 PM, Toshio Kuratomi wrote: > Mono-2.4 has been built for ppc64 in F11 and devel. ?So people should be > able to start rebuilding packages to include ppc64 as well as the other > arches. ?There's a few wrinkles to watch out for: > > 1) Packages with dependencies will have to be built in dependency order. > ?For instance, a lot of packages depend on the gtk-sharp2 bindings and > those haven't been built yet. > > 2) Because of the imminent release of F11 we're in a freeze state. ?This > ?means getting dependencies into the Fedora11 buildroot will require > people to request tagging explicitly. ?This also means that if you > rebuild your package for F11 with ppc64 support and later you have to > get this package tagged into the release, all of the packages it depends > on will need to be tagged in as well (otherwise your ppc64 build will > have broken deps). > > With these in mind, I'd recommend people start rebuilding their mono > packages on ppc64 in the devel branch. ?Keep track of the dependency > chain you encounter. ?Then perform your builds in the Fedora 11 branch > as updates after the release. ?I'm not a mono-sig member, though, so if > you guys decide something else makes sense, just be sure to come up with > a plan so we don't release with a bunch of broken dependencies. > Sound like I forgot to update this thread. Well, All packages which should depend on gtk-sharp2 and gnome-sharp has been rebuilt (list below). If i missed some please, step up or feel free to build them if you have Acls. list ---- gnome-sharp-2_24_0-4_fc11 gtksourceview2-sharp-1_0-5_svn89788_3_fc11 gecko-sharp2-0_13-3_fc11 webkit-sharp-0_2-2_fc11 monosim-1_3_0_2-3_fc11 avahi-0_6_25-2_fc11 mono-addins-0_4-7_20091702svn127062_1_fc11 gmime-2_4_3-5_fc11 bless-0_6_0-3_fc11 dbus-sharp-0_63-12_fc11 themonospot-0_7_1_1-3_fc11 ndesk-dbus-0_6_1a-5_fc11 gnome-subtitles-0_8-8_fc11 gnome-desktop-sharp-2_26_0-3_fc11 evolution-sharp-0_20_0-2_fc11 lat-1_2_3-7_fc11 gsf-sharp-0_8_1-10_fc11 mono-tools-2.4-9.fc11 bareftp-0:0.2.2-2.fc10.i386 gtk-sharp-1_0_10-23_fc11 ndesk-dbus-glib-0_4_1-5_fc11 beagle-0.3.9-8.fc11 notify-sharp-0.4.0-0.7.20080912svn.fc11 gnome-keyring-sharp-1.0.1-0.3.115768svn.fc11 podsleuth-0.6.3-3.fc11 tasque-0.1.8-3.fc11 tomboy muine f-spot ipod-sharp-0.8.1-3.fc11 mono-zeroconf-0.7.6-9.fc11 gnome-do-0.8.1.3-6.fc11 giver-0.1.8-5.fc11 gbrainy-1.1-4.fc11 -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From skvidal at fedoraproject.org Wed Jun 3 17:49:06 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 3 Jun 2009 13:49:06 -0400 (EDT) Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1244047202.8792.29.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> <20090603001532.GN3095@hansolo.jdub.homelinux.org> <20090603125548.GK3551@localhost.localdomain> <1244047202.8792.29.camel@localhost.localdomain> Message-ID: On Wed, 3 Jun 2009, Jesse Keating wrote: > On Wed, 2009-06-03 at 08:55 -0400, Paul W. Frields wrote: >> If the FAD identifies some tangibles (hardware, etc.) that would help >> alleviate some of the time problems, I can tell you that Spot and I >> will do our best to procure them. From what I've heard others >> describe up until now, it doesn't seem like there's one clear >> roadblock in that regard -- just a huge mountain of tasks that our >> current systems have to chug through for composing, and no matter how >> you slice it, it takes a lot of time and I/O bandwidth. > > Well upgrading all the buildsystem and storage system to 10gigE, and > replacing the 10TB or so filer with something that has fantastically > fast disks would certainly reduce the amount of I/O wait time, but > that's going to cost a /lot/ of money. We are still trying to find > where our bottlenecks are. We had a pretty good handle on things prior > to delta rpms, but now we've gone from 3~ hour null composes (no changed > packages) to nearly 9 hour null composes. There is obviously some > optimization to be had here. And the optimization there is fairly well known. We need to read in and not change the prestodelta file. It's on my short-ish createrepo list. -sv From mschwendt at gmail.com Wed Jun 3 18:05:07 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Jun 2009 20:05:07 +0200 Subject: chkrootkit looking for new maintainer In-Reply-To: <4A26A7BD.1020905@jcomserv.net> References: <20090603183708.6cedfec0@faldor.intranet> <4A26A7BD.1020905@jcomserv.net> Message-ID: <20090603200507.4d38a3ab@faldor.intranet> On Wed, 03 Jun 2009 11:41:33 -0500, Jon wrote: > I use it, and will take it if the co-maintainer isn't interested. There is no co-maintainer, just the EPEL maintainer as "watcher". I'll Release Ownership in pkgdb after sending this mail. From bruno at wolff.to Wed Jun 3 18:09:52 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 3 Jun 2009 13:09:52 -0500 Subject: Fedora 11 Test Day survey In-Reply-To: <1244038226.19989.45.camel@flatline.devel.redhat.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> Message-ID: <20090603180952.GA4917@wolff.to> On Wed, Jun 03, 2009 at 10:10:26 -0400, James Laska wrote: > > 1. How did you find out about Fedora Test Days? Mostly I saw them in the mailing lists first, but saw reminders in FWN. > 2. Was sufficient documentation available to help you participate in a > Fedora Test Day? If not, what did you find missing or in need of > improvement? For the ones I participated in (storage and radeon) things seemed fine. > 3. Did you encounter any obstacles preventing participation in Fedora > test Days? How might they have been avoided? Did you discover any > workaround? Some related to being pretty busy on Thursdays. For one off tests I don't see Fedora doing anything about that, but if you do repeats on the same test later it is probably worth thinking about if it would be better to keep the followup on the same day of the week to make it more likely that people who participated in the earlier session can participate in the followup or if making it a different day of the week to make it more likely that some people who couldn't participate in the earlier session because of a conflict would be able to participate in the followup. > 4. Were you able to locate and download installation media for testing? > Did it function as expected? I have a local rawhide mirror allowed me to have up to date images for testing. > 5. What follow-up actions do you expect after the Test Day? Are your > expectations currently being met? The storage test day ended up with some bugs getting filed and fixed. The radeon day, not so much. > 6. Would you participate again in future Fedora Test Days? Yes. Encryption over raid get's messed up fairly often and actively participating seems to help in getting the issues fixed. Even though the radeon stuff didn't work out that great this time, I'd participate again. I think the stuff I am having issues with is low priority right now, but might get more attention in the future. > 7. Do you have any more general comments or any suggestions for > improving future test days? Start them earlier in the process. In particular I think this would have been advantageous for the anaconda storage rewrite. From jkeating at redhat.com Wed Jun 3 18:52:37 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 03 Jun 2009 11:52:37 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> <20090603001532.GN3095@hansolo.jdub.homelinux.org> <20090603125548.GK3551@localhost.localdomain> <1244047202.8792.29.camel@localhost.localdomain> Message-ID: <1244055157.8792.31.camel@localhost.localdomain> On Wed, 2009-06-03 at 13:49 -0400, Seth Vidal wrote: > And the optimization there is fairly well known. We need to read in and > not change the prestodelta file. It's on my short-ish createrepo list. Hrm, bill thought it was something on the mash side, where he validates the signature of all the existing deltas to catch if a gpg sig changed without a n-v-r bump. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Wed Jun 3 18:54:04 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 3 Jun 2009 14:54:04 -0400 (EDT) Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1244055157.8792.31.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> <20090603001532.GN3095@hansolo.jdub.homelinux.org> <20090603125548.GK3551@localhost.localdomain> <1244047202.8792.29.camel@localhost.localdomain> <1244055157.8792.31.camel@localhost.localdomain> Message-ID: On Wed, 3 Jun 2009, Jesse Keating wrote: > On Wed, 2009-06-03 at 13:49 -0400, Seth Vidal wrote: >> And the optimization there is fairly well known. We need to read in and >> not change the prestodelta file. It's on my short-ish createrepo list. > > Hrm, bill thought it was something on the mash side, where he validates > the signature of all the existing deltas to catch if a gpg sig changed > without a n-v-r bump. Ah - well I hadn't heard the mash part - I know that we could speed up the prestodelta xml creation part - I wasn't convinced it was a 6 hour process, though :) -sv From frankly3d at gmail.com Wed Jun 3 19:13:30 2009 From: frankly3d at gmail.com (Frank Murphy) Date: Wed, 03 Jun 2009 20:13:30 +0100 Subject: Fedora 11 Test Day survey In-Reply-To: <1244038226.19989.45.camel@flatline.devel.redhat.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> Message-ID: <4A26CB5A.8050404@gmail.com> James Laska wrote: > > =================================== > > 1. How did you find out about Fedora Test Days? > Test-List > 2. Was sufficient documentation available to help you participate in a > Fedora Test Day? If not, what did you find missing or in need of > improvement? > > Yes > 3. Did you encounter any obstacles preventing participation in Fedora > test Days? How might they have been avoided? Did you discover any > workaround? > > 4. Were you able to locate and download installation media for testing? > Could be easier to find > Did it function as expected? > Yes > 5. What follow-up actions do you expect after the Test Day? Are your > expectations currently being met? > > Yes > 6. Would you participate again in future Fedora Test Days? > Yes, even more so > 7. Do you have any more general comments or any suggestions for > improving future test days? > Coffee coffee coffee :) Frank From clumens at redhat.com Wed Jun 3 19:23:21 2009 From: clumens at redhat.com (Chris Lumens) Date: Wed, 3 Jun 2009 15:23:21 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243885856.2937.271.camel@adam.local.net> <4A2579BA.2070207@leemhuis.info> <1243975589.29188.100.camel@localhost.localdomain> Message-ID: <20090603192320.GQ5296@localhost.localdomain> > > An earlier freeze would have just frozen the work unfinished. The > > rewrite was a massive undertaking and we knew it was going to take > > longer than the release cycle to finish. Freezing earlier wouldn't have > > helped. > > Then it should have been done in a work branch and targeted for a later > release. Which, of course, it was. But there's no substitute for real-world testing. We do not have nearly the variety of hardware setups, existing partition layouts, or unusual requirements here that users do. At some point, we really do just have to let the new code loose on everyone and get the broad testing that's supposed to be one of the hallmarks of free software. - Chris From fedora at leemhuis.info Wed Jun 3 19:28:36 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 03 Jun 2009 21:28:36 +0200 Subject: (Most) Results from the Candidate Questionnaire are available now Message-ID: <4A26CEE4.7050300@leemhuis.info> Hi! As you might remember, we collected a list of questions that a few days ago were sent to the Candidates of the next Fedora Board/FESCo Elections(?). I got most answers back in between (dgilmore should follow soon; no response from ianweller yet, who seems to be traveling or something according to his IRC away message) and published them in two ways: * as Plain Text: http://www.leemhuis.info/files/fedora/answers.txt * as an OpenOffice table, which IMHO allows easier comparison of the different answers: http://www.leemhuis.info/files/fedora/answers-table.ods I had planed to put them in the wiki as a table was well, but ran out of time, sorry (?). The answers are quite interesting and as far as I can see can be quite helpful to decide whom to (not) vote for. So if you plan to vote in the elections I'd suggest you go and read the answers! CU knurd (?) For details see https://fedoraproject.org/wiki/Elections https://www.redhat.com/archives/fedora-devel-list/2009-May/msg01507.html (?) Actually the whole "Candidate Questionnaire" process was a bit bumpy, but I think we learned a lot and I guess it will be a lot smoother next time if we want to do it again during the next elections From clumens at redhat.com Wed Jun 3 19:29:45 2009 From: clumens at redhat.com (Chris Lumens) Date: Wed, 3 Jun 2009 15:29:45 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <4A2579BA.2070207@leemhuis.info> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243885856.2937.271.camel@adam.local.net> <4A2579BA.2070207@leemhuis.info> Message-ID: <20090603192945.GR5296@localhost.localdomain> > It might have helped to find the problem earlier -- I for example got > the impression that a lot of people had problems with the storage > rewrite and thus aborted their tests with Alpha or Beta. There was no storage rewrite in the Alpha, so this isn't the case there. For the beta, you are correct. - Chris From bjorn at xn--rombobjrn-67a.se Wed Jun 3 20:10:05 2009 From: bjorn at xn--rombobjrn-67a.se (=?iso-8859-1?q?Bj=F6rn_Persson?=) Date: Wed, 3 Jun 2009 22:10:05 +0200 Subject: Fedora 11 Test Day survey In-Reply-To: <1244038226.19989.45.camel@flatline.devel.redhat.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> Message-ID: <200906032210.05619.bjorn@xn--rombobjrn-67a.se> James Laska wrote: > 1. How did you find out about Fedora Test Days? fedora-devel-announce > 2. Was sufficient documentation available to help you participate in a > Fedora Test Day? If not, what did you find missing or in need of > improvement? The instructions were sufficient. > 3. Did you encounter any obstacles preventing participation in Fedora > test Days? How might they have been avoided? Did you discover any > workaround? I found out about the Intel graphics test day too late to be able to participate on the right day. I first had to create a FAS account as I hadn't yet taken all the steps to become a packager. I got side-tracked by an incorrect error message in FAS and had some problems before I could report that. Then I had to create a Smolt profile. SmoltGUI crashed but I could work around the crash by changing the locale. Smolt using two kinds of UUIDs caused some confusion. I could eventually go through the test cases for Intel graphics a week after the actual test day. See also the next question: > 4. Were you able to locate and download installation media for testing? > Did it function as expected? Live CD images were linked from the wiki pages. I had no problems downloading them. I eventually managed to make a working live USB stick from the one for the Intel test day, after I transferred it to my work computer where I had Fedora 10 and could install the latest Syslinux from Rawhide. It wasn't possible to do this on Fedora 9. The live USB stick I made from the CD image for the Nvidia test day was more dead than live. It wouldn't boot, so I couldn't participate in that test day. > 5. What follow-up actions do you expect after the Test Day? Are your > expectations currently being met? I expected that someone would attempt to fix the bugs I reported. No such attempts have been mentioned in Bugzilla so far. I suppose I'll se whether they've been fixed when I upgrade to Fedora 11. Perhaps there would have been more interest in my reports if I had submitted them during the actual test day. > 6. Would you participate again in future Fedora Test Days? If they cover some functionality that's particularly important to me or some less than common hardware that I have. Bj?rn Persson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From notting at redhat.com Wed Jun 3 20:15:06 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 3 Jun 2009 16:15:06 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1244055157.8792.31.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> <20090603001532.GN3095@hansolo.jdub.homelinux.org> <20090603125548.GK3551@localhost.localdomain> <1244047202.8792.29.camel@localhost.localdomain> <1244055157.8792.31.camel@localhost.localdomain> Message-ID: <20090603201506.GA30596@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > On Wed, 2009-06-03 at 13:49 -0400, Seth Vidal wrote: > > And the optimization there is fairly well known. We need to read in and > > not change the prestodelta file. It's on my short-ish createrepo list. > > Hrm, bill thought it was something on the mash side, where he validates > the signature of all the existing deltas to catch if a gpg sig changed > without a n-v-r bump. I haven't characterized that that is *definitely* what's causing pain, but it's a likely source. It's also a hard one to optimize unless you decree that packages will never change signatures, which doesn't seem practical. Bill From kevin.kofler at chello.at Wed Jun 3 20:14:48 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 22:14:48 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> <200906031137.19294.smparrish@gmail.com> Message-ID: Steven M. Parrish wrote: > I can only speak for myself and not the other triagers. I work solely on > KDE issues because in addition to triage I also maintain several KDE > packages and work closely with the other maintainers. The upstream method > we use was discussed and agreed to as the best solution to make sure the > issues get to where they need to be. And I'll add that we KDE maintainers will reopen the bug if it gets closed UPSTREAM, but we feel it needs to be fixed within Fedora. It's not like mistakes can't be easily undone. Kevin Kofler From notting at redhat.com Wed Jun 3 20:17:13 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 3 Jun 2009 16:17:13 -0400 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <20090603023637.GA21055@nostromo.devel.redhat.com> Message-ID: <20090603201713.GB30596@nostromo.devel.redhat.com> Matej Cepl (mcepl at redhat.com) said: > > Depends on the bug/issue. For security isses, I don't think > > CLOSED->UPSTREAM is appropriate, unless it requires a major architecture > > of the code base. Similarly, if an app is crashing immediately on > > startup, it's not something we necessarily want to just hope upstream > > will fix. > > Depends also on maintainer ... we don't require packagers to be > programmers and proficient in language their package is written. Which is a bit of a shame, as we could obviously do a better job if they were. Then again, one of my packages has large chunks written in scheme. Certainly, resources are available to packagers that need them, though; if they've got crasher issues they can't solve, asking on fedora-devel-list can never hurt. Bill From skvidal at fedoraproject.org Wed Jun 3 20:16:52 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 3 Jun 2009 16:16:52 -0400 (EDT) Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <20090603201506.GA30596@nostromo.devel.redhat.com> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2578E4.3090808@leemhuis.info> <20090603001532.GN3095@hansolo.jdub.homelinux.org> <20090603125548.GK3551@localhost.localdomain> <1244047202.8792.29.camel@localhost.localdomain> <1244055157.8792.31.camel@localhost.localdomain> <20090603201506.GA30596@nostromo.devel.redhat.com> Message-ID: On Wed, 3 Jun 2009, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: >> On Wed, 2009-06-03 at 13:49 -0400, Seth Vidal wrote: >>> And the optimization there is fairly well known. We need to read in and >>> not change the prestodelta file. It's on my short-ish createrepo list. >> >> Hrm, bill thought it was something on the mash side, where he validates >> the signature of all the existing deltas to catch if a gpg sig changed >> without a n-v-r bump. > > I haven't characterized that that is *definitely* what's causing pain, > but it's a likely source. > > It's also a hard one to optimize unless you decree that packages will > never change signatures, which doesn't seem practical. We could always go to detached signatures or auto-pkg signatures and then only manually sign the repomd's. -sv From kevin.kofler at chello.at Wed Jun 3 20:17:36 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 22:17:36 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> Message-ID: Steve Grubb wrote: > Not if its closed. How would I be notified that the fix is in Fedora? If > the bug is severe enough, shouldn't the upstream commit be applied to > Fedora's package and the package pushed out for testing? Is all this going > to happen if the bug is closed? You're supposed to be the reporter of or CCed on the upstream bug, then you'll get notified of the fix and can reopen our bug asking for a backport of the fix if it's really that important (but keep in mind that Fedora packages often get upgraded to a bugfix release anyway, for example our KDE gets upgraded to a bugfix release about once a month). As maintainers, we will also try to CC ourselves on those upstream bugs to track their status, but utilimately it's the reporter who cares the most about seeing his/her bug fixed. Kevin Kofler From notting at redhat.com Wed Jun 3 20:24:16 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 3 Jun 2009 16:24:16 -0400 Subject: (Most) Results from the Candidate Questionnaire are available now In-Reply-To: <4A26CEE4.7050300@leemhuis.info> References: <4A26CEE4.7050300@leemhuis.info> Message-ID: <20090603202416.GC30596@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > The answers are quite interesting and as far as I can see can be quite > helpful to decide whom to (not) vote for. So if you plan to vote in the > elections I'd suggest you go and read the answers! Thanks for doing this! Bill From kevin.kofler at chello.at Wed Jun 3 20:21:32 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 22:21:32 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031122.46545.Juha.Tuomala@iki.fi> Message-ID: Juha Tuomala wrote: > I agree. Demanding them to take any responsibility > on that report, even testing it again makes them just > think twice next time to report anything. [snip] > Exactly. If the reporter wants to take part to that > communication, good. But that should not expected. > > More reports is better than more active reporters, those > latter ones wont disapper anywhere anyway. The reporter is the one who wants the bug fixed, it's them asking us to do something, they need to do their part. If you aren't willing to do anything to help us fix your bug, you'll just have to live with it forever. Reports aren't of much use if the reporter doesn't want to provide us with the necessary details, doesn't even bother checking whether the bug isn't already fixed when asked (If we can't reproduce the issue, how else are we to know whether it's fixed or whether we just don't have enough information on how to reproduce it?) and/or refuses to report the issue to the people who're actually able to fix it. Kevin Kofler From snecklifter at gmail.com Wed Jun 3 20:26:30 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 3 Jun 2009 21:26:30 +0100 Subject: Fedora 11 Test Day survey In-Reply-To: <1244038226.19989.45.camel@flatline.devel.redhat.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> Message-ID: <364d303b0906031326k67306ffdr7539ee1a265c5157@mail.gmail.com> > 1. How did you find out about Fedora Test Days? Planet.fp.o > 2. Was sufficient documentation available to help you participate in a > Fedora Test Day? ?If not, what did you find missing or in need of > improvement? Documentation was excellent. > 3. Did you encounter any obstacles preventing participation in Fedora > test Days? ?How might they have been avoided? ?Did you discover any > workaround? None - only took part on the nouveau day though. > 4. Were you able to locate and download installation media for testing? > Did it function as expected? Yes. > 5. What follow-up actions do you expect after the Test Day? ?Are your > expectations currently being met? Bugs fixed. Possibly a summary of how the previous test day helped before talking about the next one? > 6. Would you participate again in future Fedora Test Days? Yes, dependent on barrier to entry. > 7. Do you have any more general comments or any suggestions for > improving future test days? Just that I'm very glad they're happening. Well done. -- Christopher Brown From kevin.kofler at chello.at Wed Jun 3 20:27:13 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 22:27:13 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906031047.26436.jreznik@redhat.com> <200906031252.38232.Juha.Tuomala@iki.fi> <200906031301.01385.jreznik@redhat.com> Message-ID: Jaroslav Reznik wrote: > Most bugs are filled by quite technically skilled users. For average users > it doesn't depend if it is RH bugzilla or upstream's bugzilla - it's too > complicated for them. I know - it's another story... For these people > forums are much more better. Uh, forums are a horrible place for bug reports. For one because developers usually won't read them. It's no use complaining about bugs in front of an audience of other newbies, the bugs must be reported to the people who actually care, and that's what bug trackers are for. Another issue is that forums are freeform, they don't have any sort of form which tells users what information is required. I hate lazy idiots whining about bugs in forums when they never bothered reporting them to the developers. And I don't think we can make bug reports any easier, the point is that the information is required, those "complicated" forms are there to request the information we need. Kevin Kofler From bochecha at fedoraproject.org Wed Jun 3 20:31:11 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Wed, 3 Jun 2009 22:31:11 +0200 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031122.46545.Juha.Tuomala@iki.fi> Message-ID: <2d319b780906031331i47316129m4ac8ca466284154e@mail.gmail.com> >> I agree. Demanding them to take any responsibility >> on that report, even testing it again makes them just >> think twice next time to report anything. > [snip] >> Exactly. If the reporter wants to take part to that >> communication, good. But that should not expected. >> >> More reports is better than more active reporters, those >> latter ones wont disapper anywhere anyway. > > The reporter is the one who wants the bug fixed, it's them asking us to do > something, they need to do their part. If you aren't willing to do anything > to help us fix your bug, you'll just have to live with it forever. So as a package maintainer, you don't want a bug in a software you maintain to be fixed ? ---------- Mathieu Bridon (bochecha) From kevin.kofler at chello.at Wed Jun 3 20:32:26 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 22:32:26 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031047.26436.jreznik@redhat.com> <4A26662A.9010802@freenet.de> Message-ID: Ralf Corsepius wrote: > I consider maintainers redirecting arbitrary reporters to upstreams to > be rude and hostile, because they are presuming the reporter to be > * interested in tracking down bugs If you don't care about your bug, why are you reporting it in the first place? Only very few people report bugs just to be nice (and those will be happy to do anything to help us), most people report bugs because they want them fixed. > * interested in getting involved into upstreams > * technically able to do so. If they're able to report the bug to us, they're also able to report it to upstream, the information they need to provide is basically the same (e.g. for KDE, they just need to pick "Fedora packages" from a dropdown to let upstream know what distro they're using, other than that, the requested information is exactly the same AFAICT). > This occasionally applies to developers - To normal users it usally > doesn't apply, they want "to have their issue fixed". Then they need to do what it takes to get their issue fixed. Talking to upstream, helping with tracking the bug down etc. are all part of that. Kevin Kofler From kevin.kofler at chello.at Wed Jun 3 20:39:08 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 22:39:08 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <20090603113809.3ad3d992@faldor.intranet> <4A266755.6080904@freenet.de> <20090603150057.7d9fc5db@faldor.intranet> <4A267EA0.20600@freenet.de> Message-ID: Ralf Corsepius wrote: > I stopped reporting bugs against Fedora's evolution, because its @RH > maintainer preferred to close bugs and tried to push me around to > upstream. Wrt. evolution, I was an ordinary user and am not interested > in getting further involved. Signing up for an upstream Bugzilla account takes at most 5 minutes, then it's just as easy to file bugs there than at bugzilla.redhat.com. Bugs need to be fixed upstream (so everyone benefits, not just Fedora users), by upstream developers (not packagers, and no, not all packagers are developers, and even those who are generally aren't experts for the entire codebase they're packaging, so upstream developers are the people most qualified for fixing most bugs), so they should also be filed upstream. > There are other packages and packagers (noteworthy many of the @RH) who > exhibit the same "push reporters around" behavior. That's because that's our policy, and rightfully so. > Now combine this with the "report bugs" phrases certain people tend to > reiterate? ... Experiences, such as the one I encountered with the > evolution maintainer, are the cause why at least some people sense a > foul taste when listening to them. Then let's say: Report bugs, to the right place of course (usually upstream)! Kevin Kofler From emmanuel.seyman at club-internet.fr Wed Jun 3 20:43:57 2009 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 3 Jun 2009 22:43:57 +0200 Subject: Maintainer Responsibilities In-Reply-To: <2d319b780906031331i47316129m4ac8ca466284154e@mail.gmail.com> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031122.46545.Juha.Tuomala@iki.fi> <2d319b780906031331i47316129m4ac8ca466284154e@mail.gmail.com> Message-ID: <20090603204357.GA10943@orient.maison.lan> * Mathieu Bridon (bochecha) [03/06/2009 22:41] : > > So as a package maintainer, you don't want a bug in a software you > maintain to be fixed ? Not everyone agrees on what is a bug. Emmanuel From kevin.kofler at chello.at Wed Jun 3 20:49:11 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 22:49:11 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906030848.00617.sgrubb@redhat.com> Message-ID: Steve Grubb wrote: > For the record, I agree with this sentiment. If there's a bug in my > packages, I want to fix it and not cause the reporter to have to get > upstream bz accounts or join upstream mail lists just because they > reported a problem. I will interact with the reporter until I see the > problem myself. And then I can fix it or show upstream the problem. Maybe you package only stuff you're intimately familiar with from top to bottom and you get only very few bug reports. But in KDE, we get dozens of bug reports and it's a huge codebase. While most of the bugs are probably such that I could fix any of them on its own, there's no way I can fix all of them by myself (and even considering all the KDE SIG folks, we still don't have enough time to fix everything ourselves), nor would my fix necessarily be good enough to be accepted upstream (sometimes a good fix needs significant code changes which only the upstream maintainer of the affected code base is really qualified to do, and that's usually not a Fedora developer). So I think you're getting a better deal by us insisting on having the bugs handled upstream. I guess other codebases where bugs are expected to be filed upstream (e.g. Evolution, which was also brought up in this thread) are similar. Kevin Kofler From kevin.kofler at chello.at Wed Jun 3 20:53:05 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 22:53:05 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906031149.28816.Juha.Tuomala@iki.fi> Message-ID: Juha Tuomala wrote: > Would to make the report then if she says 'no'? :) We'll just close it as INSUFFICIENT_DATA as with any other ignored needinfo request. To get the bug fixed, they need to report it to the proper place. > It's a fact that knowledge increases when you move steps to upstream. Uh no, they request the exact same information we do. If you can't provide enough information for upstream, your bug report is just as incomplete and useless for us as it is for them. > If a packager don't have time to do that stuff, he would probably > need a co-maintainer(s) or less packages. So do you volunteer to be the bug forwarding monkey for KDE SIG? Kevin Kofler From jwboyer at gmail.com Wed Jun 3 20:55:18 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 3 Jun 2009 16:55:18 -0400 Subject: (Most) Results from the Candidate Questionnaire are available now In-Reply-To: <20090603202416.GC30596@nostromo.devel.redhat.com> References: <4A26CEE4.7050300@leemhuis.info> <20090603202416.GC30596@nostromo.devel.redhat.com> Message-ID: <20090603205518.GX3095@hansolo.jdub.homelinux.org> On Wed, Jun 03, 2009 at 04:24:16PM -0400, Bill Nottingham wrote: >Thorsten Leemhuis (fedora at leemhuis.info) said: >> The answers are quite interesting and as far as I can see can be quite >> helpful to decide whom to (not) vote for. So if you plan to vote in the >> elections I'd suggest you go and read the answers! > >Thanks for doing this! Agreed, thanks. I'd like to add that if anyone want's follow ups to answers, feel free to email the candidates too! josh From kevin.kofler at chello.at Wed Jun 3 20:58:19 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 22:58:19 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <20090603023637.GA21055@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Depends on the bug/issue. For security isses, I don't think > CLOSED->UPSTREAM is appropriate, unless it requires a major architecture > of the code base. Similarly, if an app is crashing immediately on startup, > it's not something we necessarily want to just hope upstream will fix. Of course, critical showstoppers need to be tracked within the distro. Kevin Kofler From pingou at pingoured.fr Wed Jun 3 21:02:30 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Wed, 03 Jun 2009 23:02:30 +0200 Subject: Maintainer Responsibilities In-Reply-To: <20090603204357.GA10943@orient.maison.lan> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031122.46545.Juha.Tuomala@iki.fi> <2d319b780906031331i47316129m4ac8ca466284154e@mail.gmail.com> <20090603204357.GA10943@orient.maison.lan> Message-ID: <1244062950.6092.10.camel@red.localdomain> On Wed, 2009-06-03 at 22:43 +0200, Emmanuel Seyman wrote: > * Mathieu Bridon (bochecha) [03/06/2009 22:41] : > > > > So as a package maintainer, you don't want a bug in a software you > > maintain to be fixed ? > > Not everyone agrees on what is a bug. That's a feature ;) P.Yves From stickster at gmail.com Wed Jun 3 21:03:31 2009 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 3 Jun 2009 17:03:31 -0400 Subject: (Most) Results from the Candidate Questionnaire are available now In-Reply-To: <4A26CEE4.7050300@leemhuis.info> References: <4A26CEE4.7050300@leemhuis.info> Message-ID: <20090603210331.GU3551@localhost.localdomain> On Wed, Jun 03, 2009 at 09:28:36PM +0200, Thorsten Leemhuis wrote: > As you might remember, we collected a list of questions that a few days > ago were sent to the Candidates of the next Fedora Board/FESCo > Elections(?). I got most answers back in between (dgilmore should follow > soon; no response from ianweller yet, who seems to be traveling or > something according to his IRC away message) and published them in two ways: > > * as Plain Text: > http://www.leemhuis.info/files/fedora/answers.txt > > * as an OpenOffice table, which IMHO allows easier comparison of the > different answers: > http://www.leemhuis.info/files/fedora/answers-table.ods > > I had planed to put them in the wiki as a table was well, but ran out of > time, sorry (?). > > The answers are quite interesting and as far as I can see can be quite > helpful to decide whom to (not) vote for. So if you plan to vote in the > elections I'd suggest you go and read the answers! Thorsten, thanks not only to you for doing this, but also to all the nominees who sent in thoughtful answers. I've been enjoying reading them (off and on between other tasks) today, and I certainly think this enhances the election process. I'm disappointed this ended up being a more difficult process than you intended, but I have no doubt we can improve it for the next cycle. Again, my heartfelt thanks. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From tcallawa at redhat.com Wed Jun 3 21:02:07 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 03 Jun 2009 17:02:07 -0400 Subject: (Most) Results from the Candidate Questionnaire are available now In-Reply-To: <20090603205518.GX3095@hansolo.jdub.homelinux.org> References: <4A26CEE4.7050300@leemhuis.info> <20090603202416.GC30596@nostromo.devel.redhat.com> <20090603205518.GX3095@hansolo.jdub.homelinux.org> Message-ID: <4A26E4CF.2070407@redhat.com> On 06/03/2009 04:55 PM, Josh Boyer wrote: > On Wed, Jun 03, 2009 at 04:24:16PM -0400, Bill Nottingham wrote: >> Thorsten Leemhuis (fedora at leemhuis.info) said: >>> The answers are quite interesting and as far as I can see can be quite >>> helpful to decide whom to (not) vote for. So if you plan to vote in the >>> elections I'd suggest you go and read the answers! >> Thanks for doing this! > > Agreed, thanks. > > I'd like to add that if anyone want's follow ups to answers, feel free to > email the candidates too! A great big me too here. Also, if anyone isn't able to attend the townhall meetings, I'd be happy to answer any questions sent to me via email. Thanks, ~spot From kevin.kofler at chello.at Wed Jun 3 20:57:32 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 22:57:32 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906030843.26442.sgrubb@redhat.com> Message-ID: Steve Grubb wrote: > And then should the bug be closed hoping that one day you pull in a > package that solves the user's problem? If the bug is fixed upstream, the Fedora report can be reopened with a request to backport the fix (but that should only be done if it's important enough that it cannot wait for the next bugfix update getting pushed anyway). Until then, why do we need to have the bug open in 2 places? The ball is in upstream's court as long as we're waiting for them to fix the issue, we've done our part as packagers, so as far as we're concerned the issue is closed. As for those cases where the upstream maintainer is the same as the Fedora maintainer, in those cases the maintainer will still have an open bug, the upstream one, he/she doesn't need 2 of them either. Kevin Kofler From kevin.kofler at chello.at Wed Jun 3 21:13:31 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jun 2009 23:13:31 +0200 Subject: [Bug 484862] GConf2-dbus : Conflicts with other packages References: <200906031545.n53FjRYb004944@bz-web2.app.phx.redhat.com> <20090603175919.5a0f5d68@faldor.intranet> Message-ID: Michael Schwendt wrote: > Why are the relevant Obsoletes missing (commented out)? Because if they were there, everyone would get the OLPC-patched package instead of the stock Fedora one. They should be Conflicts, not Obsoletes. But ideally the whole situation should be fixed so OLPC doesn't need a patched GConf at all. Kevin Kofler From johannbg at hi.is Wed Jun 3 21:22:15 2009 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 03 Jun 2009 21:22:15 +0000 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906030848.00617.sgrubb@redhat.com> Message-ID: <4A26E987.9080103@hi.is> Either bugzilla.redhat.com works as the center bugzilla for all components in Fedora and those maintaining or are responsible for these components for being in Fedora work as the liaison between the reporter and upstream... Or We redirect reporters directly from the beginning to upstream bugzilla. The former benefits the reporters. The latter benefits ( some ) maintainers?. >From a reporters perspective I say I would rather want to have a single central point to report to that contains all the components the distro includes and thus being more productive in reporting rather then having to surf the waves of the internet and create bugzilla account for each and every component. An conciousness needs to be established on either the former or the latter which will then be followed by all maintainers so the needed work to support/enhance either one can take place. And what's up with the twisted mentality that some maintainers have, which is looking at reporters reports bug as being "complaining" when they are actually trying to help? JBG -- Viking-Ice One of my gods has a hammer your's was nailed to a cross You do the math! From promac at gmail.com Wed Jun 3 21:31:27 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Wed, 3 Jun 2009 18:31:27 -0300 Subject: Orphaning Packages: audacious and dependencies In-Reply-To: <20090603184627.4297a25b@lain.camperquake.de> References: <20090603184627.4297a25b@lain.camperquake.de> Message-ID: <68720af30906031431s345fb7e0wa696b2eeb313f194@mail.gmail.com> On Wed, Jun 3, 2009 at 1:46 PM, Ralf Ertzinger wrote: > Hi. > > As I don't have the time to maintain audacious any more I'm orphaning the > following packages: > > audacious > audacious-plugins > libmowgli > mcs > > The last two are dependencies which, as far as I am aware, are used by > nothing else. > > There is an accompanying package in the Voldemort Repository which contains > the less free and more useful media codecs. That would be up for grabs, > too, preferrably by the same person. > > There are several bugs open against the package, most of which will > probably be fixed by the current upstream release. > The new binaries are called audiocious2 and audtool2, and they seem to be working just fine. In theory, it would be possible to keep the old audacious and the new one. Another possibility is just to rename some files to match the previous version. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From awilliam at redhat.com Wed Jun 3 21:35:07 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 03 Jun 2009 14:35:07 -0700 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <200906030843.26442.sgrubb@redhat.com> Message-ID: <1244064907.2937.346.camel@adam.local.net> On Wed, 2009-06-03 at 22:57 +0200, Kevin Kofler wrote: > Steve Grubb wrote: > > And then should the bug be closed hoping that one day you pull in a > > package that solves the user's problem? > > If the bug is fixed upstream, the Fedora report can be reopened with a > request to backport the fix (but that should only be done if it's important > enough that it cannot wait for the next bugfix update getting pushed > anyway). > > Until then, why do we need to have the bug open in 2 places? There's an obvious answer to this question: we track the importance of issues to Fedora via the Fedora bug tracker, not via upstream bug trackers. There's no way I can mark a bug in the KDE bug tracker as blocking the release of Fedora 12. (longer email on the whole thread coming.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Wed Jun 3 21:44:12 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 03 Jun 2009 14:44:12 -0700 Subject: Maintainer Responsibilities In-Reply-To: <1244024739.6512.9.camel@macbook.infradead.org> References: <200906021617.12122.sgrubb@redhat.com> <1244024739.6512.9.camel@macbook.infradead.org> Message-ID: <1244065452.2937.355.camel@adam.local.net> On Wed, 2009-06-03 at 11:25 +0100, David Woodhouse wrote: > On Tue, 2009-06-02 at 16:17 -0400, Steve Grubb wrote: > > > > I don't want to start a long thread, but just to ask a couple questions for my > > own clarification. Does a maintainer's responsibilities end with packaging > > bugs? IOW, if there is a problem in the package that is _broken code_ do they > > need to do something about it or is it acceptable for them to close the bug > > and say talk to upstream? > > There are _some_ kinds of bug (feature requests, etc.) which it's > reasonable for any decent maintainer to punt upstream. > > There are other kinds of bugs (crashes, security issues -- perhaps even > _anything_ that's a real bug rather than an RFE) which the maintainer > really _ought_ to deal with directly. > > Opinions vary on precisely where the boundary between those classes > should be, but I'm fairly adamant it should be 'RFE vs. bug'. I'm with David on this one. To answer the initial question, this is not explicitly codified anywhere AFAIK, and that's probably because it _can't_ be. It's just not possible to reasonably say that all issues that aren't introduced by actual Fedora packaging should or shouldn't be reported upstream. David's right in identifying the types of bug which it generally does and doesn't make sense to move upstream, and the rest of the thread obviously illustrates that we have different attitudes on the part of different maintainers about it as well. Personally with my maintainer hat on I generally like to keep reports open downstream as it helps me remember stuff, but for a guy with as much work to do as Kevin on a project as big as KDE, I can see how that would not be the case. There's a third element, which is how active upstream is. If you know damn well that upstream's been dead for six years or doesn't care about the branch you're packaging any more, you pretty much have to keep the bugs downstream (I know we try to avoid this situation in Fedora, but it does occur sometimes). I think we just have to be explicit about not being explicit here: it's a judgment call on the part of the maintainer (and the Bugzapper for that component, if there is one, working together with the maintainer). As long as everyone bears in mind that the objective is to get the problem fixed, whichever method is most likely to result in that happening is fine as long as it's consistently applied. As far as being nice to reporters goes, attitude is far more important than process. "report this upstream" may not work great. "Thanks for reporting this issue: as it's a bug in the latest version of the code, it will be fixed most quickly if you report it to the original developers. Their Bugzilla is at http://bugzilla.foobar.com, and you should report the bug against version X of component foobar." will work a lot better. You can also add "Once the issue has been resolved upstream, please re-open this bug to request we include the updated code in Fedora" if appropriate. Yes, it's a lot of text, but you only have to write it once, then stick it in a text file or the Stock Responses page on the Bugzappers wiki section or wherever, and you're good to go for all future upstreaming requests. Basically, I think that if you're worried about trying to keep reporters happy, the way you interact with them matters a lot more than exactly what it is you ask them to do. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Wed Jun 3 21:55:00 2009 From: awilliam at redhat.com (Adam Williamson) Date: Wed, 03 Jun 2009 14:55:00 -0700 Subject: Fedora 11 Test Day survey In-Reply-To: <8278b1b0906030721l7675f3e7h94c24f9397a19232@mail.gmail.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> <8278b1b0906030721l7675f3e7h94c24f9397a19232@mail.gmail.com> Message-ID: <1244066100.2937.359.camel@adam.local.net> On Wed, 2009-06-03 at 09:21 -0500, King InuYasha wrote: > 6. If they were planned better, then maybe I would be able to set > aside time to do them. I would like to participate in future Test > Days. You're right that we generally only get the meat of the test cases and so forth up about 48 hours in advance. However, the actual *schedule* of events is fixed a lot earlier than that. The F11 schedule was here: https://fedoraproject.org/wiki/QA/Test_Days/F11 and most of the days were listed there weeks before they actually happened. The F12 one is up now: https://fedoraproject.org/wiki/QA/Test_Days/F12 and will be getting populated starting pretty soon. So you do at least have the opportunity to see what days are coming up in future, though the test cases and live media may not be available yet. > 7. Set up a reporting center just for Test Day feedback. Using the > wiki is definitely not good enough. Additionally, Do not limit the > test days to people subscribed to the mailing list. Take a page from > Mozilla's books and announce those test days to the world. > Unfortunately, to do that, test days need to be planned better. We do announce them on Planet Fedora also. For a couple of test days in the F11 cycle, we did wider announcements to general-interest sites, and this was pretty successful; it's something we'll be doing for F12 too. However, it's not appropriate for all test days (some are things that are really specific to a Fedora audience, or even more selective than that) - we have to pick ones that are both of interest to a general audience, and that a general audience will be able to participate in (i.e. can be tested from a live CD with general-purpose hardware). Thanks for the thoughts! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From pbrobinson at gmail.com Wed Jun 3 22:10:00 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 3 Jun 2009 23:10:00 +0100 Subject: [Bug 484862] GConf2-dbus : Conflicts with other packages In-Reply-To: References: <200906031545.n53FjRYb004944@bz-web2.app.phx.redhat.com> <20090603175919.5a0f5d68@faldor.intranet> Message-ID: <5256d0b0906031510t7a8a01c3pbbc300858866d8b2@mail.gmail.com> >> Why are the relevant Obsoletes missing (commented out)? > > Because if they were there, everyone would get the OLPC-patched package > instead of the stock Fedora one. They should be Conflicts, not Obsoletes. > But ideally the whole situation should be fixed so OLPC doesn't need a > patched GConf at all. I would prefer a gnome that has none of the old crud around.... wait that's due for gnome 3 :-) But as a side note I believe one of the reasons olpc needed the dbus version was/is to do with their rainbow security system. I believe that's in the process of changing with some changes to rainbow to make it more mainline capable, but then both versions of gconf will hopefully be obsolete before then :-) Peter From andreas at bawue.net Wed Jun 3 22:30:12 2009 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 4 Jun 2009 00:30:12 +0200 (CEST) Subject: (Most) Results from the Candidate Questionnaire are available now In-Reply-To: <20090603210331.GU3551@localhost.localdomain> References: <4A26CEE4.7050300@leemhuis.info> <20090603210331.GU3551@localhost.localdomain> Message-ID: On Wed, 3 Jun 2009, Paul W. Frields wrote: > Thorsten, thanks not only to you for doing this, Yeah. Thanks a lot as well. > I'm disappointed this ended up being a more difficult process than you > intended, but I have no doubt we can improve it for the next cycle. Leaving a bit more time between the cut-off date for the questionaire and the town hall meeting should hopefully fix that. regards, andreas From kevin.kofler at chello.at Wed Jun 3 22:37:56 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 00:37:56 +0200 Subject: (Most) Results from the Candidate Questionnaire are available now References: <4A26CEE4.7050300@leemhuis.info> <20090603210331.GU3551@localhost.localdomain> Message-ID: Andreas Thienemann wrote: > Leaving a bit more time between the cut-off date for the questionaire and > the town hall meeting should hopefully fix that. Yes, there needs to be more time between the end of nominations and the town hall meetings. When I went to sleep yesterday, the meeting time was still tentative. I prepared my alarm clock to wake up in time for it anyway (yeah, I have to set an alarm clock to be up at 4 PM ;-) ) and indeed when I woke up I found the confirmation of the time in my inbox. But if the time had been moved earlier, I'd have missed the meeting. Notification of the final times needs to happen much earlier (though thankfully the tentative times which got announced beforehand were the final ones anyway). Kevin Kofler From cra at WPI.EDU Wed Jun 3 23:48:51 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 3 Jun 2009 19:48:51 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <4A2459F3.8040300@redhat.com> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <1243896345.29188.43.camel@localhost.localdomain> <4A2459F3.8040300@redhat.com> Message-ID: <20090603234851.GF2650@angus.ind.WPI.EDU> On Mon, Jun 01, 2009 at 06:45:07PM -0400, Tom spot Callaway wrote: > On 06/01/2009 06:45 PM, Jesse Keating wrote: > > If we had I2 in PHX this would get a lot faster. > > We just need to hold some classes and get the PHX datacenter certified > as a University. ;) Not necessarily. I don't see why the Fedora Project couldn't qualify as a Sponsored Participant on Internet2 [1]. In fact, Red Hat is already connected in Raleigh. I'd gladly help pursue this, but I may not be the right person seeing as I'm in Boston, not PHX. I2 also has a "private lambda" service where you can get your own dedicated 10Gig wavelength across the backbone [2]. It seems they are currently offering no-fee trials of this service to I2 connectors. Arizona State University is already on I2 via CENIC, and CENIC offers this Dynamic Circuit capability. MCNC in Durham where Red Hat is connected doesn't appear to have DCN though. [1] http://www.internet2.edu/network/participants/ "Sponsored participants are individual educational institutions (including not-for-profit and for-profit K-20, technical, and trade schools), museums, art galleries, libraries, hospitals, as well as other non-educational, not-for-profit or for-profit organizations that require routine collaboration on instructional, clinical, and/or research projects, services, and content with Primary participants or with other Sponsored Participants. Such organizations typically are either not eligible or not able to become Internet2 members." [2] http://www.internet2.edu/network/dc/ "To support the development, deployment, and use of innovative hybrid optical networking capabilities, Internet2 is initiating a no-fee trial of the Internet2 DCN." From opensource at till.name Thu Jun 4 00:12:46 2009 From: opensource at till.name (Till Maas) Date: Thu, 04 Jun 2009 02:12:46 +0200 Subject: (Most) Results from the Candidate Questionnaire are available now In-Reply-To: <4A26CEE4.7050300@leemhuis.info> References: <4A26CEE4.7050300@leemhuis.info> Message-ID: <200906040212.56937.opensource@till.name> On Wed June 3 2009, Thorsten Leemhuis wrote: > I had planed to put them in the wiki as a table was well, but ran out of > time, sorry (?). I tried to add such a table[0], but I failed to enable the horizotnal scrollbar. I even enabled javascript for the wiki, but it still does not work. Is this somehow broken in our mediawiki CSS setup? I noticed the css files contain overflow:hidden in several places. Regards Till [0] https://fedoraproject.org/wiki/Elections/Questionnaire#Answers_Wiki_Table -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From rc040203 at freenet.de Thu Jun 4 05:23:05 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 04 Jun 2009 07:23:05 +0200 Subject: Maintainer Responsibilities In-Reply-To: <200906031137.19294.smparrish@gmail.com> References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> <200906031137.19294.smparrish@gmail.com> Message-ID: <4A275A39.4070601@freenet.de> Steven M. Parrish wrote: > Many people have mentioned that it is not right to ask the users to file their > bug reports upstream. I ask why not? Let me summarize what I already wrote elsewhere in this thread: * Users aren't necessarily developers. * Users aren't necessarily interested in getting involved upstream. * Users are reporting bugs against your product (your package in Fedora), not against upstream's work (somebody else's product). Let me try an analogy: How do you handle defects/malfunctions with your car? You'll visit your car dealer/a garage and report the issue to them. You'll expect them to identify the problem and to take appropriate steps to solve your issue. You don't expect them to direct you to the car's manufacturer or a component manufacturer and to discuss technical details you have no knowledge about with them ("Is the stuttering engine cause by triac 7 in a component A you haven't heard about before" or by the hall sensor in component B you also haven't heard about before). > Obviously by reporting the issue to us > they feel it is important and needs to be addressed. The took the time to > open a RH bugzilla account to file the report, so I don't see why they can't > take 60 seconds and open an upstream account as well. Here, my answer is: They are using Fedora/participating in Fedora and therefore have RH bugzilla account. They are not participating in these upstream projects. Ralf From cemeyer at u.washington.edu Thu Jun 4 05:38:41 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Wed, 3 Jun 2009 22:38:41 -0700 Subject: Maintainer Responsibilities In-Reply-To: <4A275A39.4070601@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <200906031137.19294.smparrish@gmail.com> <4A275A39.4070601@freenet.de> Message-ID: <200906032238.41501.cemeyer@u.washington.edu> On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: > Let me try an analogy: How do you handle defects/malfunctions with your > car? Did a bunch of hobbyists from around the world build your car by communicating over the internet? If so, I think it would be safer to stop driving immediately (EBADMETAPHOR). Regards, -- Conrad Meyer From valent.turkovic at gmail.com Thu Jun 4 06:34:40 2009 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 4 Jun 2009 08:34:40 +0200 Subject: KPackageKit fail Message-ID: <64b14b300906032334v735a922r422e7ab0b5ce7116@mail.gmail.com> I'm testing Rawhide with latest updates and KPackageKit fails to do updates, I get this error log: http://fpaste.org/paste/13851 It is works for you haven't tested it please do, if it works for you then ignore this message, if not then reply if you need some more feedback from me and I will open a new bug report then. Cheers -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From rc040203 at freenet.de Thu Jun 4 06:40:42 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 04 Jun 2009 08:40:42 +0200 Subject: Maintainer Responsibilities In-Reply-To: <200906032238.41501.cemeyer@u.washington.edu> References: <200906021617.12122.sgrubb@redhat.com> <200906031137.19294.smparrish@gmail.com> <4A275A39.4070601@freenet.de> <200906032238.41501.cemeyer@u.washington.edu> Message-ID: <4A276C6A.2080503@freenet.de> Conrad Meyer wrote: > On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: >> Let me try an analogy: How do you handle defects/malfunctions with your >> car? > > Did a bunch of hobbyists from around the world build your car by communicating > over the internet? Have you ever seen an open source car? The Fedora "car" manufacturer is the "fedora community", assembling it from "upstream" components. Ralf From fedora at leemhuis.info Thu Jun 4 06:44:51 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 04 Jun 2009 08:44:51 +0200 Subject: (Most) Results from the Candidate Questionnaire are available now In-Reply-To: <4A26CEE4.7050300@leemhuis.info> References: <4A26CEE4.7050300@leemhuis.info> Message-ID: <4A276D63.5060302@leemhuis.info> On 03.06.2009 21:28, Thorsten Leemhuis wrote: > As you might remember, we collected a list of questions that a few days > ago were sent to the Candidates of the next Fedora Board/FESCo > Elections(?). I got most answers back in between (dgilmore should follow > soon; no response from ianweller yet, who seems to be traveling or > something according to his IRC away message) and published them in two ways: > > * as Plain Text: > http://www.leemhuis.info/files/fedora/answers.txt > > * as an OpenOffice table, which IMHO allows easier comparison of the > different answers: > http://www.leemhuis.info/files/fedora/answers-table.ods Both updated with the answers from Dglimore. CU knurd From cemeyer at u.washington.edu Thu Jun 4 06:45:32 2009 From: cemeyer at u.washington.edu (Conrad Meyer) Date: Wed, 3 Jun 2009 23:45:32 -0700 Subject: Maintainer Responsibilities In-Reply-To: <4A276C6A.2080503@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <200906032238.41501.cemeyer@u.washington.edu> <4A276C6A.2080503@freenet.de> Message-ID: <200906032345.32306.cemeyer@u.washington.edu> On Wednesday 03 June 2009 11:40:42 pm Ralf Corsepius wrote: > Conrad Meyer wrote: > > On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: > >> Let me try an analogy: How do you handle defects/malfunctions with your > >> car? > > > > Did a bunch of hobbyists from around the world build your car by > > communicating over the internet? > > Have you ever seen an open source car? > > The Fedora "car" manufacturer is the "fedora community", assembling it > from "upstream" components. > > Ralf That's the idea, opensource behaves completely different from a car manufacturer. -- Conrad Meyer From rc040203 at freenet.de Thu Jun 4 06:54:04 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 04 Jun 2009 08:54:04 +0200 Subject: Maintainer Responsibilities In-Reply-To: <200906032345.32306.cemeyer@u.washington.edu> References: <200906021617.12122.sgrubb@redhat.com> <200906032238.41501.cemeyer@u.washington.edu> <4A276C6A.2080503@freenet.de> <200906032345.32306.cemeyer@u.washington.edu> Message-ID: <4A276F8C.7030608@freenet.de> Conrad Meyer wrote: > On Wednesday 03 June 2009 11:40:42 pm Ralf Corsepius wrote: >> Conrad Meyer wrote: >>> On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: >>>> Let me try an analogy: How do you handle defects/malfunctions with your >>>> car? >>> Did a bunch of hobbyists from around the world build your car by >>> communicating over the internet? >> Have you ever seen an open source car? >> >> The Fedora "car" manufacturer is the "fedora community", assembling it >> from "upstream" components. >> >> Ralf > > That's the idea, opensource behaves completely different from a car > manufacturer. Wrong. It doesn't. Ralf From rc040203 at freenet.de Thu Jun 4 06:59:23 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 04 Jun 2009 08:59:23 +0200 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> Message-ID: <4A2770CB.8090708@freenet.de> Kevin Kofler wrote: > Steve Grubb wrote: >> Not if its closed. How would I be notified that the fix is in Fedora? If >> the bug is severe enough, shouldn't the upstream commit be applied to >> Fedora's package and the package pushed out for testing? Is all this going >> to happen if the bug is closed? > > You're supposed to be the reporter of or CCed on the upstream bug, then > you'll get notified of the fix and can reopen our bug asking for a backport > of the fix if it's really that important (but keep in mind that Fedora > packages often get upgraded to a bugfix release anyway, for example our KDE > gets upgraded to a bugfix release about once a month). You are still presuming your users to be interested in developing and working on your package. This simply does not apply - They want to use your package. > As maintainers, we will also try to CC ourselves on those upstream bugs to > track their status, but utilimately it's the reporter who cares the most > about seeing his/her bug fixed. I could not disagree more. People with this kind of attude should lable themselves maintainer and stop packaging packages in Fedora. Ralf From dtardon at redhat.com Thu Jun 4 07:00:29 2009 From: dtardon at redhat.com (David Tardon) Date: Thu, 4 Jun 2009 09:00:29 +0200 Subject: Maintainer Responsibilities In-Reply-To: <4A275A39.4070601@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> <200906031137.19294.smparrish@gmail.com> <4A275A39.4070601@freenet.de> Message-ID: <20090604070028.GB3712@verda-stelo.englab.brq.redhat.com> On Thu, Jun 04, 2009 at 07:23:05AM +0200, Ralf Corsepius wrote: > Steven M. Parrish wrote: > >> Many people have mentioned that it is not right to ask the users to >> file their bug reports upstream. I ask why not? > > Let me summarize what I already wrote elsewhere in this thread: > * Users aren't necessarily developers. > * Users aren't necessarily interested in getting involved upstream. > * Users are reporting bugs against your product (your package in > Fedora), not against upstream's work (somebody else's product). > > > Let me try an analogy: How do you handle defects/malfunctions with your > car? > > You'll visit your car dealer/a garage and report the issue to them. > You'll expect them to identify the problem and to take appropriate steps > to solve your issue. Let me try another analogy: How do you handle health problems? You'll visit your doctor. You'll expect him to identify the problem and to take appropriate steps to solve your issue--that may well be just him sending you to a specialist. Would you expect your doctor to serve as a proxy between you and the specialist? Or even substitute you for checkup? I wouldn't. > You don't expect them to direct you to the car's > manufacturer or a component manufacturer and to discuss technical > details you have no knowledge about with them ("Is the stuttering engine > cause by triac 7 in a component A you haven't heard about before" or by > the hall sensor in component B you also haven't heard about before). > Who spoke about technical details? Have you ever been asked to look into the source code of some project? I don't think so. An upstream developer can ask better/more detailed questions than a packager, but that's only to be expected. Btw, I'm really interested to hear why answering questions of an upstream developer through a packager as a proxy is better than answering the same questions directly... David From mschmidt at redhat.com Thu Jun 4 07:07:23 2009 From: mschmidt at redhat.com (Michal Schmidt) Date: Thu, 4 Jun 2009 09:07:23 +0200 Subject: KPackageKit fail In-Reply-To: <64b14b300906032334v735a922r422e7ab0b5ce7116@mail.gmail.com> References: <64b14b300906032334v735a922r422e7ab0b5ce7116@mail.gmail.com> Message-ID: <20090604090723.0318a2fb@leela> Dne Thu, 4 Jun 2009 08:34:40 +0200 Valent Turkovic napsal(a): > I'm testing Rawhide with latest updates and KPackageKit fails to do > updates, I get this error log: > http://fpaste.org/paste/13851 > > It is works for you haven't tested it please do, if it works for you > then ignore this message, if not then reply if you need some more > feedback from me and I will open a new bug report then. Looks like https://bugzilla.redhat.com/show_bug.cgi?id=502399 Michal From frankly3d at gmail.com Thu Jun 4 07:05:37 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Thu, 04 Jun 2009 08:05:37 +0100 Subject: KPackageKit fail In-Reply-To: <64b14b300906032334v735a922r422e7ab0b5ce7116@mail.gmail.com> References: <64b14b300906032334v735a922r422e7ab0b5ce7116@mail.gmail.com> Message-ID: <4A277241.4080208@gmail.com> Valent Turkovic wrote: > I'm testing Rawhide with latest updates and KPackageKit fails to do > updates, I get this error log: > http://fpaste.org/paste/13851 > > It is works for you haven't tested it please do, if it works for you > then ignore this message, if not then reply if you need some more > feedback from me and I will open a new bug report then. > > > Cheers > > Hi Valent. You might have better luck with rawhide questions on the test-list. Also check the bugzilla against existing kpackagekit\rawhide bugs. Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From rc040203 at freenet.de Thu Jun 4 07:08:11 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 04 Jun 2009 09:08:11 +0200 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031047.26436.jreznik@redhat.com> <4A26662A.9010802@freenet.de> Message-ID: <4A2772DB.4040601@freenet.de> Kevin Kofler wrote: > Ralf Corsepius wrote: >> I consider maintainers redirecting arbitrary reporters to upstreams to >> be rude and hostile, because they are presuming the reporter to be >> * interested in tracking down bugs > > If you don't care about your bug, why are you reporting it in the first > place? Because it's not "my bug", it's a bug in a package, which I am using, which is exposing a bug. > Only very few people report bugs just to be nice (and those will be > happy to do anything to help us), most people report bugs because they want > them fixed. Yes, they want to have them fixed ... and they use bz at rh to communicate it, because Fedora is the product they are using. >> * interested in getting involved into upstreams >> * technically able to do so. > > If they're able to report the bug to us, they're also able to report it to > upstream, the information they need to provide is basically the same (e.g. > for KDE, they just need to pick "Fedora packages" from a dropdown to let > upstream know what distro they're using, other than that, the requested > information is exactly the same AFAICT). Non-sense. A bug is fixed in Fedora when a package maintainer ships fixed packages, not when upstream "starts looking into it" or "acknowledges it". >> This occasionally applies to developers - To normal users it usally >> doesn't apply, they want "to have their issue fixed". > > Then they need to do what it takes to get their issue fixed. Talking to > upstream, helping with tracking the bug down etc. are all part of that. Non-sense. Me thinks, your are just being lazy and are trying to rudely push around Fedora's user base. "customer-friendliness" is something entirely different from your attitude. Ralf From dtardon at redhat.com Thu Jun 4 07:23:18 2009 From: dtardon at redhat.com (David Tardon) Date: Thu, 4 Jun 2009 09:23:18 +0200 Subject: Maintainer Responsibilities In-Reply-To: <4A2770CB.8090708@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> <4A2770CB.8090708@freenet.de> Message-ID: <20090604072317.GC3712@verda-stelo.englab.brq.redhat.com> On Thu, Jun 04, 2009 at 08:59:23AM +0200, Ralf Corsepius wrote: > Kevin Kofler wrote: >> Steve Grubb wrote: >>> Not if its closed. How would I be notified that the fix is in Fedora? If >>> the bug is severe enough, shouldn't the upstream commit be applied to >>> Fedora's package and the package pushed out for testing? Is all this going >>> to happen if the bug is closed? >> >> You're supposed to be the reporter of or CCed on the upstream bug, then >> you'll get notified of the fix and can reopen our bug asking for a backport >> of the fix if it's really that important (but keep in mind that Fedora >> packages often get upgraded to a bugfix release anyway, for example our KDE >> gets upgraded to a bugfix release about once a month). > You are still presuming your users to be interested in developing and > working on your package. > I think it has been already mentioned in this thread, but I'm going to mention it again (in, probably void, hope you'll understand it): One of principles of open source development is a relationship between the developer and the user. If the relationship be functioning rightly, the user should be willing _to give_ something back, not just _to take_. > This simply does not apply - They want to use your package. If you don't accept that, go on and buy RHEL or SLED or MacOS X or even MS Windows and you'll get the attendance you expect. Maybe. Maybe not. Maybe product management decides your bug is not important enough or your request for enhancement wouldn't be wanted by majority of users and rejects it... As a last instance, you can always hire a free lance programmer to fix the bugs for you, provided you have the sources and rights to modify them. David From choeger at cs.tu-berlin.de Thu Jun 4 07:30:42 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 04 Jun 2009 09:30:42 +0200 Subject: evolution header: Mime-version: 1.0 In-Reply-To: <20090603170936.GH4742@sventech.com> References: <1244048485.14565.10.camel@choeger6> <20090603170936.GH4742@sventech.com> Message-ID: <1244100642.19245.3.camel@choeger5.umpa.netz> Am Mittwoch, den 03.06.2009, 10:09 -0700 schrieb Johannes Erdfelt: > On Wed, Jun 03, 2009, Christoph H?ger wrote: > > I see a small problem with evolution when sending to mailinglists. > > Obviously evolution puts: Mime-version: 1.0 in the header, hypermail > > searches for MIME-version: and cannot find that string. So it adds it. > > In turn my mail provider bounces the return message that should be sent > > to me complaining about duplicate header field. > > > > So who is wrong here? Hypermail or evolution? Is non uppercase letter > > Mime-version allowed? Anyone knowing the answer? > > Hypermail. > > Headers should be matched in a case insensitive manner. > > JE Where do you get that conclusion from? I can only cite RFC 2045 which says: > Messages composed in accordance with this document MUST include such > a header field, with the following verbatim text: > > MIME-Version: 1.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jreznik at redhat.com Thu Jun 4 07:35:45 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Thu, 4 Jun 2009 09:35:45 +0200 Subject: Maintainer Responsibilities In-Reply-To: <4A2770CB.8090708@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <4A2770CB.8090708@freenet.de> Message-ID: <200906040935.45912.jreznik@redhat.com> On Jueves 04 Junio 2009 08:59:23 Ralf Corsepius escribi?: > Kevin Kofler wrote: > > Steve Grubb wrote: > >> Not if its closed. How would I be notified that the fix is in Fedora? If > >> the bug is severe enough, shouldn't the upstream commit be applied to > >> Fedora's package and the package pushed out for testing? Is all this > >> going to happen if the bug is closed? > > > > You're supposed to be the reporter of or CCed on the upstream bug, then > > you'll get notified of the fix and can reopen our bug asking for a > > backport of the fix if it's really that important (but keep in mind that > > Fedora packages often get upgraded to a bugfix release anyway, for > > example our KDE gets upgraded to a bugfix release about once a month). > > You are still presuming your users to be interested in developing and > working on your package. Yes and no - most of our bugs come from well known contributors - it's safe to them to say - please, report it upstream. They just ask as - is it downstream or upstream issue? Are you aware of this issue? If we know/we can see that bugreporter is ordinary user, we're trying to help him report this issue or we simply do it. It's not - upstream, close, shut your mouth, don't bother us! My final conclussion - there are power users, there are ordinary users, some of them of better knowledge, some worst - and we should help them, guide them - it's our work and we have to take care about them individually... There can't be one policy to match all cases... > This simply does not apply - They want to use your package. > > > As maintainers, we will also try to CC ourselves on those upstream bugs > > to track their status, but utilimately it's the reporter who cares the > > most about seeing his/her bug fixed. > > I could not disagree more. People with this kind of attude should lable > themselves maintainer and stop packaging packages in Fedora. You can ask our users if they are satisfied or not. From comments and posts I think they ARE! Check our fedora-kde list, IRC channel #fedora-kde as most of bugs are solved there even before they hit BZ... Jaroslav > Ralf From mhlavink at redhat.com Thu Jun 4 07:40:16 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Thu, 4 Jun 2009 09:40:16 +0200 Subject: Maintainer Responsibilities In-Reply-To: <200906021617.12122.sgrubb@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> Message-ID: <200906040940.16503.mhlavink@redhat.com> > Hello, > > I don't want to start a long thread, but just to ask a couple questions for > my own clarification. Does a maintainer's responsibilities end with > packaging bugs? IOW, if there is a problem in the package that is _broken > code_ do they need to do something about it or is it acceptable for them to > close the bug and say talk to upstream? Do we want those bugs open to track > when the bug is fixed in the distro? I'll accept whatever the answer is, > I'm just curious. I think it depends on what type of users we want. If we want only skilled users (programmers) we can close most bugs upstream. But this is not a good way if we want also less skilled users (and bug reports from them). There are tons of packages in fedora, most of them have own upstream. For every package you need usually some kind of bugzilla registration (or mailing list subscription), which is (at least) a little bit odd - expecting users are willing to have so many subscriptions/registrations. The second problem are less skilled users. What if upstream answers: ok, thanks for bug report, please try this patch... or I've fixed it in repo, please try svn snapshot, if it's fixed for you? We can't expect all users are skilled for this. Michal From frankly3d at gmail.com Thu Jun 4 07:43:38 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Thu, 04 Jun 2009 08:43:38 +0100 Subject: Packager = Programmer? Message-ID: <4A277B2A.5010808@gmail.com> Does trying to become a packager. Involve being currently a Developer, as in Programming skills\certification, whether Perl\Python\c++ etc. Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From jreznik at redhat.com Thu Jun 4 07:46:04 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Thu, 4 Jun 2009 09:46:04 +0200 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <200906031301.01385.jreznik@redhat.com> Message-ID: <200906040946.04944.jreznik@redhat.com> On Mi?rcoles 03 Junio 2009 22:27:13 Kevin Kofler escribi?: > Jaroslav Reznik wrote: > > Most bugs are filled by quite technically skilled users. For average > > users it doesn't depend if it is RH bugzilla or upstream's bugzilla - > > it's too complicated for them. I know - it's another story... For these > > people forums are much more better. > > Uh, forums are a horrible place for bug reports. For one because developers > usually won't read them. It's no use complaining about bugs in front of an > audience of other newbies, the bugs must be reported to the people who > actually care, and that's what bug trackers are for. Another issue is that > forums are freeform, they don't have any sort of form which tells users > what information is required. For bug reports - indeed. But to help users - forums/mailing list are great. > > I hate lazy idiots whining about bugs in forums when they never bothered > reporting them to the developers. Yes, some users are lazy, asking stupid questions and fighting in forum. But for users it's not easy to report bug, power users should help them (and I'm trying as much I can) > > And I don't think we can make bug reports any easier, the point is that the > information is required, those "complicated" forms are there to request the > information we need. Bug report can't be easier ever but it's responsible of us to help people but first they have to know about BZ at least :D I'm helping people on some Czech forums everyday, often they PM to contact me directly and 99% of the problems (they think it's a bug) are not actually bugs... > Kevin Kofler Jaroslav From sundaram at fedoraproject.org Thu Jun 4 07:48:38 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 04 Jun 2009 13:18:38 +0530 Subject: Packager = Programmer? In-Reply-To: <4A277B2A.5010808@gmail.com> References: <4A277B2A.5010808@gmail.com> Message-ID: <4A277C56.4080805@fedoraproject.org> On 06/04/2009 01:13 PM, Frank Murphy (Frankly3d) wrote: > Does trying to become a packager. > Involve being currently a Developer, > as in Programming skills\certification, > whether Perl\Python\c++ etc. Not necessarily. It's useful to understand the codebase but if you have a active upstream responsive to bug reports, you can just take care of the packaging aspects of it. You can always ask for help from others within Fedora or upstream if needed. Rahul From jreznik at redhat.com Thu Jun 4 07:56:46 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Thu, 4 Jun 2009 09:56:46 +0200 Subject: Maintainer Responsibilities In-Reply-To: <1244064907.2937.346.camel@adam.local.net> References: <200906021617.12122.sgrubb@redhat.com> <1244064907.2937.346.camel@adam.local.net> Message-ID: <200906040956.46815.jreznik@redhat.com> On Mi?rcoles 03 Junio 2009 23:35:07 Adam Williamson escribi?: > On Wed, 2009-06-03 at 22:57 +0200, Kevin Kofler wrote: > > Steve Grubb wrote: > > > And then should the bug be closed hoping that one day you pull in a > > > package that solves the user's problem? > > > > If the bug is fixed upstream, the Fedora report can be reopened with a > > request to backport the fix (but that should only be done if it's > > important enough that it cannot wait for the next bugfix update getting > > pushed anyway). > > > > Until then, why do we need to have the bug open in 2 places? > > There's an obvious answer to this question: we track the importance of > issues to Fedora via the Fedora bug tracker, not via upstream bug > trackers. There's no way I can mark a bug in the KDE bug tracker as > blocking the release of Fedora 12. Yes, there's the way to do it - we always have tracker bug for most important issues we have found! And not only for new releases like Fedora 12, but for even for new versions in older releases (like current Qt 4.5.1 tracker [1] which blocks this release nearly about one month). If you think your bug is so important and it's blocker, talk to us, we add it to our tracker and then we are discussing progress on every KDE SIG meeting - you can join, you're welcome! If you join us, you can drive Fedora/KDE development even as users and only users... These important blocking bugs are never closed without working solution. [1] https://bugzilla.redhat.com/show_bug.cgi?id=497658 Jaroslav > (longer email on the whole thread coming.) > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net From choeger at cs.tu-berlin.de Thu Jun 4 07:59:03 2009 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 04 Jun 2009 09:59:03 +0200 Subject: evolution header: Mime-version: 1.0 In-Reply-To: <1244100642.19245.3.camel@choeger5.umpa.netz> References: <1244048485.14565.10.camel@choeger6> <20090603170936.GH4742@sventech.com> <1244100642.19245.3.camel@choeger5.umpa.netz> Message-ID: <1244102343.19245.10.camel@choeger5.umpa.netz> Am Donnerstag, den 04.06.2009, 09:30 +0200 schrieb Christoph H?ger: > Am Mittwoch, den 03.06.2009, 10:09 -0700 schrieb Johannes Erdfelt: > > On Wed, Jun 03, 2009, Christoph H?ger wrote: > > > I see a small problem with evolution when sending to mailinglists. > > > Obviously evolution puts: Mime-version: 1.0 in the header, hypermail > > > searches for MIME-version: and cannot find that string. So it adds it. > > > In turn my mail provider bounces the return message that should be sent > > > to me complaining about duplicate header field. > > > > > > So who is wrong here? Hypermail or evolution? Is non uppercase letter > > > Mime-version allowed? Anyone knowing the answer? > > > > Hypermail. > > > > Headers should be matched in a case insensitive manner. > > > > JE > > Where do you get that conclusion from? I can only cite RFC 2045 which > says: > > > Messages composed in accordance with this document MUST include such > > a header field, with the following verbatim text: > > > > MIME-Version: 1.0 Found RFC 5234 myself. Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From mhlavink at redhat.com Thu Jun 4 08:08:27 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Thu, 4 Jun 2009 10:08:27 +0200 Subject: Fedora 11 Test Day survey In-Reply-To: <1244038226.19989.45.camel@flatline.devel.redhat.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> Message-ID: <200906041008.27294.mhlavink@redhat.com> > 1. How did you find out about Fedora Test Days? fedora-devel-list > 2. Was sufficient documentation available to help you participate in a > Fedora Test Day? If not, what did you find missing or in need of > improvement? mostly, see examples: good: Test Day:2009-03-26 Nouveau " /sbin/lspci -d 10de: | grep -iq VGA && echo "Join Nouveau Fedora Test Day" || echo "No nVidia graphics hardware found." " bad: Test Day:2009-04-09 UEFI " FIXME|How to identify if your system supports UEFI? " This text was there for some time and than it just disappeared without any answer. > 3. Did you encounter any obstacles preventing participation in Fedora > test Days? How might they have been avoided? Did you discover any > workaround? let's have live cd for all test days (where it makes sense) > 4. Were you able to locate and download installation media for testing? > Did it function as expected? yes > 5. What follow-up actions do you expect after the Test Day? Are your > expectations currently being met? imo it's ok now > 6. Would you participate again in future Fedora Test Days? yes > 7. Do you have any more general comments or any suggestions for > improving future test days? start them earlier in rawhide development phase. If tens of bugs are found three weeks before freeze, we can hardly expect they are fixed in time. From mefoster at gmail.com Thu Jun 4 08:09:32 2009 From: mefoster at gmail.com (Mary Ellen Foster) Date: Thu, 4 Jun 2009 09:09:32 +0100 Subject: KPackageKit fail In-Reply-To: <20090604090723.0318a2fb@leela> References: <64b14b300906032334v735a922r422e7ab0b5ce7116@mail.gmail.com> <20090604090723.0318a2fb@leela> Message-ID: 2009/6/4 Michal Schmidt : > Dne Thu, 4 Jun 2009 08:34:40 +0200 > Valent Turkovic napsal(a): > >> I'm testing Rawhide with latest updates and KPackageKit fails to do >> updates, I get this error log: >> http://fpaste.org/paste/13851 >> >> It is works for you haven't tested it please do, if it works for you >> then ignore this message, if not then reply if you need some more >> feedback from me and I will open a new bug report then. > > Looks like https://bugzilla.redhat.com/show_bug.cgi?id=502399 Actually, it's probably https://bugzilla.redhat.com/show_bug.cgi?id=503989 ... MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ ICCS, School of Informatics, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From hk at isphuset.no Thu Jun 4 08:15:07 2009 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Thu, 04 Jun 2009 10:15:07 +0200 Subject: Maintainer Responsibilities In-Reply-To: <4A267EA0.20600@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <20090603113809.3ad3d992@faldor.intranet> <4A266755.6080904@freenet.de> <20090603150057.7d9fc5db@faldor.intranet> <4A267EA0.20600@freenet.de> Message-ID: <1244103307.2502.45.camel@hk> On Wed, 2009-06-03 at 15:46 +0200, Ralf Corsepius wrote: > Or less abstract: > I stopped reporting bugs against Fedora's evolution, because its @RH > maintainer preferred to close bugs and tried to push me around to > upstream. Wrt. evolution, I was an ordinary user and am not interested > in getting further involved. +1 (Though not related to evolution, mbarnes has been great to me) I would like to report bugs that I happen to stumble over even when I dont need it fixed or dont even need the package. I want to report that the bug is there and provide the details that I can, so that fedora knows that the bug exists. I dont want to go around chasing developers upstream if I dont really care about the bug/package. However, on a few instances I have been met with a negative attitude stating that "You MUST report this " (...to upstream). This has stopped me from sending bug reports to fedora unless I really do need the bug fixed or actually use the package. The program in this particular case was one I was just testing out of curiosity (one of several). I found a bug and reported it. I dont have time to chase every bug upstream. This was a close-to-f11-rawhide version. It did get "CLOSED UPSTREAM". I dont want to go personal on this because I know this is a matter of opinion and several other maintainers are also following this routine, so I wont post the bug number here. However any sufficiently interested parties would have no problem searching through my reported bugs to find it. (The others would however be harder since they were posted from a different email address) I do hope this gets changed, because I believe it is valuable to fedora to know what bugs do exist, especially when about to release a new version. Sincerly Hans K. Rosbach From twaugh at redhat.com Thu Jun 4 09:01:56 2009 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 04 Jun 2009 10:01:56 +0100 Subject: Maintainer Responsibilities In-Reply-To: <200906040935.45912.jreznik@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> <4A2770CB.8090708@freenet.de> <200906040935.45912.jreznik@redhat.com> Message-ID: <1244106116.6276.11.camel@worm> My own opinion is that the package maintainer is responsible for reporting bugs upstream when they are able to reproduce them. One reason for my belief is that I've seen the situation from the other side: as an upstream maintainer for a package, getting bug reports directly from users of a packaged version in another operating system. It can be a frustrating experience because the person reporting the bug can never be quite sure which version they are using (due to additional patches used in packaging), and generally are not able to try out suggested patches or pull from a source code repository. My point is that it isn't only the people reporting bugs that get frustrated by "go report it upstream", it is also the larger free software community. Another reason for maintainers to give bug reports due diligence is that it is hard to report bugs. Package maintainers may not always appreciate this, since they do it all the time, but look at bugzilla as though you've never seen it before (or just remember back to when you first saw it) -- it is hard to fill out a huge form, and if the problem is not severe enough to warrant your time on it (or you aren't even sure if it's a bug) you may just not bother. Bug reporters are absolutely essential to healthy free software and should be treated with respect. They are our eyes. Roll on ABRT. Tim. */ -------------- 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 mcepl at redhat.com Thu Jun 4 09:07:01 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 4 Jun 2009 09:07:01 +0000 (UTC) Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906031047.26436.jreznik@redhat.com> <200906031252.38232.Juha.Tuomala@iki.fi> <200906031301.01385.jreznik@redhat.com> Message-ID: Jaroslav Reznik, Wed, 03 Jun 2009 13:01:01 +0200: > Most bugs are filled by quite technically skilled users. It doesn't seem so from my point of view. Depends on the importance of the bug (when Xorg doesn't start at all, they find a way to bugzilla). Moreover, we want to move from fora to bugzilla ... my personal hatred to fora is comparable only with my disgust for du?en? moze?ek (intentionally not translating to English to protect innocent ;-)). Matej From mcepl at redhat.com Thu Jun 4 09:26:39 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 4 Jun 2009 09:26:39 +0000 (UTC) Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031047.26436.jreznik@redhat.com> <4A26662A.9010802@freenet.de> Message-ID: Ralf Corsepius, Wed, 03 Jun 2009 14:01:46 +0200: >> We are not forcing anyone to do anything but we think direct >> communication between user and developer is much more better > > I consider maintainers redirecting arbitrary reporters to upstreams to > be rude and hostile, because they are presuming the reporter to be > * interested in tracking down bugs > * interested in getting involved into upstreams > * technically able to do so. > > This occasionally applies to developers - To normal users it usally > doesn't apply, they want "to have their issue fixed". I am quite surprised to totally agree with you this time ;-), and I am even more surprised to finally a situation where actually technology could help to resolve interpersonal problems, but I think if somebody skilled in programming Perl (hint, hint) would work on https:// bugzilla.redhat.com/show_bug.cgi?id=189813 (and its upstream counterparts), situation of our reporters COULD improve. Mat?j From frankly3d at gmail.com Thu Jun 4 09:37:58 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Thu, 04 Jun 2009 10:37:58 +0100 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031047.26436.jreznik@redhat.com> <4A26662A.9010802@freenet.de> Message-ID: <4A2795F6.6030000@gmail.com> Matej Cepl wrote: but I think if somebody > skilled in programming Perl (hint, hint) would work on https:// > bugzilla.redhat.com/show_bug.cgi?id=189813 (and its upstream > counterparts), situation of our reporters COULD improve. > > Mat?j > Is it time then to setup programming-list at fedoraproject.org as distinct from Packaging\Maintaining Where those involved in the project and aspiring programmers\students can maybe be sent. For both mentoring\ and practical involvement with some sort of wiki page\wishlist. Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible From opensource at till.name Thu Jun 4 10:04:07 2009 From: opensource at till.name (Till Maas) Date: Thu, 04 Jun 2009 12:04:07 +0200 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <200906031301.01385.jreznik@redhat.com> Message-ID: <200906041204.15608.opensource@till.name> On Wed June 3 2009, Kevin Kofler wrote: > And I don't think we can make bug reports any easier, the point is that the > information is required, those "complicated" forms are there to request the > information we need. I disagree: On https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora there are around 29 form elements and the majority of these elements does not need to be used by the non experienced bug reporter or are not used at all. Absolutely required are imho: component, version, summary, description, security sensitive bug, External Bug and sometimes attachments or URL (8 elements). Rarely the platform is required, but there does not need to be such a long list of different archs for the normal user. There are also some elements that are not used at all: OS, Target Milestone, QA Contact, Estimated Hours and Deadline (5 elements) or not yet always used: severity and priority. Also the "Fedora Project Contributors" checkbox seems not to be used. The other elements are only used by experienced bug reporters or within the triage process, e.g. Assign To, CC, Alias, Whiteboard, Clone Of, Keywords, Depends on, blocks, 4 flags (12 elements). In conclusion, more than 66% of the form elements can be removed for the unexperienced bug reporter. Also the component selection process could be made easier, because the mapping from rpms to components could be made automatically after a bug reporter supplied the name of the rpm he had problems with. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mcepl at redhat.com Thu Jun 4 10:08:35 2009 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 4 Jun 2009 10:08:35 +0000 (UTC) Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906030843.26442.sgrubb@redhat.com> <1244064907.2937.346.camel@adam.local.net> Message-ID: Adam Williamson, Wed, 03 Jun 2009 14:35:07 -0700: > There's an obvious answer to this question: we track the importance of > issues to Fedora via the Fedora bug tracker, not via upstream bug > trackers. There's no way I can mark a bug in the KDE bug tracker as > blocking the release of Fedora 12. For an exmaple see https://bugzilla.redhat.com/show_bug.cgi?id=494985 and why it doesn't work https://bugzilla.redhat.com/show_bug.cgi?id=452962 (and yes, it would be wonderful if we could go even further ... blocking our bugs by upstream ones). Mat?j From valent.turkovic at gmail.com Thu Jun 4 10:21:27 2009 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 4 Jun 2009 12:21:27 +0200 Subject: KPackageKit fail In-Reply-To: <4A277241.4080208@gmail.com> References: <64b14b300906032334v735a922r422e7ab0b5ce7116@mail.gmail.com> <4A277241.4080208@gmail.com> Message-ID: <64b14b300906040321ged0d036w8c6e41f67dab71f2@mail.gmail.com> On Thu, Jun 4, 2009 at 9:05 AM, Frank Murphy (Frankly3d) wrote: > Valent Turkovic wrote: >> >> I'm testing Rawhide with latest updates and KPackageKit fails to do >> updates, I get this error log: >> http://fpaste.org/paste/13851 >> >> It is works for you haven't tested it please do, if it works for you >> then ignore this message, if not then reply if you need some more >> feedback from me and I will open a new bug report then. >> >> >> Cheers >> >> > > > Hi Valent. > > You might have better luck with rawhide questions on the test-list. > Also check the bugzilla against existing kpackagekit\rawhide bugs. Ok, thank you Frank. I will. BTW I checked bugzilla prior to sending this mail but didn't look too deep and didn't see any bug that I recognized as a duplicate, but then again, I could have easily missed it, so that is why I send an email. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From promac at gmail.com Thu Jun 4 10:23:59 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Thu, 4 Jun 2009 07:23:59 -0300 Subject: Question about web applications Message-ID: <68720af30906040323n1856ae79h24eabaf2677015ae@mail.gmail.com> Hi, I submitted ampache (http://ampache.org/) for review, but I was told that it could not use any external software bundled in the code. In fact, it uses getid3, a file that seems to come from horde (horde/Browser.php), and some others. According to the weekpedia (http://en.wikipedia.org/wiki/Ampache) "Ampache has been featured in numerous online blogs and technical articles. One of the more notable was the O'Reilly book Spidering Hackswhich tested the security of online applications. Ampache was found to be immune to standard spidering hacks as described in the O'Reilly article, and it has continued that trend by focusing on security during its development. The Code Philosophy listed on Ampache's wiki specifically lists security as one of those most important considerations during application development." Does it make any sense to fiddle something that has always had security as a prime concern? Any comment is welcome. Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreznik at redhat.com Thu Jun 4 10:25:00 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Thu, 4 Jun 2009 12:25:00 +0200 Subject: Maintainer Responsibilities In-Reply-To: <1244106116.6276.11.camel@worm> References: <200906021617.12122.sgrubb@redhat.com> <200906040935.45912.jreznik@redhat.com> <1244106116.6276.11.camel@worm> Message-ID: <200906041225.00624.jreznik@redhat.com> On Jueves 04 Junio 2009 11:01:56 Tim Waugh escribi?: > My own opinion is that the package maintainer is responsible for > reporting bugs upstream when they are able to reproduce them. > > One reason for my belief is that I've seen the situation from the other > side: as an upstream maintainer for a package, getting bug reports > directly from users of a packaged version in another operating system. > > It can be a frustrating experience because the person reporting the bug > can never be quite sure which version they are using (due to additional > patches used in packaging), and generally are not able to try out > suggested patches or pull from a source code repository. As I said - I don't want to left user in upstream jungle :-) It's more like moving bug closer to developer - user which report it is in contact with developer (that real upstream developer) and we can provide for upstream more details from Fedora side + prepare package for user to test it etc. Simple - collaboration - open source :-) Aim is fix the bug - then user is happy, we are happy and upstream is happy! > My point is that it isn't only the people reporting bugs that get > frustrated by "go report it upstream", it is also the larger free > software community. > > Another reason for maintainers to give bug reports due diligence is that > it is hard to report bugs. Package maintainers may not always > appreciate this, since they do it all the time, but look at bugzilla as > though you've never seen it before (or just remember back to when you > first saw it) -- it is hard to fill out a huge form, and if the problem > is not severe enough to warrant your time on it (or you aren't even sure > if it's a bug) you may just not bother. But this is another problem - BZ is really big monster (every time I'm reporting bug I'm scared :D). I have small PyGtk RHBZ reporter, maybe I'll release it some day (there are hardcoded passwords etc...). > Bug reporters are absolutely essential to healthy free software and > should be treated with respect. They are our eyes. > > Roll on ABRT. And new Dr. Konqui with nice guide to report crash - directly upstream. I talked with ABRT developers about closer collaboration, we'll see. Jaroslav > > Tim. > */ -- Jaroslav ?ezn?k Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ From mschwendt at gmail.com Thu Jun 4 10:29:18 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 4 Jun 2009 12:29:18 +0200 Subject: Orphaning Packages: audacious and dependencies In-Reply-To: <68720af30906031431s345fb7e0wa696b2eeb313f194@mail.gmail.com> References: <20090603184627.4297a25b@lain.camperquake.de> <68720af30906031431s345fb7e0wa696b2eeb313f194@mail.gmail.com> Message-ID: <20090604122918.69160c49@faldor.intranet> On Wed, 3 Jun 2009 18:31:27 -0300, Paulo wrote: > > Hi. > > > > As I don't have the time to maintain audacious any more I'm orphaning the > > following packages: > > > > audacious > > audacious-plugins > > libmowgli > > mcs > > > > The last two are dependencies which, as far as I am aware, are used by > > nothing else. > > > > There is an accompanying package in the Voldemort Repository which contains > > the less free and more useful media codecs. That would be up for grabs, > > too, preferrably by the same person. > > > > There are several bugs open against the package, most of which will > > probably be fixed by the current upstream release. > > I have some limited interest in Audacious only, because it's one of the music players I use from time to time. I would be willing to examine the current state of the Fedora packages, the currently open bugs, and take a look at the new stable 2.0 series, too. The 1.5 series has been declared legacy. However, I don't want to take over the packages in the external repository. As such, anybody else who wants all of the packages would take precedence. > The new binaries are called audiocious2 and audtool2, and they seem to be > working just fine. > > In theory, it would be possible to keep the old audacious and the new one. > Another possibility is just to rename some files to match the previous > version. That would deviate from upstream and break any scripts users may use to control a running instance of Audacious2. If the two releases can coexist, I would say we don't make them conflict with eachother. From sundaram at fedoraproject.org Thu Jun 4 10:36:03 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 04 Jun 2009 16:06:03 +0530 Subject: Question about web applications In-Reply-To: <68720af30906040323n1856ae79h24eabaf2677015ae@mail.gmail.com> References: <68720af30906040323n1856ae79h24eabaf2677015ae@mail.gmail.com> Message-ID: <4A27A393.6000200@fedoraproject.org> On 06/04/2009 03:53 PM, Paulo Cavalcanti wrote: > Hi, > > I submitted ampache (http://ampache.org/) for review, but I was told > that it could not use any external software > bundled in the code. In fact, it uses getid3, a file that seems to come > from horde (horde/Browser.php), > and some others. Submit separate review requests for independent projects bundled within the source and add them as dependencies once they are approved. > Does it make any sense to fiddle something that has always had security > as a prime concern? Yes, security is precisely one of the concerns with bundling independent sources together since bug fixes and security vulnerabilities will exist hidden. Rahul From mefoster at gmail.com Thu Jun 4 10:42:48 2009 From: mefoster at gmail.com (Mary Ellen Foster) Date: Thu, 4 Jun 2009 11:42:48 +0100 Subject: KPackageKit fail In-Reply-To: References: <64b14b300906032334v735a922r422e7ab0b5ce7116@mail.gmail.com> <20090604090723.0318a2fb@leela> Message-ID: 2009/6/4 Mary Ellen Foster : > 2009/6/4 Michal Schmidt : >>> http://fpaste.org/paste/13851 >>> >> >> Looks like https://bugzilla.redhat.com/show_bug.cgi?id=502399 > > Actually, it's probably https://bugzilla.redhat.com/show_bug.cgi?id=503989 ... Sorry, should have read the backtrace -- that is indeed 502399. 503989is *another* problem. (Woohoo.) MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ ICCS, School of Informatics, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From mschwendt at gmail.com Thu Jun 4 10:51:29 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 4 Jun 2009 12:51:29 +0200 Subject: [Bug 484862] GConf2-dbus : Conflicts with other packages In-Reply-To: References: <200906031545.n53FjRYb004944@bz-web2.app.phx.redhat.com> <20090603175919.5a0f5d68@faldor.intranet> Message-ID: <20090604125129.19995d7b@faldor.intranet> On Wed, 03 Jun 2009 23:13:31 +0200, Kevin wrote: > > Why are the relevant Obsoletes missing (commented out)? > > Because if they were there, everyone would get the OLPC-patched package > instead of the stock Fedora one. They should be Conflicts, not Obsoletes. Yeah, yeah, I had reported this a few months ago, and the spec has the Obsoletes/Provides commented out. Meanwhile, a Conflicts tag has been added to GConf2 (bz 492636). From david at gnsa.us Thu Jun 4 11:00:25 2009 From: david at gnsa.us (David Nalley) Date: Thu, 4 Jun 2009 07:00:25 -0400 Subject: Question about web applications In-Reply-To: <68720af30906040323n1856ae79h24eabaf2677015ae@mail.gmail.com> References: <68720af30906040323n1856ae79h24eabaf2677015ae@mail.gmail.com> Message-ID: On Thu, Jun 4, 2009 at 6:23 AM, Paulo Cavalcanti wrote: > Hi, > > I submitted ampache (http://ampache.org/) for review, but I was told that it > could not use any external software > bundled in the code. In fact, it uses getid3, a file that seems to come from > horde (horde/Browser.php), > and some others. > > According to the weekpedia (http://en.wikipedia.org/wiki/Ampache) > > "Ampache has been featured in numerous online blogs and technical articles. > One of the more notable was the O'Reilly book Spidering Hacks which tested > the security of online applications. Ampache was found to be immune to > standard spidering hacks as described in the O'Reilly article, and it has > continued that trend by focusing on security during its development. The > Code Philosophy listed on Ampache's wiki specifically lists security as one > of those most important considerations during application development." > > Does it make any sense to fiddle something that has always had security as a > prime concern? > > Any comment is welcome. > > Thanks. > > -- > Paulo Roma Cavalcanti > LCG - UFRJ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Perhaps I am the least well suited to respond as I did some of the initial review. However, there are at least 10 bundled libraries with ampache, including pear-XML_RPC, nusoap, getid3, small snippets from Horde, captchaphp, php-Snoopy, etc. In addition to the security benefits, creating the separate package means other packages (even other web apps) can make use of the libraries that would be available in Fedora instead of just ampache. I can empathize with the extra work that this causes, as I am trying to fix a few of these problems with another web app. From andreas at bawue.net Thu Jun 4 11:25:36 2009 From: andreas at bawue.net (Andreas Thienemann) Date: Thu, 4 Jun 2009 13:25:36 +0200 (CEST) Subject: (Most) Results from the Candidate Questionnaire are available now In-Reply-To: <200906040212.56937.opensource@till.name> References: <4A26CEE4.7050300@leemhuis.info> <200906040212.56937.opensource@till.name> Message-ID: On Thu, 4 Jun 2009, Till Maas wrote: > I tried to add such a table[0], but I failed to enable the horizotnal > scrollbar. I even enabled javascript for the wiki, but it still does not work. > Is this somehow broken in our mediawiki CSS setup? I noticed the css files > contain overflow:hidden in several places. Yes, our wiki CSS is broken. I've encountered that problem several times in the past and tried raising it to the right people in our infrastructure team on #fedora-admin at the 7th of April 2009. Sadly, nothing has happened since then and I added fedoraproject.org onto the css blacklist of my browser. It might not look as nice anymore but at least I have a scrollbar when I need it. :-( regards, andreas From promac at gmail.com Thu Jun 4 11:33:36 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Thu, 4 Jun 2009 08:33:36 -0300 Subject: Question about web applications In-Reply-To: References: <68720af30906040323n1856ae79h24eabaf2677015ae@mail.gmail.com> Message-ID: <68720af30906040433i404c9den56658088cf668676@mail.gmail.com> On Thu, Jun 4, 2009 at 8:00 AM, David Nalley wrote: > On Thu, Jun 4, 2009 at 6:23 AM, Paulo Cavalcanti wrote: > > Hi, > > > > I submitted ampache (http://ampache.org/) for review, but I was told > that it > > could not use any external software > > bundled in the code. In fact, it uses getid3, a file that seems to come > from > > horde (horde/Browser.php), > > and some others. > > > > According to the weekpedia (http://en.wikipedia.org/wiki/Ampache) > > > > "Ampache has been featured in numerous online blogs and technical > articles. > > One of the more notable was the O'Reilly book Spidering Hacks which > tested > > the security of online applications. Ampache was found to be immune to > > standard spidering hacks as described in the O'Reilly article, and it has > > continued that trend by focusing on security during its development. The > > Code Philosophy listed on Ampache's wiki specifically lists security as > one > > of those most important considerations during application development." > > > > Does it make any sense to fiddle something that has always had security > as a > > prime concern? > > > > Any comment is welcome. > > > > Thanks. > > > > -- > > Paulo Roma Cavalcanti > > LCG - UFRJ > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > Perhaps I am the least well suited to respond as I did some of the > initial review. No, on the contrary. > > However, there are at least 10 bundled libraries with ampache, > including pear-XML_RPC, nusoap, getid3, small snippets from Horde, > captchaphp, php-Snoopy, etc. > > In addition to the security benefits, creating the separate package > means other packages (even other web apps) can make use of the > libraries that would be available in Fedora instead of just ampache. > I can empathize with the extra work that this causes, as I am trying > to fix a few of these problems with another web app. > > Maybe we can list all of the packages we would like to have for web applications, and try to set a "task force" to cope with them? I think if we had three or four people willing to help, the work would be concluded fast. There are always people looking forward to contributing, but without a good package to work with. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at till.name Thu Jun 4 11:35:51 2009 From: opensource at till.name (Till Maas) Date: Thu, 04 Jun 2009 13:35:51 +0200 Subject: (Most) Results from the Candidate Questionnaire are available now In-Reply-To: References: <4A26CEE4.7050300@leemhuis.info> <200906040212.56937.opensource@till.name> Message-ID: <200906041335.57044.opensource@till.name> On Thu June 4 2009, Andreas Thienemann wrote: > On Thu, 4 Jun 2009, Till Maas wrote: > > I tried to add such a table[0], but I failed to enable the horizotnal > > scrollbar. I even enabled javascript for the wiki, but it still does not > > work. Is this somehow broken in our mediawiki CSS setup? I noticed the > > css files contain overflow:hidden in several places. > > Yes, our wiki CSS is broken. > > I've encountered that problem several times in the past and tried raising > it to the right people in our infrastructure team on #fedora-admin at the > 7th of April 2009. I created a ticket here, maybe it helps: https://fedorahosted.org/fedora-infrastructure/ticket/1438 Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From david at gnsa.us Thu Jun 4 11:41:29 2009 From: david at gnsa.us (David Nalley) Date: Thu, 4 Jun 2009 07:41:29 -0400 Subject: Question about web applications In-Reply-To: <68720af30906040433i404c9den56658088cf668676@mail.gmail.com> References: <68720af30906040323n1856ae79h24eabaf2677015ae@mail.gmail.com> <68720af30906040433i404c9den56658088cf668676@mail.gmail.com> Message-ID: On Thu, Jun 4, 2009 at 7:33 AM, Paulo Cavalcanti wrote: > > > On Thu, Jun 4, 2009 at 8:00 AM, David Nalley wrote: >> >> On Thu, Jun 4, 2009 at 6:23 AM, Paulo Cavalcanti wrote: >> > Hi, >> > >> > I submitted ampache (http://ampache.org/) for review, but I was told >> > that it >> > could not use any external software >> > bundled in the code. In fact, it uses getid3, a file that seems to come >> > from >> > horde (horde/Browser.php), >> > and some others. >> > >> > According to the weekpedia (http://en.wikipedia.org/wiki/Ampache) >> > >> > "Ampache has been featured in numerous online blogs and technical >> > articles. >> > One of the more notable was the O'Reilly book Spidering Hacks which >> > tested >> > the security of online applications. Ampache was found to be immune to >> > standard spidering hacks as described in the O'Reilly article, and it >> > has >> > continued that trend by focusing on security during its development. The >> > Code Philosophy listed on Ampache's wiki specifically lists security as >> > one >> > of those most important considerations during application development." >> > >> > Does it make any sense to fiddle something that has always had security >> > as a >> > prime concern? >> > >> > Any comment is welcome. >> > >> > Thanks. >> > >> > -- >> > Paulo Roma Cavalcanti >> > LCG - UFRJ >> > >> > -- >> > fedora-devel-list mailing list >> > fedora-devel-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > >> >> >> Perhaps I am the least well suited to respond as I did some of the >> initial review. > > No, on the contrary. > >> >> However, there are at least 10 bundled libraries with ampache, >> including pear-XML_RPC, nusoap, getid3, small snippets from Horde, >> captchaphp, php-Snoopy, etc. >> >> In addition to the security benefits, creating the separate package >> means other packages (even other web apps) can make use of the >> libraries that would be available in Fedora instead of just ampache. >> I can empathize with the extra work that this causes, as I am trying >> to fix a few of these problems with another web app. >> > > Maybe we can list all of the packages we would like to have for web > applications, and try to set a "task force" to cope with them? > > I think if we had three or four people willing to help, the work would be > concluded fast. There are always people looking forward to contributing, > but without a good package to work with. > I think that's an outstanding idea, and I'd be willing to work towards such an end, and perhaps since there is such a prevalence of php we can get some buy-in from the php-sig as well. To illustrate some of the usefulness - I have a web app I am working on now that uses php-Snoopy as ampache also does, so that's at least two applications that can make use of the package. From bkearney at redhat.com Thu Jun 4 11:56:30 2009 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 04 Jun 2009 07:56:30 -0400 Subject: Packager = Programmer? In-Reply-To: <4A277C56.4080805@fedoraproject.org> References: <4A277B2A.5010808@gmail.com> <4A277C56.4080805@fedoraproject.org> Message-ID: <4A27B66E.5080703@redhat.com> Rahul Sundaram wrote: > On 06/04/2009 01:13 PM, Frank Murphy (Frankly3d) wrote: >> Does trying to become a packager. >> Involve being currently a Developer, >> as in Programming skills\certification, >> whether Perl\Python\c++ etc. > > Not necessarily. It's useful to understand the codebase but if you have > a active upstream responsive to bug reports, you can just take care of > the packaging aspects of it. You can always ask for help from others > within Fedora or upstream if needed. > > Rahul > I would content you need an ability to understand scripting languages (as spec files are really a DSL/scripting language) and an understanding of skills commonly associated with a developer: - Source Code Control - Source Layout - Software Component Types (e.g. scripts, libraries, documents, etc). however, as Rahul said, the ability to crank out the latest oCaml/Erlang/Java/C/Assembler/NameYourPoison is not required. -- bk From opensource at till.name Thu Jun 4 12:16:27 2009 From: opensource at till.name (Till Maas) Date: Thu, 04 Jun 2009 14:16:27 +0200 Subject: Fedora 11 Test Day survey In-Reply-To: <1244038226.19989.45.camel@flatline.devel.redhat.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> Message-ID: <200906041416.41427.opensource@till.name> On Wed June 3 2009, James Laska wrote: > 1. How did you find out about Fedora Test Days? devel mailing list > 2. Was sufficient documentation available to help you participate in a > Fedora Test Day? If not, what did you find missing or in need of > improvement? Yes. > 3. Did you encounter any obstacles preventing participation in Fedora > test Days? How might they have been avoided? Did you discover any > workaround? The live iso images failed to be converted to live usb media on F10 with a strange looking boot menu. It could have beend avoided with testing this before starting the test day. > 4. Were you able to locate and download installation media for testing? > Did it function as expected? Yes. No, see 3. Also I would have expected testing instructions on the live media to perform the tests without the need to setup an internet connection on the testing machine. Also some bug report info gathering scripts would have been nice, that e.g. collect all the data required by the packages maintainers for a bug report in some file on the usb medium. E.g. the Xorg people wanted a lot of information that I did not have anymore after I rebooted to my stable F10 system and reported the bug. Also when the test crashes the Xserver, it is very annoying to get to the log files, because they are deleted after a reboot. Also the media was not signed in a way that one can easily verify that it was not tampered with. E.g. the official Fedora releases are normally signed with a gpg key that can be obtained via the SSH secured CVS repository. > 5. What follow-up actions do you expect after the Test Day? Are your > expectations currently being met? The reported bugs should be fixed soon. > 6. Would you participate again in future Fedora Test Days? Yes. > 7. Do you have any more general comments or any suggestions for > improving future test days? It would be nice to automate the tests that need to be run, e.g. just boot the media and then the tests are automatically started and the user is asked for input in case something cannot be detected automatically. This is especially useful for testing hardware support, because the required testing actions are mostly simple, e.g. boot with this option, play this video, ... Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From nicolas.mailhot at laposte.net Thu Jun 4 12:18:33 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 4 Jun 2009 14:18:33 +0200 Subject: Maintainer Responsibilities In-Reply-To: <200906041204.15608.opensource@till.name> References: <200906021617.12122.sgrubb@redhat.com> <200906031301.01385.jreznik@redhat.com> <200906041204.15608.opensource@till.name> Message-ID: <0d1431c97cd225c77ffed87c1823a731.squirrel@arekh.dyndns.org> Le Jeu 4 juin 2009 12:04, Till Maas a ?crit : > In conclusion, more than 66% of the form elements can be removed for > the unexperienced bug reporter. Last time I reported this problem in the bugzilla component of redhat bugzilla (I complained about all the columns in list view no one uses when "last change" is not even displayed) the answer was that the people in charge did not want to deviate from upstream (bugzilla) defaults. Which, given all the historic redhat bugzilla customization, was a bit rich -- Nicolas Mailhot From MathStuf at gmail.com Thu Jun 4 12:18:53 2009 From: MathStuf at gmail.com (Ben Boeckel) Date: Thu, 04 Jun 2009 08:18:53 -0400 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906031301.01385.jreznik@redhat.com> <200906041204.15608.opensource@till.name> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Till Maas wrote: > On Wed June 3 2009, Kevin Kofler wrote: > >> And I don't think we can make bug reports any easier, the point is that the >> information is required, those "complicated" forms are there to request the >> information we need. > > I disagree: > > On https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora there are around > 29 form elements and the majority of these elements does not need to be used > by the non experienced bug reporter or are not used at all. > > Absolutely required are imho: component, version, summary, description, > security sensitive bug, External Bug and sometimes attachments or URL (8 > elements). Rarely the platform is required, but there does not need to be such > a long list of different archs for the normal user. > There are also some elements that are not used at all: OS, Target Milestone, > QA Contact, Estimated Hours and Deadline (5 elements) or not yet always used: > severity and priority. Also the "Fedora Project Contributors" checkbox seems > not to be used. > > The other elements are only used by experienced bug reporters or within the > triage process, e.g. Assign To, CC, Alias, Whiteboard, Clone Of, Keywords, > Depends on, blocks, 4 flags (12 elements). > > In conclusion, more than 66% of the form elements can be removed for the > unexperienced bug reporter. Also the component selection process could be made > easier, because the mapping from rpms to components could be made > automatically after a bug reporter supplied the name of the rpm he had > problems with. > > Regards > Till Maybe a form (like Review Request) for Simple Bug Report (or something) that's the default? I have the bug report page bookmarked in any case (the trail of links to get there from the front page is too much IMO; I haven't been able to get it below 3 or 4). - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkonu60ACgkQiPi+MRHG3qSjNQCfRThyKRYQaTh6ok55CxGDeyZ8 N4sAnRMfJm9/Qkh4IW2wgzNJ5pvazBRT =Ij9o -----END PGP SIGNATURE----- From sundaram at fedoraproject.org Thu Jun 4 12:27:00 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 04 Jun 2009 17:57:00 +0530 Subject: Maintainer Responsibilities In-Reply-To: <0d1431c97cd225c77ffed87c1823a731.squirrel@arekh.dyndns.org> References: <200906021617.12122.sgrubb@redhat.com> <200906031301.01385.jreznik@redhat.com> <200906041204.15608.opensource@till.name> <0d1431c97cd225c77ffed87c1823a731.squirrel@arekh.dyndns.org> Message-ID: <4A27BD94.1070606@fedoraproject.org> On 06/04/2009 05:48 PM, Nicolas Mailhot wrote: > > Last time I reported this problem in the bugzilla component of redhat > bugzilla (I complained about all the columns in list view no one uses > when "last change" is not even displayed) the answer was that the > people in charge did not want to deviate from upstream (bugzilla) > defaults. > > Which, given all the historic redhat bugzilla customization, was a bit > rich If you notice, Red Hat is steadily moving away from that and the customizations are either being upstream or removed and with new releases. So it matches the current direction. However it should be possible to turn off features we don't use in our bugzilla instance. Rahul From limb at jcomserv.net Thu Jun 4 12:28:28 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 04 Jun 2009 07:28:28 -0500 Subject: Question about web applications In-Reply-To: References: <68720af30906040323n1856ae79h24eabaf2677015ae@mail.gmail.com> <68720af30906040433i404c9den56658088cf668676@mail.gmail.com> Message-ID: <4A27BDEC.4000202@jcomserv.net> David Nalley wrote: > On Thu, Jun 4, 2009 at 7:33 AM, Paulo Cavalcanti wrote: > >> On Thu, Jun 4, 2009 at 8:00 AM, David Nalley wrote: >> >>> On Thu, Jun 4, 2009 at 6:23 AM, Paulo Cavalcanti wrote: >>> >>>> Hi, >>>> >>>> I submitted ampache (http://ampache.org/) for review, but I was told >>>> that it >>>> could not use any external software >>>> bundled in the code. In fact, it uses getid3, a file that seems to come >>>> from >>>> horde (horde/Browser.php), >>>> and some others. >>>> >>>> According to the weekpedia (http://en.wikipedia.org/wiki/Ampache) >>>> >>>> "Ampache has been featured in numerous online blogs and technical >>>> articles. >>>> One of the more notable was the O'Reilly book Spidering Hacks which >>>> tested >>>> the security of online applications. Ampache was found to be immune to >>>> standard spidering hacks as described in the O'Reilly article, and it >>>> has >>>> continued that trend by focusing on security during its development. The >>>> Code Philosophy listed on Ampache's wiki specifically lists security as >>>> one >>>> of those most important considerations during application development." >>>> >>>> Does it make any sense to fiddle something that has always had security >>>> as a >>>> prime concern? >>>> >>>> Any comment is welcome. >>>> >>>> Thanks. >>>> >>>> -- >>>> Paulo Roma Cavalcanti >>>> LCG - UFRJ >>>> >>>> -- >>>> fedora-devel-list mailing list >>>> fedora-devel-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>>> >>>> >>> Perhaps I am the least well suited to respond as I did some of the >>> initial review. >>> >> No, on the contrary. >> >> >>> However, there are at least 10 bundled libraries with ampache, >>> including pear-XML_RPC, nusoap, getid3, small snippets from Horde, >>> captchaphp, php-Snoopy, etc. >>> >>> In addition to the security benefits, creating the separate package >>> means other packages (even other web apps) can make use of the >>> libraries that would be available in Fedora instead of just ampache. >>> I can empathize with the extra work that this causes, as I am trying >>> to fix a few of these problems with another web app. >>> >>> >> Maybe we can list all of the packages we would like to have for web >> applications, and try to set a "task force" to cope with them? >> >> I think if we had three or four people willing to help, the work would be >> concluded fast. There are always people looking forward to contributing, >> but without a good package to work with. >> >> > > > I think that's an outstanding idea, and I'd be willing to work towards > such an end, and perhaps since there is such a prevalence of php we > can get some buy-in from the php-sig as well. To illustrate some of > the usefulness - I have a web app I am working on now that uses > php-Snoopy as ampache also does, so that's at least two applications > that can make use of the package. > > Count me in. I maintain several PHP apps, and having gone through the nightmare of switching from bundled to system libraries, I wholeheartedly agree that using system libraries from the beginning is the best way to go. Using the system lib means that security fixes are done in one place for all apps, and we don't have to patch the apps, or wait for upstream to push an update with an updated bundled lib. I'll help review, etc. -- in your fear, speak only peace in your fear, seek only love -d. bowie From emmanuel.seyman at club-internet.fr Thu Jun 4 12:36:18 2009 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Thu, 4 Jun 2009 14:36:18 +0200 Subject: Maintainer Responsibilities In-Reply-To: <200906041204.15608.opensource@till.name> References: <200906021617.12122.sgrubb@redhat.com> <200906031301.01385.jreznik@redhat.com> <200906041204.15608.opensource@till.name> Message-ID: <20090604123618.GA4079@orient.maison.lan> * Till Maas [04/06/2009 13:41] : > > In conclusion, more than 66% of the form elements can be removed for the > unexperienced bug reporter. Also the component selection process could be made You are seeing some of these elements because you are in the 'editbugs' group. Unexperienced bug reporters will probably not be. Emmanuel From mschwendt at gmail.com Thu Jun 4 12:48:53 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 4 Jun 2009 14:48:53 +0200 Subject: Orphaning Packages: audacious and dependencies In-Reply-To: <20090603184627.4297a25b@lain.camperquake.de> References: <20090603184627.4297a25b@lain.camperquake.de> Message-ID: <20090604144853.144f43cf@faldor.intranet> On Wed, 3 Jun 2009 18:46:27 +0200, Ralf wrote: > Hi. > > As I don't have the time to maintain audacious any more I'm orphaning the > following packages: > > audacious > audacious-plugins > libmowgli > mcs > > The last two are dependencies which, as far as I am aware, are used by > nothing else. "conky" and "kadu-audacious_mediaplayer" depend on libmowgli and libmcs. From musuruan at gmail.com Thu Jun 4 13:11:41 2009 From: musuruan at gmail.com (Andrea Musuruane) Date: Thu, 4 Jun 2009 15:11:41 +0200 Subject: Client-side certificate generation error Message-ID: <29fee02b0906040611y6e67bdd0o423c3fc438489a0@mail.gmail.com> Hi all, my client-side certificate is expired. I tried to generate a new one on the Fedora Account System, but I get an error saying "Your certificate could not be generated.". Not very helpful as an error message. I do not know what should I do. Can someone help? Thanks, Andrea. From kevin.kofler at chello.at Thu Jun 4 13:20:26 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 15:20:26 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> <4A2770CB.8090708@freenet.de> Message-ID: Ralf Corsepius wrote: > You are still presuming your users to be interested in developing and > working on your package. > > This simply does not apply - They want to use your package. I see 2 possibilities: * either the user wants his/her bug fixed, in that case he/she is responsible for reporting it to the appropriate place, * or the user does not care about having the bug fixed, that's fine with me, we can just close it, less work for me. ;-) If somebody actually cares, he/she'll report it upstream. If nobody cares, why bother fixing it? Kevin Kofler From kevin.kofler at chello.at Thu Jun 4 13:23:16 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 15:23:16 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <4A2770CB.8090708@freenet.de> <200906040935.45912.jreznik@redhat.com> <1244106116.6276.11.camel@worm> Message-ID: Tim Waugh wrote: > It can be a frustrating experience because the person reporting the bug > can never be quite sure which version they are using (due to additional > patches used in packaging), and generally are not able to try out > suggested patches or pull from a source code repository. We can build a patched package if there's a fix to try, but that doesn't mean the user shouldn't be CCed on or the reporter of the upstream bug as well, it just means we should be CCed too (which we usually are, unless we forget for some reason, we're just human too). Kevin Kofler From promac at gmail.com Thu Jun 4 13:27:33 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Thu, 4 Jun 2009 10:27:33 -0300 Subject: Question about web applications In-Reply-To: <4A27BDEC.4000202@jcomserv.net> References: <68720af30906040323n1856ae79h24eabaf2677015ae@mail.gmail.com> <68720af30906040433i404c9den56658088cf668676@mail.gmail.com> <4A27BDEC.4000202@jcomserv.net> Message-ID: <68720af30906040627s4b1a46ecic81b2cc087e0a536@mail.gmail.com> On Thu, Jun 4, 2009 at 9:28 AM, Jon Ciesla wrote: > David Nalley wrote: > >> On Thu, Jun 4, 2009 at 7:33 AM, Paulo Cavalcanti >> wrote: >> >> >>> On Thu, Jun 4, 2009 at 8:00 AM, David Nalley wrote: >>> >>> >>>> On Thu, Jun 4, 2009 at 6:23 AM, Paulo Cavalcanti >>>> wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> I submitted ampache (http://ampache.org/) for review, but I was told >>>>> that it >>>>> could not use any external software >>>>> bundled in the code. In fact, it uses getid3, a file that seems to come >>>>> from >>>>> horde (horde/Browser.php), >>>>> and some others. >>>>> >>>>> According to the weekpedia (http://en.wikipedia.org/wiki/Ampache) >>>>> >>>>> "Ampache has been featured in numerous online blogs and technical >>>>> articles. >>>>> One of the more notable was the O'Reilly book Spidering Hacks which >>>>> tested >>>>> the security of online applications. Ampache was found to be immune to >>>>> standard spidering hacks as described in the O'Reilly article, and it >>>>> has >>>>> continued that trend by focusing on security during its development. >>>>> The >>>>> Code Philosophy listed on Ampache's wiki specifically lists security as >>>>> one >>>>> of those most important considerations during application development." >>>>> >>>>> Does it make any sense to fiddle something that has always had security >>>>> as a >>>>> prime concern? >>>>> >>>>> Any comment is welcome. >>>>> >>>>> Thanks. >>>>> >>>>> -- >>>>> Paulo Roma Cavalcanti >>>>> LCG - UFRJ >>>>> >>>>> -- >>>>> fedora-devel-list mailing list >>>>> fedora-devel-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>>>> >>>>> >>>>> >>>> Perhaps I am the least well suited to respond as I did some of the >>>> initial review. >>>> >>>> >>> No, on the contrary. >>> >>> >>> >>>> However, there are at least 10 bundled libraries with ampache, >>>> including pear-XML_RPC, nusoap, getid3, small snippets from Horde, >>>> captchaphp, php-Snoopy, etc. >>>> >>>> In addition to the security benefits, creating the separate package >>>> means other packages (even other web apps) can make use of the >>>> libraries that would be available in Fedora instead of just ampache. >>>> I can empathize with the extra work that this causes, as I am trying >>>> to fix a few of these problems with another web app. >>>> >>>> >>>> >>> Maybe we can list all of the packages we would like to have for web >>> applications, and try to set a "task force" to cope with them? >>> >>> I think if we had three or four people willing to help, the work would be >>> concluded fast. There are always people looking forward to contributing, >>> but without a good package to work with. >>> >>> >>> >> >> >> I think that's an outstanding idea, and I'd be willing to work towards >> such an end, and perhaps since there is such a prevalence of php we >> can get some buy-in from the php-sig as well. To illustrate some of >> the usefulness - I have a web app I am working on now that uses >> php-Snoopy as ampache also does, so that's at least two applications >> that can make use of the package. >> >> >> > Count me in. I maintain several PHP apps, and having gone through the > nightmare of switching from bundled to system libraries, I wholeheartedly > agree that using system libraries from the beginning is the best way to go. > Using the system lib means that security fixes are done in one place for > all apps, and we don't have to patch the apps, or wait for upstream to push > an update with an updated bundled lib. > > I'll help review, etc. > > Thank you Jon. I will start with getid3. It would be nice if we had a list of packages missing available elsewhere, so people, interested in helping, could choose what to pack. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From limb at jcomserv.net Thu Jun 4 13:29:32 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 04 Jun 2009 08:29:32 -0500 Subject: Question about web applications In-Reply-To: <68720af30906040627s4b1a46ecic81b2cc087e0a536@mail.gmail.com> References: <68720af30906040323n1856ae79h24eabaf2677015ae@mail.gmail.com> <68720af30906040433i404c9den56658088cf668676@mail.gmail.com> <4A27BDEC.4000202@jcomserv.net> <68720af30906040627s4b1a46ecic81b2cc087e0a536@mail.gmail.com> Message-ID: <4A27CC3C.3010305@jcomserv.net> Paulo Cavalcanti wrote: > > > On Thu, Jun 4, 2009 at 9:28 AM, Jon Ciesla > wrote: > > David Nalley wrote: > > On Thu, Jun 4, 2009 at 7:33 AM, Paulo Cavalcanti > > wrote: > > > On Thu, Jun 4, 2009 at 8:00 AM, David Nalley > > wrote: > > > On Thu, Jun 4, 2009 at 6:23 AM, Paulo Cavalcanti > > wrote: > > > Hi, > > I submitted ampache (http://ampache.org/) for > review, but I was told > that it > could not use any external software > bundled in the code. In fact, it uses getid3, a > file that seems to come > from > horde (horde/Browser.php), > and some others. > > According to the weekpedia > (http://en.wikipedia.org/wiki/Ampache) > > "Ampache has been featured in numerous online > blogs and technical > articles. > One of the more notable was the O'Reilly book > Spidering Hacks which > tested > the security of online applications. Ampache was > found to be immune to > standard spidering hacks as described in the > O'Reilly article, and it > has > continued that trend by focusing on security > during its development. The > Code Philosophy listed on Ampache's wiki > specifically lists security as > one > of those most important considerations during > application development." > > Does it make any sense to fiddle something that > has always had security > as a > prime concern? > > Any comment is welcome. > > Thanks. > > -- > Paulo Roma Cavalcanti > LCG - UFRJ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > Perhaps I am the least well suited to respond as I did > some of the > initial review. > > > No, on the contrary. > > > > However, there are at least 10 bundled libraries with > ampache, > including pear-XML_RPC, nusoap, getid3, small snippets > from Horde, > captchaphp, php-Snoopy, etc. > > In addition to the security benefits, creating the > separate package > means other packages (even other web apps) can make > use of the > libraries that would be available in Fedora instead of > just ampache. > I can empathize with the extra work that this causes, > as I am trying > to fix a few of these problems with another web app. > > > > Maybe we can list all of the packages we would like to > have for web > applications, and try to set a "task force" to cope with them? > > I think if we had three or four people willing to help, > the work would be > concluded fast. There are always people looking forward to > contributing, > but without a good package to work with. > > > > > > I think that's an outstanding idea, and I'd be willing to work > towards > such an end, and perhaps since there is such a prevalence of > php we > can get some buy-in from the php-sig as well. To illustrate > some of > the usefulness - I have a web app I am working on now that uses > php-Snoopy as ampache also does, so that's at least two > applications > that can make use of the package. > > > > Count me in. I maintain several PHP apps, and having gone through > the nightmare of switching from bundled to system libraries, I > wholeheartedly agree that using system libraries from the > beginning is the best way to go. Using the system lib means that > security fixes are done in one place for all apps, and we don't > have to patch the apps, or wait for upstream to push an update > with an updated bundled lib. > > I'll help review, etc. > > > Thank you Jon. I will start with getid3. > > It would be nice if we had a list of packages missing available elsewhere, > so people, interested in helping, could choose what to pack. > > > -- > Paulo Roma Cavalcanti > LCG - UFRJ You mean like a subcategory of http://fedoraproject.org/wiki/PackageMaintainers/WishList ? -- in your fear, speak only peace in your fear, seek only love -d. bowie -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Thu Jun 4 13:31:17 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 04 Jun 2009 19:01:17 +0530 Subject: Question about web applications In-Reply-To: <68720af30906040627s4b1a46ecic81b2cc087e0a536@mail.gmail.com> References: <68720af30906040323n1856ae79h24eabaf2677015ae@mail.gmail.com> <68720af30906040433i404c9den56658088cf668676@mail.gmail.com> <4A27BDEC.4000202@jcomserv.net> <68720af30906040627s4b1a46ecic81b2cc087e0a536@mail.gmail.com> Message-ID: <4A27CCA5.7070001@fedoraproject.org> On 06/04/2009 06:57 PM, Paulo Cavalcanti wrote: > > Thank you Jon. I will start with getid3. > > It would be nice if we had a list of packages missing available elsewhere, > so people, interested in helping, could choose what to pack. http://fedoraproject.org/wiki/Package_maintainers_wishlist Rahul From bochecha at fedoraproject.org Thu Jun 4 13:35:52 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Thu, 4 Jun 2009 15:35:52 +0200 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> <4A2770CB.8090708@freenet.de> Message-ID: <2d319b780906040635s598ceae0oa3294f12db80a0c2@mail.gmail.com> >> You are still presuming your users to be interested in developing and >> working on your package. >> >> This simply does not apply - They want to use your package. > > I see 2 possibilities: > * either the user wants his/her bug fixed, in that case he/she is > responsible for reporting it to the appropriate place, > * or the user does not care about having the bug fixed, that's fine with me, > we can just close it, less work for me. ;-) If somebody actually cares, > he/she'll report it upstream. If nobody cares, why bother fixing it? And why can't this "somebody" be the package maintainer ? I mean, a package maintainer should care about the software he packages, otherwise, why is he packaging it ? :-/ ---------- Mathieu Bridon (bochecha) From promac at gmail.com Thu Jun 4 13:37:51 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Thu, 4 Jun 2009 10:37:51 -0300 Subject: Orphaning Packages: audacious and dependencies In-Reply-To: <20090604144853.144f43cf@faldor.intranet> References: <20090603184627.4297a25b@lain.camperquake.de> <20090604144853.144f43cf@faldor.intranet> Message-ID: <68720af30906040637m4d1ed1b9ha8c75f91551b5cbc@mail.gmail.com> On Thu, Jun 4, 2009 at 9:48 AM, Michael Schwendt wrote: > On Wed, 3 Jun 2009 18:46:27 +0200, Ralf wrote: > > > Hi. > > > > As I don't have the time to maintain audacious any more I'm orphaning the > > following packages: > > > > audacious > > audacious-plugins > > libmowgli > > mcs > > > > The last two are dependencies which, as far as I am aware, are used by > > nothing else. > > "conky" and "kadu-audacious_mediaplayer" depend on libmowgli and libmcs. > > I have the .src.rprm for audacious2, here: http://orion.lcg.ufrj.br/RPMS/src/repoview/audacious.html http://orion.lcg.ufrj.br/RPMS/src/repoview/audacious-plugins.html But it builds everything, and I just created an audacious-libs2, so I do not need to recompile the applications I have, using libaudclient.so.1, for now. I also do not want to maintain it, because it needs external packages to provide some codecs not allowed in Fedora. -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From promac at gmail.com Thu Jun 4 13:42:35 2009 From: promac at gmail.com (Paulo Cavalcanti) Date: Thu, 4 Jun 2009 10:42:35 -0300 Subject: Question about web applications In-Reply-To: <4A27CC3C.3010305@jcomserv.net> References: <68720af30906040323n1856ae79h24eabaf2677015ae@mail.gmail.com> <68720af30906040433i404c9den56658088cf668676@mail.gmail.com> <4A27BDEC.4000202@jcomserv.net> <68720af30906040627s4b1a46ecic81b2cc087e0a536@mail.gmail.com> <4A27CC3C.3010305@jcomserv.net> Message-ID: <68720af30906040642v21a5e0bbqf3d939d02ed385b5@mail.gmail.com> On Thu, Jun 4, 2009 at 10:29 AM, Jon Ciesla wrote: > Paulo Cavalcanti wrote: > > > > On Thu, Jun 4, 2009 at 9:28 AM, Jon Ciesla wrote: > >> David Nalley wrote: >> >>> On Thu, Jun 4, 2009 at 7:33 AM, Paulo Cavalcanti >>> wrote: >>> >>> >>>> On Thu, Jun 4, 2009 at 8:00 AM, David Nalley wrote: >>>> >>>> >>>>> On Thu, Jun 4, 2009 at 6:23 AM, Paulo Cavalcanti >>>>> wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I submitted ampache (http://ampache.org/) for review, but I was told >>>>>> that it >>>>>> could not use any external software >>>>>> bundled in the code. In fact, it uses getid3, a file that seems to >>>>>> come >>>>>> from >>>>>> horde (horde/Browser.php), >>>>>> and some others. >>>>>> >>>>>> According to the weekpedia (http://en.wikipedia.org/wiki/Ampache) >>>>>> >>>>>> "Ampache has been featured in numerous online blogs and technical >>>>>> articles. >>>>>> One of the more notable was the O'Reilly book Spidering Hacks which >>>>>> tested >>>>>> the security of online applications. Ampache was found to be immune to >>>>>> standard spidering hacks as described in the O'Reilly article, and it >>>>>> has >>>>>> continued that trend by focusing on security during its development. >>>>>> The >>>>>> Code Philosophy listed on Ampache's wiki specifically lists security >>>>>> as >>>>>> one >>>>>> of those most important considerations during application >>>>>> development." >>>>>> >>>>>> Does it make any sense to fiddle something that has always had >>>>>> security >>>>>> as a >>>>>> prime concern? >>>>>> >>>>>> Any comment is welcome. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> -- >>>>>> Paulo Roma Cavalcanti >>>>>> LCG - UFRJ >>>>>> >>>>>> -- >>>>>> fedora-devel-list mailing list >>>>>> fedora-devel-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>>>>> >>>>>> >>>>>> >>>>> Perhaps I am the least well suited to respond as I did some of the >>>>> initial review. >>>>> >>>>> >>>> No, on the contrary. >>>> >>>> >>>> >>>>> However, there are at least 10 bundled libraries with ampache, >>>>> including pear-XML_RPC, nusoap, getid3, small snippets from Horde, >>>>> captchaphp, php-Snoopy, etc. >>>>> >>>>> In addition to the security benefits, creating the separate package >>>>> means other packages (even other web apps) can make use of the >>>>> libraries that would be available in Fedora instead of just ampache. >>>>> I can empathize with the extra work that this causes, as I am trying >>>>> to fix a few of these problems with another web app. >>>>> >>>>> >>>>> >>>> Maybe we can list all of the packages we would like to have for web >>>> applications, and try to set a "task force" to cope with them? >>>> >>>> I think if we had three or four people willing to help, the work would >>>> be >>>> concluded fast. There are always people looking forward to contributing, >>>> but without a good package to work with. >>>> >>>> >>>> >>> >>> >>> I think that's an outstanding idea, and I'd be willing to work towards >>> such an end, and perhaps since there is such a prevalence of php we >>> can get some buy-in from the php-sig as well. To illustrate some of >>> the usefulness - I have a web app I am working on now that uses >>> php-Snoopy as ampache also does, so that's at least two applications >>> that can make use of the package. >>> >>> >>> >> Count me in. I maintain several PHP apps, and having gone through the >> nightmare of switching from bundled to system libraries, I wholeheartedly >> agree that using system libraries from the beginning is the best way to go. >> Using the system lib means that security fixes are done in one place for >> all apps, and we don't have to patch the apps, or wait for upstream to push >> an update with an updated bundled lib. >> >> I'll help review, etc. >> >> > Thank you Jon. I will start with getid3. > > It would be nice if we had a list of packages missing available elsewhere, > so people, interested in helping, could choose what to pack. > > > -- > Paulo Roma Cavalcanti > LCG - UFRJ > > You mean like a subcategory of > http://fedoraproject.org/wiki/PackageMaintainers/WishList ? > Yes, a more specific entry, such as web applications? -- Paulo Roma Cavalcanti LCG - UFRJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Thu Jun 4 13:43:06 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 15:43:06 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031047.26436.jreznik@redhat.com> <4A26662A.9010802@freenet.de> <4A2772DB.4040601@freenet.de> Message-ID: Ralf Corsepius wrote: > Me thinks, your are just being lazy and are trying to rudely push around > Fedora's user base. "customer-friendliness" is something entirely > different from your attitude. Fedora's "customers" aren't paying us anything, so they can't expect to get the equivalent of paid support. We're doing what we can to help people. But expecting unpaid volunteers to relieve the user of even the slightest chore when he/she can easily do it him/herself and to spend his/her volunteer time playing proxy between user and upstream is quite rude. The users are getting something for free, it's not their right to complain about the gift horse saying they wanted a pony instead. Kevin Kofler From tcallawa at redhat.com Thu Jun 4 13:48:14 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 04 Jun 2009 09:48:14 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <20090603234851.GF2650@angus.ind.WPI.EDU> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <1243896345.29188.43.camel@localhost.localdomain> <4A2459F3.8040300@redhat.com> <20090603234851.GF2650@angus.ind.WPI.EDU> Message-ID: <4A27D09E.1040907@redhat.com> On 06/03/2009 07:48 PM, Chuck Anderson wrote: > Not necessarily. I don't see why the Fedora Project couldn't qualify > as a Sponsored Participant on Internet2 [1]. In fact, Red Hat is > already connected in Raleigh. I think this is because they're technically on NC State University. ~spot From kevin.kofler at chello.at Thu Jun 4 13:50:38 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 15:50:38 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031047.26436.jreznik@redhat.com> <4A26662A.9010802@freenet.de> Message-ID: Matej Cepl wrote: > I am quite surprised to totally agree with you this time ;-), and I am > even more surprised to finally a situation where actually technology > could help to resolve interpersonal problems, but I think if somebody > skilled in programming Perl (hint, hint) would work on https:// > bugzilla.redhat.com/show_bug.cgi?id=189813 (and its upstream > counterparts), situation of our reporters COULD improve. If that got implemented, that would indeed make this whole discussion moot. I agree it'd be great, I just don't see it happening soon. A big issue is how upstream would validate the e-mail addresses we're entering in the CC list if we forward our bug (including CC) into their Bugzilla instance. Kevin Kofler From opensource at till.name Thu Jun 4 13:51:04 2009 From: opensource at till.name (Till Maas) Date: Thu, 04 Jun 2009 15:51:04 +0200 Subject: Client-side certificate generation error In-Reply-To: <29fee02b0906040611y6e67bdd0o423c3fc438489a0@mail.gmail.com> References: <29fee02b0906040611y6e67bdd0o423c3fc438489a0@mail.gmail.com> Message-ID: <200906041551.15601.opensource@till.name> On Thu June 4 2009, Andrea Musuruane wrote: > my client-side certificate is expired. I tried to generate a new > one on the Fedora Account System, but I get an error saying "Your > certificate could not be generated.". Not very helpful as an error > message. I do not know what should I do. Can someone help? The fedora infrastructure team can help, just open a ticket here: https://fedorahosted.org/fedora-infrastructure Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Thu Jun 4 13:56:05 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 15:56:05 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906030843.26442.sgrubb@redhat.com> <1244064907.2937.346.camel@adam.local.net> Message-ID: Adam Williamson wrote: > There's an obvious answer to this question: we track the importance of > issues to Fedora via the Fedora bug tracker, not via upstream bug > trackers. There's no way I can mark a bug in the KDE bug tracker as > blocking the release of Fedora 12. If the bug is important enough to block one of our trackers, we won't close it UPSTREAM, we'll even try to fix it on our own (and then upstream our fix) if upstream doesn't come up with a fix soon enough. But we can't reserve that treatment to every single KDE bug, there are too many! Kevin Kofler From musuruan at gmail.com Thu Jun 4 13:55:30 2009 From: musuruan at gmail.com (Andrea Musuruane) Date: Thu, 4 Jun 2009 15:55:30 +0200 Subject: Client-side certificate generation error In-Reply-To: <200906041551.15601.opensource@till.name> References: <29fee02b0906040611y6e67bdd0o423c3fc438489a0@mail.gmail.com> <200906041551.15601.opensource@till.name> Message-ID: <29fee02b0906040655y144cb78dr1245bd35dc80b12@mail.gmail.com> On Thu, Jun 4, 2009 at 3:51 PM, Till Maas wrote: > On Thu June 4 2009, Andrea Musuruane wrote: > >> ? ? my client-side certificate is expired. I tried to generate a new >> one on the Fedora Account System, but I get an error saying "Your >> certificate could not be generated.". Not very helpful as an error >> message. I do not know what should I do. Can someone help? > > The fedora infrastructure team can help, just open a ticket here: > https://fedorahosted.org/fedora-infrastructure Thanks. I'm doing it right now. Bye, Andrea. From bernie at codewiz.org Thu Jun 4 13:57:05 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Thu, 04 Jun 2009 15:57:05 +0200 Subject: Unbootable machine In-Reply-To: <4A24B44D.3070607@zytor.com> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> <4A247506.4000304@codewiz.org> <4A2483C8.7090706@zytor.com> <4A249C12.2060708@codewiz.org> <4A24B44D.3070607@zytor.com> Message-ID: <4A27D2B1.9070203@codewiz.org> On 06/02/09 07:10, H. Peter Anvin wrote: > Bernie Innocenti wrote: >> On 06/02/09 03:43, H. Peter Anvin wrote: >>> Bernie Innocenti wrote: >>>> Disk /dev/sdb: 2055 MB, 2055208960 bytes >>>> 221 heads, 2 sectors/track, 9081 cylinders >>> I don't know where fdisk, the Linux kernel, or whatever come up with >>> these kinds of geometries. They're almost universally non-bootable. >> >> Ok, I wiped mbr and made fdisk create a new one: >> >> Disk /dev/sdb: 2055 MB, 2055208960 bytes >> 64 heads, 62 sectors/track, 1011 cylinders > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Equally weird. The only "standard" ones are 64 heads, 32 sectors and > 255 heads, 63 sectors. Indeed, repartitioning the USB stick with 32 sectors and 255 heads fixed boot for a previously unbootable computer. Thanks, Peter. I think we should document this tip in the Sugar on a Stick wiki page and perhaps change the Fedora livecd-iso-to-disk script to create the MBR with parted rather than fdisk. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From kevin.kofler at chello.at Thu Jun 4 13:59:04 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 15:59:04 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906040940.16503.mhlavink@redhat.com> Message-ID: Michal Hlavinka wrote: > What if upstream answers: ok, thanks for bug report, please try this > patch... or I've fixed it in repo, please try svn snapshot, if it's fixed > for you? In that case we can roll a fixed package (e.g. as a scratch build). (If upstream says "try a current snapshot, it should be fixed", I'll usually try to find the actual commit and, if I don't find it, ask "can you please point me to the commit that fixed it so we can backport it?". But for some packages, just upgrading to the newer snapshot is the better solution.) But until that happens, there's no reason for the packager to be involved. Kevin Kofler From frankly3d at gmail.com Thu Jun 4 14:07:01 2009 From: frankly3d at gmail.com (Frank Murphy (Frankly3d)) Date: Thu, 04 Jun 2009 15:07:01 +0100 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <200906031047.26436.jreznik@redhat.com> <4A26662A.9010802@freenet.de> <4A2772DB.4040601@freenet.de> Message-ID: <4A27D505.109@gmail.com> Kevin Kofler wrote: > Ralf Corsepius wrote: >> Me thinks, your are just being lazy and are trying to rudely push around >> Fedora's user base. "customer-friendliness" is something entirely >> different from your attitude. > > Fedora's "customers" aren't paying us anything, That's the way it was\is setup. so they can't expect to get > the equivalent of paid support. We're doing what we can to help people. +1 But > expecting unpaid volunteers to relieve the user of even the slightest chore > when he/she can easily do it him/herself and to spend his/her volunteer > time playing proxy between user and upstream is quite rude. The users are > getting something for free, it's not their right to complain about the gift > horse saying they wanted a pony instead. But they are entitled to know the horse can walk. Who wants a lame horse paid for or not. However as I studied Customer Affairs, I will chime in. People aka users, can be thick. But paid or not, it is not the Packagers place to tell them so. One Disgruntled Customer\User\Person, is bad publicity. Especially if the Project wants users to both *Use and test* the Offerings. What may be worth looking into, is an expanded version of the Anaconda reported. Whereby if a bug happens, a window will pop up encouraging user to report bug's. If necessary at that point sign user up to bugzilla Packageer\Maintainer will determine if Fedora Problem\ with Project help if necessary. If upstream problem, ask reporter if they are *OK*, with bug going upstream, and have a generic helpful text ready to help them. Which could be C&P into bug comment. Frank From jreiser at BitWagon.com Thu Jun 4 14:07:54 2009 From: jreiser at BitWagon.com (John Reiser) Date: Thu, 04 Jun 2009 07:07:54 -0700 Subject: Unbootable machine In-Reply-To: <4A24B44D.3070607@zytor.com> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> <4A247506.4000304@codewiz.org> <4A2483C8.7090706@zytor.com> <4A249C12.2060708@codewiz.org> <4A24B44D.3070607@zytor.com> Message-ID: <4A27D53A.8010006@BitWagon.com> H. Peter Anvin wrote: > Bernie Innocenti wrote: >> On 06/02/09 03:43, H. Peter Anvin wrote: >>> Bernie Innocenti wrote: >>>> Disk /dev/sdb: 2055 MB, 2055208960 bytes >>>> 221 heads, 2 sectors/track, 9081 cylinders >>> I don't know where fdisk, the Linux kernel, or whatever come up with >>> these kinds of geometries. They're almost universally non-bootable. >> Ok, I wiped mbr and made fdisk create a new one: >> >> Disk /dev/sdb: 2055 MB, 2055208960 bytes >> 64 heads, 62 sectors/track, 1011 cylinders > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Equally weird. The only "standard" ones are 64 heads, 32 sectors and > 255 heads, 63 sectors. Depends on your definition of "standard". Anything with {1 <= heads <= 255, 1 <= sectors <= 63, 1 <= cylinders <= 1023} meets the requirements of many BIOS that I have encountered. In particular, I have seen sectors/track of 2, 4, 28, 31, 32, 33, 47, 48, 60, 61, 62, 63, 128, 255 on booting drives within the last two years. Picking one of my USB 2.0 flash drives, I find a Fujifilm 256 MB instance with 128 heads, 4 sectors/track, 975 cylinders -- From kevin.kofler at chello.at Thu Jun 4 14:09:29 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 16:09:29 +0200 Subject: Packager = Programmer? References: <4A277B2A.5010808@gmail.com> Message-ID: Frank Murphy (Frankly3d) wrote: > Does trying to become a packager. > Involve being currently a Developer, > as in Programming skills\certification, > whether Perl\Python\c++ etc. And to answer that part, you don't need any sort of certification to become a Fedora packager, you just need to write one or more specfile(s) which follow(s) our guidelines. Kevin Kofler From rawhide at fedoraproject.org Thu Jun 4 14:27:25 2009 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 4 Jun 2009 14:27:25 +0000 (UTC) Subject: rawhide report: 20090604 changes Message-ID: <20090604142725.595FA1F8218@releng2.fedora.phx.redhat.com> Compose started at Thu Jun 4 06:15:04 UTC 2009 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for ppc64 ---------------------------------------------------------- cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7 From nils at redhat.com Thu Jun 4 14:51:20 2009 From: nils at redhat.com (Nils Philippsen) Date: Thu, 04 Jun 2009 16:51:20 +0200 Subject: Maintainer Responsibilities In-Reply-To: <4A276F8C.7030608@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <200906032238.41501.cemeyer@u.washington.edu> <4A276C6A.2080503@freenet.de> <200906032345.32306.cemeyer@u.washington.edu> <4A276F8C.7030608@freenet.de> Message-ID: <1244127080.5171.92.camel@gibraltar.str.redhat.com> On Thu, 2009-06-04 at 08:54 +0200, Ralf Corsepius wrote: > Conrad Meyer wrote: > > On Wednesday 03 June 2009 11:40:42 pm Ralf Corsepius wrote: > >> Conrad Meyer wrote: > >>> On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: > >>>> Let me try an analogy: How do you handle defects/malfunctions with your > >>>> car? > >>> Did a bunch of hobbyists from around the world build your car by > >>> communicating over the internet? > >> Have you ever seen an open source car? > >> > >> The Fedora "car" manufacturer is the "fedora community", assembling it > >> from "upstream" components. > >> > >> Ralf > > > > That's the idea, opensource behaves completely different from a car > > manufacturer. > Wrong. It doesn't. I don't think we have the power to (nor would we want to) force upstream to do certain things in a certain way, for ridiculously low prices and "no we won't pay you on delivery" but 3 months later. The relationship between us and upstream is significantly different from a car manufacturer and its suppliers. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From skvidal at fedoraproject.org Thu Jun 4 14:56:34 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 4 Jun 2009 10:56:34 -0400 (EDT) Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <4A27D09E.1040907@redhat.com> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <1243896345.29188.43.camel@localhost.localdomain> <4A2459F3.8040300@redhat.com> <20090603234851.GF2650@angus.ind.WPI.EDU> <4A27D09E.1040907@redhat.com> Message-ID: On Thu, 4 Jun 2009, Tom \"spot\" Callaway wrote: > On 06/03/2009 07:48 PM, Chuck Anderson wrote: >> Not necessarily. I don't see why the Fedora Project couldn't qualify >> as a Sponsored Participant on Internet2 [1]. In fact, Red Hat is >> already connected in Raleigh. > > I think this is because they're technically on NC State University. > and last time I checked it's a 100mbit connection to i2. -sv From mhlavink at redhat.com Thu Jun 4 15:00:05 2009 From: mhlavink at redhat.com (Michal Hlavinka) Date: Thu, 4 Jun 2009 17:00:05 +0200 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <200906040940.16503.mhlavink@redhat.com> Message-ID: <200906041700.06098.mhlavink@redhat.com> > > What if upstream answers: ok, thanks for bug report, please try this > > patch... or I've fixed it in repo, please try svn snapshot, if it's > > fixed for you? > > In that case we can roll a fixed package (e.g. as a scratch build). (If > upstream says "try a current snapshot, it should be fixed", I'll usually > try to find the actual commit and, if I don't find it, ask "can you please > point me to the commit that fixed it so we can backport it?". But for some > packages, just upgrading to the newer snapshot is the better solution.) But > until that happens, there's no reason for the packager to be involved. Yes, but how will you notice reporter needs (your) help if bug is closed upstream? From cra at WPI.EDU Thu Jun 4 15:12:17 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 4 Jun 2009 11:12:17 -0400 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <20090601200304.GF3583@localhost.localdomain> <20090601222217.GA31066@auslistsprd01.us.dell.com> <1243896345.29188.43.camel@localhost.localdomain> <4A2459F3.8040300@redhat.com> <20090603234851.GF2650@angus.ind.WPI.EDU> <4A27D09E.1040907@redhat.com> Message-ID: <20090604151217.GQ22133@angus.ind.WPI.EDU> On Thu, Jun 04, 2009 at 10:56:34AM -0400, Seth Vidal wrote: > > > On Thu, 4 Jun 2009, Tom \"spot\" Callaway wrote: > >> On 06/03/2009 07:48 PM, Chuck Anderson wrote: >>> Not necessarily. I don't see why the Fedora Project couldn't qualify >>> as a Sponsored Participant on Internet2 [1]. In fact, Red Hat is >>> already connected in Raleigh. >> >> I think this is because they're technically on NC State University. >> > > and last time I checked it's a 100mbit connection to i2. Well, they are listed as "Red Hat" on the Internet2 map. Time to upgrade to Gig :-) From rc040203 at freenet.de Thu Jun 4 15:23:16 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 04 Jun 2009 17:23:16 +0200 Subject: Maintainer Responsibilities In-Reply-To: <1244127080.5171.92.camel@gibraltar.str.redhat.com> References: <200906021617.12122.sgrubb@redhat.com> <200906032238.41501.cemeyer@u.washington.edu> <4A276C6A.2080503@freenet.de> <200906032345.32306.cemeyer@u.washington.edu> <4A276F8C.7030608@freenet.de> <1244127080.5171.92.camel@gibraltar.str.redhat.com> Message-ID: <4A27E6E4.5010604@freenet.de> Nils Philippsen wrote: > On Thu, 2009-06-04 at 08:54 +0200, Ralf Corsepius wrote: >> Conrad Meyer wrote: >>> On Wednesday 03 June 2009 11:40:42 pm Ralf Corsepius wrote: >>>> Conrad Meyer wrote: >>>>> On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: >>>>>> Let me try an analogy: How do you handle defects/malfunctions with your >>>>>> car? >>>>> Did a bunch of hobbyists from around the world build your car by >>>>> communicating over the internet? >>>> Have you ever seen an open source car? >>>> >>>> The Fedora "car" manufacturer is the "fedora community", assembling it >>>> from "upstream" components. >>>> >>>> Ralf >>> That's the idea, opensource behaves completely different from a car >>> manufacturer. >> Wrong. It doesn't. > > I don't think we have the power to (nor would we want to) force upstream > to do certain things in a certain way, for ridiculously low prices and > "no we won't pay you on delivery" but 3 months later. The relationship > between us and upstream is significantly different from a car > manufacturer and its suppliers. I am talking about "customer"<->"manufacturer" and "manufacturer"<->"component supplier" relations. Wrt. this the relations are not any different: * manufacturer buys parts at supplier. ... Fedora "buys-in parts from upstreams". * in case of problems. customer contacts "point of sale" (garage/car dealer), point of sale processes request ... Fedora users contact Fedora/RH BZ, ... What Kevin proposes is equal to demanding car drivers to a) First identify the defective component b) Then to identify and contact the component's supplier This procedure is ridiculous. Ralf From kevin.kofler at chello.at Thu Jun 4 15:29:08 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 17:29:08 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906040940.16503.mhlavink@redhat.com> <200906041700.06098.mhlavink@redhat.com> Message-ID: Michal Hlavinka wrote: > Yes, but how will you notice reporter needs (your) help if bug is closed > upstream? By CCing ourselves on the upstream bug when we close ours. Kevin Kofler From rdieter at math.unl.edu Thu Jun 4 15:46:40 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 04 Jun 2009 10:46:40 -0500 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <4A2770CB.8090708@freenet.de> <200906040935.45912.jreznik@redhat.com> <1244106116.6276.11.camel@worm> Message-ID: Tim Waugh wrote: > My own opinion is that the package maintainer is responsible for > reporting bugs upstream when they are able to reproduce them. +1, for the most part, but distributing the load (to users, triagers, whatever) for doing so isn't wrong either, imo. Unreproducible bugs are where the "fun" begins. -- Rex From mefoster at gmail.com Thu Jun 4 15:47:32 2009 From: mefoster at gmail.com (Mary Ellen Foster) Date: Thu, 4 Jun 2009 16:47:32 +0100 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <200906040940.16503.mhlavink@redhat.com> <200906041700.06098.mhlavink@redhat.com> Message-ID: 2009/6/4 Kevin Kofler : > Michal Hlavinka wrote: >> Yes, but how will you notice reporter needs (your) help if bug is closed >> upstream? > > By CCing ourselves on the upstream bug when we close ours. > > ? ? ? ?Kevin Kofler Speaking as a semi-frequent reporter of Fedora KDE bugs, I can say that the process works pretty well for me. Of course, I'm probably somewhat more engaged in the process than average (e.g., I maintain a few packages myself, and I've had an account at bugs.kde.org for years). I do occasionally wish that I didn't have to do the upstream report myself, but I can see the reasons for it. MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ ICCS, School of Informatics, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From pasik at iki.fi Thu Jun 4 16:13:54 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Thu, 4 Jun 2009 19:13:54 +0300 Subject: F11: kernel/boot hangs after creating initial device nodes, when plymouthd is started In-Reply-To: <20090603111411.GE24960@edu.joroinen.fi> References: <20090601051548.GW24960@edu.joroinen.fi> <20090603111411.GE24960@edu.joroinen.fi> Message-ID: <20090604161354.GN24960@edu.joroinen.fi> On Wed, Jun 03, 2009 at 02:14:11PM +0300, Pasi K?rkk?inen wrote: > On Mon, Jun 01, 2009 at 08:15:48AM +0300, Pasi K?rkk?inen wrote: > > Hello. > > > > Yesterday I installed latest F11/rawhide. The default installed kernel > > (2.6.29 something) works fine. > > > > I compiled custom 2.6.30-rc6 kernel, and created initrd for it, and tried > > booting it. > > > > Booting process gets stuck at "creating initial device nodes". > > > > Any ideas? I assume that's during initrd execution.. > > Something missing from my kernel config? > > > > Any tips would be appreciated. > > Has anyone else seen this problem? > I edited the initrd image, and added some debug echos. The command that hangs the initrd execution is this: daemonize --ignore-missing /bin/plymouthd Any ideas? -- Pasi From paul at city-fan.org Thu Jun 4 16:27:42 2009 From: paul at city-fan.org (Paul Howarth) Date: Thu, 04 Jun 2009 17:27:42 +0100 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <200906040940.16503.mhlavink@redhat.com> <200906041700.06098.mhlavink@redhat.com> Message-ID: <4A27F5FE.6090305@city-fan.org> Mary Ellen Foster wrote: > 2009/6/4 Kevin Kofler : >> Michal Hlavinka wrote: >>> Yes, but how will you notice reporter needs (your) help if bug is closed >>> upstream? >> By CCing ourselves on the upstream bug when we close ours. >> >> Kevin Kofler > > Speaking as a semi-frequent reporter of Fedora KDE bugs, I can say > that the process works pretty well for me. Of course, I'm probably > somewhat more engaged in the process than average (e.g., I maintain a > few packages myself, and I've had an account at bugs.kde.org for > years). I do occasionally wish that I didn't have to do the upstream > report myself, but I can see the reasons for it. I'll happily raise upstream bugs myself but it irks me when maintainers close Fedora bugs with the UPSTREAM resolution without actually taking the upstream fix and bringing it into Fedora. If I've reported a bug in Fedora bugzilla it's because the bug is present in Fedora and I'd like to see it fixed *in Fedora*. So seeing a bug closed UPSTREAM doesn't help at all if I have a real problem with a Fedora package. Paul. From jspaleta at gmail.com Thu Jun 4 16:32:50 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 4 Jun 2009 08:32:50 -0800 Subject: Packager = Programmer? In-Reply-To: <4A277B2A.5010808@gmail.com> References: <4A277B2A.5010808@gmail.com> Message-ID: <604aa7910906040932w7952f65fmc728e612ab392245@mail.gmail.com> On Wed, Jun 3, 2009 at 11:43 PM, Frank Murphy (Frankly3d) wrote: > Does trying to become a packager. > Involve being currently a Developer, > as in Programming skills\certification, > whether Perl\Python\c++ etc. I would put it this way.... there should be an expectation that packagers are willing to learn programming skills relevant to the packages they are maintaining. There's no proficiency level or anything like that. But if you aren't interested in learning how to read and use python..you should probably not maintain a package that is heavily dependent on python. Those are the sort of personal choices that can turn the time you gift as a volunteer contribution to Fedora into a burden instead of having fun doing the work. I personally do not maintain package for things that are written in languages I'm not interested in learning how to use. I avoid perl. I avoid java. I generally have no personal interest in developing or refining my ability to read or use either(but it seems like I won't be able to avoid the java trap for long as part of my day job). And as a result I don't try to maintain packages for either. I wish I knew how to organize some optional program language specific skills development sessions aimed at packagers that made sense..but I don't. Nothing like a cert or anything like that, but to introduce packagers and potential packagers to languages just as a good skills building exercise. -jef From rc040203 at freenet.de Thu Jun 4 16:37:34 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 04 Jun 2009 18:37:34 +0200 Subject: Maintainer Responsibilities In-Reply-To: <20090604070028.GB3712@verda-stelo.englab.brq.redhat.com> References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> <200906031137.19294.smparrish@gmail.com> <4A275A39.4070601@freenet.de> <20090604070028.GB3712@verda-stelo.englab.brq.redhat.com> Message-ID: <4A27F84E.4060501@freenet.de> David Tardon wrote: > On Thu, Jun 04, 2009 at 07:23:05AM +0200, Ralf Corsepius wrote: >> Steven M. Parrish wrote: >> >>> Many people have mentioned that it is not right to ask the users to >>> file their bug reports upstream. I ask why not? >> Let me summarize what I already wrote elsewhere in this thread: >> * Users aren't necessarily developers. >> * Users aren't necessarily interested in getting involved upstream. >> * Users are reporting bugs against your product (your package in >> Fedora), not against upstream's work (somebody else's product). >> >> >> Let me try an analogy: How do you handle defects/malfunctions with your >> car? >> >> You'll visit your car dealer/a garage and report the issue to them. >> You'll expect them to identify the problem and to take appropriate steps >> to solve your issue. > > Let me try another analogy: How do you handle health problems? > > You'll visit your doctor. You'll expect him to identify the problem and > to take appropriate steps to solve your issue--that may well be just him > sending you to a specialist. Correct. > Would you expect your doctor to serve as a > proxy between you and the specialist? Or even substitute you for > checkup? I wouldn't. Of course, but in this case "the human" am "the product", which need to go through the "bug fixing process". >> You don't expect them to direct you to the car's >> manufacturer or a component manufacturer and to discuss technical >> details you have no knowledge about with them ("Is the stuttering engine >> cause by triac 7 in a component A you haven't heard about before" or by >> the hall sensor in component B you also haven't heard about before). >> > > Who spoke about technical details? I do, because analyzing bugs often requires a deep understanding of a package's infrastructure/details/etc.. You can't expect end-users to be able to have this understanding (nor to be interested in them), but you can expect a Fedora packager to have it and to act as relay. > Have you ever been asked to look into > the source code of some project? I don't think so. Oh, many times ... > An upstream developer > can ask better/more detailed questions than a packager, but that's only > to be expected. Theoretically, yes ... in practice ... not always. > Btw, I'm really interested to hear why answering questions of an > upstream developer through a packager as a proxy is better than > answering the same questions directly... I never said this - Upstreams contacting reporters, with a package maintainer acting as proxy is an option. Demanding end-users to get involved into upstreams and rendering Fedora packagers into "stupid packaging robots", like Kevin's proposal implies, is simply absurd. Ralf From a.badger at gmail.com Thu Jun 4 16:44:50 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Jun 2009 09:44:50 -0700 Subject: Maintainer Responsibilities In-Reply-To: <1244106116.6276.11.camel@worm> References: <200906021617.12122.sgrubb@redhat.com> <4A2770CB.8090708@freenet.de> <200906040935.45912.jreznik@redhat.com> <1244106116.6276.11.camel@worm> Message-ID: <4A27FA02.8010902@gmail.com> On 06/04/2009 02:01 AM, Tim Waugh wrote: > My own opinion is that the package maintainer is responsible for > reporting bugs upstream when they are able to reproduce them. > > One reason for my belief is that I've seen the situation from the other > side: as an upstream maintainer for a package, getting bug reports > directly from users of a packaged version in another operating system. > > It can be a frustrating experience because the person reporting the bug > can never be quite sure which version they are using (due to additional > patches used in packaging), and generally are not able to try out > suggested patches or pull from a source code repository. > > My point is that it isn't only the people reporting bugs that get > frustrated by "go report it upstream", it is also the larger free > software community. +1 For an upstream taking in bugs, a package maintainer reporting bugs is usually a much better resource than a random user. Random users disappear. They switch software to escape bugs. They switch distros. They report a bug that they encounter once but don't have the persistence to write down the exact steps that they used to create it. Good package maintainers do. It's much easier to collaboratively fix issues with a package maintainer because the package maintainer has invested time in getting the package into their distribution and wants the software to be bug-free as much as upstream. The end user is more fickle. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From bochecha at fedoraproject.org Thu Jun 4 16:48:05 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Thu, 4 Jun 2009 18:48:05 +0200 Subject: Packager = Programmer? In-Reply-To: <604aa7910906040932w7952f65fmc728e612ab392245@mail.gmail.com> References: <4A277B2A.5010808@gmail.com> <604aa7910906040932w7952f65fmc728e612ab392245@mail.gmail.com> Message-ID: <2d319b780906040948r24ef7001gdc73e5aefc625950@mail.gmail.com> > I wish I knew how to organize some optional program language specific > skills development sessions aimed at packagers that made sense..but I > don't. ?Nothing like a cert or anything like that, but to introduce > packagers and potential packagers to languages just as a good skills > building exercise. More than learning development skills for the language you package, it would be great to introduce stuff like how software is build / installed. I'd love to learn how autotools, setuptools, and other equivalents for other languages work. Not necessarily because I want to build a project using those, but because I sometimes have a hard time figuring out how to patch a Makefile in one of my packages, why I should patch a .in or .am file,... Actually, those would be great ideas for Fedora Classrooms I guess. ---------- Mathieu Bridon (bochecha) From sundaram at fedoraproject.org Thu Jun 4 16:54:03 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 04 Jun 2009 22:24:03 +0530 Subject: Packager = Programmer? In-Reply-To: <2d319b780906040948r24ef7001gdc73e5aefc625950@mail.gmail.com> References: <4A277B2A.5010808@gmail.com> <604aa7910906040932w7952f65fmc728e612ab392245@mail.gmail.com> <2d319b780906040948r24ef7001gdc73e5aefc625950@mail.gmail.com> Message-ID: <4A27FC2B.1090903@fedoraproject.org> On 06/04/2009 10:18 PM, Mathieu Bridon (bochecha) wrote: > I'd love to learn how autotools, setuptools, and other equivalents for > other languages work. Not necessarily because I want to build a > project using those, but because I sometimes have a hard time figuring > out how to patch a Makefile in one of my packages, why I should patch > a .in or .am file,... > > Actually, those would be great ideas for Fedora Classrooms I guess. Yes, that would be great. People who are experts in such things (I know we have a good number of those) should step up and participate in the Fedora Classroom sessions or help document it in a way relevant to package maintainers. Rahul From a.badger at gmail.com Thu Jun 4 16:59:31 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Jun 2009 09:59:31 -0700 Subject: Packager = Programmer? In-Reply-To: <4A27B66E.5080703@redhat.com> References: <4A277B2A.5010808@gmail.com> <4A277C56.4080805@fedoraproject.org> <4A27B66E.5080703@redhat.com> Message-ID: <4A27FD73.2000901@gmail.com> On 06/04/2009 04:56 AM, Bryan Kearney wrote: > Rahul Sundaram wrote: >> On 06/04/2009 01:13 PM, Frank Murphy (Frankly3d) wrote: >>> Does trying to become a packager. >>> Involve being currently a Developer, >>> as in Programming skills\certification, >>> whether Perl\Python\c++ etc. >> >> Not necessarily. It's useful to understand the codebase but if you have >> a active upstream responsive to bug reports, you can just take care of >> the packaging aspects of it. You can always ask for help from others >> within Fedora or upstream if needed. >> >> Rahul >> > I would content you need an ability to understand scripting languages > (as spec files are really a DSL/scripting language) and an understanding > of skills commonly associated with a developer: > > - Source Code Control > - Source Layout > - Software Component Types (e.g. scripts, libraries, documents, etc). > > however, as Rahul said, the ability to crank out the latest > oCaml/Erlang/Java/C/Assembler/NameYourPoison is not required. > Going even further, understanding diff and patch and tools used to build software (make/autotools/CMake/ant/maven/distutils/etc) work is probably of more importance to a packager than being able to program in C/Python/Java/etc. Knowing the basics of programming will help you tremendously but there's other people upstream and within Fedora that can do that work for you if it becomes necessary. Knowing the basics of the build tools your package uses are needed for even the most trivial deviations from what upstream provides (and in some cases, you may understand this aspect of programming better than upstream). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Thu Jun 4 17:03:46 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 04 Jun 2009 19:03:46 +0200 Subject: Maintainer Responsibilities In-Reply-To: <200906040935.45912.jreznik@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> <4A2770CB.8090708@freenet.de> <200906040935.45912.jreznik@redhat.com> Message-ID: <4A27FE72.4020703@freenet.de> Jaroslav Reznik wrote: > You can ask our users if they are satisfied or not. From comments and posts I > think they ARE! It's the nature of bugs that they often only affect a minority ("power users", "corner cases"). If they are affecting the majority of users, they are likely to be caught early and thus not to be "exposed to the wild". > Check our fedora-kde list, IRC channel #fedora-kde as most of > bugs are solved there even before they hit BZ... Well, I only have to look into my fc11 test system's /var/log/messages to watch kde and other bugs ... Ralf From pasik at iki.fi Thu Jun 4 17:11:18 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Thu, 4 Jun 2009 20:11:18 +0300 Subject: F11: plymouthd hides important (debug) messages from initrd execution In-Reply-To: <20090604161354.GN24960@edu.joroinen.fi> References: <20090601051548.GW24960@edu.joroinen.fi> <20090603111411.GE24960@edu.joroinen.fi> <20090604161354.GN24960@edu.joroinen.fi> Message-ID: <20090604171118.GO24960@edu.joroinen.fi> On Thu, Jun 04, 2009 at 07:13:54PM +0300, Pasi K?rkk?inen wrote: > On Wed, Jun 03, 2009 at 02:14:11PM +0300, Pasi K?rkk?inen wrote: > > On Mon, Jun 01, 2009 at 08:15:48AM +0300, Pasi K?rkk?inen wrote: > > > Hello. > > > > > > Yesterday I installed latest F11/rawhide. The default installed kernel > > > (2.6.29 something) works fine. > > > > > > I compiled custom 2.6.30-rc6 kernel, and created initrd for it, and tried > > > booting it. > > > > > > Booting process gets stuck at "creating initial device nodes". > > > > > > Any ideas? I assume that's during initrd execution.. > > > Something missing from my kernel config? > > > > > > Any tips would be appreciated. > > > > Has anyone else seen this problem? > > > > I edited the initrd image, and added some debug echos. > The command that hangs the initrd execution is this: > > daemonize --ignore-missing /bin/plymouthd > > Any ideas? > Ok.. After I disabled every call to plymouthd from initrd init script I figured out the problem was not related to plymouthd at all. The problem here is plymouthd seems to _hide_ everything that happens after it has been started.. and thus prevents important stuff from being seen and the real problems from being easily determined. -- Pasi From opensource at till.name Thu Jun 4 17:33:26 2009 From: opensource at till.name (Till Maas) Date: Thu, 04 Jun 2009 19:33:26 +0200 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <200906030843.26442.sgrubb@redhat.com> Message-ID: <200906041933.32347.opensource@till.name> On Wed June 3 2009, Kevin Kofler wrote: > Steve Grubb wrote: > > And then should the bug be closed hoping that one day you pull in a > > package that solves the user's problem? > > If the bug is fixed upstream, the Fedora report can be reopened with a > request to backport the fix (but that should only be done if it's important > enough that it cannot wait for the next bugfix update getting pushed > anyway). > > Until then, why do we need to have the bug open in 2 places? The ball is in > upstream's court as long as we're waiting for them to fix the issue, we've > done our part as packagers, so as far as we're concerned the issue is > closed. As for those cases where the upstream maintainer is the same as the If the new bugfix release update is created, do you include there all RH bugs that are closed UPSTREAM but fixed with this update? Keeping the bugs open to not forget to add the to the update is imho the most important reason for bugs that are already reported upstream. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From rc040203 at freenet.de Thu Jun 4 17:38:25 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 04 Jun 2009 19:38:25 +0200 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <20090603113809.3ad3d992@faldor.intranet> <4A266755.6080904@freenet.de> <20090603150057.7d9fc5db@faldor.intranet> <4A267EA0.20600@freenet.de> Message-ID: <4A280691.8030709@freenet.de> Kevin Kofler wrote: > Ralf Corsepius wrote: > Signing up for an upstream Bugzilla account takes at most 5 minutes, ... when being interested in an upstream ... wasting much more time on investigating issues ... >> There are other packages and packagers (noteworthy many of the @RH) who >> exhibit the same "push reporters around" behavior. > > That's because that's our policy, and rightfully so. I disagree. It's a serious management error. >> Now combine this with the "report bugs" phrases certain people tend to >> reiterate? ... Experiences, such as the one I encountered with the >> evolution maintainer, are the cause why at least some people sense a >> foul taste when listening to them. > > Then let's say: Report bugs, to the right place of course (usually > upstream)! Then better be consequent: Shut down Fedora's bugzilla. From awilliam at redhat.com Thu Jun 4 18:15:29 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 04 Jun 2009 11:15:29 -0700 Subject: Maintainer Responsibilities In-Reply-To: <0d1431c97cd225c77ffed87c1823a731.squirrel@arekh.dyndns.org> References: <200906021617.12122.sgrubb@redhat.com> <200906031301.01385.jreznik@redhat.com> <200906041204.15608.opensource@till.name> <0d1431c97cd225c77ffed87c1823a731.squirrel@arekh.dyndns.org> Message-ID: <1244139329.2937.363.camel@adam.local.net> On Thu, 2009-06-04 at 14:18 +0200, Nicolas Mailhot wrote: > Last time I reported this problem in the bugzilla component of redhat > bugzilla (I complained about all the columns in list view no one uses > when "last change" is not even displayed) the answer was that the > people in charge did not want to deviate from upstream (bugzilla) > defaults. > > Which, given all the historic redhat bugzilla customization, was a bit > rich Key word there is 'historic'. The experience with all that historic customization is the reason why, currently, the Bugzilla maintainers are trying to avoid having customization :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From awilliam at redhat.com Thu Jun 4 18:23:01 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 04 Jun 2009 11:23:01 -0700 Subject: Maintainer Responsibilities In-Reply-To: <4A27F5FE.6090305@city-fan.org> References: <200906021617.12122.sgrubb@redhat.com> <200906040940.16503.mhlavink@redhat.com> <200906041700.06098.mhlavink@redhat.com> <4A27F5FE.6090305@city-fan.org> Message-ID: <1244139781.2937.366.camel@adam.local.net> On Thu, 2009-06-04 at 17:27 +0100, Paul Howarth wrote: > I'll happily raise upstream bugs myself but it irks me when maintainers > close Fedora bugs with the UPSTREAM resolution without actually taking > the upstream fix and bringing it into Fedora. > > If I've reported a bug in Fedora bugzilla it's because the bug is > present in Fedora and I'd like to see it fixed *in Fedora*. So seeing a > bug closed UPSTREAM doesn't help at all if I have a real problem with a > Fedora package. In Mandriva I had it set up so Bugzilla has both an UPSTREAM *resolution* and an UPSTREAM *keyword*. This handles this situation. If, say, the bug is in a package that gets frequent releases, and was filed on the development release, you can just use CLOSED UPSTREAM, because you can rely on the fact that there'll be a new upstream release of the package soon after the upstream report is fixed, you (the maintainer) will then naturally package the new release, and the fix for the bug will have been rolled into the distribution package without you having to do anything besides your normal packaging work. In other situations, you can set the UPSTREAM keyword, so the bug remains open but you know it's being handled upstream and you need to bring the fix downstream once it's available upstream. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From sgrubb at redhat.com Thu Jun 4 18:23:44 2009 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 4 Jun 2009 14:23:44 -0400 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <200906030843.26442.sgrubb@redhat.com> Message-ID: <200906041423.44539.sgrubb@redhat.com> On Wednesday 03 June 2009 04:57:32 pm Kevin Kofler wrote: > Steve Grubb wrote: > > And then should the bug be closed hoping that one day you pull in a > > package that solves the user's problem? > > If the bug is fixed upstream, the Fedora report can be reopened with a > request to backport the fix (but that should only be done if it's important > enough that it cannot wait for the next bugfix update getting pushed > anyway). When bugs are closed, they disappear from the reporter's bz frontpage. Its far easier to leave the bug open and close it when the fixed package gets pushed through bodi. > Until then, why do we need to have the bug open in 2 places? Yes. Many times when I am evaluating a package I look in bz to see what bugs are open against it as a test sniff of what its quality might be like. If the maintainer is closing everything as upstream bugs, I might be installing a steaming hot pile of awful and not knowing its got lots of problems. Also by closing unresolved bugs you are inviting duplicate bug reports. -Steve From josef at toxicpanda.com Thu Jun 4 18:23:59 2009 From: josef at toxicpanda.com (Josef Bacik) Date: Thu, 4 Jun 2009 14:23:59 -0400 Subject: Maintainer Responsibilities In-Reply-To: <4A267EA0.20600@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <20090603113809.3ad3d992@faldor.intranet> <4A266755.6080904@freenet.de> <20090603150057.7d9fc5db@faldor.intranet> <4A267EA0.20600@freenet.de> Message-ID: <1b7401870906041123x536300bbnb67d74643594b0d1@mail.gmail.com> On Wed, Jun 3, 2009 at 9:46 AM, Ralf Corsepius wrote: > Michael Schwendt wrote: >> >> On Wed, 03 Jun 2009 14:06:45 +0200, Ralf wrote: >> >>> I consider users (esp. bug reporters) not to be "the dumb pigs eating the >>> hog wash they get for free", or "clueless comsumer masses" aborbing anything >>> they don't pay for with money, but them to be the foundation of your work >>> and them to be valuable business partners, paying in immaterial payment >>> (e.g. feedback, such as bug reports). >> >> That's an idealistic [over-simplified] point of view which I don't want to >> agree with. > > Well, whether it's idealistic or not is irrelevant. It's one of the > foundations of open source. > > Or less abstract: > I stopped reporting bugs against Fedora's evolution, because its @RH > maintainer preferred to close bugs and tried to push me around to upstream. > Wrt. evolution, I was an ordinary user and am not interested in getting > further involved. > > As simple as it is: I felt sufficiently pissed of by this guy to leave him > and his upstream alone, ... so be it, he wanted it this way. > > There are other packages and packagers (noteworthy many of the @RH) who > exhibit the same "push reporters around" behavior. > Bz #'s? You seem to like to complain a lot about how crappy of a job us Red Hatters do, but don't offer any concrete evidence. I would be very much interested in seeing these "many" people at RH who exhibit this behaviour. One anecdotal interaction where we only have your word about what happened does not count as sufficient evidence for the sweeping generalization that @RH people don't care about bugs. Josef From awilliam at redhat.com Thu Jun 4 18:40:04 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 04 Jun 2009 11:40:04 -0700 Subject: Fedora 11 Test Day survey In-Reply-To: <200906041008.27294.mhlavink@redhat.com> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> <200906041008.27294.mhlavink@redhat.com> Message-ID: <1244140804.2937.371.camel@adam.local.net> On Thu, 2009-06-04 at 10:08 +0200, Michal Hlavinka wrote: > > 2. Was sufficient documentation available to help you participate in a > > Fedora Test Day? If not, what did you find missing or in need of > > improvement? > > mostly, see examples: > good: > Test Day:2009-03-26 Nouveau > " > /sbin/lspci -d 10de: | grep -iq VGA && echo "Join Nouveau Fedora Test Day" || > echo "No nVidia graphics hardware found." > " > > bad: > Test Day:2009-04-09 UEFI > " > FIXME|How to identify if your system supports UEFI? > " > This text was there for some time and than it just disappeared without any > answer. The UEFI one was kind of a special case. The only people who actually have appropriate hardware either work for BIOS companies, hardware manufacturers, or in the testing department of companies like RH, and everyone who has UEFI hardware certainly knows they do. :) We intentionally under-promoted that test day because it was really only of interest to a small and very definitely defined circle of people. We should, however, have made that rather a lot clearer on the Wiki page itself, for people who'd got into the habit of just looking at each week's Test Day as it came. You're right there. > > 7. Do you have any more general comments or any suggestions for > > improving future test days? > > start them earlier in rawhide development phase. If tens of bugs are found > three weeks before freeze, we can hardly expect they are fixed in time. Scheduling is a tricky point, yep: too late in the cycle and you can't get fixes in, too early and the feature isn't done being written yet. We're trying to think of ways to optimize scheduling as far as we can. Thanks for your feedback! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From h.reindl at thelounge.net Thu Jun 4 18:45:21 2009 From: h.reindl at thelounge.net (Reindl Harald) Date: Thu, 04 Jun 2009 20:45:21 +0200 Subject: Maintainer Responsibilities In-Reply-To: <20090604182409.5C74361B07E@hormel.redhat.com> References: <20090604182409.5C74361B07E@hormel.redhat.com> Message-ID: <4A281641.8060804@thelounge.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think it is simple BAD to close bugreports with "upstream"! For me as "enduser" of fedora i have one bugzilla and i really like to help with bugreports, try things if maintainer needs better explains what happens. But i have no time and no energy to register on the bugzilla of every piece of software i have installed and i can not look at bugzilla from rsync, kde, amarok..... the whole time. Should the enduser try patches and svn-versions? NO he is user and that was it If someone maintains a package he can test this much better and understands many things the normal user never can and want to konw I know the maintainer can't too for all BUT he get's only bugs for packages which he maintains, he konws (or should know) the software he maintains and normally i think he/she have a watch at upstream-bugzilla and knows MUCH more about the upstream project as the most users So i think the maintainer should play as "relay", taking fedora-bugreports and in many cases report them with much more knowing about the software upstream. If you want that the enduser report bugs upstream you get no repsonse in many cases because the user will say "WTF i wanted to help and you want to say me exactly how i have to help" and after this happens trhee times he is frustrated and will never ever report bugs As poweruser you could use many applications and find mny small bugs in all of them - If you try to handle all of that stuff in the upstream-project and have a fulltimejob and a family you would egt a problem - reporting bugs on fedora-bz or lost your life and deal with all upstream-projects you know Forget it - I think this is maintainers work or you will lost respnses time after time -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkooFkEACgkQhmBjz394AnlLzgCglDQ465W4reprEmCbmoiYgw48 X1MAoJj3mdTmlo+SCD+kC/myICY3V+SP =b+9R -----END PGP SIGNATURE----- From skvidal at fedoraproject.org Thu Jun 4 18:47:29 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 4 Jun 2009 14:47:29 -0400 (EDT) Subject: Maintainer Responsibilities In-Reply-To: <4A281641.8060804@thelounge.net> References: <20090604182409.5C74361B07E@hormel.redhat.com> <4A281641.8060804@thelounge.net> Message-ID: On Thu, 4 Jun 2009, Reindl Harald wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I think it is simple BAD to close bugreports with "upstream"! > For me as "enduser" of fedora i have one bugzilla and i really like > to help with bugreports, try things if maintainer needs better explains > what happens. I am the packager for some pkgs and I'm also one of the upstream maintainers. I'll close bugs 'upstream' when I've fixed them in the upstream tree but not yet pushed them out to fedora. -sv From kevin at scrye.com Thu Jun 4 18:49:26 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 4 Jun 2009 12:49:26 -0600 Subject: Maintainer Responsibilities In-Reply-To: <1244139781.2937.366.camel@adam.local.net> References: <200906021617.12122.sgrubb@redhat.com> <200906040940.16503.mhlavink@redhat.com> <200906041700.06098.mhlavink@redhat.com> <4A27F5FE.6090305@city-fan.org> <1244139781.2937.366.camel@adam.local.net> Message-ID: <20090604124926.1d6c2b74@ohm.scrye.com> Just to chime in here... I personally try and do the following with my bugs: - Look over the inital report. - Move to ASSIGNED and ask the reporter any further info I need to try and figure out if it's a packaging issue or upstream or bug or enhancement or what. - If its a packaging issue, I try and fix it. - If it's an enhancement/difficult upstream issue/etc I ask the reporter: "Hey, would you like to report this upstream and see if they can fix it?" If they say they don't want to for whatever reason, I do so. If they do, I get the bug # and add myself upstream to help out. I think the point is that one size doesn't fit all here. I don't think we can have a single policy to cover this. It depends on many factors, like: - Is upstream responsive? - Is the reporter responsive? - Is the bug something that the maintainer really feels should get fixed, even if the reporter is no longer responsive? - Is the bug something the maintainer can't duplicate for whatever reason? (ie, the reporter is needed to try fixes). I agree it's the role for maintainers to maintain their packages and work to help the reporters get their issues fixed. Whatever way they feel is best to do so. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hpa at zytor.com Thu Jun 4 18:51:00 2009 From: hpa at zytor.com (H. Peter Anvin) Date: Thu, 04 Jun 2009 11:51:00 -0700 Subject: Unbootable machine In-Reply-To: <4A27D2B1.9070203@codewiz.org> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> <4A247506.4000304@codewiz.org> <4A2483C8.7090706@zytor.com> <4A249C12.2060708@codewiz.org> <4A24B44D.3070607@zytor.com> <4A27D2B1.9070203@codewiz.org> Message-ID: <4A281794.2010108@zytor.com> Bernie Innocenti wrote: >> >> Equally weird. The only "standard" ones are 64 heads, 32 sectors and >> 255 heads, 63 sectors. > > Indeed, repartitioning the USB stick with 32 sectors and 255 heads fixed > boot for a previously unbootable computer. > 32x255? That's an odd mix? Does 32x64 work on that machine, too? -hpa From notting at redhat.com Thu Jun 4 18:53:40 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 4 Jun 2009 14:53:40 -0400 Subject: Action requested: check dist tags and conditionals Message-ID: <20090604185340.GA16703@nostromo.devel.redhat.com> (If you've never used a construct like "%if 0%{?fedora}" in your spec file, you can disregard this message.) Many packages in Fedora use release-based conditionals such as: ... %if 0%{?rhel} %endif %if 0%{?fedora} < 10 %endif %{?fedora:%global _with_xfce --with-xfce} ... I'd just like to remind people of the following: - If you're using open ended conditionals such as: %if 0%{?fedora} > 9 make sure you keep in mind what will happen if %{fedora} isn't defined, such as in the case of a derivative distribution. - If you're building for EPEL from a unified Fedora spec file, and have separate %{fedora} and %{rhel} sections, make sure they do the right things for any potential new releases, not just %{rhel} = 4 or %{rhel} = 5. Thanks! Bill _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From craftjml at gmail.com Thu Jun 4 18:56:28 2009 From: craftjml at gmail.com (Jud Craft) Date: Thu, 4 Jun 2009 13:56:28 -0500 Subject: Maintainer Responsibilities In-Reply-To: <4A27F84E.4060501@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> <200906031137.19294.smparrish@gmail.com> <4A275A39.4070601@freenet.de> <20090604070028.GB3712@verda-stelo.englab.brq.redhat.com> <4A27F84E.4060501@freenet.de> Message-ID: <20d6441a0906041156m194b5c76m95721154a5e39e77@mail.gmail.com> On Thu, Jun 4, 2009 at 11:37 AM, Ralf Corsepius wrote: > David Tardon wrote: >> >> Let me try another analogy: How do you handle health problems? >> >> You'll visit your doctor. You'll expect him to identify the problem and >> to take appropriate steps to solve your issue--that may well be just him >> sending you to a specialist. Would you expect your doctor to serve as a >> proxy between you and the specialist? Or even substitute you for >> checkup? I wouldn't. That, in fact...is...exactly how it works. There's too much knowledge. A general-specialized entity has to forward clients to a super-specialized entity for super-specialized service. You can't expect one entity (when the entity = human) to be able to do everything. Don't use that analogy. It doesn't help. In my opinion, you're all missing the big picture. And in my audacity, let me suggest it. 1. End-users should be able to seek out support when they need it. You all agree. 2. End-users should be expected to go to upstream with their issues. You are split. 3. Maintainers should be expected to go to upstream with end-user's issues. You are split. Support != upstream. It's a symptom of the fact that the open source community is where people who create goods often don't do top-down support of those goods to end-users, the final recipient. Here's the problem: You all agree that end-users should seek out support. The reason why "they should go to upstream" is split isn't because Seeking Support = Bad. Seeking Support = Good. You're split because Having Outsiders Navigate Two/Three Layers of Community Indirection = Bad. In terms of navigating the community, open-source is as bad as any bureaucracy. It says "Let me forward you to X", when getting to X is appropriately daunting, and by the time you do you don't even know what to tell X. It's not "who should do it", it's "what do these users have to go through?" That's your problem, so rephrasing it in terms of "who should have to do the upstream contact?" is not the problem. That's delegating everything to one entity. End-users, package maintainers, upstream. One has the user experience. One delivers the user experience. One creates the user experience. Sadly, 2 and 3 aren't the same person. There must be a system that can allow 1 and 3 to talk directly, easily, without worrying about any adverse factors that 2 might have stuck into the works. (It does no good for end-users to work with upstream on packages that upstream doesn't even understand). Until someone is a genius enough to come up with these ideas, you're always going to have problems. So for the here and now: 1. Assume the average end-user will be of no help -- he should be expected to seek support, but he cannot be expected to navigate the open source community. A few will, but to be super-effective the barrier to entry must be drastically lowered. 2. Maintainers must realize that de facto -- even though it isn't ideal -- they'll have to take on some burden of upstream contact. And accept it. (While being a little grumpy. That's probably okay.) 3. You need an easier way for users to file for issues. All necessary metadata information gathering (versions, kernel, package names) should be automatic. The system should be smart enough to do that. (It seems like Fedora is getting there with its new reporting tools and on-demand debug utility.) Let the end-user do the only thing he can: describe what went wrong in plain english in a text-box, and then don't burden him with anything else. From awilliam at redhat.com Thu Jun 4 18:56:41 2009 From: awilliam at redhat.com (Adam Williamson) Date: Thu, 04 Jun 2009 11:56:41 -0700 Subject: Fedora 11 Test Day survey In-Reply-To: <200906041416.41427.opensource@till.name> References: <1244038226.19989.45.camel@flatline.devel.redhat.com> <200906041416.41427.opensource@till.name> Message-ID: <1244141801.2937.379.camel@adam.local.net> On Thu, 2009-06-04 at 14:16 +0200, Till Maas wrote: > > 3. Did you encounter any obstacles preventing participation in Fedora > > test Days? How might they have been avoided? Did you discover any > > workaround? > > The live iso images failed to be converted to live usb media on F10 with a > strange looking boot menu. It could have beend avoided with testing this > before starting the test day. This sounds like the somewhat-infamous problem with f10's USB creator not working for F11 images. Later in the F11 cycle, we did have that issue neatly identified and pinned down, and we started adding a box out to test days explaining it. See the nouveau page, for e.g.: https://fedoraproject.org/wiki/Test_Day:2009-03-26_Nouveau#Live_Image note the blue box. The explanation could have been a bit more descriptive and emphatic, though, I suppose. > > 4. Were you able to locate and download installation media for testing? > > Did it function as expected? > > Yes. No, see 3. Also I would have expected testing instructions on the live > media to perform the tests without the need to setup an internet connection on > the testing machine. That's a good point - in some situations it's hard to get an internet connection on a live image. So we should try as hard as we can to include all necessary material on the image itself. > Also some bug report info gathering scripts would have > been nice, that e.g. collect all the data required by the packages maintainers > for a bug report in some file on the usb medium. E.g. the Xorg people wanted a > lot of information that I did not have anymore after I rebooted to my stable > F10 system and reported the bug. Also when the test crashes the Xserver, it is > very annoying to get to the log files, because they are deleted after a > reboot. This one's a bit tricky - on the one hand it'd be nice, on the other it'd be a substantial development effort for each test day and they already take quite a lot of effort to organize. Perhaps, however, we could come up with a general-purpose script which could be used for X test days, as the procedures tend to be very similar for different drivers and different releases. We'll certainly look into that for the X test days for F12. Thanks for your feedback! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net From bernie at codewiz.org Thu Jun 4 19:03:06 2009 From: bernie at codewiz.org (Bernie Innocenti) Date: Thu, 04 Jun 2009 21:03:06 +0200 Subject: Unbootable machine In-Reply-To: <4A281794.2010108@zytor.com> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> <4A247506.4000304@codewiz.org> <4A2483C8.7090706@zytor.com> <4A249C12.2060708@codewiz.org> <4A24B44D.3070607@zytor.com> <4A27D2B1.9070203@codewiz.org> <4A281794.2010108@zytor.com> Message-ID: <4A281A6A.8040005@codewiz.org> On 06/04/09 20:51, H. Peter Anvin wrote: > Bernie Innocenti wrote: >>> >>> Equally weird. The only "standard" ones are 64 heads, 32 sectors and >>> 255 heads, 63 sectors. >> >> Indeed, repartitioning the USB stick with 32 sectors and 255 heads fixed >> boot for a previously unbootable computer. >> > > 32x255? That's an odd mix? Does 32x64 work on that machine, too? Sorry, I mistyped the numbers. It was really 255 heads, 63 sectors: (parted) p Model: LEXAR JD EXPRESSION (scsi) Disk /dev/sdb: 123,86,26 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 123,255,63. Each cylinder is 8225kB. Partition Table: msdos -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ From hpa at zytor.com Thu Jun 4 19:06:36 2009 From: hpa at zytor.com (H. Peter Anvin) Date: Thu, 04 Jun 2009 12:06:36 -0700 Subject: Unbootable machine In-Reply-To: <4A281A6A.8040005@codewiz.org> References: <4A236808.1050106@codewiz.org> <4A2377B3.8060309@zytor.com> <4A247506.4000304@codewiz.org> <4A2483C8.7090706@zytor.com> <4A249C12.2060708@codewiz.org> <4A24B44D.3070607@zytor.com> <4A27D2B1.9070203@codewiz.org> <4A281794.2010108@zytor.com> <4A281A6A.8040005@codewiz.org> Message-ID: <4A281B3C.7020300@zytor.com> Bernie Innocenti wrote: > > Sorry, I mistyped the numbers. It was really 255 heads, 63 sectors: > > (parted) p > Model: LEXAR JD EXPRESSION (scsi) > Disk /dev/sdb: 123,86,26 > Sector size (logical/physical): 512B/512B > BIOS cylinder,head,sector geometry: 123,255,63. Each cylinder is 8225kB. > Partition Table: msdos > Ah, okay. Does 64x32 work, too? I'm trying to gather as much information about what makes sticks boot... -hpa From khc at pm.waw.pl Thu Jun 4 19:12:03 2009 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Thu, 04 Jun 2009 21:12:03 +0200 Subject: F11 discontinued so fast? :-) Message-ID: I guess I understand why the following URL is no longer valid, but perhaps the ErrorDocument doesn't work by mistake? http://download.fedora.redhat.com/pub/fedora/linux/releases/11/Fedora/x86_64/iso/ Forbidden You don't have permission to access /pub/fedora/linux/releases/11/Fedora/x86_64/iso/ on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. -- Krzysztof Halasa From Jochen at herr-schmitt.de Thu Jun 4 19:15:15 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 04 Jun 2009 21:15:15 +0200 Subject: F11 discontinued so fast? :-) In-Reply-To: References: Message-ID: <4A281D43.8050402@herr-schmitt.de> Krzysztof Halasa schrieb: > I guess I understand why the following URL is no longer valid, > but perhaps the ErrorDocument doesn't work by mistake? > > http://download.fedora.redhat.com/pub/fedora/linux/releases/11/Fedora/x86_64/iso/ > > Forbidden > The reason is, that the release date of F-11 was sliped to Jun, 9. This slip was caused by a severe issue on anaconda. Best Regards: Jochen Schmitt From sundaram at fedoraproject.org Thu Jun 4 19:22:27 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 05 Jun 2009 00:52:27 +0530 Subject: Comaintainers needed - Gnote and Transmission Message-ID: <4A281EF3.8020805@fedoraproject.org> Hi, Gnote is a port of Tomboy to C++ and will be default in GNOME for Fedora 12 Transmission is a GTK app and the default torrent client for Fedora in GNOME and Xfce (Live CD) Both are active and responsive upstreams and do have frequent releases. If anyone want to be comaintainer, feel free to apply. If you have a good understanding of the codebase or would be able to help with fixes, that would be nice. Rahul From jspaleta at gmail.com Thu Jun 4 19:37:20 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 4 Jun 2009 11:37:20 -0800 Subject: Comaintainers needed - Gnote and Transmission In-Reply-To: <4A281EF3.8020805@fedoraproject.org> References: <4A281EF3.8020805@fedoraproject.org> Message-ID: <604aa7910906041237o54f3ae9ft1c039b2f028bc207@mail.gmail.com> On Thu, Jun 4, 2009 at 11:22 AM, Rahul Sundaram wrote: > Both are active and responsive upstreams and do have frequent releases. > If anyone want to be comaintainer, feel free to apply. If you have a > good understanding of the codebase or would be able to help with fixes, > that would be nice. I'm in! -jef From skvidal at fedoraproject.org Thu Jun 4 19:39:35 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 4 Jun 2009 15:39:35 -0400 (EDT) Subject: F11 discontinued so fast? :-) In-Reply-To: References: Message-ID: On Thu, 4 Jun 2009, Krzysztof Halasa wrote: > I guess I understand why the following URL is no longer valid, > but perhaps the ErrorDocument doesn't work by mistake? > > http://download.fedora.redhat.com/pub/fedora/linux/releases/11/Fedora/x86_64/iso/ f11 is not yet released. -sv From mschwendt at gmail.com Thu Jun 4 19:41:03 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 4 Jun 2009 21:41:03 +0200 Subject: libmowgli SONAME bump in devel (F-12) only Message-ID: <20090604214103.15a88ba2@faldor.intranet> A new libmowgli release has been built in "devel" tree (F-12), which changes the SONAME from libmowgli.so.1 to libmowgli.so.2. Rebuilds are needed for conky kadu-audacious_mediaplayer mcs audacious-plugin* I've rebuilt "mcs" already and continue with peeking at audacious and its plugins. From behdad at behdad.org Thu Jun 4 19:43:01 2009 From: behdad at behdad.org (Behdad Esfahbod) Date: Thu, 04 Jun 2009 15:43:01 -0400 Subject: Renaming language groups Message-ID: <4A2823C5.9070607@behdad.org> Hi, Right now if I do "yum grouplist" I see something like: ... Portuguese Support Romanian Support Ruby Russian Support Samoan Support Sanskrit Support Sardinian Support Serbian Support Sindhi Support Slovak Support Slovenian Support Somali Support Sound and Video Southern Ndebele Support Southern Sotho Support Spanish Support ... May I suggest that we rename the language groups from "XXX Support" to either "XXX Language" or "XXX Translations"? That's simply more informative when you don't know, say, what "Hiligaynon" is, as well as enables grepping them out to see what other groups there are. Cheers, behdad From dpierce at redhat.com Thu Jun 4 19:44:39 2009 From: dpierce at redhat.com (Darryl L. Pierce) Date: Thu, 4 Jun 2009 15:44:39 -0400 Subject: Maintainer Responsibilities In-Reply-To: <4A281641.8060804@thelounge.net> References: <20090604182409.5C74361B07E@hormel.redhat.com> <4A281641.8060804@thelounge.net> Message-ID: <20090604194439.GA32252@mcpierce-laptop.rdu.redhat.com> On Thu, Jun 04, 2009 at 08:45:21PM +0200, Reindl Harald wrote: > I think it is simple BAD to close bugreports with "upstream"! +1 That's one step away from just ignoring the user. > So i think the maintainer should play as "relay", taking fedora-bugreports > and in many cases report them with much more knowing about the software > upstream. This is what I posted yesterday. The package maintainer should act as the face for their package(s) to the user. If the maintainer is not the upstream, then part of their job as maintainer should be to relay those bugs to the upstream, opening the bugs there, and then ensuring any patches or updates are moved into Fedora as soon as they're available. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste n? B?arla cliste. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jkeating at j2solutions.net Thu Jun 4 19:44:13 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 04 Jun 2009 12:44:13 -0700 Subject: F11 discontinued so fast? :-) In-Reply-To: References: Message-ID: <1244144653.2876.35.camel@localhost.localdomain> On Thu, 2009-06-04 at 21:12 +0200, Krzysztof Halasa wrote: > I guess I understand why the following URL is no longer valid, > but perhaps the ErrorDocument doesn't work by mistake? > > http://download.fedora.redhat.com/pub/fedora/linux/releases/11/Fedora/x86_64/iso/ > > Forbidden > > You don't have permission to access > /pub/fedora/linux/releases/11/Fedora/x86_64/iso/ on this server. The directory was open by mistake. We're not fully staged for the release yet. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From francis.earl at gmail.com Thu Jun 4 19:44:59 2009 From: francis.earl at gmail.com (Francis Earl) Date: Thu, 04 Jun 2009 12:44:59 -0700 Subject: Maintainer Responsibilities In-Reply-To: <200906021617.12122.sgrubb@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> Message-ID: <1244144699.5941.10.camel@thasylum.home> I think a package maintainers responsibilities should be to incorporate any back-ported bug fixes, and ensure the package is reasonably fit for end users... if they can't do this, I don't think they should be packaging that software (whether it be due to individual skill set, or simply the upstream state). I wish Bugzilla had a way to track bugs in different instances of itself, that way once a package maintainer has figured out it's not a packaging issue, he can simply send it upstream, and have it all tracked as one bug from there - propagating that to whatever other instances have linked to it (read other distros with the same bug). This would simplify a lot of things for maintainers, and save them a lot of time also. Things like the auto-crash handler will help with users that don't wish to learn technical details, with the debugfs simplifying everything fairly well to ensure bug reports are useful. This often results in repeated bug reports though, so I hope they take lessons learned from apport into account here. Overall, I do not believe that package maintainers need to necessarily be programmers, and I believe upstream should have some say in most bug fixes. Of course it helps if they actually know the software, rather than just being competent with the packaging tools, but that starts to raise the barrier for contribution, so I don't know if requiring that is a good idea... what I state above goes a long way to ensuring they don't need to be programmers though. From notting at redhat.com Thu Jun 4 19:58:40 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 4 Jun 2009 15:58:40 -0400 Subject: Renaming language groups In-Reply-To: <4A2823C5.9070607@behdad.org> References: <4A2823C5.9070607@behdad.org> Message-ID: <20090604195839.GB18078@nostromo.devel.redhat.com> Behdad Esfahbod (behdad at behdad.org) said: > Right now if I do "yum grouplist" I see something like: > > ... > Portuguese Support > Romanian Support > Ruby > Russian Support > Samoan Support > Sanskrit Support > Sardinian Support > Serbian Support > Sindhi Support > Slovak Support > Slovenian Support > Somali Support > Sound and Video > Southern Ndebele Support > Southern Sotho Support > Spanish Support > ... > > May I suggest that we rename the language groups from "XXX Support" to > either "XXX Language" or "XXX Translations"? That's simply more > informative when you don't know, say, what "Hiligaynon" is, as well as > enables grepping them out to see what other groups there are. It's not just translations - there are input methods and display fonts as well. We could change them all to " Language Support", but that would break translations. Of course, there's a proposal on the table to kill most of them for Fedora 12 in favor of a different infrastructure entirely. Bill From belegdol at gmail.com Thu Jun 4 20:11:49 2009 From: belegdol at gmail.com (Julian Sikorski) Date: Thu, 04 Jun 2009 22:11:49 +0200 Subject: Action requested: check dist tags and conditionals In-Reply-To: <20090604185340.GA16703__20368.7377543703$1244141637$gmane$org@nostromo.devel.redhat.com> References: <20090604185340.GA16703__20368.7377543703$1244141637$gmane$org@nostromo.devel.redhat.com> Message-ID: Bill Nottingham pisze: > (If you've never used a construct like "%if 0%{?fedora}" in your spec > file, you can disregard this message.) > > Many packages in Fedora use release-based conditionals such as: > > ... > %if 0%{?rhel} > %endif > > %if 0%{?fedora} < 10 > %endif > > %{?fedora:%global _with_xfce --with-xfce} > ... > > I'd just like to remind people of the following: > > - If you're using open ended conditionals such as: > %if 0%{?fedora} > 9 > make sure you keep in mind what will happen if %{fedora} isn't defined, > such as in the case of a derivative distribution. > > - If you're building for EPEL from a unified Fedora spec file, and have > separate %{fedora} and %{rhel} sections, make sure they do the right > things for any potential new releases, not just %{rhel} = 4 or %{rhel} = 5. > > Thanks! > > Bill > > _______________________________________________ > Fedora-devel-announce mailing list > Fedora-devel-announce at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-announce > This is often used to tailor BuildRequires, I can't take responsibility what a given release of a derivative distro does or doesn't include. Julian From smparrish at gmail.com Thu Jun 4 20:02:11 2009 From: smparrish at gmail.com (Steven M. Parrish) Date: Thu, 4 Jun 2009 16:02:11 -0400 Subject: KPackageKit fail In-Reply-To: <64b14b300906032334v735a922r422e7ab0b5ce7116@mail.gmail.com> References: <64b14b300906032334v735a922r422e7ab0b5ce7116@mail.gmail.com> Message-ID: <200906041602.11617.smparrish@gmail.com> We are aware of the kpackagekit issue and are awaiting a release from the upstream developers. It should be released later today and after a bit of testing I will get it into the repo asap. SMP > I'm testing Rawhide with latest updates and KPackageKit fails to do > updates, I get this error log: > http://fpaste.org/paste/13851 > > It is works for you haven't tested it please do, if it works for you > then ignore this message, if not then reply if you need some more > feedback from me and I will open a new bug report then. > > > Cheers > > > -- > http://kernelreloaded.blog385.com/ > linux, blog, anime, spirituality, windsurf, wireless > registered as user #367004 with the Linux Counter, http://counter.li.org. > ICQ: 2125241, Skype: valent.turkovic From kevin.kofler at chello.at Thu Jun 4 20:30:33 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 22:30:33 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> <200906031137.19294.smparrish@gmail.com> <4A275A39.4070601@freenet.de> <20090604070028.GB3712@verda-stelo.englab.brq.redhat.com> <4A27F84E.4060501@freenet.de> <20d6441a0906041156m194b5c76m95721154a5e39e77@mail.gmail.com> Message-ID: Jud Craft wrote: > Support != upstream. It's a symptom of the fact that the open source > community is where people who create goods often don't do top-down > support of those goods to end-users, the final recipient. > > Here's the problem: You all agree that end-users should seek out > support. The reason why "they should go to upstream" is split isn't > because Seeking Support = Bad. Seeking Support = Good. You're split > because Having Outsiders Navigate Two/Three Layers of Community > Indirection = Bad. Fixing bugs is a service we do to end users. If they don't want to use the service the way we provide it, that's fine with me, we can just close their stuff as INSUFFICIENT_DATA and move on. Kevin Kofler From kevin.kofler at chello.at Thu Jun 4 20:39:13 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 22:39:13 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906030843.26442.sgrubb@redhat.com> <200906041933.32347.opensource@till.name> Message-ID: Till Maas wrote: > If the new bugfix release update is created, do you include there all RH > bugs that are closed UPSTREAM but fixed with this update? Well, we try to reference fixed bugs, but often we don't even know that a bug was fixed by an upstream bugfix release until after the fact. In fact upstream themselves don't always realize it, upstream bugs occasionally get closed only weeks after the release as "seems fixed, can't reproduce with 4.x.y" or "apparently the fix for kde#123456 also fixed this one". Large projects like KDE have way too many bug reports to keep track of all of them. Kevin Kofler From kevin.kofler at chello.at Thu Jun 4 20:35:30 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 22:35:30 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <4A25E97D.8000202@freenet.de> <20090603113809.3ad3d992@faldor.intranet> <4A266755.6080904@freenet.de> <20090603150057.7d9fc5db@faldor.intranet> <4A267EA0.20600@freenet.de> <4A280691.8030709@freenet.de> Message-ID: Ralf Corsepius wrote: > Then better be consequent: Shut down Fedora's bugzilla. We need the Bugzilla for issues which are actually Fedora's fault. But most of them are bugs in upstream code and upstream's to fix. They hit all distributions the same way, why should they be tracked in a random distribution's bug tracker? Kevin Kofler From kevin.kofler at chello.at Thu Jun 4 20:45:43 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 22:45:43 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906030843.26442.sgrubb@redhat.com> <200906041423.44539.sgrubb@redhat.com> Message-ID: Steve Grubb wrote: > When bugs are closed, they disappear from the reporter's bz frontpage. That's a Bugzilla misfeature (not to say "bug"). Bugzilla should default to showing closed bugs. Not just for this case, but also to avoid duplicate reports for: * NOTABUG reports (which keep getting duplicates because people don't notice the bugs closed as NOTABUG), * issues which are fixed in supported releases, but not in the EOL release the user is still using, * issues which are fixed in Rawhide, but cannot be fixed in existing releases for technical reasons etc. > Its far easier to leave the bug open and close it when the fixed package > gets pushed through bodi. That assumes we know when the bug got fixed in the first place, which isn't always the case (see my reply to Till Maas). > Yes. Many times when I am evaluating a package I look in bz to see what > bugs are open against it as a test sniff of what its quality might be > like. If the maintainer is closing everything as upstream bugs, I might be > installing a steaming hot pile of awful and not knowing its got lots of > problems. Then you need to fix your search to include closed bugs. > Also by closing unresolved bugs you are inviting duplicate bug reports. Because Bugzilla is broken. See above. Let's fix Bugzilla. Kevin Kofler From kevin.kofler at chello.at Thu Jun 4 20:47:54 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 22:47:54 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906040940.16503.mhlavink@redhat.com> <200906041700.06098.mhlavink@redhat.com> Message-ID: Mary Ellen Foster wrote: > Speaking as a semi-frequent reporter of Fedora KDE bugs, I can say > that the process works pretty well for me. Of course, I'm probably > somewhat more engaged in the process than average (e.g., I maintain a > few packages myself, and I've had an account at bugs.kde.org for > years). I do occasionally wish that I didn't have to do the upstream > report myself, but I can see the reasons for it. Oh, by the way, if you see an upstream bug with a matching Fedora bug and no Fedora folks CCed on it, feel free to CC me on it (the e-mail address I use on the KDE Bugzilla is the same showing up in the "From" header of this mail). AFAIK, Rex (rdieter at math.unl.edu) also likes to be CCed on those bugs. Kevin Kofler From kevin.kofler at chello.at Thu Jun 4 20:53:48 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 22:53:48 +0200 Subject: Maintainer Responsibilities References: <200906021617.12122.sgrubb@redhat.com> <200906040940.16503.mhlavink@redhat.com> <200906041700.06098.mhlavink@redhat.com> <4A27F5FE.6090305@city-fan.org> <1244139781.2937.366.camel@adam.local.net> Message-ID: Adam Williamson wrote: > If, say, the bug is in a package that gets frequent releases, and was > filed on the development release, you can just use CLOSED UPSTREAM, > because you can rely on the fact that there'll be a new upstream release > of the package soon after the upstream report is fixed, you (the > maintainer) will then naturally package the new release, and the fix for > the bug will have been rolled into the distribution package without you > having to do anything besides your normal packaging work. In fact that's what happens with KDE, bugfix releases come out once a month in most cases (the time from the last bugfix point release to the next feature release is a bit longer though, about 2 months upstream (blame the folks who decided *.5 releases are not needed), plus about 2 weeks of testing in updates-testing to prevent regressions). You're also welcome to reopen bugs if upstream has a fix and you want us to backport it (but please don't do this if the fixed release is coming soon anyway and the bug is not critical). Kevin Kofler From kevin at scrye.com Thu Jun 4 21:11:22 2009 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 4 Jun 2009 15:11:22 -0600 Subject: Plans for tomorrow's (20090604) FESCo meeting Message-ID: <20090604151122.01ae6e06@ohm.scrye.com> Following are the topics that are likely to be discussed at tomorrows's FESCo meeting, taking place at 1700UTC (1300EDT) in #fedora-meeting on irc.freenode.net: #134 Approval needed - zsync needs to ship internal zlib for rsync compatibility #158 Create new meeting summary procedure #159 FPC report - 2009-06-02 For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kevin.kofler at chello.at Thu Jun 4 21:24:19 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 23:24:19 +0200 Subject: Packager = Programmer? References: <4A277B2A.5010808@gmail.com> <604aa7910906040932w7952f65fmc728e612ab392245@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > I would put it this way.... there should be an expectation that > packagers are willing to learn programming skills relevant to the > packages they are maintaining. There's no proficiency level or > anything like that. But if you aren't interested in learning how to > read and use python..you should probably not maintain a package that > is heavily dependent on python. Those are the sort of personal choices > that can turn the time you gift as a volunteer contribution to Fedora > into a burden instead of having fun doing the work. > > I personally do not maintain package for things that are written in > languages I'm not interested in learning how to use. I avoid perl. I > avoid java. I generally have no personal interest in developing or > refining my ability to read or use either(but it seems like I won't be > able to avoid the java trap for long as part of my day job). And as a > result I don't try to maintain packages for either. Well, it really depends on the package. Some packages need a lot of attention, they constantly need fixing and upstream is non-responsive or just introduces more bugs all the time. Maintaining such a package requires knowing the language it's written in very well. On the other hand, I'm maintaining ocaml-facile just fine with basically nonexistent OCaml skills (because it's used by Kalzium to balance chemical reaction equations). I guess I could figure out enough OCaml to fix issues if I had to (and I'm sure the OCaml SIG can help me if I really can't figure out what's going on), but so far I didn't have to change anything in the OCaml code. The makefile needed fixing (but Debian already had a patch for that, so I didn't have to write even that), but otherwise it just works. No open bugs. Nor even closed ones except the ppc64 ExcludeArch tracking bug which I opened because OCaml wasn't available on ppc64 (it now is). There also haven't been any updates from upstream for ages, probably because there's nothing to fix. So maintenance workload and required skills can vary a lot from package to package. Kevin Kofler From edwin at tenbrink-bekkers.nl Thu Jun 4 21:19:30 2009 From: edwin at tenbrink-bekkers.nl (Edwin ten Brink) Date: Thu, 04 Jun 2009 23:19:30 +0200 Subject: Maintainer Responsibilities In-Reply-To: <200906021617.12122.sgrubb@redhat.com> References: <200906021617.12122.sgrubb@redhat.com> Message-ID: <4A283A62.2070105@tenbrink-bekkers.nl> Steve Grubb wrote: > Does a maintainer's responsibilities end with packaging > bugs? IOW, if there is a problem in the package that is _broken code_ do they > need to do something about it or is it acceptable for them to close the bug > and say talk to upstream? Do we want those bugs open to track when the bug is > fixed in the distro? Aside from all discussions in this thread, the current Bugzilla documentation seems quite clear on this topic. Whatever the outcome of the discussion is, I think the documentation which is visible to the end-user (customer), should at least match the common practice/procedure. Note also that the discussion is primarily focussed on the Resolution of the bug report, while there are also two Keywords available with respect to upstream. I've quoted the full texts below for reference. Regards, Edwin From https://bugzilla.redhat.com/describekeywords.cgi Keyword: MoveUpstream Bugs with this keyword are slated to be filed in the upstream bug tracker or reported to the upstream mailing list, then closed UPSTREAM on the Red Hat level. This typically includes almost all feature requests and enhancements, and most bugs that we don't consider release showstoppers. (moving a bug upstream typically increases the chance that someone will have time to look at it, and often the upstream developer or bug owner even works at Red Hat - moving things upstream simply allows us to keep everything in one place, and work better with open source community developers outside of Red Hat. We only keep bugs open on redhat.com to track our immediate short-term TODO items, or issues with our patches/packaging, or because the upstream package in question has poor bug tracking. The main focus of development for most packages is the upstream community, even when Red Hat is a big contributor to the community.) Some upstream bug trackers: http://bugzilla.gnome.org http://bugzilla.kde.org http://bugzilla.mozilla.org If a bug has this keyword, feel free to go ahead and move it upstream, add a link to the upstream report in our report, and then close the bug. Or we typically do this ourselves in batches. Keyword: Upstream This keyword means that the feature or bug fix in this bugzilla was already accepted upstream and will be inherited by a RHEL release. From https://bugzilla.redhat.com/page.cgi?id=fields.html#status Resolution: UPSTREAM This resolution should not be used for RHEL bugs. Otherwise, bugs closed with this resolution are filed in the upstream bugs tracker or reported to the upstream mailing list. This typically includes almost all feature requests and enhancements, and most bugs that we don't consider release showstoppers. (moving a bugs upstream typically increases the chance that someone will have time to look at it, and often the upstream developer or bug owner even works at Red Hat - moving things upstream simply allows us to keep everything in one place, and work better with open source community developers outside of Red Hat. We only keep bug open on redhat.com to track our immediate short-term TODO items, or issues with our patches/packaging, or because the upstream package in question has poor bug tracking. The main focus of development for most packages is the upstream community, even when Red Hat is a big contributor to the community.) Some upstream bug trackers: http://bugzilla.gnome.org http://bugs.kde.org http://bugzilla.mozilla.org. From kevin.kofler at chello.at Thu Jun 4 21:26:12 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 23:26:12 +0200 Subject: Maintainer Responsibilities References: <20090604182409.5C74361B07E@hormel.redhat.com> <4A281641.8060804@thelounge.net> Message-ID: Reindl Harald wrote: > If you want that the enduser report bugs upstream you get no repsonse > in many cases because the user will say "WTF i wanted to help and you > want to say me exactly how i have to help" and after this happens > trhee times he is frustrated and will never ever report bugs Your misunderstanding is there: it's US maintainers that are helping YOU reporters by fixing your bugs. If you think you don't need our help because you don't care about the bug anyway, we can just close it as INSUFFICIENT_DATA and stop there. Kevin Kofler From itamar at ispbrasil.com.br Thu Jun 4 21:31:08 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Thu, 4 Jun 2009 18:31:08 -0300 Subject: the end of life for flash player (HTML5) Message-ID: LOOK the end of life for flash player (HTML5) http://www.dailymotion.com/openvideodemo I am very happy to watch a video without macromedia flash. -- ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From kevin.kofler at chello.at Thu Jun 4 21:34:54 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 23:34:54 +0200 Subject: Action requested: check dist tags and conditionals References: <20090604185340.GA16703__20368.7377543703$1244141637$gmane$org@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > %if 0%{?fedora} < 10 > %endif While we are at it: Please make sure you always use 0%{?fedora}, not "%{?fedora}". The latter will do string comparisons and do the wrong thing when comparing "9" with "10" or "11". We already had a broken dependency in F9 updates because of that. So DO NOT DO THIS: %if "%{?fedora}" < "11" <-- THIS WILL NOT WORK FOR F9! do this instead: %if 0%{?fedora} < 11 Also DO NOT DO THIS: %if "%{?fedora}" > "9" <-- THIS WILL NOT WORK FOR ABOUT 40 MORE YEARS (*)! do this instead: %if 0%{?fedora} > 9 (*) assuming Fedora still exists by then ;-) and it'll break again with Fedora 100... Of course, this issue will be less pressing with F9 going EOL, but it's good to remind people of this. It'll also become an issue for %{?rhel} when we'll reach RHEL 10, which will happen in more or less 8 years if RHEL continues at its current pace. Kevin Kofler From kevin.kofler at chello.at Thu Jun 4 21:47:21 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jun 2009 23:47:21 +0200 Subject: the end of life for flash player (HTML5) References: Message-ID: Itamar Reis Peixoto wrote: > the end of life for flash player (HTML5) Unfortunately, as much as I'd like that to be true, at this point it's mostly just wishful thinking. :-( (It's good that Dailymotion is leading the way there though. It's NOT good that they're hardcoding a browser check for only Firefox though, the latest Arora which does support HTML 5 video is not recognized, that's broken!) Now we just need HTML 5 video support in Konqueror! :-) (And an entry for Firefox 3.5 in the list of fake browser IDs for crappy sites which still don't understand that sniffing user agents is broken!) That said, unfortunately, I think we'll be stuck with some sites using Flash crap for years to come. :-( Projects like Gnash and Swfdec will remain important. I agree that people should NOT install the proprietary Flash. > I am very happy to watch a video without macromedia flash. FYI, YouTube works with Gnash if you have the required codecs (but embedded YouTube videos elsewhere don't work). There's also the solution to download the videos from most of those sites using various downloaders or servicemenus, then watch them with any video player. But HTML 5 with patent-free codecs is clearly the solution we should all fight for! (But hardcoded checks for only Firefox aren't!) Kevin Kofler From sundaram at fedoraproject.org Thu Jun 4 21:49:17 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 05 Jun 2009 03:19:17 +0530 Subject: the end of life for flash player (HTML5) In-Reply-To: References: Message-ID: <4A28415D.5000707@fedoraproject.org> On 06/05/2009 03:01 AM, Itamar Reis Peixoto wrote: > LOOK > > the end of life for flash player (HTML5) > > http://www.dailymotion.com/openvideodemo > > I am very happy to watch a video without macromedia flash. It is certainly a good start but basically supported in very few browsers at this point. Not a death of Flash certainly. Atleast not yet. Rahul From jeremy at jeremysanders.net Thu Jun 4 21:56:27 2009 From: jeremy at jeremysanders.net (Jeremy Sanders) Date: Thu, 04 Jun 2009 22:56:27 +0100 Subject: Action requested: check dist tags and conditionals References: <20090604185340.GA16703__20368.7377543703$1244141637$gmane$org@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > - If you're using open ended conditionals such as: > %if 0%{?fedora} > 9 > make sure you keep in mind what will happen if %{fedora} isn't defined, > such as in the case of a derivative distribution. > > - If you're building for EPEL from a unified Fedora spec file, and have > separate %{fedora} and %{rhel} sections, make sure they do the right > things for any potential new releases, not just %{rhel} = 4 or %{rhel} = > 5. Can someone suggest how I should do this? I'm not sure who put this in my spec file! # for eggs %if 0%{?fedora} >= 8 BuildRequires: python-setuptools-devel %else BuildRequires: python-setuptools %endif Is it safe to drop the conditional now and always expect python-setup-devel to be there? Jeremy -- http://jeremysanders.net/ From a.badger at gmail.com Thu Jun 4 21:55:41 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Jun 2009 14:55:41 -0700 Subject: Maintainer Responsibilities In-Reply-To: References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> <200906031137.19294.smparrish@gmail.com> <4A275A39.4070601@freenet.de> <20090604070028.GB3712@verda-stelo.englab.brq.redhat.com> <4A27F84E.4060501@freenet.de> <20d6441a0906041156m194b5c76m95721154a5e39e77@mail.gmail.com> Message-ID: <4A2842DD.2050708@gmail.com> On 06/04/2009 01:30 PM, Kevin Kofler wrote: > Jud Craft wrote: >> Support != upstream. It's a symptom of the fact that the open source >> community is where people who create goods often don't do top-down >> support of those goods to end-users, the final recipient. >> >> Here's the problem: You all agree that end-users should seek out >> support. The reason why "they should go to upstream" is split isn't >> because Seeking Support = Bad. Seeking Support = Good. You're split >> because Having Outsiders Navigate Two/Three Layers of Community >> Indirection = Bad. > > Fixing bugs is a service we do to end users. If they don't want to use the > service the way we provide it, that's fine with me, we can just close their > stuff as INSUFFICIENT_DATA and move on. > This is where a lot of us disagree with you. There's several ways to look at this: * Maintainers are providing a service to users. Users are consuming programs. Maintainers are fixing the bugs in those programs as a service to the user. * Maintainers are providing a service to upstream. Upstream writes programs. Maintainers get their programs exposure, filter out things that aren't really bugs, help to write good bug reports, write patches to the software, etc. * Users are providing a service to the development of the program. All code has bugs. If there's bugs that you don't know about but your users are running into, they could just choose to not use it and use a different program. If they report the bug, they're trying to make the program better. I think failing to realize that all of these services are being rendered simultaneously is a grave mistake for us. We all benefit from a healthy ecosystem around bug reporting. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From pbrobinson at gmail.com Thu Jun 4 22:00:10 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 4 Jun 2009 23:00:10 +0100 Subject: Action requested: check dist tags and conditionals In-Reply-To: References: <20090604185340.GA16703__20368.7377543703$1244141637$gmane$org@nostromo.devel.redhat.com> Message-ID: <5256d0b0906041500q7e6f34a8yd544ce57d9b06e6f@mail.gmail.com> >> - If you're using open ended conditionals such as: >> %if 0%{?fedora} > 9 >> ? make sure you keep in mind what will happen if %{fedora} isn't defined, >> ? such as in the case of a derivative distribution. >> >> - If you're building for EPEL from a unified Fedora spec file, and have >> ? separate %{fedora} and %{rhel} sections, make sure they do the right >> ? things for any potential new releases, not just %{rhel} = 4 or %{rhel} = >> ? 5. > > Can someone suggest how I should do this? I'm not sure who put this in my > spec file! > > # for eggs > %if 0%{?fedora} >= 8 > BuildRequires: ?python-setuptools-devel > %else > BuildRequires: ?python-setuptools > %endif > > Is it safe to drop the conditional now and always expect python-setup-devel > to be there? If the fedora release is no longer supported its safe to drop. In the case of Fedora 8 its no longer a supported release so its now safe to drop the requirement. Peter From notting at redhat.com Thu Jun 4 22:00:37 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 4 Jun 2009 18:00:37 -0400 Subject: Action requested: check dist tags and conditionals In-Reply-To: References: <20090604185340.GA16703__20368.7377543703$1244141637$gmane$org@nostromo.devel.redhat.com> Message-ID: <20090604220037.GA30383@nostromo.devel.redhat.com> Jeremy Sanders (jeremy at jeremysanders.net) said: > Can someone suggest how I should do this? I'm not sure who put this in my > spec file! > > # for eggs > %if 0%{?fedora} >= 8 > BuildRequires: python-setuptools-devel > %else > BuildRequires: python-setuptools > %endif > > Is it safe to drop the conditional now and always expect python-setup-devel > to be there? If you're not building for EPEL 4/5, yes. Bill From pbrobinson at gmail.com Thu Jun 4 22:01:49 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 4 Jun 2009 23:01:49 +0100 Subject: Action requested: check dist tags and conditionals In-Reply-To: <20090604220037.GA30383@nostromo.devel.redhat.com> References: <20090604185340.GA16703__20368.7377543703$1244141637$gmane$org@nostromo.devel.redhat.com> <20090604220037.GA30383@nostromo.devel.redhat.com> Message-ID: <5256d0b0906041501r32f88ed0td116ff33b58f3ffa@mail.gmail.com> >> Can someone suggest how I should do this? I'm not sure who put this in my >> spec file! >> >> # for eggs >> %if 0%{?fedora} >= 8 >> BuildRequires: ?python-setuptools-devel >> %else >> BuildRequires: ?python-setuptools >> %endif >> >> Is it safe to drop the conditional now and always expect python-setup-devel >> to be there? > > If you're not building for EPEL 4/5, yes. Do EPEL pick up the fedora >= 8 conditional? Peter From mjg at redhat.com Thu Jun 4 22:04:19 2009 From: mjg at redhat.com (Matthew Garrett) Date: Thu, 4 Jun 2009 23:04:19 +0100 Subject: Maintainer Responsibilities In-Reply-To: References: <20090604182409.5C74361B07E@hormel.redhat.com> <4A281641.8060804@thelounge.net> Message-ID: <20090604220419.GA12476@srcf.ucam.org> On Thu, Jun 04, 2009 at 11:26:12PM +0200, Kevin Kofler wrote: > Reindl Harald wrote: > > If you want that the enduser report bugs upstream you get no repsonse > > in many cases because the user will say "WTF i wanted to help and you > > want to say me exactly how i have to help" and after this happens > > trhee times he is frustrated and will never ever report bugs > > Your misunderstanding is there: it's US maintainers that are helping YOU > reporters by fixing your bugs. If you think you don't need our help because > you don't care about the bug anyway, we can just close it as > INSUFFICIENT_DATA and stop there. Careful with that "we". I'd rather have a large list of open but low priority and difficult to reproduce bugs than have users who never bother reporting bugs in the first place - I may never get round to fixing them myself, but having that bug open makes it easier for other people who hit the same issue to determine that it is a bug and perhaps save themselves some time. And if it ever does get fixed, then that's even better. Flagging it closed means that's less likely to happen, and the quality of the software that we ship (and, as a result, the perceived usefulness of Fedora) is lower as a result. -- Matthew Garrett | mjg59 at srcf.ucam.org From gmaxwell at gmail.com Thu Jun 4 22:09:32 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Thu, 4 Jun 2009 18:09:32 -0400 Subject: the end of life for flash player (HTML5) In-Reply-To: References: Message-ID: On Thu, Jun 4, 2009 at 5:47 PM, Kevin Kofler wrote: [snip] > the way there though. It's NOT good that they're hardcoding a browser check > for only Firefox though, Don't worry, plenty of people have pointed out that it isn't the way to go. HTML 5 video provides the right tools for querying for support for not only the video tag itself but for supported codecs. Some of that wasn't there in the earlier firefox betas, which probably encouraged the use of simple useragent based checking. It's there now. > the latest Arora which does support HTML 5 video > is not recognized, that's broken!) The string "video" doesn't occur anywhere in the current Arora git. Can you point me to more information? In testing I find that a couple of problems: (1) it appears the it doesn't begin until it has completely transferred the file(?) (2) audio plays but video does not (3) seeking does nothing Here is a simple example that queries the browser for support, and if HTML 5 video isn't supported it falls back to using the Java player: http://www.celt-codec.org/presentations/ Thanks! From kevin.kofler at chello.at Thu Jun 4 22:24:20 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 05 Jun 2009 00:24:20 +0200 Subject: Action requested: check dist tags and conditionals References: <20090604185340.GA16703__20368.7377543703$1244141637$gmane$org@nostromo.devel.redhat.com> Message-ID: Jeremy Sanders wrote: > %if 0%{?fedora} >= 8 That should be: %if 0%{?fedora} >= 8 || 0%{?rhel} >= 6 Kevin Kofler From kevin.kofler at chello.at Thu Jun 4 22:36:33 2009 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 05 Jun 2009 00:36:33 +0200 Subject: the end of life for flash player (HTML5) References: Message-ID: Gregory Maxwell wrote: > The string "video" doesn't occur anywhere in the current Arora git. > Can you point me to more information? See QtWebKit, which is part of Qt >= 4.4 and supports HTML 5 video in Qt >= 4.5. Arora uses QtWebKit. > In testing I find that a couple of problems: > (1) it appears the it doesn't begin until it has completely > transferred the file(?) > (2) audio plays but video does not > (3) seeking does nothing QtWebKit's HTML 5 support apparently needs a lot of improvement. :-( One issue is that there are multiple Phonon backends (Phonon is the Qt multimedia framework, which QtWebKit uses for video playback), Qt Software doesn't test with the xine-lib backend which is the default in KDE, whereas the developers of Amarok and some other KDE apps recommend only the xine-lib backend and test primarily with that one. There are also other technical issues with the GStreamer backend, i.e. the one which Qt Software recommends (whereas the Amarok developers say it's extremely buggy and should never be the default), which prevent us from making it the default (the bugs with Amarok, but also issues with how output selection is implemented, they use a backend-specific "GStreamer sink" setting in addition to the standard output device setting in the Phonon API, with the result that, last I checked, it didn't work out of the box with our default PulseAudio setup). Kevin Kofler From naheemzaffar at gmail.com Thu Jun 4 22:41:48 2009 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Thu, 4 Jun 2009 23:41:48 +0100 Subject: the end of life for flash player (HTML5) In-Reply-To: References: Message-ID: <3adc77210906041541n5d7977ebg2f8b28953db7e889@mail.gmail.com> 2009/6/4 Kevin Kofler > Unfortunately, as much as I'd like that to be true, at this point it's > mostly just wishful thinking. :-( Maybe, but there are real business reasons for investigating such alternatives. But HTML 5 with patent-free codecs is clearly the solution we should all > fight for! (But hardcoded checks for only Firefox aren't!) Yes, and the most popular patent encumbered format will soon no longer be free for online content distributors (according to http://www.mpegla.com/avc/AVC_TermsSummary.pdf, the free ride will end on 31 December 2010). That should IMO create some momentum to move to other formats, as a per title cost could be prohibitively high. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at ausil.us Thu Jun 4 22:45:52 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 4 Jun 2009 17:45:52 -0500 Subject: Action requested: check dist tags and conditionals In-Reply-To: <5256d0b0906041501r32f88ed0td116ff33b58f3ffa@mail.gmail.com> References: <20090604185340.GA16703__20368.7377543703$1244141637$gmane$org@nostromo.devel.redhat.com> <20090604220037.GA30383@nostromo.devel.redhat.com> <5256d0b0906041501r32f88ed0td116ff33b58f3ffa@mail.gmail.com> Message-ID: <200906041745.58100.dennis@ausil.us> On Thursday 04 June 2009 05:01:49 pm Peter Robinson wrote: > >> Can someone suggest how I should do this? I'm not sure who put this in > >> my spec file! > >> > >> # for eggs > >> %if 0%{?fedora} >= 8 > >> BuildRequires: python-setuptools-devel > >> %else > >> BuildRequires: python-setuptools > >> %endif > >> > >> Is it safe to drop the conditional now and always expect > >> python-setup-devel to be there? > > > > If you're not building for EPEL 4/5, yes. > > Do EPEL pick up the fedora >= 8 conditional? > > Peter epel defines a %{rhel} macro to 4 or 5 when rhel6 comes whenever that is hopefully it will have defined in redhat-release the macros defineing %{rhel} = 6 probably a better way to do the above example is %if 0%{?fedora} <= 8 || 0%{?rhel} <= 5 BuildRequires: python-setuptools %else BuildRequires: python-setuptools-devel %endif that way if the macros are not defined the newer package is required not the older way. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From hugh at mimosa.com Fri Jun 5 00:09:35 2009 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Thu, 4 Jun 2009 20:09:35 -0400 (EDT) Subject: Static system level uid/gid's reservations in Fedora/RHEL - how to handle situation? In-Reply-To: <20090429153048.GC4323@nostromo.devel.redhat.com> References: <1240902265.3858.11.camel@dhcp-lab-219.englab.brq.redhat.com> <20090429153048.GC4323@nostromo.devel.redhat.com> Message-ID: | Date: Wed, 29 Apr 2009 11:30:48 -0400 | From: Bill Nottingham | Ond?ej Va??k (ovasik at redhat.com) said: | > What's the best way to handle that situation? One possibility is to | > increase the threshold of system level id's (to 200? 300?), another is | > to check current reservation and clean long-term unused reservations (I | > doubt there are many such cases, so it's only temporary solution). Other | > could be sharing groups (as static uid's are still available), but | > that's not always good solution. | > | > Any other idea or some prefered solution? | | Simplest way is to bump the lowest number that's used for system IDs; | that may run into some collisions on older systems, though. I just thought I'd grumble here. In 1983, I assigned really high UIDs to my users (my family) on the first UNIX box I owned. 100 and up. I really wanted the UIDs to be the same on all my boxes. A couple of years ago, I tried Ubuntu. It would not let me keep those numbers. But Fedora would, with effort. I gave up and renumbered on my newest boxes. It sure is a pain today when I'm trying to use NFS between an old box and a new one. I think that Sun supports UID mapping on NFS but Linux does not. It is also annoying when I move disks between systems. I guess I could use FAT :-) From khc at pm.waw.pl Fri Jun 5 00:55:53 2009 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Fri, 05 Jun 2009 02:55:53 +0200 Subject: F11 discontinued so fast? :-) In-Reply-To: <1244144653.2876.35.camel@localhost.localdomain> (Jesse Keating's message of "Thu\, 04 Jun 2009 12\:44\:13 -0700") References: <1244144653.2876.35.camel@localhost.localdomain> Message-ID: Jesse Keating writes: >> /pub/fedora/linux/releases/11/Fedora/x86_64/iso/ on this server. > > The directory was open by mistake. We're not fully staged for the > release yet. I was sure about that, note the smile. The question was mainly about the (not working) ErrorDocument, i.e., httpd configuration. -- Krzysztof Halasa From notting at redhat.com Fri Jun 5 00:55:35 2009 From: notting at redhat.com (Bill Nottingham) Date: Thu, 4 Jun 2009 20:55:35 -0400 Subject: Action requested: check dist tags and conditionals In-Reply-To: <5256d0b0906041501r32f88ed0td116ff33b58f3ffa@mail.gmail.com> References: <20090604185340.GA16703__20368.7377543703$1244141637$gmane$org@nostromo.devel.redhat.com> <20090604220037.GA30383@nostromo.devel.redhat.com> <5256d0b0906041501r32f88ed0td116ff33b58f3ffa@mail.gmail.com> Message-ID: <20090605005535.GA32347@nostromo.devel.redhat.com> Peter Robinson (pbrobinson at gmail.com) said: > >> Is it safe to drop the conditional now and always expect python-setup-devel > >> to be there? > > > > If you're not building for EPEL 4/5, yes. > > Do EPEL pick up the fedora >= 8 conditional? Not as far as I know - that would make the earlier mentioned use of using it for choosing build requirements not work. Bill From khc at pm.waw.pl Fri Jun 5 01:20:23 2009 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Fri, 05 Jun 2009 03:20:23 +0200 Subject: F11 discontinued so fast? :-) In-Reply-To: (Krzysztof Halasa's message of "Fri\, 05 Jun 2009 02\:55\:53 +0200") References: <1244144653.2876.35.camel@localhost.localdomain> Message-ID: > The question was mainly about the (not working) ErrorDocument, i.e., > httpd configuration. OTOH it's interesting: http://download.fedora.redhat.com/pub/fedora/linux/releases/11/ - no problem ("no permission" only). http://download.fedora.redhat.com/pub/fedora/linux/releases/11/Fedora/ - "Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request." -- Krzysztof Halasa From a.badger at gmail.com Thu Jun 4 23:13:29 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Jun 2009 16:13:29 -0700 Subject: Action requested: check dist tags and conditionals In-Reply-To: References: <20090604185340.GA16703__20368.7377543703$1244141637$gmane$org@nostromo.devel.redhat.com> Message-ID: <4A285519.3070706@gmail.com> On 06/04/2009 01:11 PM, Julian Sikorski wrote: > Bill Nottingham pisze: >> (If you've never used a construct like "%if 0%{?fedora}" in your spec >> file, you can disregard this message.) >> >> Many packages in Fedora use release-based conditionals such as: >> >> ... >> %if 0%{?rhel} >> %endif >> >> %if 0%{?fedora} < 10 >> %endif >> >> %{?fedora:%global _with_xfce --with-xfce} >> ... >> >> I'd just like to remind people of the following: >> >> - If you're using open ended conditionals such as: >> %if 0%{?fedora} > 9 >> make sure you keep in mind what will happen if %{fedora} isn't defined, >> such as in the case of a derivative distribution. >> >> - If you're building for EPEL from a unified Fedora spec file, and have >> separate %{fedora} and %{rhel} sections, make sure they do the right >> things for any potential new releases, not just %{rhel} = 4 or %{rhel} = 5. >> Does this look like the right generic structure for doing this: %if 0%{?fedora} >= X || 0%{?rhel} >= Y # Do things from X until Current Fedora, Y until Current RHEL # Y should be the latest released version if we don't know that # it's not going to change in the next version %else %if %{fedora} && 0%{fedora} < X && ! %{rhel} # Do things for Fedora < X %else %if ! %{fedora} && %{rhel} && 0%{rhel} < Y # Do things for RHEL < Y %else # Do things for any other distros %endif %endif %endif If so, then we'd want to prettify and codify it a bit so we can put it in the Packaging Guidelines > This is often used to tailor BuildRequires, I can't take responsibility > what a given release of a derivative distro does or doesn't include. > So we could just decide that derivative distros include those things unless proven wrong. Note that that seems to make my final %else above wrong.... -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From poelstra at redhat.com Fri Jun 5 02:29:07 2009 From: poelstra at redhat.com (John Poelstra) Date: Thu, 04 Jun 2009 19:29:07 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <1243880066.29188.20.camel@localhost.localdomain> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> Message-ID: <4A2882F3.10001@redhat.com> Jesse Keating said the following on 06/01/2009 11:14 AM Pacific Time: > On Mon, 2009-06-01 at 19:49 +0200, Thorsten Leemhuis wrote: >> - why do we have to slip by a whole week most of the time? can't we find >> ways to slip just a day or two if there really is no way around a delay? > > The marketing machine has very strongly requested that we only do > releases on Tuesdays. > Seeking clarification... From my perspective, "marketing machine" has a derogatory tone to it. Is that the intended tone? If, "yes," why? If "no," never mind :) John From jkeating at redhat.com Fri Jun 5 03:01:40 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 04 Jun 2009 20:01:40 -0700 Subject: Announcing Fedora Activity Day - Fedora Development Cycle 2009 In-Reply-To: <4A2882F3.10001@redhat.com> References: <1243630631.3037.149.camel@localhost.localdomain> <4A2414B8.2000907@leemhuis.info> <1243880066.29188.20.camel@localhost.localdomain> <4A2882F3.10001@redhat.com> Message-ID: <1244170900.2876.39.camel@localhost.localdomain> On Thu, 2009-06-04 at 19:29 -0700, John Poelstra wrote: > Seeking clarification... From my perspective, "marketing machine" has a > derogatory tone to it. Is that the intended tone? > > If, "yes," why? If "no," never mind :) > There was no derogatory tone intended. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From h.reindl at thelounge.net Fri Jun 5 03:06:56 2009 From: h.reindl at thelounge.net (Reindl Harald) Date: Fri, 05 Jun 2009 05:06:56 +0200 Subject: Maintainer Responsibilities In-Reply-To: <20090604224624.B9DB261B725@hormel.redhat.com> References: <20090604224624.B9DB261B725@hormel.redhat.com> Message-ID: <4A288BD0.7000807@thelounge.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Message: 1 > Date: Thu, 04 Jun 2009 23:26:12 +0200 > From: Kevin Kofler > Subject: Re: Maintainer Responsibilities > To: fedora-devel-list at redhat.com > Message-ID: > Content-Type: text/plain; charset=us-ascii > Your misunderstanding is there: it's US maintainers that are helping YOU > reporters by fixing your bugs. If you think you don't need our help because > you don't care about the bug anyway, we can just close it as > INSUFFICIENT_DATA and stop there. > > Kevin Kofler YOU missunderstand You really believe a normal user ever registers at bugzilla for every piece of software he uses? The truth is the MOST upstream-bugzillas are fu**ing ignored and/or arrogant and thats the reason why i gave up in the meantime because i have better things to do as registering and be ignored or in the best cases i must discuss per private mail that some stupid upstream-developer repopens a bug after understanding "oh yes this is really a bug" PHP: http://bugs.php.net/bug.php?id=42836 Bogus? Not a problem in php when it mixes per-host-configuration? I'm php-developer and serveradmin for long enough to be sure that this IS a bug OK PHP6 is pre-alpha but thats not the point - how will tey get away them They do not need help? the do not got help upstream any longer You can be sure if a @redhat.com-address or a known maintainer reports this it would not be closed as "bogus". For unknown users the developers have a reflex "close as soon as possible" PHP: http://bugs.php.net/bug.php?id=42077 Closed with "read why there in the archive" and at this time you could not comment a closed bug and you hace to mail this crazy peopole until he understands this is a bug - sorry but if this would not be a showstopper for our whole company if released this way i would se "leave me fuck in peace and do what you want" Firefox: I NEVER got any response from upstream bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=495196 I do not like to search older ones but if i trie to report bugs there should be any response and i got never ever any response from firefox-bugzilla eaccelerator: http://eaccelerator.net/ticket/307 WTF - New snapshot introduces a new problem, repoorted a year ago, a workaround is no solution and its not really funny to get ignored in such way ffmpeg-php https://sourceforge.net/tracker/?func=detail&aid=2017954&group_id=122353&atid=693224 does not compile after ffmpeg-upgrade from livna, livna-bugtracker told i should make a bugreport against upstream and they ignores it since nearly a year, some other reporters got "svn has fixes" but svn-version also not compiles _____________________________ Only in the last 2 years i can search a lot of such frustrating things and only the time spent for registering in the bugzillas should be used for drink some beer to make more sense and yes it is a BIG different if a nobody or a well known maintainer from a distribution reports something upstream So please leave me in peace with "report upstream" and take the love for the software and help from users that way they are able and willing to give or you lose them in many cases with no response in rh-bugzilla AND do not get the bug reported upstream -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkooi9AACgkQhmBjz394AnnT1QCglPGy7GBT8AfmAC/XIsXOKyQM ayAAn2xp4iRoeRcJsEUcgBSdMMuZ28eN =nhRF -----END PGP SIGNATURE----- From jonathan at jonmasters.org Fri Jun 5 04:21:09 2009 From: jonathan at jonmasters.org (Jon Masters) Date: Fri, 05 Jun 2009 00:21:09 -0400 Subject: Some pulseaudio questions... Message-ID: <1244175669.11597.19.camel@localhost.localdomain> Folks, Anyone want to clarify my understanding of PA's use of mlock/posix_madvise? From looking over the code - in particular pa_will_need, and its callsites - it looks like PA doesn't really use this support that it has for locking pages. Which seems weird. I'll admit I'm about ready to hack in some horrible mlockall hacks to see if that'll stop the poppy/skippyness on this box. Jon. From jkeating at redhat.com Fri Jun 5 05:09:49 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 04 Jun 2009 22:09:49 -0700 Subject: Rawhide moving on to Fedora 12 content Message-ID: <1244178589.2876.48.camel@localhost.localdomain> I've made the switch tonight so that rawhide will be Fedora 12 content. This will cause a huge number of updates, if the compose actually finishes, and will finish quite late. For the next few days, attempts to use mirror manager for the Fedora 11 repo will fail. This is something we hope to fix at the Fedora Activity Day next week. Thanks for putting up with the delays as we try to get Fedora 11 out the door! -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From bill at bfccomputing.com Fri Jun 5 05:28:59 2009 From: bill at bfccomputing.com (Bill McGonigle) Date: Fri, 05 Jun 2009 01:28:59 -0400 Subject: Static system level uid/gid's reservations in Fedora/RHEL - how to handle situation? In-Reply-To: <1240902265.3858.11.camel@dhcp-lab-219.englab.brq.redhat.com> References: <1240902265.3858.11.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <4A28AD1B.4000903@bfccomputing.com> On 04/28/2009 03:04 AM, Ond?ej Va??k wrote: > What's the best way to handle that situation? One possibility is to > increase the threshold of system level id's (to 200? 300?) I guess I've been blissfully ignorant and always assumed that id's under 500 were reserved for system use since Redhat systems have always created the first user uid as 500. Other admins I've worked with have been similarly misinformed, so you might get lucky here. I wonder if a check for uid's between 100 and 500 could be added to smolt. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill at bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From jan.klepek at brandforge.sk Fri Jun 5 06:30:49 2009 From: jan.klepek at brandforge.sk (Jan Klepek) Date: Fri, 05 Jun 2009 08:30:49 +0200 Subject: package review questions Message-ID: <1244183449.24795.2.camel@localhost.localdomain> Hi, I'm working on unofficial package review for redmine ( https://bugzilla.redhat.com/show_bug.cgi?id=499959 ). Redmine is written in ruby and is using rubygem-actionwebservice, which is shipped with redmine. Rubygem-actionwebservice was abandoned by upstream like two years ago, and same happened for fedora package. My question is if redmine package should install it on system or it should be considered as blocker, until upstream of redmine migrate to activeresource. Second question is when redmine contains plugins which are separate applications/libraries (coderay is used by redmine for example) this applications/libraries should be shipped within this package or should be shipped in it's own package (and package should be created when it doesn't exists)? My thoughts are that it should be shipped separately, so it could be used by more applications. Thanks for help, Jan Klepek From dchen at redhat.com Fri Jun 5 07:17:34 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Fri, 05 Jun 2009 17:17:34 +1000 Subject: Maintainer Responsibilities In-Reply-To: <4A275A39.4070601@freenet.de> References: <200906021617.12122.sgrubb@redhat.com> <200906021817.04327.smparrish@gmail.com> <200906031001.58178.sgrubb@redhat.com> <200906031137.19294.smparrish@gmail.com> <4A275A39.4070601@freenet.de> Message-ID: <1244186254.4634.10.camel@dhcp-0-207.bne.redhat.com> ? ??2009-06-04 ? 07:23 +0200?Ralf Corsepius ??? > Steven M. Parrish wrote: > > > Many people have mentioned that it is not right to ask the users to file their > > bug reports upstream. I ask why not? > > Let me summarize what I already wrote elsewhere in this thread: > * Users aren't necessarily developers. > * Users aren't necessarily interested in getting involved upstream. > * Users are reporting bugs against your product (your package in > Fedora), not against upstream's work (somebody else's product). > > > Let me try an analogy: How do you handle defects/malfunctions with your > car? > > You'll visit your car dealer/a garage and report the issue to them. > You'll expect them to identify the problem and to take appropriate steps > to solve your issue. You don't expect them to direct you to the car's > manufacturer or a component manufacturer and to discuss technical > details you have no knowledge about with them ("Is the stuttering engine > cause by triac 7 in a component A you haven't heard about before" or by > the hall sensor in component B you also haven't heard about before). Using your analogy: If the car workshop does not have sufficient knowledge and material, yes, that's right, the parts are ordered from upstream (the car manufacturer). If you want to, say, make a suggestion for your Ford, giving the suggestion to the car workshop does not help much, unless it is one of Ford's branch. Some bugs need to go upstream, some bugs need not. > Ralf > -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From jreznik at redhat.com Fri Jun 5 07:48:09 2009 From: jreznik at redhat.com (Jaroslav Reznik) Date: Fri, 5 Jun 2009 09:48:09 +0200 Subject: the end of life for flash player (HTML5) In-Reply-To: References: Message-ID: <200906050948.09656.jreznik@redhat.com> On Jueves 04 Junio 2009 23:47:21 Kevin Kofler escribi?: > Itamar Reis Peixoto wrote: > > the end of life for flash player (HTML5) > > Unfortunately, as much as I'd like that to be true, at this point it's > mostly just wishful thinking. :-( (It's good that Dailymotion is leading > the way there though. It's NOT good that they're hardcoding a browser check > for only Firefox though, the latest Arora which does support HTML 5 video > is not recognized, that's broken!) I was really surprised - hardcoded download of FF 3.5 :( > Now we just need HTML 5 video support in Konqueror! :-) (And an entry for > Firefox 3.5 in the list of fake browser IDs for crappy sites which still > don't understand that sniffing user agents is broken!) > > That said, unfortunately, I think we'll be stuck with some sites using > Flash crap for years to come. :-( Projects like Gnash and Swfdec will > remain important. I agree that people should NOT install the proprietary > Flash. Mostly it depends on YouTube - it's 90% of all Flash content for me. So if YouTube (and p0rn variants :D) adopts