From buildsys at fedoraproject.org Mon Jan 1 01:17:02 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 31 Dec 2006 20:17:02 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-31 Message-ID: <20070101011702.6C14715212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): autofs FC6-updates > FC7 (1:5.0.1-0.rc2.40 > 1:5.0.1-0.rc2.38) dbus FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) andreas.bierfert AT lowlatency.de: wine-docs FE3 > FE4 (0:0.9.27-1.fc3 > 0:0.9.24-1.fc4) cgoorah AT yahoo.com.au: ngspice FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-7.fc6 > 0:1.4.2.cvs20060817-5.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) roozbeh AT farsiweb.info: pyfribidi FE5 > FE6 (0:0.6.0-3.fc5 > 0:0.6.0-2.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) ---------------------------------------------------------------------- autofs: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:5.0.1-0.rc2.40 > 1:5.0.1-0.rc2.38) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-7.fc6 > 0:1.4.2.cvs20060817-5.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) ngspice: cgoorah AT yahoo.com.au FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) pyfribidi: roozbeh AT farsiweb.info FE5 > FE6 (0:0.6.0-3.fc5 > 0:0.6.0-2.fc6) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) wine-docs: andreas.bierfert AT lowlatency.de FE3 > FE4 (0:0.9.27-1.fc3 > 0:0.9.24-1.fc4) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From dennis at ausil.us Mon Jan 1 17:12:52 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 1 Jan 2007 11:12:52 -0600 Subject: Extras Buildsys Message-ID: <200701011112.57790.dennis@ausil.us> Just a note to all, the buildsys no longer accepts jobs for Extras for FC-3 and FC-4 -- Dennis Gilmore, RHCE Proud Australian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Mon Jan 1 18:58:50 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Jan 2007 12:58:50 -0600 Subject: Extras Buildsys In-Reply-To: <200701011112.57790.dennis@ausil.us> References: <200701011112.57790.dennis@ausil.us> Message-ID: >>>>> "DG" == Dennis Gilmore writes: DG> Just a note to all, the buildsys no longer accepts jobs for Extras DG> for FC-3 and FC-4 Since that's the case, perhaps we could trim FC3 and FC4 from the EVR problem report. There now seems to be no possibility of fixing those issues. I think we got all of the FC3 and FC4 broken rep's fixed, so there shouldn't be problems with that report. - J< > LocalWords: EVR From kevin at tummy.com Mon Jan 1 19:32:37 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 1 Jan 2007 12:32:37 -0700 Subject: Extras Buildsys In-Reply-To: References: <200701011112.57790.dennis@ausil.us> Message-ID: <20070101123237.6cc16990@ningauble.scrye.com> On 01 Jan 2007 12:58:50 -0600 tibbs at math.uh.edu (Jason L Tibbitts III) wrote: > >>>>> "DG" == Dennis Gilmore writes: > > DG> Just a note to all, the buildsys no longer accepts jobs for Extras > DG> for FC-3 and FC-4 > > Since that's the case, perhaps we could trim FC3 and FC4 from the EVR > problem report. There now seems to be no possibility of fixing those > issues. Yeah, that leaves us with in extras: andreas.bierfert AT lowlatency.de: wine-docs FE3 > FE4 (0:0.9.27-1.fc3 > 0:0.9.24-1.fc4) In core there is: device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) xen FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) > > I think we got all of the FC3 and FC4 broken rep's fixed, so there > shouldn't be problems with that report. Yeah, none there that I know of. > > - J< Two other end of life issues someone needs to address: - Is someone going to close all the legacy/FE/FC <5 bugs in bugzilla? Looks like there are 77 or so for fe3/fe4. Around 841 in fc1/fc2/fc3/fc4 Around 107 in legacy. - I seem to remember that the infrastructure team was for some reason using some fc/fe3 packages on the builders or other infrastructure machines. Can we make sure those get branched/maintained for epel and any machines switched to those new packages? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Mon Jan 1 19:48:33 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 1 Jan 2007 21:48:33 +0200 Subject: Extras Buildsys In-Reply-To: References: <200701011112.57790.dennis@ausil.us> Message-ID: <200701012148.34087.ville.skytta@iki.fi> On Monday 01 January 2007 20:58, Jason L Tibbitts III wrote: > >>>>> "DG" == Dennis Gilmore writes: > > DG> Just a note to all, the buildsys no longer accepts jobs for Extras > DG> for FC-3 and FC-4 > > Since that's the case, perhaps we could trim FC3 and FC4 from the EVR > problem report. There now seems to be no possibility of fixing those > issues. FC3 trimmed, but FC4 needs to stay so it catches issues possibly present/introduced in FC5+ which need to be fixed in those distros anyway. From a.badger at gmail.com Mon Jan 1 19:53:47 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 01 Jan 2007 11:53:47 -0800 Subject: Extras Buildsys In-Reply-To: <20070101123237.6cc16990@ningauble.scrye.com> References: <200701011112.57790.dennis@ausil.us> <20070101123237.6cc16990@ningauble.scrye.com> Message-ID: <1167681227.3248.13.camel@localhost.localdomain> On Mon, 2007-01-01 at 12:32 -0700, Kevin Fenzi wrote: > On 01 Jan 2007 12:58:50 -0600 > tibbs at math.uh.edu (Jason L Tibbitts III) wrote: > > > >>>>> "DG" == Dennis Gilmore writes: > > > > DG> Just a note to all, the buildsys no longer accepts jobs for Extras > > DG> for FC-3 and FC-4 > > > > Since that's the case, perhaps we could trim FC3 and FC4 from the EVR > > problem report. There now seems to be no possibility of fixing those > > issues. > > Yeah, that leaves us with in extras: > > andreas.bierfert AT lowlatency.de: > wine-docs > FE3 > FE4 (0:0.9.27-1.fc3 > 0:0.9.24-1.fc4) > This is held up on this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179852 wine-docs on FC-4 is out of sync with the other wine packages as well: The wine-docs rpm from FC-3 is actually a better match for the FC-4 wine than the older wine-docs. > > Two other end of life issues someone needs to address: > > - Is someone going to close all the legacy/FE/FC <5 bugs in bugzilla? > > Looks like there are 77 or so for fe3/fe4. > Around 841 in fc1/fc2/fc3/fc4 > Around 107 in legacy. > IMHO, it would be best if the package maintainer does this. Look at the open bugs on your packages. Decide whether to push them forward, close them, or mark them NEEDINFO so that the bug reporter has the opportunity to push them forward (like Davej's treatment of kernel bugs.) > - I seem to remember that the infrastructure team was for some reason > using some fc/fe3 packages on the builders or other infrastructure > machines. Can we make sure those get branched/maintained for epel and > any machines switched to those new packages? > Machines which are using RHEL4 (Most everything except the builders) were using fe/fc3 packages when necessary. epel will be a better fit for these cases and we've started using this now... We haven't completely converted yet, though. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kevin at tummy.com Mon Jan 1 20:23:45 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 1 Jan 2007 13:23:45 -0700 Subject: bugzilla bugs for < fc5 (was Re: Extras Buildsys) In-Reply-To: <1167681227.3248.13.camel@localhost.localdomain> References: <200701011112.57790.dennis@ausil.us> <20070101123237.6cc16990@ningauble.scrye.com> <1167681227.3248.13.camel@localhost.localdomain> Message-ID: <20070101132345.4824d52b@ningauble.scrye.com> On Mon, 01 Jan 2007 11:53:47 -0800 a.badger at gmail.com (Toshio Kuratomi) wrote: > > > > Two other end of life issues someone needs to address: > > > > - Is someone going to close all the legacy/FE/FC <5 bugs in > > bugzilla? > > > > Looks like there are 77 or so for fe3/fe4. > > Around 841 in fc1/fc2/fc3/fc4 > > Around 107 in legacy. > > > IMHO, it would be best if the package maintainer does this. Look at > the open bugs on your packages. Decide whether to push them forward, > close them, or mark them NEEDINFO so that the bug reporter has the > opportunity to push them forward (like Davej's treatment of kernel > bugs.) I suspect that many people won't do so for whatever reason, and we will be left with bugs where people expect responses and never get them. Thats just not good IMHO. I think someone doing a blanket 'This release is no longer supported, can you retest with fc6 and re-file if it is still an issue' and closing the bug would be better. All just my opinion. ;) Also, can someone disable reporting new bugs against those older releases? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Mon Jan 1 20:32:37 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Jan 2007 14:32:37 -0600 Subject: Extras Buildsys In-Reply-To: <200701012148.34087.ville.skytta@iki.fi> References: <200701011112.57790.dennis@ausil.us> <200701012148.34087.ville.skytta@iki.fi> Message-ID: >>>>> "VS" == Ville Skytt? writes: VS> FC3 trimmed, but FC4 needs to stay so it catches issues possibly VS> present/introduced in FC5+ which need to be fixed in those distros VS> anyway. I realize that I had really only intended to say that problems between FC3 and FC4 should be trimmed; it's still quite possible to fix problems where, say, FC3 > FC5 by updating FC5. But for core packages I think it's pretty obvious now that FC5 updates to fix these problems aren't going to happen anyway. - J< From buildsys at fedoraproject.org Mon Jan 1 20:53:35 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 1 Jan 2007 15:53:35 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-01-01 Message-ID: <20070101205335.2524915212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): autofs FC6-updates > FC7 (1:5.0.1-0.rc2.40 > 1:5.0.1-0.rc2.38) dbus FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) cgoorah AT yahoo.com.au: ngspice FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-7.fc6 > 0:1.4.2.cvs20060817-5.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) ---------------------------------------------------------------------- autofs: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:5.0.1-0.rc2.40 > 1:5.0.1-0.rc2.38) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-7.fc6 > 0:1.4.2.cvs20060817-5.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) ngspice: cgoorah AT yahoo.com.au FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From bugs.michael at gmx.net Mon Jan 1 21:16:47 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 1 Jan 2007 22:16:47 +0100 Subject: Extras Buildsys In-Reply-To: <1167681227.3248.13.camel@localhost.localdomain> References: <200701011112.57790.dennis@ausil.us> <20070101123237.6cc16990@ningauble.scrye.com> <1167681227.3248.13.camel@localhost.localdomain> Message-ID: <20070101221647.24ea6985.bugs.michael@gmx.net> On Mon, 01 Jan 2007 11:53:47 -0800, Toshio Kuratomi wrote: > > Yeah, that leaves us with in extras: > > > > andreas.bierfert AT lowlatency.de: > > wine-docs > > FE3 > FE4 (0:0.9.27-1.fc3 > 0:0.9.24-1.fc4) > > > This is held up on this bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179852 > > wine-docs on FC-4 is out of sync with the other wine packages as well: > The wine-docs rpm from FC-3 is actually a better match for the FC-4 wine > than the older wine-docs. I've fixed that by copying FC-3 wine-docs to FC-4. It's noarch. The buildsys has failed to build wine-docs for FC-4 for a long time (above bug), and only a work-around managed to get it built until a new build problem turnt up recently. It is not worth doing anything else in this matter. Well, unless the problem returns for a target > FC-4 or RHEL. FE-3 and FE-4 have been pruned to just the latest package release. Only in FE-3 there are six packages from pre-"Fedora Extras 3" which differ in %release for i386 and x86_64 because of manual builds, and hence there are two srpms for them. From a.badger at gmail.com Tue Jan 2 07:17:57 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 01 Jan 2007 23:17:57 -0800 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <200612311042.02906.jkeating@redhat.com> References: <45951F62.4020302@leemhuis.info> <200612291119.57073.jkeating@redhat.com> <1167565930.14707.42.camel@localhost.localdomain> <200612311042.02906.jkeating@redhat.com> Message-ID: <1167722277.2436.21.camel@localhost.localdomain> On Sun, 2006-12-31 at 10:42 -0500, Jesse Keating wrote: > On Sunday 31 December 2006 06:52, Callum Lerwick wrote: > > Which is the whole idea of my checklist. It follows the MUST list > > basically point-for-point. (Some related stuff gets mushed together into > > one item, like everything relating to %file lists, and directory/file > > ownership.) Everything in the MUST list is a MUST, and thus... MUST be > > checked. > > > > And really, the list is primarily for *my* benefit. To make sure *I* > > don't miss any of them. I don't know how anyone could keep track of all > > that in their head. And since I'm keeping a checklist anyway, I might as > > well post it in the review. > > > > Like Axel said, professional pilots and NASA astronauts keep pre and > > post-flight checklists. (And in the case of NASA, a bazillion in > > between...) I honestly don't understand how a professional packager > > could be so against keeping a review checklist. Of MUST items. To each > > their own I guess. > > I'm all for having a checklist. What I'm not for is adding more noise to the > review that doesn't help. It doesn't solve the fundamental problem of "was > this package correctly reviewed or not" and no amount of noise in a bug will > help that. Back/forth on items that don't adhere to the guideline DOES help, > but in the end, the only way to actually know if the review was done right is > to look at the package yourself. And even then its a wash as the lazy > reviewer could have just gotten lucky and the package was fine. > > So, checklist good. Dumping checklist into review bug not so useful. I largely agree with Jesse and mschwendt on this. The only place that I see a checklist being helpful is when deciding whether to sponsor a new contributor. At that time, it is still an open question whether the contributor has even read the ReviewGuidelines page. If they create and fill out a checklist based on the ReviewGuidelines page then you know that they are aware of the ReviewGuidelines and things you find lacking are either sloppiness or misunderstanding of what the Guidelines mean. If they don't include the checklist, you don't know whether they're misunderstanding or if they haven't even read through the Guidelines. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From williams at redhat.com Tue Jan 2 18:09:19 2007 From: williams at redhat.com (Clark Williams) Date: Tue, 02 Jan 2007 12:09:19 -0600 Subject: More Extras orphans on the hit list In-Reply-To: <45803196.8010003@redhat.com> References: <20061213155636.8ad10d49.bugs.michael@gmx.net> <45801C9B.5060108@redhat.com> <1166028253.11616.3.camel@Chuck> <45803196.8010003@redhat.com> Message-ID: <459A9FCF.8060304@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Clark Williams wrote: > Brian Pepple wrote: >> On Wed, 2006-12-13 at 09:30 -0600, Clark Williams wrote: >>> Michael Schwendt wrote: >>>> The following Fedora Extras packages have been orphaned prior to >>>> December 1st and need a new maintainer: >>> >>>> python-id3 >>> I use this one and would hate to see it go away. I'll take it if no one >>> else has a desire for it. >> Why not use python-eyeD3 which is already in FE? >> http://eyed3.nicfit.net/ > > > Ummm, because I didn't know about it? :) > > I have a script that I wrote a couple of years back (ripit) that uses > the CDDB and ID3 python modules and I haven't needed to change. I'll go > take a look eyeD3 and see if I should port my script to it. > > Clark > I got around to porting my script to use eyeD3 instead of ID3 and it works just fine. I withdraw my offer to maintain python-id3. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFmp/OHyuj/+TTEp0RAkfdAKCV0zXkuf9cfWbu1zqDMhjpcZjQlwCgqJtX oMdPe+r0aJ4WiZLW/mjKYQY= =IwP6 -----END PGP SIGNATURE----- From gauret at free.fr Tue Jan 2 22:19:16 2007 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 2 Jan 2007 23:19:16 +0100 Subject: Automate parts of review process? In-Reply-To: <1167544048.7452.2.camel@Chuck> References: <20061231043335.GB396@neu.nirvana> <1167540800.3328.609.camel@localhost.localdomain> <1167544048.7452.2.camel@Chuck> Message-ID: <200701022319.31707.gauret@free.fr> > Maybe we could look at using or extending Aur?lien Bompard's fedora-qa > script? > > http://gauret.free.fr/fichiers/rpms/fedora/fedora-qa My objective when I wrote this tool (and I'm still extending it) was to help me do reviews, so it's interactive : it asks the reviewer to validate the tests. However, I'm sure it can be tweaked to remove the interactive tests (there's about a dozen of them, over 42 total tests) or to make them non-interactive. The aim was to cover as much as the packaging guidelines as possible. And, it's python. So it should be hackable by the crowd here. Feel free to do whatever you please with it, and of course I'll be glad to help. Aur?lien. -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr En essayant continuellement, on finit par r?ussir. Donc plus ?a rate, plus on a des chances que ?a marche. -- devise Shadok. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Jan 3 19:46:54 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 03 Jan 2007 20:46:54 +0100 Subject: Plan for tomorrows (20070104) FESCO meeting Message-ID: <459C082E.3090502@leemhuis.info> Hi all, find below the list of topics that are likely to come up in the next FESCo meeting that scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-extras on irc.freenode.org. > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- EPEL doesn't really lift of -- what do? > /topic FESCO-Meeting -- Opening Core -- rdieter, jeremy, warren -- status update > /topic FESCO-Meeting -- Opening Core -- rdieter, jeremy, warren -- FESCo future? Deadlock? [WWW] https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00003.html) > /topic FESCO-Meeting -- Encourage co-maintainership -- c4chris > /topic FESCO-Meeting -- MISC -- firefox updates in stable often breaks quite some packages (galeon, liferia, ...); do we need some kind of task force that steps up to rebuild the stuff? > /topic FESCO-Meeting -- MISC -- disallow cvs-import for everything but the initial import? > /topic FESCO-Meeting -- MISC -- "what do we want like to see in the approved-message in a review bug" -- [WWW] https://www.redhat.com/archives/fedora-maintainers/2006-December/msg00214.html > /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop > /topic FESCo meeting -- Maintainer Responsibility Policy -- bpepple > /topic FESCo meeting -- Free discussion around Fedora Extras The meeting rules can be found at: http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... The schedule page in the wiki has more details on the individual topics; see http://www.fedoraproject.org/wiki/Extras/Schedule The individual pages specific to the topics are linked from there. The same as above holds true: if you name is somewhere on the schedule page in the wiki please update the status in the wiki ahead of the meeting. Ohh, and please update it also directly after the meeting so it's update and prepared for next weeks meeting :-) Hint: If you want to know what FESCo is doing simply subscribe in the wiki to "Extras/Schedul.*" and you'll get mails if something changes in that areas of the wiki. That should give you a good idea of FESCo's work. CU thl From jgarzik at redhat.com Thu Jan 4 00:47:51 2007 From: jgarzik at redhat.com (Jeff Garzik) Date: Wed, 3 Jan 2007 19:47:51 -0500 Subject: Plan for tomorrows (20070104) FESCO meeting In-Reply-To: <459C082E.3090502@leemhuis.info> References: <459C082E.3090502@leemhuis.info> Message-ID: <20070104004751.GH6278@devserv.devel.redhat.com> On Wed, Jan 03, 2007 at 08:46:54PM +0100, Thorsten Leemhuis wrote: > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora Extras" phase. Item: "syslog-ng patent problems" From jwboyer at jdub.homelinux.org Thu Jan 4 02:57:20 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 03 Jan 2007 20:57:20 -0600 Subject: Plan for tomorrows (20070104) FESCO meeting In-Reply-To: <20070104004751.GH6278@devserv.devel.redhat.com> References: <459C082E.3090502@leemhuis.info> <20070104004751.GH6278@devserv.devel.redhat.com> Message-ID: <1167879441.3159.9.camel@vader.jdub.homelinux.org> On Wed, 2007-01-03 at 19:47 -0500, Jeff Garzik wrote: > On Wed, Jan 03, 2007 at 08:46:54PM +0100, Thorsten Leemhuis wrote: > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora Extras" phase. > > Item: "syslog-ng patent problems" Fair enough. However, there are a few things to remember. 1) none of FESCo are lawyers 2) Based on what little I've found, it seems Huawei will not assert any patents against parties that are implementing the standard they claim to be patenting as long as said parties don't assert rights against Huawei and the implementation is necessary for compliance to the standard. See: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=724 3) I am not a lawyer 4) Removing syslog-ng at this point seems premature 5) I am not a lawyer So, FESCo can certainly discuss it, but I'd recommend sending it to Red Hat Legal for opinions before making any sort of decision on it. josh From buildsys at fedoraproject.org Thu Jan 4 09:38:25 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 4 Jan 2007 04:38:25 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-01-04 Message-ID: <20070104093825.441D015212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): dbus FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) cgoorah AT yahoo.com.au: ngspice FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) jwilson AT redhat.com: beryl-core FE6 > FE7 (0:0.1.4-2.fc6 > 0:0.1.4-1.fc7) beryl-plugins FE6 > FE7 (0:0.1.4-2.fc6 > 0:0.1.4-1.fc7) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-7.fc6 > 0:1.4.2.cvs20060817-5.fc7) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) ville.skytta AT iki.fi: em8300-kmod FE6 > FE7 (0:0.16.0-5.2.6.18_1.2869.fc6 > 0:0.16.0-5.2.6.18_1.2868.fc6) zcerza AT redhat.com: dogtail FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) ---------------------------------------------------------------------- beryl-core: jwilson AT redhat.com FE6 > FE7 (0:0.1.4-2.fc6 > 0:0.1.4-1.fc7) beryl-plugins: jwilson AT redhat.com FE6 > FE7 (0:0.1.4-2.fc6 > 0:0.1.4-1.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) em8300-kmod: ville.skytta AT iki.fi FE6 > FE7 (0:0.16.0-5.2.6.18_1.2869.fc6 > 0:0.16.0-5.2.6.18_1.2868.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-7.fc6 > 0:1.4.2.cvs20060817-5.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) ngspice: cgoorah AT yahoo.com.au FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From ville.skytta at iki.fi Thu Jan 4 19:49:41 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 4 Jan 2007 21:49:41 +0200 Subject: install-info scriptlet failures Message-ID: <200701042149.42369.ville.skytta@iki.fi> Having lately played around with (very) minimal installs, I was surprised to find how many packages' scriptlets fail on "%_excludedocs 1" setups. I've filed bugs against all Extras packages where I found the issue, as well as a bunch of Core packages that had more problems than a simple non-failsafe scriptlet (info files being erased on upgrades etc). In a nutshell, install-info in scriptlets should be protected both against the info files not existing (%_excludedocs 1) and read-only %_netsharedpath /usr/share installations. More info at http://fedoraproject.org/wiki/Packaging/ScriptletSnippets 60 easyfix Core packages remain - I'd rather not file bugs against all of them, so here are the patches: http://koti.welho.com/vskytta/install-infos/ List of affected packages: a2ps am-utils aspell autoconf automake bc binutils bison compat-gcc-34 coreutils cpio cvs diffutils ed emacspeak festival findutils gawk gcc gdbm gettext gimp-print glibc gmp gnuplot gnutls gperf gpm grep groff grub gsl guile g-wrap gzip indent jwhois krb5 libgcrypt libIDL libidn libtool make mgetty mikmod mtools mysql nasm pinfo psgml screen sed slib tar tetex texi2html time wget which zsh From Christian.Iseli at licr.org Thu Jan 4 20:01:47 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 4 Jan 2007 21:01:47 +0100 Subject: Bugzilla tickets for old Fedora releases Message-ID: <20070104210147.6527699c@ludwig-alpha.unil.ch> Dear all, Now that Fedora legacy has dropped 3 and 4, it seems time to close the old bug reports regarding FC 3 and FC 4. We invite all maintainers to have a look at open tickets for those old releases and take appropriate actions as they see fit: move to newer releases or close down. Next Monday, abadger1999, nirik and I will move all the remaining ones to NEEDINFO/reporter, wait one more week and close them down. So now is your chance... :-) Cheers, C From mattdm at mattdm.org Thu Jan 4 21:13:46 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 4 Jan 2007 16:13:46 -0500 Subject: Bugzilla tickets for old Fedora releases In-Reply-To: <20070104210147.6527699c@ludwig-alpha.unil.ch> References: <20070104210147.6527699c@ludwig-alpha.unil.ch> Message-ID: <20070104211346.GA6617@jadzia.bu.edu> On Thu, Jan 04, 2007 at 09:01:47PM +0100, Christian Iseli wrote: > We invite all maintainers to have a look at open tickets for those old > releases and take appropriate actions as they see fit: move to newer > releases or close down. > Next Monday, abadger1999, nirik and I will move all the remaining ones > to NEEDINFO/reporter, wait one more week and close them down. > So now is your chance... :-) A week seems fine for FC3, since I needinfo'd all of those before. (There's currently 16 still open for whatever reason.) It might be good to wait a bit longer before moving FC4 bugs out of needinfo state, since there's probably a handful that really do deserve to be moved up to a newer version and it's worth giving reporters a little bit of time. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at leemhuis.info Fri Jan 5 06:01:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 05 Jan 2007 07:01:21 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061229192506.GB14930@devserv.devel.redhat.com> References: <45951F62.4020302@leemhuis.info> <20061229192506.GB14930@devserv.devel.redhat.com> Message-ID: <459DE9B1.4010302@leemhuis.info> On 29.12.2006 20:25, Jeff Garzik wrote: > On Fri, Dec 29, 2006 at 03:00:02PM +0100, Thorsten Leemhuis wrote: >> Mroe detailed variant of the summary and the full log can be found at: >> http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20061228 >> Note: due to the holiday season is was expected that probably only small >> number of people could participate. FESCo nevertheless choose to run a >> small and meeting without actually voting on anything. > An issue to /not/ forget: > syslog-ng patent problems need examination and avoidance or clearing. > http://bazsi.blogspot.com/2006/07/thoughts-on-patent-system.html In addition to the stuff Josh posted: we'll chat about it in the next weeks meeting probably. But we probably leave this problem up to those that are currently known is "Fedora Core folks" (e.g. people from Red Hat). They have it on their agenda already: http://www.fedoraproject.org/wiki/Releases/FeatureSyslogNG Quoting: "Make sure that [WWW] any patent concerns are handled." CU thl From jspaleta at gmail.com Fri Jan 5 07:17:36 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 4 Jan 2007 22:17:36 -0900 Subject: Followup to FESCO meeting: firefox dependancy tracking. Message-ID: <604aa7910701042317p7c2201b7p3f338b9bea49d15b@mail.gmail.com> As per the FESCO meeting item list, and irc discussion, here is my humble attempt to identify via repoquery what packages are currently prone to library dependancy breakage without being noticed by the automated scripts which just look for rpm autogenerated library dependancies. these are packages which have a requirement on a library from firefox, but do not explicitly require firefox or gecko-libs: epiphany-extensions-0:2.16.1-1.i386 gnome-chemistry-utils-mozplugin-0:0.6.3-4.fc6.i386 openvrml-gtkplug-0:0.16.3-1.fc6.i386 openvrml-mozilla-plugin-0:0.16.3-1.fc6.i386 If you just look at packages which do not use a versioned firefox dep you also get: devhelp-0:0.12-9.fc6.i386 epiphany-0:2.16.2-1.fc6.i386 galeon-0:2.0.3-4.fc6.1.i386 gtkmozembedmm-0:1.4.2.cvs20060817-7.fc6.i386 libswt3-gtk2-1:3.2.1-23.fc6.i386 openvrml-0:0.16.3-1.fc6.i386 yelp-0:2.16.0-11.fc6.i386 The only packages which use a versioned firefox requirements are: gnome-python2-gtkmozembed-0:2.14.2-6.fc6.i386 liferea-0:1.0.26-2.fc6.i386 My suggestion is that all packages which end up requiring a library from firefox should use a versioned dependancy as long as firefox continues to keep its libraries in a versioned directory tree ( currently /usr/lib/firefox-1.5.0.9/ ). If a versioned firefox requirement is used we can atleast become aware of breakage as it happens via the available infrastructure scripts. As it stands the majority of the packages which depend on libraries from firefox will have library breakages on firefox updates and we can't see them from the available rpm dependancy information. Users will hit this issues when the library linker goes looking for a library in the wrong place. Comments? Should I start filing bugs against these packages to get versioned firefox requires added to their specfiles? Should we look at making this sort of thing part of the review process that should be checked for? Note that my use of repoquery still doesn't catch problematic packages like gnome-python2-extras nor esc which do not have trackable rpm library dependancies for repoquery to work with. -jef From rc040203 at freenet.de Fri Jan 5 07:39:09 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 05 Jan 2007 08:39:09 +0100 Subject: Followup to FESCO meeting: firefox dependancy tracking. In-Reply-To: <604aa7910701042317p7c2201b7p3f338b9bea49d15b@mail.gmail.com> References: <604aa7910701042317p7c2201b7p3f338b9bea49d15b@mail.gmail.com> Message-ID: <1167982749.9424.316.camel@mccallum.corsepiu.local> On Thu, 2007-01-04 at 22:17 -0900, Jeff Spaleta wrote: > As per the FESCO meeting item list, and irc discussion, here is my > humble attempt to identify via repoquery what packages are currently > prone to library dependancy breakage without being noticed by the > automated scripts which just look for rpm autogenerated library > dependancies. > > these are packages which have a requirement on a library from firefox, > but do not explicitly require firefox or gecko-libs: > > epiphany-extensions-0:2.16.1-1.i386 > gnome-chemistry-utils-mozplugin-0:0.6.3-4.fc6.i386 > openvrml-gtkplug-0:0.16.3-1.fc6.i386 > openvrml-mozilla-plugin-0:0.16.3-1.fc6.i386 > > If you just look at packages which do not use a versioned firefox dep > you also get: > > devhelp-0:0.12-9.fc6.i386 > epiphany-0:2.16.2-1.fc6.i386 > galeon-0:2.0.3-4.fc6.1.i386 > gtkmozembedmm-0:1.4.2.cvs20060817-7.fc6.i386 > libswt3-gtk2-1:3.2.1-23.fc6.i386 > openvrml-0:0.16.3-1.fc6.i386 > yelp-0:2.16.0-11.fc6.i386 > > > The only packages which use a versioned firefox requirements are: > > gnome-python2-gtkmozembed-0:2.14.2-6.fc6.i386 > liferea-0:1.0.26-2.fc6.i386 Hmm? # rpm -q --requires openvrml | grep firefox firefox = 1.5.0.9 > My suggestion is that all packages which end up requiring a library > from firefox should use a versioned dependancy as long as firefox > continues to keep its libraries in a versioned directory tree ( > currently /usr/lib/firefox-1.5.0.9/ ). ACK. > Comments? Should I start filing bugs against these packages to get > versioned firefox requires added to their specfiles ? Probably. It actually depends on what a package needs a versioned firefox dep for. In some cases, it's a library search path (Some packages use firefox libs as system libraries, but they are out of ld.so's search path, some explicitly dlopen them), in some cases it's a directory name, in some cases it's a particular version of a firefox library (Firefox libs lack proper SONAMES and properly versioned API). > Should we look at making this sort of thing part of the review process > that should be checked for? Yes, .. better have firefox fixed. IMO it's "plain broken". Ralf From Axel.Thimm at ATrpms.net Fri Jan 5 07:43:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 Jan 2007 08:43:43 +0100 Subject: Disttag for Fedora 7 and beyond Message-ID: <20070105074343.GB22825@neu.nirvana> Hi, it has often come up lately that since the "Core" will be removed from Fedora as a name the currently used disttag of fcN needs to be adjusted. As long as people were discussing what Fedora will be named it was difficult to nail some acronym, but now the simple "Fedora" emerged (which is good IMO). The problem is that the natural disttag of f7 is rpm-lesser that any fcN. There are two paths to take: a) Don't care about upgrade paths through disttags, just rebuild everything with a higher buildid (the part of the release before the disttag) and you can pick any disttag you like. The pros are obviously that one can use .f7, the cons are that we'll artificially introduce a specfile difference between many fc5/fc6 and f7/f8 specfiles which will make maintenance more error prone (foo will be foo-1-1.fc5, foo-1-1.fc6, foo-1-2.f7, foo-1-2.f8, e.g. foo-1-1%{?dist} pre- and foo-1-2%{?dist} post-merge). Add RHEL4/5 to the mix and the buildid confusion is perfect. It would haunt us until early 2008 (EOL for fc6), but then we'd be using our favourite disttag w/o a specfile era barrier anymore. b) Make sure any abbreviation used in the disttag for Fedora 7 and above is higher than that of fc6 and below. I.e. find something that is rpm-newer than "fc". "f" itself is lesser, capitalized versions the same. If one want to stick with something that starts with an "f" and has minimal characters one needs to play with "fd" to "fz". Out of them two seem to make sense acronym-wise (perhaps other's are also making sense, speak up if you spot one!): "fl" (Fedora Linux) or "fp" (Fedora Project). fl was up to now semantically occupied by the legacy project, but it's free to use now. The downside is that it implies that "Fedora" is "Fedora Linux" or "Fedora Project" which may be good or bad, it depends on marketing strategies. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Jan 5 07:59:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 05 Jan 2007 08:59:28 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105074343.GB22825@neu.nirvana> References: <20070105074343.GB22825@neu.nirvana> Message-ID: <459E0560.5080902@leemhuis.info> On 05.01.2007 08:43, Axel Thimm wrote: > [...] > b) Make sure any abbreviation used in the disttag for Fedora 7 and > above is higher than that of fc6 and below. I.e. find something > that is rpm-newer than "fc". "f" itself is lesser, capitalized > versions the same. If one want to stick with something that starts > with an "f" and has minimal characters one needs to play with "fd" > to "fz". Out of them two seem to make sense acronym-wise (perhaps > other's are also making sense, speak up if you spot one!): > > "fl" (Fedora Linux) or > "fp" (Fedora Project). > [...] Me currently votes for fp for "Fedora Packages" (and matches Fedora Project at the same time, too), because that's what it is afaics. BTW, what shall FESCo be called in the future? The "E" for Extras is obsolete now, too. FeSCo -> Fedora Steering Committee (does not really describe what is does) FePSCo -> Fedora Packages Steering Committee Any better suggestions? CU thl From paul at city-fan.org Fri Jan 5 08:12:54 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 05 Jan 2007 08:12:54 +0000 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105074343.GB22825@neu.nirvana> References: <20070105074343.GB22825@neu.nirvana> Message-ID: <1167984774.15187.9.camel@metropolis.intra.city-fan.org> On Fri, 2007-01-05 at 08:43 +0100, Axel Thimm wrote: > Hi, > > it has often come up lately that since the "Core" will be removed from > Fedora as a name the currently used disttag of fcN needs to be > adjusted. As long as people were discussing what Fedora will be named > it was difficult to nail some acronym, but now the simple "Fedora" > emerged (which is good IMO). > > The problem is that the natural disttag of f7 is rpm-lesser that any > fcN. There are two paths to take: > > a) Don't care about upgrade paths through disttags, just rebuild > everything with a higher buildid (the part of the release before > the disttag) and you can pick any disttag you like. > > The pros are obviously that one can use .f7, the cons are that > we'll artificially introduce a specfile difference between many > fc5/fc6 and f7/f8 specfiles which will make maintenance more error > prone (foo will be foo-1-1.fc5, foo-1-1.fc6, foo-1-2.f7, > foo-1-2.f8, e.g. foo-1-1%{?dist} pre- and foo-1-2%{?dist} > post-merge). Add RHEL4/5 to the mix and the buildid confusion is > perfect. It would haunt us until early 2008 (EOL for fc6), but then > we'd be using our favourite disttag w/o a specfile era barrier > anymore. > > b) Make sure any abbreviation used in the disttag for Fedora 7 and > above is higher than that of fc6 and below. I.e. find something > that is rpm-newer than "fc". "f" itself is lesser, capitalized > versions the same. If one want to stick with something that starts > with an "f" and has minimal characters one needs to play with "fd" > to "fz". Out of them two seem to make sense acronym-wise (perhaps > other's are also making sense, speak up if you spot one!): > > "fl" (Fedora Linux) or > "fp" (Fedora Project). > > fl was up to now semantically occupied by the legacy project, but > it's free to use now. > > The downside is that it implies that "Fedora" is "Fedora Linux" or > "Fedora Project" which may be good or bad, it depends on marketing > strategies. How about "fv" (Fedora Version) or "fr" (Fedora Release)? Paul. From nicolas.mailhot at laposte.net Fri Jan 5 08:46:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 5 Jan 2007 09:46:40 +0100 (CET) Subject: Disttag for Fedora 7 and beyond In-Reply-To: <459E0560.5080902@leemhuis.info> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> Message-ID: <3574.192.54.193.51.1167986800.squirrel@rousalka.dyndns.org> Le Ven 5 janvier 2007 08:59, Thorsten Leemhuis a ?crit : > BTW, what shall FESCo be called in the future? The "E" for Extras is > obsolete now, too. > > FeSCo -> Fedora Steering Committee (does not really describe what is does) > FePSCo -> Fedora Packages Steering Committee > > Any better suggestions? FepsiCo -> Fedora Packages SteerIng Committee -- Nicolas Mailhot From bugs.michael at gmx.net Fri Jan 5 08:55:50 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 5 Jan 2007 09:55:50 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105074343.GB22825@neu.nirvana> References: <20070105074343.GB22825@neu.nirvana> Message-ID: <20070105095550.117550ed.bugs.michael@gmx.net> On Fri, 5 Jan 2007 08:43:43 +0100, Axel Thimm wrote: > Hi, > > it has often come up lately that since the "Core" will be removed from > Fedora as a name the currently used disttag of fcN needs to be > adjusted. As long as people were discussing what Fedora will be named > it was difficult to nail some acronym, but now the simple "Fedora" > emerged (which is good IMO). > > The problem is that the natural disttag of f7 is rpm-lesser that any > fcN. There are two paths to take: > > a) Don't care about upgrade paths through disttags, just rebuild > everything with a higher buildid (the part of the release before > the disttag) and you can pick any disttag you like. > > The pros are obviously that one can use .f7, the cons are that > we'll artificially introduce a specfile difference between many > fc5/fc6 and f7/f8 specfiles which will make maintenance more error > prone (foo will be foo-1-1.fc5, foo-1-1.fc6, foo-1-2.f7, > foo-1-2.f8, e.g. foo-1-1%{?dist} pre- and foo-1-2%{?dist} > post-merge). Add RHEL4/5 to the mix and the buildid confusion is > perfect. It would haunt us until early 2008 (EOL for fc6), but then > we'd be using our favourite disttag w/o a specfile era barrier > anymore. The bottom part of that "a)" point enters too much wrong information into spec changelogs already. Just watch commits-list a bit to see how history is changed when spec files are copied over from newer branches. Sometimes changelog entries disappear. And not seldomly, mass-updates to multiple branches of the distribution are untested and break something. The top part of "a)" is misguidance. Using dist tags does not ensure sane upgrade paths in all known scenarios. Only in conjunction with full *online* upgrades, dist tags simplify package versioning. Hence: a.2) Do care about upgrade paths _without_ using dist tags. Start using stricter versioning with Epoch bumps as necessary, possibly even a hidden Dist Epoch inside RPM. Core+Extras merge. Packages from (ex-)Extras find their way into a collection and into the ISO images (snapshots!). We have arrived at the point where all package EVR tuples for the previous distribution versions (including upgrade and errata packages) ought to lose RPM version comparison when compared with any of the package EVRs for the newer distributions. This is especially useful when somebody upgrades from an up-to-date Fedora N-1 to the CD/DVD release of Fedora N. If we continue upgrading packages in the merged "Fedora" distribution as has been done in Fedora Extras before (ABI breakage, renames, and other things), there will be many burnt fingers during firstboot, and prior to a first full online update in general. From bugs.michael at gmx.net Fri Jan 5 09:19:07 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 5 Jan 2007 10:19:07 +0100 Subject: Plan for tomorrows (20070104) FESCO meeting In-Reply-To: <459C082E.3090502@leemhuis.info> References: <459C082E.3090502@leemhuis.info> Message-ID: <20070105101907.42e8b57c.bugs.michael@gmx.net> On Wed, 03 Jan 2007 20:46:54 +0100, Thorsten Leemhuis wrote: > Hi all, > > find below the list of topics that are likely to come up in the next > FESCo meeting that scheduled for tomorrow, Thursday at 18:00 UTC in > #fedora-extras on irc.freenode.org. > > > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- EPEL doesn't really lift of -- what do? > EPEL steering and status update coverage is non-existant. That's IMHO, at least. One benefit of stepping down from FESCO and not lurking 24/7 on IRC is that I can observe things from the perspective of an ordinary contributor with the risk of being subscribed to the wrong mailing-lists. So, what do I know about EPEL? extras.108.redhat.com is dead, at least on the mailing-list. Not enough momentum [and decision-power] from those who wanted to lift it off. EPEL owners.list in CVS is filled with a weird choice of initial packages. Where those additions (and package versions) are discussed is not known to me. EPEL builds have happened silently, giving the impression of a private playground. There are builds waiting to be published. But is it even known yet where to keep the repository? Is a mirroring system in place? And while the Extras' pushscript can be configured with a Config_EPEL.py module to push EPEL packages just fine, most likely the interest in waiting for Luke Macken's update system work to be usable seems bigger. From Christian.Iseli at licr.org Fri Jan 5 09:23:10 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 5 Jan 2007 10:23:10 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <459E0560.5080902@leemhuis.info> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> Message-ID: <20070105102310.3bb8241c@ludwig-alpha.unil.ch> On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: > Me currently votes for fp for "Fedora Packages" (and matches Fedora > Project at the same time, too), because that's what it is afaics. How about we just stay with fc7, and think of it as Fedora, collection 7 ? C From Axel.Thimm at ATrpms.net Fri Jan 5 09:25:03 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 Jan 2007 10:25:03 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105095550.117550ed.bugs.michael@gmx.net> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> Message-ID: <20070105092503.GA4860@neu.nirvana> On Fri, Jan 05, 2007 at 09:55:50AM +0100, Michael Schwendt wrote: > Start using stricter versioning with Epoch bumps as necessary, Ouch! Anything but epochs! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Fri Jan 5 09:47:53 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 05 Jan 2007 10:47:53 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105102310.3bb8241c@ludwig-alpha.unil.ch> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> Message-ID: <1167990473.9424.337.camel@mccallum.corsepiu.local> On Fri, 2007-01-05 at 10:23 +0100, Christian Iseli wrote: > On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: > > Me currently votes for fp for "Fedora Packages" (and matches Fedora > > Project at the same time, too), because that's what it is afaics. > > How about we just stay with fc7, and think of it as > Fedora, collection 7 ? +1 I like this, technically least intrusive, handy and ... meaningful. Ralf From jamatos at fc.up.pt Fri Jan 5 09:55:41 2007 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Fri, 5 Jan 2007 09:55:41 +0000 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1167990473.9424.337.camel@mccallum.corsepiu.local> References: <20070105074343.GB22825@neu.nirvana> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <1167990473.9424.337.camel@mccallum.corsepiu.local> Message-ID: <200701050955.41224.jamatos@fc.up.pt> On Friday 05 January 2007 9:47 am, Ralf Corsepius wrote: > > > > How about we just stay with fc7, and think of it as > > Fedora, collection 7 ? > > +1 > > I like this, technically least intrusive, handy and ... meaningful. I like it as well, and we already have the gcc precedent. :-) gcc: gnu c compiler -> gnu compiler collection > Ralf -- Jos? Ab?lio From jwboyer at jdub.homelinux.org Fri Jan 5 11:44:27 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 05 Jan 2007 05:44:27 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105092503.GA4860@neu.nirvana> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> Message-ID: <1167997467.3159.34.camel@vader.jdub.homelinux.org> On Fri, 2007-01-05 at 10:25 +0100, Axel Thimm wrote: > On Fri, Jan 05, 2007 at 09:55:50AM +0100, Michael Schwendt wrote: > > Start using stricter versioning with Epoch bumps as necessary, > > Ouch! Anything but epochs! Why? I keep hearing epochs are the spawn of satan. It's just a number... why are they so bad? josh From lists at timj.co.uk Fri Jan 5 11:45:01 2007 From: lists at timj.co.uk (Tim Jackson) Date: Fri, 05 Jan 2007 11:45:01 +0000 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105102310.3bb8241c@ludwig-alpha.unil.ch> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> Message-ID: <459E3A3D.7020000@timj.co.uk> Christian Iseli wrote: > On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: >> Me currently votes for fp for "Fedora Packages" (and matches Fedora >> Project at the same time, too), because that's what it is afaics. > > How about we just stay with fc7, and think of it as > Fedora, collection 7 ? Definitely the simplest solution so far :) This would save a lot of hassle. Tim From jwboyer at jdub.homelinux.org Fri Jan 5 11:50:20 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 05 Jan 2007 05:50:20 -0600 Subject: Plan for tomorrows (20070104) FESCO meeting In-Reply-To: <20070105101907.42e8b57c.bugs.michael@gmx.net> References: <459C082E.3090502@leemhuis.info> <20070105101907.42e8b57c.bugs.michael@gmx.net> Message-ID: <1167997820.3159.39.camel@vader.jdub.homelinux.org> On Fri, 2007-01-05 at 10:19 +0100, Michael Schwendt wrote: > On Wed, 03 Jan 2007 20:46:54 +0100, Thorsten Leemhuis wrote: > > > Hi all, > > > > find below the list of topics that are likely to come up in the next > > FESCo meeting that scheduled for tomorrow, Thursday at 18:00 UTC in > > #fedora-extras on irc.freenode.org. > > > > > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- EPEL doesn't really lift of -- what do? > > > > EPEL steering and status update coverage is non-existant. That's IMHO, at > least. > > One benefit of stepping down from FESCO and not lurking 24/7 on IRC is > that I can observe things from the perspective of an ordinary contributor > with the risk of being subscribed to the wrong mailing-lists. > > So, what do I know about EPEL? extras.108.redhat.com is dead, at least on > the mailing-list. Not enough momentum [and decision-power] from those who > wanted to lift it off. EPEL owners.list in CVS is filled with a weird > choice of initial packages. Where those additions (and package versions) The initial packages were done on a trial basis to get the buildsys up and running and tested. > are discussed is not known to me. EPEL builds have happened silently, > giving the impression of a private playground. There are builds waiting to Until the infrastructure team felt comfortable that the buildsys was working properly, it wasn't open to contributors. > be published. But is it even known yet where to keep the repository? Is a Yes, the repo location is known. > mirroring system in place? And while the Extras' pushscript can be > configured with a Config_EPEL.py module to push EPEL packages just fine, > most likely the interest in waiting for Luke Macken's update system work > to be usable seems bigger. I believe EPEL is open to contributors that currently have 5 or more packages and/or sponsor status. There is no need to wait for Luke's work. However, one thing that contributors might want wait on is an updated mock package with EPEL configs. I've got a bug opened to get that done and just need to find some time. josh From jwboyer at jdub.homelinux.org Fri Jan 5 11:52:03 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 05 Jan 2007 05:52:03 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <459E3A3D.7020000@timj.co.uk> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> Message-ID: <1167997923.3159.41.camel@vader.jdub.homelinux.org> On Fri, 2007-01-05 at 11:45 +0000, Tim Jackson wrote: > Christian Iseli wrote: > > On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: > >> Me currently votes for fp for "Fedora Packages" (and matches Fedora > >> Project at the same time, too), because that's what it is afaics. > > > > How about we just stay with fc7, and think of it as > > Fedora, collection 7 ? > > Definitely the simplest solution so far :) > This would save a lot of hassle. Why? Unless you've hard coded the dist tag in the spec file (which you shouldn't be doing), if the dist tag changes on the buildsys you don't even have to make any changes. A rebuild will just add the new dist tag. What hassle am I missing? josh From rc040203 at freenet.de Fri Jan 5 11:56:12 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 05 Jan 2007 12:56:12 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1167997923.3159.41.camel@vader.jdub.homelinux.org> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> Message-ID: <1167998172.3963.2.camel@mccallum.corsepiu.local> On Fri, 2007-01-05 at 05:52 -0600, Josh Boyer wrote: > On Fri, 2007-01-05 at 11:45 +0000, Tim Jackson wrote: > > Christian Iseli wrote: > > > On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: > > >> Me currently votes for fp for "Fedora Packages" (and matches Fedora > > >> Project at the same time, too), because that's what it is afaics. > > > > > > How about we just stay with fc7, and think of it as > > > Fedora, collection 7 ? > > > > Definitely the simplest solution so far :) > > This would save a lot of hassle. > > Why? Unless you've hard coded the dist tag in the spec file (which you > shouldn't be doing), if the dist tag changes on the buildsys you don't > even have to make any changes. A rebuild will just add the new dist > tag. > > What hassle am I missing? The hassle, - this discussion is causing ;) - of having to examine specs dist-tags - of having to adapt other SW (e.g. scripts in buildsystems, build scripts, html scripts on web sites etc.) - of a mass rebuild - of badly chosen dist-tags, such as .f7 Ralf From Axel.Thimm at ATrpms.net Fri Jan 5 11:57:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 Jan 2007 12:57:13 +0100 Subject: epel (was: Plan for tomorrows (20070104) FESCO meeting) In-Reply-To: <1167997820.3159.39.camel@vader.jdub.homelinux.org> References: <459C082E.3090502@leemhuis.info> <20070105101907.42e8b57c.bugs.michael@gmx.net> <1167997820.3159.39.camel@vader.jdub.homelinux.org> Message-ID: <20070105115713.GK4860@neu.nirvana> On Fri, Jan 05, 2007 at 05:50:20AM -0600, Josh Boyer wrote: > I believe EPEL is open to contributors that currently have 5 or more > packages and/or sponsor status. There is no need to wait for Luke's > work. > > However, one thing that contributors might want wait on is an updated > mock package with EPEL configs. I've got a bug opened to get that done > and just need to find some time. What exactly does a contributor need to do to branch into which RHEL branches? And where do the packages land in? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From devrim at CommandPrompt.com Fri Jan 5 12:06:48 2007 From: devrim at CommandPrompt.com (Devrim GUNDUZ) Date: Fri, 05 Jan 2007 14:06:48 +0200 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <459E3A3D.7020000@timj.co.uk> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> Message-ID: <1167998808.2879.3.camel@laptop.gunduz.org> Hi, On Fri, 2007-01-05 at 11:45 +0000, Tim Jackson wrote: > > How about we just stay with fc7, and think of it as > > Fedora, collection 7 ? > > Definitely the simplest solution so far :) > This would save a lot of hassle. Agreed. -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- 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 fedora at leemhuis.info Fri Jan 5 12:08:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 05 Jan 2007 13:08:10 +0100 Subject: epel In-Reply-To: <20070105115713.GK4860@neu.nirvana> References: <459C082E.3090502@leemhuis.info> <20070105101907.42e8b57c.bugs.michael@gmx.net> <1167997820.3159.39.camel@vader.jdub.homelinux.org> <20070105115713.GK4860@neu.nirvana> Message-ID: <459E3FAA.500@leemhuis.info> On 05.01.2007 12:57, Axel Thimm wrote: > On Fri, Jan 05, 2007 at 05:50:20AM -0600, Josh Boyer wrote: >> I believe EPEL is open to contributors that currently have 5 or more >> packages and/or sponsor status. There is no need to wait for Luke's >> work. >> However, one thing that contributors might want wait on is an updated >> mock package with EPEL configs. I've got a bug opened to get that done >> and just need to find some time. > What exactly does a contributor need to do to branch into which RHEL > branches? And where do the packages land in? Dgilmore promised in yesterday meeting to - send a mail that answers this sort of questions - that he'll try to drive this whole effort a bit more to get it flying - but I'm sure he'll be glad if people help. A real EPEL SIG that meets now and then and works out the details and leads EPEL is IMHO overdue. CU thl From Axel.Thimm at ATrpms.net Fri Jan 5 12:10:00 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 Jan 2007 13:10:00 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1167997467.3159.34.camel@vader.jdub.homelinux.org> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> Message-ID: <20070105121000.GL4860@neu.nirvana> On Fri, Jan 05, 2007 at 05:44:27AM -0600, Josh Boyer wrote: > On Fri, 2007-01-05 at 10:25 +0100, Axel Thimm wrote: > > On Fri, Jan 05, 2007 at 09:55:50AM +0100, Michael Schwendt wrote: > > > Start using stricter versioning with Epoch bumps as necessary, > > > > Ouch! Anything but epochs! > > Why? I keep hearing epochs are the spawn of satan. It's just a > number... why are they so bad? If it were just for a per package versioning epochs are just ugly, but when it comes to sane versioning of package dependencies you get these artificial beasts scattered all around. How many packagers have been bitten by Requires: foo >= 2.0.1 while they really needed foo >= 17:2.0.1 and the next update needed at least 23:3.0. E.g. the epoch inflation everywhere make it mandatory to start checking all your versioned BRs and Requires for having epochs before writing them down and it's both cumbersome and error-prone. Not to mention that it's non-portable, too, but that's not an issue here. And this is just the base problem - the ugliest part is that once you accidentially increase the epoch you're trapped - there's no way back - you have to cope with the above issue for the rest of this package's life (or until rpm-ng 6 changes rpmvercmp to use somthing else than epochs). The monotonic increase is similar to entropy in a way, so we'll all eventually die in a warm equilibrium. ;) Anyway I hope this short intro into "Epochs: are all equal to 666?" gives you some idea, otherwise "evil epoch rpm" gives 43.000 hits :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jan 5 12:14:57 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 Jan 2007 13:14:57 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1167997923.3159.41.camel@vader.jdub.homelinux.org> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> Message-ID: <20070105121457.GM4860@neu.nirvana> On Fri, Jan 05, 2007 at 05:52:03AM -0600, Josh Boyer wrote: > On Fri, 2007-01-05 at 11:45 +0000, Tim Jackson wrote: > > Christian Iseli wrote: > > > On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: > > >> Me currently votes for fp for "Fedora Packages" (and matches Fedora > > >> Project at the same time, too), because that's what it is afaics. > > > > > > How about we just stay with fc7, and think of it as > > > Fedora, collection 7 ? > > > > Definitely the simplest solution so far :) > > This would save a lot of hassle. > > Why? Unless you've hard coded the dist tag in the spec file (which you > shouldn't be doing), if the dist tag changes on the buildsys you don't > even have to make any changes. A rebuild will just add the new dist > tag. Correct. > What hassle am I missing? The chosen disttag whichever it will be, needs to be backwards compatible to the previous releases to allow for proper upgrade paths, e.g. it need to be rpm-newer. For example if you change the disttag from fc6 to abc1 then foo-1.2.3-4.abc1 will appear older to rpm than foo-1.2.3-4.fc6, so no fc6 package would ever upgrade to an abc1 package. Therefore we shouldn't use abc1 as a disttag :) Jokes aside - what happens with abc1 happens with "f7", too. f7 packages would again appear older than fc6 and even fc5 etc. packages, so all upgrade paths would be broken. That's why one needs to think about the disttag, and it looks like people prefer to stay in line and use fc7. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Fri Jan 5 12:15:46 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 5 Jan 2007 13:15:46 +0100 Subject: epel In-Reply-To: <459E3FAA.500@leemhuis.info> References: <459C082E.3090502@leemhuis.info> <20070105101907.42e8b57c.bugs.michael@gmx.net> <1167997820.3159.39.camel@vader.jdub.homelinux.org> <20070105115713.GK4860@neu.nirvana> <459E3FAA.500@leemhuis.info> Message-ID: <20070105121546.GA14484@free.fr> On Fri, Jan 05, 2007 at 01:08:10PM +0100, Thorsten Leemhuis wrote: > > Dgilmore promised in yesterday meeting to > - send a mail that answers this sort of questions > - that he'll try to drive this whole effort a bit more to get it > flying - but I'm sure he'll be glad if people help. A real EPEL SIG that > meets now and then and works out the details and leads EPEL is IMHO overdue. Have the quality standards of EPEL (like, for example binary stability...) been discussed? -- Pat From Axel.Thimm at ATrpms.net Fri Jan 5 12:18:53 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 Jan 2007 13:18:53 +0100 Subject: epel In-Reply-To: <459E3FAA.500@leemhuis.info> References: <459C082E.3090502@leemhuis.info> <20070105101907.42e8b57c.bugs.michael@gmx.net> <1167997820.3159.39.camel@vader.jdub.homelinux.org> <20070105115713.GK4860@neu.nirvana> <459E3FAA.500@leemhuis.info> Message-ID: <20070105121853.GN4860@neu.nirvana> On Fri, Jan 05, 2007 at 01:08:10PM +0100, Thorsten Leemhuis wrote: > On 05.01.2007 12:57, Axel Thimm wrote: > >On Fri, Jan 05, 2007 at 05:50:20AM -0600, Josh Boyer wrote: > >>I believe EPEL is open to contributors that currently have 5 or more > >>packages and/or sponsor status. There is no need to wait for Luke's > >>work. > >>However, one thing that contributors might want wait on is an updated > >>mock package with EPEL configs. I've got a bug opened to get that done > >>and just need to find some time. > >What exactly does a contributor need to do to branch into which RHEL > >branches? And where do the packages land in? > > Dgilmore promised in yesterday meeting to > - send a mail that answers this sort of questions > - that he'll try to drive this whole effort a bit more to get it > flying - but I'm sure he'll be glad if people help. A real EPEL SIG that > meets now and then and works out the details and leads EPEL is IMHO overdue. Well, I was very eager to help from the very beginning (I think my whining got Karsten to setup the 108 list), but w/o any info I don't have a handle to do anything. Perhaps it was wrong to move the discussion out of the 108 list, because now noone really knows who is doing what where and what is being discussed by which parties. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gauret at free.fr Fri Jan 5 12:33:24 2007 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 5 Jan 2007 13:33:24 +0100 Subject: Automate parts of review process? In-Reply-To: <1167544048.7452.2.camel@Chuck> References: <20061231043335.GB396@neu.nirvana> <1167540800.3328.609.camel@localhost.localdomain> <1167544048.7452.2.camel@Chuck> Message-ID: <200701051333.28194.gauret@free.fr> > Maybe we could look at using or extending Aur?lien Bompard's fedora-qa > script? > http://gauret.free.fr/fichiers/rpms/fedora/fedora-qa FYI, I just added a preliminar check to verify that the packaging guidelines have not changed. It's a very basic hack, but it does the job. Since we discussed this in the previous thread... Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From denis at poolshark.org Fri Jan 5 12:44:39 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 05 Jan 2007 13:44:39 +0100 Subject: Followup to FESCO meeting: firefox dependancy tracking. In-Reply-To: <604aa7910701042317p7c2201b7p3f338b9bea49d15b@mail.gmail.com> References: <604aa7910701042317p7c2201b7p3f338b9bea49d15b@mail.gmail.com> Message-ID: <459E4837.3040301@poolshark.org> Jeff Spaleta wrote: > As per the FESCO meeting item list, and irc discussion, here is my > humble attempt to identify via repoquery what packages are currently > prone to library dependancy breakage without being noticed by the > automated scripts which just look for rpm autogenerated library > dependancies. > > these are packages which have a requirement on a library from firefox, > but do not explicitly require firefox or gecko-libs: > > epiphany-extensions-0:2.16.1-1.i386 > gnome-chemistry-utils-mozplugin-0:0.6.3-4.fc6.i386 > openvrml-gtkplug-0:0.16.3-1.fc6.i386 > openvrml-mozilla-plugin-0:0.16.3-1.fc6.i386 > > If you just look at packages which do not use a versioned firefox dep > you also get: > > devhelp-0:0.12-9.fc6.i386 > epiphany-0:2.16.2-1.fc6.i386 > galeon-0:2.0.3-4.fc6.1.i386 galeon uses a versioned dependency on gecko-libs. From the spec file: Requires: gecko-libs = %{gecko_ver} BuildRequires: gecko-devel = %{gecko_ver} Epiphany does this as well. From fedora at leemhuis.info Fri Jan 5 12:49:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 05 Jan 2007 13:49:33 +0100 Subject: epel In-Reply-To: <20070105121853.GN4860@neu.nirvana> References: <459C082E.3090502@leemhuis.info> <20070105101907.42e8b57c.bugs.michael@gmx.net> <1167997820.3159.39.camel@vader.jdub.homelinux.org> <20070105115713.GK4860@neu.nirvana> <459E3FAA.500@leemhuis.info> <20070105121853.GN4860@neu.nirvana> Message-ID: <459E495D.6080706@leemhuis.info> On 05.01.2007 13:18, Axel Thimm wrote: > On Fri, Jan 05, 2007 at 01:08:10PM +0100, Thorsten Leemhuis wrote: >> On 05.01.2007 12:57, Axel Thimm wrote: >>> On Fri, Jan 05, 2007 at 05:50:20AM -0600, Josh Boyer wrote: >>>> I believe EPEL is open to contributors that currently have 5 or more >>>> packages and/or sponsor status. There is no need to wait for Luke's >>>> work. >>>> However, one thing that contributors might want wait on is an updated >>>> mock package with EPEL configs. I've got a bug opened to get that done >>>> and just need to find some time. >>> What exactly does a contributor need to do to branch into which RHEL >>> branches? And where do the packages land in? >> Dgilmore promised in yesterday meeting to >> - send a mail that answers this sort of questions >> - that he'll try to drive this whole effort a bit more to get it >> flying - but I'm sure he'll be glad if people help. A real EPEL SIG that >> meets now and then and works out the details and leads EPEL is IMHO overdue. > Well, I was very eager to help from the very beginning (I think my > whining got Karsten to setup the 108 list), but w/o any info I don't > have a handle to do anything. The FESCo <-> "Packager community" communication is IMHO the problem. It seems FESCo want contributors to participate in the FESCo meetings and/or step up and simply do stuff they think Extras needs. But some contributors seems to say "FESCo, here is a problem, please solve it" and/or they don't even notice that FESCo needs help. That FESCo's fault. We need to improve this, suggestions welcomed. Two things I'm planing to improve the situation: - let somebody else do the job of the FESCo-chair after the next election. Fresh blood, new ideas hopefully help. Maybe even earlier if someone steps up from current FESCo -- not sure. Handling the big merge with the current team might be more important ATM. - maintain a public list of things were FESCo/Extras in general needs a helping hand. > Perhaps it was wrong to move the discussion out of the 108 list, > because now noone really knows who is doing what where and what is > being discussed by which parties. Might be part of the problem (others will say that more mailing lists are the problem), but the real problem IMHO is: It lacked a real driver. I tried to do that, but I'm buried with other work already and thus tried to move it over to mmcgrath and dgilmore. They did a lot of work for it, but they have a lot of other work to do already, too. :-/ CU thl From jwboyer at jdub.homelinux.org Fri Jan 5 13:14:46 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 05 Jan 2007 07:14:46 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1167998172.3963.2.camel@mccallum.corsepiu.local> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> Message-ID: <1168002886.3836.91.camel@zod.rchland.ibm.com> On Fri, 2007-01-05 at 12:56 +0100, Ralf Corsepius wrote: > On Fri, 2007-01-05 at 05:52 -0600, Josh Boyer wrote: > > On Fri, 2007-01-05 at 11:45 +0000, Tim Jackson wrote: > > > Christian Iseli wrote: > > > > On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: > > > >> Me currently votes for fp for "Fedora Packages" (and matches Fedora > > > >> Project at the same time, too), because that's what it is afaics. > > > > > > > > How about we just stay with fc7, and think of it as > > > > Fedora, collection 7 ? > > > > > > Definitely the simplest solution so far :) > > > This would save a lot of hassle. > > > > Why? Unless you've hard coded the dist tag in the spec file (which you > > shouldn't be doing), if the dist tag changes on the buildsys you don't > > even have to make any changes. A rebuild will just add the new dist > > tag. > > > > What hassle am I missing? > The hassle, > - this discussion is causing ;) Sure :) > - of having to examine specs dist-tags They shouldn't have passed review if they are hard coded. If they did, a bug needs to be opened to fix it anyway. > - of having to adapt other SW (e.g. scripts in buildsystems, > build scripts, html scripts on web sites etc.) As far as I know, it's a single file to change. > - of a mass rebuild Which is likely to get done anyway around Test2. It's been done for the past 2 releases. > - of badly chosen dist-tags, such as .f7 That isn't really a hassle. It just needs to not be done. :) josh From bugs.michael at gmx.net Fri Jan 5 13:54:05 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 5 Jan 2007 14:54:05 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105121000.GL4860@neu.nirvana> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> <20070105121000.GL4860@neu.nirvana> Message-ID: <20070105145405.c9057674.bugs.michael@gmx.net> On Fri, 5 Jan 2007 13:10:00 +0100, Axel Thimm wrote: > On Fri, Jan 05, 2007 at 05:44:27AM -0600, Josh Boyer wrote: > > On Fri, 2007-01-05 at 10:25 +0100, Axel Thimm wrote: > > > On Fri, Jan 05, 2007 at 09:55:50AM +0100, Michael Schwendt wrote: > > > > Start using stricter versioning with Epoch bumps as necessary, > > > > > > Ouch! Anything but epochs! > > > > Why? I keep hearing epochs are the spawn of satan. It's just a > > number... why are they so bad? > > If it were just for a per package versioning epochs are just ugly, but > when it comes to sane versioning of package dependencies you get these > artificial beasts scattered all around. > > How many packagers have been bitten by Requires: foo >= 2.0.1 while > they really needed foo >= 17:2.0.1 Users, not packagers. Years ago, with command-line RPM, when a user downloaded an arbitrary foo-2.0.1-4.i386.rpm from rpmfind.net in believe that it need not be for a specific distribution and that it would install and work fine. A non-obvious hidden Epoch value makes such users scratch their heads, especially with RPM < 4.1.1. [Similar users also run into other problems, such as EVR being correct, but SONAME dependencies being incompatible. Repositories and Add/Remove Software GUIs to the rescue.] For everyone else including packagers, in the distribution there is only one package "foo" with version 2.0.1 or the very latest errata package in the updates channel. Any yum [or put your favourite package resolver here] update will pull it in if the system has an older "foo" with a lower Epoch installed. If, however, the distribution's repository also contains an older build of "foo" 3.0, which is broken, the requirement "foo >= 2.0.1" is not specific enough. You could delete foo 3.0 from the repository, but that would not result in an automatic downgrade on users' or packagers' machines where the broken package is still installed. > and the next update needed at least 23:3.0. > E.g. the epoch inflation everywhere make it mandatory to start > checking all your versioned BRs and Versioned BRs are not affected, since the RPM Epoch never specifies an API version. You would only BR foo >= 3.0 to satisfy a build requirement, and that would be both good enough and fragile enough at the same time. Fragile, because 4.0 might be incompatible, and you cannot avoid using the Epoch, anyway, if the repository ever contained foo > 3.0 prior to a non-trivial rollback. Just as dist tags are no silver bullet and have their own problems and pitfalls, epochs are just one mighty tool to something done and be able to work around a variety of problems. Epochs are not evil. Even the old explicit "Epoch: 0" policy solved more problems [of an epoch promotion bug in rpm] than it created, but is no longer needed. Packagers using dist tags have run into more pitfalls than packagers using epochs (e.g. with cvs tags, with minor release bumps, with dist tags on huge noarch data packages, with superfluous rebuilds only to update the dist tag in the pkg file name, with quick mass-updates to multiple branches). From stickster at gmail.com Fri Jan 5 14:09:01 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 05 Jan 2007 09:09:01 -0500 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105102310.3bb8241c@ludwig-alpha.unil.ch> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> Message-ID: <1168006141.4299.29.camel@localhost.localdomain> On Fri, 2007-01-05 at 10:23 +0100, Christian Iseli wrote: > On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: > > Me currently votes for fp for "Fedora Packages" (and matches Fedora > > Project at the same time, too), because that's what it is afaics. > > How about we just stay with fc7, and think of it as > Fedora, collection 7 ? +1 -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- 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 lists at timj.co.uk Fri Jan 5 14:09:39 2007 From: lists at timj.co.uk (Tim Jackson) Date: Fri, 05 Jan 2007 14:09:39 +0000 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1167997923.3159.41.camel@vader.jdub.homelinux.org> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> Message-ID: <459E5C23.8000505@timj.co.uk> Josh Boyer wrote: > On Fri, 2007-01-05 at 11:45 +0000, Tim Jackson wrote: >> Christian Iseli wrote: >>> How about we just stay with fc7, and think of it as >>> Fedora, collection 7 ? >> Definitely the simplest solution so far :) >> This would save a lot of hassle. > > Why? [...] > What hassle am I missing? - possible confusion since the .fcX disttag is used in *many* other repos (please no flamewars about how FP should just completely ignore the existence of anything other than The One True Official Repo. This may or may not be a sensible approach, but it has no bearing on this situation) - hassle for other repos which either all have to fall into line (=change all their stuff too) or risk being confusing (see above re: flamewars) - hassle for anyone that has personal scripts that do stuff, and have .fcX hardcoded in them. (I do, and I bet there are thousands out there) - possible hassle for any other third party systems (RPM search sites maybe?) that may use the presence of an "fc" disttag in their processing somehow. - hassle when people forget the change and do typos. e.g. a CVS admin creating FC-8 instead of FP-8 for example. (OK, maybe that's scripted in the Fedora dist system, but I'm willing to bet that if the disttag changes, someone, somewhere will cause grief by forgetting the change) Whilst it's hardly earth-shattering, and we'll all live with it, it just seems a bit pointless - like change for change's sake. Someone's come up with a plausible and meaningful revised term that still uses "FC" so given that, surely everyone's time would be better spent on technical stuff rather than changing the letter "C" to "P" (or whatever) in various places? Tim From lists at timj.co.uk Fri Jan 5 14:15:57 2007 From: lists at timj.co.uk (Tim Jackson) Date: Fri, 05 Jan 2007 14:15:57 +0000 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1167997467.3159.34.camel@vader.jdub.homelinux.org> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> Message-ID: <459E5D9D.4060800@timj.co.uk> Josh Boyer wrote: > On Fri, 2007-01-05 at 10:25 +0100, Axel Thimm wrote: >> On Fri, Jan 05, 2007 at 09:55:50AM +0100, Michael Schwendt wrote: >>> Start using stricter versioning with Epoch bumps as necessary, >> Ouch! Anything but epochs! > > Why? I keep hearing epochs are the spawn of satan. It's just a > number... why are they so bad? One reason is that they're opaque to several common use cases, with current RPM versions. Neither "rpm -q" nor "rpm -qi" show Epochs. Neither are epochs included in RPM file names. Now arguably this is a problem with RPM rather than with epochs, but until the defaults change in RPM it can make things confusing and awkward. Try explaining to a non-RPM expert why doing this: rpm -i foo-1.0.i386.rpm rpm -U foo-1.1.i386.rpm gives an error about foo-1.1 being an older version. (in the case that the Epoch on foo-1.1 is lower than that on foo-1.0) Even though I'm a packager and I know about epochs, I still occasionally have a head-scratching moment related to something like this. Tim From gdk at redhat.com Fri Jan 5 14:30:02 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Fri, 5 Jan 2007 09:30:02 -0500 (EST) Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1167990473.9424.337.camel@mccallum.corsepiu.local> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <1167990473.9424.337.camel@mccallum.corsepiu.local> Message-ID: On Fri, 5 Jan 2007, Ralf Corsepius wrote: > On Fri, 2007-01-05 at 10:23 +0100, Christian Iseli wrote: >> On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: >>> Me currently votes for fp for "Fedora Packages" (and matches Fedora >>> Project at the same time, too), because that's what it is afaics. >> >> How about we just stay with fc7, and think of it as >> Fedora, collection 7 ? > +1 > > I like this, technically least intrusive, handy and ... meaningful. +1. No need to mess with disttags for the speculative gain of branding, IMHO. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From dennis at ausil.us Fri Jan 5 14:36:55 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 5 Jan 2007 08:36:55 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168006141.4299.29.camel@localhost.localdomain> References: <20070105074343.GB22825@neu.nirvana> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <1168006141.4299.29.camel@localhost.localdomain> Message-ID: <200701050836.55447.dennis@ausil.us> On Friday 05 January 2007 08:09, Paul W. Frields wrote: > On Fri, 2007-01-05 at 10:23 +0100, Christian Iseli wrote: > > On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: > > > Me currently votes for fp for "Fedora Packages" (and matches Fedora > > > Project at the same time, too), because that's what it is afaics. > > > > How about we just stay with fc7, and think of it as > > Fedora, collection 7 ? > > +1 +1 it could also stand for fedora community 7 -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From panemade at gmail.com Fri Jan 5 15:31:50 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 5 Jan 2007 21:01:50 +0530 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105102310.3bb8241c@ludwig-alpha.unil.ch> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> Message-ID: Hi, On 1/5/07, Christian Iseli wrote: > On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: > > Me currently votes for fp for "Fedora Packages" (and matches Fedora > > Project at the same time, too), because that's what it is afaics. > > How about we just stay with fc7, and think of it as > Fedora, collection 7 ? +1 from me also. Its really Nice alternative to Fedora Core 7. Regards, Parag. From skvidal at linux.duke.edu Fri Jan 5 16:11:13 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 05 Jan 2007 11:11:13 -0500 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <459E5D9D.4060800@timj.co.uk> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> <459E5D9D.4060800@timj.co.uk> Message-ID: <1168013473.11355.118.camel@cutter> On Fri, 2007-01-05 at 14:15 +0000, Tim Jackson wrote: > Josh Boyer wrote: > > On Fri, 2007-01-05 at 10:25 +0100, Axel Thimm wrote: > >> On Fri, Jan 05, 2007 at 09:55:50AM +0100, Michael Schwendt wrote: > >>> Start using stricter versioning with Epoch bumps as necessary, > >> Ouch! Anything but epochs! > > > > Why? I keep hearing epochs are the spawn of satan. It's just a > > number... why are they so bad? > > One reason is that they're opaque to several common use cases, with > current RPM versions. > > Neither "rpm -q" nor "rpm -qi" show Epochs. Neither are epochs included > in RPM file names. Now arguably this is a problem with RPM rather than > with epochs, but until the defaults change in RPM it can make things > confusing and awkward. Try explaining to a non-RPM expert why doing this: > > rpm -i foo-1.0.i386.rpm > rpm -U foo-1.1.i386.rpm > > gives an error about foo-1.1 being an older version. (in the case that > the Epoch on foo-1.1 is lower than that on foo-1.0) > > Even though I'm a packager and I know about epochs, I still occasionally > have a head-scratching moment related to something like this. > yum list shows epochs. if it is any consolation. -sv From ajackson at redhat.com Fri Jan 5 16:57:47 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 05 Jan 2007 11:57:47 -0500 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105074343.GB22825@neu.nirvana> References: <20070105074343.GB22825@neu.nirvana> Message-ID: <1168016267.7683.559.camel@localhost.localdomain> On Fri, 2007-01-05 at 08:43 +0100, Axel Thimm wrote: > Hi, > > it has often come up lately that since the "Core" will be removed from > Fedora as a name the currently used disttag of fcN needs to be > adjusted. As long as people were discussing what Fedora will be named > it was difficult to nail some acronym, but now the simple "Fedora" > emerged (which is good IMO). > > The problem is that the natural disttag of f7 is rpm-lesser that any > fcN. There are two paths to take: > > a) Don't care about upgrade paths through disttags, just rebuild > everything with a higher buildid (the part of the release before > the disttag) and you can pick any disttag you like. > > b) Make sure any abbreviation used in the disttag for Fedora 7 and > above is higher than that of fc6 and below. I.e. find something > that is rpm-newer than "fc". "f" itself is lesser, capitalized > versions the same. If one want to stick with something that starts > with an "f" and has minimal characters one needs to play with "fd" > to "fz". Out of them two seem to make sense acronym-wise (perhaps > other's are also making sense, speak up if you spot one!): c) leave it as .fcN and don't worry about it? Changing it doesn't fix any real problem we are currently having or are about to have, and really just invites people to debate what color the bikeshed should be. - ajax From caillon at redhat.com Fri Jan 5 17:07:44 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 05 Jan 2007 12:07:44 -0500 Subject: Followup to FESCO meeting: firefox dependancy tracking. In-Reply-To: <604aa7910701042317p7c2201b7p3f338b9bea49d15b@mail.gmail.com> References: <604aa7910701042317p7c2201b7p3f338b9bea49d15b@mail.gmail.com> Message-ID: <459E85E0.8000804@redhat.com> Let me first preface this by stating very clearly: Firefox is NOT a devel environment. It will NEVER be one. There is a -devel package only because there is no other choice at the moment. There is no supported way to use a gecko build environment from upstream until XULrunner 1.0 is released. Every package that attempts to build against Firefox is doing so at their own risk. Having said that, every package in Core which needs to has always had an explicit versioned requires (except for the packages in FC6 GOLD which was an unfortunate regression, but long since fixed). See the latest epiphany/devhelp/yelp RPMs for how to do the dependencies (I'm not sure how they got in your list of non-versioned deps unless you looked at FC6 GOLD). So, the real question is now: do we want to continue to allow more gecko based applications into fedora at all? There is no real build environment for it, and it works only as a side effect of hacking it up to work for yelp, really which we need and is in core. I'd like to say no if we can help it. Things like esc have no business using gecko, IMO. Using gecko just opens up the package maintainer to a world of pain, which I also have to face, but I'm being paid for it at least. It is a negative experience for the maintainer to have to rebuild things all the damn time. On 01/05/2007 02:17 AM, Jeff Spaleta wrote: > As per the FESCO meeting item list, and irc discussion, here is my > humble attempt to identify via repoquery what packages are currently > prone to library dependancy breakage without being noticed by the > automated scripts which just look for rpm autogenerated library > dependancies. > > these are packages which have a requirement on a library from firefox, > but do not explicitly require firefox or gecko-libs: > > epiphany-extensions-0:2.16.1-1.i386 > gnome-chemistry-utils-mozplugin-0:0.6.3-4.fc6.i386 > openvrml-gtkplug-0:0.16.3-1.fc6.i386 > openvrml-mozilla-plugin-0:0.16.3-1.fc6.i386 > > If you just look at packages which do not use a versioned firefox dep > you also get: > > devhelp-0:0.12-9.fc6.i386 > epiphany-0:2.16.2-1.fc6.i386 > galeon-0:2.0.3-4.fc6.1.i386 > gtkmozembedmm-0:1.4.2.cvs20060817-7.fc6.i386 > libswt3-gtk2-1:3.2.1-23.fc6.i386 > openvrml-0:0.16.3-1.fc6.i386 > yelp-0:2.16.0-11.fc6.i386 > > > The only packages which use a versioned firefox requirements are: > > gnome-python2-gtkmozembed-0:2.14.2-6.fc6.i386 > liferea-0:1.0.26-2.fc6.i386 > > My suggestion is that all packages which end up requiring a library > from firefox should use a versioned dependancy as long as firefox > continues to keep its libraries in a versioned directory tree ( > currently /usr/lib/firefox-1.5.0.9/ ). If a versioned firefox > requirement is used we can atleast become aware of breakage as it > happens via the available infrastructure scripts. As it stands the > majority of the packages which depend on libraries from firefox will > have library breakages on firefox updates and we can't see them from > the available rpm dependancy information. Users will hit this issues > when the library linker goes looking for a library in the wrong place. > > Comments? Should I start filing bugs against these packages to get > versioned firefox requires added to their specfiles? Should we look > at making this sort of thing part of the review process that should be > checked for? > > Note that my use of repoquery still doesn't catch problematic packages > like gnome-python2-extras nor esc which do not have trackable rpm > library dependancies for repoquery to work with. > > -jef > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From davidz at redhat.com Fri Jan 5 17:19:32 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 05 Jan 2007 12:19:32 -0500 Subject: CC-BY-SA in Fedora Message-ID: <1168017572.2474.20.camel@zelda.fubar.dk> Hi! It appears that tango-icon-themes in Extras http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/repodata/repoview/tango-icon-theme-0-0.7.2-5.fc6.html is licensed under the CC-BY-SA-2.5 license http://creativecommons.org/licenses/by-sa/2.5/ According to http://fedoraproject.org/wiki/Packaging/Guidelines#head-76294f12c6b481792eb001ba9763d95e2792e825 CC-BY-SA-2.5 appears NOT to be a valid license. So either 1) the Packaging Guidelines needs to be fixed up; 2) I'm not reading them right (in that case apologies for the noise); 3) something else needs to happen I'm writing this mail because I'm interested in CC-BY-SA-2.0 or later being a valid license for Fedora but right now it doesn't appear that way. Thanks. David From caillon at redhat.com Fri Jan 5 17:17:51 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 05 Jan 2007 12:17:51 -0500 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168002886.3836.91.camel@zod.rchland.ibm.com> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> <1168002886.3836.91.camel@zod.rchland.ibm.com> Message-ID: <459E883F.1020208@redhat.com> On 01/05/2007 08:14 AM, Josh Boyer wrote: > On Fri, 2007-01-05 at 12:56 +0100, Ralf Corsepius wrote: >> - of having to examine specs dist-tags > > They shouldn't have passed review if they are hard coded. If they did, > a bug needs to be opened to fix it anyway. You're thinking of only extras here. Many core packages used hardcoded dist tags long before we had the ability to do them. Additionally, specs in extras could get approved without dist tags and then have them hard coded in by someone who mightn't know better. >> - of a mass rebuild > > Which is likely to get done anyway around Test2. It's been done for the > past 2 releases. ...because of significant changes to the toolchain, not because we like to do them. There's no guarantee we'll need one in any given release cycle. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From sundaram at fedoraproject.org Fri Jan 5 17:24:05 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 05 Jan 2007 22:54:05 +0530 Subject: CC-BY-SA in Fedora In-Reply-To: <1168017572.2474.20.camel@zelda.fubar.dk> References: <1168017572.2474.20.camel@zelda.fubar.dk> Message-ID: <459E89B5.7090507@fedoraproject.org> David Zeuthen wrote: > Hi! > > It appears that tango-icon-themes in Extras > > http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/repodata/repoview/tango-icon-theme-0-0.7.2-5.fc6.html > > is licensed under the CC-BY-SA-2.5 license > > http://creativecommons.org/licenses/by-sa/2.5/ > > According to > > http://fedoraproject.org/wiki/Packaging/Guidelines#head-76294f12c6b481792eb001ba9763d95e2792e825 > > CC-BY-SA-2.5 appears NOT to be a valid license. So either > > 1) the Packaging Guidelines needs to be fixed up; > > 2) I'm not reading them right (in that case apologies for the noise); > > 3) something else needs to happen > > I'm writing this mail because I'm interested in CC-BY-SA-2.0 or later > being a valid license for Fedora but right now it doesn't appear that > way. Thanks I think it is 2). Since you are talking about themes do look at http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9cf7b9a49b5edb36e3bda3aac Rahul From tibbs at math.uh.edu Fri Jan 5 17:32:00 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Jan 2007 11:32:00 -0600 Subject: CC-BY-SA in Fedora In-Reply-To: <1168017572.2474.20.camel@zelda.fubar.dk> References: <1168017572.2474.20.camel@zelda.fubar.dk> Message-ID: >>>>> "DZ" == David Zeuthen writes: DZ> CC-BY-SA-2.5 appears NOT to be a valid license. So either Well, CC-BY-SA-2.0 is free. (It's way down at the bottom of the FSF list, under "Licenses for Works Besides Software and Documentation".) I don't know that 2.5 is also considered free, but I can't even see any difference between them and common sense would seem to dictate that someone wouldn't be dumb enough to make a minor revision non-free, so it seems at least reasonable to ping the FSF first and only remove the package if that fails. - J< From davidz at redhat.com Fri Jan 5 17:39:16 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 05 Jan 2007 12:39:16 -0500 Subject: CC-BY-SA in Fedora In-Reply-To: <459E89B5.7090507@fedoraproject.org> References: <1168017572.2474.20.camel@zelda.fubar.dk> <459E89B5.7090507@fedoraproject.org> Message-ID: <1168018756.2474.25.camel@zelda.fubar.dk> On Fri, 2007-01-05 at 22:54 +0530, Rahul Sundaram wrote: > I think it is 2). Since you are talking about themes do look at > http://fedoraproject.org/wiki/Packaging/Guidelines#head-daa717ea096fa4d9cf7b9a49b5edb36e3bda3aac Phew, I was hoping it was 2) but wanted to check here just in case :-). It would be useful to a) link to this section from the Licensing section I linked to (or perhaps merge them); and b) have a list of acceptable licenses for content (just like we have for code). So I'd appreciate if the people involved in writing the guide lines could change it; I can edit the Wiki, of course, but I guess some of the people "owning" this document should do it. Thanks! David From jwilson at redhat.com Fri Jan 5 17:41:29 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 5 Jan 2007 12:41:29 -0500 Subject: Package EVR problems in FC+FE 2007-01-04 In-Reply-To: <20070104093825.441D015212E@buildsys.fedoraproject.org> References: <20070104093825.441D015212E@buildsys.fedoraproject.org> Message-ID: <200701051241.33520.jwilson@redhat.com> On Thursday 04 January 2007 04:38, buildsys at fedoraproject.org wrote: > jwilson AT redhat.com: > ? ? beryl-core > ? ? ? FE6 > FE7 (0:0.1.4-2.fc6 > 0:0.1.4-1.fc7) > ? ? > ? ? beryl-plugins > ? ? ? FE6 > FE7 (0:0.1.4-2.fc6 > 0:0.1.4-1.fc7) Oopsies. Fixed. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Fri Jan 5 17:42:27 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 05 Jan 2007 11:42:27 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <459E883F.1020208@redhat.com> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> <1168002886.3836.91.camel@zod.rchland.ibm.com> <459E883F.1020208@redhat.com> Message-ID: <1168018947.3836.132.camel@zod.rchland.ibm.com> On Fri, 2007-01-05 at 12:17 -0500, Christopher Aillon wrote: > On 01/05/2007 08:14 AM, Josh Boyer wrote: > > On Fri, 2007-01-05 at 12:56 +0100, Ralf Corsepius wrote: > >> - of having to examine specs dist-tags > > > > They shouldn't have passed review if they are hard coded. If they did, > > a bug needs to be opened to fix it anyway. > > You're thinking of only extras here. Many core packages used hardcoded > dist tags long before we had the ability to do them. Additionally, > specs in extras could get approved without dist tags and then have them > hard coded in by someone who mightn't know better. The core packages need to go through a review for the merge anyway. And the latter case is a bug :) > >> - of a mass rebuild > > > > Which is likely to get done anyway around Test2. It's been done for the > > past 2 releases. > > ...because of significant changes to the toolchain, not because we like > to do them. There's no guarantee we'll need one in any given release cycle. Ok true. josh From nicolas.mailhot at laposte.net Fri Jan 5 17:46:46 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 05 Jan 2007 18:46:46 +0100 Subject: Followup to FESCO meeting: firefox dependancy tracking. In-Reply-To: <459E85E0.8000804@redhat.com> References: <604aa7910701042317p7c2201b7p3f338b9bea49d15b@mail.gmail.com> <459E85E0.8000804@redhat.com> Message-ID: <1168019206.10184.2.camel@rousalka.dyndns.org> Le vendredi 05 janvier 2007 ? 12:07 -0500, Christopher Aillon a ?crit : > Let me first preface this by stating very clearly: Firefox is NOT a > devel environment. BTW, I'm curious : will the Fedora Directory Server (n?e Netscape Directory Server) inclusion force some modularisation ? IIRC it shared quite a few libraries with Mozilla Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From peter at thecodergeek.com Fri Jan 5 17:53:13 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 05 Jan 2007 09:53:13 -0800 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <459E883F.1020208@redhat.com> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> <1168002886.3836.91.camel@zod.rchland.ibm.com> <459E883F.1020208@redhat.com> Message-ID: <1168019593.3318.2.camel@localhost> On Fri, 2007-01-05 at 12:17 -0500, Christopher Aillon wrote: > >> - of a mass rebuild > > > > Which is likely to get done anyway around Test2. It's been done for the > > past 2 releases. > > ...because of significant changes to the toolchain, not because we like > to do them. There's no guarantee we'll need one in any given release cycle. Over the past couple of releases we have done mass rebuilds also to ensure that packages have active maintainers, and not solely for toolchain fixes/etc. (Though, I don't remember if this was Extras only or all of Core as well.) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri Jan 5 18:00:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 5 Jan 2007 13:00:10 -0500 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168019593.3318.2.camel@localhost> References: <20070105074343.GB22825@neu.nirvana> <459E883F.1020208@redhat.com> <1168019593.3318.2.camel@localhost> Message-ID: <200701051300.10980.jkeating@redhat.com> On Friday 05 January 2007 12:53, Peter Gordon wrote: > Over the past couple of releases we have done mass rebuilds also to > ensure that packages have active maintainers, and not solely for > toolchain fixes/etc. (Though, I don't remember if this was Extras only > or all of Core as well.) Extras only, most often on the heels of a core rebuild for a technical reason. Usually extended to all of Extras for non-technical reasons. I'd rather not continue that pain through the entire combined repo. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jan 5 18:09:00 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 Jan 2007 19:09:00 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105145405.c9057674.bugs.michael@gmx.net> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> <20070105121000.GL4860@neu.nirvana> <20070105145405.c9057674.bugs.michael@gmx.net> Message-ID: <20070105180900.GF14050@neu.nirvana> On Fri, Jan 05, 2007 at 02:54:05PM +0100, Michael Schwendt wrote: > > How many packagers have been bitten by Requires: foo >= 2.0.1 while > > they really needed foo >= 17:2.0.1 > > Users, not packagers. That's the same, or if one get's bitten he bites the next in the food chain ;) > For everyone else including packagers, in the distribution there is > only one package "foo" [...] Nah, that's an arghument against having versioned dependencies at all, which is not what we want. > > and the next update needed at least 23:3.0. E.g. the epoch > > inflation everywhere make it mandatory to start checking all your > > versioned BRs and > > Versioned BRs are not affected, since the RPM Epoch never specifies an > API version. What makes you say this? How about epoch of the perl package itself? They very much define the ABI/API in this case by themselves. Furthermore the automated perl dependencies that by definition lack an epoch, can become an indirect BR quite easily ... Ask the people that had to cope with the epochs in perl itself, that required special handling in all perl dependency detection and that creates redundant parts of redhat-rpm-config that we cannot send back upstream, because any epochs are non-portable. So we get to sit on all the special handling stuff and this just for automatic depedencies for perl the package. Now for perl-foo-bar with an epoch the same story would need to get repeated, e.g. a requires on foo::bar greater than 1.0 one would need to lookup the table and check whether the user meant >= 1:0.03, >= 2:0.1, and map that bakc into the dependency generation. But noone want to do that pain again, so the depencny remains broken until noticed. Anyway: If epoch were an acronym, the E would stand for Evil. > Epochs are not evil. Even the old explicit "Epoch: 0" policy solved > more problems [of an epoch promotion bug in rpm] than it created, Ouch, no, let me respectfully disagree 100%. That broke apt, the only depsolver back in these days, and until we knew what it was it created an epoch inflation never seen again since. And it did solve nothing, because the problem was in comparing epoch "none" vs epoch "0", and guess what: There were no packages with explict epoch "0" back then. Anyway we're getting off-topic. If you consider epochs to not be evil, that's OK, we need someone to defend the accused ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Jan 5 18:12:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 05 Jan 2007 19:12:45 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <200701051300.10980.jkeating@redhat.com> References: <20070105074343.GB22825@neu.nirvana> <459E883F.1020208@redhat.com> <1168019593.3318.2.camel@localhost> <200701051300.10980.jkeating@redhat.com> Message-ID: <459E951D.3010703@leemhuis.info> Jesse Keating schrieb: > On Friday 05 January 2007 12:53, Peter Gordon wrote: >> Over the past couple of releases we have done mass rebuilds also to >> ensure that packages have active maintainers, and not solely for >> toolchain fixes/etc. (Though, I don't remember if this was Extras only >> or all of Core as well.) > Extras only, most often on the heels of a core rebuild for a technical reason. > Usually extended to all of Extras for non-technical reasons. I'd rather not > continue that pain through the entire combined repo. +1, but we need to work out another solution to check if maintainers are still around and *active* for real. CU thl From jspaleta at gmail.com Fri Jan 5 18:14:29 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 5 Jan 2007 09:14:29 -0900 Subject: Followup to FESCO meeting: firefox dependancy tracking. In-Reply-To: <459E85E0.8000804@redhat.com> References: <604aa7910701042317p7c2201b7p3f338b9bea49d15b@mail.gmail.com> <459E85E0.8000804@redhat.com> Message-ID: <604aa7910701051014j1d458b8dl5b16f52a98b26fb1@mail.gmail.com> On 1/5/07, Christopher Aillon wrote: > Having said that, every package in Core which needs to has always had an > explicit versioned requires (except for the packages in FC6 GOLD which > was an unfortunate regression, but long since fixed). See the latest > epiphany/devhelp/yelp RPMs for how to do the dependencies (I'm not sure > how they got in your list of non-versioned deps unless you looked at FC6 > GOLD). I ran multiple runs of repoquery with fc6,updates,updates-testing, and extras enabled. Please read my message again. The first group of packages are the packages that do not have a dep on firefox nor gecko-libs and that netted only 4 packages from Extras as ones with a potential issue. In total there are 13 packages that my repoquery runs showed depend on libraries from firefox. Since the number is so thankfully small, its no big deal to follow up and add versioned requirments on a case by case basis. And I have to stress to everyone that this was a first attempt to just identify the space of affected packages. repoquery definitely did not catch everything, and I probably fat-fingered some of my hand editting of the repoquery output. Since repoquery outputs all packages that match... not just the 'newest'... i cleaned up the output a bit and probably made a opps. I'm much more concerned about packages that are using the firefox libs but I can't see via the rpm deps at all. I can't think of a way to check for that without installing all of fedora-space on a system and doing a brute-force run of ldd looking for libxpcom for example. And I don't think we ever really fixed how readahead works to account for firefox's versioned directory. -jef From peter at thecodergeek.com Fri Jan 5 18:21:08 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 05 Jan 2007 10:21:08 -0800 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <200701051300.10980.jkeating@redhat.com> References: <20070105074343.GB22825@neu.nirvana> <459E883F.1020208@redhat.com> <1168019593.3318.2.camel@localhost> <200701051300.10980.jkeating@redhat.com> Message-ID: <1168021268.3318.3.camel@localhost> On Fri, 2007-01-05 at 13:00 -0500, Jesse Keating wrote: > Extras only, most often on the heels of a core rebuild for a technical reason. > Usually extended to all of Extras for non-technical reasons. I'd rather not > continue that pain through the entire combined repo. Thanks for the clarification, Jesse. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- 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 bugs.michael at gmx.net Fri Jan 5 19:05:24 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 5 Jan 2007 20:05:24 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105180900.GF14050@neu.nirvana> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> <20070105121000.GL4860@neu.nirvana> <20070105145405.c9057674.bugs.michael@gmx.net> <20070105180900.GF14050@neu.nirvana> Message-ID: <20070105200524.63115f03.bugs.michael@gmx.net> On Fri, 5 Jan 2007 19:09:00 +0100, Axel Thimm wrote: > > > How many packagers have been bitten by Requires: foo >= 2.0.1 while > > > they really needed foo >= 17:2.0.1 > > > > Users, not packagers. > > That's the same, or if one get's bitten he bites the next in the food > chain ;) The packagers made the packages, becauses the strict dependency works for them. But it's not transparent for the users. > > For everyone else including packagers, in the distribution there is > > only one package "foo" [...] > > Nah, that's an arghument against having versioned dependencies at all, > which is not what we want. It's an argument against superfluous and desolate versioned deps, yes. > > > and the next update needed at least 23:3.0. E.g. the epoch > > > inflation everywhere make it mandatory to start checking all your > > > versioned BRs and > > > > Versioned BRs are not affected, since the RPM Epoch never specifies an > > API version. > > What makes you say this? How about epoch of the perl package itself? It is specific to the RPM package, not defined by Perl at all. > They very much define the ABI/API in this case by themselves. There is no Epoch in Perl's versioning scheme. Not in the old one, and not in the new one either. > Furthermore the automated perl dependencies that by definition lack an > epoch, can become an indirect BR quite easily ... > > Ask the people that had to cope with the epochs in perl itself, that > required special handling in all perl dependency detection and that > creates redundant parts of redhat-rpm-config that we cannot send back > upstream, because any epochs are non-portable. So we get to sit on all > the special handling stuff and this just for automatic depedencies for > perl the package. Why do you want to add Epochs to versioned Perl dependencies? > > Epochs are not evil. Even the old explicit "Epoch: 0" policy solved > > more problems [of an epoch promotion bug in rpm] than it created, > > Ouch, no, let me respectfully disagree 100%. That broke apt, the only > depsolver back in these days, and until we knew what it was it created > an epoch inflation never seen again since. And it did solve nothing, > because the problem was in comparing epoch "none" vs epoch "0", c.f. http://www.wideopen.com/archives/rpm-list/2003-June/msg00137.html There are more gems to find. > and guess what: There were no packages with explict epoch "0" back then. It broke comparing "no Epoch" with "Epoch!=0". Sub-packages that were moved into a new main package with an own versioning scheme around that time were affected, for instance. From bugs.michael at gmx.net Fri Jan 5 19:13:12 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 5 Jan 2007 20:13:12 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168018947.3836.132.camel@zod.rchland.ibm.com> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> <1168002886.3836.91.camel@zod.rchland.ibm.com> <459E883F.1020208@redhat.com> <1168018947.3836.132.camel@zod.rchland.ibm.com> Message-ID: <20070105201312.c36b697f.bugs.michael@gmx.net> On Fri, 05 Jan 2007 11:42:27 -0600, Josh Boyer wrote: > On Fri, 2007-01-05 at 12:17 -0500, Christopher Aillon wrote: > > On 01/05/2007 08:14 AM, Josh Boyer wrote: > > > On Fri, 2007-01-05 at 12:56 +0100, Ralf Corsepius wrote: > > >> - of having to examine specs dist-tags > > > > > > They shouldn't have passed review if they are hard coded. If they did, > > > a bug needs to be opened to fix it anyway. > > > > You're thinking of only extras here. Many core packages used hardcoded > > dist tags long before we had the ability to do them. Additionally, > > specs in extras could get approved without dist tags and then have them > > hard coded in by someone who mightn't know better. > > The core packages need to go through a review for the merge anyway. And > the latter case is a bug :) It is not a bug. Semantically, a hardcoded dist tag can mean that the package has been developed (e.g. configured, patched, customised) and tested for the single specified distribution release and that nothing else is supported by the packager (not even if it works by coincidence). Rebuilding it without packaging changes and updating the dist tag automatically would be a bug. From jwboyer at jdub.homelinux.org Fri Jan 5 19:27:22 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 05 Jan 2007 13:27:22 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105201312.c36b697f.bugs.michael@gmx.net> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> <1168002886.3836.91.camel@zod.rchland.ibm.com> <459E883F.1020208@redhat.com> <1168018947.3836.132.camel@zod.rchland.ibm.com> <20070105201312.c36b697f.bugs.michael@gmx.net> Message-ID: <1168025242.3836.158.camel@zod.rchland.ibm.com> On Fri, 2007-01-05 at 20:13 +0100, Michael Schwendt wrote: > On Fri, 05 Jan 2007 11:42:27 -0600, Josh Boyer wrote: > > > On Fri, 2007-01-05 at 12:17 -0500, Christopher Aillon wrote: > > > On 01/05/2007 08:14 AM, Josh Boyer wrote: > > > > On Fri, 2007-01-05 at 12:56 +0100, Ralf Corsepius wrote: > > > >> - of having to examine specs dist-tags > > > > > > > > They shouldn't have passed review if they are hard coded. If they did, > > > > a bug needs to be opened to fix it anyway. > > > > > > You're thinking of only extras here. Many core packages used hardcoded > > > dist tags long before we had the ability to do them. Additionally, > > > specs in extras could get approved without dist tags and then have them > > > hard coded in by someone who mightn't know better. > > > > The core packages need to go through a review for the merge anyway. And > > the latter case is a bug :) > > It is not a bug. Semantically, a hardcoded dist tag can mean that the > package has been developed (e.g. configured, patched, customised) and > tested for the single specified distribution release and that nothing else > is supported by the packager (not even if it works by coincidence). > Rebuilding it without packaging changes and updating the dist tag > automatically would be a bug. No, it's a bug. Hardcoding the disttag is explicitly against the packaging guidelines. josh From tcallawa at redhat.com Fri Jan 5 19:32:36 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 05 Jan 2007 13:32:36 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168025242.3836.158.camel@zod.rchland.ibm.com> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> <1168002886.3836.91.camel@zod.rchland.ibm.com> <459E883F.1020208@redhat.com> <1168018947.3836.132.camel@zod.rchland.ibm.com> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168025242.3836.158.camel@zod.rchland.ibm.com> Message-ID: <1168025556.3161.131.camel@dhcp-32-109.ord.redhat.com> On Fri, 2007-01-05 at 13:27 -0600, Josh Boyer wrote: > On Fri, 2007-01-05 at 20:13 +0100, Michael Schwendt wrote: > > On Fri, 05 Jan 2007 11:42:27 -0600, Josh Boyer wrote: > > > > > On Fri, 2007-01-05 at 12:17 -0500, Christopher Aillon wrote: > > > > On 01/05/2007 08:14 AM, Josh Boyer wrote: > > > > > On Fri, 2007-01-05 at 12:56 +0100, Ralf Corsepius wrote: > > > > >> - of having to examine specs dist-tags > > > > > > > > > > They shouldn't have passed review if they are hard coded. If they did, > > > > > a bug needs to be opened to fix it anyway. > > > > > > > > You're thinking of only extras here. Many core packages used hardcoded > > > > dist tags long before we had the ability to do them. Additionally, > > > > specs in extras could get approved without dist tags and then have them > > > > hard coded in by someone who mightn't know better. > > > > > > The core packages need to go through a review for the merge anyway. And > > > the latter case is a bug :) > > > > It is not a bug. Semantically, a hardcoded dist tag can mean that the > > package has been developed (e.g. configured, patched, customised) and > > tested for the single specified distribution release and that nothing else > > is supported by the packager (not even if it works by coincidence). > > Rebuilding it without packaging changes and updating the dist tag > > automatically would be a bug. > > No, it's a bug. Hardcoding the disttag is explicitly against the > packaging guidelines. Indeed. Hardcoding the disttag is not permitted. The buildsystem will get it right when you set %{?dist}. ~spot From Axel.Thimm at ATrpms.net Fri Jan 5 19:32:45 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 Jan 2007 20:32:45 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105200524.63115f03.bugs.michael@gmx.net> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> <20070105121000.GL4860@neu.nirvana> <20070105145405.c9057674.bugs.michael@gmx.net> <20070105180900.GF14050@neu.nirvana> <20070105200524.63115f03.bugs.michael@gmx.net> Message-ID: <20070105193245.GG14050@neu.nirvana> On Fri, Jan 05, 2007 at 08:05:24PM +0100, Michael Schwendt wrote: > On Fri, 5 Jan 2007 19:09:00 +0100, Axel Thimm wrote: > > > > and the next update needed at least 23:3.0. E.g. the epoch > > > > inflation everywhere make it mandatory to start checking all your > > > > versioned BRs and > > > > > > Versioned BRs are not affected, since the RPM Epoch never specifies an > > > API version. > > > > What makes you say this? How about epoch of the perl package itself? > > It is specific to the RPM package, not defined by Perl at all. > > > They very much define the ABI/API in this case by themselves. > > There is no Epoch in Perl's versioning scheme. Not in the old one, > and not in the new one either. Ehem, perl itself is currently at epoch 4. Any package that needs to define that it needs a specific range of perl ABI/API to work with/build against needs to know the version-epoch mapping history of perl or to reply on artificially virtual provides. > Why do you want to add Epochs to versioned Perl dependencies? I don't, but if there are such I have to. Say for example that xmltv depends on perl(Lingua::Preferred) >= 0.2.4. If perl-Lingua-Preferred had an epoch the above check would need to get this epoch added and properly maintained by humans or machines. Anyway the world would be a better place w/o epochs. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Fri Jan 5 19:39:49 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 5 Jan 2007 20:39:49 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168025242.3836.158.camel@zod.rchland.ibm.com> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> <1168002886.3836.91.camel@zod.rchland.ibm.com> <459E883F.1020208@redhat.com> <1168018947.3836.132.camel@zod.rchland.ibm.com> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168025242.3836.158.camel@zod.rchland.ibm.com> Message-ID: <20070105203949.7a92a70c.bugs.michael@gmx.net> On Fri, 05 Jan 2007 13:27:22 -0600, Josh Boyer wrote: > > On Fri, 05 Jan 2007 11:42:27 -0600, Josh Boyer wrote: > > > > > On Fri, 2007-01-05 at 12:17 -0500, Christopher Aillon wrote: > > > > On 01/05/2007 08:14 AM, Josh Boyer wrote: > > > > > On Fri, 2007-01-05 at 12:56 +0100, Ralf Corsepius wrote: > > > > >> - of having to examine specs dist-tags > > > > > > > > > > They shouldn't have passed review if they are hard coded. If they did, > > > > > a bug needs to be opened to fix it anyway. > > > > > > > > You're thinking of only extras here. Many core packages used hardcoded > > > > dist tags long before we had the ability to do them. Additionally, > > > > specs in extras could get approved without dist tags and then have them > > > > hard coded in by someone who mightn't know better. > > > > > > The core packages need to go through a review for the merge anyway. And > > > the latter case is a bug :) > > > > It is not a bug. Semantically, a hardcoded dist tag can mean that the > > package has been developed (e.g. configured, patched, customised) and > > tested for the single specified distribution release and that nothing else > > is supported by the packager (not even if it works by coincidence). > > Rebuilding it without packaging changes and updating the dist tag > > automatically would be a bug. > > No, it's a bug. Hardcoding the disttag is explicitly against the > packaging guidelines. What a sad mistake. Well, in that case not using %{?dist} is a work-around. http://fedoraproject.org/wiki/Packaging/DistTag?action=diff&rev2=15&rev1=14 From jkeating at redhat.com Fri Jan 5 19:37:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 5 Jan 2007 14:37:50 -0500 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168025242.3836.158.camel@zod.rchland.ibm.com> References: <20070105074343.GB22825@neu.nirvana> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168025242.3836.158.camel@zod.rchland.ibm.com> Message-ID: <200701051437.50451.jkeating@redhat.com> On Friday 05 January 2007 14:27, Josh Boyer wrote: > > It is not a bug. Semantically, a hardcoded dist tag can mean that the > > package has been developed (e.g. configured, patched, customised) and > > tested for the single specified distribution release and that nothing > > else is supported by the packager (not even if it works by coincidence). > > Rebuilding it without packaging changes and updating the dist tag > > automatically would be a bug. > > No, it's a bug. ?Hardcoding the disttag is explicitly against the > packaging guidelines. Being in the guidelines does not automatically mean it is correct. We're humans, we make mistakes, we sometimes have narrow view of issues and don't anticipate other things. I see much value in Michael's statement, unfortunately I don't know of a good way to allow for that, but keep other people from shooting themselves in the foot with hardcoded dist tags. This is one of the reasons why its in the guidelines. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Fri Jan 5 19:45:09 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 05 Jan 2007 13:45:09 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <200701051437.50451.jkeating@redhat.com> References: <20070105074343.GB22825@neu.nirvana> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168025242.3836.158.camel@zod.rchland.ibm.com> <200701051437.50451.jkeating@redhat.com> Message-ID: <1168026309.3836.163.camel@zod.rchland.ibm.com> On Fri, 2007-01-05 at 14:37 -0500, Jesse Keating wrote: > On Friday 05 January 2007 14:27, Josh Boyer wrote: > > > It is not a bug. Semantically, a hardcoded dist tag can mean that the > > > package has been developed (e.g. configured, patched, customised) and > > > tested for the single specified distribution release and that nothing > > > else is supported by the packager (not even if it works by coincidence). > > > Rebuilding it without packaging changes and updating the dist tag > > > automatically would be a bug. > > > > No, it's a bug. Hardcoding the disttag is explicitly against the > > packaging guidelines. > > Being in the guidelines does not automatically mean it is correct. We're > humans, we make mistakes, we sometimes have narrow view of issues and don't > anticipate other things. Sure. But unless the guidelines are changed, it's a bug. Look at it this way, a new package the violates the guidelines either gets fixed or doesn't get in. Any existing package hardcoding it therefore has a bug. > I see much value in Michael's statement, unfortunately I don't know of a good > way to allow for that, but keep other people from shooting themselves in the > foot with hardcoded dist tags. This is one of the reasons why its in the > guidelines. Right. josh From jwboyer at jdub.homelinux.org Fri Jan 5 19:46:15 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 05 Jan 2007 13:46:15 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105203949.7a92a70c.bugs.michael@gmx.net> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> <1168002886.3836.91.camel@zod.rchland.ibm.com> <459E883F.1020208@redhat.com> <1168018947.3836.132.camel@zod.rchland.ibm.com> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168025242.3836.158.camel@zod.rchland.ibm.com> <20070105203949.7a92a70c.bugs.michael@gmx.net> Message-ID: <1168026375.3836.165.camel@zod.rchland.ibm.com> On Fri, 2007-01-05 at 20:39 +0100, Michael Schwendt wrote: > On Fri, 05 Jan 2007 13:27:22 -0600, Josh Boyer wrote: > > > > On Fri, 05 Jan 2007 11:42:27 -0600, Josh Boyer wrote: > > > > > > > On Fri, 2007-01-05 at 12:17 -0500, Christopher Aillon wrote: > > > > > On 01/05/2007 08:14 AM, Josh Boyer wrote: > > > > > > On Fri, 2007-01-05 at 12:56 +0100, Ralf Corsepius wrote: > > > > > >> - of having to examine specs dist-tags > > > > > > > > > > > > They shouldn't have passed review if they are hard coded. If they did, > > > > > > a bug needs to be opened to fix it anyway. > > > > > > > > > > You're thinking of only extras here. Many core packages used hardcoded > > > > > dist tags long before we had the ability to do them. Additionally, > > > > > specs in extras could get approved without dist tags and then have them > > > > > hard coded in by someone who mightn't know better. > > > > > > > > The core packages need to go through a review for the merge anyway. And > > > > the latter case is a bug :) > > > > > > It is not a bug. Semantically, a hardcoded dist tag can mean that the > > > package has been developed (e.g. configured, patched, customised) and > > > tested for the single specified distribution release and that nothing else > > > is supported by the packager (not even if it works by coincidence). > > > Rebuilding it without packaging changes and updating the dist tag > > > automatically would be a bug. > > > > No, it's a bug. Hardcoding the disttag is explicitly against the > > packaging guidelines. > > What a sad mistake. Well, in that case not using %{?dist} is a > work-around. Very true. > > http://fedoraproject.org/wiki/Packaging/DistTag?action=diff&rev2=15&rev1=14 That was already implied by the line above it, but it was unclear. I asked it to be clarified. josh From ajackson at redhat.com Fri Jan 5 19:42:47 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 05 Jan 2007 14:42:47 -0500 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <200701051437.50451.jkeating@redhat.com> References: <20070105074343.GB22825@neu.nirvana> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168025242.3836.158.camel@zod.rchland.ibm.com> <200701051437.50451.jkeating@redhat.com> Message-ID: <1168026167.7683.583.camel@localhost.localdomain> On Fri, 2007-01-05 at 14:37 -0500, Jesse Keating wrote: > On Friday 05 January 2007 14:27, Josh Boyer wrote: > > > It is not a bug. Semantically, a hardcoded dist tag can mean that the > > > package has been developed (e.g. configured, patched, customised) and > > > tested for the single specified distribution release and that nothing > > > else is supported by the packager (not even if it works by coincidence). > > > Rebuilding it without packaging changes and updating the dist tag > > > automatically would be a bug. > > > > No, it's a bug. Hardcoding the disttag is explicitly against the > > packaging guidelines. > > Being in the guidelines does not automatically mean it is correct. We're > humans, we make mistakes, we sometimes have narrow view of issues and don't > anticipate other things. > > I see much value in Michael's statement, unfortunately I don't know of a good > way to allow for that, but keep other people from shooting themselves in the > foot with hardcoded dist tags. This is one of the reasons why its in the > guidelines. Prohibit hardcoding in devel, allow it in release branches if it matches what %{dist} would expand to? - ajax From buildsys at fedoraproject.org Fri Jan 5 20:17:38 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 5 Jan 2007 15:17:38 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-01-05 Message-ID: <20070105201738.1ACF615212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): dbus FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) cgoorah AT yahoo.com.au: ngspice FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) devrim AT commandprompt.com: phpPgAdmin FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-7.fc6 > 0:1.4.2.cvs20060817-5.fc7) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) tcallawa AT redhat.com: ntfs-3g FE5 > FE7 (2:0-0.7.20070920.fc5 > 1:0-0.6.20070102.fc7) FE6 > FE7 (2:0-0.7.20070920.fc6 > 1:0-0.6.20070102.fc7) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-7.fc6 > 0:1.4.2.cvs20060817-5.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) ngspice: cgoorah AT yahoo.com.au FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) ntfs-3g: tcallawa AT redhat.com FE5 > FE7 (2:0-0.7.20070920.fc5 > 1:0-0.6.20070102.fc7) FE6 > FE7 (2:0-0.7.20070920.fc6 > 1:0-0.6.20070102.fc7) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) phpPgAdmin: devrim AT commandprompt.com FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From bugs.michael at gmx.net Fri Jan 5 20:20:08 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 5 Jan 2007 21:20:08 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105193245.GG14050@neu.nirvana> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> <20070105121000.GL4860@neu.nirvana> <20070105145405.c9057674.bugs.michael@gmx.net> <20070105180900.GF14050@neu.nirvana> <20070105200524.63115f03.bugs.michael@gmx.net> <20070105193245.GG14050@neu.nirvana> Message-ID: <20070105212008.3b5c0323.bugs.michael@gmx.net> On Fri, 5 Jan 2007 20:32:45 +0100, Axel Thimm wrote: > On Fri, Jan 05, 2007 at 08:05:24PM +0100, Michael Schwendt wrote: > > On Fri, 5 Jan 2007 19:09:00 +0100, Axel Thimm wrote: > > > > > and the next update needed at least 23:3.0. E.g. the epoch > > > > > inflation everywhere make it mandatory to start checking all your > > > > > versioned BRs and > > > > > > > > Versioned BRs are not affected, since the RPM Epoch never specifies an > > > > API version. > > > > > > What makes you say this? How about epoch of the perl package itself? > > > > It is specific to the RPM package, not defined by Perl at all. > > > > > They very much define the ABI/API in this case by themselves. > > > > There is no Epoch in Perl's versioning scheme. Not in the old one, > > and not in the new one either. > > Ehem, perl itself is currently at epoch 4. Perl itself isn't, the RPM package in FC6 is "perl <= 4:5.8.8". > Any package that needs to > define that it needs a specific range of perl ABI/API to work > with/build against needs to know the version-epoch mapping history of > perl or to reply on artificially virtual provides. You build against a single target. In FC6 it's Perl v5.8.8. Its API/ABI is defined by its version and in detail by a lot of stuff in the "Provides". The Epoch of the RPM package has nothing to do with that. > > Why do you want to add Epochs to versioned Perl dependencies? > > I don't, but if there are such I have to. Say for example that xmltv > depends on perl(Lingua::Preferred) >= 0.2.4. If perl-Lingua-Preferred > had an epoch the above check would need to get this epoch added and > properly maintained by humans or machines. Why? You want 'perl(Lingua::Preferred) >= 0.2.4', and either your build/target environment provides this version or not. From caillon at redhat.com Fri Jan 5 21:33:09 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 05 Jan 2007 16:33:09 -0500 Subject: Followup to FESCO meeting: firefox dependancy tracking. In-Reply-To: <1168019206.10184.2.camel@rousalka.dyndns.org> References: <604aa7910701042317p7c2201b7p3f338b9bea49d15b@mail.gmail.com> <459E85E0.8000804@redhat.com> <1168019206.10184.2.camel@rousalka.dyndns.org> Message-ID: <459EC415.4030402@redhat.com> On 01/05/2007 12:46 PM, Nicolas Mailhot wrote: > Le vendredi 05 janvier 2007 ? 12:07 -0500, Christopher Aillon a ?crit : >> Let me first preface this by stating very clearly: Firefox is NOT a >> devel environment. > > BTW, I'm curious : will the Fedora Directory Server (n?e Netscape > Directory Server) inclusion force some modularisation ? IIRC it shared > quite a few libraries with Mozilla > nss and nspr are split out already. the LDAP stuff is being split out I'm told. I'm guessing it's not a priority for any of the teams, so help might be nice. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From caillon at redhat.com Fri Jan 5 21:41:39 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 05 Jan 2007 16:41:39 -0500 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <459E951D.3010703@leemhuis.info> References: <20070105074343.GB22825@neu.nirvana> <459E883F.1020208@redhat.com> <1168019593.3318.2.camel@localhost> <200701051300.10980.jkeating@redhat.com> <459E951D.3010703@leemhuis.info> Message-ID: <459EC613.3020200@redhat.com> On 01/05/2007 01:12 PM, Thorsten Leemhuis wrote: > Jesse Keating schrieb: >> On Friday 05 January 2007 12:53, Peter Gordon wrote: >>> Over the past couple of releases we have done mass rebuilds also to >>> ensure that packages have active maintainers, and not solely for >>> toolchain fixes/etc. (Though, I don't remember if this was Extras only >>> or all of Core as well.) >> Extras only, most often on the heels of a core rebuild for a technical reason. >> Usually extended to all of Extras for non-technical reasons. I'd rather not >> continue that pain through the entire combined repo. > > +1, but we need to work out another solution to check if maintainers are > still around and *active* for real. Check whether their certs have expired (plus adequate grace period). If renewing every 12 months isn't interesting enough, that number can be changed. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From nicolas.mailhot at laposte.net Fri Jan 5 22:07:44 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 05 Jan 2007 23:07:44 +0100 Subject: Followup to FESCO meeting: firefox dependancy tracking. In-Reply-To: <459EC415.4030402@redhat.com> References: <604aa7910701042317p7c2201b7p3f338b9bea49d15b@mail.gmail.com> <459E85E0.8000804@redhat.com> <1168019206.10184.2.camel@rousalka.dyndns.org> <459EC415.4030402@redhat.com> Message-ID: <1168034864.3611.0.camel@rousalka.dyndns.org> Le vendredi 05 janvier 2007 ? 16:33 -0500, Christopher Aillon a ?crit : > On 01/05/2007 12:46 PM, Nicolas Mailhot wrote: > > Le vendredi 05 janvier 2007 ? 12:07 -0500, Christopher Aillon a ?crit : > >> Let me first preface this by stating very clearly: Firefox is NOT a > >> devel environment. > > > > BTW, I'm curious : will the Fedora Directory Server (n?e Netscape > > Directory Server) inclusion force some modularisation ? IIRC it shared > > quite a few libraries with Mozilla > > > > nss and nspr are split out already. the LDAP stuff is being split out > I'm told. I'm guessing it's not a priority for any of the teams, so > help might be nice. Actually I asked because I remember the ldapsdk & jss bits as hellish to package:) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From a.badger at gmail.com Sat Jan 6 07:41:44 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 05 Jan 2007 23:41:44 -0800 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <200701051437.50451.jkeating@redhat.com> References: <20070105074343.GB22825@neu.nirvana> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168025242.3836.158.camel@zod.rchland.ibm.com> <200701051437.50451.jkeating@redhat.com> Message-ID: <1168069304.14818.53.camel@localhost.localdomain> On Fri, 2007-01-05 at 14:37 -0500, Jesse Keating wrote: > On Friday 05 January 2007 14:27, Josh Boyer wrote: > > > It is not a bug. Semantically, a hardcoded dist tag can mean that the > > > package has been developed (e.g. configured, patched, customised) and > > > tested for the single specified distribution release and that nothing > > > else is supported by the packager (not even if it works by coincidence). > > > Rebuilding it without packaging changes and updating the dist tag > > > automatically would be a bug. > > > > No, it's a bug. Hardcoding the disttag is explicitly against the > > packaging guidelines. > > Being in the guidelines does not automatically mean it is correct. We're > humans, we make mistakes, we sometimes have narrow view of issues and don't > anticipate other things. > Right. I think in this case the first thing I'd want to know is what does hardcoding a disttag buy you that not having a disttag at all does not? With that information, a more informed decision could be made. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Sat Jan 6 09:31:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 6 Jan 2007 10:31:40 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105212008.3b5c0323.bugs.michael@gmx.net> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> <20070105121000.GL4860@neu.nirvana> <20070105145405.c9057674.bugs.michael@gmx.net> <20070105180900.GF14050@neu.nirvana> <20070105200524.63115f03.bugs.michael@gmx.net> <20070105193245.GG14050@neu.nirvana> <20070105212008.3b5c0323.bugs.michael@gmx.net> Message-ID: <20070106093140.GB27313@neu.nirvana> On Fri, Jan 05, 2007 at 09:20:08PM +0100, Michael Schwendt wrote: > On Fri, 5 Jan 2007 20:32:45 +0100, Axel Thimm wrote: > > > On Fri, Jan 05, 2007 at 08:05:24PM +0100, Michael Schwendt wrote: > > > On Fri, 5 Jan 2007 19:09:00 +0100, Axel Thimm wrote: > > > > > > and the next update needed at least 23:3.0. E.g. the epoch > > > > > > inflation everywhere make it mandatory to start checking all your > > > > > > versioned BRs and > > > > > > > > > > Versioned BRs are not affected, since the RPM Epoch never specifies an > > > > > API version. > > > > > > > > What makes you say this? How about epoch of the perl package itself? > > > > > > It is specific to the RPM package, not defined by Perl at all. > > > > > > > They very much define the ABI/API in this case by themselves. > > > > > > There is no Epoch in Perl's versioning scheme. Not in the old one, > > > and not in the new one either. > > > > Ehem, perl itself is currently at epoch 4. > > Perl itself isn't, the RPM package in FC6 is "perl <= 4:5.8.8". Exactly, and we're talking about package dependencies and how the ugly epoch is needed for expressing the desired API/ABI in BuildRequires. > > Any package that needs to define that it needs a specific range of > > perl ABI/API to work with/build against needs to know the > > version-epoch mapping history of perl or to reply on artificially > > virtual provides. > > You build against a single target. In FC6 it's Perl v5.8.8. Its API/ABI > is defined by its version and in detail by a lot of stuff in the > "Provides". The Epoch of the RPM package has nothing to do with > that. You are promoting to tailor specfiles against target releases. This is a wrong thing to do for many things, for one I want to keep the same specfile across different releases (*and* distributions like Fedora <-> RHEL specfile sharing). Removing all versioning in specfiles because "we know" fcN has foo version XYZ leads to broken and low-quality specfiles. > > > Why do you want to add Epochs to versioned Perl dependencies? > > > > I don't, but if there are such I have to. Say for example that xmltv > > depends on perl(Lingua::Preferred) >= 0.2.4. If perl-Lingua-Preferred > > had an epoch the above check would need to get this epoch added and > > properly maintained by humans or machines. > > Why? You want 'perl(Lingua::Preferred) >= 0.2.4', and either your > build/target environment provides this version or not. And it may even provide it with a lower version and a higher epoch, so my version requirements go banana. Epoch bad. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sat Jan 6 11:43:42 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 6 Jan 2007 12:43:42 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070106093140.GB27313@neu.nirvana> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> <20070105121000.GL4860@neu.nirvana> <20070105145405.c9057674.bugs.michael@gmx.net> <20070105180900.GF14050@neu.nirvana> <20070105200524.63115f03.bugs.michael@gmx.net> <20070105193245.GG14050@neu.nirvana> <20070105212008.3b5c0323.bugs.michael@gmx.net> <20070106093140.GB27313@neu.nirvana> Message-ID: <20070106124342.0543e627.bugs.michael@gmx.net> On Sat, 6 Jan 2007 10:31:40 +0100, Axel Thimm wrote: > > > > > What makes you say this? How about epoch of the perl package itself? > > > > > > > > It is specific to the RPM package, not defined by Perl at all. > > > > > > > > > They very much define the ABI/API in this case by themselves. > > > > > > > > There is no Epoch in Perl's versioning scheme. Not in the old one, > > > > and not in the new one either. > > > > > > Ehem, perl itself is currently at epoch 4. > > > > Perl itself isn't, the RPM package in FC6 is "perl <= 4:5.8.8". > > Exactly, and we're talking about package dependencies and how the ugly > epoch is needed for expressing the desired API/ABI in BuildRequires. You don't need to. The Epoch is irrelevant in Perl's API/ABI definition. "perl <= 4:5.8.8" means that any version, any Epoch is provided. You could do "Requires: perl = 2:5.005" and "Requires: perl = 1:4", it would be satisfied, too. Btw, defining Perl's ABI via a single integer would be very close to an impossible mission. > > > Any package that needs to define that it needs a specific range of > > > perl ABI/API to work with/build against needs to know the > > > version-epoch mapping history of perl or to reply on artificially > > > virtual provides. > > > > You build against a single target. In FC6 it's Perl v5.8.8. Its API/ABI > > is defined by its version and in detail by a lot of stuff in the > > "Provides". The Epoch of the RPM package has nothing to do with > > that. > > You are promoting to tailor specfiles against target > releases. Non-versioned dependencies in spec files are more portable than versioned ones. Generally, I promote build requirement checks in configure scripts. There are too many ">=" requirements in spec files, which are out-of-date, superfluous, or plain wrong. At run-time, only exact dependencies help. Any ">=" is dangerous when no other safety checks are active. On the other hand, if you refer to mass-updates, where an updated spec file is copied over to multiple target releases and alters history (e.g. in %changelogs), yes, I would be better if that were not done. > This is a wrong thing to do for many things, for one I want > to keep the same specfile across different releases (*and* > distributions like Fedora <-> RHEL specfile sharing). Removing all > versioning in specfiles because "we know" fcN has foo version XYZ > leads to broken and low-quality specfiles. Hmm, that are your personal preferences which conflict with what can happen due to Epochs in RPM version comparison. Personally, I don't like to rely on the relationship of different products. The life-time of a package in one distribution could have lead to a different EVR than with another distribution. At least where using Epoch instead of a versioning scheme for pre-releases is not forbidden. Further, a "Dist Epoch" preferably would not be visible in spec files. It would only help in answering the question which of two packages is for a newer distribution. Upgrade path sanity. > > > > Why do you want to add Epochs to versioned Perl dependencies? > > > > > > I don't, but if there are such I have to. Say for example that xmltv > > > depends on perl(Lingua::Preferred) >= 0.2.4. If perl-Lingua-Preferred > > > had an epoch the above check would need to get this epoch added and > > > properly maintained by humans or machines. > > > > Why? You want 'perl(Lingua::Preferred) >= 0.2.4', and either your > > build/target environment provides this version or not. > > And it may even provide it with a lower version and a higher epoch, so > my version requirements go banana. > > Epoch bad. No. A Perl module definition does not have any RPM Epoch in its versioning. Never. You require an Epoch-less Perl module "Provides". A lower module version would provide 'perl(Lingua::Preferred) = 0.2.0', for example, which would break your dependency even if the RPM had an increased Epoch. 0.2.0 < 0.2.4 The Epoch is irrelevant here. So, let's escape from this bad example, please. Assuming you meant a package dependency in general, not a dependency on a Perl module, adding an Epoch to your versioned requirement does not help either. Any increase in Epoch would break the dependency. If you only wanted to demonstrate that, no need to go in circles and drag in Perl stuff. It is ">=" which is bad already. Any increase in Version could make it break, too, since you don't guarantee that 'perl(Lingua::Preferred) = 0.3.0' is compatible, and neither 'perl-Lingua-Preferred = 0.4.0'. Going back to a lower version plus setting Epoch is the bad thing. Sure. But there is no alternative solution (other than a silent and questionable rollback) for downgrades during development. Still, it is possible to omit Epochs from automated dependency checks, provided that any versioned requirements in binary rpms are accurate enough. From bugs.michael at gmx.net Sat Jan 6 11:49:33 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 6 Jan 2007 12:49:33 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168069304.14818.53.camel@localhost.localdomain> References: <20070105074343.GB22825@neu.nirvana> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168025242.3836.158.camel@zod.rchland.ibm.com> <200701051437.50451.jkeating@redhat.com> <1168069304.14818.53.camel@localhost.localdomain> Message-ID: <20070106124933.5e340e20.bugs.michael@gmx.net> On Fri, 05 Jan 2007 23:41:44 -0800, Toshio Kuratomi wrote: > Right. I think in this case the first thing I'd want to know is what > does hardcoding a disttag buy you that not having a disttag at all does > not? With that information, a more informed decision could be made. Hardcoding a dist tag explicitly flags the package as being made for that dist by the packager. That is visible in the file name, too. A simple mass-rebuild would not pretend that the package has been updated (read: prepared for the new dist). It would need a package maintainer to update customisation and integration patches first before changing the dist tag would make sense. From Axel.Thimm at ATrpms.net Sat Jan 6 11:59:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 6 Jan 2007 12:59:59 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070106124342.0543e627.bugs.michael@gmx.net> References: <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> <20070105121000.GL4860@neu.nirvana> <20070105145405.c9057674.bugs.michael@gmx.net> <20070105180900.GF14050@neu.nirvana> <20070105200524.63115f03.bugs.michael@gmx.net> <20070105193245.GG14050@neu.nirvana> <20070105212008.3b5c0323.bugs.michael@gmx.net> <20070106093140.GB27313@neu.nirvana> <20070106124342.0543e627.bugs.michael@gmx.net> Message-ID: <20070106115959.GC6654@neu.nirvana> On Sat, Jan 06, 2007 at 12:43:42PM +0100, Michael Schwendt wrote: > > Exactly, and we're talking about package dependencies and how the ugly > > epoch is needed for expressing the desired API/ABI in BuildRequires. > > You don't need to. The Epoch is irrelevant in Perl's API/ABI definition. > "perl <= 4:5.8.8" means that any version, any Epoch is provided. You could > do "Requires: perl = 2:5.005" and "Requires: perl = 1:4", it would be > satisfied, too. As well as Required: perl >= 6, because the epoch was forgotten => broken package => epoch bad > > You are promoting to tailor specfiles against target releases. > > Non-versioned dependencies in spec files are more portable than > versioned ones. On the first look only, because the package layer allows you to push the package in. The missing dependency information will reveal itself later while building or even worse, while running => broken package => removing versioned dependencies and relying on target platform bad, and since you suggest that as a workaround due to epoching: => epoch bad > > This is a wrong thing to do for many things, for one I want > > to keep the same specfile across different releases (*and* > > distributions like Fedora <-> RHEL specfile sharing). Removing all > > versioning in specfiles because "we know" fcN has foo version XYZ > > leads to broken and low-quality specfiles. > > Hmm, that are your personal preferences which conflict with what can > happen due to Epochs in RPM version comparison. ??? > Personally, I don't like to rely on the relationship of different > products. So remove all dependencies and go LFS? Not a good idea. 10: > > Epoch bad. > > No. goto 10: Can we simply agree that we are 180? of different opinion and get out of the loop? I think I need to bring this up at the fedora-packaging list - I thought that epochs being evil was rather common knowledge and since it's not we noeed to put a recommendation against using them in the guidelines. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sat Jan 6 12:16:46 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 6 Jan 2007 13:16:46 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070106115959.GC6654@neu.nirvana> References: <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> <20070105121000.GL4860@neu.nirvana> <20070105145405.c9057674.bugs.michael@gmx.net> <20070105180900.GF14050@neu.nirvana> <20070105200524.63115f03.bugs.michael@gmx.net> <20070105193245.GG14050@neu.nirvana> <20070105212008.3b5c0323.bugs.michael@gmx.net> <20070106093140.GB27313@neu.nirvana> <20070106124342.0543e627.bugs.michael@gmx.net> <20070106115959.GC6654@neu.nirvana> Message-ID: <20070106131646.6bf12c56.bugs.michael@gmx.net> On Sat, 6 Jan 2007 12:59:59 +0100, Axel Thimm wrote: > 10: > > > Epoch bad. > > > > No. > > goto 10: Amusing how you cut off a long paragraph about improperly versioned Perl dependencies only to alter the context of my "No". > Can we simply agree that we are 180? of different opinion and get out > of the loop? Yes. From buildsys at fedoraproject.org Sat Jan 6 21:48:34 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 6 Jan 2007 16:48:34 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-01-06 Message-ID: <20070106214834.8EBEA15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): dbus FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) cgoorah AT yahoo.com.au: ngspice FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) devrim AT commandprompt.com: phpPgAdmin FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-5.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-6.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) tcallawa AT redhat.com: ntfs-3g FE5 > FE7 (2:0-0.7.20070920.fc5 > 1:0-0.6.20070102.fc7) FE6 > FE7 (2:0-0.7.20070920.fc6 > 1:0-0.6.20070102.fc7) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) ngspice: cgoorah AT yahoo.com.au FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) ntfs-3g: tcallawa AT redhat.com FE5 > FE7 (2:0-0.7.20070920.fc5 > 1:0-0.6.20070102.fc7) FE6 > FE7 (2:0-0.7.20070920.fc6 > 1:0-0.6.20070102.fc7) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) phpPgAdmin: devrim AT commandprompt.com FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-5.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-6.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From devrim at CommandPrompt.com Sat Jan 6 22:17:02 2007 From: devrim at CommandPrompt.com (Devrim GUNDUZ) Date: Sun, 07 Jan 2007 00:17:02 +0200 Subject: Package EVR problems in FC+FE 2007-01-06 In-Reply-To: <20070106214834.8EBEA15212E@buildsys.fedoraproject.org> References: <20070106214834.8EBEA15212E@buildsys.fedoraproject.org> Message-ID: <1168121822.27612.18.camel@laptop.gunduz.org> Hi, On Sat, 2007-01-06 at 16:48 -0500, buildsys at fedoraproject.org wrote: > devrim AT commandprompt.com: > phpPgAdmin > FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) This is not a real problem; and it will be fixed when 4.1 stable will be released. -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- 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 tcallawa at redhat.com Sun Jan 7 01:47:34 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 06 Jan 2007 19:47:34 -0600 Subject: Package EVR problems in FC+FE 2007-01-06 In-Reply-To: <20070106214834.8EBEA15212E@buildsys.fedoraproject.org> References: <20070106214834.8EBEA15212E@buildsys.fedoraproject.org> Message-ID: <1168134454.3341.35.camel@dhcp-32-109.ord.redhat.com> On Sat, 2007-01-06 at 16:48 -0500, buildsys at fedoraproject.org wrote: > tcallawa AT redhat.com: > ntfs-3g > FE5 > FE7 (2:0-0.7.20070920.fc5 > 1:0-0.6.20070102.fc7) > FE6 > FE7 (2:0-0.7.20070920.fc6 > 1:0-0.6.20070102.fc7) I had to epoch bump to rollback to the previous build, because the new ntfs-3g (which fixes a rather serious bug) requires the fuse kernel module >= 2.6.0, but the FC5/FC6 kernel doesn't yet have that new of a fuse kernel module. Development has a new enough fuse kernel module, so I didn't roll it back there. Hopefully, we'll get a kernel update with the new fuse module for FC5/FC6, and at that point, I'll fix up the epoch fun. ~spot From bugs.michael at gmx.net Sun Jan 7 10:42:26 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 7 Jan 2007 11:42:26 +0100 Subject: FC5 =?iso-8859-1?q?=B7?= Extras rebuilds =?iso-8859-1?q?=B7?= mozilla -> seamonkey Message-ID: <20070107114226.624ff9b6.bugs.michael@gmx.net> To all FC5 Extras packagers, who have a dependency on "mozilla" or on its sub-packages: https://www.redhat.com/archives/fedora-de-list/2007-January/msg00024.html You may need to rebuild your packages against "seamonkey-devel" and update your explicit "Requires", regardless of whether the broken deps report has caught this. seamonkey* in FC5 updates obsoletes mozilla* and provides it with a new version, 37:1.8, which breaks dependencies. The next run of the broken deps script will catch these obsoletes, too and also send a mail. Independent of that I've filed a ticket about galeon and liferea already. But I guess they are not the only two packages which depend on mozilla. From Axel.Thimm at ATrpms.net Sun Jan 7 13:35:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 7 Jan 2007 14:35:11 +0100 Subject: epel In-Reply-To: <459E495D.6080706@leemhuis.info> References: <459C082E.3090502@leemhuis.info> <20070105101907.42e8b57c.bugs.michael@gmx.net> <1167997820.3159.39.camel@vader.jdub.homelinux.org> <20070105115713.GK4860@neu.nirvana> <459E3FAA.500@leemhuis.info> <20070105121853.GN4860@neu.nirvana> <459E495D.6080706@leemhuis.info> Message-ID: <20070107133511.GC26973@neu.nirvana> On Fri, Jan 05, 2007 at 01:49:33PM +0100, Thorsten Leemhuis wrote: > On 05.01.2007 13:18, Axel Thimm wrote: > >On Fri, Jan 05, 2007 at 01:08:10PM +0100, Thorsten Leemhuis wrote: > >>On 05.01.2007 12:57, Axel Thimm wrote: > >>>On Fri, Jan 05, 2007 at 05:50:20AM -0600, Josh Boyer wrote: > >>>>I believe EPEL is open to contributors that currently have 5 or more > >>>>packages and/or sponsor status. There is no need to wait for Luke's > >>>>work. > >>>>However, one thing that contributors might want wait on is an updated > >>>>mock package with EPEL configs. I've got a bug opened to get that done > >>>>and just need to find some time. > >>>What exactly does a contributor need to do to branch into which RHEL > >>>branches? And where do the packages land in? > >>Dgilmore promised in yesterday meeting to > >>- send a mail that answers this sort of questions > >>- that he'll try to drive this whole effort a bit more to get it > >>flying - but I'm sure he'll be glad if people help. A real EPEL SIG that > >>meets now and then and works out the details and leads EPEL is IMHO > >>overdue. > >Well, I was very eager to help from the very beginning (I think my > >whining got Karsten to setup the 108 list), but w/o any info I don't > >have a handle to do anything. > > The FESCo <-> "Packager community" communication is IMHO the > problem. Hm, I think the meeting minutes are quite OK. Rather concise and still it looks like they are covering everything. > >Perhaps it was wrong to move the discussion out of the 108 list, > >because now noone really knows who is doing what where and what is > >being discussed by which parties. > > Might be part of the problem (others will say that more mailing lists > are the problem), but the real problem IMHO is: It lacked a real driver. > I tried to do that, but I'm buried with other work already and thus > tried to move it over to mmcgrath and dgilmore. They did a lot of work > for it, but they have a lot of other work to do already, too. :-/ I was trying to become a driver, and the 108 mailing list already started looking like a SIG, since the people Karsten had acquired there were really interested in a RHEL branch. But then the SIG was more or less spilled into the infinite Fedora space and lost coherency and signal. I think this was one of the cases where deframentation led to opposite results, and the current merge hype (not the one of Core and Extras, but of all lists and wiki namespaces) may create other such disadvantageous situations. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seg at haxxed.com Sun Jan 7 20:02:46 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 07 Jan 2007 14:02:46 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105201312.c36b697f.bugs.michael@gmx.net> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> <1168002886.3836.91.camel@zod.rchland.ibm.com> <459E883F.1020208@redhat.com> <1168018947.3836.132.camel@zod.rchland.ibm.com> <20070105201312.c36b697f.bugs.michael@gmx.net> Message-ID: <1168200167.6142.13.camel@max.booze> On Fri, 2007-01-05 at 20:13 +0100, Michael Schwendt wrote: > It is not a bug. Semantically, a hardcoded dist tag can mean that the > package has been developed (e.g. configured, patched, customised) and > tested for the single specified distribution release and that nothing else > is supported by the packager (not even if it works by coincidence). > Rebuilding it without packaging changes and updating the dist tag > automatically would be a bug. I dare say this is crackrock. The dist tag says what distribution the package was built against. Not "intended to be built against". And hardcoding it does not actually stop it from building on the "wrong dist", does it? You've only created a confusing situation where you have a distag of say "fc42" on a package even though it was built against fc666. If you're really that worried about a package only building on a certain dist, put a (pseudocode) 'if (%{dist} != fc42 and %{dist} != "") then exit 1' check in %prep or something. That will ACTUALLY kill the build on the "wrong dist". IMHO, %{?dist} should be a MUST unless there's a damn good reason for it, like the "giant huge mirror killing binary blob of game data" case. -------------- 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 seg at haxxed.com Sun Jan 7 20:11:19 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 07 Jan 2007 14:11:19 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <459E5D9D.4060800@timj.co.uk> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> <459E5D9D.4060800@timj.co.uk> Message-ID: <1168200679.6142.20.camel@max.booze> On Fri, 2007-01-05 at 14:15 +0000, Tim Jackson wrote: > rpm -i foo-1.0.i386.rpm > rpm -U foo-1.1.i386.rpm > > gives an error about foo-1.1 being an older version. (in the case that > the Epoch on foo-1.1 is lower than that on foo-1.0) > > Even though I'm a packager and I know about epochs, I still occasionally > have a head-scratching moment related to something like this. Something similarly irritating is that the arch isn't shown, which causes me constant pain on x86_64. I finally managed to hack this together with the help of some googling, put this in ~/.rpmmacros: %_query_all_fmt %{name}-%|epoch?{%{epoch}:}| %{version}-%{release}.%{arch} Is there any reason this can't become default in our shiny new community rpm fork? -------------- 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 seg at haxxed.com Sun Jan 7 20:16:47 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 07 Jan 2007 14:16:47 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168200167.6142.13.camel@max.booze> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> <1168002886.3836.91.camel@zod.rchland.ibm.com> <459E883F.1020208@redhat.com> <1168018947.3836.132.camel@zod.rchland.ibm.com> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168200167.6142.13.camel@max.booze> Message-ID: <1168201007.6142.22.camel@max.booze> On Sun, 2007-01-07 at 14:02 -0600, Callum Lerwick wrote: > IMHO, %{?dist} should be a MUST unless there's a damn good reason for > it, like the "giant huge mirror killing binary blob of game data" case. Make that the "giant huge mirror killing binary blob of **noarch** game data" case. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sun Jan 7 20:15:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 7 Jan 2007 15:15:28 -0500 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168200679.6142.20.camel@max.booze> References: <20070105074343.GB22825@neu.nirvana> <459E5D9D.4060800@timj.co.uk> <1168200679.6142.20.camel@max.booze> Message-ID: <200701071515.28502.jkeating@redhat.com> On Sunday 07 January 2007 15:11, Callum Lerwick wrote: > Something similarly irritating is that the arch isn't shown, which > causes me constant pain on x86_64. I finally managed to hack this > together with the help of some googling, put this in ~/.rpmmacros: > > %_query_all_fmt %{name}-%|epoch?{%{epoch}:}| > %{version}-%{release}.%{arch} > > Is there any reason this can't become default in our shiny new community > rpm fork? I'd like to see that, however that should cause a pretty big version bump. Changing the output like that is not to be taken lightly. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seg at haxxed.com Sun Jan 7 20:27:31 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 07 Jan 2007 14:27:31 -0600 Subject: install-info scriptlet failures In-Reply-To: <200701042149.42369.ville.skytta@iki.fi> References: <200701042149.42369.ville.skytta@iki.fi> Message-ID: <1168201651.6142.29.camel@max.booze> On Thu, 2007-01-04 at 21:49 +0200, Ville Skytt? wrote: > Having lately played around with (very) minimal installs, I was surprised to > find how many packages' scriptlets fail on "%_excludedocs 1" setups. I've > filed bugs against all Extras packages where I found the issue, as well as a > bunch of Core packages that had more problems than a simple non-failsafe > scriptlet (info files being erased on upgrades etc). Whoo, you got to it before I did. My mock setups all have "nodocs" set which is a good way to see the breakage upon install. I have one "nodocs" machine as well, which caused some pain when upgrading it from FC5 to FC6. A few packages had broken scripts which caused a "multiple package versions installed" situation. Though I don't think I had the presence of mind to note which ones. -------------- 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 a.badger at gmail.com Sun Jan 7 20:29:56 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 07 Jan 2007 12:29:56 -0800 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <200701071515.28502.jkeating@redhat.com> References: <20070105074343.GB22825@neu.nirvana> <459E5D9D.4060800@timj.co.uk> <1168200679.6142.20.camel@max.booze> <200701071515.28502.jkeating@redhat.com> Message-ID: <1168201796.14818.111.camel@localhost.localdomain> On Sun, 2007-01-07 at 15:15 -0500, Jesse Keating wrote: > On Sunday 07 January 2007 15:11, Callum Lerwick wrote: > > Something similarly irritating is that the arch isn't shown, which > > causes me constant pain on x86_64. I finally managed to hack this > > together with the help of some googling, put this in ~/.rpmmacros: > > > > %_query_all_fmt %{name}-%|epoch?{%{epoch}:}| > > %{version}-%{release}.%{arch} > > > > Is there any reason this can't become default in our shiny new community > > rpm fork? > > I'd like to see that, however that should cause a pretty big version bump. > Changing the output like that is not to be taken lightly. We could add this as a new commandline switch rather than replacing -q/-qa with it. Popt makes this kind of thing easy to implement. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sun Jan 7 20:36:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 7 Jan 2007 15:36:31 -0500 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168201796.14818.111.camel@localhost.localdomain> References: <20070105074343.GB22825@neu.nirvana> <200701071515.28502.jkeating@redhat.com> <1168201796.14818.111.camel@localhost.localdomain> Message-ID: <200701071536.31362.jkeating@redhat.com> On Sunday 07 January 2007 15:29, Toshio Kuratomi wrote: > We could add this as a new commandline switch rather than replacing > -q/-qa with it. > > Popt makes this kind of thing easy to implement. Well, I don't think that helps the issue as much. Those that don't know about the arch stuff are also not likely to know about a new command line switch to see the arch stuff. rpm -q(i) will continue to be used. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Sun Jan 7 21:32:30 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 7 Jan 2007 16:32:30 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-01-07 Message-ID: <20070107213230.3FBA715212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): dbus FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dovecot FC6-updates > FC7 (0:1.0-1.1.rc15.fc6 > 0:1.0-1.rc15.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) cgoorah AT yahoo.com.au: ngspice FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) devrim AT commandprompt.com: phpPgAdmin FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-5.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-6.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) rdieter AT math.unl.edu: maxima FE5 > FE6 (0:5.11.0-5.fc5 > 0:5.11.0-4.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) tcallawa AT redhat.com: ntfs-3g FE5 > FE7 (2:0-0.7.20070920.fc5 > 1:0-0.6.20070102.fc7) FE6 > FE7 (2:0-0.7.20070920.fc6 > 1:0-0.6.20070102.fc7) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dovecot: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0-1.1.rc15.fc6 > 0:1.0-1.rc15.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) maxima: rdieter AT math.unl.edu FE5 > FE6 (0:5.11.0-5.fc5 > 0:5.11.0-4.fc6) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) ngspice: cgoorah AT yahoo.com.au FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) ntfs-3g: tcallawa AT redhat.com FE5 > FE7 (2:0-0.7.20070920.fc5 > 1:0-0.6.20070102.fc7) FE6 > FE7 (2:0-0.7.20070920.fc6 > 1:0-0.6.20070102.fc7) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) phpPgAdmin: devrim AT commandprompt.com FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-5.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-6.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From bugs.michael at gmx.net Sun Jan 7 22:00:30 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 7 Jan 2007 23:00:30 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168200167.6142.13.camel@max.booze> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> <1168002886.3836.91.camel@zod.rchland.ibm.com> <459E883F.1020208@redhat.com> <1168018947.3836.132.camel@zod.rchland.ibm.com> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168200167.6142.13.camel@max.booze> Message-ID: <20070107230030.653fa1fd.bugs.michael@gmx.net> On Sun, 07 Jan 2007 14:02:46 -0600, Callum Lerwick wrote: > > It is not a bug. Semantically, a hardcoded dist tag can mean that the > > package has been developed (e.g. configured, patched, customised) and > > tested for the single specified distribution release and that nothing else > > is supported by the packager (not even if it works by coincidence). > > Rebuilding it without packaging changes and updating the dist tag > > automatically would be a bug. > > I dare say this is crackrock. The dist tag says what distribution the > package was built against. Not "intended to be built against". The tag (if it's not a macro) exists in the spec file, which is the source of a package for a specific target distribution. The spec file, the %changelog and the entire source rpm may contain stuff that is specific to that target distribution. Don't pretend that there's only one spec file for all distributions. > And > hardcoding it does not actually stop it from building on the "wrong > dist", does it? You've only created a confusing situation where you have > a distag of say "fc42" on a package even though it was built against > fc666. And? The binary packages are still marked as being for "fc42", which is wrong. In the repository this is indication that the package needs maintenance. The point is, it needs somebody to modify the src.rpm before the binary rpms would jump to "fc666". > If you're really that worried about a package only building on a certain > dist, put a (pseudocode) 'if (%{dist} != fc42 and %{dist} != "") then > exit 1' check in %prep or something. That will ACTUALLY kill the build > on the "wrong dist". > > IMHO, %{?dist} should be a MUST unless there's a damn good reason for > it, like the "giant huge mirror killing binary blob of game data" case. It is worth enough that %dist finds its way into the binary %changelog or doesn't. Either case is very bad IMO when %dist is used. Don't take away the packager's freedom with lousy policies. From bugs.michael at gmx.net Sun Jan 7 22:24:44 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 7 Jan 2007 23:24:44 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070107230030.653fa1fd.bugs.michael@gmx.net> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <459E3A3D.7020000@timj.co.uk> <1167997923.3159.41.camel@vader.jdub.homelinux.org> <1167998172.3963.2.camel@mccallum.corsepiu.local> <1168002886.3836.91.camel@zod.rchland.ibm.com> <459E883F.1020208@redhat.com> <1168018947.3836.132.camel@zod.rchland.ibm.com> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168200167.6142.13.camel@max.booze> <20070107230030.653fa1fd.bugs.michael@gmx.net> Message-ID: <20070107232444.36749acb.bugs.michael@gmx.net> On Sun, 7 Jan 2007 23:00:30 +0100, Michael Schwendt wrote: > > If you're really that worried about a package only building on a certain > > dist, put a (pseudocode) 'if (%{dist} != fc42 and %{dist} != "") then > > exit 1' check in %prep or something. That will ACTUALLY kill the build > > on the "wrong dist". > > > > IMHO, %{?dist} should be a MUST unless there's a damn good reason for > > it, like the "giant huge mirror killing binary blob of game data" case. > > It is worth enough that %dist finds its way into the binary %changelog or > doesn't. Either case is very bad IMO when %dist is used. s/worth/worse/ > Don't take away the packager's freedom with lousy policies. From jpo at di.uminho.pt Sun Jan 7 21:56:17 2007 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sun, 07 Jan 2007 21:56:17 +0000 Subject: FE-7 perl modules freshness (2007-01-07) Message-ID: <45A16C81.90104@di.uminho.pt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fe7_perl_modules_20070107.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From a.badger at gmail.com Sun Jan 7 22:28:35 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 07 Jan 2007 14:28:35 -0800 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070106124933.5e340e20.bugs.michael@gmx.net> References: <20070105074343.GB22825@neu.nirvana> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168025242.3836.158.camel@zod.rchland.ibm.com> <200701051437.50451.jkeating@redhat.com> <1168069304.14818.53.camel@localhost.localdomain> <20070106124933.5e340e20.bugs.michael@gmx.net> Message-ID: <1168208915.14818.143.camel@localhost.localdomain> On Sat, 2007-01-06 at 12:49 +0100, Michael Schwendt wrote: > On Fri, 05 Jan 2007 23:41:44 -0800, Toshio Kuratomi wrote: > > > Right. I think in this case the first thing I'd want to know is what > > does hardcoding a disttag buy you that not having a disttag at all does > > not? With that information, a more informed decision could be made. > > Hardcoding a dist tag explicitly flags the package as being made for that > dist by the packager. That is visible in the file name, too. > It's visible in the file name when something's wrong (ie: 1.fc4 in the devel tree). It blends in when everything's right. (As it should.) > A simple mass-rebuild would not pretend that the package has been updated > (read: prepared for the new dist). It would need a package maintainer to > update customisation and integration patches first before changing the > dist tag would make sense. When would this be appropriate to use? In non-devel branches it could mark where the packager made the conscious decision to create a separate spec file for the older release. In this case, it is really just a comment for other packagers to pick up as we don't rebranch a package after the first import. In the devel branch, it would mark the package as needing to be updated manually for every release and could prevent mass rebuilds from operating on it (or flag the package as needing more work if it were mass rebuilt). However, how does the packager know that this is the case before the new release is even created? Is there an example package which illustrates this? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From berrange at redhat.com Sun Jan 7 22:49:25 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 7 Jan 2007 22:49:25 +0000 Subject: FE-7 perl modules freshness (2007-01-07) In-Reply-To: <45A16C81.90104@di.uminho.pt> References: <45A16C81.90104@di.uminho.pt> Message-ID: <20070107224925.GA26880@redhat.com> On Sun, Jan 07, 2007 at 09:56:17PM +0000, Jose Pedro Oliveira wrote: > Perl distros that aren't CPAN based or CPAN Perl distros > that don't have 'http://search.cpan.org/dist/...' URLs > > perl-Test-AutoBuild http://autobuild.org/ The site http://autobuild.org/ is the main project website, but there is a CPAN download URL at http://search.cpan.org/dist/Test-AutoBuild/. I had used the former in the RPM spec because its got more useful content for users on it. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From bugs.michael at gmx.net Sun Jan 7 23:47:38 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 8 Jan 2007 00:47:38 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168208915.14818.143.camel@localhost.localdomain> References: <20070105074343.GB22825@neu.nirvana> <20070105201312.c36b697f.bugs.michael@gmx.net> <1168025242.3836.158.camel@zod.rchland.ibm.com> <200701051437.50451.jkeating@redhat.com> <1168069304.14818.53.camel@localhost.localdomain> <20070106124933.5e340e20.bugs.michael@gmx.net> <1168208915.14818.143.camel@localhost.localdomain> Message-ID: <20070108004738.ce78d5f7.bugs.michael@gmx.net> On Sun, 07 Jan 2007 14:28:35 -0800, Toshio Kuratomi wrote: > > A simple mass-rebuild would not pretend that the package has been updated > > (read: prepared for the new dist). It would need a package maintainer to > > update customisation and integration patches first before changing the > > dist tag would make sense. > > When would this be appropriate to use? > > In non-devel branches it could mark where the packager made the > conscious decision to create a separate spec file for the older release. > In this case, it is really just a comment for other packagers to pick up > as we don't rebranch a package after the first import. > > In the devel branch, it would mark the package as needing to be updated > manually for every release and could prevent mass rebuilds from > operating on it (or flag the package as needing more work if it were > mass rebuilt). However, how does the packager know that this is the > case before the new release is even created? Is there an example > package which illustrates this? We've had it before with custom patches (e.g. configuring an application with different helper program paths for different distribution targets, versioned requirements, dist-dependent build sections). We've had it before that a previously orphaned package was picked up, extended with %{?dist} and mass-built for multiple dists down to the oldest dists only to find it breaks at run-time because the spec was less "portable" than expected. I don't keep a book where I write down such issues. All that matters is that bad experience with %{?dist} piles up. Among the worst things is that you cannot use the dist tag in the %changelog. You cannot keep %release and %changelog in sync, particularly not when a minor release is added right of %{?dist} as some packagers do it to work around cvs tagging mess. I see the benefit of being permitted to hardcode a dist tag. From nicolas.mailhot at laposte.net Sun Jan 7 23:47:29 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 08 Jan 2007 00:47:29 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168200679.6142.20.camel@max.booze> References: <20070105074343.GB22825@neu.nirvana> <20070105095550.117550ed.bugs.michael@gmx.net> <20070105092503.GA4860@neu.nirvana> <1167997467.3159.34.camel@vader.jdub.homelinux.org> <459E5D9D.4060800@timj.co.uk> <1168200679.6142.20.camel@max.booze> Message-ID: <1168213650.4914.3.camel@rousalka.dyndns.org> Le dimanche 07 janvier 2007 ? 14:11 -0600, Callum Lerwick a ?crit : > Something similarly irritating is that the arch isn't shown, which > causes me constant pain on x86_64. I finally managed to hack this > together with the help of some googling, put this in ~/.rpmmacros: > > %_query_all_fmt %{name}-%|epoch?{%{epoch}:}| > %{version}-%{release}.%{arch} > > Is there any reason this can't become default in our shiny new community > rpm fork? +1, just point us to the RFE bug and you'll get a lot of support -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Mon Jan 8 00:06:10 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 08 Jan 2007 01:06:10 +0100 Subject: FE-7 perl modules freshness (2007-01-07) In-Reply-To: <45A16C81.90104@di.uminho.pt> References: <45A16C81.90104@di.uminho.pt> Message-ID: <1168214770.4914.8.camel@rousalka.dyndns.org> Hi, Since we're talking about Fedora cpan perl packages, it would be awesome is the buildsys relayed Fedora build results/logs to cpantesters automatically. I'm too cheap to relay all the build warnings upstream systematically:( Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From giallu at gmail.com Mon Jan 8 08:30:08 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 8 Jan 2007 09:30:08 +0100 Subject: Bugzilla tickets for old Fedora releases In-Reply-To: <20070104210147.6527699c@ludwig-alpha.unil.ch> References: <20070104210147.6527699c@ludwig-alpha.unil.ch> Message-ID: On 1/4/07, Christian Iseli wrote: > Dear all, > > Now that Fedora legacy has dropped 3 and 4, it seems time to close the > old bug reports regarding FC 3 and FC 4. > > We invite all maintainers to have a look at open tickets for those old > releases and take appropriate actions as they see fit: move to newer > releases or close down. I'd like to close a couple of mine. Given they are not applicable to FC5 and newer, would you suggest me to I close them as WONTFIX or NEXTRELEASE ? From Christian.Iseli at licr.org Mon Jan 8 15:08:43 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 8 Jan 2007 16:08:43 +0100 Subject: Bugzilla tickets for old Fedora releases In-Reply-To: References: <20070104210147.6527699c@ludwig-alpha.unil.ch> Message-ID: <20070108160843.56495c60@ludwig-alpha.unil.ch> On Mon, 8 Jan 2007 09:30:08 +0100, Gianluca Sforna wrote: > I'd like to close a couple of mine. Given they are not applicable to > FC5 and newer, would you suggest me to I close them as WONTFIX or > NEXTRELEASE ? Given you will not make a new release in FC3/4, I'd go with WONTFIX... C From mattdm at mattdm.org Mon Jan 8 15:24:38 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 8 Jan 2007 10:24:38 -0500 Subject: Bugzilla tickets for old Fedora releases In-Reply-To: References: <20070104210147.6527699c@ludwig-alpha.unil.ch> Message-ID: <20070108152438.GA2836@jadzia.bu.edu> On Mon, Jan 08, 2007 at 09:30:08AM +0100, Gianluca Sforna wrote: > >We invite all maintainers to have a look at open tickets for those old > >releases and take appropriate actions as they see fit: move to newer > >releases or close down. > I'd like to close a couple of mine. Given they are not applicable to > FC5 and newer, would you suggest me to I close them as WONTFIX or > NEXTRELEASE ? I'd say: the former if it's not applicable because it's functionality that has been dropped or replaced with something else. The latter if FC5 or newer has a version or patch that actually fixes the issue. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jan 8 15:55:48 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 8 Jan 2007 16:55:48 +0100 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070105102310.3bb8241c@ludwig-alpha.unil.ch> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> Message-ID: <20070108165548.018c63ae@python3.es.egwn.lan> Christian Iseli wrote : > On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: > > Me currently votes for fp for "Fedora Packages" (and matches Fedora > > Project at the same time, too), because that's what it is afaics. > > How about we just stay with fc7, and think of it as > Fedora, collection 7 ? Strange. No one seems to have suggested "fe7" in this thread. Not as in "Fedora Extras" anymore, but as in "FEdora". And "e > c" so it works. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.18-1.2835.fc6 Load : 0.29 2.06 2.58 From giallu at gmail.com Mon Jan 8 16:01:00 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 8 Jan 2007 17:01:00 +0100 Subject: Bugzilla tickets for old Fedora releases In-Reply-To: <20070108152438.GA2836@jadzia.bu.edu> References: <20070104210147.6527699c@ludwig-alpha.unil.ch> <20070108152438.GA2836@jadzia.bu.edu> Message-ID: On 1/8/07, Matthew Miller wrote: > On Mon, Jan 08, 2007 at 09:30:08AM +0100, Gianluca Sforna wrote: > > >We invite all maintainers to have a look at open tickets for those old > > >releases and take appropriate actions as they see fit: move to newer > > >releases or close down. > > I'd like to close a couple of mine. Given they are not applicable to > > FC5 and newer, would you suggest me to I close them as WONTFIX or > > NEXTRELEASE ? > > I'd say: the former if it's not applicable because it's functionality that > has been dropped or replaced with something else. The latter if FC5 or newer > has a version or patch that actually fixes the issue. > The latter seems to be my case. So I have 2 different opinions... From Christian.Iseli at licr.org Mon Jan 8 17:46:42 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 8 Jan 2007 18:46:42 +0100 Subject: Bugzilla tickets for old Fedora releases In-Reply-To: References: <20070104210147.6527699c@ludwig-alpha.unil.ch> <20070108152438.GA2836@jadzia.bu.edu> Message-ID: <20070108184642.0119c665@ludwig-alpha.unil.ch> On Mon, 8 Jan 2007 17:01:00 +0100, Gianluca Sforna wrote: > The latter seems to be my case. So I have 2 different opinions... Ah well :-) I always took NEXTRELEASE to mean "fixed in the next rpm release within the same product", but I suppose it can also mean "fixed in the next rpm release *or* within the next product release"... So just go ahead with NEXTRELEASE... Cheers, C From chris.stone at gmail.com Mon Jan 8 17:40:14 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 8 Jan 2007 09:40:14 -0800 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <20070108165548.018c63ae@python3.es.egwn.lan> References: <20070105074343.GB22825@neu.nirvana> <459E0560.5080902@leemhuis.info> <20070105102310.3bb8241c@ludwig-alpha.unil.ch> <20070108165548.018c63ae@python3.es.egwn.lan> Message-ID: On 1/8/07, Matthias Saou wrote: > Christian Iseli wrote : > > > On Fri, 05 Jan 2007 08:59:28 +0100, Thorsten Leemhuis wrote: > > > Me currently votes for fp for "Fedora Packages" (and matches Fedora > > > Project at the same time, too), because that's what it is afaics. > > > > How about we just stay with fc7, and think of it as > > Fedora, collection 7 ? > > Strange. No one seems to have suggested "fe7" in this thread. Not as in > "Fedora Extras" anymore, but as in "FEdora". And "e > c" so it works. I was going to suggest "fedora7" as a new dist tag, but then someone came up with the suggestion of just sticking with "fc7" and calling it Fedora Community. From Axel.Thimm at ATrpms.net Mon Jan 8 18:10:16 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 8 Jan 2007 19:10:16 +0100 Subject: Bugzilla tickets for old Fedora releases In-Reply-To: References: <20070104210147.6527699c@ludwig-alpha.unil.ch> <20070108152438.GA2836@jadzia.bu.edu> Message-ID: <20070108181016.GH18545@neu.nirvana> On Mon, Jan 08, 2007 at 05:01:00PM +0100, Gianluca Sforna wrote: > On 1/8/07, Matthew Miller wrote: > >On Mon, Jan 08, 2007 at 09:30:08AM +0100, Gianluca Sforna wrote: > >> >We invite all maintainers to have a look at open tickets for those old > >> >releases and take appropriate actions as they see fit: move to newer > >> >releases or close down. > >> I'd like to close a couple of mine. Given they are not applicable to > >> FC5 and newer, would you suggest me to I close them as WONTFIX or > >> NEXTRELEASE ? > > > >I'd say: the former if it's not applicable because it's functionality that > >has been dropped or replaced with something else. The latter if FC5 or > >newer > >has a version or patch that actually fixes the issue. > > > > The latter seems to be my case. So I have 2 different opinions... Just take a step back an ask yourself "has the issue been dropped or has it been fixed one way or another"? WONTFIX means you stay on your problem even after an upgrade, NEXTRELEASE means the problem goes away by upgrading. Note: upgrading, not fresh-installs. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jan 8 18:41:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 13:41:20 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day Message-ID: <200701081341.20700.jkeating@redhat.com> This will come up fast. For this test release I'm planning: A Fedora Desktop Spin (with LiveCD) A Fedora Server Spin Each of these spins can include packages that are either in Core or Extras, given that we'll be merging later. The Core set can be frozen easily, can we make the same happen for Extras? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Mon Jan 8 18:55:18 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 8 Jan 2007 12:55:18 -0600 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081341.20700.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> Message-ID: <200701081255.19182.dennis@ausil.us> On Monday 08 January 2007 12:41, Jesse Keating wrote: > This will come up fast. For this test release I'm planning: > > A Fedora Desktop Spin (with LiveCD) > A Fedora Server Spin > > Each of these spins can include packages that are either in Core or Extras, > given that we'll be merging later. > > The Core set can be frozen easily, can we make the same happen for Extras? Right now probably not easily -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From rdieter at math.unl.edu Mon Jan 8 18:55:52 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 08 Jan 2007 12:55:52 -0600 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081341.20700.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> Message-ID: <45A293B8.2070700@math.unl.edu> Jesse Keating wrote: > This will come up fast. For this test release I'm planning: > > A Fedora Desktop Spin (with LiveCD) > A Fedora Server Spin > > Each of these spins can include packages that are either in Core or Extras, > given that we'll be merging later. > > The Core set can be frozen easily, can we make the same happen for Extras? Sure, we can try. Can you define exactly what you mean by frozen? (or simply immutable/unchanging until unfrozen?) -- Rex From notting at redhat.com Mon Jan 8 18:56:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 8 Jan 2007 13:56:06 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081341.20700.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> Message-ID: <20070108185606.GC20857@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > This will come up fast. For this test release I'm planning: > > A Fedora Desktop Spin (with LiveCD) > A Fedora Server Spin Brave - you really want to try and hit these goals for Test 1? I think we probably need to decide on a FTP structure first, and get development working in that context. Bill From jkeating at redhat.com Mon Jan 8 18:59:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 13:59:53 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108185606.GC20857@nostromo.devel.redhat.com> References: <200701081341.20700.jkeating@redhat.com> <20070108185606.GC20857@nostromo.devel.redhat.com> Message-ID: <200701081359.53801.jkeating@redhat.com> On Monday 08 January 2007 13:56, Bill Nottingham wrote: > Brave - you really want to try and hit these goals for Test 1? For this cut, I'm thinking package manifest only, since that's cheap and easy to fiddle with. I'm doing some composes today to see where things are (and hitting many many bugs preventing me from doing an install *sigh*) > I think we probably need to decide on a FTP structure first, and > get development working in that context. Yes, this needs to happen too, but I think it could happen in parallel. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Mon Jan 8 21:26:59 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 08 Jan 2007 15:26:59 -0600 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081341.20700.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> Message-ID: <1168291619.3159.68.camel@vader.jdub.homelinux.org> On Mon, 2007-01-08 at 13:41 -0500, Jesse Keating wrote: > This will come up fast. For this test release I'm planning: > > A Fedora Desktop Spin (with LiveCD) > A Fedora Server Spin > > Each of these spins can include packages that are either in Core or Extras, > given that we'll be merging later. > > The Core set can be frozen easily, can we make the same happen for Extras? Ok, realistically here's what would need to happen to freeze Extras (not necessarily in this order) 1) Lock down the FE-devel repository This can be done by either selectively pushing things, or by completely turning off build access through plague. Essentially, "freeze" would mean no new packages and no version upgrades of current packages. 2) Open a freeze-update blocker bug in bugzilla This would track requests to allow fixes to be pushed to the frozen repository after being reviewed by a "Freeze Review Team" 3) Create the Freeze Review Team This is a group of individuals that would monitor the tracking bug and ACK or NACK the requests. If ACKed, a package would be built and pushed into the repo at that point. 4) Email -extras, -devel, and -maintainers with the above information as soon as we can to get the word out. I'm sure I'm missing something, but that's a 10,000 meter view of what's going to be needed. We'll need help from the Infrastructure Team, and we'll need to get the review team in place rather quickly. This should be added to the FESCo agenda for this week. Thoughts? josh From dennis at ausil.us Mon Jan 8 21:37:06 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 8 Jan 2007 15:37:06 -0600 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <1168291619.3159.68.camel@vader.jdub.homelinux.org> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> Message-ID: <200701081537.06636.dennis@ausil.us> On Monday 08 January 2007 15:26, Josh Boyer wrote: > Ok, realistically here's what would need to happen to freeze Extras (not > necessarily in this order) > > 1) Lock down the FE-devel repository not necessary. we just don't push for the freeze window. > 2) Open a freeze-update blocker bug in bugzilla :) we need that > 3) Create the Freeze Review Team We would need to create a special build target so that we don't pull in other packages built in the mean time. when a package is acked it gets built for both the unpublished devel tree and the published one. packages in the unpublished tree get a .1 at the end of its release. > 4) Email -extras, -devel, and -maintainers with the above information as > soon as we can to get the word out. > Thoughts? we need this done ASAP -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From notting at redhat.com Mon Jan 8 21:46:04 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 8 Jan 2007 16:46:04 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081537.06636.dennis@ausil.us> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> <200701081537.06636.dennis@ausil.us> Message-ID: <20070108214604.GA23597@nostromo.devel.redhat.com> Dennis Gilmore (dennis at ausil.us) said: > We would need to create a special build target so that we don't pull in other > packages built in the mean time. when a package is acked it gets built for > both the unpublished devel tree and the published one. packages in the > unpublished tree get a .1 at the end of its release. Why not just build for the unpublished tree, and selectively pull those into published tree when ready? Bill From pertusus at free.fr Mon Jan 8 21:50:01 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 8 Jan 2007 22:50:01 +0100 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <1168291619.3159.68.camel@vader.jdub.homelinux.org> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> Message-ID: <20070108215001.GC3109@free.fr> On Mon, Jan 08, 2007 at 03:26:59PM -0600, Josh Boyer wrote: > > 2) Open a freeze-update blocker bug in bugzilla > > This would track requests to allow fixes to be pushed to the frozen > repository after being reviewed by a "Freeze Review Team" > > 3) Create the Freeze Review Team > > This is a group of individuals that would monitor the tracking bug and > ACK or NACK the requests. If ACKed, a package would be built and pushed > into the repo at that point. I don't think a Freeze Review Team is needed. I think the contributors should use their best judgement on whether they build for the frozen target or the rolling one, the default being the rolling one, of course. Using a blocker bug to document why there was a version/package released for the frozen target and leave a possibility to other contributors to yell would be the recommended way, however. People interested in releases could then be in CC of that blocker. -- Pat From dennis at ausil.us Mon Jan 8 21:56:07 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 8 Jan 2007 15:56:07 -0600 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108214604.GA23597@nostromo.devel.redhat.com> References: <200701081341.20700.jkeating@redhat.com> <200701081537.06636.dennis@ausil.us> <20070108214604.GA23597@nostromo.devel.redhat.com> Message-ID: <200701081556.07405.dennis@ausil.us> On Monday 08 January 2007 15:46, Bill Nottingham wrote: > Dennis Gilmore (dennis at ausil.us) said: > > We would need to create a special build target so that we don't pull in > > other packages built in the mean time. when a package is acked it gets > > built for both the unpublished devel tree and the published one. > > packages in the unpublished tree get a .1 at the end of its release. > > Why not just build for the unpublished tree, and selectively pull > those into published tree when ready? you could but you will possibly need to pull other packages in than the ones fixing the problems. I was just thinking to minimise problems. But you also would end up replacing all of them once the freeze is done. I guess pick the lesser of two evils. -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From jwboyer at jdub.homelinux.org Mon Jan 8 21:58:20 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 08 Jan 2007 15:58:20 -0600 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108215001.GC3109@free.fr> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> <20070108215001.GC3109@free.fr> Message-ID: <1168293501.3159.71.camel@vader.jdub.homelinux.org> On Mon, 2007-01-08 at 22:50 +0100, Patrice Dumas wrote: > On Mon, Jan 08, 2007 at 03:26:59PM -0600, Josh Boyer wrote: > > > > 2) Open a freeze-update blocker bug in bugzilla > > > > This would track requests to allow fixes to be pushed to the frozen > > repository after being reviewed by a "Freeze Review Team" > > > > 3) Create the Freeze Review Team > > > > This is a group of individuals that would monitor the tracking bug and > > ACK or NACK the requests. If ACKed, a package would be built and pushed > > into the repo at that point. > > I don't think a Freeze Review Team is needed. I think the contributors > should use their best judgement on whether they build for the frozen > target or the rolling one, the default being the rolling one, of course. > Using a blocker bug to document why there was a version/package released > for the frozen target and leave a possibility to other contributors to > yell would be the recommended way, however. People interested in releases > could then be in CC of that blocker. I'd rather do it the other way. There is going to be QA on-going of the test releases and I want the test team (speak up Will) to _know_ what's being pushed in. josh From notting at redhat.com Mon Jan 8 21:58:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 8 Jan 2007 16:58:16 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081556.07405.dennis@ausil.us> References: <200701081341.20700.jkeating@redhat.com> <200701081537.06636.dennis@ausil.us> <20070108214604.GA23597@nostromo.devel.redhat.com> <200701081556.07405.dennis@ausil.us> Message-ID: <20070108215816.GB23597@nostromo.devel.redhat.com> Dennis Gilmore (dennis at ausil.us) said: > On Monday 08 January 2007 15:46, Bill Nottingham wrote: > > Dennis Gilmore (dennis at ausil.us) said: > > > We would need to create a special build target so that we don't pull in > > > other packages built in the mean time. when a package is acked it gets > > > built for both the unpublished devel tree and the published one. > > > packages in the unpublished tree get a .1 at the end of its release. > > > > Why not just build for the unpublished tree, and selectively pull > > those into published tree when ready? > you could but you will possibly need to pull other packages in than the ones > fixing the problems. I was just thinking to minimise problems. But you also > would end up replacing all of them once the freeze is done. I guess pick the > lesser of two evils. Not sure why you'd need to pull in others, unless you let the buildroots pull from unpublished (which I don't think you want.) Bill From jkeating at redhat.com Mon Jan 8 21:58:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 16:58:56 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108215001.GC3109@free.fr> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> <20070108215001.GC3109@free.fr> Message-ID: <200701081658.56921.jkeating@redhat.com> On Monday 08 January 2007 16:50, Patrice Dumas wrote: > I don't think a Freeze Review Team is needed. I think the contributors > should use their best judgement on whether they build for the frozen > target or the rolling one, the default being the rolling one, of course. > Using a blocker bug to document why there was a version/package released > for the frozen target and leave a possibility to other contributors to > yell would be the recommended way, however. People interested in releases > could then be in CC of that blocker. Getting the mass community of packagers to notice we're in a freeze will be impossible. Things will get in that will cause problems. This happens even within Red Hat just on the Core set. I'd rather not fight it with 2x the packages. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Jan 8 22:03:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 8 Jan 2007 23:03:40 +0100 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081341.20700.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> Message-ID: <20070108220340.GI18545@neu.nirvana> On Mon, Jan 08, 2007 at 01:41:20PM -0500, Jesse Keating wrote: > This will come up fast. For this test release I'm planning: > > A Fedora Desktop Spin (with LiveCD) > A Fedora Server Spin > > Each of these spins can include packages that are either in Core or Extras, > given that we'll be merging later. > > The Core set can be frozen easily, can we make the same happen for Extras? Would it make sense to only freeze the packages that are being used for the spins? That way people would be able to continue on other packages, but still contribute to testing the spins since they continue building on them and also need to use the frozen spin packages to run theirs. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Mon Jan 8 22:02:59 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 8 Jan 2007 23:02:59 +0100 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081658.56921.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> <20070108215001.GC3109@free.fr> <200701081658.56921.jkeating@redhat.com> Message-ID: <20070108220259.GD3109@free.fr> On Mon, Jan 08, 2007 at 04:58:56PM -0500, Jesse Keating wrote: > > Getting the mass community of packagers to notice we're in a freeze will be > impossible. Things will get in that will cause problems. This happens even > within Red Hat just on the Core set. I'd rather not fight it with 2x the > packages. The jobs submitted regularly won't be pushed to the frozen package set, so the packagers ignoring the issue won't put anything in the frozen packages set. -- Pat From jkeating at redhat.com Mon Jan 8 22:03:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 17:03:27 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081537.06636.dennis@ausil.us> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> <200701081537.06636.dennis@ausil.us> Message-ID: <200701081703.27896.jkeating@redhat.com> On Monday 08 January 2007 16:37, Dennis Gilmore wrote: > not necessary. ?we just don't push for the freeze window. > > > 2) Open a freeze-update blocker bug in bugzilla > > > :) we need that > : > > 3) Create the Freeze Review Team > > We would need to create a special build target so that we don't pull in > other packages built in the mean time. ?when a package is acked ?it gets > built for both the unpublished devel tree and the ?published one. ?packages > in the unpublished tree get a .1 at the end of its release. Why build twice? What we do internally is setup a second build target, that for the duration of the freeze does not self-update (builds are not available for later builds). Builds continue, and when we need some specific fix, we copy/tag it from the second build target to the frozen target. Once the freeze is over, the packages remaining in the second target are just sourced into the maintarget and life goes on. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Mon Jan 8 22:05:10 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 8 Jan 2007 23:05:10 +0100 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <1168293501.3159.71.camel@vader.jdub.homelinux.org> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> <20070108215001.GC3109@free.fr> <1168293501.3159.71.camel@vader.jdub.homelinux.org> Message-ID: <20070108220510.GE3109@free.fr> On Mon, Jan 08, 2007 at 03:58:20PM -0600, Josh Boyer wrote: > On Mon, 2007-01-08 at 22:50 +0100, Patrice Dumas wrote: > > I'd rather do it the other way. There is going to be QA on-going of the > test releases and I want the test team (speak up Will) to _know_ what's > being pushed in. For that there could be something along the mail we all get when things are pushed to extras or core, no need of something different here. -- Pat From jwboyer at jdub.homelinux.org Mon Jan 8 22:07:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 08 Jan 2007 16:07:58 -0600 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108220340.GI18545@neu.nirvana> References: <200701081341.20700.jkeating@redhat.com> <20070108220340.GI18545@neu.nirvana> Message-ID: <1168294078.3159.73.camel@vader.jdub.homelinux.org> On Mon, 2007-01-08 at 23:03 +0100, Axel Thimm wrote: > On Mon, Jan 08, 2007 at 01:41:20PM -0500, Jesse Keating wrote: > > This will come up fast. For this test release I'm planning: > > > > A Fedora Desktop Spin (with LiveCD) > > A Fedora Server Spin > > > > Each of these spins can include packages that are either in Core or Extras, > > given that we'll be merging later. > > > > The Core set can be frozen easily, can we make the same happen for Extras? > > Would it make sense to only freeze the packages that are being used > for the spins? We don't know what those would be. And you can have multiple spins now, remember? Think Fedora KDE, Fedora XFCE, Fedora "Bob's release"... josh From sundaram at fedoraproject.org Mon Jan 8 22:05:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 09 Jan 2007 03:35:39 +0530 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108220340.GI18545@neu.nirvana> References: <200701081341.20700.jkeating@redhat.com> <20070108220340.GI18545@neu.nirvana> Message-ID: <45A2C033.7090106@fedoraproject.org> Axel Thimm wrote: > On Mon, Jan 08, 2007 at 01:41:20PM -0500, Jesse Keating wrote: >> This will come up fast. For this test release I'm planning: >> >> A Fedora Desktop Spin (with LiveCD) >> A Fedora Server Spin >> >> Each of these spins can include packages that are either in Core or Extras, >> given that we'll be merging later. >> >> The Core set can be frozen easily, can we make the same happen for Extras? > > Would it make sense to only freeze the packages that are being used > for the spins? I would prefer a complete freeze as I have been requesting that we have a DVD set with all the packages in it. Rahul From jkeating at redhat.com Mon Jan 8 22:16:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 17:16:57 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108220259.GD3109@free.fr> References: <200701081341.20700.jkeating@redhat.com> <200701081658.56921.jkeating@redhat.com> <20070108220259.GD3109@free.fr> Message-ID: <200701081716.57405.jkeating@redhat.com> On Monday 08 January 2007 17:02, Patrice Dumas wrote: > The jobs submitted regularly won't be pushed to the frozen package set, > so the packagers ignoring the issue won't put anything in the frozen > packages set. Which means we still need a team of folks to decide what needs to get pulled INTO the frozen package set. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jan 8 22:19:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 17:19:12 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108220340.GI18545@neu.nirvana> References: <200701081341.20700.jkeating@redhat.com> <20070108220340.GI18545@neu.nirvana> Message-ID: <200701081719.12780.jkeating@redhat.com> On Monday 08 January 2007 17:03, Axel Thimm wrote: > Would it make sense to only freeze the packages that are being used > for the spins? > > That way people would be able to continue on other packages, but still > contribute to testing the spins since they continue building on them > and also need to use the frozen spin packages to run theirs. Given that we can enable the massive repo at install time, the entire repo should be frozen (and consistant with regard to deps/conflicts). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Mon Jan 8 22:22:17 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 08 Jan 2007 16:22:17 -0600 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081716.57405.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> <200701081658.56921.jkeating@redhat.com> <20070108220259.GD3109@free.fr> <200701081716.57405.jkeating@redhat.com> Message-ID: <1168294937.3159.75.camel@vader.jdub.homelinux.org> On Mon, 2007-01-08 at 17:16 -0500, Jesse Keating wrote: > On Monday 08 January 2007 17:02, Patrice Dumas wrote: > > The jobs submitted regularly won't be pushed to the frozen package set, > > so the packagers ignoring the issue won't put anything in the frozen > > packages set. > > Which means we still need a team of folks to decide what needs to get pulled > INTO the frozen package set. Right. That is what I'm most concerned about. The technical implementation is a detail that will work itself out. josh From dennis at ausil.us Mon Jan 8 22:27:00 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 8 Jan 2007 16:27:00 -0600 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108215816.GB23597@nostromo.devel.redhat.com> References: <200701081341.20700.jkeating@redhat.com> <200701081556.07405.dennis@ausil.us> <20070108215816.GB23597@nostromo.devel.redhat.com> Message-ID: <200701081627.01752.dennis@ausil.us> On Monday 08 January 2007 15:58, Bill Nottingham wrote: > Dennis Gilmore (dennis at ausil.us) said: > > On Monday 08 January 2007 15:46, Bill Nottingham wrote: > > > Dennis Gilmore (dennis at ausil.us) said: > > > > We would need to create a special build target so that we don't pull > > > > in other packages built in the mean time. when a package is acked > > > > it gets built for both the unpublished devel tree and the published > > > > one. packages in the unpublished tree get a .1 at the end of its > > > > release. > > > > > > Why not just build for the unpublished tree, and selectively pull > > > those into published tree when ready? > > > > you could but you will possibly need to pull other packages in than the > > ones fixing the problems. I was just thinking to minimise problems. But > > you also would end up replacing all of them once the freeze is done. I > > guess pick the lesser of two evils. > > Not sure why you'd need to pull in others, unless you let the buildroots > pull from unpublished (which I don't think you want.) > > Bill Plague pulls in from unpublished in the build roots. Which is why i said what i initially said. -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From pertusus at free.fr Mon Jan 8 22:26:14 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 8 Jan 2007 23:26:14 +0100 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081716.57405.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> <200701081658.56921.jkeating@redhat.com> <20070108220259.GD3109@free.fr> <200701081716.57405.jkeating@redhat.com> Message-ID: <20070108222614.GF3109@free.fr> On Mon, Jan 08, 2007 at 05:16:57PM -0500, Jesse Keating wrote: > On Monday 08 January 2007 17:02, Patrice Dumas wrote: > > The jobs submitted regularly won't be pushed to the frozen package set, > > so the packagers ignoring the issue won't put anything in the frozen > > packages set. > > Which means we still need a team of folks to decide what needs to get pulled > INTO the frozen package set. Why not everything? All the packages in the repo are at their frozen version, and after that, to submit a build to the frozen package set it is another comand than the usual build. -- Pat From jkeating at redhat.com Mon Jan 8 22:30:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 17:30:24 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108222614.GF3109@free.fr> References: <200701081341.20700.jkeating@redhat.com> <200701081716.57405.jkeating@redhat.com> <20070108222614.GF3109@free.fr> Message-ID: <200701081730.24928.jkeating@redhat.com> On Monday 08 January 2007 17:26, Patrice Dumas wrote: > Why not everything? All the packages in the repo are at their frozen > version, and after that, to submit a build to the frozen package set > it is another comand than the usual build. Because more often than not "My build is really important for the freeze" when really it isn't. Every maintainer's package is the most important package (to them). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Jan 8 22:31:19 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 8 Jan 2007 17:31:19 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081627.01752.dennis@ausil.us> References: <200701081341.20700.jkeating@redhat.com> <200701081556.07405.dennis@ausil.us> <20070108215816.GB23597@nostromo.devel.redhat.com> <200701081627.01752.dennis@ausil.us> Message-ID: <20070108223119.GA24335@nostromo.devel.redhat.com> Dennis Gilmore (dennis at ausil.us) said: > Plague pulls in from unpublished in the build roots. Which is why i said what > i initially said. Hrm. Is that possible to change without massively breaking things? Bill From dennis at ausil.us Mon Jan 8 22:44:43 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 8 Jan 2007 16:44:43 -0600 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108223119.GA24335@nostromo.devel.redhat.com> References: <200701081341.20700.jkeating@redhat.com> <200701081627.01752.dennis@ausil.us> <20070108223119.GA24335@nostromo.devel.redhat.com> Message-ID: <200701081644.44879.dennis@ausil.us> On Monday 08 January 2007 16:31, Bill Nottingham wrote: > Dennis Gilmore (dennis at ausil.us) said: > > Plague pulls in from unpublished in the build roots. Which is why i said > > what i initially said. > > Hrm. Is that possible to change without massively breaking things? Not really. it would require knowing about collections and different tags. which is something we will get once Brew is set free. so hopefully by the time we get to test2 or test3 we will have it. Jesse, how far away are we from having code? will it be available for FUDCon? -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From jkeating at redhat.com Mon Jan 8 22:48:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 17:48:53 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081644.44879.dennis@ausil.us> References: <200701081341.20700.jkeating@redhat.com> <20070108223119.GA24335@nostromo.devel.redhat.com> <200701081644.44879.dennis@ausil.us> Message-ID: <200701081748.53559.jkeating@redhat.com> On Monday 08 January 2007 17:44, Dennis Gilmore wrote: > so hopefully by the time we get to test2 or test3 we will have it. ?Jesse, > ? how far away are we from having code? ?will it be available for FUDCon? I would hope Br^Wwort would be available for hacking by then, but I can't really tell. I'll keep poking / prodding. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Mon Jan 8 22:51:09 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 8 Jan 2007 23:51:09 +0100 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081730.24928.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> <200701081716.57405.jkeating@redhat.com> <20070108222614.GF3109@free.fr> <200701081730.24928.jkeating@redhat.com> Message-ID: <20070108225109.GH3109@free.fr> On Mon, Jan 08, 2007 at 05:30:24PM -0500, Jesse Keating wrote: > On Monday 08 January 2007 17:26, Patrice Dumas wrote: > > Why not everything? All the packages in the repo are at their frozen > > version, and after that, to submit a build to the frozen package set > > it is another comand than the usual build. > > Because more often than not "My build is really important for the freeze" when > really it isn't. Every maintainer's package is the most important package > (to them). But everything will be frozen, so there cannot be more important package as you say. Or am I missing something? Maybe you are talking about update of packages. I hope, for that, that packagers are responsible enough not to need to be controlled by a release team. If some packagers submit unneeded builds that update the frozen packages, people can complain privately or on the list, or escalate the issue. But I can't see why maintainers wouldn't be responsible. -- Pat From jkeating at redhat.com Mon Jan 8 22:57:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 17:57:21 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108225109.GH3109@free.fr> References: <200701081341.20700.jkeating@redhat.com> <200701081730.24928.jkeating@redhat.com> <20070108225109.GH3109@free.fr> Message-ID: <200701081757.21421.jkeating@redhat.com> On Monday 08 January 2007 17:51, Patrice Dumas wrote: > But I can't see why maintainers > wouldn't be responsible. Oh what a wonderful world that would be. But the reality of it is, we need to be very sure what we're pulling into the compose. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wwoods at redhat.com Mon Jan 8 23:11:49 2007 From: wwoods at redhat.com (Will Woods) Date: Mon, 8 Jan 2007 18:11:49 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <1168293501.3159.71.camel@vader.jdub.homelinux.org> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> <20070108215001.GC3109@free.fr> <1168293501.3159.71.camel@vader.jdub.homelinux.org> Message-ID: <3C9578C5-C8D2-4FC2-BDB5-009382488754@redhat.com> On Jan 8, 2007, at 4:58 PM, Josh Boyer wrote: > On Mon, 2007-01-08 at 22:50 +0100, Patrice Dumas wrote: >> On Mon, Jan 08, 2007 at 03:26:59PM -0600, Josh Boyer wrote: >>> 3) Create the Freeze Review Team >>> >>> This is a group of individuals that would monitor the tracking >>> bug and >>> ACK or NACK the requests. If ACKed, a package would be built and >>> pushed >>> into the repo at that point. >> >> I don't think a Freeze Review Team is needed. I think the >> contributors >> should use their best judgement on whether they build for the frozen >> target or the rolling one, the default being the rolling one, of >> course. >> Using a blocker bug to document why there was a version/package >> released >> for the frozen target and leave a possibility to other >> contributors to >> yell would be the recommended way, however. People interested in >> releases >> could then be in CC of that blocker. > > I'd rather do it the other way. There is going to be QA on-going > of the > test releases and I want the test team (speak up Will) to _know_ > what's > being pushed in. Yeah, I'm not sure I like the idea of a "freeze" without something keeping people from violating it. As Jesse pointed out, it's really hard to keep freezes frozen. It makes testing awful when we don't even get notified of proposed changes. How much churn do we actually expect after the freezes? Couldn't we handle it with the combined Release Cabal and QA Team doing ACK/NACK on proposed changes? Will we need to build something to keep track of proposals and acks? I think RHEL does this with the bugzilla flag stuff, which seems to drive everyone insane, so I'm hoping to avoid the Lovecraftian horrors therein.. -w From jwboyer at jdub.homelinux.org Mon Jan 8 23:25:18 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 08 Jan 2007 17:25:18 -0600 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081757.21421.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> <200701081730.24928.jkeating@redhat.com> <20070108225109.GH3109@free.fr> <200701081757.21421.jkeating@redhat.com> Message-ID: <1168298718.3159.78.camel@vader.jdub.homelinux.org> On Mon, 2007-01-08 at 17:57 -0500, Jesse Keating wrote: > On Monday 08 January 2007 17:51, Patrice Dumas wrote: > > But I can't see why maintainers > > wouldn't be responsible. > > Oh what a wonderful world that would be. But the reality of it is, we need to > be very sure what we're pulling into the compose. +1 I've been through multiple "releases" of one form or another. I have yet to encounter one where explicit release controls weren't required. josh From pertusus at free.fr Mon Jan 8 23:37:33 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 9 Jan 2007 00:37:33 +0100 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <3C9578C5-C8D2-4FC2-BDB5-009382488754@redhat.com> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> <20070108215001.GC3109@free.fr> <1168293501.3159.71.camel@vader.jdub.homelinux.org> <3C9578C5-C8D2-4FC2-BDB5-009382488754@redhat.com> Message-ID: <20070108233733.GK3109@free.fr> On Mon, Jan 08, 2007 at 06:11:49PM -0500, Will Woods wrote: > > Yeah, I'm not sure I like the idea of a "freeze" without something > keeping people from violating it. the default build command being such that a package rebuild is not pushed to the freeze seems enough to me. With proper documentation and agreed guidelines that packages should be rebuilt using the special command that push then to the freeze only if really needed. > As Jesse pointed out, it's really > hard to keep freezes frozen. It makes testing awful when we don't > even get notified of proposed changes. Everyone is notified when packages are pushed. Why more? To help people watching releases, there could be a mail showing what was pushed to the freeze containing only that information (the mail showing what was pushed in extras is for all the releases). > How much churn do we actually expect after the freezes? Couldn't we > handle it with the combined Release Cabal and QA Team doing ACK/NACK > on proposed changes? Why not let the maintainers decide by themselves and let people blame on the lists where the build reports appear? -- Pat From Christian.Iseli at licr.org Mon Jan 8 23:42:53 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 9 Jan 2007 00:42:53 +0100 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <1168291619.3159.68.camel@vader.jdub.homelinux.org> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> Message-ID: <20070109004253.343ad6f7@ludwig-alpha.unil.ch> On Mon, 08 Jan 2007 15:26:59 -0600, Josh Boyer wrote: > 1) Lock down the FE-devel repository Any reason not to do a CVS branch of FC7 right now and go in bug-fixing mode in there until Fedora 7 is out ? No pushing unless the push fixes a reported bug ? Wouldn't that make it simpler ? C From pertusus at free.fr Mon Jan 8 23:46:26 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 9 Jan 2007 00:46:26 +0100 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <1168298718.3159.78.camel@vader.jdub.homelinux.org> References: <200701081341.20700.jkeating@redhat.com> <200701081730.24928.jkeating@redhat.com> <20070108225109.GH3109@free.fr> <200701081757.21421.jkeating@redhat.com> <1168298718.3159.78.camel@vader.jdub.homelinux.org> Message-ID: <20070108234626.GL3109@free.fr> On Mon, Jan 08, 2007 at 05:25:18PM -0600, Josh Boyer wrote: > > > > Oh what a wonderful world that would be. But the reality of it is, we need to > > be very sure what we're pulling into the compose. > > +1 > > I've been through multiple "releases" of one form or another. I have > yet to encounter one where explicit release controls weren't required. Why shouldn't the control of people discussing abusive builds on lists be enough? -- Pat From pertusus at free.fr Mon Jan 8 23:48:37 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 9 Jan 2007 00:48:37 +0100 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081757.21421.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> <200701081730.24928.jkeating@redhat.com> <20070108225109.GH3109@free.fr> <200701081757.21421.jkeating@redhat.com> Message-ID: <20070108234837.GM3109@free.fr> On Mon, Jan 08, 2007 at 05:57:21PM -0500, Jesse Keating wrote: > On Monday 08 January 2007 17:51, Patrice Dumas wrote: > > But I can't see why maintainers > > wouldn't be responsible. > > Oh what a wonderful world that would be. But the reality of it is, we need to > be very sure what we're pulling into the compose. Indeed, but it is better, in my opinion, to do that through education of packagers and collective control from those who cares, rather than through another set of rules. -- Pat From jkeating at redhat.com Tue Jan 9 00:05:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 19:05:35 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108233733.GK3109@free.fr> References: <200701081341.20700.jkeating@redhat.com> <3C9578C5-C8D2-4FC2-BDB5-009382488754@redhat.com> <20070108233733.GK3109@free.fr> Message-ID: <200701081905.38419.jkeating@redhat.com> On Monday 08 January 2007 18:37, Patrice Dumas wrote: > Why not let the maintainers decide by themselves and let people > blame on the lists where the build reports appear? Because then its too late and we've already wasted too much time on spin and test, especially if we're already slipping due to other things and that just doesn't fly. Please have a little faith in those that have done this a few times (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jan 9 00:06:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 19:06:44 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108234626.GL3109@free.fr> References: <200701081341.20700.jkeating@redhat.com> <1168298718.3159.78.camel@vader.jdub.homelinux.org> <20070108234626.GL3109@free.fr> Message-ID: <200701081906.44765.jkeating@redhat.com> On Monday 08 January 2007 18:46, Patrice Dumas wrote: > Why shouldn't the control of people discussing abusive builds on lists > be enough? Because like it or not, not every developer follows the lists and pays attention. It's a fact of life that we deal with, so we have tools in place to keep maintainers from shooting themselves in the foot, and us at the same time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jan 9 00:08:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 8 Jan 2007 19:08:12 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070109004253.343ad6f7@ludwig-alpha.unil.ch> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> <20070109004253.343ad6f7@ludwig-alpha.unil.ch> Message-ID: <200701081908.12896.jkeating@redhat.com> On Monday 08 January 2007 18:42, Christian Iseli wrote: > Any reason not to do a CVS branch of FC7 right now and go in bug-fixing > mode in there until Fedora 7 is out ? ?No pushing unless the push fixes > a reported bug ? > > Wouldn't that make it simpler ? No, the F7 release is a long way off, and there are some things we're still experimenting with that may not make it. Sometime around Test2, the feature freeze it might almost make sense, but even then all it really does is move the problem to another branch, as we're going to still feed rawhide from the collection that will be F7. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Tue Jan 9 00:17:10 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 8 Jan 2007 15:17:10 -0900 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108234837.GM3109@free.fr> References: <200701081341.20700.jkeating@redhat.com> <200701081730.24928.jkeating@redhat.com> <20070108225109.GH3109@free.fr> <200701081757.21421.jkeating@redhat.com> <20070108234837.GM3109@free.fr> Message-ID: <604aa7910701081617o11e8d9abha4f55a9374fb993c@mail.gmail.com> On 1/8/07, Patrice Dumas wrote: > Indeed, but it is better, in my opinion, to do that through education > of packagers and collective control from those who cares, rather than > through another set of rules. Untarnished idealism is nice, and I applaud your identification of packager education and collective negotiation of interests as central issues in the growing contributor space. But.... there are practical considerations concerning how release engineering is done so we do this in a timely an orderly manner. There absolutely needs to be brief periods of time when the tree is frozen and gatekeepers are in place, to act as a safety valve against human action that is out-of-sync with the freeze process. To re-cast this in terms of brick-and-mortar issues, there is a very common concept in industrial safety call "Lock-out/Tag-out." When potentially hazardous equipment is undergoing service that impacts the safe operation of other pieces of equipment, the whole chain of equipment which is affected is locked and tagged so that normal operation is absolutely not possible and people are aware as to why the equipment is out of service by reading the tag. You can have mountains of trust in the equipment operators , and you can put them into meetings for hours and hours telling them not to operate the equipment on a certain day...but if you don't lock it out and physically prevent them from operating it... it will be a big problem, a problem that's not worth the risk, even if your employees feel slighted about not being trusted to that extent. That is exactly what a build system freeze with a group of gatekeepers is for a Fedora Release.. its a lock-out/tag-out process to make sure things we don't accidentally break pieces of a larger system through normal operation actions. It's not personal... its sound management. It doesn't matter if the actions are malicious or not, there doesn't need to be malicious intent for a mistake. Its much easier in the long run to train people to respect lock-out/tag-out when it needs to happen than it is to try to find ways to avoid locking people out to make people feel better about their personal control issues. -jef"wtf am I doing, quoting integrated line safety management concepts to code developers"spaleta From Axel.Thimm at ATrpms.net Tue Jan 9 00:22:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 9 Jan 2007 01:22:24 +0100 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081719.12780.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> <20070108220340.GI18545@neu.nirvana> <200701081719.12780.jkeating@redhat.com> Message-ID: <20070109002224.GJ18545@neu.nirvana> On Mon, Jan 08, 2007 at 05:19:12PM -0500, Jesse Keating wrote: > On Monday 08 January 2007 17:03, Axel Thimm wrote: > > Would it make sense to only freeze the packages that are being used > > for the spins? > > > > That way people would be able to continue on other packages, but still > > contribute to testing the spins since they continue building on them > > and also need to use the frozen spin packages to run theirs. > > Given that we can enable the massive repo at install time, the entire repo > should be frozen (and consistant with regard to deps/conflicts). Indeed, I forgot about that. No, you are right, all packages can contribute to install-time breakage, so all packages should be frozen. Sorry for turning my brain off. :/ -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Tue Jan 9 01:52:33 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 9 Jan 2007 02:52:33 +0100 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108233733.GK3109@free.fr> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> <20070108215001.GC3109@free.fr> <1168293501.3159.71.camel@vader.jdub.homelinux.org> <3C9578C5-C8D2-4FC2-BDB5-009382488754@redhat.com> <20070108233733.GK3109@free.fr> Message-ID: <20070109025233.f81461f7.bugs.michael@gmx.net> On Tue, 9 Jan 2007 00:37:33 +0100, Patrice Dumas wrote: > Everyone is notified when packages are pushed. Why more? To help people > watching releases, there could be a mail showing what was pushed to the > freeze containing only that information (the mail showing what was pushed > in extras is for all the releases). Nothing to worry about. It's an implementation detail that the build reports for the multiple targets are combined into one mail. It is like that so by default no information about published packages is lost when there is a sync to the master repository. If, however, a single target is pushed only, only a single mail is sent. It is easy to add another target to the pushscript, which must be pushed separately and would send a separate mail. Currently, what is executed most often is "extras-push all", which is short for "Push.py Extras all" and "Push.py Extras 5 6 development". Assuming plague would add a separate target, e.g. "fc7" for the freezed pre-Fedora 7 repository, one would not add it to the default config profile of the pushscript, but put it into a separate one. Only executing something different then, like "Push.py FreezedExtras 7", would publish the pending packages and send a separate mail. Publishing individual packages is not possible without adding some more lines of code first. It's no hurdle though. The current implementation knows about source rpm package names (and hence about individual build job results), but simply doesn't do any filtering and always pushes all build results. From tibbs at math.uh.edu Tue Jan 9 05:06:42 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Jan 2007 23:06:42 -0600 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <200701081908.12896.jkeating@redhat.com> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> <20070109004253.343ad6f7@ludwig-alpha.unil.ch> <200701081908.12896.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: [Regarding branching F7 now] JK> No, the F7 release is a long way off, and there are some things JK> we're still experimenting with that may not make it. Sometime JK> around Test2, the feature freeze it might almost make sense, but JK> even then all it really does is move the problem to another JK> branch, as we're going to still feed rawhide from the collection JK> that will be F7. So then what do we do about new packages? If we have no development branch to import them to, we have to decide whether to stop new imports or somehow exempt new packages from the freeze. - J< From nicolas.mailhot at laposte.net Tue Jan 9 08:30:09 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 9 Jan 2007 09:30:09 +0100 (CET) Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108220259.GD3109@free.fr> References: <200701081341.20700.jkeating@redhat.com> <1168291619.3159.68.camel@vader.jdub.homelinux.org> <20070108215001.GC3109@free.fr> <200701081658.56921.jkeating@redhat.com> <20070108220259.GD3109@free.fr> Message-ID: <59172.192.54.193.51.1168331409.squirrel@rousalka.dyndns.org> Le Lun 8 janvier 2007 23:02, Patrice Dumas a ?crit : > On Mon, Jan 08, 2007 at 04:58:56PM -0500, Jesse Keating wrote: >> >> Getting the mass community of packagers to notice we're in a freeze will >> be >> impossible. Things will get in that will cause problems. This happens >> even >> within Red Hat just on the Core set. I'd rather not fight it with 2x >> the >> packages. > > The jobs submitted regularly won't be pushed to the frozen package set, > so the packagers ignoring the issue won't put anything in the frozen > packages > set. Let's say I have a package with next upstream release announced around the freeze time (+/- 2 days IIRC?). If I want to get it in test1, can I wait for upstream release or push a rc now and "fix" it after freeze? ? we all know releases can slip a little -- Nicolas Mailhot From jkeating at redhat.com Tue Jan 9 13:11:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 9 Jan 2007 08:11:00 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <59172.192.54.193.51.1168331409.squirrel@rousalka.dyndns.org> References: <200701081341.20700.jkeating@redhat.com> <20070108220259.GD3109@free.fr> <59172.192.54.193.51.1168331409.squirrel@rousalka.dyndns.org> Message-ID: <200701090811.08680.jkeating@redhat.com> On Tuesday 09 January 2007 03:30, Nicolas Mailhot wrote: > Let's say I have a package with next upstream release announced around the > freeze time (+/- 2 days IIRC?). If I want to get it in test1, can I wait > for upstream release or push a rc now and "fix" it after freeze? > > ? we all know releases can slip a little Depends on the quality of the upstream RC releases. If you're confident, I'd say go ahead, but if you're just guessing, I'd say please no. Also, the freeze deadline isn't a deadline to get all your untested builds in. One of the reasons we have so many slips is that people rush their builds to get in before the freeze and then we have this huge crap pile that we have to stabilize during the freeze, which just takes time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jan 9 13:12:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 9 Jan 2007 08:12:04 -0500 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: References: <200701081341.20700.jkeating@redhat.com> <200701081908.12896.jkeating@redhat.com> Message-ID: <200701090812.04757.jkeating@redhat.com> On Tuesday 09 January 2007 00:06, Jason L Tibbitts III wrote: > So then what do we do about new packages? ?If we have no development > branch to import them to, we have to decide whether to stop new > imports or somehow exempt new packages from the freeze. Either stop imports, or just don't let the new packages make it into the freeze collection. Hold up publishing them until after the freeze. We're only talking a week or two, this shouldn't be a huge issue. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ikent at redhat.com Tue Jan 9 15:59:04 2007 From: ikent at redhat.com (Ian Kent) Date: Wed, 10 Jan 2007 00:59:04 +0900 Subject: Freeze for Test1 is in 2 weeks + 1 day In-Reply-To: <20070108234626.GL3109@free.fr> References: <200701081341.20700.jkeating@redhat.com> <200701081730.24928.jkeating@redhat.com> <20070108225109.GH3109@free.fr> <200701081757.21421.jkeating@redhat.com> <1168298718.3159.78.camel@vader.jdub.homelinux.org> <20070108234626.GL3109@free.fr> Message-ID: <1168358344.3641.35.camel@raven.themaw.net> On Tue, 2007-01-09 at 00:46 +0100, Patrice Dumas wrote: > On Mon, Jan 08, 2007 at 05:25:18PM -0600, Josh Boyer wrote: > > > > > > Oh what a wonderful world that would be. But the reality of it is, we need to > > > be very sure what we're pulling into the compose. > > > > +1 > > > > I've been through multiple "releases" of one form or another. I have > > yet to encounter one where explicit release controls weren't required. > > Why shouldn't the control of people discussing abusive builds on lists > be enough? Because don't want to cause the release engineers so much frustration that they pull out all their hair. Release management is needed and it's hard enough to do even with enough admin controls. Ian From seg at haxxed.com Tue Jan 9 17:36:19 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 09 Jan 2007 11:36:19 -0600 Subject: Disttag for Fedora 7 and beyond In-Reply-To: <1168201796.14818.111.camel@localhost.localdomain> References: <20070105074343.GB22825@neu.nirvana> <459E5D9D.4060800@timj.co.uk> <1168200679.6142.20.camel@max.booze> <200701071515.28502.jkeating@redhat.com> <1168201796.14818.111.camel@localhost.localdomain> Message-ID: <1168364181.13222.10.camel@localhost.localdomain> On Sun, 2007-01-07 at 12:29 -0800, Toshio Kuratomi wrote: > On Sun, 2007-01-07 at 15:15 -0500, Jesse Keating wrote: > > I'd like to see that, however that should cause a pretty big version bump. > > Changing the output like that is not to be taken lightly. > > We could add this as a new commandline switch rather than replacing > -q/-qa with it. Yet more command line options? Why? Either this new output format is a desirable default or not. Though in Fedora terms, waiting for a new major release (F7) to make a change like this is certainly reasonable. Which if this is done upstream should work out that way anyway. -------------- 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 bugs.michael at gmx.net Tue Jan 9 19:14:07 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 9 Jan 2007 20:14:07 +0100 Subject: More Extras orphans on the hit list - 20070109 Message-ID: <20070109201407.43826104.bugs.michael@gmx.net> The following Fedora Extras packages have been orphaned last year (after Nov 1st) and need a new maintainer: deltarpm gaim-guifications gdome2 gstreamer08 gstreamer08-plugins gstreamer08-python gtranslator perl-String-Ediff python-htmltmpl python-id3 As usual they will be removed from the development repository and will be disabled in CVS rather sooner than later. The last round of removals was on Nov 1st, 2006. How to claim ownership of an orphaned package...? http://fedoraproject.org/wiki/Extras/OrphanedPackages From ajackson at redhat.com Tue Jan 9 19:11:19 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 09 Jan 2007 14:11:19 -0500 Subject: More Extras orphans on the hit list - 20070109 In-Reply-To: <20070109201407.43826104.bugs.michael@gmx.net> References: <20070109201407.43826104.bugs.michael@gmx.net> Message-ID: <1168369879.7683.651.camel@localhost.localdomain> On Tue, 2007-01-09 at 20:14 +0100, Michael Schwendt wrote: > The following Fedora Extras packages have been orphaned last year (after > Nov 1st) and need a new maintainer: > > deltarpm I can take this. - ajax From jgarzik at redhat.com Tue Jan 9 19:40:17 2007 From: jgarzik at redhat.com (Jeff Garzik) Date: Tue, 9 Jan 2007 14:40:17 -0500 Subject: More Extras orphans on the hit list - 20070109 In-Reply-To: <20070109201407.43826104.bugs.michael@gmx.net> References: <20070109201407.43826104.bugs.michael@gmx.net> Message-ID: <20070109194017.GJ1055@devserv.devel.redhat.com> On Tue, Jan 09, 2007 at 08:14:07PM +0100, Michael Schwendt wrote: > The following Fedora Extras packages have been orphaned last year (after > Nov 1st) and need a new maintainer: > > perl-String-Ediff As an aside... A great many Perl modules can be maintained on 'autopilot' by using the cpan2rpm tool found in Fedora Extras... Jeff From chrisw at redhat.com Tue Jan 9 19:51:56 2007 From: chrisw at redhat.com (Chris Wright) Date: Tue, 9 Jan 2007 11:51:56 -0800 Subject: More Extras orphans on the hit list - 20070109 In-Reply-To: <20070109194017.GJ1055@devserv.devel.redhat.com> References: <20070109201407.43826104.bugs.michael@gmx.net> <20070109194017.GJ1055@devserv.devel.redhat.com> Message-ID: <20070109195156.GH10475@sequoia.sous-sol.org> * Jeff Garzik (jgarzik at redhat.com) wrote: > On Tue, Jan 09, 2007 at 08:14:07PM +0100, Michael Schwendt wrote: > > The following Fedora Extras packages have been orphaned last year (after > > Nov 1st) and need a new maintainer: > > > > perl-String-Ediff > > As an aside... > > A great many Perl modules can be maintained on 'autopilot' by using the > cpan2rpm tool found in Fedora Extras... I looked at that at one point, but the spec files weren't up to par for Fedora Extras. Was an OK starting point, but still needed intervention. thanks, -chris From bugs.michael at gmx.net Tue Jan 9 20:06:22 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 9 Jan 2007 21:06:22 +0100 Subject: File conflicts in Fedora Extras devel - 20070109 Message-ID: <20070109210622.8b03dc7f.bugs.michael@gmx.net> This is just a reminder. These are all non-explicit package conflicts found in FE development. I've filed several tickets plus a few more for FE<=6 (check out the FE7Target bug) some time ago or some minutes ago, but not all, because there is no policy about it. blackbox - 0.70.1-5.fc6.i386 File conflict with: /usr/bin/bsetbg File conflict with: /usr/bin/bsetroot => Package conflicts with: hackedbox - 0.8.4-7.fc6.i386 libextractor - 0.5.17-2.fc7.i386 File conflict with: /usr/bin/extract => Package conflicts with: csound - 5.03.0-9.fc7.i386 => Package conflicts with: html-xml-utils - 3.7-4.fc6.i386 QuantLib-doc - 0.3.14-1.fc7.i386 File conflict with: /usr/share/man/man3/error.3.gz File conflict with: /usr/share/man/man3/y0.3.gz File conflict with: /usr/share/man/man3/err.3.gz File conflict with: /usr/share/man/man3/floor.3.gz => Package conflicts with: man-pages - 2.43-2.fc7.noarch hackedbox - 0.8.4-7.fc6.i386 File conflict with: /usr/bin/bsetbg File conflict with: /usr/bin/bsetroot => Package conflicts with: blackbox - 0.70.1-5.fc6.i386 plib-devel - 1.8.4-8.fc6.i386 File conflict with: /usr/include/plib/ssgKeyFlier.h File conflict with: /usr/include/plib/sg.h File conflict with: /usr/include/plib/pu.h File conflict with: /usr/include/plib/ssgconf.h File conflict with: /usr/include/plib/slPortability.h File conflict with: /usr/include/plib/ssgAux.h File conflict with: /usr/include/plib/sl.h File conflict with: /usr/include/plib/sm.h File conflict with: /usr/include/plib/fnt.h File conflict with: /usr/include/plib/netChannel.h File conflict with: /usr/include/plib/netSocket.h File conflict with: /usr/include/plib/netMessage.h File conflict with: /usr/include/plib/netBuffer.h File conflict with: /usr/include/plib/ssg.h File conflict with: /usr/include/plib/netMonitor.h File conflict with: /usr/include/plib/ulRTTI.h File conflict with: /usr/include/plib/ssgaWaveSystem.h File conflict with: /usr/include/plib/ul.h File conflict with: /usr/include/plib/js.h => Package conflicts with: plib16-devel - 1.6.0-6.fc6.i386 python-twisted-web - 0.6.0-4.fc7.i386 File conflict with: /usr/bin/websetroot File conflict with: /usr/share/man/man1/websetroot.1.gz => Package conflicts with: python-twisted - 1.3.0-7.fc6.i386 uw-imap - 2006d-1.fc7.i386 File conflict with: /etc/pam.d/imap File conflict with: /etc/pam.d/pop File conflict with: /usr/share/man/man8/imapd.8.gz => Package conflicts with: cyrus-imapd - 2.3.7-6.fc7.i386 gdesklets - 0.35.4-4.fc7.i386 File conflict with: /usr/share/locale/ru/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/sv/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/de/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/hr/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/fr/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/cs/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/ja/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/ko/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/ar/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/is/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/nl/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/zh_TW/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/lt/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/pl/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/el/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/es/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/zh_CN/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/sr/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/vi/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/bg/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/he/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/hu/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/uk/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/tr/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/it/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/fi/LC_MESSAGES/gdesklets.mo => Package conflicts with: gdeskcal - 1.0-10.fc7.noarch python-twisted-conch - 0.7.0-4.fc7.i386 File conflict with: /usr/bin/tkconch File conflict with: /usr/bin/conch File conflict with: /usr/bin/ckeygen File conflict with: /usr/share/man/man1/conch.1.gz File conflict with: /usr/share/man/man1/ckeygen.1.gz File conflict with: /usr/share/man/man1/tkconch.1.gz => Package conflicts with: python-twisted - 1.3.0-7.fc6.i386 python-twisted - 1.3.0-7.fc6.i386 File conflict with: /usr/bin/tkconch File conflict with: /usr/bin/tkconch File conflict with: /usr/bin/manhole File conflict with: /usr/bin/manhole File conflict with: /usr/bin/conch File conflict with: /usr/bin/conch File conflict with: /usr/bin/lore File conflict with: /usr/bin/lore File conflict with: /usr/bin/mktap File conflict with: /usr/bin/mktap File conflict with: /usr/bin/im File conflict with: /usr/bin/im File conflict with: /usr/bin/tap2deb File conflict with: /usr/bin/tap2deb File conflict with: /usr/bin/mailmail File conflict with: /usr/bin/mailmail File conflict with: /usr/bin/twistd File conflict with: /usr/bin/twistd File conflict with: /usr/bin/trial File conflict with: /usr/bin/trial File conflict with: /usr/bin/tapconvert File conflict with: /usr/bin/tapconvert File conflict with: /usr/bin/websetroot File conflict with: /usr/bin/websetroot File conflict with: /usr/bin/ckeygen File conflict with: /usr/bin/ckeygen File conflict with: /usr/bin/tkmktap File conflict with: /usr/bin/tkmktap File conflict with: /usr/share/man/man1/conch.1.gz File conflict with: /usr/bin/im File conflict with: /usr/bin/im File conflict with: /usr/share/man/man1/manhole.1.gz File conflict with: /usr/share/man/man1/tap2rpm.1.gz File conflict with: /usr/bin/mailmail File conflict with: /usr/bin/mailmail File conflict with: /usr/share/man/man1/tkconch.1.gz File conflict with: /usr/share/man/man1/lore.1.gz File conflict with: /usr/bin/tap2deb File conflict with: /usr/bin/tap2deb File conflict with: /usr/share/man/man1/twistd.1.gz File conflict with: /usr/bin/websetroot File conflict with: /usr/bin/websetroot File conflict with: /usr/share/man/man1/mailmail.1.gz File conflict with: /usr/bin/tapconvert File conflict with: /usr/bin/tapconvert File conflict with: /usr/bin/mktap File conflict with: /usr/bin/mktap File conflict with: /usr/share/man/man1/mktap.1.gz File conflict with: /usr/share/man/man1/t-im.1.gz File conflict with: /usr/share/man/man1/tap2deb.1.gz File conflict with: /usr/share/man/man1/tkmktap.1.gz File conflict with: /usr/bin/trial File conflict with: /usr/bin/trial File conflict with: /usr/bin/manhole File conflict with: /usr/bin/manhole File conflict with: /usr/bin/ckeygen File conflict with: /usr/bin/ckeygen File conflict with: /usr/share/man/man1/ckeygen.1.gz File conflict with: /usr/bin/lore File conflict with: /usr/bin/lore File conflict with: /usr/share/man/man1/websetroot.1.gz File conflict with: /usr/bin/tkmktap File conflict with: /usr/bin/tkmktap File conflict with: /usr/bin/conch File conflict with: /usr/bin/conch File conflict with: /usr/bin/tkconch File conflict with: /usr/bin/tkconch File conflict with: /usr/share/man/man1/tapconvert.1.gz File conflict with: /usr/share/man/man1/im.1.gz File conflict with: /usr/bin/twistd File conflict with: /usr/bin/twistd File conflict with: /usr/share/man/man1/trial.1.gz => Package conflicts with: python-twisted-core - 2.4.0-6.fc7.i386 => Package conflicts with: python-twisted-mail - 0.3.0-4.fc7.i386 => Package conflicts with: python-twisted-conch - 0.7.0-4.fc7.i386 => Package conflicts with: python-twisted-words - 0.4.0-3.fc7.i386 => Package conflicts with: python-twisted-lore - 0.2.0-4.fc7.i386 => Package conflicts with: python-twisted-web - 0.6.0-4.fc7.i386 python-twisted-words - 0.4.0-3.fc7.i386 File conflict with: /usr/bin/im File conflict with: /usr/share/man/man1/im.1.gz File conflict with: /usr/share/man/man1/t-im.1.gz => Package conflicts with: python-twisted - 1.3.0-7.fc6.i386 csound - 5.03.0-9.fc7.i386 File conflict with: /usr/bin/extract => Package conflicts with: libextractor - 0.5.17-2.fc7.i386 => Package conflicts with: html-xml-utils - 3.7-4.fc6.i386 python-twisted-core - 2.4.0-6.fc7.i386 File conflict with: /usr/bin/manhole File conflict with: /usr/bin/manhole File conflict with: /usr/bin/mktap File conflict with: /usr/bin/mktap File conflict with: /usr/bin/tap2deb File conflict with: /usr/bin/tap2deb File conflict with: /usr/bin/twistd File conflict with: /usr/bin/twistd File conflict with: /usr/bin/trial File conflict with: /usr/bin/trial File conflict with: /usr/bin/tapconvert File conflict with: /usr/bin/tapconvert File conflict with: /usr/bin/tkmktap File conflict with: /usr/bin/tkmktap File conflict with: /usr/share/man/man1/mktap.1.gz File conflict with: /usr/bin/trial File conflict with: /usr/bin/trial File conflict with: /usr/bin/manhole File conflict with: /usr/bin/manhole File conflict with: /usr/share/man/man1/tap2deb.1.gz File conflict with: /usr/bin/mktap File conflict with: /usr/bin/mktap File conflict with: /usr/share/man/man1/tapconvert.1.gz File conflict with: /usr/bin/tapconvert File conflict with: /usr/bin/tapconvert File conflict with: /usr/bin/tap2deb File conflict with: /usr/bin/tap2deb File conflict with: /usr/share/man/man1/tkmktap.1.gz File conflict with: /usr/share/man/man1/trial.1.gz File conflict with: /usr/share/man/man1/manhole.1.gz File conflict with: /usr/bin/twistd File conflict with: /usr/bin/twistd File conflict with: /usr/share/man/man1/tap2rpm.1.gz File conflict with: /usr/bin/tkmktap File conflict with: /usr/bin/tkmktap File conflict with: /usr/share/man/man1/twistd.1.gz => Package conflicts with: python-twisted - 1.3.0-7.fc6.i386 plib16-devel - 1.6.0-6.fc6.i386 File conflict with: /usr/include/plib/ssgKeyFlier.h File conflict with: /usr/include/plib/sg.h File conflict with: /usr/include/plib/pu.h File conflict with: /usr/include/plib/ssgconf.h File conflict with: /usr/include/plib/slPortability.h File conflict with: /usr/include/plib/ssgAux.h File conflict with: /usr/include/plib/ssg.h File conflict with: /usr/include/plib/sl.h File conflict with: /usr/include/plib/sm.h File conflict with: /usr/include/plib/fnt.h File conflict with: /usr/include/plib/netChannel.h File conflict with: /usr/include/plib/netSocket.h File conflict with: /usr/include/plib/netMessage.h File conflict with: /usr/include/plib/netBuffer.h File conflict with: /usr/include/plib/ssgaWaveSystem.h File conflict with: /usr/include/plib/netMonitor.h File conflict with: /usr/include/plib/ulRTTI.h File conflict with: /usr/include/plib/ul.h File conflict with: /usr/include/plib/js.h => Package conflicts with: plib-devel - 1.8.4-8.fc6.i386 python-twisted-lore - 0.2.0-4.fc7.i386 File conflict with: /usr/bin/lore File conflict with: /usr/bin/lore File conflict with: /usr/share/man/man1/lore.1.gz File conflict with: /usr/bin/lore File conflict with: /usr/bin/lore => Package conflicts with: python-twisted - 1.3.0-7.fc6.i386 html-xml-utils - 3.7-4.fc6.i386 File conflict with: /usr/bin/count File conflict with: /usr/bin/count File conflict with: /usr/bin/extract File conflict with: /usr/bin/extract File conflict with: /usr/bin/extract File conflict with: /usr/bin/extract File conflict with: /usr/bin/count File conflict with: /usr/bin/count File conflict with: /usr/bin/extract File conflict with: /usr/bin/extract File conflict with: /usr/bin/extract File conflict with: /usr/bin/extract File conflict with: /usr/share/man/man1/count.1.gz => Package conflicts with: fish - 1.21.12-1.fc6.i386 => Package conflicts with: libextractor - 0.5.17-2.fc7.i386 => Package conflicts with: csound - 5.03.0-9.fc7.i386 python-twisted-mail - 0.3.0-4.fc7.i386 File conflict with: /usr/bin/mailmail File conflict with: /usr/bin/mailmail File conflict with: /usr/bin/mailmail File conflict with: /usr/bin/mailmail File conflict with: /usr/share/man/man1/mailmail.1.gz => Package conflicts with: python-twisted - 1.3.0-7.fc6.i386 cyrus-imapd - 2.3.7-6.fc7.i386 File conflict with: /etc/pam.d/imap File conflict with: /etc/pam.d/imap File conflict with: /etc/pam.d/pop File conflict with: /etc/pam.d/pop File conflict with: /etc/pam.d/pop File conflict with: /etc/pam.d/pop File conflict with: /usr/share/man/man8/imapd.8.gz File conflict with: /etc/pam.d/imap File conflict with: /etc/pam.d/imap => Package conflicts with: uw-imap - 2006d-1.fc7.i386 gdeskcal - 1.0-10.fc7.noarch File conflict with: /usr/share/locale/ru/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/ko/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/zh_TW/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/bg/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/lt/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/pl/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/hu/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/ar/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/uk/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/hr/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/el/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/he/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/cs/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/es/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/sv/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/de/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/tr/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/ja/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/it/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/fi/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/nl/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/is/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/fr/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/zh_CN/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/sr/LC_MESSAGES/gdesklets.mo File conflict with: /usr/share/locale/vi/LC_MESSAGES/gdesklets.mo => Package conflicts with: gdesklets - 0.35.4-4.fc7.i386 fish - 1.21.12-1.fc6.i386 File conflict with: /usr/bin/count File conflict with: /usr/bin/count File conflict with: /usr/bin/count File conflict with: /usr/bin/count File conflict with: /usr/share/man/man1/count.1.gz => Package conflicts with: html-xml-utils - 3.7-4.fc6.i386 From williams at redhat.com Tue Jan 9 23:42:02 2007 From: williams at redhat.com (Clark Williams) Date: Tue, 09 Jan 2007 17:42:02 -0600 Subject: More Extras orphans on the hit list - 20070109 In-Reply-To: <20070109201407.43826104.bugs.michael@gmx.net> References: <20070109201407.43826104.bugs.michael@gmx.net> Message-ID: <45A4284A.2020801@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > The following Fedora Extras packages have been orphaned last year (after > Nov 1st) and need a new maintainer: > > python-id3 Michael, I had earlier expressed interest in maintaining this, but the python-eyed3 package does everything I need and seems to be under active development. Unless someone screams for it, I'd say let this one go. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFpChJHyuj/+TTEp0RAh6IAKC4KdrJe5cX1xG6qdRE7M3487kvNwCgpwLq iczsH+k8QTvByVBsM3H7XM4= =ggI6 -----END PGP SIGNATURE----- From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jan 10 10:24:28 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 10 Jan 2007 11:24:28 +0100 Subject: File conflicts in Fedora Extras devel - 20070109 In-Reply-To: <20070109210622.8b03dc7f.bugs.michael@gmx.net> References: <20070109210622.8b03dc7f.bugs.michael@gmx.net> Message-ID: <20070110112428.7e2baf3d@python3.es.egwn.lan> Michael Schwendt wrote : > This is just a reminder. Thanks for the reminder :-) > These are all non-explicit package conflicts found in FE development. > I've filed several tickets plus a few more for FE<=6 (check out the > FE7Target bug) some time ago or some minutes ago, but not all, because > there is no policy about it. > > blackbox - 0.70.1-5.fc6.i386 > File conflict with: /usr/bin/bsetbg > File conflict with: /usr/bin/bsetroot > => Package conflicts with: hackedbox - 0.8.4-7.fc6.i386 [...] > hackedbox - 0.8.4-7.fc6.i386 > File conflict with: /usr/bin/bsetbg > File conflict with: /usr/bin/bsetroot > => Package conflicts with: blackbox - 0.70.1-5.fc6.i386 This one has already been filed : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212318 I still haven't taken time to fix it, as I consider it a minor issue, but anyone wanting to contribute a quick fix/patch is more than welcome to do so! Simply renaming the b* binaries to h* instead might even be sufficient, but further checking and testing is in order. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2888.fc6 Load : 0.37 0.32 0.46 From Axel.Thimm at ATrpms.net Wed Jan 10 10:36:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 10 Jan 2007 11:36:19 +0100 Subject: File conflicts in Fedora Extras devel - 20070109 In-Reply-To: <20070109210622.8b03dc7f.bugs.michael@gmx.net> References: <20070109210622.8b03dc7f.bugs.michael@gmx.net> Message-ID: <20070110103619.GA8195@neu.nirvana> On Tue, Jan 09, 2007 at 09:06:22PM +0100, Michael Schwendt wrote: > This is just a reminder. > > These are all non-explicit package conflicts found in FE development. > I've filed several tickets plus a few more for FE<=6 (check out the > FE7Target bug) some time ago or some minutes ago, but not all, because > there is no policy about it. > > blackbox - 0.70.1-5.fc6.i386 > File conflict with: /usr/bin/bsetbg > File conflict with: /usr/bin/bsetroot > => Package conflicts with: hackedbox - 0.8.4-7.fc6.i386 Which tool are you using for finding this out? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Wed Jan 10 14:31:11 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 10 Jan 2007 15:31:11 +0100 Subject: File conflicts in Fedora Extras devel - 20070109 In-Reply-To: <20070109210622.8b03dc7f.bugs.michael@gmx.net> References: <20070109210622.8b03dc7f.bugs.michael@gmx.net> Message-ID: <45A4F8AF.6070408@hhs.nl> Michael Schwendt wrote: > This is just a reminder. > > plib-devel - 1.8.4-8.fc6.i386 > File conflict with: /usr/include/plib/ssgKeyFlier.h > File conflict with: /usr/include/plib/sg.h > File conflict with: /usr/include/plib/pu.h > File conflict with: /usr/include/plib/ssgconf.h > File conflict with: /usr/include/plib/slPortability.h > File conflict with: /usr/include/plib/ssgAux.h > File conflict with: /usr/include/plib/sl.h > File conflict with: /usr/include/plib/sm.h > File conflict with: /usr/include/plib/fnt.h > File conflict with: /usr/include/plib/netChannel.h > File conflict with: /usr/include/plib/netSocket.h > File conflict with: /usr/include/plib/netMessage.h > File conflict with: /usr/include/plib/netBuffer.h > File conflict with: /usr/include/plib/ssg.h > File conflict with: /usr/include/plib/netMonitor.h > File conflict with: /usr/include/plib/ulRTTI.h > File conflict with: /usr/include/plib/ssgaWaveSystem.h > File conflict with: /usr/include/plib/ul.h > File conflict with: /usr/include/plib/js.h > => Package conflicts with: plib16-devel - 1.6.0-6.fc6.i386 > I filed a bug for this against plib16-devel: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222111 Regards, Hans From fedora at leemhuis.info Wed Jan 10 18:35:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 10 Jan 2007 19:35:45 +0100 Subject: Plan for tomorrows (20070110) FESCO meeting Message-ID: <45A53201.3060208@leemhuis.info> Hi all, find below the list of topics that are likely to come up in the next FESCo meeting that scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-extras on irc.freenode.org. > /topic FESCO-Meeting -- FESCo changes FYI: Part of this topic: Elect a new chair. I'm doing the job for one year and it's IMHO time for me to leave and let one of the others handle it to get some new ideas into the game. I'll remain in FESCo for now. > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- EPEL doesn't really lift of -- what do? > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- open elep to sponsors and people with 5 packages or more -- why wasn't that announced properly? > /topic FESCO-Meeting -- Opening Core -- rdieter, jeremy, warren -- FESCo future? Deadlock? [WWW] https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00003.html) > /topic FESCO-Meeting -- Opening Core -- jeremy, warren -- how to actually do the merge (sponsership and review issues) > /topic FESCO-Meeting -- Encourage co-maintainership -- c4chris > /topic FESCO-Meeting -- MISC -- firefox updates in stable often breaks quite some packages (galeon, liferia, ...); do we need some kind of task force that steps up to rebuild the stuff? > /topic FESCO-Meeting -- MISC -- disallow cvs-import for everything but the initial import? > /topic FESCO-Meeting -- MISC -- "what do we want like to see in the approved-message in a review bug" -- [WWW] https://www.redhat.com/archives/fedora-maintainers/2006-December/msg00214.html > /topic FESCo-Meeting -- MISC -- the "syslog-ng patent problems" [WWW] https://www.redhat.com/archives/fedora-maintainers/2007-January/msg00015.html > /topic FESCo-Meeting -- MISC -- kernel-naming [WWW] https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00581.html > /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop I haven't seen any reports from the PC to the list yet. > /topic FESCo meeting -- Maintainer Responsibility Policy -- bpepple > /topic FESCo meeting -- Free discussion around Fedora Extras The meeting rules can be found at: http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... The schedule page in the wiki has more details on the individual topics; see http://www.fedoraproject.org/wiki/Extras/Schedule The individual pages specific to the topics are linked from there. The same as above holds true: if you name is somewhere on the schedule page in the wiki please update the status in the wiki ahead of the meeting. Ohh, and please update it also directly after the meeting so it's update and prepared for next weeks meeting :-) Hint: If you want to know what FESCo is doing simply subscribe in the wiki to "Extras/Schedul.*" and you'll get mails if something changes in that areas of the wiki. That should give you a good idea of FESCo's work. CU thl From buildsys at fedoraproject.org Thu Jan 11 00:08:51 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 10 Jan 2007 19:08:51 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-01-10 Message-ID: <20070111000851.068F415212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) cgoorah AT yahoo.com.au: ngspice FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) devrim AT commandprompt.com: phpPgAdmin FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-5.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-6.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) tcallawa AT redhat.com: ntfs-3g FE5 > FE7 (2:0-0.7.20070920.fc5 > 1:0-0.6.20070102.fc7) FE6 > FE7 (2:0-0.7.20070920.fc6 > 1:0-0.6.20070102.fc7) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) ngspice: cgoorah AT yahoo.com.au FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) ntfs-3g: tcallawa AT redhat.com FE5 > FE7 (2:0-0.7.20070920.fc5 > 1:0-0.6.20070102.fc7) FE6 > FE7 (2:0-0.7.20070920.fc6 > 1:0-0.6.20070102.fc7) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) phpPgAdmin: devrim AT commandprompt.com FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-5.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-6.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From roland at redhat.com Thu Jan 11 09:54:37 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 11 Jan 2007 01:54:37 -0800 (PST) Subject: elfutils-devel-static, elfutils-libelf-devel-static Message-ID: <20070111095437.407CE1800E5@magilla.sf.frob.com> In rawhide, libelf.a and libdw.a have moved to new rpms. If you need to do a static link against libelf.a or libdw.a, you need a buildreq on elfutils-libelf-devel-static or elfutils-devel-static now. I couldn't really tell if rpm did this or not, but it seemed like it might, at least in debugedit. I don't expect anything else statically links libelf or libdw, and probably nothing should. In the fc6 and el5 updates, I added -static rpms but made -devel require them so that old requires: elfutils-libelf-devel or elfutils-devel will still be sufficient, but specs can update to -static buildreqs if they need them. Thanks, Roland From limb at jcomserv.net Thu Jan 11 12:20:39 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 11 Jan 2007 06:20:39 -0600 (CST) Subject: CVS problem Message-ID: <5499.65.192.24.190.1168518039.squirrel@mail.jcomserv.net> Hi. I'm a new maintainer, and have been sponsored for approximately 20 hours. I've followed the directions on the wiki regarding GPG keys, certificates, plague and cvs, and I am unable to check out common to begin the import process for my package (review bug 214830). A "screenshot": [limb at zanoni cvs]$ cvs co common Permission denied (publickey,keyboard-interactive). cvs [checkout aborted]: end of file from server (consult above messages if any) Any suggestions? I would have thought permissions would have propagated by now. I checked with my sponsor and we're both at a loss. Thank you in advance, Jon Ciesla -- novus ordo absurdum From Christian.Iseli at licr.org Thu Jan 11 13:27:37 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 11 Jan 2007 14:27:37 +0100 Subject: CVS problem In-Reply-To: <5499.65.192.24.190.1168518039.squirrel@mail.jcomserv.net> References: <5499.65.192.24.190.1168518039.squirrel@mail.jcomserv.net> Message-ID: <20070111142737.1e9325d0@ludwig-alpha.unil.ch> On Thu, 11 Jan 2007 06:20:39 -0600 (CST), Jon Ciesla wrote: > [limb at zanoni cvs]$ cvs co common > Permission denied (publickey,keyboard-interactive). > cvs [checkout aborted]: end of file from server (consult above messages if > any) Can you show the output of: $ env|grep CVS C From limb at jcomserv.net Thu Jan 11 13:36:58 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 11 Jan 2007 07:36:58 -0600 (CST) Subject: CVS problem In-Reply-To: <20070111142737.1e9325d0@ludwig-alpha.unil.ch> References: <5499.65.192.24.190.1168518039.squirrel@mail.jcomserv.net> <20070111142737.1e9325d0@ludwig-alpha.unil.ch> Message-ID: <10072.65.192.24.190.1168522618.squirrel@mail.jcomserv.net> [limb at zanoni cvs]$ env | grep CVS CVSROOT=:ext:limb at cvs.fedora.redhat.com:/cvs/extras CVS_RSH=/usr/bin/ssh I also tried CVS_RSH=ssh, per the wiki, but that failed as well. > On Thu, 11 Jan 2007 06:20:39 -0600 (CST), Jon Ciesla wrote: >> [limb at zanoni cvs]$ cvs co common >> Permission denied (publickey,keyboard-interactive). >> cvs [checkout aborted]: end of file from server (consult above messages >> if >> any) > > Can you show the output of: > $ env|grep CVS > > C > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From Christian.Iseli at licr.org Thu Jan 11 14:58:38 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 11 Jan 2007 15:58:38 +0100 Subject: CVS problem In-Reply-To: <10072.65.192.24.190.1168522618.squirrel@mail.jcomserv.net> References: <5499.65.192.24.190.1168518039.squirrel@mail.jcomserv.net> <20070111142737.1e9325d0@ludwig-alpha.unil.ch> <10072.65.192.24.190.1168522618.squirrel@mail.jcomserv.net> Message-ID: <20070111155838.10ba7064@ludwig-alpha.unil.ch> On Thu, 11 Jan 2007 07:36:58 -0600 (CST), Jon Ciesla wrote: > CVSROOT=:ext:limb at cvs.fedora.redhat.com:/cvs/extras Can you try with: CVSROOT = :ext:limb at cvs.fedoraproject.org:/cvs/extras Do you have the proper private key in $HOME/.ssh ? C From limb at jcomserv.net Thu Jan 11 15:34:58 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 11 Jan 2007 09:34:58 -0600 (CST) Subject: CVS problem In-Reply-To: <20070111155838.10ba7064@ludwig-alpha.unil.ch> References: <5499.65.192.24.190.1168518039.squirrel@mail.jcomserv.net> <20070111142737.1e9325d0@ludwig-alpha.unil.ch> <10072.65.192.24.190.1168522618.squirrel@mail.jcomserv.net> <20070111155838.10ba7064@ludwig-alpha.unil.ch> Message-ID: <21786.65.192.24.190.1168529698.squirrel@mail.jcomserv.net> That didn't work. I have the ssh-generated entries in ~/.ssh/known_hosts for both cvs.fedora.redhat.org and cvs.fedoraproject.org, which are identical, as well as id_dsa.pub, which contains my public key. What should ideally be in ~.ssh/? > On Thu, 11 Jan 2007 07:36:58 -0600 (CST), Jon Ciesla wrote: >> CVSROOT=:ext:limb at cvs.fedora.redhat.com:/cvs/extras > > Can you try with: > CVSROOT = :ext:limb at cvs.fedoraproject.org:/cvs/extras > > Do you have the proper private key in $HOME/.ssh ? > > C > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From rmeggins at redhat.com Thu Jan 11 15:45:24 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 11 Jan 2007 08:45:24 -0700 Subject: CVS problem In-Reply-To: <21786.65.192.24.190.1168529698.squirrel@mail.jcomserv.net> References: <5499.65.192.24.190.1168518039.squirrel@mail.jcomserv.net> <20070111142737.1e9325d0@ludwig-alpha.unil.ch> <10072.65.192.24.190.1168522618.squirrel@mail.jcomserv.net> <20070111155838.10ba7064@ludwig-alpha.unil.ch> <21786.65.192.24.190.1168529698.squirrel@mail.jcomserv.net> Message-ID: <45A65B94.4060007@redhat.com> Jon Ciesla wrote: > That didn't work. > > I have the ssh-generated entries in ~/.ssh/known_hosts for both > cvs.fedora.redhat.org and cvs.fedoraproject.org, which are identical, as > well as id_dsa.pub, which contains my public key. What should ideally be > in ~.ssh/? > You also need id_dsa - your private key - make sure the mode on this is set to 0400. > > > >> On Thu, 11 Jan 2007 07:36:58 -0600 (CST), Jon Ciesla wrote: >> >>> CVSROOT=:ext:limb at cvs.fedora.redhat.com:/cvs/extras >>> >> Can you try with: >> CVSROOT = :ext:limb at cvs.fedoraproject.org:/cvs/extras >> >> Do you have the proper private key in $HOME/.ssh ? >> >> C >> >> -- >> Fedora-maintainers mailing list >> Fedora-maintainers at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-maintainers >> >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From limb at jcomserv.net Thu Jan 11 16:25:48 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 11 Jan 2007 10:25:48 -0600 (CST) Subject: CVS problem Message-ID: <26803.65.192.24.190.1168532748.squirrel@mail.jcomserv.net> Ah-HA! That worked. Thanks Richard and Christian! > Jon Ciesla wrote: >> That didn't work. >> >> I have the ssh-generated entries in ~/.ssh/known_hosts for both cvs.fedora.redhat.org and cvs.fedoraproject.org, which are identical, as well as id_dsa.pub, which contains my public key. What should ideally be >> in ~.ssh/? >> > You also need id_dsa - your private key - make sure the mode on this is set to 0400. >> >> >> >>> On Thu, 11 Jan 2007 07:36:58 -0600 (CST), Jon Ciesla wrote: >>> >>>> CVSROOT=:ext:limb at cvs.fedora.redhat.com:/cvs/extras >>>> >>> Can you try with: >>> CVSROOT = :ext:limb at cvs.fedoraproject.org:/cvs/extras >>> >>> Do you have the proper private key in $HOME/.ssh ? >>> >>> C >>> >>> -- >>> Fedora-maintainers mailing list >>> Fedora-maintainers at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-maintainers >>> >>> >> >> >> > -- novus ordo absurdum -- novus ordo absurdum From Christian.Iseli at licr.org Thu Jan 11 16:47:04 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 11 Jan 2007 17:47:04 +0100 Subject: CVS problem In-Reply-To: <26803.65.192.24.190.1168532748.squirrel@mail.jcomserv.net> References: <26803.65.192.24.190.1168532748.squirrel@mail.jcomserv.net> Message-ID: <20070111174704.723c575f@ludwig-alpha.unil.ch> On Thu, 11 Jan 2007 10:25:48 -0600 (CST), Jon Ciesla wrote: > Ah-HA! That worked. Cool :-) Happy hacking, C From dennis at ausil.us Thu Jan 11 17:04:59 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 11 Jan 2007 11:04:59 -0600 Subject: Plan for tomorrows (20070110) FESCO meeting In-Reply-To: <45A53201.3060208@leemhuis.info> References: <45A53201.3060208@leemhuis.info> Message-ID: <200701111105.00296.dennis@ausil.us> Once upon a time Wednesday 10 January 2007 12:35 pm, Thorsten Leemhuis wrote: Sorry guys im going to miss the meeting > > /topic FESCO-Meeting -- FESCo changes > > FYI: Part of this topic: Elect a new chair. I'm doing the job for one > year and it's IMHO time for me to leave and let one of the others handle > it to get some new ideas into the game. I'll remain in FESCo for now. > > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update Right now im trying to get everything setup for the public repository. Red Hat IS is being very very slow on this. EPEL mock configs have made it into mock upstream. I need to spend time on the update system with lmacken . > > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- EPEL doesn't really > > lift of -- what do? Im trying to think of the best way to get buy in for EPEL from the community. It is a big commitment to undertake. Who in the community wants EPEL? > > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- > > open elep to sponsors and people with 5 packages or more -- why wasn't > > that announced properly? that was my fault. From dennis at ausil.us Thu Jan 11 17:13:43 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 11 Jan 2007 11:13:43 -0600 Subject: EPEL Branches Message-ID: <200701111113.43843.dennis@ausil.us> Hey All, As most of you are aware we are working on setting up EPEL, What is EPEL? It is a port of Fedora to RHEL (and clones) how is it working? right now slowly :( What we are doing is creating branches for EL as requested EL-4 branches are created off of FC-3 if it exists and devel otherwise. EL-5 branches from devel Who can request branches? Sponsors, people who maintain 5 or more packages. ( We will open up to everyone once we have all the pieces in place) Some other notes RHEL is supported for 7 years. and has strict binary compatability for that time period. This will not be a matter of bumping to the latest release all the time. dependencies may not be met. So please request branches in the usual place if you want to participate. Please ask questions and provide feedback. We want this to be a big bonus for the community. Dennis From jdennis at redhat.com Thu Jan 11 17:20:29 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 11 Jan 2007 12:20:29 -0500 Subject: EPEL Branches In-Reply-To: <200701111113.43843.dennis@ausil.us> References: <200701111113.43843.dennis@ausil.us> Message-ID: <1168536029.21316.48.camel@finch.boston.redhat.com> On Thu, 2007-01-11 at 11:13 -0600, Dennis Gilmore wrote: > What is EPEL? > > It is a port of Fedora to RHEL (and clones) O.K. you lost me, what does it mean to port Fedora to RHEL? -- John Dennis Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 From pix at crazyfrogs.org Thu Jan 11 17:23:14 2007 From: pix at crazyfrogs.org (Pix) Date: Thu, 11 Jan 2007 18:23:14 +0100 Subject: EPEL Branches In-Reply-To: <1168536029.21316.48.camel@finch.boston.redhat.com> References: <200701111113.43843.dennis@ausil.us> <1168536029.21316.48.camel@finch.boston.redhat.com> Message-ID: <1168536194.4192.0.camel@ruatha> He means Fedora Extras i guess Le jeudi 11 janvier 2007 ? 12:20 -0500, John Dennis a ?crit : > On Thu, 2007-01-11 at 11:13 -0600, Dennis Gilmore wrote: > > What is EPEL? > > > > It is a port of Fedora to RHEL (and clones) > > O.K. you lost me, what does it mean to port Fedora to RHEL? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.stone at gmail.com Thu Jan 11 17:26:27 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 11 Jan 2007 09:26:27 -0800 Subject: EPEL Branches In-Reply-To: <1168536194.4192.0.camel@ruatha> References: <200701111113.43843.dennis@ausil.us> <1168536029.21316.48.camel@finch.boston.redhat.com> <1168536194.4192.0.camel@ruatha> Message-ID: On 1/11/07, Pix wrote: > > He means Fedora Extras i guess What is Fedora Extras? ;-) From dennis at ausil.us Thu Jan 11 17:29:43 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 11 Jan 2007 11:29:43 -0600 Subject: EPEL Branches In-Reply-To: <1168536029.21316.48.camel@finch.boston.redhat.com> References: <200701111113.43843.dennis@ausil.us> <1168536029.21316.48.camel@finch.boston.redhat.com> Message-ID: <200701111129.44735.dennis@ausil.us> On Thursday 11 January 2007 11:20 am, John Dennis wrote: > On Thu, 2007-01-11 at 11:13 -0600, Dennis Gilmore wrote: > > What is EPEL? > > > > It is a port of Fedora to RHEL (and clones) > > O.K. you lost me, what does it mean to port Fedora to RHEL? Well it was Extras but as that doesn't exist anymore it is packages in Fedora not available in EL -- Dennis Gilmore, RHCE Proud Australian From giallu at gmail.com Thu Jan 11 17:25:16 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 11 Jan 2007 18:25:16 +0100 Subject: CVS problem In-Reply-To: <20070111174704.723c575f@ludwig-alpha.unil.ch> References: <26803.65.192.24.190.1168532748.squirrel@mail.jcomserv.net> <20070111174704.723c575f@ludwig-alpha.unil.ch> Message-ID: On 1/11/07, Christian Iseli wrote: > On Thu, 11 Jan 2007 10:25:48 -0600 (CST), Jon Ciesla wrote: > > Ah-HA! That worked. > > Cool :-) > > Happy hacking, I've just added a brief note on: http://fedoraproject.org/wiki/Extras/Contributors to highlight this Q/A, just in case... From rdieter at math.unl.edu Thu Jan 11 17:34:07 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 11 Jan 2007 11:34:07 -0600 Subject: EPEL Branches In-Reply-To: <1168536029.21316.48.camel@finch.boston.redhat.com> References: <200701111113.43843.dennis@ausil.us> <1168536029.21316.48.camel@finch.boston.redhat.com> Message-ID: <45A6750F.3080807@math.unl.edu> John Dennis wrote: > On Thu, 2007-01-11 at 11:13 -0600, Dennis Gilmore wrote: >> What is EPEL? >> It is a port of Fedora to RHEL (and clones) > O.K. you lost me, what does it mean to port Fedora to RHEL? Analogous to Extras for Fedora, EPEL is Extras for Red Hat Enterprise Linux, see also: http://www.redhat.com/archives/fedora-extras-list/2006-September/msg00232.html http://fedoraproject.org/wiki/EnterpriseExtras -- Rex From limb at jcomserv.net Thu Jan 11 17:37:05 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 11 Jan 2007 11:37:05 -0600 (CST) Subject: CVS problem In-Reply-To: References: <26803.65.192.24.190.1168532748.squirrel@mail.jcomserv.net> <20070111174704.723c575f@ludwig-alpha.unil.ch> Message-ID: <34213.65.192.24.190.1168537025.squirrel@mail.jcomserv.net> Excellent. :) Iterative wikified documentation is a beautiful thing. > On 1/11/07, Christian Iseli wrote: >> On Thu, 11 Jan 2007 10:25:48 -0600 (CST), Jon Ciesla wrote: >> > Ah-HA! That worked. >> >> Cool :-) >> >> Happy hacking, > > I've just added a brief note on: > > http://fedoraproject.org/wiki/Extras/Contributors > > to highlight this Q/A, just in case... > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From wolfy at nobugconsulting.ro Thu Jan 11 17:49:49 2007 From: wolfy at nobugconsulting.ro (lonely wolf) Date: Thu, 11 Jan 2007 19:49:49 +0200 Subject: Plan for tomorrows (20070110) FESCO meeting In-Reply-To: <200701111105.00296.dennis@ausil.us> References: <45A53201.3060208@leemhuis.info> <200701111105.00296.dennis@ausil.us> Message-ID: <45A678BD.1050203@nobugconsulting.ro> On 01/11/2007 07:04 PM, Dennis Gilmore wrote: > > Im trying to think of the best way to get buy in for EPEL from the community. > It is a big commitment to undertake. Who in the community wants EPEL? I do. In this very moment I am trying to build nedit from FE6 in RHEL3 From kaboom at oobleck.net Thu Jan 11 17:24:23 2007 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 11 Jan 2007 12:24:23 -0500 (EST) Subject: EPEL Branches In-Reply-To: <200701111113.43843.dennis@ausil.us> References: <200701111113.43843.dennis@ausil.us> Message-ID: On Thu, 11 Jan 2007, Dennis Gilmore wrote: > Some other notes > > RHEL is supported for 7 years. and has strict binary compatability for that > time period. This will not be a matter of bumping to the latest release all > the time. dependencies may not be met. So does EPEL also have those same stability requirements? Also, with the brave new world of Core and Extras merged, is it just "anything in Fedora that's not in RHEL is fine for EPEL", or what? later, chris From giallu at gmail.com Thu Jan 11 18:53:14 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 11 Jan 2007 19:53:14 +0100 Subject: EPEL Branches In-Reply-To: References: <200701111113.43843.dennis@ausil.us> Message-ID: On 1/11/07, Chris Ricker wrote: > On Thu, 11 Jan 2007, Dennis Gilmore wrote: > > > Some other notes > > > > RHEL is supported for 7 years. and has strict binary compatability for that > > time period. This will not be a matter of bumping to the latest release all > > the time. dependencies may not be met. > > So does EPEL also have those same stability requirements? I guess this is the trickiest stuff to define > > Also, with the brave new world of Core and Extras merged, is it just > "anything in Fedora that's not in RHEL is fine for EPEL", or what? > I guess so, but what about stuff in RHEL which is now in Extras, possibly with a community maintaner? From tburke at redhat.com Thu Jan 11 19:04:39 2007 From: tburke at redhat.com (Tim Burke) Date: Thu, 11 Jan 2007 14:04:39 -0500 Subject: EPEL Branches In-Reply-To: References: <200701111113.43843.dennis@ausil.us> Message-ID: <45A68A47.8010801@redhat.com> Chris Ricker wrote: > > > Also, with the brave new world of Core and Extras merged, is it just > "anything in Fedora that's not in RHEL is fine for EPEL", or what? > > Perhaps a small distinction, but I think the definition is a little broader.. ie a little more than RHEL... extending to the layered products. Specifically, I propose that EPEL is "FE stuff that RH doesn't otherwise ship that someone volunteers to do the work in EPEL". That would preclude things like our cluster and directory server packages from simply being rebuilt and pushed in EPEL. From kaboom at oobleck.net Thu Jan 11 19:58:28 2007 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 11 Jan 2007 14:58:28 -0500 (EST) Subject: EPEL Branches In-Reply-To: <45A68A47.8010801@redhat.com> References: <200701111113.43843.dennis@ausil.us> <45A68A47.8010801@redhat.com> Message-ID: On Thu, 11 Jan 2007, Tim Burke wrote: > > Also, with the brave new world of Core and Extras merged, is it just > > "anything in Fedora that's not in RHEL is fine for EPEL", or what? > > > > > Perhaps a small distinction, but I think the definition is a little broader.. > ie a little more than RHEL... extending to the layered products. > Specifically, I propose that EPEL is "FE stuff that RH doesn't otherwise ship > that someone volunteers to do the work in EPEL". That would preclude things > like our cluster and directory server packages from simply being rebuilt and > pushed in EPEL. But how would that work? There's soon no FE, just F. And, for example, directory server will likely be in F at some point.... later, chris From jkeating at redhat.com Thu Jan 11 20:05:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 11 Jan 2007 15:05:30 -0500 Subject: EPEL Branches In-Reply-To: References: <200701111113.43843.dennis@ausil.us> <45A68A47.8010801@redhat.com> Message-ID: <200701111505.33651.jkeating@redhat.com> On Thursday 11 January 2007 14:58, Chris Ricker wrote: > But how would that work? There's soon no FE, just F. And, for example, > directory server will likely be in F at some point.... So expand it slightly. EPEL can take anything from the Fedora Collection that isn't shipped by any other RHEL like product, such as RHEL or the layered products on top of RHEL. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Thu Jan 11 20:44:18 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 11 Jan 2007 21:44:18 +0100 Subject: imlib is orphaned Message-ID: <20070111214418.e9e6511f.bugs.michael@gmx.net> The right way to interpret the most recent broken deps report is to notice that imlib (not imlib2) has been orphaned silently several months ago and has not been picked up since then. It is needed by: qiv gnome-libs libglade kdegraphics-extras From grenier at cgsecurity.org Thu Jan 11 20:46:38 2007 From: grenier at cgsecurity.org (Christophe GRENIER) Date: Thu, 11 Jan 2007 21:46:38 +0100 (CET) Subject: CVS problem In-Reply-To: References: <26803.65.192.24.190.1168532748.squirrel@mail.jcomserv.net> <20070111174704.723c575f@ludwig-alpha.unil.ch> Message-ID: On Thu, 11 Jan 2007, Gianluca Sforna wrote: > On 1/11/07, Christian Iseli wrote: >> On Thu, 11 Jan 2007 10:25:48 -0600 (CST), Jon Ciesla wrote: >> > Ah-HA! That worked. >> >> Cool :-) >> >> Happy hacking, > > I've just added a brief note on: > > http://fedoraproject.org/wiki/Extras/Contributors > > to highlight this Q/A, just in case... It may be a good idea to add some documentation on how to submit a new package once the user is already a contributor. Christophe ----------------------------------------------------------------- ,-~~-.___. ._. / | ' \ | |"""""""""| -= GRENIER Christophe =- ( ) 0 | | | \_/-, ,----' | | | ==== !_!--v---v--" http://www.cgsecurity.org / \-'~; |""""""""| / __/~| ._-""|| | Email: grenier at cgsecurity.org =( _____|_|____||________| ----------------------------------------------------------------- From limb at jcomserv.net Thu Jan 11 20:50:16 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 11 Jan 2007 14:50:16 -0600 (CST) Subject: CVS problem In-Reply-To: References: <26803.65.192.24.190.1168532748.squirrel@mail.jcomserv.net> <20070111174704.723c575f@ludwig-alpha.unil.ch> Message-ID: <54957.65.192.24.190.1168548616.squirrel@mail.jcomserv.net> On that note, is the documentation on submitting udated to existing packages up to date? http://fedoraproject.org/wiki/Extras/UsingCvsFaq#head-192dbe7a1e9b114afc81d0a3753a00f9cfa70bbe Is the complete SRPM import method workable? > On Thu, 11 Jan 2007, Gianluca Sforna wrote: > >> On 1/11/07, Christian Iseli wrote: >>> On Thu, 11 Jan 2007 10:25:48 -0600 (CST), Jon Ciesla wrote: >>> > Ah-HA! That worked. >>> >>> Cool :-) >>> >>> Happy hacking, >> >> I've just added a brief note on: >> >> http://fedoraproject.org/wiki/Extras/Contributors >> >> to highlight this Q/A, just in case... > > It may be a good idea to add some documentation on how to submit > a new package once the user is already a contributor. > > Christophe > > ----------------------------------------------------------------- > ,-~~-.___. ._. > / | ' \ | |"""""""""| -= GRENIER Christophe =- > ( ) 0 | | | > \_/-, ,----' | | | > ==== !_!--v---v--" http://www.cgsecurity.org > / \-'~; |""""""""| > / __/~| ._-""|| | Email: grenier at cgsecurity.org > =( _____|_|____||________| > ----------------------------------------------------------------- > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From dlutter at redhat.com Thu Jan 11 23:17:56 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 11 Jan 2007 15:17:56 -0800 Subject: EPEL Branches In-Reply-To: <200701111113.43843.dennis@ausil.us> References: <200701111113.43843.dennis@ausil.us> Message-ID: <1168557476.21083.31.camel@localhost.localdomain> On Thu, 2007-01-11 at 11:13 -0600, Dennis Gilmore wrote: > As most of you are aware we are working on setting up EPEL, What is the relation between the buildsys definitions for epelN and rhelN [1] ? Which one is the build system using ? Also, could you add rpmdevtools to the rhel5 buildsys repo ? It's not available in rhel5, and without it, you can't setup a proper rhel5 buildroot. I haven't tried the epel buildsys definitions, but I'd imagine that they need rpmdevtools, too. > Who can request branches? > > Sponsors, people who maintain 5 or more packages. ( We will open up to > everyone once we have all the pieces in place) Where do you request branches ? Same place as for Extras[2] ? David [1] http://buildsys.fedoraproject.org/buildgroups/ [2] http://fedoraproject.org/wiki/Extras/CVSSyncNeeded From giallu at gmail.com Thu Jan 11 22:24:39 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 11 Jan 2007 23:24:39 +0100 Subject: CVS problem In-Reply-To: <54957.65.192.24.190.1168548616.squirrel@mail.jcomserv.net> References: <26803.65.192.24.190.1168532748.squirrel@mail.jcomserv.net> <20070111174704.723c575f@ludwig-alpha.unil.ch> <54957.65.192.24.190.1168548616.squirrel@mail.jcomserv.net> Message-ID: On 1/11/07, Jon Ciesla wrote: > On that note, is the documentation on submitting udated to existing > packages up to date? AFAICT, it looks fine > > http://fedoraproject.org/wiki/Extras/UsingCvsFaq#head-192dbe7a1e9b114afc81d0a3753a00f9cfa70bbe > > Is the complete SRPM import method workable? It was proposed to disallow the cvs-import.sh method for anything but the first import. Please take your time to learn the basic cvs commands you need to perform your packager work. I can assure you it's not wasted time. From dennis at ausil.us Thu Jan 11 23:39:46 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 11 Jan 2007 17:39:46 -0600 Subject: EPEL Branches In-Reply-To: <1168557476.21083.31.camel@localhost.localdomain> References: <200701111113.43843.dennis@ausil.us> <1168557476.21083.31.camel@localhost.localdomain> Message-ID: <200701111739.47039.dennis@ausil.us> On Thursday 11 January 2007 17:17, David Lutterkort wrote: > On Thu, 2007-01-11 at 11:13 -0600, Dennis Gilmore wrote: > > As most of you are aware we are working on setting up EPEL, > > What is the relation between the buildsys definitions for epelN and > rhelN [1] ? Which one is the build system using ? We are using the rhel one the epel has a different disttag but we are not using it I need to clean it up > Also, could you add rpmdevtools to the rhel5 buildsys repo ? It's not > available in rhel5, and without it, you can't setup a proper rhel5 > buildroot. I haven't tried the epel buildsys definitions, but I'd > imagine that they need rpmdevtools, too. Done > > Who can request branches? > > > > Sponsors, people who maintain 5 or more packages. ( We will open up to > > everyone once we have all the pieces in place) > > Where do you request branches ? Same place as for Extras[2] ? Yes the same place as Extras Request branches for EL-4 and EL-5 -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From Axel.Thimm at ATrpms.net Fri Jan 12 00:23:57 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 12 Jan 2007 01:23:57 +0100 Subject: EPEL Branches In-Reply-To: <200701111113.43843.dennis@ausil.us> References: <200701111113.43843.dennis@ausil.us> Message-ID: <20070112002357.GI16762@neu.nirvana> On Thu, Jan 11, 2007 at 11:13:43AM -0600, Dennis Gilmore wrote: > So please request branches in the usual place if you want to participate. Do we need to dig out the old review bugzilla ids? Or is it enough to * EPEL-4 foo What releases are supported? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jan 12 00:31:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 12 Jan 2007 01:31:28 +0100 Subject: EPEL Branches In-Reply-To: <200701111113.43843.dennis@ausil.us> References: <200701111113.43843.dennis@ausil.us> Message-ID: <20070112003128.GK16762@neu.nirvana> On Thu, Jan 11, 2007 at 11:13:43AM -0600, Dennis Gilmore wrote: > Hey All, > > As most of you are aware we are working on setting up EPEL, > > What is EPEL? > > It is a port of Fedora to RHEL (and clones) > > how is it working? > > right now slowly :( What we are doing is creating branches for EL as requested > EL-4 branches are created off of FC-3 if it exists and devel otherwise. EL-5 > branches from devel > > Who can request branches? > > Sponsors, people who maintain 5 or more packages. ( We will open up to > everyone once we have all the pieces in place) > > Some other notes > > RHEL is supported for 7 years. and has strict binary compatability for that > time period. This will not be a matter of bumping to the latest release all > the time. dependencies may not be met. > > So please request branches in the usual place if you want to participate. > Please ask questions and provide feedback. We want this to be a big bonus > for the community. > > > Dennis > And the most interesting part for users, not packagers: Where do the packages land (URL)? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Fri Jan 12 00:55:50 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 11 Jan 2007 18:55:50 -0600 Subject: EPEL Branches In-Reply-To: <20070112003128.GK16762@neu.nirvana> References: <200701111113.43843.dennis@ausil.us> <20070112003128.GK16762@neu.nirvana> Message-ID: <200701111855.50393.dennis@ausil.us> On Thursday 11 January 2007 18:31, Axel Thimm wrote: > > And the most interesting part for users, not packagers: Where do the > packages land (URL)? That is still being debated. so for now no idea. As for branching EL-4 foo is enough -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From Axel.Thimm at ATrpms.net Fri Jan 12 01:08:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 12 Jan 2007 02:08:38 +0100 Subject: EPEL Branches In-Reply-To: <200701111855.50393.dennis@ausil.us> References: <200701111113.43843.dennis@ausil.us> <20070112003128.GK16762@neu.nirvana> <200701111855.50393.dennis@ausil.us> Message-ID: <20070112010838.GL16762@neu.nirvana> On Thu, Jan 11, 2007 at 06:55:50PM -0600, Dennis Gilmore wrote: > On Thursday 11 January 2007 18:31, Axel Thimm wrote: > > > > > And the most interesting part for users, not packagers: Where do the > > packages land (URL)? > That is still being debated. so for now no idea. As for branching EL-4 foo > is enough Isn't there some hidden URL for packagers at least to test what the buildsystem produced? For now I feel like this is a block box I can feed, but I see no output (other than build logs). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Fri Jan 12 01:18:37 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 11 Jan 2007 19:18:37 -0600 Subject: EPEL Branches In-Reply-To: <20070112010838.GL16762@neu.nirvana> References: <200701111113.43843.dennis@ausil.us> <200701111855.50393.dennis@ausil.us> <20070112010838.GL16762@neu.nirvana> Message-ID: <200701111918.37453.dennis@ausil.us> On Thursday 11 January 2007 19:08, Axel Thimm wrote: > On Thu, Jan 11, 2007 at 06:55:50PM -0600, Dennis Gilmore wrote: > > On Thursday 11 January 2007 18:31, Axel Thimm wrote: > > > And the most interesting part for users, not packagers: Where do the > > > packages land (URL)? > > > > That is still being debated. so for now no idea. As for branching EL-4 > > foo is enough > > Isn't there some hidden URL for packagers at least to test what the > buildsystem produced? For now I feel like this is a block box I can > feed, but I see no output (other than build logs). sure there is http://buildsys.fedoraproject.org/plague-results/ its also defined as [local] in the mock configs provided with Fedora. Its not a hidden url just not as publicly advertised. -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From jwboyer at jdub.homelinux.org Fri Jan 12 02:12:09 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 11 Jan 2007 20:12:09 -0600 Subject: Plan for tomorrows (20070110) FESCO meeting In-Reply-To: <45A678BD.1050203@nobugconsulting.ro> References: <45A53201.3060208@leemhuis.info> <200701111105.00296.dennis@ausil.us> <45A678BD.1050203@nobugconsulting.ro> Message-ID: <20070112021208.GB30399@yoda.jdub.homelinux.org> On Thu, Jan 11, 2007 at 07:49:49PM +0200, lonely wolf wrote: > On 01/11/2007 07:04 PM, Dennis Gilmore wrote: > > > >Im trying to think of the best way to get buy in for EPEL from the > >community. It is a big commitment to undertake. Who in the community > >wants EPEL? > I do. In this very moment I am trying to build nedit from FE6 in RHEL3 That seems like a very painful thing to do. And EPEL wouldn't help at any rate. EPEL starts at RHEL 4 (which is closer to FC-3). josh From paul at city-fan.org Fri Jan 12 08:47:45 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 12 Jan 2007 08:47:45 +0000 Subject: imlib is orphaned In-Reply-To: <20070111214418.e9e6511f.bugs.michael@gmx.net> References: <20070111214418.e9e6511f.bugs.michael@gmx.net> Message-ID: <45A74B31.7080907@city-fan.org> Michael Schwendt wrote: > The right way to interpret the most recent broken deps report is to notice > that > > imlib > > (not imlib2) has been orphaned silently several months ago and has not > been picked up since then. > > It is needed by: > > qiv > gnome-libs > libglade > kdegraphics-extras Since two of those are mine, I volunteer to pick it up. Paul. From wolfy at nobugconsulting.ro Fri Jan 12 10:43:49 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 12 Jan 2007 12:43:49 +0200 Subject: Plan for tomorrows (20070110) FESCO meeting In-Reply-To: <20070112021208.GB30399@yoda.jdub.homelinux.org> References: <45A53201.3060208@leemhuis.info> <200701111105.00296.dennis@ausil.us> <45A678BD.1050203@nobugconsulting.ro> <20070112021208.GB30399@yoda.jdub.homelinux.org> Message-ID: <45A76665.1020006@nobugconsulting.ro> Josh Boyer wrote: > On Thu, Jan 11, 2007 at 07:49:49PM +0200, lonely wolf wrote: > >> On 01/11/2007 07:04 PM, Dennis Gilmore wrote: >> >>> Im trying to think of the best way to get buy in for EPEL from the >>> community. It is a big commitment to undertake. Who in the community >>> wants EPEL? >>> >> I do. In this very moment I am trying to build nedit from FE6 in RHEL3 >> > > That seems like a very painful thing to do. And EPEL wouldn't help at > any rate. EPEL starts at RHEL 4 (which is closer to FC-3). > I know the differences too well... I use RH since v4.2. As of this particular case a) I am stuck with RHEL3 b) it is painful because of new xorg vs old XFree plus lestiff vs openmotif, but not as painful as it sounds. But let's stick to the original question ('who wants...'). From bpepple at fedoraproject.org Fri Jan 12 18:56:06 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 12 Jan 2007 13:56:06 -0500 Subject: FESCo Meeting Summary for 2007-01-11 Message-ID: <1168628166.12544.9.camel@Chuck> Members Present * Thorsten Leemhuis (thl) * Brian Pepple (bpepple) * Rex Dieter (rdieter) * Jason Tibbitts (tibbs) * Toshio Kuratomi (abadger1999) * Christian Iseli (ch4chris) * Warren Togami (warren) * Jeremy Katz (jeremy) * Josh Boyer (jwb) Absent * Dennis Gilmore (dgilmore) * Ville Skytt? (scop) * Tom Callaway (spot) * Andreas Bierfert (awjb) FAB Members Present * Max Spevack (mspevack) * Rahul Sundaram (mether) * Bill Nottingham (notting) * Seth Vidal (skvidal) === Summary === FESCo/Core cabal merge * Long discussion about the FESCo/Core cabal merge. The initial thought is to merge the members from the Core Cabal and FESCo into FTC (Fedora Technical Committee). * The exact number of members in the FTC, and other issues will be discussed on the FAB-mailing list this week. * FESCo members are also encouraged to be present for the IRC FAB meeting on Tuesday (2007-1-16). FESCo changes * thl has decided to step down as chair of FESCo, and bpepple has been chosen as the interim chair until FTC is up and running. Everyone thanked thl for all the hard work he has put into running FESCo. * Kevin Fenzi (nirik) has joined FESCo, to fill the vacated seat of scop. FESCo would like to thank Ville for his hard work during his tenure there. Welcome aboard, Kevin! Opening Core * Some reviews of Core packages should hopefully start being done in a trickle fashion. At FUDCon, there will be a hack-fest to review Core packages.http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest Kernel-Naming * The kernel doesn't currently follow the Naming Guidelines, and Jeremy is going to investigate if we need to make an exception for this in the Guidelines. For full IRC log of meeting: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070111 Next FESCo Meeting: 2007-01-15 18:00 UTC Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Fri Jan 12 23:01:00 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 13 Jan 2007 00:01:00 +0100 Subject: imlib is orphaned In-Reply-To: <45A74B31.7080907@city-fan.org> References: <20070111214418.e9e6511f.bugs.michael@gmx.net> <45A74B31.7080907@city-fan.org> Message-ID: <20070113000100.2bf0ee7d.bugs.michael@gmx.net> On Fri, 12 Jan 2007 08:47:45 +0000, Paul Howarth wrote: > Michael Schwendt wrote: > > The right way to interpret the most recent broken deps report is to notice > > that > > > > imlib > > > > (not imlib2) has been orphaned silently several months ago and has not > > been picked up since then. > > > > It is needed by: > > > > qiv > > gnome-libs > > libglade > > kdegraphics-extras > > Since two of those are mine, I volunteer to pick it up. Please update owners.list and query bugzilla for any open tickets. There is an imlib 1.9.15 release which seems to contain at least one patch (against misc.c) that is not included in the Fedora rpm (1.9.13 plus some patches). The big chunk of the diffs against 1.9.13 is automake updates. From paul at city-fan.org Sun Jan 14 12:12:08 2007 From: paul at city-fan.org (Paul Howarth) Date: Sun, 14 Jan 2007 12:12:08 +0000 Subject: imlib is orphaned In-Reply-To: <20070113000100.2bf0ee7d.bugs.michael@gmx.net> References: <20070111214418.e9e6511f.bugs.michael@gmx.net> <45A74B31.7080907@city-fan.org> <20070113000100.2bf0ee7d.bugs.michael@gmx.net> Message-ID: <1168776728.10623.21.camel@metropolis.intra.city-fan.org> On Sat, 2007-01-13 at 00:01 +0100, Michael Schwendt wrote: > On Fri, 12 Jan 2007 08:47:45 +0000, Paul Howarth wrote: > > > Michael Schwendt wrote: > > > The right way to interpret the most recent broken deps report is to notice > > > that > > > > > > imlib > > > > > > (not imlib2) has been orphaned silently several months ago and has not > > > been picked up since then. > > > > > > It is needed by: > > > > > > qiv > > > gnome-libs > > > libglade > > > kdegraphics-extras > > > > Since two of those are mine, I volunteer to pick it up. > > Please update owners.list and query bugzilla for any open tickets. As imlib on recently appeared on the OrphanedPackages page on the wiki, I'm planning on waiting the 10 days to see if anyone else wants to maintain or co-maintain it. When that time's up, I'll go through the full change of ownership process. > There is an imlib 1.9.15 release which seems to contain at least one patch > (against misc.c) that is not included in the Fedora rpm (1.9.13 plus some > patches). The big chunk of the diffs against 1.9.13 is automake updates. Yes, my plan is to bring it up to date with the most recent release, as I did with gnome-libs when I took that over. Paul. From bpepple at fedoraproject.org Sun Jan 14 15:45:16 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 14 Jan 2007 10:45:16 -0500 Subject: Plan for tomorrows (20070115) FESCO meeting Message-ID: <1168789516.4710.7.camel@Chuck> Hi all, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Monday at 18:00 UTC in #fedora-extras on irc.freenode.org: /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- EPEL doesn't really lift of -- what do? /topic FESCO-Meeting -- Opening Core -- rdieter, jeremy, warren -- FESCo future? Deadlock? https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00003.html) /topic FESCO-Meeting -- Opening Core -- jeremy -- how to actually do the merge (sponsership and review issues) /topic FESCO-Meeting -- Encourage co-maintainership -- c4chris /topic FESCO-Meeting -- MISC -- firefox updates in stable often breaks quite some packages (galeon, liferia, ...); do we need some kind of task force that steps up to rebuild the stuff? /topic FESCO-Meeting -- MISC -- disallow cvs-import for everything but the initial import? /topic FESCO-Meeting -- MISC -- "what do we want like to see in the approved-message in a review bug" -- https://www.redhat.com/archives/fedora-maintainers/2006-December/msg00214.html /topic FESCo-Meeting -- MISC -- the "syslog-ng patent problems" https://www.redhat.com/archives/fedora-maintainers/2007-January/msg00015.html /topic FESCo-Meeting -- MISC -- kernel-naming https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00581.html /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCo meeting -- Maintainer Responsibility Policy -- bpepple /topic FESCo meeting -- Free discussion around Fedora Extras The meeting rules can be found at: http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... The schedule page in the wiki has more details on the individual topics; see http://www.fedoraproject.org/wiki/Extras/Schedule The individual pages specific to the topics are linked from there. The same as above holds true: if you name is somewhere on the schedule page in the wiki please update the status in the wiki ahead of the meeting. Ohh, and please update it also directly after the meeting so it's update and prepared for next weeks meeting :-) Hint: If you want to know what FESCo is doing simply subscribe in the wiki to "Extras/Schedul.*" and you'll get mails if something changes in that areas of the wiki. That should give you a good idea of FESCo's work. Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From laroche at redhat.com Tue Jan 16 08:49:37 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 16 Jan 2007 09:49:37 +0100 Subject: obsoleted rpm packages we can remove from the FE6 repo Message-ID: <20070116084937.GA3646@dudweiler.stuttgart.redhat.com> The following rpms could be removed from the FE6 repos to clean things up: l2tpd-0.69-0.6.20051030.fc6.i386.rpm is obsoleted by xl2tpd-1.1.06-5.fc6.i386.rpm lincvs-1.4.4-2.fc6.i386.rpm is obsoleted by crossvc-1.5.0-4.fc6.i386.rpm pdftohtml-0.36-9.fc6.i386.rpm is obsoleted by poppler-utils-0.5.4-5.fc6.i386.rpm swh-plugins-0.4.15-4.fc6.i386.rpm is obsoleted by ladspa-swh-plugins-0.4.15-6.fc6.i386.rpm regards, Florian La Roche From bugs.michael at gmx.net Tue Jan 16 12:07:38 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 16 Jan 2007 13:07:38 +0100 Subject: obsoleted rpm packages we can remove from the FE6 repo In-Reply-To: <20070116084937.GA3646@dudweiler.stuttgart.redhat.com> References: <20070116084937.GA3646@dudweiler.stuttgart.redhat.com> Message-ID: <20070116130738.07059623.bugs.michael@gmx.net> On Tue, 16 Jan 2007 09:49:37 +0100, Florian La Roche wrote: > The following rpms could be removed from the FE6 repos to clean > things up: > > l2tpd-0.69-0.6.20051030.fc6.i386.rpm is obsoleted by xl2tpd-1.1.06-5.fc6.i386.rpm > lincvs-1.4.4-2.fc6.i386.rpm is obsoleted by crossvc-1.5.0-4.fc6.i386.rpm > pdftohtml-0.36-9.fc6.i386.rpm is obsoleted by poppler-utils-0.5.4-5.fc6.i386.rpm > swh-plugins-0.4.15-4.fc6.i386.rpm is obsoleted by ladspa-swh-plugins-0.4.15-6.fc6.i386.rpm > I've removed the following (the binaries won't survive that during the next push): 6: l2tpd-0.69-0.6.20051030.fc6.src.rpm lincvs-1.4.4-2.fc6.src.rpm pdftohtml-0.36-9.fc6.src.rpm swh-plugins-0.4.15-4.fc6.src.rpm devel: l2tpd-0.69-0.6.20051030.fc6.src.rpm lincvs-1.4.4-2.fc6.src.rpm pdftohtml-0.36-9.fc6.src.rpm swh-plugins-0.4.15-4.fc6.src.rpm python-nltk-1.4.4-3.fc7.src.rpm From buildsys at fedoraproject.org Tue Jan 16 13:33:49 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 16 Jan 2007 08:33:49 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-01-16 Message-ID: <20070116133349.8716615212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): avahi FC6-updates > FC7 (0:0.6.16-1.fc6 > 0:0.6.15-4.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) selinux-policy FC6-updates > FC7 (0:2.4.6-23.fc6 > 0:2.4.6-21.fc7) xen FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) yum FC6-updates > FC7 (0:3.0.3-1.fc6 > 0:3.0.1-6.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) devrim AT commandprompt.com: phpPgAdmin FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-5.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-6.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: listen FE6 > FE7 (0:0.5-11.beta1.fc6 > 0:0.5-9.beta1.fc7.4) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) tcallawa AT redhat.com: ntfs-3g FE5 > FE7 (2:0-0.7.20070920.fc5 > 1:0-0.6.20070102.fc7) FE6 > FE7 (2:0-0.7.20070920.fc6 > 1:0-0.6.20070102.fc7) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) ---------------------------------------------------------------------- avahi: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.6.16-1.fc6 > 0:0.6.15-4.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) listen: karlthered AT gmail.com FE6 > FE7 (0:0.5-11.beta1.fc6 > 0:0.5-9.beta1.fc7.4) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) ntfs-3g: tcallawa AT redhat.com FE5 > FE7 (2:0-0.7.20070920.fc5 > 1:0-0.6.20070102.fc7) FE6 > FE7 (2:0-0.7.20070920.fc6 > 1:0-0.6.20070102.fc7) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) phpPgAdmin: devrim AT commandprompt.com FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-5.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-6.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) selinux-policy: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.4.6-23.fc6 > 0:2.4.6-21.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:3.0.3-2.fc5 > 0:3.0.3-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) yum: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.0.3-1.fc6 > 0:3.0.1-6.fc7) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From fedora at leemhuis.info Tue Jan 16 18:01:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 16 Jan 2007 19:01:29 +0100 Subject: Name for a FESCo Successor? Suggestions anyone? Message-ID: <45AD12F9.3050204@leemhuis.info> Cross-posting to three lists, but follow-up set to fedora-devel, to not have the discussion on 3 lists in parallel. But I'm sure mailman will eat the manual follow up before sending the mail out again :-/ So please adjust it manually and send your replies *only* to fedora-devel ;-) tia! Hi all! FESCo in its yesterday out-of-order meeting agreed to follow the proposal I posted on fedora-advisory-board ( https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00129.html ) to merge the Core Cabal and FESCo into a new committee that handles the day to day work around the stuff that was formally known as Fedora Core and Fedora Extras. In other words: we integrate Jesse (aka f13) and Bill (aka notting) into FESCo (Jeremy is already part of FESCo), merge the responsibilities of both groups (and thus give it lot more to do). The Fedora Board will probably discuss the proposal in todays meeting, too. But one issue is still totally undecided and needs to be solved soon: What do we call that FESCo and Core Cabal successor? The "E" in FESCo until now stood for Extras, but soon Extras will vanish due to the merge. So hat do we want to call it? Suggestions that came up: FTC -- Fedora Technical Committee FTT -- Fedora Technical Team FET -- Fedora Engineering Team FEDCo -- Fedora Distribution Committee FESCo -- Fedora Steering Committee 42 None of the above name suggestions did receive a "yes, that's a really great idea, I like it, all the people I asked love it, thus go for it" from the people involved in the discussions. Thus with this mail we'd like to ask the community for suggestions and its option: "Which of the above names do you like most or do you have something better in mind that sounds good, is not to easily confused with other stuff from this world and roughly describes what the committee does?" CU thl P.S.: For those that missed it, I'm not FESCo's chairmen any more (but still a FESCo member) since last Thursday -- After doing the job for one year I felt that it's time for me to hand it over to someone else with fresh blood and new ideas. Brian Pepple is FESCo's interims chair now and I'm sure he'll do a great job. Please help him as good as you can -- and always keep in mind: You don't have to be in FESCo or any other committee to to help improving Fedora! P.P.S.:Ohh, some backgrounds for the proposed names: * FTC -- name clash with Federal Trade Commission. A bit bad, but seems some people don't care much about that. http://www.acronymfinder.com/af-query.asp?Acronym=FTC&Find=find&string=exact 39 meanings in total on acronym finder * FTT -- "Failure to thrive (FTT) refers to a baby or child that is not developing as well as desired." http://www.acronymfinder.com/af-query.asp?Acronym=FTT&Find=find&string=exact 12 meanings in total on acronym finder * FTT -- Field-Effect Transistor http://www.acronymfinder.com/af-query.asp?Acronym=FET&Find=find&string=exact 24 meanings in total on acronym finder * FEDSCo "Federal Employees Distributing Company (Co-Op)" http://www.acronymfinder.com/af-query.asp?Acronym=FEDCo&Find=find&string=exact 2 meanings on acronym finder * FESCO-- Fedora Steering Committee is to easily confused with the Board, thus probably a no-go * 42 -- Answer to Life, the Universe, and Everything http://en.wikipedia.org/wiki/The_Answer_to_Life%2C_the_Universe%2C_and_Everything From jwboyer at jdub.homelinux.org Wed Jan 17 03:11:36 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 16 Jan 2007 21:11:36 -0600 Subject: Name for a FESCo Successor? Suggestions anyone? In-Reply-To: <45AD12F9.3050204@leemhuis.info> References: <45AD12F9.3050204@leemhuis.info> Message-ID: <1169003496.3159.110.camel@vader.jdub.homelinux.org> > But one issue is still totally undecided and needs to be solved soon: > What do we call that FESCo and Core Cabal successor? The "E" in FESCo > until now stood for Extras, but soon Extras will vanish due to the > merge. So hat do we want to call it? Suggestions that came up: I like "the Cabal". Simple, descriptive, and most importantly not another acronym?. josh ? I have been inundated with TLAs for entirely too long. ? ? Thorsten, look I figured it out! :) From bpepple at fedoraproject.org Wed Jan 17 14:53:12 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 17 Jan 2007 09:53:12 -0500 Subject: FESCo Meeting Summary for 2007-01-15 Message-ID: <1169045592.24884.15.camel@Chuck> Members Present * Thorsten Leemhuis (thl) * Brian Pepple (bpepple) * Rex Dieter (rdieter) * Jason Tibbitts (tibbs) * Toshio Kuratomi (abadger1999) * Christian Iseli (ch4chris) * Warren Togami (warren) * Josh Boyer (jwb) * Tom Callaway (spot) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) Absent * Andreas Bierfert (awjb) * Jeremy Katz (jeremy) FAB Members Present * Bill Nottingham (notting) NOTE: This was a special meeting to discuss the FESCo/Core Cabal merge. === Summary === FESCo/Core Cabal Merge Merge Proposal * FESCo approved thl's proposal to handle the migration to FESCo's successor. This proposal will be sent now to FAB to get an ACK. Some of the items in the proposal: 1. FESCo adds notting & Jesse Keating (f13) to the current FESCo group to comprise the successor committee to FESCo. 2. Tentatively the plans are to have elections for this new committee six weeks after the release of Fedora 7. 3. Link to thl's full proposal: https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00129.html Misc Merge Items * thl is going to send an e-mail to the fedora-extras-list and fedora-devel-list to find a good name for the successor to FESCo. The goal here is to have a name picked out by next weeks FESCo meeting. * notting brought up the idea of importing revision-control-with-history instead of srpms when the Core packages are merged with the Extras packages. * It was brought up that the Conflicts use in spec files issue should be resolved before the Core packages are mass-reviewed. Spot stated that they are working to complete that soon in the Packaging Commitee. Misc * With the merger of Core and Extras happening soon, it makes sense to have the FESCo meeting in a different IRC channel, since eventually the #fedora-extras channel will be fazed out. The plan is beginning with the 2007-01-25 meeting, to have meeting in the #fedora-devel channel. For full IRC log of meeting: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070115 Next FESCo Meeting: 2007-01-18 18:00 UTC Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Thu Jan 18 02:38:32 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 17 Jan 2007 21:38:32 -0500 Subject: Plan for tomorrows (20070118) FESCO meeting Message-ID: <1169087912.24436.7.camel@Chuck> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-extras on irc.freenode.org: /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- EPEL doesn't really lift of -- what do? /topic FESCO-Meeting -- Opening Core -- rdieter, jeremy, warren -- FESCo future? Deadlock? https://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00003.html) /topic FESCO-Meeting -- Opening Core -- jeremy -- how to actually do the merge (sponsership and review issues) /topic FESCO-Meeting -- Encourage co-maintainership -- c4chris, thl /topic FESCO-Meeting -- MISC -- firefox updates in stable often breaks quite some packages (galeon, liferia, ...); do we need some kind of task force that steps up to rebuild the stuff? /topic FESCO-Meeting -- MISC -- disallow cvs-import for everything but the initial import? /topic FESCO-Meeting -- MISC -- "what do we want like to see in the approved-message in a review bug" -- https://www.redhat.com/archives/fedora-maintainers/2006-December/msg00214.html /topic FESCo-Meeting -- MISC -- the "syslog-ng patent problems" https://www.redhat.com/archives/fedora-maintainers/2007-January/msg00015.html /topic FESCo-Meeting -- MISC -- kernel-naming https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00581.html /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCo meeting -- Maintainer Responsibility Policy -- bpepple /topic FESCo meeting -- Free discussion around Fedora Extras The meeting rules can be found at: http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines The schedule page in the wiki has more details on the individual topics; see http://www.fedoraproject.org/wiki/Extras/Schedule You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Thu Jan 18 18:39:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 18 Jan 2007 19:39:23 +0100 Subject: Name for a FESCo Successor? Suggestions anyone? In-Reply-To: <45AD12F9.3050204@leemhuis.info> References: <45AD12F9.3050204@leemhuis.info> Message-ID: <45AFBEDB.60107@leemhuis.info> Hi! /me again! Thorsten Leemhuis schrieb: > [...] > But one issue is still totally undecided and needs to be solved soon: > What do we call that FESCo and Core Cabal successor? The "E" in FESCo > until now stood for Extras, but soon Extras will vanish due to the > merge. So hat do we want to call it? [...] FESCo discussed this in todays meeting. We agreed to just continue with the old name :) It just means "Fedora Steering Committee" or "Fedora Engineering Steering Committee" now :-)) CU thl From gdk at redhat.com Thu Jan 18 19:36:53 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Thu, 18 Jan 2007 14:36:53 -0500 (EST) Subject: Name for a FESCo Successor? Suggestions anyone? In-Reply-To: <45AFBEDB.60107@leemhuis.info> References: <45AD12F9.3050204@leemhuis.info> <45AFBEDB.60107@leemhuis.info> Message-ID: +1 to Fedora Engineering Steering Committee. :) --g On Thu, 18 Jan 2007, Thorsten Leemhuis wrote: > Hi! > > /me again! > > Thorsten Leemhuis schrieb: >> [...] >> But one issue is still totally undecided and needs to be solved soon: >> What do we call that FESCo and Core Cabal successor? The "E" in FESCo >> until now stood for Extras, but soon Extras will vanish due to the >> merge. So hat do we want to call it? [...] > > FESCo discussed this in todays meeting. We agreed to just continue with > the old name :) > > It just means "Fedora Steering Committee" or "Fedora Engineering > Steering Committee" now :-)) > > CU > thl > > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From jkeating at redhat.com Thu Jan 18 20:33:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Jan 2007 15:33:36 -0500 Subject: Name for a FESCo Successor? Suggestions anyone? In-Reply-To: References: <45AD12F9.3050204@leemhuis.info> <45AFBEDB.60107@leemhuis.info> Message-ID: <200701181533.40804.jkeating@redhat.com> On Thursday 18 January 2007 14:36, Greg Dekoenigsberg wrote: > +1 to Fedora Engineering Steering Committee. ?:) +1 from me on this too, since we'll be dealing mostly with engineering type things, and not necessarily marketing, or art, or... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Fri Jan 19 19:50:18 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 19 Jan 2007 14:50:18 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-01-19 Message-ID: <20070119195018.E958B15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): avahi FC6-updates > FC7 (0:0.6.16-2.fc6 > 0:0.6.15-4.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) selinux-policy FC6-updates > FC7 (0:2.4.6-23.fc6 > 0:2.4.6-21.fc7) xen FC5-updates > FC7 (0:3.0.3-3.fc5 > 0:3.0.3-3) FC6-updates > FC7 (0:3.0.3-3.fc6 > 0:3.0.3-3) yum FC6-updates > FC7 (0:3.0.3-1.fc6 > 0:3.0.1-6.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) devrim AT commandprompt.com: phpPgAdmin FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) gauret AT free.fr: amarok FE6 > FE7 (0:1.4.4-6.fc6 > 0:1.4.4-5.fc7) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jkeating AT redhat.com: pungi FE6 > FE7 (0:0.1.2-2.fc6 > 0:0.1.2-1.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-5.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-6.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: listen FE6 > FE7 (0:0.5-11.beta1.fc6 > 0:0.5-9.beta1.fc7.4) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) ville.skytta AT iki.fi: em8300-kmod FE6 > FE7 (0:0.16.0-5.2.6.19_1.2895.fc6 > 0:0.16.0-5.2.6.18_1.2869.fc6) ---------------------------------------------------------------------- amarok: gauret AT free.fr FE6 > FE7 (0:1.4.4-6.fc6 > 0:1.4.4-5.fc7) avahi: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.6.16-2.fc6 > 0:0.6.15-4.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) em8300-kmod: ville.skytta AT iki.fi FE6 > FE7 (0:0.16.0-5.2.6.19_1.2895.fc6 > 0:0.16.0-5.2.6.18_1.2869.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) listen: karlthered AT gmail.com FE6 > FE7 (0:0.5-11.beta1.fc6 > 0:0.5-9.beta1.fc7.4) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) phpPgAdmin: devrim AT commandprompt.com FE6 > FE7 (0:4.0.1-7.fc6 > 0:4.0.1-6.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-5.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-6.fc6 > 0:2.5.1-3.fc7) pungi: jkeating AT redhat.com FE6 > FE7 (0:0.1.2-2.fc6 > 0:0.1.2-1.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) selinux-policy: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.4.6-23.fc6 > 0:2.4.6-21.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.0.3-3.fc5 > 0:3.0.3-3) FC6-updates > FC7 (0:3.0.3-3.fc6 > 0:3.0.3-3) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) yum: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.0.3-1.fc6 > 0:3.0.1-6.fc7) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From fedora at leemhuis.info Sat Jan 20 16:59:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 20 Jan 2007 17:59:10 +0100 Subject: Co-maintainersip policy for Fedora Packages Message-ID: <45B24A5E.9050207@leemhuis.info> Hi all! Fedora Extras for a long time wanted to have more than one maintainer per package as that has several advantages (see below). But until now we never had a policy how it should look like and how it those maintainers should work and interact. I took some time and wrote something up. Please comment! CU thl P.S.: This stuff (and some more details) can be found in the wiki at http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership === Why do we need it === There are several reasons why we need it: * co-maintainership could be the main new enter path for new Extras contributors -- people could start their "Extras maintainer life" with co-maintaining packages when they don't know what to package (a lot of/most interesting stuff is already packaged so the traditional enter path Fedora Extras used in the past doesn't scale anymore). Experienced maintainer could then watch, help and teach the new contributor that way. If the new contributor showed that he understands everything well he gets more permissions in Extras -- he for example could take over a package as primary maintainer * upstream maintainers could co-maintain their packages. They could import the updates while the fedora-maintainers watches their doings and checks that everything stays compatible to Fedora and the Fedora packaging guidelines * One maintainer does not scale; for example, if a maintainer offline due to vacations, traveling to conferences or other happenings someone else has should be easily able to fix security stuff * people get when distracted by other projects/work areas/schedules/real life and can't watch their packages closely to fix/update stuff * people use packages sometimes differently -- one maintainer might be more interested in feature foo while the other might be more interested in bar -- let them work together and the package is better maintained and the quality improved for users that need both foo and bar * maintainers of one package could watch and check each others commits * we support multiple releases (and will probably support even more in the future) -- one packager might be interested in devel and FC-current only while another might be interested in FC-current -1, or EPEL * some people maintain more then 50 (one even more then 100) packages -- we should make sure they don't burn out. And the package quality probably is better if one maintainer only maintains a smaller number of packages * sponsors could act as primary-maintainer for a new package from a new contributor in the beginning if they are unsure if the new contributor is worth sponsoring. The new contributor could do all the work in cvs while being watched by the sponsor. Only the sponsor would have permission to request the build of a package in the beginning; the new contributors gets more permissions if everything worked fine for a while. === Policy Proposal === ---- == Digest == All packages in Fedora Extras shall normally be maintained by a group of maintainers. Each package normally should have at least three maintainers in total. There is one primary maintainer and a primary maintainer per distribution release (both often will be identical); he should have at least one co-maintainer per release. Maintainers and sponsors are encouraged to use co-maintainership to educate new contributors an help them getting involved and integrated into the Project. Maintainers should hand over packages to co-maintainers when they have lots of packages to improve the quality, share the load and get people involved. == Co-maintainership == All packages in Fedora Extras shall normally be maintained by a group of maintainers. That has several benefits; maintainers for example can watch and help each other. One maintainer further can fix important bugs (security, data-corruption, whatever!) even when the other maintainer(s) are offline (traveling, sleeping, whatever). The goal is to have at least three maintainers per package in total and at least two per distribution release. Big and important packages should have more -- there is no upper limit. There is a primary maintainer that takes care of the package in general; it's his job to make sure the efforts of the different maintainers get coordinated. Then there is a primary maintainer per distribution release (often that will be the same as the primary maintainer); bugs get assigned to him. It does not mean that he has to do all the work, but he has to make sure the work gets done! All the maintainers normally should share the load to make sure that all are familiar with the package -- the Fedora Distribution in a big community project and keeping something like that running is not be helped with a "This is my package, I don't want other people touching it" attitude. Packages primary maintained by Red Hat employees should have at least one co-maintainer from the community. They should try to hand over certain regular maintain task to the the community; that should help getting the community involved everywhere and to get some load of the Red Hat employees so they can focus on more imporant things -- that's best for both sides! Co-maintainership should also make the sponsorship process easier, too. New contributors can (they don't have to -- that's the decision of the sponsor) start as co-maintainers for the packages they submitted while the Sponsor or some experienced packager gets primary maintainer of it. The new contributor then get limited ACLs first that allow him to only modify those packages in CVS that they co-maintains. The primary maintainer can check the things that got changed before he kicks off the build. The new contributor gets full access after everything worked fine for a while. === Coordination between maintainers === The primary maintainer can set individual guidelines what his co-maintainers are allowed and what not; be has to put them into the wiki at Packages//MaintainerRules . A hint to that page should be as comment on the top of the spec file. Those rules are optional, it normally works like this if no rules were specified: * the per-release primary maintainer takes care of the a package for that release; he has to make sure the work gets done. He shares the workload with the co-maintainers. All of them check each others commits for correctness. * all maintainers can directly commit small changes (for example: small package enhancements/fixups) to cvs. Only the primary maintainers normally builds them. * medium sized changes (for example: update from 1.0.1 to 1.0.2) should get coordinated. Best and easiest practice it to commit changes if they are obvious and wait one or two days before building/pushing the package out to give the co-maintainers a chance to yell if they see problems. Only the primary maintainers normally builds the update. * big changes (for example: update from 1.0.1 to 1.2.0 or heavy changes in the spec file) should normally get coordinated between the different maintainers via e-mail or bugzilla before they get committed * the usual rules for [:Extras/Policy/WhoIsAllowedToModifyWhichPackages: modifying other people packages] remain intact, thus people from QA, Security or Arch-SIGs might touch the package, too. * the primary maintainer handles who is co-maintaining his packages === Disputes === There are big chances that conflicts will always arise if two or more people work together on a package (a: "1+1=2"; b: "no, you're stupid; 1+1=10"; c: "you are both stupid, 1+1=11"). There are no hard rules how maintainers should solve those disagreements. But in practice it should be something like this: * if one maintainer thinks the primary (per release) maintainer is doing something wrong then the primary (per release) maintainer should ask a third person (preferred: another maintainer of said package or the SIG that handles them) as mediator or ask on the mailing list for comments. * if two maintainers agree that the primary maintainer is doing something not as they would like to then the primary maintainer should really start thinking about changing something to make those two happy. A fourth person or a SIG can be asked as mediator; the list can be used to get further comments, too. If the problems don't get solved that way a FESCo-member should be asked to mediate. If co-maintainers get the impression that the primary maintainer is a lame duck and doesn't do his job properly then they should kindly ask the primary maintainer to hand over the package. If he's unwilling for no good reasons or does not respond at all or seems to be AFK then again a mediator has to be found. FESCo can hand over a package to somebody else if there is a need to (packager does not respond) if the committee believes that the co-maintainers will do the job better. === Don't maintain to many packages === People owning a lot of packages are encouraged to hand over maintainership to other maintainers with less packages. That should share the load between different people and result in better overall package quality, as people that maintain only a small number of packages often take more care of them than those with a lot of packages. By handling over packages to other people we let new people learn packaging and maintaining software in Fedora, too; that should help getting more people involved into Fedora and let them grow up. That serves the Project as a whole and is important for us. Maintainers with lots of packages thus should ask others (existing co-maintainers and *especially* new contributors that seems to be willing to get more involved) that seem to be interested in a package to become a co-maintainer for a package. Educate those co-maintainers a bit and tell them about the backgrounds of the package and how it was maintained in the past. Then let the co-maintainer do some work and watch him. If he does a good job give him more responsibilities over time and while stepping back from it more and more over time. At some point hand over the job as primary (release) maintainer to the co-maintainer when he did the job fine; become a co-maintainer for the package at the same time. If the new primary maintainer continues to do a good job consider stepping away completely to yet make more room for a new packager to get involved. === Other aspects of co-maintainership === We had some situations where maintainers had to stop maintaining packages in Fedora. That can happen due to different circumstances -- sicknesses, accidents, changes in the job or at home are only some examples for reasons to stop. Some of those situations happen suddenly and are not foreseeable. Due to this maintainers are strongly advised to build a healthy maintainer community around all of their packages so those people can take over the packages smoothly even if you stop maintaining packages tomorrow suddenly because you won in the lottery and became millionaire. SIGs can't become co-maintainers per-se. Rather they should observe the packages or make sure that SIG members are co-maintainers. === Intermediate solution === We require the PackageDB and some other technical things to really make above policy possible. Until we have those it works like this: * the general and primary-maintainers for each release are always identical (exception: EPEL); it's the one that listed as first in owners.list * co-maintainers all get listed in the last field in owners.list * there are no ACLs yet in the VCS, thus we need to find ways to live without them * all packages should have at least two co-maintainers From bpepple at fedoraproject.org Sat Jan 20 18:10:34 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 20 Jan 2007 13:10:34 -0500 Subject: FESCo Meeting Summary for 2007-01-18 Message-ID: <1169316634.27605.2.camel@Chuck> Members Present * Thorsten Leemhuis (thl) * Brian Pepple (bpepple) * Rex Dieter (rdieter) * Jason Tibbitts (tibbs) * Toshio Kuratomi (abadger1999) * Christian Iseli (ch4chris) * Warren Togami (warren) * Josh Boyer (jwb) * Tom Callaway (spot) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jeremy Katz (jeremy) * Jesse Keating (f13) * Bill Nottingham (notting) Absent * Andreas Bierfert (awjb) == Summary == EPEL Update * Most of the outstanding issues are waiting on RedHat IS. * It was brought up that EPEL should have separate guideline (e.g. latest and greatest vs. a more stable approach), and that the EPEL community should make this decision. Opening Core * FAB accepted thl's proposal on the FESCo/Core cabal merge. Welcome to FESCo Jesse & Bill! * f13, notting, and max will be added to the fesco-list. FESCo-successor name issue * It was decided to keep the name 'FESCo' after the Core/Extras merge. thl will send an e-mail to the mailing lists announcing this. Encourage co-maintainership * thl is going to send an e-mail to the mailing lists with his proposal. Firefox updates in stable often breaks packages * Will look at automating rebuilds of affected packages, though this won't before F7. * For now, bpepple is going to form a group with other maintainers with packages affected by Firefox updates so rebuilds are handled more quickly. Disallow cvs-import for everything but the initial import * It was discussed how using cvs-import quite often overwrite previous changes done by other maintainers. * The initial thought on how to fix this was to modify cvs-import to prevent this behavior, but many issues need further discussion before acting. Further brain-storming will occur on the mailing list, so as not to waste meeting time. What do we want to see in the approved-message in a review bug * People seeking sponsorship should definitely use checklist of items reviewed, so there is documentation of their knowledge of the packaging guidelines. * If there is a discussion on issues in the review, then an APPROVED only is probably ok. Syslog-ng Patent Problems * RedHat Legal is currently reviewing this issue. Misc * FESCo meeting in the future will take place in #fedora-meeting beginning on 2007-01-25. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070118 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at fedoraproject.org Sun Jan 21 21:20:33 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 21 Jan 2007 16:20:33 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-01-21 Message-ID: <20070121212033.81B8D15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): avahi FC6-updates > FC7 (0:0.6.16-2.fc6 > 0:0.6.15-4.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) selinux-policy FC6-updates > FC7 (0:2.4.6-23.fc6 > 0:2.4.6-21.fc7) yum FC6-updates > FC7 (0:3.0.3-1.fc6 > 0:3.0.1-6.fc7) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) gauret AT free.fr: amarok FE6 > FE7 (0:1.4.4-6.fc6 > 0:1.4.4-5.fc7) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jkeating AT redhat.com: pungi FE6 > FE7 (0:0.1.2-2.fc6 > 0:0.1.2-1.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-5.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-6.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: listen FE6 > FE7 (0:0.5-11.beta1.fc6 > 0:0.5-9.beta1.fc7.4) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) ville.skytta AT iki.fi: em8300-kmod FE6 > FE7 (0:0.16.0-5.2.6.19_1.2895.fc6 > 0:0.16.0-5.2.6.18_1.2869.fc6) ---------------------------------------------------------------------- amarok: gauret AT free.fr FE6 > FE7 (0:1.4.4-6.fc6 > 0:1.4.4-5.fc7) avahi: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.6.16-2.fc6 > 0:0.6.15-4.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) em8300-kmod: ville.skytta AT iki.fi FE6 > FE7 (0:0.16.0-5.2.6.19_1.2895.fc6 > 0:0.16.0-5.2.6.18_1.2869.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) listen: karlthered AT gmail.com FE6 > FE7 (0:0.5-11.beta1.fc6 > 0:0.5-9.beta1.fc7.4) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-5.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-6.fc6 > 0:2.5.1-3.fc7) pungi: jkeating AT redhat.com FE6 > FE7 (0:0.1.2-2.fc6 > 0:0.1.2-1.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) selinux-policy: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.4.6-23.fc6 > 0:2.4.6-21.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) yum: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.0.3-1.fc6 > 0:3.0.1-6.fc7) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From alexl at redhat.com Mon Jan 22 09:33:00 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 22 Jan 2007 10:33:00 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B24A5E.9050207@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> Message-ID: <1169458380.18434.12.camel@greebo> On Sat, 2007-01-20 at 17:59 +0100, Thorsten Leemhuis wrote: > Hi all! > > Fedora Extras for a long time wanted to have more than one maintainer > per package as that has several advantages (see below). But until now we > never had a policy how it should look like and how it those maintainers > should work and interact. I took some time and wrote something up. > Please comment! I have a somewhat related question. Is there a way for a user to follow all bugzilla traffic for a specific module. This is useful both in the multiple maintainers case, but also in the current state where people are helping out with specific modules. Right now the only way i know of is to follow all the maintainers bugzilla mail and filter on the component in the mail header. This is not particularly nice though... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a fiendish gay senator looking for 'the Big One.' She's a disco-crazy gypsy Valkyrie from a different time and place. They fight crime! From bugs.michael at gmx.net Mon Jan 22 09:47:40 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 22 Jan 2007 10:47:40 +0100 Subject: More Extras orphans on the hit list - 20070109 In-Reply-To: <1168369879.7683.651.camel@localhost.localdomain> References: <20070109201407.43826104.bugs.michael@gmx.net> <1168369879.7683.651.camel@localhost.localdomain> Message-ID: <20070122104740.e1f1e77f.bugs.michael@gmx.net> On Tue, 09 Jan 2007 14:11:19 -0500, Adam Jackson wrote: > > The following Fedora Extras packages have been orphaned last year (after > > Nov 1st) and need a new maintainer: > > > > deltarpm > > I can take this. If you are serious about this, please edit owners/owners.list in CVS so the package is no longer orphaned. From a.badger at gmail.com Mon Jan 22 09:46:47 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 22 Jan 2007 01:46:47 -0800 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169458380.18434.12.camel@greebo> References: <45B24A5E.9050207@leemhuis.info> <1169458380.18434.12.camel@greebo> Message-ID: <1169459207.6687.29.camel@localhost.localdomain> On Mon, 2007-01-22 at 10:33 +0100, Alexander Larsson wrote: > On Sat, 2007-01-20 at 17:59 +0100, Thorsten Leemhuis wrote: > > Hi all! > > > > Fedora Extras for a long time wanted to have more than one maintainer > > per package as that has several advantages (see below). But until now we > > never had a policy how it should look like and how it those maintainers > > should work and interact. I took some time and wrote something up. > > Please comment! > > I have a somewhat related question. Is there a way for a user to follow > all bugzilla traffic for a specific module. This is useful both in the > multiple maintainers case, but also in the current state where people > are helping out with specific modules. > > Right now the only way i know of is to follow all the maintainers > bugzilla mail and filter on the component in the mail header. This is > not particularly nice though... Initialcc might be the functionality you're looking for. If you want to be cc'd to bugzilla traffic for the bzr package you checkout the owners module from extras cvs. Then you edit the owners.list file, adding your bugzilla email address to the last field in the list. Future bugzilla reports should add your email to the initial cc list for the package. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From roozbeh at farsiweb.info Mon Jan 22 10:29:40 2007 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Mon, 22 Jan 2007 13:59:40 +0330 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B24A5E.9050207@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> Message-ID: <1169461780.3329.12.camel@shalil.farsiweb.info> On Sat, 2007-01-20 at 17:59 +0100, Thorsten Leemhuis wrote: > === Disputes === > [...] I don't know what is it, but this part makes me worry to some degree. It looks like too much bureaucracy, and the challenge-from-within thing is rather scary, and may make some maintainers choose polite and accepting co-maintainers instead of competent ones (although these attributes are not mutually exclusive, the limited choice makes that kind of decisions unavoidable sometimes). I also tend to think that the suggested mechanism will push us toward a democracy to some degree instead of a meritocracy. I guess I should bite the bullet and say it: The bureaucracy looks too much like Debian to me. I quite like other parts of the proposal, and the only other part that makes me worry a little is the three-maintainers-per-package part. I can't say much about other packages, with the kind of packages that I am/was involved in maintaining, two is usually quite enough. Three or more maintainers will only make things more complicated. Roozbeh From denis at poolshark.org Mon Jan 22 11:07:52 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 22 Jan 2007 12:07:52 +0100 Subject: More Extras orphans on the hit list - 20070109 In-Reply-To: <20070109201407.43826104.bugs.michael@gmx.net> References: <20070109201407.43826104.bugs.michael@gmx.net> Message-ID: <45B49B08.5040808@poolshark.org> Michael Schwendt wrote: > gtranslator if nobody objects, I'll pick that one up. From roozbeh at farsiweb.info Mon Jan 22 11:30:27 2007 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Mon, 22 Jan 2007 15:00:27 +0330 Subject: More Extras orphans on the hit list - 20070109 In-Reply-To: <45B49B08.5040808@poolshark.org> References: <20070109201407.43826104.bugs.michael@gmx.net> <45B49B08.5040808@poolshark.org> Message-ID: <1169465427.3329.15.camel@shalil.farsiweb.info> On Mon, 2007-01-22 at 12:07 +0100, Denis Leroy wrote: > Michael Schwendt wrote: > > gtranslator > > if nobody objects, I'll pick that one up. Just to note that it is quite under-maintained, which was the main reason I dropped it. Last release has been about two years ago, for example. Roozbeh From pertusus at free.fr Mon Jan 22 14:09:40 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 22 Jan 2007 15:09:40 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B24A5E.9050207@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> Message-ID: <20070122140940.GD2586@free.fr> > === Disputes === > I don't think we need something specific here. In my opinion disputes between co-maintainers or disputes between fedora contributors should be settled similarly. And I think something simpler should be used, like * first try to discuss (preferably on a bugzilla ticket) * mail to the fedora-extras-list or similar to ask for advice from the community * escalate to FESCo And of course, there is the already the AWOL policy. -- Pat From sandmann at redhat.com Mon Jan 22 15:54:23 2007 From: sandmann at redhat.com (Soeren Sandmann Pedersen) Date: 22 Jan 2007 10:54:23 -0500 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169458380.18434.12.camel@greebo> References: <45B24A5E.9050207@leemhuis.info> <1169458380.18434.12.camel@greebo> Message-ID: Alexander Larsson writes: > On Sat, 2007-01-20 at 17:59 +0100, Thorsten Leemhuis wrote: > > Hi all! > > > > Fedora Extras for a long time wanted to have more than one maintainer > > per package as that has several advantages (see below). But until now we > > never had a policy how it should look like and how it those maintainers > > should work and interact. I took some time and wrote something up. > > Please comment! > > I have a somewhat related question. Is there a way for a user to follow > all bugzilla traffic for a specific module. This is useful both in the > multiple maintainers case, but also in the current state where people > are helping out with specific modules. > > Right now the only way i know of is to follow all the maintainers > bugzilla mail and filter on the component in the mail header. This is > not particularly nice though... What GNOME usually does, is send all the bugzilla mail for to some -maint email address that doesn't actually go anywhere. That way maintainers and everybody else who is interested can follow all email sent to that address. Soren From alexl at redhat.com Mon Jan 22 16:56:32 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 22 Jan 2007 17:56:32 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169459207.6687.29.camel@localhost.localdomain> References: <45B24A5E.9050207@leemhuis.info> <1169458380.18434.12.camel@greebo> <1169459207.6687.29.camel@localhost.localdomain> Message-ID: <1169484992.18434.22.camel@greebo> On Mon, 2007-01-22 at 01:46 -0800, Toshio Kuratomi wrote: > Initialcc might be the functionality you're looking for. If you want to > be cc'd to bugzilla traffic for the bzr package you checkout the owners > module from extras cvs. Then you edit the owners.list file, adding your > bugzilla email address to the last field in the list. Future bugzilla > reports should add your email to the initial cc list for the package. Can anyone edit that file? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a globe-trotting vegetarian boxer searching for his wife's true killer. She's a foxy bisexual archaeologist with only herself to blame. They fight crime! From a.badger at gmail.com Mon Jan 22 17:11:25 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 22 Jan 2007 09:11:25 -0800 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169461780.3329.12.camel@shalil.farsiweb.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> Message-ID: <1169485885.6687.48.camel@localhost.localdomain> On Mon, 2007-01-22 at 13:59 +0330, Roozbeh Pournader wrote: > On Sat, 2007-01-20 at 17:59 +0100, Thorsten Leemhuis wrote: > > === Disputes === > > [...] > > I don't know what is it, but this part makes me worry to some degree. It > looks like too much bureaucracy, and the challenge-from-within thing is > rather scary, and may make some maintainers choose polite and accepting > co-maintainers instead of competent ones (although these attributes are > not mutually exclusive, the limited choice makes that kind of decisions > unavoidable sometimes). > If you and another person rub each other the wrong way there's a good chance you shouldn't make them a co-maintainer anyway. Competency is more than knowing how to code and package, it's also interpersonal skills and the ability to communicate with your peers. You don't want "yes men" but you also don't want people who will take any controversial decision as a chance to publicly argue with you. > I also tend to think that the suggested mechanism will push us toward a > democracy to some degree instead of a meritocracy. I guess I should bite > the bullet and say it: The bureaucracy looks too much like Debian to me. > There needs to be a dispute policy of some kind, though. And some method of challenge from within is good too. That way when you have a maintainer who is mismanaging their packages there is a documented way to get them into the hands of someone who can and wants to do a better job. If this kind of thing is left up to an ad hoc, when the situation arises, we'll do something about it policy, then the packager who loses control of the package will be sure that his situation is a special case of everybody else out to get him personally. That said, there could definitely be changes made to the dispute section to make it address your concerns. thl outlines two cases where disputes arise: 1) Comaintainer and owner disagree over how to solve a problem. 2) Comaintainers feel the owner is holding up the process of developing the package. Do you have some suggestions for minimizing bureaucracy and ensuring that decisions are based on merit in each of these cases? > I quite like other parts of the proposal, and the only other part that > makes me worry a little is the three-maintainers-per-package part. I > can't say much about other packages, with the kind of packages that I > am/was involved in maintaining, two is usually quite enough. Three or > more maintainers will only make things more complicated. I read that as two maintainers (one primary, one co-maintainer) but thl would need to clarify. In general, I think having more co-maintainers would be beneficial to most packages. thl outlines the benefits in the policy draft. The disadvantage is the increased chance of disputes between maintainers. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tmz at pobox.com Mon Jan 22 17:26:22 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 22 Jan 2007 12:26:22 -0500 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169484992.18434.22.camel@greebo> References: <45B24A5E.9050207@leemhuis.info> <1169458380.18434.12.camel@greebo> <1169459207.6687.29.camel@localhost.localdomain> <1169484992.18434.22.camel@greebo> Message-ID: <20070122172622.GN30198@psilocybe.teonanacatl.org> Alexander Larsson wrote: > On Mon, 2007-01-22 at 01:46 -0800, Toshio Kuratomi wrote: > >> Initialcc might be the functionality you're looking for. If you >> want to be cc'd to bugzilla traffic for the bzr package you >> checkout the owners module from extras cvs. Then you edit the >> owners.list file, adding your bugzilla email address to the last >> field in the list. Future bugzilla reports should add your email >> to the initial cc list for the package. > > Can anyone edit that file? AFAIK anyone in the cvsextras group can do so. That sounds like it'll work nicely once core and extras merge. If there's a similar method to do this for current core packages, that'd be excellent. Anyone know if there is? -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== The chains of habit are too weak to be felt until they are too strong to be broken -- Samuel Johnson (1709-1784) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From a.badger at gmail.com Mon Jan 22 17:32:53 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 22 Jan 2007 09:32:53 -0800 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169484992.18434.22.camel@greebo> References: <45B24A5E.9050207@leemhuis.info> <1169458380.18434.12.camel@greebo> <1169459207.6687.29.camel@localhost.localdomain> <1169484992.18434.22.camel@greebo> Message-ID: <1169487173.6687.59.camel@localhost.localdomain> On Mon, 2007-01-22 at 17:56 +0100, Alexander Larsson wrote: > On Mon, 2007-01-22 at 01:46 -0800, Toshio Kuratomi wrote: > > > Initialcc might be the functionality you're looking for. If you want to > > be cc'd to bugzilla traffic for the bzr package you checkout the owners > > module from extras cvs. Then you edit the owners.list file, adding your > > bugzilla email address to the last field in the list. Future bugzilla > > reports should add your email to the initial cc list for the package. > > Can anyone edit that file? You have to be able to edit files in extras cvs which means general distro users, no. In the merged Core+Extras all the current RH packagers are going to have to get sponsored in so they can continue to maintain their packages so they'll have access to it. For the packageDB, I've included a way to sign up to watch commit mail and watch bugzilla mail. We might want to enable this for non-contributors but currently it's not easy to enable this without being in the Fedora Account System. We might be able to solve that by allowing people to sign up for a "I'm not a contributor and don't want to sign the CLA" group where anyone can sign up, add their bugzilla email account, and add themselves as watchers. This group wouldn't have to sign the CLA and wouldn't be able to make any changes to code or documentation; just sign up for notifications. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Jan 22 19:06:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 22 Jan 2007 14:06:43 -0500 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <20070122140940.GD2586@free.fr> References: <45B24A5E.9050207@leemhuis.info> <20070122140940.GD2586@free.fr> Message-ID: <20070122190643.GA26694@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > I don't think we need something specific here. In my opinion disputes > between co-maintainers or disputes between fedora contributors should be > settled similarly. And I think something simpler should be used, like > > * first try to discuss (preferably on a bugzilla ticket) > * mail to the fedora-extras-list or similar to ask for advice from the > community > * escalate to FESCo > > And of course, there is the already the AWOL policy. I agree. Realistically, this is about packaging and package maintenance. Hopefully, we can get to the point where there's nothing controversial enough about it to cause large disagreements. :) Bill From paul at xelerance.com Mon Jan 22 19:21:07 2007 From: paul at xelerance.com (Paul Wouters) Date: Mon, 22 Jan 2007 20:21:07 +0100 (CET) Subject: obsoleted rpm packages we can remove from the FE6 repo In-Reply-To: <20070116084937.GA3646@dudweiler.stuttgart.redhat.com> References: <20070116084937.GA3646@dudweiler.stuttgart.redhat.com> Message-ID: On Tue, 16 Jan 2007, Florian La Roche wrote: > l2tpd-0.69-0.6.20051030.fc6.i386.rpm is obsoleted by xl2tpd-1.1.06-5.fc6.i386.rpm As the maintainer of both, should I turn l2tpd in a DEAD_PACKAGE in the fc6 repo? Paul From notting at redhat.com Mon Jan 22 19:32:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 22 Jan 2007 14:32:39 -0500 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B24A5E.9050207@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> Message-ID: <20070122193239.GB26694@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > Fedora Extras for a long time wanted to have more than one maintainer > per package as that has several advantages (see below). But until now we > never had a policy how it should look like and how it those maintainers > should work and interact. I took some time and wrote something up. > Please comment! I suspect finding three people that care about every package is going to be hard, although I'd love to be proven wrong. My main comment is it does seem like a lot of policy/procedures around something that might be better to grow organically - a lot of the should/ shall seems better suited to be 'are encouraged to'. > All packages in Fedora Extras shall normally be maintained by a group of > maintainers. That has several benefits; maintainers for example can > watch and help each other. One maintainer further can fix important bugs > (security, data-corruption, whatever!) even when the other maintainer(s) > are offline (traveling, sleeping, whatever). *cough* Upstream! *cough* > Packages primary maintained by Red Hat employees should > have at least one co-maintainer from the community. They should try to > hand over certain regular maintain task to the the community; that > should help getting the community involved everywhere and to get some > load of the Red Hat employees so they can focus on more imporant things > -- that's best for both sides! How is this different than the rest of the policy? One community, maintainers are maintainers, co-maintainers are co-maintainers. Trying to draft specific policy based on locality seems like a bad idea to me. > The primary maintainer can set individual guidelines what his > co-maintainers are allowed and what not; be has to put them into the > wiki at Packages//MaintainerRules . A hint to that page > should be as comment on the top of the spec file. Seems overkill to me, leads to dependencies in system A (package SCM) to absolute paths in system B (wiki), etc. (comemnts about dispute resolution in another mail) > SIGs can't become co-maintainers per-se. Rather they should observe the > packages or make sure that SIG members are co-maintainers. Leads to a big grey area w.r.t 5/10 maintainers vs. a SIG. > We require the PackageDB and some other technical things to really make > above policy possible. Until we have those it works like this: > > * the general and primary-maintainers for each release are always > identical (exception: EPEL); it's the one that listed as first in > owners.list > > * co-maintainers all get listed in the last field in owners.list > > * there are no ACLs yet in the VCS, thus we need to find ways to live > without them Slight counter proposal: - primary maintainer is the one in owners.list - co-maintainers are the ones in the ACLs. Add yourself to initial CC if you'd like. (These, unfortunately, are separate) - further waits on the package db. > * all packages should have at least two co-maintainers See above. TBH, I don't see that we're drowning in maintainers - how is someone that co-maintains 50 packages better than someone that maintains 20? Bill From belegdol at gmail.com Mon Jan 22 20:34:14 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Mon, 22 Jan 2007 20:34:14 +0000 Subject: Stuck behind a proxy :( Message-ID: <9b1b20e70701221234r5779e1albb782471c95cb861@mail.gmail.com> Hello. It looks like I will be stuck behind a proxy for a while :( I have left Poland for about half a year, to spend one semester at the University of Strathclyde (Erasmus exchange). The problem is that the network within the halls of residence connects to the outer world via http proxy. So I am able to browse the web and download files via ftp, but cvs does not work for me. So please, feel free to push any updates to my packages that you find necesary. I am (was?) the maintainer of the following ones: chemical-mime-data gchempaint gnome-chemistry-utils museek+ qt-qsa qwtplot3d I'll still be reading the list and once I get back access to cvs, I'll let you know. From denis at poolshark.org Mon Jan 22 21:05:00 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 22 Jan 2007 22:05:00 +0100 Subject: Stuck behind a proxy :( In-Reply-To: <9b1b20e70701221234r5779e1albb782471c95cb861@mail.gmail.com> References: <9b1b20e70701221234r5779e1albb782471c95cb861@mail.gmail.com> Message-ID: <45B526FC.5040505@poolshark.org> Julian Sikorski wrote: > Hello. It looks like I will be stuck behind a proxy for a while :( I > have left Poland for about half a year, to spend one semester at the > University of Strathclyde (Erasmus exchange). The problem is that the > network within the halls of residence connects to the outer world via > http proxy. So I am able to browse the web and download files via ftp, > but cvs does not work for me. So please, feel free to push any updates > to my packages that you find necesary. I am (was?) the maintainer of > the following ones: > chemical-mime-data > gchempaint > gnome-chemistry-utils > museek+ > qt-qsa > qwtplot3d > I'll still be reading the list and once I get back access to cvs, I'll > let you know. you can use cvs across an http proxy by using 'ProxyCommand' in your .ssh/config file (see 'man ssh_config', look for ProxyCommand). From musuruan at gmail.com Mon Jan 22 21:17:17 2007 From: musuruan at gmail.com (Andrea Musuruane) Date: Mon, 22 Jan 2007 22:17:17 +0100 Subject: More Extras orphans on the hit list - 20070109 In-Reply-To: <1169465427.3329.15.camel@shalil.farsiweb.info> References: <20070109201407.43826104.bugs.michael@gmx.net> <45B49B08.5040808@poolshark.org> <1169465427.3329.15.camel@shalil.farsiweb.info> Message-ID: <1169500637.3008.8.camel@localhost.localdomain> Il giorno lun, 22/01/2007 alle 15.00 +0330, Roozbeh Pournader ha scritto: > On Mon, 2007-01-22 at 12:07 +0100, Denis Leroy wrote: > > Michael Schwendt wrote: > > > gtranslator > > > > if nobody objects, I'll pick that one up. > > Just to note that it is quite under-maintained, which was the main > reason I dropped it. Last release has been about two years ago, for > example. I don't know if it is under-maintained but the last release was made last November: http://mail.gnome.org/archives/gtranslator-list/2006-November/msg00000.html Andrea. From denis at poolshark.org Mon Jan 22 21:22:03 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 22 Jan 2007 22:22:03 +0100 Subject: More Extras orphans on the hit list - 20070109 In-Reply-To: <1169500637.3008.8.camel@localhost.localdomain> References: <20070109201407.43826104.bugs.michael@gmx.net> <45B49B08.5040808@poolshark.org> <1169465427.3329.15.camel@shalil.farsiweb.info> <1169500637.3008.8.camel@localhost.localdomain> Message-ID: <45B52AFB.3030004@poolshark.org> Andrea Musuruane wrote: > Il giorno lun, 22/01/2007 alle 15.00 +0330, Roozbeh Pournader ha > scritto: >> On Mon, 2007-01-22 at 12:07 +0100, Denis Leroy wrote: >>> Michael Schwendt wrote: >>>> gtranslator >>> if nobody objects, I'll pick that one up. >> Just to note that it is quite under-maintained, which was the main >> reason I dropped it. Last release has been about two years ago, for >> example. > > I don't know if it is under-maintained but the last release was made > last November: > > http://mail.gnome.org/archives/gtranslator-list/2006-November/msg00000.html for the record, Sindre Bjordal expressed interest in gtranslate on f-e-l before I did, so the package is now his. From jkeating at redhat.com Mon Jan 22 23:30:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Jan 2007 18:30:51 -0500 Subject: Fedora 7 Test 1 Freeze tomorrow Message-ID: <200701221830.51918.jkeating@redhat.com> I plan on locking down the internal dist-fc7 collection at close of business tomorrow, which is roughly 18:00 EST, 23:00 UTC. The targets have changed a bit, we're only going to compose Fedora Desktop, and a LiveCD to accompany it. Other spins may be done later and be published in a yet to be determined locations, as we try to fine tune them, but for the "official" test 1, just the desktop. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon Jan 22 23:30:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 23 Jan 2007 05:00:41 +0530 Subject: Fedora 7 Test 1 Freeze tomorrow In-Reply-To: <200701221830.51918.jkeating@redhat.com> References: <200701221830.51918.jkeating@redhat.com> Message-ID: <45B54921.1010201@fedoraproject.org> Jesse Keating wrote: > I plan on locking down the internal dist-fc7 collection at close of business > tomorrow, which is roughly 18:00 EST, 23:00 UTC. > > The targets have changed a bit, we're only going to compose Fedora Desktop, > and a LiveCD to accompany it. Other spins may be done later and be published > in a yet to be determined locations, as we try to fine tune them, but for > the "official" test 1, just the desktop. > How many CD's is the desktop spin? Is there a DVD too? Is that Live CD installable? Would you be able to accommodate release notes? Rahul From Axel.Thimm at ATrpms.net Tue Jan 23 00:00:09 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 23 Jan 2007 01:00:09 +0100 Subject: Fedora 7 Test 1 Freeze tomorrow In-Reply-To: <200701221830.51918.jkeating@redhat.com> References: <200701221830.51918.jkeating@redhat.com> Message-ID: <20070123000009.GC1182@neu.nirvana> On Mon, Jan 22, 2007 at 06:30:51PM -0500, Jesse Keating wrote: > I plan on locking down the internal dist-fc7 collection at close of business > tomorrow, which is roughly 18:00 EST, 23:00 UTC. What was the outcome of the discussion about extras freezing as well on the same date? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jan 23 02:04:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Jan 2007 21:04:45 -0500 Subject: Fedora 7 Test 1 Freeze tomorrow In-Reply-To: <45B54921.1010201@fedoraproject.org> References: <200701221830.51918.jkeating@redhat.com> <45B54921.1010201@fedoraproject.org> Message-ID: <200701222104.49083.jkeating@redhat.com> On Monday 22 January 2007 18:30, Rahul Sundaram wrote: > How many CD's is the desktop spin? Is there a DVD too? Is that Live CD > installable? Would you be able to accommodate release notes? So many questions! Currently the desktop spin is weighing in at just barely 4 CDs with all the translations. We may be able to trim that a bit (monodevelop is getting pulled in for some reason) down to a full 3 CDs for i386, 4 CDs for x86_64/ppc. There will be a DVD. The LiveCD should be installable, the work went into Anaconda to allow for this, it does need a lot of testing! Are there release notes to accommodate? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Tue Jan 23 02:09:12 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 22 Jan 2007 20:09:12 -0600 Subject: Fedora 7 Test 1 Freeze tomorrow In-Reply-To: <20070123000009.GC1182@neu.nirvana> References: <200701221830.51918.jkeating@redhat.com> <20070123000009.GC1182@neu.nirvana> Message-ID: <20070123020912.GC25489@yoda.jdub.homelinux.org> On Tue, Jan 23, 2007 at 01:00:09AM +0100, Axel Thimm wrote: > On Mon, Jan 22, 2007 at 06:30:51PM -0500, Jesse Keating wrote: > > I plan on locking down the internal dist-fc7 collection at close of business > > tomorrow, which is roughly 18:00 EST, 23:00 UTC. > > What was the outcome of the discussion about extras freezing as well on > the same date? Good question... josh From katzj at redhat.com Tue Jan 23 03:14:07 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 22 Jan 2007 22:14:07 -0500 Subject: Fedora 7 Test 1 Freeze tomorrow In-Reply-To: <20070123020912.GC25489@yoda.jdub.homelinux.org> References: <200701221830.51918.jkeating@redhat.com> <20070123000009.GC1182@neu.nirvana> <20070123020912.GC25489@yoda.jdub.homelinux.org> Message-ID: <1169522047.4922.1.camel@aglarond.local> On Mon, 2007-01-22 at 20:09 -0600, Josh Boyer wrote: > On Tue, Jan 23, 2007 at 01:00:09AM +0100, Axel Thimm wrote: > > On Mon, Jan 22, 2007 at 06:30:51PM -0500, Jesse Keating wrote: > > > I plan on locking down the internal dist-fc7 collection at close of business > > > tomorrow, which is roughly 18:00 EST, 23:00 UTC. > > > > What was the outcome of the discussion about extras freezing as well on > > the same date? > > Good question... For test1 and our amazing, entirely manual and not at all automated process that we're going to be using[1], I think that we're just going to let the builds keep flowing and do pulls as needed into a repo that we use as the compose source. Jeremy From katzj at redhat.com Tue Jan 23 03:15:26 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 22 Jan 2007 22:15:26 -0500 Subject: Fedora 7 Test 1 Freeze tomorrow In-Reply-To: <45B54921.1010201@fedoraproject.org> References: <200701221830.51918.jkeating@redhat.com> <45B54921.1010201@fedoraproject.org> Message-ID: <1169522126.4922.4.camel@aglarond.local> On Tue, 2007-01-23 at 05:00 +0530, Rahul Sundaram wrote: > Is that Live CD installable? Yes, the plan is that the live CD will be installable. Unless something breaks between now and when it's spun. Jeremy From rdieter at math.unl.edu Tue Jan 23 03:26:12 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 22 Jan 2007 21:26:12 -0600 Subject: Fedora 7 Test 1 Freeze tomorrow In-Reply-To: <1169522126.4922.4.camel@aglarond.local> References: <200701221830.51918.jkeating@redhat.com> <45B54921.1010201@fedoraproject.org> <1169522126.4922.4.camel@aglarond.local> Message-ID: <45B58054.5090903@math.unl.edu> Jeremy Katz wrote: > On Tue, 2007-01-23 at 05:00 +0530, Rahul Sundaram wrote: > >>Is that Live CD installable? > Yes, the plan is that the live CD will be installable. Unless something > breaks between now and when it's spun. What will be used to generate said livecd? Last I checked, livecd-tools and fedora-livecd packages are still pending review. -- Rex From mclasen at redhat.com Tue Jan 23 04:06:03 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 22 Jan 2007 23:06:03 -0500 Subject: Fedora 7 Test 1 Freeze tomorrow In-Reply-To: <45B58054.5090903@math.unl.edu> References: <200701221830.51918.jkeating@redhat.com> <45B54921.1010201@fedoraproject.org> <1169522126.4922.4.camel@aglarond.local> <45B58054.5090903@math.unl.edu> Message-ID: <1169525163.3488.0.camel@localhost.localdomain> On Mon, 2007-01-22 at 21:26 -0600, Rex Dieter wrote: > Jeremy Katz wrote: > > On Tue, 2007-01-23 at 05:00 +0530, Rahul Sundaram wrote: > > > >>Is that Live CD installable? > > > Yes, the plan is that the live CD will be installable. Unless something > > breaks between now and when it's spun. > > What will be used to generate said livecd? Last I checked, livecd-tools > and fedora-livecd packages are still pending review. Which doesn't mean that you can't use them to produce live cds... From luya_tfz at thefinalzone.com Tue Jan 23 09:03:44 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Tue, 23 Jan 2007 04:03:44 -0500 Subject: Fedora 7 Test 1 Freeze tomorrow In-Reply-To: <200701222104.49083.jkeating@redhat.com> References: <200701221830.51918.jkeating@redhat.com> <45B54921.1010201@fedoraproject.org> <200701222104.49083.jkeating@redhat.com> Message-ID: <1169543024.45b5cf708215e@ssl.mecca.ca> Quoting Jesse Keating : > On Monday 22 January 2007 18:30, Rahul Sundaram wrote: > > How many CD's is the desktop spin? Is there a DVD too? Is that Live CD > > installable? Would you be able to accommodate release notes? > > So many questions! > > Currently the desktop spin is weighing in at just barely 4 CDs with all the > translations. We may be able to trim that a bit (monodevelop is getting > pulled in for some reason) down to a full 3 CDs for i386, 4 CDs for > x86_64/ppc. > > There will be a DVD. > > The LiveCD should be installable, the work went into Anaconda to allow for > this, it does need a lot of testing! > > Are there release notes to accommodate? I will update the release note related to Anaconda for F7T3. I am currently busy with work and the inclusion of more icons for Echo. -- Luya Tshimbalanga Fedora Project contributor http://www.fedoraproject.org/wiki/LuyaTshimbalanga From roozbeh at farsiweb.info Tue Jan 23 10:42:30 2007 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Tue, 23 Jan 2007 14:12:30 +0330 Subject: More Extras orphans on the hit list - 20070109 In-Reply-To: <1169500637.3008.8.camel@localhost.localdomain> References: <20070109201407.43826104.bugs.michael@gmx.net> <45B49B08.5040808@poolshark.org> <1169465427.3329.15.camel@shalil.farsiweb.info> <1169500637.3008.8.camel@localhost.localdomain> Message-ID: <1169548950.3364.3.camel@shalil.farsiweb.info> On Mon, 2007-01-22 at 22:17 +0100, Andrea Musuruane wrote: > I don't know if it is under-maintained but the last release was made > last November: > > http://mail.gnome.org/archives/gtranslator-list/2006-November/msg00000.html Heh. I had missed that. They have not updated their web page, so I assumed the project is half-dead. Roozbeh From jkeating at redhat.com Tue Jan 23 13:22:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 Jan 2007 08:22:13 -0500 Subject: Fedora 7 Test 1 Freeze tomorrow In-Reply-To: <1169522047.4922.1.camel@aglarond.local> References: <200701221830.51918.jkeating@redhat.com> <20070123020912.GC25489@yoda.jdub.homelinux.org> <1169522047.4922.1.camel@aglarond.local> Message-ID: <200701230822.13364.jkeating@redhat.com> On Monday 22 January 2007 22:14, Jeremy Katz wrote: > For test1 and our amazing, entirely manual and not at all automated > process that we're going to be using[1], I think that we're just going > to let the builds keep flowing and do pulls as needed into a repo that > we use as the compose source. Agreed. Pungi just pulls from arbitrary repositories, I can freeze myself and add to a repo as needed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Tue Jan 23 21:16:24 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 23 Jan 2007 15:16:24 -0600 Subject: Fedora Extras License Audit Message-ID: <1169586984.3333.21.camel@localhost.localdomain> As part of our ongoing committment to Open Source, Fedora Extras is undergoing a license audit of the packages contained within it. We do this for several reasons: 1. To ensure that we don't have any packages containing licenses that do not meet the Fedora licensing standards. 2. To ensure that the license tag for Fedora packages is accurate (even though it is by no means legally binding). 3. To get rid of things like "BSD-ish" and "Distributable" wherever possible. 4. Because we like pain. It hurts, sooo good. I can do this by myself. Of course, if I do, then the results of this audit will probably be ready sometime in 2013. Sadly, this is not a process that can be easily scripted (at least, not to my knowledge), and just requires knowledgable people looking at the package source code and identifying the licensing. Sound like fun? Well, no. But it is something that we do need volunteers to help with. So, if you're interested in taking on this challenge, let me know. The more people we can get to help in this task, the quicker it will be completed. We have about 2550 source packages to check. Thanks, ~spot From pertusus at free.fr Tue Jan 23 21:57:03 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 23 Jan 2007 22:57:03 +0100 Subject: Fedora Extras License Audit In-Reply-To: <1169586984.3333.21.camel@localhost.localdomain> References: <1169586984.3333.21.camel@localhost.localdomain> Message-ID: <20070123214530.GB7356@free.fr> On Tue, Jan 23, 2007 at 03:16:24PM -0600, Tom 'spot' Callaway wrote: > > I can do this by myself. Of course, if I do, then the results of this > audit will probably be ready sometime in 2013. Sadly, this is not a > process that can be easily scripted (at least, not to my knowledge), and > just requires knowledgable people looking at the package source code and > identifying the licensing. > > Sound like fun? Well, no. But it is something that we do need volunteers > to help with. So, if you're interested in taking on this challenge, let > me know. The more people we can get to help in this task, the quicker it > will be completed. We have about 2550 source packages to check. That's supposed to be done during review, isn't it? How could an audit catch more issues than caught during reviews? Maybe in the early day some packages weren't audited (like the one coming from core at some point), but a full rereview would seem to be more relevant than only a license audit. If I recall well this is on the way, but scheduled after the core packages review. Maybe it could be better if maintainers asked spontaneously for a rereview when they think that their package has potential license issues. For example, I think that it is a loss of time if somebody audit the license of the packages I maintain or I reviewed. I am not saying that I see everything and never make mistake, it may be possible that there are problematic files in those packages, but I think that re-auditing them is doing something twice without a guarantee that it will be done netter. I know for sure that there was some non-free code in the cernlib some time ago which weren't noticed during review, but an audit wouldn't have been likely to catch this issue either. -- Pat From opensource at till.name Tue Jan 23 23:47:07 2007 From: opensource at till.name (Till Maas) Date: Wed, 24 Jan 2007 00:47:07 +0100 Subject: Fedora Extras License Audit In-Reply-To: <20070123214530.GB7356@free.fr> References: <1169586984.3333.21.camel@localhost.localdomain> <20070123214530.GB7356@free.fr> Message-ID: <200701240047.10213.opensource@till.name> On Tuesday 23 January 2007 22:57, Patrice Dumas wrote: > On Tue, Jan 23, 2007 at 03:16:24PM -0600, Tom 'spot' Callaway wrote: > > just requires knowledgable people looking at the package source code and > That's supposed to be done during review, isn't it? How could an audit When I asked what needs to be done to check the license of a package in review it was said that it is enough to check the upstream documentation, e.g. the COPYING file. So looking into every source file for license information was probably not done for every package. And sometimes even included binary files slip through review e.g. in XaraLX. Regards, Till From pertusus at free.fr Wed Jan 24 00:47:32 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 24 Jan 2007 01:47:32 +0100 Subject: Fedora Extras License Audit In-Reply-To: <200701240047.10213.opensource@till.name> References: <1169586984.3333.21.camel@localhost.localdomain> <20070123214530.GB7356@free.fr> <200701240047.10213.opensource@till.name> Message-ID: <20070124004732.GC7356@free.fr> On Wed, Jan 24, 2007 at 12:47:07AM +0100, Till Maas wrote: > > When I asked what needs to be done to check the license of a package in review > it was said that it is enough to check the upstream documentation, e.g. the > COPYING file. I don't think it is right. What I do is try some random files in each directory to check that they have the right license. I also look carefully at things that seems to be added by external contributors. I also look at file names to try to find out some files that could come from other projects and be problematic. And as soon as I find one thing which isn't right, I do a complete audit of all the files. > So looking into every source file for license information was > probably not done for every package. And sometimes even included binary files Is it really to be done on each file? For big non problematic packages, I don't think it is worth it. -- Pat From pertusus at free.fr Wed Jan 24 00:54:09 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 24 Jan 2007 01:54:09 +0100 Subject: Fedora Extras License Audit In-Reply-To: <1169586984.3333.21.camel@localhost.localdomain> References: <1169586984.3333.21.camel@localhost.localdomain> Message-ID: <20070124005409.GD7356@free.fr> On Tue, Jan 23, 2007 at 03:16:24PM -0600, Tom 'spot' Callaway wrote: > As part of our ongoing committment to Open Source, Fedora Extras is > undergoing a license audit of the packages contained within it. We do > this for several reasons: > > 1. To ensure that we don't have any packages containing licenses that do > not meet the Fedora licensing standards. I take that opportunity to ask a few questions for cases that seem unclear to me. Do we consider files with copyright or a mention of an author and no license to be problematic, or to be covered by the main license (if such a thing exists)? Files copyrighted, but without license should be considered to be under a restrictive license (no modification nor redistribution). However, when the remaining of the package is consistently under a given license and the authors are the same I consider that the notice is missing, but that the main license cover the files. Is it right? Do we consider files with incomplete license notice (when a complete notice exists, like for the GPL) to be problematic? -- Pat From jkeating at redhat.com Wed Jan 24 04:00:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 Jan 2007 23:00:36 -0500 Subject: Fedora 7 Test 1 Freeze tomorrow In-Reply-To: <200701221830.51918.jkeating@redhat.com> References: <200701221830.51918.jkeating@redhat.com> Message-ID: <200701232300.36458.jkeating@redhat.com> On Monday 22 January 2007 18:30, Jesse Keating wrote: > I plan on locking down the internal dist-fc7 collection at close of > business tomorrow, which is roughly 18:00 EST, 23:00 UTC. We froze a few minutes ago, but not in the "normal" Fedora way. I've created a freeze tag internally, 'f7-test1', and tagged all the latest dist-fc7 builds with this tag. I'll be using this tag to create the repos that pungi will be using to compose the Test1 spins. Builds into dist-fc7 will continue as normally, things which we need for Test1 will be tagged with f7-test1 appropriately. If I get the configs right, rawhide will compose from f7-test1 as well until the trees are spun (this helps those playing with composes / composing outside the Red Hat Wall) If you need something from core tagged for Test1, please email jkeating at redhat do com, katzj at redhat dot com, and notting at redhat dot com. One of us will make the tag happen if we deem it proper for test1. As for extras, I'll most likely just cache the extras repo tonight or tomorrow and use that as my "freeze", updating it when necessary. Brrr! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Wed Jan 24 05:50:00 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 23 Jan 2007 23:50:00 -0600 Subject: Fedora Extras License Audit In-Reply-To: <20070124005409.GD7356@free.fr> References: <1169586984.3333.21.camel@localhost.localdomain> <20070124005409.GD7356@free.fr> Message-ID: <1169617800.8027.18.camel@localhost.localdomain> On Wed, 2007-01-24 at 01:54 +0100, Patrice Dumas wrote: > On Tue, Jan 23, 2007 at 03:16:24PM -0600, Tom 'spot' Callaway wrote: > > As part of our ongoing committment to Open Source, Fedora Extras is > > undergoing a license audit of the packages contained within it. We do > > this for several reasons: > > > > 1. To ensure that we don't have any packages containing licenses that do > > not meet the Fedora licensing standards. > > I take that opportunity to ask a few questions for cases that seem > unclear to me. > > Do we consider files with copyright or a mention of an author and no > license to be problematic, or to be covered by the main license (if such > a thing exists)? Yes. In those cases, we're noting that the license is not listed in the source code, and we'll be informing upstream of this, and suggesting that they correct this. > Files copyrighted, but without license should be > considered to be under a restrictive license (no modification nor > redistribution). However, when the remaining of the package is > consistently under a given license and the authors are the same I > consider that the notice is missing, but that the main license cover the > files. Is it right? This is almost certainly the intent of the upstream author, who probably thinks it is sufficient to either just say "This code is GPL" or dump a copy of COPYING in the top-level buildroot. Is that legally sufficient? Its a gray area. We'd much rather have them include the license in at least some part of the source code, or have the source code say something like /* This code is under the GPL, see full text of license in COPYING. */ > Do we consider files with incomplete license notice (when a complete > notice exists, like for the GPL) to be problematic? Problematic, yes. Cause for removal from Fedora? No. ~spot From fedora at leemhuis.info Wed Jan 24 14:26:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 24 Jan 2007 15:26:46 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169461780.3329.12.camel@shalil.farsiweb.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> Message-ID: <45B76CA6.20903@leemhuis.info> Roozbeh Pournader schrieb: > On Sat, 2007-01-20 at 17:59 +0100, Thorsten Leemhuis wrote: >> === Disputes === >> [...] > > I don't know what is it, but this part makes me worry to some degree. It > looks like too much bureaucracy, The first para ended with: "There are no hard rules how maintainers should solve those disagreements. But in practice it should be something like this:". In other words: those were only suggestions. I'll clarify the wording a bit to make that more clear. > [...] > I also tend to think that the suggested mechanism will push us toward a > democracy to some degree instead of a meritocracy. I guess I should bite > the bullet and say it: The bureaucracy looks too much like Debian to me. I don't want to much bureaucracy, but some is needed. If you have special points you'd like to see improved/changed in the proposal please be more specific, send me a diff (preferred), or write a proposal please. > I quite like other parts of the proposal, and the only other part that > makes me worry a little is the three-maintainers-per-package part. I > can't say much about other packages, with the kind of packages that I > am/was involved in maintaining, two is usually quite enough. Three or > more maintainers will only make things more complicated. I think three it the best middle ground. CU thl From fedora at leemhuis.info Wed Jan 24 14:47:51 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 24 Jan 2007 15:47:51 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169485885.6687.48.camel@localhost.localdomain> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <1169485885.6687.48.camel@localhost.localdomain> Message-ID: <45B77197.4000005@leemhuis.info> Toshio Kuratomi schrieb: > On Mon, 2007-01-22 at 13:59 +0330, Roozbeh Pournader wrote: >> On Sat, 2007-01-20 at 17:59 +0100, Thorsten Leemhuis wrote: >>> === Disputes === >>> [...] >> I also tend to think that the suggested mechanism will push us toward a >> democracy to some degree instead of a meritocracy. I guess I should bite >> the bullet and say it: The bureaucracy looks too much like Debian to me. > There needs to be a dispute policy of some kind, though. Actually, that probably should be a general policy, independent of the comaintainership stuff. But I mentioned it there for now until we have one, as it seemed the right place. > [...] >> I quite like other parts of the proposal, and the only other part that >> makes me worry a little is the three-maintainers-per-package part. I >> can't say much about other packages, with the kind of packages that I >> am/was involved in maintaining, two is usually quite enough. Three or >> more maintainers will only make things more complicated. > > I read that as two maintainers (one primary, one co-maintainer) but thl > would need to clarify. Three in total for all supported dists [all would mean F(current), F(current-1), F(devel) and EPEL] and two per release. > In general, I think having more co-maintainers > would be beneficial to most packages. Strongly agreed. Actually for *my* packages I consider (not more yet) even a more free, wiki-style approach. E.g. something like "if you think something should be fixed, feel free to fix it in cvs. But please leave building the packages and major updates up to the maintainers" > thl outlines the benefits in the > policy draft. The disadvantage is the increased chance of disputes > between maintainers. We can at any time adjust the policy if people are unhappy with it (e.g. if it results in to many disputes). CU thl From fedora at leemhuis.info Wed Jan 24 15:29:06 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 24 Jan 2007 16:29:06 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <20070122193239.GB26694@nostromo.devel.redhat.com> References: <45B24A5E.9050207@leemhuis.info> <20070122193239.GB26694@nostromo.devel.redhat.com> Message-ID: <45B77B42.6020908@leemhuis.info> Bill Nottingham schrieb: > Thorsten Leemhuis (fedora at leemhuis.info) said: >> Fedora Extras for a long time wanted to have more than one maintainer >> per package as that has several advantages (see below). But until now we >> never had a policy how it should look like and how it those maintainers >> should work and interact. I took some time and wrote something up. >> Please comment! > I suspect finding three people that care about every package is going > to be hard, although I'd love to be proven wrong. Note that there are a lot of "should" or "the goal is" in the policy, and not "must have". So if there is not interest in a package its fine if there is only one maintainer for a package. I'll add this to the proposal: Nobody can be forced to maintain packages, so sometimes it might happen that a package has only one maintainer. That's fine, but the maintainer should now and then ask other contributors and also interested users to become co-maintainers -- that will get more people involved into the project and is better for the package and the project as a whole. > My main comment is it does seem like a lot of policy/procedures around > something that might be better to grow organically - a lot of the should/ > shall seems better suited to be 'are encouraged to'. Well, co-maintainership can be used for a long time (okay, bugzilla was broken for a long time, too), but a lot of people did not care much about it (in other words: it did not grow organically). Some people also seem to have a "this is my package, don't touch it" attitude, which is not good for the project as a whole. Thus I think the benefits are worth the procedures. And as I said: there are a lot of "should" or "the goal is" in the policy, and not "must have". >> All packages in Fedora Extras shall normally be maintained by a group of >> maintainers. That has several benefits; maintainers for example can >> watch and help each other. One maintainer further can fix important bugs >> (security, data-corruption, whatever!) even when the other maintainer(s) >> are offline (traveling, sleeping, whatever). > *cough* Upstream! *cough* -ECantFollow The Fedora maintainer still needs to import a new upstream version that fixes stuff. I'm all for having upstream maintainers as co-maintainers that can commit and build updates if there is a strong need to, but most often that won't be the case. >> Packages primary maintained by Red Hat employees should >> have at least one co-maintainer from the community. They should try to >> hand over certain regular maintain task to the the community; that >> should help getting the community involved everywhere and to get some >> load of the Red Hat employees so they can focus on more imporant things >> -- that's best for both sides! > How is this different than the rest of the policy? One community, > maintainers are maintainers, co-maintainers are co-maintainers. Trying > to draft specific policy based on locality seems like a bad idea to > me. I hope that para can vanish over time, but I think it's worth it for now, to make sure the community gets involved everywhere so the differences between red hat and community members then will hopefully nearly vanish. >> The primary maintainer can set individual guidelines what his >> co-maintainers are allowed and what not; be has to put them into the >> wiki at Packages//MaintainerRules . A hint to that page >> should be as comment on the top of the spec file. > Seems overkill to me, leads to dependencies in system A (package SCM) > to absolute paths in system B (wiki), etc. > (comemnts about dispute resolution in another mail) I fail to see a suggestion what you would like to see. I considered to use the VCS for the MaintainerRules file, but my feeling was that the wiki was the better place for it. BTW, having a "Packages/" for most of our packages or another form of easy to modify package webinterface (I'd prefer a mix of wiki and automatically generated pages) is something we should work towards in the longer term in any case. >> SIGs can't become co-maintainers per-se. Rather they should observe the >> packages or make sure that SIG members are co-maintainers. > Leads to a big grey area w.r.t 5/10 maintainers vs. a SIG. Not sure if I can follow you here. >> We require the PackageDB and some other technical things to really make >> above policy possible. Until we have those it works like this: >> [...] > Slight counter proposal: [...] I fail to see the exact differences. The outcome seems to be mostly the same, you just seem to say it with different words. Or what did I miss? >> * all packages should have at least two co-maintainers > See above. TBH, I don't see that we're drowning in maintainers That, IMHO, is the a big problem with the current scheme and the reasons why I'm driving this forward. If I today would want to become a packager for Fedora I'd not know how. All the stuff that I use is packaged already. I could package something I don't use else to get involved, but that's not really a good way IMHO. With the new scheme I can ask packager foo: "Hey, you maintain a lot of packages. I'd want to become a packager, too. Can I help you as co-maintainer for package bar to get more involved?" Yes, we need some other stuff (PackageDB, Alternative paths of membership) to make that work, but most of it is in the planing stages already. > - how > is someone that co-maintains 50 packages better than someone that > maintains 20? That why there is the "Don't maintain too many packages" section. I extended it a bit to make it obvious that co-maintaining a lot of packagers is a bad idea, too. CU thl From fedora at leemhuis.info Wed Jan 24 15:32:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 24 Jan 2007 16:32:11 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B24A5E.9050207@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> Message-ID: <45B77BFB.1090701@leemhuis.info> Hi all! Thorsten Leemhuis schrieb: > Fedora Extras for a long time wanted to have more than one maintainer > per package as that has several advantages (see below). But until now we > never had a policy how it should look like and how it those maintainers > should work and interact. I took some time and wrote something up. > > P.S.: This stuff (and some more details) can be found in the wiki at > http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership A slightly updated/enhanced version can be found in the wiki at above URL now. Diff against previous: http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership?action=diff&rev2=10&rev1=8 CU thl From roozbeh at farsiweb.info Wed Jan 24 15:40:29 2007 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Wed, 24 Jan 2007 19:10:29 +0330 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B77197.4000005@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <1169485885.6687.48.camel@localhost.localdomain> <45B77197.4000005@leemhuis.info> Message-ID: <1169653229.9308.31.camel@shalil.farsiweb.info> On Wed, 2007-01-24 at 15:47 +0100, Thorsten Leemhuis wrote: > > I read that as two maintainers (one primary, one co-maintainer) but thl > > would need to clarify. > > Three in total for all supported dists [all would mean F(current), > F(current-1), F(devel) and EPEL] and two per release. Another question rises here. What if some package doesn't find enough maintainers? Will the owner be required to choose some people from the volunteers available? What if there isn't even enough volunteers? > Strongly agreed. Actually for *my* packages I consider (not more yet) > even a more free, wiki-style approach. E.g. something like "if you think > something should be fixed, feel free to fix it in cvs. But please leave > building the packages and major updates up to the maintainers" Hmmm. It seems that instead of package-based maintenance policies, we will be going to have mostly owner-based policies, that is each owner applying the same policies to all of his packages. This may mean that the recommendations on how to keep the info should be changed in some ways, like putting the information on the owner's wiki page, instead of the package's. Also, we may want to have a HACKING file or something like that in the CVS repository, instead of putting the info in the wiki. Roozbeh From roozbeh at farsiweb.info Wed Jan 24 15:45:08 2007 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Wed, 24 Jan 2007 19:15:08 +0330 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B76CA6.20903@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> Message-ID: <1169653508.9308.37.camel@shalil.farsiweb.info> On Wed, 2007-01-24 at 15:26 +0100, Thorsten Leemhuis wrote: > I don't want to much bureaucracy, but some is needed. If you have > special points you'd like to see improved/changed in the proposal please > be more specific, send me a diff (preferred), or write a proposal please. Not really. I was mostly telling what I felt. I can't say I know good ways to fix it, but I would prefer more simplified policies, so people could recall them without thinking instead of looking them up each time. Anyway, thanks again for all the work. I was more expecting a controversial proposal on such a subject, but you wrote a very solid one. It's great work. Roozbeh From fedora at leemhuis.info Wed Jan 24 15:57:58 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 24 Jan 2007 16:57:58 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169653508.9308.37.camel@shalil.farsiweb.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <1169653508.9308.37.camel@shalil.farsiweb.info> Message-ID: <45B78206.1080801@leemhuis.info> Roozbeh Pournader schrieb: > On Wed, 2007-01-24 at 15:26 +0100, Thorsten Leemhuis wrote: >> I don't want to much bureaucracy, but some is needed. If you have >> special points you'd like to see improved/changed in the proposal please >> be more specific, send me a diff (preferred), or write a proposal please. > Not really. I was mostly telling what I felt. BTW, and more in general then on this specific topic: I also fear that we sooner or later have to much "bureaucracy". That probably happens over time always in projects like Fedora. Thus we now and then should revisit and/or slightly adjust all the policies. That's btw a reasons why I think the policies should not be protected by ACLs in the wiki. > I can't say I know good > ways to fix it, but I would prefer more simplified policies, so people > could recall them without thinking instead of looking them up each time. Well, that's what the digest is for IMHO. Reading it should be enough normally (e.g. for new contributors). The other stuff is more a "if you want to now the details or hit a complex situation". Cu thl From fedora at leemhuis.info Wed Jan 24 16:01:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 24 Jan 2007 17:01:53 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169653229.9308.31.camel@shalil.farsiweb.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <1169485885.6687.48.camel@localhost.localdomain> <45B77197.4000005@leemhuis.info> <1169653229.9308.31.camel@shalil.farsiweb.info> Message-ID: <45B782F1.1030102@leemhuis.info> Roozbeh Pournader schrieb: > On Wed, 2007-01-24 at 15:47 +0100, Thorsten Leemhuis wrote: >>> I read that as two maintainers (one primary, one co-maintainer) but thl >>> would need to clarify. >> Three in total for all supported dists [all would mean F(current), >> F(current-1), F(devel) and EPEL] and two per release. > Another question rises here. What if some package doesn't find enough > maintainers? Will the owner be required to choose some people from the > volunteers available? What if there isn't even enough volunteers? See one of the other mails/the enhanced proposal. >> Strongly agreed. Actually for *my* packages I consider (not more yet) >> even a more free, wiki-style approach. E.g. something like "if you think >> something should be fixed, feel free to fix it in cvs. But please leave >> building the packages and major updates up to the maintainers" > Hmmm. It seems that instead of package-based maintenance policies, we > will be going to have mostly owner-based policies, that is each owner > applying the same policies to all of his packages. This may mean that > the recommendations on how to keep the info should be changed in some > ways, like putting the information on the owner's wiki page, instead of > the package's. Hmmm, I think per package is the better approach. > Also, we may want to have a HACKING file or something like that in the > CVS repository, instead of putting the info in the wiki. Still unsure. I still prefer the wiki a bit over CVS. Other opinions? Or could we use the PackageDB for this sort of stuff, too? CU thl From j.w.r.degoede at hhs.nl Wed Jan 24 16:16:49 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 24 Jan 2007 17:16:49 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B76CA6.20903@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> Message-ID: <45B78671.8050603@hhs.nl> Hi all, Just jumping into the discussion here, I haven't followed this from the start as I was busy with other stuff, so I just started reading the proposal on the wiki. I have a couple of problems with the current text, which I will list most important ones first: 1) "People owning a lot of packages are encouraged to hand over maintainership to other maintainers with less packages. That should share the load between different people and result in better overall package quality, as people that maintain only a small number of packages often take more care of them than those with a lot of packages." WHHAAAATTT??? This is absurd, so people with a lot of dedication to the project supposedly are doing a worse job then Johnny oneshot / twoshot? (apologies to all those with only a few packages who do a good job!) This is really absurd, according the the Status page I have 98 packages in FE, yet I have 0 open bugzilla tickets against any of my 98 packages, regularly help closing other peoples bugs, and have 0 cleanups needed on the Status page either. I feel offended, really I do! Please remove this text ASAP! 2) "all packages should have at least two co-maintainers" Already discussed in this thread, but I think the text about this should be removed completely too. It will be nearly impossible to find co-maintainers for many of my packages. Quite a few of them I picked up because their original maintainers orphaned them for various reasons. I fully welcome quality co-maintainers who volunteer, but I will spend 0 time actively searching for co-maintainers. 3) "The primary maintainer can set individual guidelines what his co-maintainers are allowed and what not; be has to put them into the wiki at Packages//MaintainerRules . A hint to that page should be as comment on the top of the spec file." This belongs in the VCS or in the package database, why don't put owners.list on the wiki too? My main interface when doing FE work is an xterm with a text-editor and a browser window with bugzilla, thats 2 different interfaces already I don't want a third, thinking about this I believe that for the sake of keeping information together maybe other per package info should be in a textfile in the VCS-dir of the package too. Say an owners.txt file per package-dir? 4) All in all the whole proposol reads as a vision of how things should ideally be and not as a proposal for a policy at all, a policy states rules and procedures, this is not a policy, this is a piece of prosa, a view of how things should be. And at that I believe a view of how things should be according to a small group of people, not how things should be according to the larger community, but thats just my opinion. When looking at this as a policy, then the only real policy in there is: a) "Coordination between maintainers" b) "Disputes" c) "Intermediate solution" The rest is a vision statement, not a policy. Please put this in 2 different documents. Regards, Hans From chris.stone at gmail.com Wed Jan 24 16:30:52 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 24 Jan 2007 08:30:52 -0800 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B78671.8050603@hhs.nl> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> Message-ID: On 1/24/07, Hans de Goede wrote: > package quality, as people that maintain only a small number of packages > often take more care of them than those with a lot of packages." HAHAH yea, I totally disagree 100%. I havn't been following this discussion either, but this above statement is totally absurd. I too mantain many packages (50+ and growing) and do a far better job at it than many people with just a couple packages. I currently have zero bugzilla entries open for my packages and no outstanding QA issues. I have to ask, whomever wrote this, how many packages do _you_ maintain? And do you not take care of your own packages? LOL. From notting at redhat.com Wed Jan 24 18:06:45 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 Jan 2007 13:06:45 -0500 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B782F1.1030102@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <1169485885.6687.48.camel@localhost.localdomain> <45B77197.4000005@leemhuis.info> <1169653229.9308.31.camel@shalil.farsiweb.info> <45B782F1.1030102@leemhuis.info> Message-ID: <20070124180645.GA6105@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > > Also, we may want to have a HACKING file or something like that in the > > CVS repository, instead of putting the info in the wiki. > > Still unsure. I still prefer the wiki a bit over CVS. Other opinions? Or > could we use the PackageDB for this sort of stuff, too? In the package is easiest for obvious maintenance - packagedb probably shouldn't be required to carry free-form information. Also, most of the stuff should be obvious. Bill From notting at redhat.com Wed Jan 24 18:31:07 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 Jan 2007 13:31:07 -0500 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B77B42.6020908@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> <20070122193239.GB26694@nostromo.devel.redhat.com> <45B77B42.6020908@leemhuis.info> Message-ID: <20070124183107.GB6105@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > >> All packages in Fedora Extras shall normally be maintained by a group of > >> maintainers. That has several benefits; maintainers for example can > >> watch and help each other. One maintainer further can fix important bugs > >> (security, data-corruption, whatever!) even when the other maintainer(s) > >> are offline (traveling, sleeping, whatever). > > *cough* Upstream! *cough* > > -ECantFollow > > The Fedora maintainer still needs to import a new upstream version that > fixes stuff. I'm all for having upstream maintainers as co-maintainers > that can commit and build updates if there is a strong need to, but most > often that won't be the case. Generally, the bugfixing should be done upstream, not local to the package. If there's not a lot of patching *specific* to the package, most of the opportunities for conflict should go away. > >> Packages primary maintained by Red Hat employees should > >> have at least one co-maintainer from the community. They should try to > >> hand over certain regular maintain task to the the community; that > >> should help getting the community involved everywhere and to get some > >> load of the Red Hat employees so they can focus on more imporant things > >> -- that's best for both sides! > > How is this different than the rest of the policy? One community, > > maintainers are maintainers, co-maintainers are co-maintainers. Trying > > to draft specific policy based on locality seems like a bad idea to > > me. > > I hope that para can vanish over time, but I think it's worth it for > now, to make sure the community gets involved everywhere so the > differences between red hat and community members then will hopefully > nearly vanish. OK, I'm getting tired of arguing this point with you. Your words say it very clearly - 'make sure the community gets involved', 'differences between red hat and community members'. What those words say to me is that you don't think people in Red Hat are now, or can be part of the community - that the community is always entirely separate. And, frankly, I find that offensive. If I want to co-maintain some game that Hans maintains, then I talk to him, and it's irrelevant w.r.t. who signs his or my paycheck. If Josh wants to co-maintain vte, then he talks to Behdad (or whomever), and it's irrelevant who signs their paychecks. If there are trust or other issues with how things are maintained, let's hear them. But I'm not going to have some policy that mandates actions based on some caste system separating maintainers into different camps. > BTW, having a "Packages/" for most of our packages or > another form of easy to modify package webinterface (I'd prefer a mix of > wiki and automatically generated pages) is something we should work > towards in the longer term in any case. Sure, but this seems better suited for a user-level interface, not a developer-level interface. > >> SIGs can't become co-maintainers per-se. Rather they should observe the > >> packages or make sure that SIG members are co-maintainers. > > Leads to a big grey area w.r.t 5/10 maintainers vs. a SIG. > > Not sure if I can follow you here. You start out with 2 people dealing with all of the KDE packages. Eventually, you keep adding people and you now have 10 co-maintainers for all of KDE - it's now a de-facto SIG. So, I don't think saying that SIGs can't be co-maintainers is the right answer, as I expect SIGs will grow out of co-maintainership. Make more sense? > >> We require the PackageDB and some other technical things to really make > >> above policy possible. Until we have those it works like this: > >> [...] > > Slight counter proposal: [...] > I fail to see the exact differences. The outcome seems to be mostly the > same, you just seem to say it with different words. Or what did I miss? Moving co-maintainers to ACLs vs. owners.list. Could go in owners.list in the *owner* field, but that might break someone elses tools. (Yes, I'm basing this on the code that's going to be deployed to get the ACLs and notification set up.) Bill From skvidal at linux.duke.edu Wed Jan 24 18:40:54 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 24 Jan 2007 13:40:54 -0500 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B78671.8050603@hhs.nl> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> Message-ID: <1169664054.21801.9.camel@cutter> Comaintainership - an alternate policy suggestion: 1. two(or more) people maintain the package 2. they talk to each other if there is a conflict 3. if there is a big conflict and they can't work it out, they talk to fesco for resolution 4. no more rules after this are needed Seriously - why not just make it simple and have all other things resolved like we would resolve normal conflicts? Why all the overhead of rules early? -sv From jkeating at redhat.com Wed Jan 24 18:58:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Jan 2007 13:58:05 -0500 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169664054.21801.9.camel@cutter> References: <45B24A5E.9050207@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> Message-ID: <200701241358.06166.jkeating@redhat.com> On Wednesday 24 January 2007 13:40, seth vidal wrote: > Comaintainership - an alternate policy suggestion: > > 1. two(or more) people maintain the package > 2. they talk to each other if there is a conflict > 3. if there is a big conflict and they can't work it out, they talk to > fesco for resolution > 4. no more rules after this are needed > > > Seriously - why not just make it simple and have all other things > resolved like we would resolve normal conflicts? > > Why all the overhead of rules early? +1 KISS -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jamatos at fc.up.pt Wed Jan 24 18:55:39 2007 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Wed, 24 Jan 2007 18:55:39 +0000 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169664054.21801.9.camel@cutter> References: <45B24A5E.9050207@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> Message-ID: <200701241855.39763.jamatos@fc.up.pt> On Wednesday 24 January 2007 6:40:54 pm seth vidal wrote: > Comaintainership - an alternate policy suggestion: > > 1. two(or more) people maintain the package > 2. they talk to each other if there is a conflict > 3. if there is a big conflict and they can't work it out, they talk to > fesco for resolution > 4. no more rules after this are needed > > > Seriously - why not just make it simple and have all other things > resolved like we would resolve normal conflicts? I agree. The reason why co-maintainership is not more used is because the tools don't help, just like programming Object Oriented code in C. Once the tools are in place I think that even without any strict policy in place we will see this as the common rule. What should be made clear is that this behaviour is encouraged. > Why all the overhead of rules early? The funny part is that in order to explain the reasons there was the need to use generalizations, and we all know how unfair generalizations can be. I agree with Bill in the reference to Red Hat, I think that we could in the extreme case to replace the reference by University guys (gals), there are lots of us with .edu (or similar) addresses and we all know how difficult we are to deal with... ;-) Similarly when I look to the people with the largest number of packages I don't think about complaints. :-) So, please let us keep it simple, just say that co-maintainership is encouraged, have the tools in place to deal with it. Pretty please. :-) > -sv -- Jos? Ab?lio From gdk at redhat.com Wed Jan 24 18:55:08 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 24 Jan 2007 13:55:08 -0500 (EST) Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169664054.21801.9.camel@cutter> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> Message-ID: +1. Actually, +10000000. Let's start simple, with the assumption that package maintainers will trust one another. If more complex policies prove to be necessary, let's let experience prove that to us. This will also allow us to shape a policy based on our experience with *actual* issues, rather than fears about potential issues. --g On Wed, 24 Jan 2007, seth vidal wrote: > > Comaintainership - an alternate policy suggestion: > > 1. two(or more) people maintain the package > 2. they talk to each other if there is a conflict > 3. if there is a big conflict and they can't work it out, they talk to > fesco for resolution > 4. no more rules after this are needed > > > Seriously - why not just make it simple and have all other things > resolved like we would resolve normal conflicts? > > Why all the overhead of rules early? > > -sv > > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From rdieter at math.unl.edu Wed Jan 24 18:59:35 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 24 Jan 2007 12:59:35 -0600 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <200701241855.39763.jamatos@fc.up.pt> References: <45B24A5E.9050207@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <200701241855.39763.jamatos@fc.up.pt> Message-ID: <45B7AC97.1070004@math.unl.edu> Jos? Matos wrote: > So, please let us keep it simple, just say that co-maintainership is > encouraged, have the tools in place to deal with it. Pretty please. :-) co-maintainership is good, mm-kay? -- Rex From fedora at leemhuis.info Wed Jan 24 19:01:06 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 24 Jan 2007 20:01:06 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <20070124183107.GB6105@nostromo.devel.redhat.com> References: <45B24A5E.9050207@leemhuis.info> <20070122193239.GB26694@nostromo.devel.redhat.com> <45B77B42.6020908@leemhuis.info> <20070124183107.GB6105@nostromo.devel.redhat.com> Message-ID: <45B7ACF2.9070405@leemhuis.info> Bill Nottingham schrieb: > Thorsten Leemhuis (fedora at leemhuis.info) said: >>>> All packages in Fedora Extras shall normally be maintained by a group of >>>> maintainers. That has several benefits; maintainers for example can >>>> watch and help each other. One maintainer further can fix important bugs >>>> (security, data-corruption, whatever!) even when the other maintainer(s) >>>> are offline (traveling, sleeping, whatever). >>> *cough* Upstream! *cough* >> -ECantFollow >> The Fedora maintainer still needs to import a new upstream version that >> fixes stuff. I'm all for having upstream maintainers as co-maintainers >> that can commit and build updates if there is a strong need to, but most >> often that won't be the case. > Generally, the bugfixing should be done upstream, not local to the > package. If there's not a lot of patching *specific* to the package, > most of the opportunities for conflict should go away. I think we are talking on cross purposes here. By "fix important bugs" I meant "update to a new upstream release, test locally, commit to cvs, build and get it out". I'll clarify the wording to make that more clear. >>>> Packages primary maintained by Red Hat employees should >>>> have at least one co-maintainer from the community. They should try to >>>> hand over certain regular maintain task to the the community; that >>>> should help getting the community involved everywhere and to get some >>>> load of the Red Hat employees so they can focus on more imporant things >>>> -- that's best for both sides! >>> How is this different than the rest of the policy? One community, >>> maintainers are maintainers, co-maintainers are co-maintainers. Trying >>> to draft specific policy based on locality seems like a bad idea to >>> me. >> I hope that para can vanish over time, but I think it's worth it for >> now, to make sure the community gets involved everywhere so the >> differences between red hat and community members then will hopefully >> nearly vanish. > > > [...] > Okay, I removed that para. >> BTW, having a "Packages/" for most of our packages or >> another form of easy to modify package webinterface (I'd prefer a mix of >> wiki and automatically generated pages) is something we should work >> towards in the longer term in any case. > Sure, but this seems better suited for a user-level interface, > not a developer-level interface. So, HACKING file in CVS? >>>> SIGs can't become co-maintainers per-se. Rather they should observe the >>>> packages or make sure that SIG members are co-maintainers. >>> Leads to a big grey area w.r.t 5/10 maintainers vs. a SIG. >> Not sure if I can follow you here. > You start out with 2 people dealing with all of the KDE packages. > Eventually, you keep adding people and you now have 10 co-maintainers > for all of KDE - it's now a de-facto SIG. So, I don't think saying > that SIGs can't be co-maintainers is the right answer, as I expect > SIGs will grow out of co-maintainership. Make more sense? What I fear is this: You have a number of foo packages. Foo-SIG is by default Co-maintainer for all of them. New member bar (sponsored three days ago) gets member of SIG foo (that *until now* often is nothing more then saying "I want" and you become accepted). Now he has access to all Foo-Packages. I think the solution I proposed (SIGs can't become co-maintainers) is the best *for now*. >>>> We require the PackageDB and some other technical things to really make >>>> above policy possible. Until we have those it works like this: >>>> [...] >>> Slight counter proposal: [...] >> I fail to see the exact differences. The outcome seems to be mostly the >> same, you just seem to say it with different words. Or what did I miss? > > Moving co-maintainers to ACLs vs. owners.list. Could go in owners.list > in the *owner* field, but that might break someone elses tools. > > (Yes, I'm basing this on the code that's going to be deployed > to get the ACLs and notification set up.) Hmmm. That would mean that we need to wait yet again for something. No, I'd like to avoid that. Cu thl From fedora at leemhuis.info Wed Jan 24 19:08:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 24 Jan 2007 20:08:45 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169664054.21801.9.camel@cutter> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> Message-ID: <45B7AEBD.90607@leemhuis.info> seth vidal schrieb: > Comaintainership - an alternate policy suggestion: > > 1. two(or more) people maintain the package > 2. they talk to each other if there is a conflict > 3. if there is a big conflict and they can't work it out, they talk to > fesco for resolution > 4. no more rules after this are needed > > Seriously - why not just make it simple and have all other things > resolved like we would resolve normal conflicts? That's basically what we always had. Only a small number of people used it. > Why all the overhead of rules early? Well, my proposal is not that much more comlicated: All packages in Fedora Extras shall normally be maintained by a group of maintainers. Each package normally should have at least three maintainers in total. There is one primary maintainer and a primary maintainer per distribution release (both often will be identical); he should have at least one co-maintainer per release. Maintainers and sponsors are encouraged to use co-maintainership to educate new contributors an help them getting involved and integrated into the Project. Maintainers should hand over packages to co-maintainers when they have lots of packages to improve the quality, share the load and get people involved. All the other stuff is just meant "why we need it with some more details" CU th From jkeating at redhat.com Wed Jan 24 19:18:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Jan 2007 14:18:00 -0500 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B7AEBD.90607@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> Message-ID: <200701241418.01226.jkeating@redhat.com> On Wednesday 24 January 2007 14:08, Thorsten Leemhuis wrote: > All packages in Fedora Extras shall normally be maintained by a group of > maintainers. Each package normally should have at least three > maintainers in total. There is one primary maintainer and a primary > maintainer per distribution release (both often will be identical); he > should have at least one co-maintainer per release. This feels like we're dictating how people should manage their packages. Why should EVERY package have more than one maintainer? There are some pretty simple packages out there, does it really need 3? Do we really want to tell everybody that we don't trust just them, we need to trust 3 of them? Why is this necessary? > Maintainers and sponsors are encouraged to use co-maintainership to > educate new contributors an help them getting involved and integrated > into the Project. This above paragraph is all you need (and the tools to easily support this) > Maintainers should hand over packages to > co-maintainers when they have lots of packages to improve the quality, > share the load and get people involved. again, dictating. You're saying that just because you own more than a few packages, you're automatically lowering the quality of those packages, or you automatically can't handle the load. This is a bad and very unfriendly assumption to make. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Jan 24 19:21:01 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 24 Jan 2007 20:21:01 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B7AEBD.90607@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> Message-ID: <45B7B19D.4060107@leemhuis.info> Thorsten Leemhuis schrieb: > seth vidal schrieb: >> Why all the overhead of rules early? In addition to my other mail: some of my other stuffs gives new people a chance to find their way into the project. That what I'd like to see with co-maintainers -- the current sponsorship process does not scale forever (as I said: I for one would today not find my way into the project -- all the sutff I know about is packaged already and your proposal requires people are already sponsored). I think we've already reached the point where we need to get new people into the game via co-maintainership. At the same time people that proofed to be capable should get higher in the game and get involved in the more important and more complicated stuff now that Core and Extras merge. CU thl From gdk at redhat.com Wed Jan 24 19:20:57 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Wed, 24 Jan 2007 14:20:57 -0500 (EST) Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <200701241418.01226.jkeating@redhat.com> References: <45B24A5E.9050207@leemhuis.info> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> <200701241418.01226.jkeating@redhat.com> Message-ID: On Wed, 24 Jan 2007, Jesse Keating wrote: > again, dictating. You're saying that just because you own more than a few > packages, you're automatically lowering the quality of those packages, or you > automatically can't handle the load. This is a bad and very unfriendly > assumption to make. +1. The fears: * Packages with single maintainers are more vulnerable to bitrot; * If default policy is not multiple packagers, people might start to feel like they're better going it alone. The likely reality, as I see it: * It will become obvious when a package needs additional love, especially if we can build some simple tools: for instance, a daily report on the 10 packages with the highest bug rates; * People will, in general, be open to help with troublesome packages; * FESCO will be an effective body in arbiting any disputes. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From jkeating at redhat.com Wed Jan 24 19:39:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Jan 2007 14:39:56 -0500 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B7B19D.4060107@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> <45B7AEBD.90607@leemhuis.info> <45B7B19D.4060107@leemhuis.info> Message-ID: <200701241439.57147.jkeating@redhat.com> On Wednesday 24 January 2007 14:21, Thorsten Leemhuis wrote: > I think we've already reached the point where we need to get new people > into the game via co-maintainership. At the same time people that > proofed to be capable should get higher in the game and get involved in > the more important and more complicated stuff now that Core and Extras > merge. This is a problem though, as I don't want to hand over access to my package to somebody who is fresh to the scene. I'd like to have seen them do their own packaging for a while and know that they won't make silly mistakes with my packages. Maintainer shadowing perhaps? Watch what I do, ask questions along the way, learn, grow, etc...? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Jan 24 20:26:08 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 24 Jan 2007 21:26:08 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <200701241439.57147.jkeating@redhat.com> References: <45B24A5E.9050207@leemhuis.info> <45B7AEBD.90607@leemhuis.info> <45B7B19D.4060107@leemhuis.info> <200701241439.57147.jkeating@redhat.com> Message-ID: <45B7C0E0.4030203@leemhuis.info> Jesse Keating schrieb: > On Wednesday 24 January 2007 14:21, Thorsten Leemhuis wrote: >> I think we've already reached the point where we need to get new people >> into the game via co-maintainership. At the same time people that >> proofed to be capable should get higher in the game and get involved in >> the more important and more complicated stuff now that Core and Extras >> merge. > This is a problem though, as I don't want to hand over access to my package to > somebody who is fresh to the scene. Nobody requested that. > I'd like to have seen them do their own > packaging for a while and know that they won't make silly mistakes with my > packages. > > Maintainer shadowing perhaps? Watch what I do, ask questions along the way, > learn, grow, etc...? That in the proposal already. Here is a slightly modified variant of a relevant section. New contributors that seems to be willing to get more involved could become a co-maintainer for a package without build permissions. Educate those co-maintainers a bit and tell them about the backgrounds of the package and how it was maintained in the past. Then let the co-maintainer do some work and watch him. If he does a good job give him more responsibilities over time and while stepping back from it more and more over time. At some point hand over the job as primary (release) maintainer to the co-maintainer when he did the job fine; become a co-maintainer for the package at the same time. If the new primary maintainer continues to do a good job consider stepping away completely to yet make more room for a new packager to get involved. Insert a "let the new co-maintainer watch the doings for some time" if you want. But I don't think that will be needed if the new co-maintainer does not get build permissions in the beginning. CU thl From jwboyer at jdub.homelinux.org Wed Jan 24 19:37:50 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 24 Jan 2007 13:37:50 -0600 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: References: <45B24A5E.9050207@leemhuis.info> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> <200701241418.01226.jkeating@redhat.com> Message-ID: <1169667470.7011.77.camel@zod.rchland.ibm.com> On Wed, 2007-01-24 at 14:20 -0500, Greg Dekoenigsberg wrote: > > * It will become obvious when a package needs additional love, > especially if we can build some simple tools: for instance, a > daily report on the 10 packages with the highest bug rates; Um, no. Stay away from a metric like that. Otherwise stuff like the kernel will always be flagged. Packages are only as good as their upstream. What you're really looking for is packages that are neglected. That different from packages that are buggy but have a responsive maintainer. josh From peter at thecodergeek.com Wed Jan 24 21:12:35 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 24 Jan 2007 13:12:35 -0800 (PST) Subject: Policy on Reviewing Packages In Preparation for Core/Extras Merge? Message-ID: <24515.65.223.36.19.1169673155.squirrel@thecodergeek.com> Hi, all. I'd like to help out where I can with the merge of Core/Extras; and was wondering what policy there is in terms of who is allowed to formally review and approve these packages (ones moving from Core to Extras/"Collection"). Is it the same as current Extras review guidelines (whereby any sponsored contributor can review/accept packages of others that do not need sponsoring); or is it something different? If so, how does it differ and why? Thanks for your time. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From jkeating at redhat.com Wed Jan 24 21:20:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Jan 2007 16:20:33 -0500 Subject: Policy on Reviewing Packages In Preparation for Core/Extras Merge? In-Reply-To: <24515.65.223.36.19.1169673155.squirrel@thecodergeek.com> References: <24515.65.223.36.19.1169673155.squirrel@thecodergeek.com> Message-ID: <200701241620.33372.jkeating@redhat.com> On Wednesday 24 January 2007 16:12, Peter Gordon wrote: > I'd like to help out where I can with the merge of Core/Extras; and was > wondering what policy there is in terms of who is allowed to formally > review and approve these packages (ones moving from Core to > Extras/"Collection"). > > Is it the same as current Extras review guidelines (whereby any sponsored > contributor can review/accept packages of others that do not need > sponsoring); or is it something different? If so, how does it differ and > why? IIRC it would be the same as Extras. I think a few of us were going to somewhat mass sponsor current Red Hat employed maintainers (given that they're currently maintaining Fedora packages) and taking responsibility for them. This should open it up for even more people to review the Core packages. Am I not remembering correctly? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Thu Jan 25 00:33:27 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 24 Jan 2007 19:33:27 -0500 Subject: Plan for tomorrows (20070125) FESCO meeting Message-ID: <1169685207.2121.8.camel@Chuck> Hi, I'm still working on getting Channel OPS on #fedora-meeting, so lets plan on having the meeting tomorrow in #fedora-extras on irc.freenode.org at 18:00 UTC. Please find below the list of topics that are likely to come up: /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update /topic FESCO-Meeting -- Opening Core -- jeremy/warren -- plans for the mass review seem to be really needed soon! /topic FESCO-Meeting -- Encourage co-maintainership -- all /topic FESCo-Meeting -- MISC -- the "syslog-ng patent problems" - Has RH legal resolved this? /topic FESCo-Meeting -- MISC -- kernel-naming - What did davej find out about this? /topic FESCo-Meeting -- MISC -- No meeting on 2007-02-01, due to folks traveling to FUDCon? /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCo meeting -- Maintainer Responsibility Policy -- bpepple /topic FESCo meeting -- Free discussion around Fedora Extras The meeting rules can be found at: http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines The schedule page in the wiki has more details on the individual topics; see http://www.fedoraproject.org/wiki/Extras/Schedule You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Christian.Iseli at licr.org Thu Jan 25 00:42:41 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 25 Jan 2007 01:42:41 +0100 Subject: Policy on Reviewing Packages In Preparation for Core/Extras Merge? In-Reply-To: <200701241620.33372.jkeating@redhat.com> References: <24515.65.223.36.19.1169673155.squirrel@thecodergeek.com> <200701241620.33372.jkeating@redhat.com> Message-ID: <20070125014241.3bae1152@ludwig-alpha.unil.ch> On Wed, 24 Jan 2007 16:20:33 -0500, Jesse Keating wrote: > IIRC it would be the same as Extras. I think a few of us were going to > somewhat mass sponsor current Red Hat employed maintainers (given that > they're currently maintaining Fedora packages) and taking responsibility for > them. This should open it up for even more people to review the Core > packages. > > Am I not remembering correctly? AFAIK, you remember correctly :-) C From bugs.michael at gmx.net Thu Jan 25 00:55:51 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 25 Jan 2007 01:55:51 +0100 Subject: Plan for tomorrows (20070125) FESCO meeting In-Reply-To: <1169685207.2121.8.camel@Chuck> References: <1169685207.2121.8.camel@Chuck> Message-ID: <20070125015551.27a9a95d.bugs.michael@gmx.net> On Wed, 24 Jan 2007 19:33:27 -0500, Brian Pepple wrote: > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora Extras" phase. /topic FESCO-Meeting -- Extras 7 preparation -- roadmap, broken deps, key packages (wxGTK2 issues solved?), rebuilds, FE7Target bug, mail to all package owners? From bpepple at fedoraproject.org Thu Jan 25 01:17:13 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 24 Jan 2007 20:17:13 -0500 Subject: Plan for tomorrows (20070125) FESCO meeting In-Reply-To: <20070125015551.27a9a95d.bugs.michael@gmx.net> References: <1169685207.2121.8.camel@Chuck> <20070125015551.27a9a95d.bugs.michael@gmx.net> Message-ID: <1169687833.3941.0.camel@Chuck> On Thu, 2007-01-25 at 01:55 +0100, Michael Schwendt wrote: > On Wed, 24 Jan 2007 19:33:27 -0500, Brian Pepple wrote: > > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora Extras" phase. > > /topic FESCO-Meeting -- Extras 7 preparation -- roadmap, broken deps, > key packages (wxGTK2 issues solved?), rebuilds, FE7Target bug, mail > to all package owners? Added to the schedule. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Thu Jan 25 02:31:21 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 24 Jan 2007 18:31:21 -0800 Subject: [Resolved] Re: Policy on Reviewing Packages In Preparation for Core/Extras Merge? In-Reply-To: <200701241620.33372.jkeating@redhat.com> References: <24515.65.223.36.19.1169673155.squirrel@thecodergeek.com> <200701241620.33372.jkeating@redhat.com> Message-ID: <1169692281.3534.1.camel@localhost> Great. Thanks for the information, Jesse and Christian. -- Peter Gordon (codergeek42) / FSF Associate Member #5015 GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 rc040203 at freenet.de Thu Jan 25 04:47:48 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 25 Jan 2007 05:47:48 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169664054.21801.9.camel@cutter> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> Message-ID: <1169700468.6751.267.camel@mccallum.corsepiu.local> On Wed, 2007-01-24 at 13:40 -0500, seth vidal wrote: > Comaintainership - an alternate policy suggestion: > > 1. two(or more) people maintain the package > 2. they talk to each other if there is a conflict > 3. if there is a big conflict and they can't work it out, they talk to > fesco for resolution What makes you think FESCO is qualified for this? Of cause there are "maintainer conflicts" where FESCO can help, but in many cases such conflicts originate from technical issues, one or more maintainers are unable to solve. In such cases, FESCO can't really help. > 4. no more rules after this are needed > Seriously - why not just make it simple and have all other things > resolved like we would resolve normal conflicts? ACK. > Why all the overhead of rules early? One problem I have with both THL's and your "ad-hoq proposal" above, is them both being strictly connected to "owners". This completely ignores "competence" and "knowledge domains". Therefore, instead of seeing a strict "owner"/"co-maintainers"-only scheme I'd like to see a multi-dimensional "maintainers' responsibility/privilege" system ("owners/co-maintainers" could be one dimension of such a system). E.g. a team of "packaging specialists" being granted "card blanche privileges" on "packaging issues" or a "team of perl/python/c/c ++/ specialists" being granted "card blanche privileges" on " issues" etc. At least to me, e.g. wrt. packaging, in obvious cases, this would spare me a lot of time, because bugzilla'ing takes much more time than directly fixing something. Ralf From j.w.r.degoede at hhs.nl Thu Jan 25 07:16:44 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 25 Jan 2007 08:16:44 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169664054.21801.9.camel@cutter> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> Message-ID: <45B8595C.7010905@hhs.nl> seth vidal wrote: > Comaintainership - an alternate policy suggestion: > > 1. two(or more) people maintain the package > 2. they talk to each other if there is a conflict > 3. if there is a big conflict and they can't work it out, they talk to > fesco for resolution > 4. no more rules after this are needed > > > Seriously - why not just make it simple and have all other things > resolved like we would resolve normal conflicts? > > Why all the overhead of rules early? > > -sv > +1, Me like KISS too. Regards, Hans From j.w.r.degoede at hhs.nl Thu Jan 25 07:21:29 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 25 Jan 2007 08:21:29 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <200701241418.01226.jkeating@redhat.com> References: <45B24A5E.9050207@leemhuis.info> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> <200701241418.01226.jkeating@redhat.com> Message-ID: <45B85A79.4050206@hhs.nl> Jesse Keating wrote: > On Wednesday 24 January 2007 14:08, Thorsten Leemhuis wrote: >> All packages in Fedora Extras shall normally be maintained by a group of >> maintainers. Each package normally should have at least three >> maintainers in total. There is one primary maintainer and a primary >> maintainer per distribution release (both often will be identical); he >> should have at least one co-maintainer per release. > > This feels like we're dictating how people should manage their packages. Why > should EVERY package have more than one maintainer? There are some pretty > simple packages out there, does it really need 3? Do we really want to tell > everybody that we don't trust just them, we need to trust 3 of them? Why is > this necessary? > +1, JK words the major part of my issues with this proposal well: "dictating how people should manage their packages" I don't like to be dictated, I don't like it at all! Also I find it funny that you (THL) first say: "Well, my proposal is not that much more complicated:" And then need a couple of very dense and hard to read paragraphs like the one quoted by JK above to explain your policy. >> Maintainers should hand over packages to >> co-maintainers when they have lots of packages to improve the quality, >> share the load and get people involved. > > again, dictating. You're saying that just because you own more than a few > packages, you're automatically lowering the quality of those packages, or you > automatically can't handle the load. This is a bad and very unfriendly > assumption to make. > +1 (But I made that clear already) Regards, Hans From triad at df.lth.se Thu Jan 25 08:10:51 2007 From: triad at df.lth.se (Linus Walleij) Date: Thu, 25 Jan 2007 09:10:51 +0100 (CET) Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169700468.6751.267.camel@mccallum.corsepiu.local> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <1169700468.6751.267.camel@mccallum.corsepiu.local> Message-ID: On Thu, 25 Jan 2007, Ralf Corsepius wrote: > E.g. a team of "packaging specialists" being granted "card blanche > privileges" on "packaging issues" (...) > > At least to me, e.g. wrt. packaging, in obvious cases, this would spare > me a lot of time, because bugzilla'ing takes much more time than > directly fixing something. You're right. And I notice that I also stated before that most of the Fedora core people (loosely defined term but definately including Ralf) are welcome to change and rebuild any of my packages at will. Actually the idea of strict ownership evades me, I would rather prefer a more Wiki-like attitude (once you have a Fedora ID account and PGP key) - "BE BOLD", "If in doubt, fix it". http://en.wikipedia.org/wiki/Wikipedia:Be_bold_in_updating_pages Linus From a.badger at gmail.com Thu Jan 25 08:41:57 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 25 Jan 2007 00:41:57 -0800 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <20070124183107.GB6105@nostromo.devel.redhat.com> References: <45B24A5E.9050207@leemhuis.info> <20070122193239.GB26694@nostromo.devel.redhat.com> <45B77B42.6020908@leemhuis.info> <20070124183107.GB6105@nostromo.devel.redhat.com> Message-ID: <1169714517.5106.176.camel@localhost.localdomain> On Wed, 2007-01-24 at 13:31 -0500, Bill Nottingham wrote: > Thorsten Leemhuis (fedora at leemhuis.info) said: > > >> Packages primary maintained by Red Hat employees should > > >> have at least one co-maintainer from the community. They should try to > > >> hand over certain regular maintain task to the the community; that > > >> should help getting the community involved everywhere and to get some > > >> load of the Red Hat employees so they can focus on more imporant things > > >> -- that's best for both sides! > > > How is this different than the rest of the policy? One community, > > > maintainers are maintainers, co-maintainers are co-maintainers. Trying > > > to draft specific policy based on locality seems like a bad idea to > > > me. > > > > I hope that para can vanish over time, but I think it's worth it for > > now, to make sure the community gets involved everywhere so the > > differences between red hat and community members then will hopefully > > nearly vanish. > > > > OK, I'm getting tired of arguing this point with you. Your words say > it very clearly - 'make sure the community gets involved', 'differences > between red hat and community members'. > > What those words say to me is that you don't think people in Red Hat are > now, or can be part of the community - that the community is always > entirely separate. And, frankly, I find that offensive. > > If I want to co-maintain some game that Hans maintains, then I talk to > him, and it's irrelevant w.r.t. who signs his or my paycheck. If Josh > wants to co-maintain vte, then he talks to Behdad (or whomever), and > it's irrelevant who signs their paychecks. > > If there are trust or other issues with how things are maintained, let's > hear them. But I'm not going to have some policy that mandates actions > based on some caste system separating maintainers into different camps. > > I don't like requirements here or elsewhere that mandate "X of the community and Y from Red Hat" for mostly the same reasons as you, Bill. However, I think what Thorsten is trying to address in this policy is the fact that currently, there's a block of Red Hat packagers that aren't really integrated or interacting with the community that has evolved around Fedora Extras. This is the cause of the Red Hat vs community mentality that has come out here. Now I think we want to shoot for a time when it won't matter who your employer is; if you are here to work on Fedora you have a niche within the Fedora Community. But to get there we have to acknowledge that not everyone who currently works on Fedora wants to be active in the community. Some people at Red Hat just want to do their jobs and go home; some people involved in upstream projects want to see their one specific package available for Fedora users and that's it. We have to address this, either by getting active community members to maintain/co-maintain those packages (Devrim Gunduz is an example of someone working to be a bridge between upstream postgresql projects and Fedora Packaging) or by making use of something like warren's proposal for multiple paths to advancement[1]_ and realizing that advancement needs to involve the interpersonal aspects of Fedora as well as technical savvy. If we don't address this we're always going to see a split that is stereotyped as Red Hat vs Community. [1]_: http://fedoraproject.org/wiki/Extras/Schedule/AlternativePathsOfMembershipAdvancement -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Thu Jan 25 08:48:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 25 Jan 2007 09:48:56 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <1169700468.6751.267.camel@mccallum.corsepiu.local> Message-ID: <45B86EF8.9030209@leemhuis.info> Linus Walleij schrieb: > On Thu, 25 Jan 2007, Ralf Corsepius wrote: >> E.g. a team of "packaging specialists" being granted "card blanche >> privileges" on "packaging issues" (...) >> At least to me, e.g. wrt. packaging, in obvious cases, this would spare >> me a lot of time, because bugzilla'ing takes much more time than >> directly fixing something. > You're right. And I notice that I also stated before that most of the > Fedora core people (loosely defined term but definately including Ralf) > are welcome to change and rebuild any of my packages at will. > > Actually the idea of strict ownership evades me, I would rather prefer a > more Wiki-like attitude (once you have a Fedora ID account and PGP key) - > "BE BOLD", "If in doubt, fix it". > http://en.wikipedia.org/wiki/Wikipedia:Be_bold_in_updating_pages +1 -- I'm all for that, too, but every time I proposed something like the above somewhere I got quickly shot down by other people. But the proper place for that IMHO is not the co-maintainers policy. It's IMHO the "when to touch other peoples packages" policy. When I wrote that I even tried to grant some "packaging specialists" access everywhere, but as I said: People did not like it and preferred the bugzilla way even for obvious fixes. Cu thl From nicolas.mailhot at laposte.net Thu Jan 25 09:14:13 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 25 Jan 2007 10:14:13 +0100 (CET) Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <1169700468.6751.267.camel@mccallum.corsepiu.local> Message-ID: <54087.192.54.193.51.1169716453.squirrel@rousalka.dyndns.org> Le Jeu 25 janvier 2007 09:10, Linus Walleij a ?crit : > Actually the idea of strict ownership evades me, I would rather prefer a > more Wiki-like attitude (once you have a Fedora ID account and PGP key) - > "BE BOLD", "If in doubt, fix it". You have to be a little more careful than this. It's easy to propose a fix one-time fix for a problem you're well aquainted with. It's harder to follow a package long-term. Long-term maintenance means fixing stuff even if it's not your main area of expertise/interest, honoring upstream & Fedora deadlines, etc You have to balance getting *one* fix in faster with losing the current maintainer if you brutaly short-circuit him. -- Nicolas Mailhot From j.w.r.degoede at hhs.nl Thu Jan 25 10:17:20 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 25 Jan 2007 11:17:20 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B86EF8.9030209@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <1169700468.6751.267.camel@mccallum.corsepiu.local> <45B86EF8.9030209@leemhuis.info> Message-ID: <45B883B0.7060502@hhs.nl> Thorsten Leemhuis wrote: > Linus Walleij schrieb: >> On Thu, 25 Jan 2007, Ralf Corsepius wrote: >>> E.g. a team of "packaging specialists" being granted "card blanche >>> privileges" on "packaging issues" (...) >>> At least to me, e.g. wrt. packaging, in obvious cases, this would spare >>> me a lot of time, because bugzilla'ing takes much more time than >>> directly fixing something. >> You're right. And I notice that I also stated before that most of the >> Fedora core people (loosely defined term but definately including Ralf) >> are welcome to change and rebuild any of my packages at will. >> >> Actually the idea of strict ownership evades me, I would rather prefer a >> more Wiki-like attitude (once you have a Fedora ID account and PGP key) - >> "BE BOLD", "If in doubt, fix it". >> http://en.wikipedia.org/wiki/Wikipedia:Be_bold_in_updating_pages > > +1 -- I'm all for that, too, but every time I proposed something like > the above somewhere I got quickly shot down by other people. > > But the proper place for that IMHO is not the co-maintainers policy. > It's IMHO the "when to touch other peoples packages" policy. When I > wrote that I even tried to grant some "packaging specialists" access > everywhere, but as I said: People did not like it and preferred the > bugzilla way even for obvious fixes. > I'm not sure where I stand here, on one hand, I like the idea of being able to fix other peoples packages as bugzilla indeed sometimes is a slow path. OTOH I don't like people touching some of my packages without me being in the loop somehow. This differs from one package to the other, some are quite straight forward, others however are not and are easy to break. Take Ogre for example, a minor update from 1.2.3 to 1.2.4 from upstream might seam harmless there, but upstream tends to break the ABI every update! Some other maintainer trying to help is likely not to know this and thus create problems, so I don't want other people touching Ogre without asking me first. I think that we need todo 2 things: 1) Define the problem we are trying to solve. It seems that part of the problem is the bugzilla path to get fixes into others packages is slow. Replacing the bugzilla path is only one answer to this part of the problem, why not first find out why its slow (in some caseS) and see if we can remedy this. 2) Have a way to mark packages as ok to touch / don't touch. As said I know that some of my packages are easy to break if handled wrong, others OTOH should be fine candidates for other to fixup if a fixup if needed, or even candidates for someone to take over if he/she has an interest in doing so. Regards, Hans From rc040203 at freenet.de Thu Jan 25 10:46:42 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 25 Jan 2007 11:46:42 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B883B0.7060502@hhs.nl> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <1169700468.6751.267.camel@mccallum.corsepiu.local> <45B86EF8.9030209@leemhuis.info> <45B883B0.7060502@hhs.nl> Message-ID: <1169722003.5838.36.camel@mccallum.corsepiu.local> On Thu, 2007-01-25 at 11:17 +0100, Hans de Goede wrote: > Thorsten Leemhuis wrote: > > Linus Walleij schrieb: > >> On Thu, 25 Jan 2007, Ralf Corsepius wrote: > >>> E.g. a team of "packaging specialists" being granted "card blanche > >>> privileges" on "packaging issues" (...) > >>> At least to me, e.g. wrt. packaging, in obvious cases, this would spare > >>> me a lot of time, because bugzilla'ing takes much more time than > >>> directly fixing something. > >> You're right. And I notice that I also stated before that most of the > >> Fedora core people (loosely defined term but definately including Ralf) > >> are welcome to change and rebuild any of my packages at will. > I'm not sure where I stand here, on one hand, I like the idea of being > able to fix other peoples packages as bugzilla indeed sometimes is a > slow path. OTOH I don't like people touching some of my packages without > me being in the loop somehow. This differs from one package to the > other, some are quite straight forward, others however are not and are > easy to break. Take Ogre for example, a minor update from 1.2.3 to 1.2.4 > from upstream might seam harmless there, but upstream tends to break the > ABI every update! Some other maintainer trying to help is likely not to > know this and thus create problems, so I don't want other people > touching Ogre without asking me first. > > I think that we need todo 2 things: > 1) Define the problem we are trying to solve. I only see one issue: Non-responsive maintainers and issues not being addressed in "timely manners" rsp in "correct manners": As I see it, the causes are manifold. - In some cases it's a maintainer's "oversight" - In some cases it's a maintainer's non-awareness about a problem. (Many packaging mistakes/bugs fall into this category) - In some cases it's a maintainer's ignorance about the consequences of this deeds (The classical "FIXED RAWHIDE" falls into this category "FIXED RAWHIDE == unfixed in "CURRENT") - In some cases it's incompetence/lack of knowledge: Maintainers do not address an issue because they don't know what to do about it or apply arkward hacks, despite "specialists could easily help out" (many autotool- and 64bit-hacks are from this class of problems). - In some cases it's a maintainer being absent / having gone lost / not listening / not following the lists / not being subscribed to a list an issue is being reported (many of the broken EVRs issues fall into this category). ... So, in a nutshell: All I am proposing is, instead of forcing everybody to bugzilla issues/bugs and to wait for a maintainer to consider doing his job, let's build up some trusted teams who's task it would be to address "clear and obvious cases" to take off some load from the actual maintainer. An alternative to building such teams would be to build a group of semi-trusted "seniors" with "commit-after-approval" privileges. I.e. somebody from this "senior" group who is not the "nominal maintainer" of a package would have to present his diffs for review/approval to his fellow "seniors" until his proposal has collected sufficient votes from other "seniors". Other projects (eg. the GCC project) implement all 3 models at once: "Owners", "write after approval" and "card-blanche on specific problem domains". Ralf From fedora at leemhuis.info Thu Jan 25 12:11:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 25 Jan 2007 13:11:29 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169714517.5106.176.camel@localhost.localdomain> References: <45B24A5E.9050207@leemhuis.info> <20070122193239.GB26694@nostromo.devel.redhat.com> <45B77B42.6020908@leemhuis.info> <20070124183107.GB6105@nostromo.devel.redhat.com> <1169714517.5106.176.camel@localhost.localdomain> Message-ID: <45B89E71.1070607@leemhuis.info> Toshio Kuratomi schrieb: > On Wed, 2007-01-24 at 13:31 -0500, Bill Nottingham wrote: >> Thorsten Leemhuis (fedora at leemhuis.info) said: >>>>> Packages primary maintained by Red Hat employees should >>>>> have at least one co-maintainer from the community. They should try to >>>>> hand over certain regular maintain task to the the community; that >>>>> should help getting the community involved everywhere and to get some >>>>> load of the Red Hat employees so they can focus on more imporant things >>>>> -- that's best for both sides! >>>> How is this different than the rest of the policy? One community, >>>> maintainers are maintainers, co-maintainers are co-maintainers. Trying >>>> to draft specific policy based on locality seems like a bad idea to >>>> me. >>> I hope that para can vanish over time, but I think it's worth it for >>> now, to make sure the community gets involved everywhere so the >>> differences between red hat and community members then will hopefully >>> nearly vanish. >> >> >> OK, I'm getting tired of arguing this point with you. Your words say >> it very clearly - 'make sure the community gets involved', 'differences >> between red hat and community members'. >> >> What those words say to me is that you don't think people in Red Hat are >> now, or can be part of the community - that the community is always >> entirely separate. And, frankly, I find that offensive. >> >> If I want to co-maintain some game that Hans maintains, then I talk to >> him, and it's irrelevant w.r.t. who signs his or my paycheck. If Josh >> wants to co-maintain vte, then he talks to Behdad (or whomever), and >> it's irrelevant who signs their paychecks. >> >> If there are trust or other issues with how things are maintained, let's >> hear them. But I'm not going to have some policy that mandates actions >> based on some caste system separating maintainers into different camps. >> >> > > I don't like requirements here or elsewhere that mandate "X of the > community and Y from Red Hat" for mostly the same reasons as you, Bill. > However, I think what Thorsten is trying to address in this policy is > the fact that currently, there's a block of Red Hat packagers that > aren't really integrated or interacting with the community that has > evolved around Fedora Extras. This is the cause of the Red Hat vs > community mentality that has come out here. Exactly. With one important addition: There are a lot of (often vocal) users out there that say "Red Hat is totally controlling Fedora and especially the important packages, thus Fedora is not a community project and I don't want to contribute to it" or "Red Hat is the Microsoft in the Linux world". We can't get those and similar statements out of the world in the short term (probably never, as Red Hat *has* certain influence in Fedora). But we could do some small things and set clear signs here and there that show that those statements are mostly false and that we are "The good guys". That could improve our reputation and might make us a lot more attractive for contributors. The Core and Extras merge is such a good sign. But we need a bit more and that merge must show that we mean it serious with the "Community Project". Getting a lot of non-Red-Hat contributors as co-maintainers for all the stuff that was known as "Fedora Core" until now *and* saying "Red Hat might have a majority in the Fedora Project Board, but the community has much influence there, too, and always has at least 50% of the seats in FESCo which does the day-to-day for for the Fedora distribution" are IMHO two clear signs we could and should set. CU thl Disclaimer: I highly respect all the Red Hat developers (guys, you are really doing a good job!) and the company and its politics. That's why I'm contributing to Fedora. But it seems the view from the world is not that positive, thus I think some small things like those outlines above could help Fedora a lot! From paul at city-fan.org Thu Jan 25 12:28:26 2007 From: paul at city-fan.org (Paul Howarth) Date: Thu, 25 Jan 2007 12:28:26 +0000 Subject: Plan for tomorrows (20070125) FESCO meeting In-Reply-To: <20070125015551.27a9a95d.bugs.michael@gmx.net> References: <1169685207.2121.8.camel@Chuck> <20070125015551.27a9a95d.bugs.michael@gmx.net> Message-ID: <45B8A26A.7090901@city-fan.org> Michael Schwendt wrote: > On Wed, 24 Jan 2007 19:33:27 -0500, Brian Pepple wrote: > >> You want something to be discussed? Send a note to the list in reply to >> this mail and I'll add it to the schedule (I can't promise we will get >> to it tomorrow, but we'll most likely will if we don't run out of time). >> You can also propose topics in the meeting while it is in the "Free >> discussion around Fedora Extras" phase. > > /topic FESCO-Meeting -- Extras 7 preparation -- roadmap, broken deps, > key packages (wxGTK2 issues solved?), rebuilds, FE7Target bug, mail > to all package owners? Regarding wxGTK2, I'm not sure that all is well there yet. The current stable release of the official BitTorrent client (the bittorrent package in Extras) is developed using wx 2.6.x and doesn't work out of the box with 2.8.x due to some code that specifically requests version 2.6. If this code is tweaked to request version 2.8, the GUI client gets as far as displaying the main window and then segfaults in a logging routine. Working around that one just leads to another segfault somewhere else and it ends up as a game of whack-a-mole with segfaults (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223623). The upstream BitTorrent maintainer reckons that the wxPython appears to be broken. I don't know either way, but if someone more familiar with wxPython could take a look at it, I'd be most grateful. The same problems occur on Rawhide and on FC6 with the wxGTK and wxPython 2.8 SRPMs from the devel branch rebuilt on FC6 (i.e. it's not a python 2.5 problem). With the FC6 wx 2.6 packages, the GUI client works OK. Paul. From belegdol at gmail.com Thu Jan 25 20:22:19 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Thu, 25 Jan 2007 20:22:19 +0000 Subject: Stuck behind a proxy :( In-Reply-To: <45B526FC.5040505@poolshark.org> References: <9b1b20e70701221234r5779e1albb782471c95cb861@mail.gmail.com> <45B526FC.5040505@poolshark.org> Message-ID: <9b1b20e70701251222v6ac69f04s6d739e8f0cccfea3@mail.gmail.com> I tried to make it work, but the design of the residence network seems to be really crappy :( 2007/1/22, Denis Leroy : > Julian Sikorski wrote: > > Hello. It looks like I will be stuck behind a proxy for a while :( I > > have left Poland for about half a year, to spend one semester at the > > University of Strathclyde (Erasmus exchange). The problem is that the > > network within the halls of residence connects to the outer world via > > http proxy. So I am able to browse the web and download files via ftp, > > but cvs does not work for me. So please, feel free to push any updates > > to my packages that you find necesary. I am (was?) the maintainer of > > the following ones: > > chemical-mime-data > > gchempaint > > gnome-chemistry-utils > > museek+ > > qt-qsa > > qwtplot3d > > I'll still be reading the list and once I get back access to cvs, I'll > > let you know. > > you can use cvs across an http proxy by using 'ProxyCommand' in your > .ssh/config file (see 'man ssh_config', look for ProxyCommand). > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From roozbeh at farsiweb.info Fri Jan 26 14:28:53 2007 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Fri, 26 Jan 2007 17:58:53 +0330 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B7B19D.4060107@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> <45B7B19D.4060107@leemhuis.info> Message-ID: <1169821733.4305.12.camel@shalil.farsiweb.info> On Wed, 2007-01-24 at 20:21 +0100, Thorsten Leemhuis wrote: > I think we've already reached the point where we need to get new people > into the game via co-maintainership. Exactly. But a question. Will you need co-maintainers to be sponsored for co-maintenance? For example, may I (not a sponsor) get new people involved in Fedora by making them co-sponsors of my packages? Roozbeh From notting at redhat.com Fri Jan 26 14:31:51 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 26 Jan 2007 09:31:51 -0500 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169821733.4305.12.camel@shalil.farsiweb.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> <45B7B19D.4060107@leemhuis.info> <1169821733.4305.12.camel@shalil.farsiweb.info> Message-ID: <20070126143151.GB4166@nostromo.devel.redhat.com> Roozbeh Pournader (roozbeh at farsiweb.info) said: > Exactly. > > But a question. Will you need co-maintainers to be sponsored for > co-maintenance? For example, may I (not a sponsor) get new people > involved in Fedora by making them co-sponsors of my packages? So, this is interesting from a logistics perspective; we would want a way to allow ACLs for committing to the package they're co-maintaining, without allowing them to commit to other packages that may be open. That's not possible ATM with current code. Bill From gdk at redhat.com Fri Jan 26 14:41:32 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Fri, 26 Jan 2007 09:41:32 -0500 (EST) Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <1169821733.4305.12.camel@shalil.farsiweb.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> <45B7B19D.4060107@leemhuis.info> <1169821733.4305.12.camel@shalil.farsiweb.info> Message-ID: On Fri, 26 Jan 2007, Roozbeh Pournader wrote: > On Wed, 2007-01-24 at 20:21 +0100, Thorsten Leemhuis wrote: > >> I think we've already reached the point where we need to get new people >> into the game via co-maintainership. > > Exactly. I'm not sure this follows. Is the true statement, "we need to get new people into the game via co-maintainership"? Or is it, "we need to get new people into the game"? These are two different statements. === So let me approach this from a different tack. I think we've got two major issues to resolve: 1. Making it crystal clear what packages need help, in whatever category: orphaned, possibly orphaned, poorly maintained, on a wish list. 2. Making it dead easy for new packages to contribute. At this point, I think this means *actively* training packagers. I think we're trying to solve problem 2 with co-maintainership -- and I don't think that's necessarily the right approach. What about an IRC teach-in? What if we had a couple of packagers who, once a month or so, took a couple of hours to run a packaging tutorial in real time? --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From fedora at leemhuis.info Fri Jan 26 15:06:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 26 Jan 2007 16:06:26 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> <45B7B19D.4060107@leemhuis.info> <1169821733.4305.12.camel@shalil.farsiweb.info> Message-ID: <45BA18F2.6070709@leemhuis.info> BTW, FESCo discussed the whole co-maintainership proposal a little bit in yesterdays meeting. I'll revisit the proposal and hope to come up with something that will get into the same direction, but a bit differently, in the hope to make more people glad. But that might take some time. Greg Dekoenigsberg schrieb: > On Fri, 26 Jan 2007, Roozbeh Pournader wrote: >> On Wed, 2007-01-24 at 20:21 +0100, Thorsten Leemhuis wrote: >>> I think we've already reached the point where we need to get new people >>> into the game via co-maintainership. >> Exactly. > I'm not sure this follows. > > Is the true statement, "we need to get new people into the game via > co-maintainership"? Or is it, "we need to get new people into the game"? > > These are two different statements. I'd say both are important. [...] > What about an IRC teach-in? What if we had a couple of packagers who, > once a month or so, took a couple of hours to run a packaging tutorial in > real time? "Learning by doing" and especially the part "*making errors* and learn from them" (?) is IMHO important, especially for packaging. In other words: I don't think a IRC packaging tutorial will be a big help as those that will give that tutorial will probably be experts already and experts often forgot all those small errors they did in the beginning. CU thl (?) -- read: making errors in this case means: make errors while being co-maintainer, get told by the primary maintainer before the package gets build or hits the repo. And *no*, I don't want to force that on anybody. It's something that primary maintainer *can* do if they want. From gdk at redhat.com Fri Jan 26 15:27:57 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Fri, 26 Jan 2007 10:27:57 -0500 (EST) Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45BA18F2.6070709@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> <45B7B19D.4060107@leemhuis.info> <1169821733.4305.12.camel@shalil.farsiweb.info> <45BA18F2.6070709@leemhuis.info> Message-ID: On Fri, 26 Jan 2007, Thorsten Leemhuis wrote: >> What about an IRC teach-in? What if we had a couple of packagers who, >> once a month or so, took a couple of hours to run a packaging tutorial in >> real time? > > "Learning by doing" and especially the part "*making errors* and learn > from them" (?) is IMHO important, especially for packaging. > > In other words: I don't think a IRC packaging tutorial will be a big > help as those that will give that tutorial will probably be experts > already and experts often forgot all those small errors they did in the > beginning. What if we're teaching by leading newbies through the packaging of actual orphaned/wishlist packages? --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From fedora at leemhuis.info Fri Jan 26 16:24:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 26 Jan 2007 17:24:26 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> <45B7B19D.4060107@leemhuis.info> <1169821733.4305.12.camel@shalil.farsiweb.info> <45BA18F2.6070709@leemhuis.info> Message-ID: <45BA2B3A.9090900@leemhuis.info> Greg Dekoenigsberg schrieb: > On Fri, 26 Jan 2007, Thorsten Leemhuis wrote: >>> What about an IRC teach-in? What if we had a couple of packagers who, >>> once a month or so, took a couple of hours to run a packaging tutorial in >>> real time? >> "Learning by doing" and especially the part "*making errors* and learn >> from them" (?) is IMHO important, especially for packaging. >> In other words: I don't think a IRC packaging tutorial will be a big >> help as those that will give that tutorial will probably be experts >> already and experts often forgot all those small errors they did in the >> beginning. > What if we're teaching by leading newbies through the packaging of actual > orphaned/wishlist packages? I for one would not be interested to package something I don't even use and/or I have no interest in. And it IMHO might lead to bad package quality. So encouraging new packagers to do that is IMHO not a good idea. CU thl From gdk at redhat.com Fri Jan 26 16:35:53 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Fri, 26 Jan 2007 11:35:53 -0500 (EST) Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45BA2B3A.9090900@leemhuis.info> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> <45B7B19D.4060107@leemhuis.info> <1169821733.4305.12.camel@shalil.farsiweb.info> <45BA18F2.6070709@leemhuis.info> <45BA2B3A.9090900@leemhuis.info> Message-ID: On Fri, 26 Jan 2007, Thorsten Leemhuis wrote: > Greg Dekoenigsberg schrieb: >> On Fri, 26 Jan 2007, Thorsten Leemhuis wrote: >>>> What about an IRC teach-in? What if we had a couple of packagers who, >>>> once a month or so, took a couple of hours to run a packaging tutorial in >>>> real time? >>> "Learning by doing" and especially the part "*making errors* and learn >>> from them" (?) is IMHO important, especially for packaging. >>> In other words: I don't think a IRC packaging tutorial will be a big >>> help as those that will give that tutorial will probably be experts >>> already and experts often forgot all those small errors they did in the >>> beginning. >> What if we're teaching by leading newbies through the packaging of actual >> orphaned/wishlist packages? > > I for one would not be interested to package something I don't even use > and/or I have no interest in. And it IMHO might lead to bad package quality. > > So encouraging new packagers to do that is IMHO not a good idea. Duh. :) Of course *that* isn't a good idea, Thorsten. We wouldn't be mandating forcing new packagers to package stuff they don't like. That would be stupid. In fact, one of the greatest potential motivators for a new packager is simple: they can't find a package in Fedora that they really, really want. The key question: how do we turn this motivation into action? It could be as simple as a wiki page: NewPackagerTraining, let's say. The page refers to some reading material, maybe, so that new packagers have some homework to do and aren't wasting potential instructor time. People then sign up for "classes", and they each list the one package that they think they'd like to take a shot at packaging. And then, once a month, we run a session with them, where the Professors: a. Review the basics of packaging; b. Walk through the process (get the bits, write the spec file, etc.); c. Answer newbie questions; d. Act as sponsors for the ones who "get it". Sure, the best way of learning, ultimately, is to learn by doing. But I suspect there are lots of folks who would respond very positively to some direct hands-on work -- including some very smart people who may just need a little bit of assurance. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From bugs.michael at gmx.net Fri Jan 26 18:43:37 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 26 Jan 2007 19:43:37 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45B883B0.7060502@hhs.nl> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <1169700468.6751.267.camel@mccallum.corsepiu.local> <45B86EF8.9030209@leemhuis.info> <45B883B0.7060502@hhs.nl> Message-ID: <20070126194337.9d70be3b.bugs.michael@gmx.net> On Thu, 25 Jan 2007 11:17:20 +0100, Hans de Goede wrote: > >> Actually the idea of strict ownership evades me, I would rather prefer a > >> more Wiki-like attitude (once you have a Fedora ID account and PGP key) - > >> "BE BOLD", "If in doubt, fix it". > >> http://en.wikipedia.org/wiki/Wikipedia:Be_bold_in_updating_pages > > > > +1 -- I'm all for that, too, but every time I proposed something like > > the above somewhere I got quickly shot down by other people. > > > > But the proper place for that IMHO is not the co-maintainers policy. > > It's IMHO the "when to touch other peoples packages" policy. When I > > wrote that I even tried to grant some "packaging specialists" access > > everywhere, but as I said: People did not like it and preferred the > > bugzilla way even for obvious fixes. > > > > I'm not sure where I stand here, on one hand, I like the idea of being > able to fix other peoples packages as bugzilla indeed sometimes is a > slow path. OTOH I don't like people touching some of my packages without > me being in the loop somehow. This differs from one package to the > other, some are quite straight forward, others however are not and are > easy to break. Take Ogre for example, a minor update from 1.2.3 to 1.2.4 > from upstream might seam harmless there, but upstream tends to break the > ABI every update! Some other maintainer trying to help is likely not to > know this and thus create problems, so I don't want other people > touching Ogre without asking me first. "Touching your packages" and "upgrading your packages" is not the same. Why, oh, why are breakage scenarios like that used as a main argument everytime there is a discussion like this? From fedora at leemhuis.info Fri Jan 26 18:44:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 26 Jan 2007 19:44:05 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <45B7AEBD.90607@leemhuis.info> <45B7B19D.4060107@leemhuis.info> <1169821733.4305.12.camel@shalil.farsiweb.info> <45BA18F2.6070709@leemhuis.info> <45BA2B3A.9090900@leemhuis.info> Message-ID: <45BA4BF5.8070704@leemhuis.info> Greg, it seems to me we have different things in mind. Sure, something like you outlined in your mail might help teaching new contributors packaging -- but it would be a lot of work for some existing contributors (you mentioned Professors/Instructors and homework [which would need to be prepared or "checked"]). But it's to a wide part a variant of the sponsorship process we have already. A variant that has a higher entry burden then the current process afaics. That's a bit problematic, too, IMHO -- but that's a different thing, so back to the main topic: Greg Dekoenigsberg schrieb: > [...] > In fact, one of the greatest potential motivators for a new packager is > simple: they can't find a package in Fedora that they really, really want. Sure, that's the greatest potential motivator and it was probably the motivator for most of the current Extras contributors. But that potential motivator got and still gets smaller and smaller with every package that finds its way into the repo. It IMHO is quite small already. Just imagine a alternate variant thl that was busy with real life in the last three years, never became a Fedora contributor (?) until now but *now* wants to become one. All the software I use that can be packaged in Fedora is there these days. So this potential motivator would not exist for me and thus the "traditional sponsership process" is no way of entry for me. So where do I start? How do I get involved in Fedora? We need a entry point for people like the alternate variant of thl. One way for those people IMHO could be this: * I read a bit about rpm packaging in general, look at the guidlines, try a bit here, try a bit there. * I look around what smaller packages exist in Fedora that I'm interested it. * I watch the maintainers of those packagers and their doings a bit * I ask some of those maintainers if I can help them with some stuff and/or I provide patches and enhancements for this or that * I ask to become a co-maintainer for some of those packages. I of course get only access to those packages in the beginning and *no* permissions to build anything * I start do do some regular maintain tasks; the primary maintainer checks them and builds the package if everything is fine * I learn while doing it * I Learn more * Sooner or later I will have learned a lot. Then the primary maintainer IMHO could says: "okay, you are doing a good job, I'm involved in a lot of other stuff these days, do you want to take the package over" This often would have advantages for the primary maintainer at the same time as well: After the initial learn and integration period of the new contributor he has a bit less work to care about. He can use that time for more crucial and more complicated stuff in Fedora land. E.g. work directly on Features like a new init system for Fedora 8. Or work on more complicated packages. CU thl (?) -- some people would probably prefer that scenario :) From j.w.r.degoede at hhs.nl Mon Jan 29 08:11:13 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 29 Jan 2007 09:11:13 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <20070126194337.9d70be3b.bugs.michael@gmx.net> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <1169700468.6751.267.camel@mccallum.corsepiu.local> <45B86EF8.9030209@leemhuis.info> <45B883B0.7060502@hhs.nl> <20070126194337.9d70be3b.bugs.michael@gmx.net> Message-ID: <45BDAC21.9020008@hhs.nl> Michael Schwendt wrote: > On Thu, 25 Jan 2007 11:17:20 +0100, Hans de Goede wrote: > >>>> Actually the idea of strict ownership evades me, I would rather prefer a >>>> more Wiki-like attitude (once you have a Fedora ID account and PGP key) - >>>> "BE BOLD", "If in doubt, fix it". >>>> http://en.wikipedia.org/wiki/Wikipedia:Be_bold_in_updating_pages >>> +1 -- I'm all for that, too, but every time I proposed something like >>> the above somewhere I got quickly shot down by other people. >>> >>> But the proper place for that IMHO is not the co-maintainers policy. >>> It's IMHO the "when to touch other peoples packages" policy. When I >>> wrote that I even tried to grant some "packaging specialists" access >>> everywhere, but as I said: People did not like it and preferred the >>> bugzilla way even for obvious fixes. >>> >> I'm not sure where I stand here, on one hand, I like the idea of being >> able to fix other peoples packages as bugzilla indeed sometimes is a >> slow path. OTOH I don't like people touching some of my packages without >> me being in the loop somehow. This differs from one package to the >> other, some are quite straight forward, others however are not and are >> easy to break. Take Ogre for example, a minor update from 1.2.3 to 1.2.4 >> from upstream might seam harmless there, but upstream tends to break the >> ABI every update! Some other maintainer trying to help is likely not to >> know this and thus create problems, so I don't want other people >> touching Ogre without asking me first. > > "Touching your packages" and "upgrading your packages" is not the same. > Why, oh, why are breakage scenarios like that used as a main argument > everytime there is a discussion like this? > Because: 1) I've sponsored several people and in general that meant having to teach / coach them until they become familiar enough with packaging issues and guidelines to give them the green light. At that point most of them still weren't really good packagers, think of them as just graduated from school and now learning the real stuff in practice. 2) One of THL's main arguments for this co-maintaining is to allow new (unexperienced) contributers to get into the game by co maintaining 3) New (unexperienced) contributers are likely to not know the difference between touching and updating. That doesn't mean I'm opposed to all this, it just means I'm critical. I for one wouldn't let a new (unexperienced) contributer, co-maintain any (delicate) libraries as the chance for breakage is just too high (IMHO). OTOH I have plenty of simple / small package for which a co-maintainer would be more then welcome, and in that case to actual handle things like new upstream versions, fix small packaging bugs etc. Regards, Hans From bugs.michael at gmx.net Mon Jan 29 11:16:47 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 29 Jan 2007 12:16:47 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <45BDAC21.9020008@hhs.nl> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <1169700468.6751.267.camel@mccallum.corsepiu.local> <45B86EF8.9030209@leemhuis.info> <45B883B0.7060502@hhs.nl> <20070126194337.9d70be3b.bugs.michael@gmx.net> <45BDAC21.9020008@hhs.nl> Message-ID: <20070129121647.6dc95175.bugs.michael@gmx.net> On Mon, 29 Jan 2007 09:11:13 +0100, Hans de Goede wrote: > > "Touching your packages" and "upgrading your packages" is not the same. > > Why, oh, why are breakage scenarios like that used as a main argument > > everytime there is a discussion like this? > > > > Because: > 1) I've sponsored several people and in general that meant having to > teach / coach them until they become familiar enough with packaging > issues and guidelines to give them the green light. At that point > most of them still weren't really good packagers, think of them as > just graduated from school and now learning the real stuff in > practice. > 2) One of THL's main arguments for this co-maintaining is to allow new > (unexperienced) contributers to get into the game by co maintaining > > 3) New (unexperienced) contributers are likely to not know the > difference between touching and updating. It has not become clear to me that thl refers to inexperienced people only (I may need to reread his overlong proposal). Experience is relative. Existing Fedora packagers can apply over-ambitious or questionable changes, too, and sometimes make mistakes. Generally, the entry path is blocked not only for inexperienced people, who haven't signed up before, but also for knowledgeable people. Without an alternative process for new contributors, they cannot become Fedora packagers of anything that is included in the distribution already. Even if they found a single package to submit (possibly an orphaned one), there is an artificial hurdle that in order to find a sponsor, they should do a couple of reviews first. I don't really see a problem with letting new contributor sign up as co-maintainers when they would like to help with a specific package. An existing package owner would take the place of the account sponsor, and there is no requirement to give new contributors a free ticket for running wild in the scm and buildsys. Certainly it could be arranged that they talk to the primary package owner about planned changes and build jobs. Failure to do so could have consequences or in case something breaks badly. > That doesn't mean I'm opposed to all this, it just means I'm critical. > I for one wouldn't let a new (unexperienced) contributer, co-maintain > any (delicate) libraries as the chance for breakage is just too high > (IMHO). "No chance = no breakage" is like trying to keep the door closed. It should be possible to open the door cautiously, with proper policies and guidelines in place. > OTOH I have plenty of simple / small package for which a > co-maintainer would be more then welcome, and in that case to actual > handle things like new upstream versions, fix small packaging bugs etc. Even "simple / small" packages can be build dependencies for other packages and therefore increase the overall maintenance requirements. From j.w.r.degoede at hhs.nl Mon Jan 29 12:01:45 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 29 Jan 2007 13:01:45 +0100 Subject: Co-maintainersip policy for Fedora Packages In-Reply-To: <20070129121647.6dc95175.bugs.michael@gmx.net> References: <45B24A5E.9050207@leemhuis.info> <1169461780.3329.12.camel@shalil.farsiweb.info> <45B76CA6.20903@leemhuis.info> <45B78671.8050603@hhs.nl> <1169664054.21801.9.camel@cutter> <1169700468.6751.267.camel@mccallum.corsepiu.local> <45B86EF8.9030209@leemhuis.info> <45B883B0.7060502@hhs.nl> <20070126194337.9d70be3b.bugs.michael@gmx.net> <45BDAC21.9020008@hhs.nl> <20070129121647.6dc95175.bugs.michael@gmx.net> Message-ID: <45BDE229.2000006@hhs.nl> Michael Schwendt wrote: > On Mon, 29 Jan 2007 09:11:13 +0100, Hans de Goede wrote: >> OTOH I have plenty of simple / small package for which a >> co-maintainer would be more then welcome, and in that case to actual >> handle things like new upstream versions, fix small packaging bugs etc. > > Even "simple / small" packages can be build dependencies for other > packages and therefore increase the overall maintenance requirements. > Trust me the packages I have in mind are not build deps of other packages, Regards, Hans From buildsys at fedoraproject.org Mon Jan 29 13:42:55 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 29 Jan 2007 08:42:55 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-01-29 Message-ID: <20070129134255.A627415212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): cman FC6-updates > FC7 (0:2.0.60-1.fc6 > 0:2.0.18-2.fc6) crontabs FC6-updates > FC7 (0:1.10-11.fc6 > 0:1.10-8) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) gfs2-utils FC6-updates > FC7 (0:0.1.25-1.fc6 > 0:0.1.7-1.fc6) gphoto2 FC5-updates > FC6-updates (0:2.3.1-3.fc5 > 0:2.3.1-1.fc6) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) libxslt FC6-updates > FC7 (0:1.1.20-1.fc6 > 0:1.1.20-1) lvm2-cluster FC6-updates > FC7 (0:2.02.17-1.fc6 > 0:2.02.11-4.fc7) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) screen FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) squirrelmail FC5-updates > FC7 (0:1.4.8-4.fc5 > 0:1.4.8-3.fc6) FC6-updates > FC7 (0:1.4.8-4.fc6 > 0:1.4.8-3.fc6) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) traceroute FC5-updates > FC7 (3:2.0.2-1.fc5 > 1:2.0.3-1.fc7) FC6-updates > FC7 (3:2.0.2-1.fc6 > 1:2.0.3-1.fc7) xorg-x11-drv-trident FC6-updates > FC7 (0:1.2.3-1.fc6 > 0:1.2.1-3.fc6) cgoorah AT yahoo.com.au: toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT christoph-wickert.de: xfce4-fsguard-plugin FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) gauret AT free.fr: amarok FE6 > FE7 (0:1.4.4-7.fc6 > 0:1.4.4-5.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) karlikt AT gmail.com: warzone2100 FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) karlthered AT gmail.com: listen FE6 > FE7 (0:0.5-11.beta1.fc6 > 0:0.5-9.beta1.fc7.4) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) orion AT cora.nwra.com: ncarg FE6 > FE7 (0:4.4.1-7.fc6 > 0:4.4.1-6.fc7) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: gnome-sudoku FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) ville.skytta AT iki.fi: em8300-kmod FE6 > FE7 (0:0.16.0-5.2.6.19_1.2895.fc6 > 0:0.16.0-5.2.6.18_1.2869.fc6) ---------------------------------------------------------------------- amarok: gauret AT free.fr FE6 > FE7 (0:1.4.4-7.fc6 > 0:1.4.4-5.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) cman: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.0.60-1.fc6 > 0:2.0.18-2.fc6) crontabs: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.10-11.fc6 > 0:1.10-8) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) em8300-kmod: ville.skytta AT iki.fi FE6 > FE7 (0:0.16.0-5.2.6.19_1.2895.fc6 > 0:0.16.0-5.2.6.18_1.2869.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gfs2-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.1.25-1.fc6 > 0:0.1.7-1.fc6) gnome-sudoku: stickster AT gmail.com FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) gphoto2: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:2.3.1-3.fc5 > 0:2.3.1-1.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) libxslt: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.1.20-1.fc6 > 0:1.1.20-1) listen: karlthered AT gmail.com FE6 > FE7 (0:0.5-11.beta1.fc6 > 0:0.5-9.beta1.fc7.4) lvm2-cluster: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.02.17-1.fc6 > 0:2.02.11-4.fc7) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) ncarg: orion AT cora.nwra.com FE6 > FE7 (0:4.4.1-7.fc6 > 0:4.4.1-6.fc7) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) screen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) squirrelmail: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:1.4.8-4.fc5 > 0:1.4.8-3.fc6) FC6-updates > FC7 (0:1.4.8-4.fc6 > 0:1.4.8-3.fc6) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) traceroute: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (3:2.0.2-1.fc5 > 1:2.0.3-1.fc7) FC6-updates > FC7 (3:2.0.2-1.fc6 > 1:2.0.3-1.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) warzone2100: karlikt AT gmail.com FE5 > FE6 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc6) FE5 > FE7 (0:2.0.5-4.fc5 > 0:2.0.5-3.fc7) xfce4-fsguard-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.3.0-4.fc6 > 0:0.3.0-3.fc6) xfce4-websearch-plugin: fedora AT christoph-wickert.de FE6 > FE7 (0:0.1.1-0.3.20060923svn.fc6 > 0:0.1.1-0.2.20060923svn.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) xorg-x11-drv-trident: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.2.3-1.fc6 > 0:1.2.1-3.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-1.fc6 > 0:2.9.4-2.fc6) From ajackson at redhat.com Mon Jan 29 15:48:12 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 29 Jan 2007 10:48:12 -0500 Subject: Package EVR problems in FC+FE 2007-01-29 In-Reply-To: <20070129134255.A627415212E@buildsys.fedoraproject.org> References: <20070129134255.A627415212E@buildsys.fedoraproject.org> Message-ID: <1170085692.21709.41.camel@localhost.localdomain> On Mon, 2007-01-29 at 08:42 -0500, buildsys at fedoraproject.org wrote: > UNKNOWN OWNER (possibly Core package): > cman > FC6-updates > FC7 (0:2.0.60-1.fc6 > 0:2.0.18-2.fc6) > > crontabs > FC6-updates > FC7 (0:1.10-11.fc6 > 0:1.10-8) > > dbus > FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) > > gfs2-utils > FC6-updates > FC7 (0:0.1.25-1.fc6 > 0:0.1.7-1.fc6) > > gphoto2 > FC5-updates > FC6-updates (0:2.3.1-3.fc5 > 0:2.3.1-1.fc6) > > iscsi-initiator-utils > FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) > > kdeedu > FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) > FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) > > libxslt > FC6-updates > FC7 (0:1.1.20-1.fc6 > 0:1.1.20-1) > > lvm2-cluster > FC6-updates > FC7 (0:2.02.17-1.fc6 > 0:2.02.11-4.fc7) > > nfs-utils > FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) > > screen > FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) > > squirrelmail > FC5-updates > FC7 (0:1.4.8-4.fc5 > 0:1.4.8-3.fc6) > FC6-updates > FC7 (0:1.4.8-4.fc6 > 0:1.4.8-3.fc6) > > systemtap > FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) > > traceroute > FC5-updates > FC7 (3:2.0.2-1.fc5 > 1:2.0.3-1.fc7) > FC6-updates > FC7 (3:2.0.2-1.fc6 > 1:2.0.3-1.fc7) > > xorg-x11-drv-trident > FC6-updates > FC7 (0:1.2.3-1.fc6 > 0:1.2.1-3.fc6) This makes no sense. The rawhide spec file is for 1.2.3-1.fc7, and if I attempt to rebuild it, brew refuses saying the tag already exists. That said, I still only see 1.2.1-3 in development/source/SRPMS, so, whatever. Rebuilt, should be fixed tomorrow. - ajax From jkeating at redhat.com Mon Jan 29 15:58:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 29 Jan 2007 10:58:27 -0500 Subject: Package EVR problems in FC+FE 2007-01-29 In-Reply-To: <1170085692.21709.41.camel@localhost.localdomain> References: <20070129134255.A627415212E@buildsys.fedoraproject.org> <1170085692.21709.41.camel@localhost.localdomain> Message-ID: <200701291058.27331.jkeating@redhat.com> On Monday 29 January 2007 10:48, Adam Jackson wrote: > This makes no sense. ?The rawhide spec file is for 1.2.3-1.fc7, and if I > attempt to rebuild it, brew refuses saying the tag already exists. > > That said, I still only see 1.2.1-3 in development/source/SRPMS, so, > whatever. ?Rebuilt, should be fixed tomorrow. This could be because rawhide right now composes from the f7-test1 tag, the freeze tag for Test1. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Mon Jan 29 15:52:02 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 29 Jan 2007 10:52:02 -0500 Subject: Package EVR problems in FC+FE 2007-01-29 In-Reply-To: <200701291058.27331.jkeating@redhat.com> References: <20070129134255.A627415212E@buildsys.fedoraproject.org> <1170085692.21709.41.camel@localhost.localdomain> <200701291058.27331.jkeating@redhat.com> Message-ID: <1170085922.21709.43.camel@localhost.localdomain> On Mon, 2007-01-29 at 10:58 -0500, Jesse Keating wrote: > On Monday 29 January 2007 10:48, Adam Jackson wrote: > > This makes no sense. The rawhide spec file is for 1.2.3-1.fc7, and if I > > attempt to rebuild it, brew refuses saying the tag already exists. > > > > That said, I still only see 1.2.1-3 in development/source/SRPMS, so, > > whatever. Rebuilt, should be fixed tomorrow. > > This could be because rawhide right now composes from the f7-test1 tag, the > freeze tag for Test1. Clever. 1.2.3-1.fc7 was built on Jan 24, if my changelog isn't lying; would that have been before or after we switched? - ajax From jkeating at redhat.com Mon Jan 29 16:04:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 29 Jan 2007 11:04:49 -0500 Subject: Package EVR problems in FC+FE 2007-01-29 In-Reply-To: <1170085922.21709.43.camel@localhost.localdomain> References: <20070129134255.A627415212E@buildsys.fedoraproject.org> <200701291058.27331.jkeating@redhat.com> <1170085922.21709.43.camel@localhost.localdomain> Message-ID: <200701291104.49510.jkeating@redhat.com> On Monday 29 January 2007 10:52, Adam Jackson wrote: > On Mon, 2007-01-29 at 10:58 -0500, Jesse Keating wrote: > > On Monday 29 January 2007 10:48, Adam Jackson wrote: > > > This makes no sense. The rawhide spec file is for 1.2.3-1.fc7, and if > > > I attempt to rebuild it, brew refuses saying the tag already exists. > > > > > > That said, I still only see 1.2.1-3 in development/source/SRPMS, so, > > > whatever. Rebuilt, should be fixed tomorrow. > > > > This could be because rawhide right now composes from the f7-test1 tag, > > the freeze tag for Test1. > > Clever. 1.2.3-1.fc7 was built on Jan 24, if my changelog isn't lying; > would that have been before or after we switched? > After. latest-pkg f7-test1 would show you. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Mon Jan 29 16:03:42 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 29 Jan 2007 11:03:42 -0500 Subject: Package EVR problems in FC+FE 2007-01-29 In-Reply-To: <200701291104.49510.jkeating@redhat.com> References: <20070129134255.A627415212E@buildsys.fedoraproject.org> <200701291058.27331.jkeating@redhat.com> <1170085922.21709.43.camel@localhost.localdomain> <200701291104.49510.jkeating@redhat.com> Message-ID: <1170086622.21709.46.camel@localhost.localdomain> On Mon, 2007-01-29 at 11:04 -0500, Jesse Keating wrote: > On Monday 29 January 2007 10:52, Adam Jackson wrote: > > On Mon, 2007-01-29 at 10:58 -0500, Jesse Keating wrote: > > > On Monday 29 January 2007 10:48, Adam Jackson wrote: > > > > This makes no sense. The rawhide spec file is for 1.2.3-1.fc7, and if > > > > I attempt to rebuild it, brew refuses saying the tag already exists. > > > > > > > > That said, I still only see 1.2.1-3 in development/source/SRPMS, so, > > > > whatever. Rebuilt, should be fixed tomorrow. > > > > > > This could be because rawhide right now composes from the f7-test1 tag, > > > the freeze tag for Test1. > > > > Clever. 1.2.3-1.fc7 was built on Jan 24, if my changelog isn't lying; > > would that have been before or after we switched? > > After. latest-pkg f7-test1 would show you. Should I assume that the test2 will compose from dist-fc7? Because if so I'll just wait and let that fix it. - ajax From bpepple at fedoraproject.org Mon Jan 29 16:29:05 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 29 Jan 2007 11:29:05 -0500 Subject: FESCo Meeting Summary for 2007-01-25 Message-ID: <1170088145.12976.5.camel@Chuck> Members Present * Brian Pepple (bpepple) * Thorsten Leemhuis (thl) * Warren Togami (warren) * Jeremy Katz (jeremy) * Christian Iseli (ch4chris) * Toshio Kuratomi (abadger1999) * Jason Tibbitts (tibbs) * Tom Callaway (spot) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Rex Dieter (rdieter) * Josh Boyer (jwb) * Kevin Fenzi (nirik) * Jesse Keating (f13) Absent * Andreas Bierfert (awjb) Summary EPEL Update * Still waiting on RedHat IT. Most of the necessary people will be at FUDCon, and the plan is to have a session regarding EPEL at the HackFest. Opening Core * Warren discussed the basic plan on how the review of the Core packages will proceed. He is going to work out the final details before FUDCon. Encourage co-maintainership * thl sent an e-mail to the mailing lists with his proposal for co-maintainership which generated quite a bit of discussion. He will incorporate suggestions from the mailing lists and the meeting into his proposal, and bring it back to FESCo. Syslog-ng Patent Problems * bpepple is going to check with Greg DeKoenigsberg and spot to verify that this is in legal's queue. Preparation for F7 * nirik is going to poke some folks regarding broken deps. * The current plan is not to do a mass-rebuild of packages since there aren't any toolchain reasons for it. Proposed ACL system * notting gave a brief description on how the ACL system will work: A. there will be a file 'pkg.acl' that can be added either to the package toplevel or per-branch. It lists account names (one per line) that get access: 1. no pkg.acl == wide open 2. empty pkg.acl == 'owner' only I. 'owner' == owners.list + owners.epel.list owner II. only the owner or the CVS admin can add/modify the acl III. owners.list is going to be locked down. 3. per-branch ACLs inherit from the toplevel ACL for the package B. e-mail notification: the package owner + anyone in the acl for the package will get e-mail notifications of all changes to said branch * For more details, please refer to the IRC log. Misc * There will be no FESCo meeting on 2007-02-01, since most of FESCo will be traveling to FUDCon that day. FESCo will have a meetup during FUDCon. * People attending the HackFest at FUDCon, please look at [WWW]http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070125 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Mon Jan 29 21:06:51 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 29 Jan 2007 23:06:51 +0200 Subject: Packages with optflags and/or debuginfo issues Message-ID: <200701292306.51269.ville.skytta@iki.fi> Quite a few packages produce useless -debuginfos nowadays. In addition to empty -debuginfos, a debuginfo package that contains some *.debug files but no sources is also quite likely not honoring $RPM_OPT_FLAGS, and if so, also very likely to have been built without compiler generated security features. Looks like reviewers should pay more attention to these issues (although they can obviously be introduced after reviews too). More info, including some suggestions how to fix common cases: http://fedoraproject.org/wiki/Packaging/Debuginfo Lists of susceptible packages in Core and Extras devel repos follows, and the crude script to produce this output is attached. The output is not 100% bleeding edge; it's run against current public repos. Some packages have already had bugs reported against them, and some already fixed in CVS. The script currently excludes *.debug installed in %{_libdir}/gcj - I suppose rpmbuild does not know how to include sources for gcj's Java *.so. ---- Core devel i386 ---- $ debuginfocheck.py development-debuginfo Importing additional filelist information Empty debuginfo packages: aspell-nl-debuginfo at-debuginfo brltty-debuginfo busybox-debuginfo byacc-debuginfo check-debuginfo dbus-sharp-debuginfo dev86-debuginfo dosfstools-debuginfo ftp-debuginfo gecko-sharp2-debuginfo gnome-mime-data-debuginfo gnu-efi-debuginfo gpart-debuginfo intltool-debuginfo ipvsadm-debuginfo iscsi-initiator-utils-debuginfo isicom-debuginfo java-1.4.2-gcj-compat-debuginfo mktemp-debuginfo nmap-debuginfo passwd-debuginfo pkgconfig-debuginfo rdesktop-debuginfo symlinks-debuginfo syslinux-debuginfo sysstat-debuginfo system-config-boot-debuginfo timidity++-debuginfo traceroute-debuginfo vconfig-debuginfo wpa_supplicant-debuginfo yp-tools-debuginfo Debuginfo packages without sources: beecrypt-debuginfo compat-gcc-296-debuginfo cpuspeed-debuginfo eclipse-cdt-debuginfo ed-debuginfo esc-debuginfo festival-debuginfo gtkhtml3-debuginfo hardlink-debuginfo ksh-debuginfo libdbi-debuginfo libdbi-drivers-debuginfo mozplugger-debuginfo nhpf-debuginfo pcmciautils-debuginfo pvm-debuginfo redhat-lsb-debuginfo rp-pppoe-debuginfo star-debuginfo statserial-debuginfo synaptics-debuginfo transfig-debuginfo xfig-debuginfo 961 debuginfo packages, 33 empty, 23 with no sources. ---- Extras devel i386 ---- $ debuginfocheck.py extras-development-debuginfo Importing additional filelist information Empty debuginfo packages: boo-debuginfo chemical-mime-data-debuginfo daap-sharp-debuginfo exaile-debuginfo factory-debuginfo freenx-debuginfo gtksourceview-sharp-debuginfo ipod-sharp-debuginfo libassuan-debuginfo libfac-debuginfo libnet-debuginfo libnet10-debuginfo libresample-debuginfo lightning-debuginfo monodevelop-debuginfo moomps-debuginfo openoffice.org-dict-cs_CZ-debuginfo plib16-debuginfo Debuginfo packages without sources: BibTool-debuginfo Canna-debuginfo HelixPlayer-debuginfo TeXmacs-debuginfo arrows-debuginfo aterm-debuginfo atlas-debuginfo bin2iso-debuginfo blender-debuginfo cfitsio-debuginfo cksfv-debuginfo clisp-debuginfo csmash-debuginfo csound-debuginfo curry-debuginfo deltarpm-debuginfo emacs-vm-debuginfo gauche-gl-debuginfo gauche-gtk-debuginfo graveman-debuginfo hdf-debuginfo hdf5-debuginfo hevea-debuginfo hfsplusutils-debuginfo highlight-debuginfo initng-debuginfo initng-ifiles-debuginfo iperf-debuginfo jogl-debuginfo kicad-debuginfo kinput2-debuginfo libreadline-java-debuginfo libtasn1-debuginfo mediawiki-debuginfo mock-debuginfo mono-debugger-debuginfo mpc-debuginfo nas-debuginfo nmh-debuginfo nqc-debuginfo oddjob-debuginfo openalpp-debuginfo osgal-debuginfo pdftk-debuginfo pgadmin3-debuginfo php-pecl-xdebug-debuginfo revelation-debuginfo tuxpaint-debuginfo vigra-debuginfo vnc-reflector-debuginfo wfut-debuginfo wings-debuginfo xkeycaps-debuginfo 1677 debuginfo packages, 18 empty, 53 with no sources. -------------- next part -------------- A non-text attachment was scrubbed... Name: debuginfocheck.py Type: application/x-python Size: 1590 bytes Desc: not available URL: From wtogami at redhat.com Mon Jan 29 22:20:50 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 29 Jan 2007 17:20:50 -0500 Subject: RFC: Mass Review Process with Flags? Message-ID: <45BE7342.1070005@redhat.com> You might have seen the "Merge Review" tickets beginning to hit fedora-package-review list. The filing would be on-going now, but we hit a snag (found non-existent owners). I am waiting for that to be corrected so this can proceed in an automated fashion. Meanwhile, I hope we can figure out this aspect, because our decision of the review process influences how the rest of the reviews should be filed. Bugzilla Ticket for Each Package ================================ We desire a paper trail to show that each package has gone through a review. We want to be able to see who reviewed and approved each package. We want to be able to refer to these tickets for historical purposes. No Tracking Bugs ================ After mulling this over a bit, I have decided that using tracking bugs with this review would be too confusing, as well as too slow to be usable in a work-flow, and would generate too much extraneous mail spam. This is simply TOO MANY bugs to work with in a single tracker. Even if we made it more confusing by splitting into six trackers, it would still be slow and annoying. Thankfully, it seems that Bugzilla flags should be a vastly superior alternative for tracking our mass review progress. Review Flags! ============= You may notice that all Fedora tickets now have the "fedora-review" flag if you are part of the fedora_bugs group in the Fedora Account System (FAS). fedora-review BLANK (not reviewed yet) fedora-review ? (review in progress) fedora-review - (rejected with reason stated in comments) fedora-review + (review approved) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225231 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225232 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225233 Please play with flipping the flags on throw-away test bugs like these. If your Bugzilla account can't see flags, then you are not a member of the fedora_bugs group. Please consider using your Bugzilla e-mail address in your Fedora Account System account so it is easier to sync up the permission. What should ASSIGNED mean? ========================== In the past we used ASSIGNED as "who the reviewer was". But flags now give us the potential for something a bit more logical. When a flag is set to any state -, ? or +, your name appears next to the flag. If the flag state changed multiple times, you can view the bug's Activity Log to see who made those changes. Querying Flags ============== Query -> Advanced -> Boolean State Flag -> is equal to -> fedora-review? Flag -> is equal to -> fedora-review- Flag -> is equal to -> fedora-review+ (or query for Package Review with a NOT of the three above to see everything with blank flags) Canned queries can show useful info like this... although in the long-term we will want to use the Bugzilla xmlrpc.cgi interface to create a nicely formatted and cached static view elsewhere. This static view can display far more bugs than the web interface. Bug Mail Subjects ================= Subject: APPROVED [Bug 225307] New: Merge Review: awesfx Subject: TAKEN [Bug 225307] New: Merge Review: awesfx Subject: REJECTED [Bug 225307] New: Merge Review: awesfx When flag states change, if you would have received mail about it, then the mail subject is customized slightly to make it more obvious at a glance. (dkl is not entirely thrilled by this part of the proposal because it would require a one-off ugly hack to Bugzilla. However, if we decide that we think this part would be VERY useful, then we can request it anyway.) (I suspect an UNTAKEN message is unnecessary, as well as grammatically incorrect?) Proposal: Review Process Using Flags ==================================== 1) Use flags exclusively for tracking the review state. Flags state who set that flag, so there is no confusion. 2) The package owner is ASSIGNED instead of the reviewer. This is more logically consistent than the past. I believe this process works, but perhaps I missed something. Thoughts? Warren Togami wtogami at redhat.com From wolfy at nobugconsulting.ro Mon Jan 29 22:43:53 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 30 Jan 2007 00:43:53 +0200 Subject: RFC: Mass Review Process with Flags? In-Reply-To: <45BE7342.1070005@redhat.com> References: <45BE7342.1070005@redhat.com> Message-ID: <45BE78A9.5020701@nobugconsulting.ro> On 01/30/2007 12:20 AM, Warren Togami wrote: > You might have seen the "Merge Review" tickets beginning to hit > fedora-package-review list. The filing would be on-going now, but we > hit a snag (found non-existent owners). I am waiting for that to be > corrected so this can proceed in an automated fashion. [...] How picky should we be with those specs? For instance none of the 4-5 I have glimpsed at have the recommended BuildRoot value, but "BuildRoot: %{_tmppath}/%{name}-root", "BuildRoot: %{_tmppath}/%{name}-%{version}-root" etc. Given the semantical meaning of "recommended" I for one have pointed out but never objected to other values than the one recommended in the packaging guidelines (especially after reading some explanations which seemed rational). However I've seen people much more experienced than me refusing to approve or even to review because of this aspect, so I would like to know if there is a definite policy about this, or we should just leave them as they are. Regards manuel From pertusus at free.fr Mon Jan 29 23:01:06 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 30 Jan 2007 00:01:06 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701292306.51269.ville.skytta@iki.fi> References: <200701292306.51269.ville.skytta@iki.fi> Message-ID: <20070129230106.GA24020@free.fr> On Mon, Jan 29, 2007 at 11:06:51PM +0200, Ville Skytt? wrote: > > libnet-debuginfo > libnet10-debuginfo These are static only library packages, so the empty debuginfo is normal here. > Debuginfo packages without sources: > BibTool-debuginfo This should be fixed now, thanks to your report, thanks Ville. -- Pat From tibbs at math.uh.edu Mon Jan 29 23:13:16 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Jan 2007 17:13:16 -0600 Subject: RFC: Mass Review Process with Flags? In-Reply-To: <45BE7342.1070005@redhat.com> References: <45BE7342.1070005@redhat.com> Message-ID: >>>>> "WT" == Warren Togami writes: WT> I believe this process works, but perhaps I missed something. Will the tickets I'm reviewing show up on my bugzilla front page? I find that page to be an important part of my workflow, especially when I have upwards of twenty reviews in flight (and surely more once the hackfest gets going). - J< From tibbs at math.uh.edu Mon Jan 29 23:31:19 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Jan 2007 17:31:19 -0600 Subject: RFC: Mass Review Process with Flags? In-Reply-To: <45BE78A9.5020701@nobugconsulting.ro> References: <45BE7342.1070005@redhat.com> <45BE78A9.5020701@nobugconsulting.ro> Message-ID: >>>>> "MW" == Manuel Wolfshant writes: MW> For instance none of the 4-5 I have glimpsed at have the MW> recommended BuildRoot value, Lack of the recommend buildroot value is not a blocker, unless the buildroot is broken somehow. For example, if it's not under /tmp or doesn't include the package name. I'm honestly not sure about whether the version needs to be there. The point is to make sure that someone doing multiple rebuilds in parallel doesn't get hosed because the packages try to write to the same place, or try to write somewhere the user can't. There was some discussion on the fedora-packaging list some time ago; perhaps the archives would be of help. - J< From pertusus at free.fr Mon Jan 29 23:35:28 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 30 Jan 2007 00:35:28 +0100 Subject: RFC: Mass Review Process with Flags? In-Reply-To: <45BE78A9.5020701@nobugconsulting.ro> References: <45BE7342.1070005@redhat.com> <45BE78A9.5020701@nobugconsulting.ro> Message-ID: <20070129233527.GB24020@free.fr> On Tue, Jan 30, 2007 at 12:43:53AM +0200, Manuel Wolfshant wrote: > 4-5 I have glimpsed at have the recommended BuildRoot value, but > "BuildRoot: %{_tmppath}/%{name}-root", "BuildRoot: > %{_tmppath}/%{name}-%{version}-root" etc. > Given the semantical meaning of "recommended" I for one have pointed > out but never objected to other values than the one recommended in the > packaging guidelines (especially after reading some explanations which > seemed rational). However I've seen people much more experienced than me > refusing to approve or even to review because of this aspect, so I would > like to know if there is a definite policy about this, or we should just > leave them as they are. Since it is not a blocker as per the guidelines you are free to do whatever you want (refuse to formally review if you don't like it or let it pass). I personally wouldn't want to accept lightly anything shorter than %{_tmppath}/%{name}-%{version}-%{release}-root because of the name clash issue, but you are free to do otherwise. -- Pat From jkeating at redhat.com Mon Jan 29 23:37:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 29 Jan 2007 18:37:40 -0500 Subject: Package EVR problems in FC+FE 2007-01-29 In-Reply-To: <1170086622.21709.46.camel@localhost.localdomain> References: <20070129134255.A627415212E@buildsys.fedoraproject.org> <200701291104.49510.jkeating@redhat.com> <1170086622.21709.46.camel@localhost.localdomain> Message-ID: <200701291837.43567.jkeating@redhat.com> On Monday 29 January 2007 11:03, Adam Jackson wrote: > Should I assume that the test2 will compose from dist-fc7? ?Because if > so I'll just wait and let that fix it. Yea, once test1 is composed, the freeze will lift and rawhide will once again compose from dist-fc7. Test2 will do the same dance, a freeze tag created and populated from a point in time from dist-fc7 (or whatever we call the collection in the new external buildsystem) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Mon Jan 29 23:52:22 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 29 Jan 2007 15:52:22 -0800 Subject: RFC: Mass Review Process with Flags? In-Reply-To: <45BE7342.1070005@redhat.com> References: <45BE7342.1070005@redhat.com> Message-ID: <1170114742.18675.133.camel@localhost.localdomain> On Mon, 2007-01-29 at 17:20 -0500, Warren Togami wrote: > Review Flags! > ============= > You may notice that all Fedora tickets now have the "fedora-review" flag > if you are part of the fedora_bugs group in the Fedora Account System (FAS). > > fedora-review BLANK (not reviewed yet) > fedora-review ? (review in progress) > fedora-review - (rejected with reason stated in comments) > fedora-review + (review approved) Looks pretty good. Can the flags be more verbose or is "single character symbol" a property of the bugzilla flags interface? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Tue Jan 30 00:32:11 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 29 Jan 2007 19:32:11 -0500 Subject: Package EVR problems in FC+FE 2007-01-29 In-Reply-To: <20070129134255.A627415212E@buildsys.fedoraproject.org> References: <20070129134255.A627415212E@buildsys.fedoraproject.org> Message-ID: <1170117131.15526.5.camel@localhost.localdomain> On Mon, 2007-01-29 at 08:42 -0500, buildsys at fedoraproject.org wrote: > stickster AT gmail.com: > gnome-sudoku > FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) > FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) This has been removed from the devel branch, as it's now included in gnome-games upstream. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- 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 peter at thecodergeek.com Tue Jan 30 02:28:10 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 29 Jan 2007 18:28:10 -0800 Subject: Package EVR problems in FC+FE 2007-01-29 In-Reply-To: <1170117131.15526.5.camel@localhost.localdomain> References: <20070129134255.A627415212E@buildsys.fedoraproject.org> <1170117131.15526.5.camel@localhost.localdomain> Message-ID: <1170124090.8217.4.camel@localhost> On Mon, 2007-01-29 at 19:32 -0500, Paul W. Frields wrote: > On Mon, 2007-01-29 at 08:42 -0500, buildsys at fedoraproject.org wrote: > > stickster AT gmail.com: > > gnome-sudoku > > FE5 > FE7 (0:0.7.1-3.fc5 > 0:0.5.0-1.fc6) > > FE6 > FE7 (0:0.7.1-3.fc6 > 0:0.5.0-1.fc6) > > This has been removed from the devel branch, as it's now included in > gnome-games upstream. In that case, you will need to add a dead.package file to it in CVS and remove it from the repo as explained in the Extras/PackageEndOfLife page on the wiki. That should stop these warnings from occuring. (But to maintain a proper upgrade path, we should bug the gnome-games maintainer to add the necessary Provides/Obsoletes to the spec.) -- Peter Gordon (codergeek42) / FSF Associate Member #5015 GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Tue Jan 30 04:03:05 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 29 Jan 2007 23:03:05 -0500 Subject: RFC: Mass Review Process with Flags? In-Reply-To: <1170114742.18675.133.camel@localhost.localdomain> References: <45BE7342.1070005@redhat.com> <1170114742.18675.133.camel@localhost.localdomain> Message-ID: <45BEC379.1030906@redhat.com> Toshio Kuratomi wrote: > On Mon, 2007-01-29 at 17:20 -0500, Warren Togami wrote: > >> Review Flags! >> ============= >> You may notice that all Fedora tickets now have the "fedora-review" flag >> if you are part of the fedora_bugs group in the Fedora Account System (FAS). >> >> fedora-review BLANK (not reviewed yet) >> fedora-review ? (review in progress) >> fedora-review - (rejected with reason stated in comments) >> fedora-review + (review approved) > > Looks pretty good. Can the flags be more verbose or is "single > character symbol" a property of the bugzilla flags interface? I think we can't easily change the single character symbol. Warren Togami wtogami at redhat.com From wtogami at redhat.com Tue Jan 30 04:04:42 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 29 Jan 2007 23:04:42 -0500 Subject: RFC: Mass Review Process with Flags? In-Reply-To: References: <45BE7342.1070005@redhat.com> Message-ID: <45BEC3DA.6030603@redhat.com> Jason L Tibbitts III wrote: >>>>>> "WT" == Warren Togami writes: > > WT> I believe this process works, but perhaps I missed something. > > Will the tickets I'm reviewing show up on my bugzilla front page? I > find that page to be an important part of my workflow, especially when > I have upwards of twenty reviews in flight (and surely more once the > hackfest gets going). > What do you mean exactly? The best way I can think of using flags to query a workflow is to use canned queries, like fedora.us/PUBLISH, fedora.us/NEEDSWORK, fedora.us/REVIEW. Warren Togami wtogami at redhat.com From wtogami at redhat.com Tue Jan 30 04:11:01 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 29 Jan 2007 23:11:01 -0500 Subject: RFC: Mass Review Process with Flags? In-Reply-To: <45BE7342.1070005@redhat.com> References: <45BE7342.1070005@redhat.com> Message-ID: <45BEC555.8050908@redhat.com> Further filing of review bugs is blocking on two issues: 1) We must decide whether or not the review should be assigned to the reviewer or package owner. I believe package owner is more logical, because that person is accountable to doing the work. The reviewer is already tracked by name in the flag itself, which too is logical. 2) Release Engineering must fix internal ticket #8521, to update the many changes from the Java team in package ownership. Warren Togami wtogami at redhat.com From ville.skytta at iki.fi Tue Jan 30 07:15:56 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 30 Jan 2007 09:15:56 +0200 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <20070129230106.GA24020@free.fr> References: <200701292306.51269.ville.skytta@iki.fi> <20070129230106.GA24020@free.fr> Message-ID: <200701300915.56609.ville.skytta@iki.fi> On Tuesday 30 January 2007 01:01, Patrice Dumas wrote: > On Mon, Jan 29, 2007 at 11:06:51PM +0200, Ville Skytt? wrote: > > libnet-debuginfo > > libnet10-debuginfo > > These are static only library packages, so the empty debuginfo is > normal here. I think it would be good to disable those explicitly with a comment in the specfile until (if?) someday rpmbuild can create useful ones for static libs. From kzak at redhat.com Tue Jan 30 09:25:52 2007 From: kzak at redhat.com (Karel Zak) Date: Tue, 30 Jan 2007 10:25:52 +0100 Subject: RFC: Mass Review Process with Flags? In-Reply-To: <45BE7342.1070005@redhat.com> References: <45BE7342.1070005@redhat.com> Message-ID: <20070130092552.GF3810@petra.dvoda.cz> Please... *every* bugzilla record should be *always* useful for a random reader. The "Merge Review:" records don't make sense for uninitiated people. There should be note or link which explain the record in the bugzilla. Sorry, these records seem like incomplete junk now. Karel On Mon, Jan 29, 2007 at 05:20:50PM -0500, Warren Togami wrote: > You might have seen the "Merge Review" tickets beginning to hit > fedora-package-review list. The filing would be on-going now, but we > hit a snag (found non-existent owners). I am waiting for that to be > corrected so this can proceed in an automated fashion. -- Karel Zak From pertusus at free.fr Tue Jan 30 09:27:10 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 30 Jan 2007 10:27:10 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701300915.56609.ville.skytta@iki.fi> References: <200701292306.51269.ville.skytta@iki.fi> <20070129230106.GA24020@free.fr> <200701300915.56609.ville.skytta@iki.fi> Message-ID: <20070130092709.GB2843@free.fr> On Tue, Jan 30, 2007 at 09:15:56AM +0200, Ville Skytt? wrote: > > I think it would be good to disable those explicitly with a comment in the > specfile until (if?) someday rpmbuild can create useful ones for static libs. I don't think so. In my opinion this is a bug in rpmbuild scripts, reported here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316 I see no reason to workaround it in my spec instead of fixing it where it should be (given that its effects are harmless). -- Pat From pertusus at free.fr Tue Jan 30 10:52:10 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 30 Jan 2007 11:52:10 +0100 Subject: RFC: Mass Review Process with Flags? In-Reply-To: <45BE7342.1070005@redhat.com> References: <45BE7342.1070005@redhat.com> Message-ID: <20070130105210.GC2843@free.fr> On Mon, Jan 29, 2007 at 05:20:50PM -0500, Warren Togami wrote: > You might have seen the "Merge Review" tickets beginning to hit > fedora-package-review list. The filing would be on-going now, but we > hit a snag (found non-existent owners). I am waiting for that to be > corrected so this can proceed in an automated fashion. The link to cvs points to the latest cvs version. It should point to the version that was put under review. -- Pat From caolanm at redhat.com Tue Jan 30 11:06:12 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Tue, 30 Jan 2007 11:06:12 +0000 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701292306.51269.ville.skytta@iki.fi> References: <200701292306.51269.ville.skytta@iki.fi> Message-ID: <1170155175.8714.1.camel@soulcrusher.caolan.org> On Mon, 2007-01-29 at 23:06 +0200, Ville Skytt? wrote: > Quite a few packages produce useless -debuginfos nowadays. In addition to > empty -debuginfos, a debuginfo package that contains some *.debug files but > no sources is also quite likely not honoring $RPM_OPT_FLAGS, and if so, also > very likely to have been built without compiler generated security features. > Looks like reviewers should pay more attention to these issues (although they > can obviously be introduced after reviews too). > > More info, including some suggestions how to fix common cases: > http://fedoraproject.org/wiki/Packaging/Debuginfo "find-debuginfo.sh processes only files that are executable when it's run" I think that another obvious reason for empty debuginfo is non owner writable .so files as well as non-executable ones. C. From opensource at till.name Tue Jan 30 14:31:34 2007 From: opensource at till.name (Till Maas) Date: Tue, 30 Jan 2007 15:31:34 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701292306.51269.ville.skytta@iki.fi> References: <200701292306.51269.ville.skytta@iki.fi> Message-ID: <200701301531.37067.opensource@till.name> On Monday 29 January 2007 22:06, Ville Skytt? wrote: > Quite a few packages produce useless -debuginfos nowadays. In addition to > empty -debuginfos, a debuginfo package that contains some *.debug files but What about -fomit-frame-pointer and -O3, that maybe breaks debuginfo, too: https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00712.html > no sources is also quite likely not honoring $RPM_OPT_FLAGS, and if so, > also very likely to have been built without compiler generated security Do $RPM_OPT_FLAGS need to be used in LDFLAGS, too? > (although they can obviously be introduced after reviews too). What to do then? I once filled a bug about this for qemu and it was closed with WONTFIX: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208026 Regards, Till From tibbs at math.uh.edu Tue Jan 30 15:31:02 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Jan 2007 09:31:02 -0600 Subject: RFC: Mass Review Process with Flags? In-Reply-To: <45BEC3DA.6030603@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC3DA.6030603@redhat.com> Message-ID: >>>>> "WT" == Warren Togami writes: WT> Jason L Tibbitts III wrote: >> Will the tickets I'm reviewing show up on my bugzilla front page? WT> What do you mean exactly? Well, currently I visit "My Bugzilla Front Page" at https://bugzilla.redhat.com/bugzilla/frontpage.cgi rather often as part of my workflow. It shows all of the issues assigned to me, opened by me or needing attention from me. - J< From ville.skytta at iki.fi Tue Jan 30 16:55:04 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 30 Jan 2007 18:55:04 +0200 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <20070130092709.GB2843@free.fr> References: <200701292306.51269.ville.skytta@iki.fi> <200701300915.56609.ville.skytta@iki.fi> <20070130092709.GB2843@free.fr> Message-ID: <200701301855.04383.ville.skytta@iki.fi> On Tuesday 30 January 2007 11:27, Patrice Dumas wrote: > On Tue, Jan 30, 2007 at 09:15:56AM +0200, Ville Skytt? wrote: > > I don't think so. In my opinion this is a bug in rpmbuild scripts, > reported here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316 There's no evidence in that bug that would suggest things will change. If you think it's a bug that can be resolved, it should be reopened, or a new one posted wherever upstream rpm tracks issues. > I see no reason to workaround it in my spec instead of fixing it where > it should be (given that its effects are harmless). The existence of this subthread is IMO a proof that it's not harmless :) From ville.skytta at iki.fi Tue Jan 30 17:29:01 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 30 Jan 2007 19:29:01 +0200 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <1170155175.8714.1.camel@soulcrusher.caolan.org> References: <200701292306.51269.ville.skytta@iki.fi> <1170155175.8714.1.camel@soulcrusher.caolan.org> Message-ID: <200701301929.01469.ville.skytta@iki.fi> On Tuesday 30 January 2007 13:06, Caolan McNamara wrote: > On Mon, 2007-01-29 at 23:06 +0200, Ville Skytt? wrote: > > > More info, including some suggestions how to fix common cases: > > http://fedoraproject.org/wiki/Packaging/Debuginfo > > "find-debuginfo.sh processes only files that are executable when it's > run" > > I think that another obvious reason for empty debuginfo is non owner > writable .so files as well as non-executable ones. That shouldn't be an issue since rpm 4.2.2, find-debuginfo.sh does this nowadays: if test -w "$f"; then strip_to_debug "${debugfn}" "$f" else chmod u+w "$f" strip_to_debug "${debugfn}" "$f" chmod u-w "$f" fi From ville.skytta at iki.fi Tue Jan 30 17:48:36 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 30 Jan 2007 19:48:36 +0200 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701301531.37067.opensource@till.name> References: <200701292306.51269.ville.skytta@iki.fi> <200701301531.37067.opensource@till.name> Message-ID: <200701301948.36287.ville.skytta@iki.fi> On Tuesday 30 January 2007 16:31, Till Maas wrote: > On Monday 29 January 2007 22:06, Ville Skytt? wrote: > > What about -fomit-frame-pointer and -O3, that maybe breaks debuginfo, too: > https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00712.html That would be a good addition to the Wiki page, but: does -O3 break it alone, or with -fomit-frame-pointer, or is it just -fomit-frame-pointer? What about other flags that could result in the same? > > no sources is also quite likely not honoring $RPM_OPT_FLAGS, and if so, > > also very likely to have been built without compiler generated security > > Do $RPM_OPT_FLAGS need to be used in LDFLAGS, too? I don't think I've ever seen it being used there. FWIW, unlike CFLAGS/CXXFLAGS/FFLAGS, %configure doesn't set LDFLAGS at all. > What to do then? I once filled a bug about this for qemu and it was closed > with WONTFIX: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208026 Maybe ask the maintainer to explain why the chosen flags are more important than working -debuginfo, and if they really are, why the packager is knowingly shipping a useless -debuginfo instead of explicitly disabling it (with a comment explaining why) in the specfile? Or forward to an appropriate committee to decide if there's no consensus? From rc040203 at freenet.de Tue Jan 30 18:30:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 30 Jan 2007 19:30:15 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701301948.36287.ville.skytta@iki.fi> References: <200701292306.51269.ville.skytta@iki.fi> <200701301531.37067.opensource@till.name> <200701301948.36287.ville.skytta@iki.fi> Message-ID: <1170181816.5838.270.camel@mccallum.corsepiu.local> On Tue, 2007-01-30 at 19:48 +0200, Ville Skytt? wrote: > On Tuesday 30 January 2007 16:31, Till Maas wrote: > > On Monday 29 January 2007 22:06, Ville Skytt? wrote: > > > > What about -fomit-frame-pointer and -O3, that maybe breaks debuginfo, too: > > https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00712.html > > That would be a good addition to the Wiki page, but: does -O3 break it alone, > or with -fomit-frame-pointer, or is it just -fomit-frame-pointer? -fomit-frame-pointer alone breaks debugging on many platforms (It causes the compiler to omit code generation to support the frame-pointer.) What -O3 does is subject to change at any time and therefore is unsafe. Those people who implemented RPM_OPT_FLAGS have reasons why they chose them the way they did - Any modification to code-generation related additions to CFLAGS therefore can't be considered lightly. > What about > other flags that could result in the same? Many -m* flags fall into same category. In most cases, they don't necessarily break "debugging". In most cases they break the ABI. > > > no sources is also quite likely not honoring $RPM_OPT_FLAGS, and if so, > > > also very likely to have been built without compiler generated security > > > > Do $RPM_OPT_FLAGS need to be used in LDFLAGS, too? > > I don't think I've ever seen it being used there. Depends on a packages details. In general, many flags also affect linkage (e.g. -m* implies the library path in a multilib'ed environment). > FWIW, unlike > CFLAGS/CXXFLAGS/FFLAGS, %configure doesn't set LDFLAGS at all. Yes, most packages link through the compiler and do not explicitly invoke the linker. Therefore, in most cases, linking also receives CFLAGS, which makes tweaking LDFLAGS unnecessary. In exotic cases (e.g. build-scripts), it can be necessary to also tweak LDFLAGS. Ralf From opensource at till.name Tue Jan 30 18:34:38 2007 From: opensource at till.name (Till Maas) Date: Tue, 30 Jan 2007 19:34:38 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701301948.36287.ville.skytta@iki.fi> References: <200701292306.51269.ville.skytta@iki.fi> <200701301531.37067.opensource@till.name> <200701301948.36287.ville.skytta@iki.fi> Message-ID: <200701301934.40094.opensource@till.name> On Tuesday 30 January 2007 18:48, Ville Skytt? wrote: > On Tuesday 30 January 2007 16:31, Till Maas wrote: > > On Monday 29 January 2007 22:06, Ville Skytt? wrote: > > > > What about -fomit-frame-pointer and -O3, that maybe breaks debuginfo, > > too: > > https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00712.htm > >l > > That would be a good addition to the Wiki page, but: does -O3 break it > alone, or with -fomit-frame-pointer, or is it just -fomit-frame-pointer? > What about other flags that could result in the same? gcc man page: | -fomit-frame-pointer | Don?t keep the frame pointer in a register for functions that | don?t need one. This avoids the instructions to save, set up and | restore frame pointers; it also makes an extra register available | in many functions. It also makes debugging impossible on some | machines. I don't really know whether or not -O3 breaks it but when I used gentoo I read that some applications may break when using -O3, but better ask someone who knows this. :-) > > > no sources is also quite likely not honoring $RPM_OPT_FLAGS, and if so, > > > also very likely to have been built without compiler generated security > > > > Do $RPM_OPT_FLAGS need to be used in LDFLAGS, too? > > I don't think I've ever seen it being used there. FWIW, unlike > CFLAGS/CXXFLAGS/FFLAGS, %configure doesn't set LDFLAGS at all. I do not really understand autoconf but it seems to me that LDFLAGS are created using CFLAGS, e.g. in beryl-core: | gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 [...] -o .libs/beryl main.o | privates.o [...] line 633 in http://buildsys.fedoraproject.org/logs/fedora-6-extras/26630-beryl-core-0.1.99.2-1.fc6/i386/build.log > > What to do then? I once filled a bug about this for qemu and it was > > closed with WONTFIX: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208026 > > Maybe ask the maintainer to explain why the chosen flags are more important > than working -debuginfo, and if they really are, why the packager is > knowingly shipping a useless -debuginfo instead of explicitly disabling it > (with a comment explaining why) in the specfile? Or forward to an > appropriate committee to decide if there's no consensus? It's speed vs security/debugging, afaik applications compiled with -fomit-frame-pointer are (slightly?) faster that compiled without it and I guess the security features slow down applications, too. I guess there is not much to discuss, either speed or security/debugging is more important. What would be the appropriate committee? fedora-packaging at redhat.com? Regards, Till From rdieter at math.unl.edu Tue Jan 30 19:02:32 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 30 Jan 2007 13:02:32 -0600 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701301934.40094.opensource@till.name> References: <200701292306.51269.ville.skytta@iki.fi> <200701301531.37067.opensource@till.name> <200701301948.36287.ville.skytta@iki.fi> <200701301934.40094.opensource@till.name> Message-ID: <45BF9648.8000109@math.unl.edu> Till Maas wrote: > It's speed vs security/debugging, afaik applications compiled > with -fomit-frame-pointer are (slightly?) faster that compiled without it and > I guess the security features slow down applications, too. I guess there is > not much to discuss, either speed or security/debugging is more important. > What would be the appropriate committee? fedora-packaging at redhat.com? > > Packaging Guidelines are already pretty clear, imo, http://fedoraproject.org/wiki/Packaging/Guidelines#head-8b14098227aebff1cf6188939e9d0877295ac448 "... Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases." -- Rex From opensource at till.name Tue Jan 30 18:58:21 2007 From: opensource at till.name (Till Maas) Date: Tue, 30 Jan 2007 19:58:21 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <1170181816.5838.270.camel@mccallum.corsepiu.local> References: <200701292306.51269.ville.skytta@iki.fi> <200701301948.36287.ville.skytta@iki.fi> <1170181816.5838.270.camel@mccallum.corsepiu.local> Message-ID: <200701301958.23203.opensource@till.name> On Tuesday 30 January 2007 19:30, Ralf Corsepius wrote: > Yes, most packages link through the compiler and do not explicitly > invoke the linker. Therefore, in most cases, linking also receives > CFLAGS, which makes tweaking LDFLAGS unnecessary. > > In exotic cases (e.g. build-scripts), it can be necessary to also tweak > LDFLAGS. So whenever linking is done whith gcc then it needs to be passed $RPM_OPT_FLAGS ? Or how do I know whether or not to tweak LDFLAGS? If you like, please take a look into my package john, because I am not sure whether or not LDFLAGS=$RPM_OPT_FLAGS are needed there but when I tested the difference it seemed that even with LDFLAGS="" the stack protection worked. Regards, Till From opensource at till.name Tue Jan 30 19:04:00 2007 From: opensource at till.name (Till Maas) Date: Tue, 30 Jan 2007 20:04:00 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <45BF9648.8000109@math.unl.edu> References: <200701292306.51269.ville.skytta@iki.fi> <200701301934.40094.opensource@till.name> <45BF9648.8000109@math.unl.edu> Message-ID: <200701302004.01797.opensource@till.name> On Tuesday 30 January 2007 20:02, Rex Dieter wrote: > Packaging Guidelines are already pretty clear, imo, It is not clear to me, what to do when violations of the Packaging Guidelines are detected or who should review changes in the flags after review time. Regards, Till From tibbs at math.uh.edu Tue Jan 30 19:05:58 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Jan 2007 13:05:58 -0600 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701302004.01797.opensource@till.name> References: <200701292306.51269.ville.skytta@iki.fi> <200701301934.40094.opensource@till.name> <45BF9648.8000109@math.unl.edu> <200701302004.01797.opensource@till.name> Message-ID: >>>>> "TM" == Till Maas writes: TM> It is not clear to me, what to do when violations of the Packaging TM> Guidelines are detected File bugs. TM> or who should review changes in the flags after review time. Anyone is free to do so. Nobody is tasked with doing so. - J< From opensource at till.name Tue Jan 30 19:18:00 2007 From: opensource at till.name (Till Maas) Date: Tue, 30 Jan 2007 20:18:00 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: References: <200701292306.51269.ville.skytta@iki.fi> <200701302004.01797.opensource@till.name> Message-ID: <200701302018.01307.opensource@till.name> On Tuesday 30 January 2007 20:05, Jason L Tibbitts III wrote: > >>>>> "TM" == Till Maas writes: > > TM> It is not clear to me, what to do when violations of the Packaging > TM> Guidelines are detected > > File bugs. I filed a bug[1], what is the next step? Regards, Till [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208026 From tibbs at math.uh.edu Tue Jan 30 19:49:40 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Jan 2007 13:49:40 -0600 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701302018.01307.opensource@till.name> References: <200701292306.51269.ville.skytta@iki.fi> <200701302004.01797.opensource@till.name> <200701302018.01307.opensource@till.name> Message-ID: >>>>> "TM" == Till Maas writes: TM> I filed a bug[1], what is the next step? Well, it's kind of obvious that the package maintainer should then deal with the bug. Is there some question that you're trying to ask without actually asking it? Or are you trying to bring up some issue without actually stating what that issue is? - J< From opensource at till.name Tue Jan 30 20:18:03 2007 From: opensource at till.name (Till Maas) Date: Tue, 30 Jan 2007 21:18:03 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: References: <200701292306.51269.ville.skytta@iki.fi> <200701302018.01307.opensource@till.name> Message-ID: <200701302118.05272.opensource@till.name> On Tuesday 30 January 2007 20:49, Jason L Tibbitts III wrote: > >>>>> "TM" == Till Maas writes: > > TM> I filed a bug[1], what is the next step? > > Well, it's kind of obvious that the package maintainer should then > deal with the bug. Ok, but what to do when the package maintainer states that he would not change it? > Is there some question that you're trying to ask without actually > asking it? Or are you trying to bring up some issue without actually > stating what that issue is? I do not completly understand where there is a problem. Initially I asked the following, maybe it helps to read it again to understand my other questions: | > (although they can obviously be introduced after reviews too). | | What to do then? I once filled a bug about this for qemu and it was closed | with WONTFIX: | | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208026 So there is the question how to proceed when one discovers a violation of the packaging guidelines and the maintainer does not want to change it. And there is also a specific issue: qemu which does not honor $RPM_OPT_FLAGS, it (maybe) destroys debuginfo with "-fomit-frame-pointer" and it does not provide the upstream license (which I only mentioned in the bug report). Regards, Till From pertusus at free.fr Tue Jan 30 20:21:13 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 30 Jan 2007 21:21:13 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701302018.01307.opensource@till.name> References: <200701292306.51269.ville.skytta@iki.fi> <200701302004.01797.opensource@till.name> <200701302018.01307.opensource@till.name> Message-ID: <20070130202113.GA2685@free.fr> On Tue, Jan 30, 2007 at 08:18:00PM +0100, Till Maas wrote: > > I filed a bug[1], what is the next step? > > Regards, > Till > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208026 Next step is to ask on public lists. We're there now. Last is to ask FESCo advice. Hopefully we won't have to go there. -- Pat From tibbs at math.uh.edu Tue Jan 30 20:38:55 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Jan 2007 14:38:55 -0600 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701302118.05272.opensource@till.name> References: <200701292306.51269.ville.skytta@iki.fi> <200701302018.01307.opensource@till.name> <200701302118.05272.opensource@till.name> Message-ID: >>>>> "TM" == Till Maas writes: TM> Ok, but what to do when the package maintainer states that he TM> would not change it? Talk to the co-maintainer, then the maintainer's sponsor and, if necessary, bring the issue before FESCo. (Note in this case that there seems to be no sponsor for the package's maintainer.) TM> So there is the question how to proceed when one discovers a TM> violation of the packaging guidelines and the maintainer does not TM> want to change it. Well, there are multiple issues here. Fortunately all of the core packages will all have to be reviewed before becoming part of Fedora 7, so these issues will get fixed one way or another. I suspect that qemu may have valid performance concerns that those who understand the issues will have to discuss. (The license bit is pretty simple; if it's in the upstream tarball then it must be in the package; there's no flexibility here.) Could you check back later in the week for the review ticket to be opened and then mention your open ticket in that bug? That way the reviewer is sure to see it. You can even join in the mass review if you like. - J< From opensource at till.name Tue Jan 30 20:49:18 2007 From: opensource at till.name (Till Maas) Date: Tue, 30 Jan 2007 21:49:18 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: References: <200701292306.51269.ville.skytta@iki.fi> <200701302118.05272.opensource@till.name> Message-ID: <200701302149.19911.opensource@till.name> On Tuesday 30 January 2007 21:38, Jason L Tibbitts III wrote: > Well, there are multiple issues here. Fortunately all of the core > packages will all have to be reviewed before becoming part of Fedora > 7, so these issues will get fixed one way or another. > Could you check back later in the week for the review ticket to be > opened and then mention your open ticket in that bug? That way the > reviewer is sure to see it. You can even join in the mass review if > you like. Qemu is an Extras package, will these get a new review, too? Regards, Till From tibbs at math.uh.edu Tue Jan 30 21:33:06 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Jan 2007 15:33:06 -0600 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701302149.19911.opensource@till.name> References: <200701292306.51269.ville.skytta@iki.fi> <200701302118.05272.opensource@till.name> <200701302149.19911.opensource@till.name> Message-ID: >>>>> "TM" == Till Maas writes: TM> Qemu is an Extras package, will these get a new review, too? Sorry, I was confused; it won't be re-reviewed as part of this mass review. - J< From kevin at tummy.com Tue Jan 30 21:36:36 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Tue, 30 Jan 2007 14:36:36 -0700 Subject: WorldWide ReviewDays this weekend Message-ID: <20070130143636.743d687f@ningauble.scrye.com> Fedora Worldwide Review Days As part of the upcoming merge of Fedora Core and Fedora Extras, and in concert with FudconBoston, the Fedora project is happy to announce the Fedora Worldwide Review days. Whats a Review Day? A Review day is a day where interested parties gather on irc (or in person at FudconBoston) and review a number of Fedora packages that are awaiting review. Each package will be checked against the current Fedora package guidelines. All of the formerly Fedora Core packages will be up for review this weekend. Why have a review Day? * All the formerly Fedora Core packages will need to be reviewed and checked for compliance with the latest guidelines. If you have ever seen packaging problems with your favorite package, now might be a good time to assist reviewing it. * Interested parties will know to meet other reviewers on a central irc channel or in person at FudconBoston. * Questions about reviews or procedures can be answered quickly on channel. Input on core package reviews can be sent to the package maintainer as part of the review. Where are the Wordwide Review Days? Worldwide Review Days will be done via IRC on the irc.freenode.net IRC network, in channel #fedora-extras. Additionally there will be a number of reviewers and members of the Fedora packaging Commitee physically present at the HackFest sessions after FudconBoston, as well as available on IRC to answer questions or provide assistance. See: http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest If you are available and would like to be invited to the physical HackFest in Boston. When will the Worldwide Review Days be held? The Worldwide Review days will be this Saturday and Sunday (2007-02-03 and 2007-02-04), starting around 9:30am EST. See: http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest for more on the schedule. How does it work? Simply join the irc channel. Folks there will be able to point you to a list of packages needing review. If you are a Fedora Maintainer already you should be able to review and approve packages from that list once you are sure they meet all the guidelines. If you are not currently a Fedora Maintainer, you can still provide valuable input on reviews and help us make all our packages better. Note that many people check IRC only every once in a while. Don't be discouraged if you don't see an immediate reply. Ask your question and leave your IRC window open to collect replies as people have time to do so. Also, it's better to ask your questions and wait than to ask if anyone is there or if you can ask questions. Helpful Links general IRC information: http://www.tldp.org/HOWTO/IRC/beginners.html irc.freenode.net information: http://fedoraproject.org/wiki/Communicate FudConBoston: http://barcamp.org/FudconBoston2007 HackFest: http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest WorldWideReviewDays: http://www.fedoraproject.org/wiki/Extras/WorldWideReviewDays -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jan 30 22:47:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 30 Jan 2007 17:47:45 -0500 Subject: Fedora Release Engineering Message-ID: <200701301747.48619.jkeating@redhat.com> As we gear up toward a merged world where the entire Fedora community gets to play in the same sandbox, I wanted to create a document that outlines some of what Release Engineering means to Fedora, as well as give folks an idea of what it might mean to be a part of the team. I've created something of a rough draft that I would like to fine tune over the next few months, and I'm happy to talk to anybody about any particular part of it. I know that some of you have expressed interest in helping me to accomplish some of these tasks, as such I've signed up to do a FUDCon session on Friday regarding Fedora release engineering. I hope to have somebody in the audience also be on IRC to relay questions/answers much like during Fedora Board meetings and such. Anyway, here is the "manifesto": http://fedoraproject.org/wiki/JesseKeating/RelEng This obviously isn't going to be the final home, but it is just the working home for it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Tue Jan 30 23:03:11 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Jan 2007 18:03:11 -0500 Subject: new features in package CVS Message-ID: <20070130230311.GA16319@nostromo.devel.redhat.com> Tonight we're planning on deploying a couple of new features in CVS for packages. If you read the FESCo meeting notes, you've already heard about them. 1) ACLs To add an ACL to your package, add a 'pkg.acl' file to either the package toplevel, or to a particular branch, such as FC-6 or devel. ACLs are inherited; branches will inherit ACLs from the toplevel. The ACL file format is simply a list of account names, one per line. You can add comment lines with '#'. Access is determined as follows: No pkg.acl file: all are allowed access Empty pkg.acl file: only the package owner [1] is allowed access. Populated pkg.acl file: only the package owner and those in the file are allowed access. pkg.acl files can only be added/deleted/modified by the package owner. As part of this change, there are two changes to how certain processes will work: - owners.list and owners.epel.list are now locked down. To request changes, please send mail to cvsadmin-members at fedoraproject.org. (This may be replaced with the wiki or the ticketing system really fast.) - packages, by default, on import will have a empty pkg.acl added. These can be removed by the owner if they truly wish. 2) E-mail notification By defalt, e-mail notification will now be sent on all package commits to the package owner, and any co-maintainers listed in the pkg.acl files. The format will be exactly the same format as is sent to the commits list. Bill [1] 'Package owner' is defined as the union of the owners listed in owners.list and owners.epel.list From opensource at till.name Tue Jan 30 23:22:09 2007 From: opensource at till.name (Till Maas) Date: Wed, 31 Jan 2007 00:22:09 +0100 Subject: new features in package CVS In-Reply-To: <20070130230311.GA16319@nostromo.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> Message-ID: <200701310022.10559.opensource@till.name> On Wednesday 31 January 2007 00:03, Bill Nottingham wrote: > - owners.list and owners.epel.list are now locked down. To request > changes, please send mail to cvsadmin-members at fedoraproject.org. > (This may be replaced with the wiki or the ticketing system really > fast.) > > - packages, by default, on import will have a empty pkg.acl added. > These can be removed by the owner if they truly wish. How does importing a new package work now? Does one need to ask for addition to owners.list now, first? Oder does importing still work for everyone? And does the maintainer of a new package need to wait till he is added to owners.list before he can change anything in his new package tree or will the import script add one automatically to owners.list for the new package? Regards, Till From peter at thecodergeek.com Tue Jan 30 23:48:00 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 30 Jan 2007 15:48:00 -0800 (PST) Subject: new features in package CVS In-Reply-To: <20070130230311.GA16319@nostromo.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> Message-ID: <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> Bill Nottingham wrote: > To add an ACL to your package, add a 'pkg.acl' file to either > the package toplevel, or to a particular branch, such as FC-6 > or devel. ACLs are inherited; branches will inherit ACLs from > the toplevel. > Is this ACL for CVS access only, or also for build submissions? What about the current initialcclist column of owners.list? That's how I comaintain a package (epiphany-extensions). Thanks. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From tgl at redhat.com Wed Jan 31 00:05:42 2007 From: tgl at redhat.com (Tom Lane) Date: Tue, 30 Jan 2007 19:05:42 -0500 Subject: new features in package CVS In-Reply-To: <20070130230311.GA16319@nostromo.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> Message-ID: <13526.1170201942@sss.pgh.pa.us> Bill Nottingham writes: > Access is determined as follows: > No pkg.acl file: all are allowed access OK, but then the default for existing packages is to be wide open :-(. Or are you auto-creating empty pkg.acl file for all existing packages, as well as new imports? I hope the answer is yes, so we don't all have to scramble to close up our packages. regards, tom lane From pertusus at free.fr Wed Jan 31 00:04:40 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 31 Jan 2007 01:04:40 +0100 Subject: new features in package CVS In-Reply-To: <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> Message-ID: <20070131000440.GA4113@free.fr> On Tue, Jan 30, 2007 at 03:48:00PM -0800, Peter Gordon wrote: > > What about the current initialcclist column of owners.list? That's how I > comaintain a package (epiphany-extensions). adresses listed in initialcclist may be adresses of people different from comaintainers (upstream, sig, whatever). So this cannot be used for ACLs. -- Pat From tibbs at math.uh.edu Wed Jan 31 00:43:36 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Jan 2007 18:43:36 -0600 Subject: new features in package CVS In-Reply-To: <13526.1170201942@sss.pgh.pa.us> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> Message-ID: >>>>> "TL" == Tom Lane writes: TL> OK, but then the default for existing packages is to be wide open TL> :-(. Yes, thankfully. Otherwise we would have a massive change in behavior overnight. TL> Or are you auto-creating empty pkg.acl file for all existing TL> packages, as well as new imports? Hopefully not. TL> I hope the answer is yes, so we don't all have to scramble to TL> close up our packages. Why on earth would you want to? We've not had any access control for all this time (and with amazingly good results, I might add), and all of a sudden you'd have to scramble to close things down? If you do nothing to impose ACLs on your packages, no behavior will change. You'll not somehow be less secure. The one concern I have is the ability of package maintainers to lock out too many people, such as the security team or those of us who just go through and fix problems in packages. - J< From steve at silug.org Wed Jan 31 00:49:46 2007 From: steve at silug.org (Steven Pritchard) Date: Tue, 30 Jan 2007 18:49:46 -0600 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701292306.51269.ville.skytta@iki.fi> References: <200701292306.51269.ville.skytta@iki.fi> Message-ID: <20070131004946.GA19041@osiris.silug.org> On Mon, Jan 29, 2007 at 11:06:51PM +0200, Ville Skytt? wrote: > tuxpaint-debuginfo Should be fixed now. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From a.badger at gmail.com Wed Jan 31 00:51:05 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 30 Jan 2007 16:51:05 -0800 Subject: new features in package CVS In-Reply-To: <20070130230311.GA16319@nostromo.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> Message-ID: <1170204665.18675.216.camel@localhost.localdomain> On Tue, 2007-01-30 at 18:03 -0500, Bill Nottingham wrote: > Tonight we're planning on deploying a couple of new features in > CVS for packages. If you read the FESCo meeting notes, you've > already heard about them. > > 1) ACLs > > To add an ACL to your package, add a 'pkg.acl' file to either > the package toplevel, or to a particular branch, such as FC-6 > or devel. ACLs are inherited; branches will inherit ACLs from > the toplevel. > > The ACL file format is simply a list of account names, one per > line. You can add comment lines with '#'. > Which account name? Fedora Account System name or something different? > Access is determined as follows: > > No pkg.acl file: all are allowed access > > Empty pkg.acl file: only the package owner [1] is allowed access. > > Populated pkg.acl file: only the package owner and those in > the file are allowed access. > > pkg.acl files can only be added/deleted/modified by the package > owner. > > As part of this change, there are two changes to how certain > processes will work: > > - owners.list and owners.epel.list are now locked down. To request > changes, please send mail to cvsadmin-members at fedoraproject.org. > (This may be replaced with the wiki or the ticketing system really > fast.) > Additions to initialcclist go through this as well? Are there any changes to the format of owners.list? > - packages, by default, on import will have a empty pkg.acl added. > These can be removed by the owner if they truly wish. > Are there methods for adding groups to acls that can't be removed by the package maintainer? Extras has policy to allow sponsors to make changes to other people's packages if there's a need. > 2) E-mail notification > > By defalt, e-mail notification will now be sent on all package > commits to the package owner, and any co-maintainers listed in > the pkg.acl files. The format will be exactly the same format > as is sent to the commits list. Cool. Is the code tucked away in a cvs repo or on the server where I can take a look? (I'll need to pull acls from this system into the packagedb and also allow setting the acls from the packagedb.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jgarzik at redhat.com Wed Jan 31 01:05:01 2007 From: jgarzik at redhat.com (Jeff Garzik) Date: Tue, 30 Jan 2007 20:05:01 -0500 Subject: new features in package CVS In-Reply-To: <13526.1170201942@sss.pgh.pa.us> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> Message-ID: <20070131010501.GN893@devserv.devel.redhat.com> On Tue, Jan 30, 2007 at 07:05:42PM -0500, Tom Lane wrote: > OK, but then the default for existing packages is to be wide open :-(. That's the current default, from the beginning of time until today. Jeff From notting at redhat.com Wed Jan 31 02:05:40 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Jan 2007 21:05:40 -0500 Subject: new features in package CVS In-Reply-To: <1170204665.18675.216.camel@localhost.localdomain> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <1170204665.18675.216.camel@localhost.localdomain> Message-ID: <20070131020539.GC18505@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > > The ACL file format is simply a list of account names, one per > > line. You can add comment lines with '#'. > > Which account name? Fedora Account System name or something different? Account system name, aka cvs account name, etc. > > As part of this change, there are two changes to how certain > > processes will work: > > > > - owners.list and owners.epel.list are now locked down. To request > > changes, please send mail to cvsadmin-members at fedoraproject.org. > > (This may be replaced with the wiki or the ticketing system really > > fast.) > > > > Additions to initialcclist go through this as well? They'd have to, yes. > Are there any changes to the format of owners.list? Not knowing what else parses it, I wasn't going to change it. The scripts that are doing this support multiple comma-separated owners in the owners field, but I figure that would break *something*. > > - packages, by default, on import will have a empty pkg.acl added. > > These can be removed by the owner if they truly wish. > > Are there methods for adding groups to acls that can't be removed by the > package maintainer? Extras has policy to allow sponsors to make changes > to other people's packages if there's a need. Not at the moment. That may need to wait for more dynamic things like the package database. Bill From notting at redhat.com Wed Jan 31 02:10:14 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Jan 2007 21:10:14 -0500 Subject: new features in package CVS In-Reply-To: <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> Message-ID: <20070131021014.GE18505@nostromo.devel.redhat.com> Peter Gordon (peter at thecodergeek.com) said: > > To add an ACL to your package, add a 'pkg.acl' file to either > > the package toplevel, or to a particular branch, such as FC-6 > > or devel. ACLs are inherited; branches will inherit ACLs from > > the toplevel. > > Is this ACL for CVS access only, or also for build submissions? CVS, at the moment. > What about the current initialcclist column of owners.list? That's how I > comaintain a package (epiphany-extensions). As initialcclist is used to feed into bugzilla, it contains e-mail addresses for people who aren't in the account system at all; ergo, it's ignored for this. Bill From rc040203 at freenet.de Wed Jan 31 03:15:11 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 31 Jan 2007 04:15:11 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <200701301958.23203.opensource@till.name> References: <200701292306.51269.ville.skytta@iki.fi> <200701301948.36287.ville.skytta@iki.fi> <1170181816.5838.270.camel@mccallum.corsepiu.local> <200701301958.23203.opensource@till.name> Message-ID: <1170213312.5838.291.camel@mccallum.corsepiu.local> On Tue, 2007-01-30 at 19:58 +0100, Till Maas wrote: > On Tuesday 30 January 2007 19:30, Ralf Corsepius wrote: > > > Yes, most packages link through the compiler and do not explicitly > > invoke the linker. Therefore, in most cases, linking also receives > > CFLAGS, which makes tweaking LDFLAGS unnecessary. > > > > In exotic cases (e.g. build-scripts), it can be necessary to also tweak > > LDFLAGS. > > So whenever linking is done whith gcc then it needs to be passed > $RPM_OPT_FLAGS ? Yes. Probably 99.9% of all existing Makefiles automatically do so. > Or how do I know whether or not to tweak LDFLAGS? By checking build logs. Normally you'll see build errors ("Missing symbols", "wrong architecture" or similar if something doesn't work. > If you like, please take a look into my package john, because I am not sure > whether or not LDFLAGS=$RPM_OPT_FLAGS are needed there but when I tested the > difference it seemed that even with LDFLAGS="" the stack protection worked. Ralf From jkeating at redhat.com Wed Jan 31 03:16:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 30 Jan 2007 22:16:59 -0500 Subject: rawhide unfrozen Message-ID: <200701302216.59497.jkeating@redhat.com> This evening I "unfroze" rawhide. This is because the F7 Test1 bits are finally on their way to the mirrors. Tonight's rawhide spin will pick up all the new packages that have been built over the past week~ during the freeze. This will make rawhide newer than test 1, for those of you thinking about doing an upgrade. Let the breaking begin! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Wed Jan 31 04:01:48 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 31 Jan 2007 05:01:48 +0100 Subject: new features in package CVS In-Reply-To: <20070131021014.GE18505@nostromo.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> <20070131021014.GE18505@nostromo.devel.redhat.com> Message-ID: <1170216109.5838.294.camel@mccallum.corsepiu.local> On Tue, 2007-01-30 at 21:10 -0500, Bill Nottingham wrote: > Peter Gordon (peter at thecodergeek.com) said: > > > To add an ACL to your package, add a 'pkg.acl' file to either > > > the package toplevel, or to a particular branch, such as FC-6 > > > or devel. ACLs are inherited; branches will inherit ACLs from > > > the toplevel. > > > > Is this ACL for CVS access only, or also for build submissions? > > CVS, at the moment. > > > What about the current initialcclist column of owners.list? That's how I > > comaintain a package (epiphany-extensions). > > As initialcclist is used to feed into bugzilla, it contains e-mail > addresses for people who aren't in the account system at all; ergo, > it's ignored for this. i.e. any attempts to co-maintainership has just been killed. Ralf From wtogami at redhat.com Wed Jan 31 04:06:02 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 30 Jan 2007 23:06:02 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45BEC555.8050908@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> Message-ID: <45C015AA.6070008@redhat.com> Warren Togami wrote: > Further filing of review bugs is blocking on two issues: > > 1) We must decide whether or not the review should be assigned to the > reviewer or package owner. I believe package owner is more logical, > because that person is accountable to doing the work. The reviewer is > already tracked by name in the flag itself, which too is logical. OK, it seems the only real drawback to "ASSIGNED to owner instead of reviewer" is Tibbs' good point about being able to see it on frontpage.cgi. https://bugzilla.redhat.com/bugzilla/request.cgi dkl mentioned this interface that provides a way to query for flags. He said that we can add a query like this to frontpage.cgi later after we figure out exactly what we want to do. This would take care of the personal work-flow tracking case. Other canned queries can take care of the general "see everything in this state" case. I believe we should go ahead with this as the package review process for not only the mass review, but all future reviews. Steps to make this happen: 1) File the mass review bugs, auto-assigned to the package owners. 2) FESCO should discuss and vote to ratify this process change. 3) Documentation should be updated. I'd like to go ahead with filing step #1 on Wednesday. Thoughts? Warren Togami wtogami at redhat.com From notting at redhat.com Wed Jan 31 04:04:08 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Jan 2007 23:04:08 -0500 Subject: new features in package CVS In-Reply-To: <1170216109.5838.294.camel@mccallum.corsepiu.local> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> <20070131021014.GE18505@nostromo.devel.redhat.com> <1170216109.5838.294.camel@mccallum.corsepiu.local> Message-ID: <20070131040407.GA20841@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > > > What about the current initialcclist column of owners.list? That's how I > > > comaintain a package (epiphany-extensions). > > > > As initialcclist is used to feed into bugzilla, it contains e-mail > > addresses for people who aren't in the account system at all; ergo, > > it's ignored for this. > > i.e. any attempts to co-maintainership has just been killed. Whaaaaa? Heck, I already have a list of 17 co-maintainers for 500 packages to add when we get packages moved over (yikes). The problem is, inital cc list can't just be imported, as there are e-mail addresses in there that aren't in the account system, aren't fedora maintainers, etc. If you'd like, we can add multiple owners in the owner section of owners.list - I'm just afraid that that's going to break someone else's scripts. Bill From notting at redhat.com Wed Jan 31 04:05:48 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Jan 2007 23:05:48 -0500 Subject: new features in package CVS In-Reply-To: <200701310022.10559.opensource@till.name> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <200701310022.10559.opensource@till.name> Message-ID: <20070131040548.GB20841@nostromo.devel.redhat.com> Till Maas (opensource at till.name) said: > And > does the maintainer of a new package need to wait till he is added to > owners.list before he can change anything in his new package tree Pretty much, yeah. We want to get this fixed to be sane, for sure. Bill From rc040203 at freenet.de Wed Jan 31 04:20:43 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 31 Jan 2007 05:20:43 +0100 Subject: new features in package CVS In-Reply-To: <20070131040407.GA20841@nostromo.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> <20070131021014.GE18505@nostromo.devel.redhat.com> <1170216109.5838.294.camel@mccallum.corsepiu.local> <20070131040407.GA20841@nostromo.devel.redhat.com> Message-ID: <1170217243.5838.302.camel@mccallum.corsepiu.local> On Tue, 2007-01-30 at 23:04 -0500, Bill Nottingham wrote: > Ralf Corsepius (rc040203 at freenet.de) said: > > > > What about the current initialcclist column of owners.list? That's how I > > > > comaintain a package (epiphany-extensions). > > > > > > As initialcclist is used to feed into bugzilla, it contains e-mail > > > addresses for people who aren't in the account system at all; ergo, > > > it's ignored for this. > > > > i.e. any attempts to co-maintainership has just been killed. > > Whaaaaa? Heck, I already have a list of 17 co-maintainers for 500 packages > to add when we get packages moved over (yikes). > > The problem is, inital cc list can't just be imported, as there are > e-mail addresses in there that aren't in the account system, aren't > fedora maintainers, etc. Yes ... > If you'd like, we can add multiple owners in the owner section of > owners.list - I'm just afraid that that's going to break someone > else's scripts. Adding oneself to initialcc-list had been the way to denote co-maintainership in FE - It had rarely been used, but it had been used (I did). Also, I am sorry, finding this acl and "ask before import" to be counter-productive and non-helpful. 1. It's yet another bureaucratic hurdle to drive people away from Fedora. 2. It's a big push away from "collaboration" towards "province dukes controlling their packages/fencing off against others". 3. How do you want to handle "emergency situations"? In the past, I've repeatedly silently intervened into packages, if they were causing damage. Ralf From tgl at redhat.com Wed Jan 31 04:52:44 2007 From: tgl at redhat.com (Tom Lane) Date: Tue, 30 Jan 2007 23:52:44 -0500 Subject: new features in package CVS In-Reply-To: <20070131010501.GN893@devserv.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> Message-ID: <15572.1170219164@sss.pgh.pa.us> Jeff Garzik writes: > On Tue, Jan 30, 2007 at 07:05:42PM -0500, Tom Lane wrote: >> OK, but then the default for existing packages is to be wide open :-(. > That's the current default, from the beginning of time until today. Yeah, but that default has been for developers *within Red Hat* to have open access to each other's packages. Perhaps I'm not understanding something, but I thought that the brave new world was going to involve anyone who'd signed up for a Fedora account to have commit access to our CVS. I am prepared to trust other people within Red Hat, but not just any J. Random Hacker. regards, tom lane From j.w.r.degoede at hhs.nl Wed Jan 31 07:43:25 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 31 Jan 2007 08:43:25 +0100 Subject: new features in package CVS In-Reply-To: <13526.1170201942@sss.pgh.pa.us> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> Message-ID: <45C0489D.6040303@hhs.nl> Tom Lane wrote: > Bill Nottingham writes: >> Access is determined as follows: >> No pkg.acl file: all are allowed access > > OK, but then the default for existing packages is to be wide open :-(. > Or are you auto-creating empty pkg.acl file for all existing packages, > as well as new imports? I hope the answer is yes, so we don't all have > to scramble to close up our packages. > I for one don't mind my 98 (I really should get 2 more 100 sounds so much better) packages being open. Up until now that has caused 0 problems and allowed other todo things like rebuilds for a new python while I was busy/away. I think having ACL's is good, but having them created as closed by default is BAD. Regards, Hans From j.w.r.degoede at hhs.nl Wed Jan 31 07:46:47 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 31 Jan 2007 08:46:47 +0100 Subject: new features in package CVS In-Reply-To: <15572.1170219164@sss.pgh.pa.us> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> Message-ID: <45C04967.8060608@hhs.nl> Tom Lane wrote: > Jeff Garzik writes: >> On Tue, Jan 30, 2007 at 07:05:42PM -0500, Tom Lane wrote: >>> OK, but then the default for existing packages is to be wide open :-(. > >> That's the current default, from the beginning of time until today. > > Yeah, but that default has been for developers *within Red Hat* to have > open access to each other's packages. Perhaps I'm not understanding > something, but I thought that the brave new world was going to involve > anyone who'd signed up for a Fedora account to have commit access to our > CVS. > > I am prepared to trust other people within Red Hat, but not just any > J. Random Hacker. > > regards, tom lane Why thank you for the compliment and for trusting the community. I'll gladly admit not everyone with a CVS account has excellent packaging skills, but everyone has gone through the sponsorship process and just has been tested to have some packaging skills and more importantly to be thrustworthy. As said I maintain 98 packages, and have had none of them touched in a harmfull way. Just because someone is a beginning packager doesn't mean that he will start submitting random changes to other peoples packages. Regards, Hans From j.w.r.degoede at hhs.nl Wed Jan 31 07:51:19 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 31 Jan 2007 08:51:19 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <20070129230106.GA24020@free.fr> References: <200701292306.51269.ville.skytta@iki.fi> <20070129230106.GA24020@free.fr> Message-ID: <45C04A77.7050007@hhs.nl> Patrice Dumas wrote: > On Mon, Jan 29, 2007 at 11:06:51PM +0200, Ville Skytt? wrote: >> libnet-debuginfo >> libnet10-debuginfo > > These are static only library packages, so the empty debuginfo is > normal here. > Why o why? It isn't that hard to patch upstream's makefiles to create .so 's and get all the benefits of those (including working debugging). I've done this for a handfull of libraries I maintain without any ill side effect. Beware though when you do this you must carefully inspect new upstream releases for any ABI breakage. Regards, Hans From j.w.r.degoede at hhs.nl Wed Jan 31 07:58:48 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 31 Jan 2007 08:58:48 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <20070130202113.GA2685@free.fr> References: <200701292306.51269.ville.skytta@iki.fi> <200701302004.01797.opensource@till.name> <200701302018.01307.opensource@till.name> <20070130202113.GA2685@free.fr> Message-ID: <45C04C38.1070704@hhs.nl> Patrice Dumas wrote: > On Tue, Jan 30, 2007 at 08:18:00PM +0100, Till Maas wrote: >> I filed a bug[1], what is the next step? >> >> Regards, >> Till >> >> [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208026 > > Next step is to ask on public lists. We're there now. Last is to > ask FESCo advice. Hopefully we won't have to go there. > I'm sort of co-maintaining qemu, I've added a comment to this bug to try to get this sorted out. Also I'm a bit annoyed about this public naming and shaming of this bug, without first properly discussing this. This bug has only 1 comment and that is from the maintainer: "Feel free to provide a tested patch which doesn't affect performance" After which he closed it. IOW he gave the reporter plenty of room to start a discussion about this. But instead the reporter has choosen to start complaining about it here. Not a good move IMHO. Regards, Hans From pertusus at free.fr Wed Jan 31 08:33:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 31 Jan 2007 09:33:36 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <45C04A77.7050007@hhs.nl> References: <200701292306.51269.ville.skytta@iki.fi> <20070129230106.GA24020@free.fr> <45C04A77.7050007@hhs.nl> Message-ID: <20070131083336.GA2687@free.fr> On Wed, Jan 31, 2007 at 08:51:19AM +0100, Hans de Goede wrote: > > Why o why? It isn't that hard to patch upstream's makefiles to create > .so 's and get all the benefits of those (including working debugging). > > I've done this for a handfull of libraries I maintain without any ill > side effect. Beware though when you do this you must carefully inspect > new upstream releases for any ABI breakage. If upstream changes its mind and starts doing shared libraries, you are in trouble. So it is better, in my opinion to work with upstream to try to have shared libraries, than try to do your own, except when you are sure that upstream is dead and nobody will restart the project. -- Pat From j.w.r.degoede at hhs.nl Wed Jan 31 08:46:33 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 31 Jan 2007 09:46:33 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <20070131083336.GA2687@free.fr> References: <200701292306.51269.ville.skytta@iki.fi> <20070129230106.GA24020@free.fr> <45C04A77.7050007@hhs.nl> <20070131083336.GA2687@free.fr> Message-ID: <45C05769.8060702@hhs.nl> Patrice Dumas wrote: > On Wed, Jan 31, 2007 at 08:51:19AM +0100, Hans de Goede wrote: >> Why o why? It isn't that hard to patch upstream's makefiles to create >> .so 's and get all the benefits of those (including working debugging). >> >> I've done this for a handfull of libraries I maintain without any ill >> side effect. Beware though when you do this you must carefully inspect >> new upstream releases for any ABI breakage. > > If upstream changes its mind and starts doing shared libraries, you are > in trouble. So it is better, in my opinion to work with upstream to try > to have shared libraries, than try to do your own, except when you are > sure that upstream is dead and nobody will restart the project. > Agreed, you should always ask upstream but in some cases, upstream is either dead or simply refuses todo dynamic libs (plib for example). Regards, Hans From dwmw2 at infradead.org Wed Jan 31 08:45:04 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 31 Jan 2007 08:45:04 +0000 Subject: qemu optflags In-Reply-To: <45C04C38.1070704@hhs.nl> References: <200701292306.51269.ville.skytta@iki.fi> <200701302004.01797.opensource@till.name> <200701302018.01307.opensource@till.name> <20070130202113.GA2685@free.fr> <45C04C38.1070704@hhs.nl> Message-ID: <1170233104.29759.233.camel@pmac.infradead.org> On Wed, 2007-01-31 at 08:58 +0100, Hans de Goede wrote: > I'm sort of co-maintaining qemu, I've added a comment to this bug to try > to get this sorted out. Also I'm a bit annoyed about this public naming > and shaming of this bug, without first properly discussing this. But how can we discuss it without referring to it :) > This bug has only 1 comment and that is from the maintainer: > > "Feel free to provide a tested patch which doesn't affect performance" > After which he closed it. IOW he gave the reporter plenty of room to > start a discussion about this. But instead the reporter has choosen to > start complaining about it here. Not a good move IMHO. I don't mind much where the discussion happens, although it's best to Cc me if it's on a mailing list. In fact, using the mailing list may entice other capable people to look at the problem so maybe it's not such a bad move. I'll elucidate, shall I? Let's start with an excerpt from the changelog for the package in question... * Sat Mar 18 2006 David Woodhouse 0.8.0-5 - Just drop $RPM_OPT_FLAGS. They're too much of a PITA * Sat Mar 18 2006 David Woodhouse 0.8.0-4 - Disable stack-protector options which gcc 3.2 doesn't like * Fri Mar 17 2006 David Woodhouse 0.8.0-3 - Use -mcpu= instead of -mtune= on x86_64 too - Disable SPARC targets on x86_64, because dyngen doesn't like fnegs * Fri Mar 17 2006 David Woodhouse 0.8.0-2 - Don't use -mtune=pentium4 on i386. GCC 3.2 doesn't like it * Fri Mar 17 2006 David Woodhouse 0.8.0-1 - Update to 0.8.0 - Resort to using compat-gcc-32 - Enable ALSA * Mon May 16 2005 David Woodhouse 0.7.0-2 - Proper fix for GCC 4 putting 'blr' or 'ret' in the middle of the function, for i386, x86_64 and PPC. * Sat Apr 30 2005 David Woodhouse 0.7.0-1 - Update to 0.7.0 - Fix dyngen for PPC functions which end in unconditional branch Qemu is, as stated, a pain in the arse. It's _very_ dependent on compiler output, because of the way it takes 'snippets' of code from tiny functions and uses those as the building blocks for its translation. In particular, we can't use GCC 4.x for it, because that'll tend to insert 'blr' instructions in the middle of function calls rather than jumping to the end and having only a single return -- and that really makes qemu unhappy when it just knocks the 'blr' off the end and sticks those blocks of code together sequentially. When we used GCC 4 I think there was also a problem with global register variables on some crappy arch with too few registers too. There's work on making qemu happy with current compilers, but it's not ready yet. I've poked at it myself on occasion, as evidenced above, but there's _always_ something more important to do and something else that goes wrong with it just when you think it's OK. And the work I _have_ done on qemu recently has been on NPTL support in the qemu-user tools, so you can actually run current userspace (I want i386 flash plugin in qemu in nspluginwrapper in my ppc firefox, and I actually have it just about working). So we can't "just use $RPM_OPT_FLAGS" because some of those flags don't work with the older compiler. Although there _is_ a possibility of using one compiler for dyngen and another for qemu proper, which could perhaps be investigated. The bit about -fomit-frame-pointer I wasn't really paying much attention to -- I never debug on i386 anyway, and in fact I rarely debug qemu itself; more often I want to debug the stuff I run _in_ it. The above-quoted sentence should be taken with emphasis on the "provide a tested patch" part rather than the "doesn't affect performance" part. And in the context of the changelog... And it should be taken at face value -- really, feel free to provide a patch. It wasn't just a brush-off. It's not that I don't want to do it. It's not (just) that I'm lazy. It's that I tried, and I failed, and I ended up reverting to what we have at the moment. There is probably room for improvement -- perhaps by using GCC 4 for most of it but GCC 3 for dyngen. But then you have to deal with that crappy register-starved arch, I think, which is why I didn't do it before. Although I have to admit I _was_ tempted to ExcludeArch: i386 :) -- dwmw2 From pertusus at free.fr Wed Jan 31 08:47:05 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 31 Jan 2007 09:47:05 +0100 Subject: new features in package CVS In-Reply-To: <20070130230311.GA16319@nostromo.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> Message-ID: <20070131084705.GB2687@free.fr> On Tue, Jan 30, 2007 at 06:03:11PM -0500, Bill Nottingham wrote: > > Empty pkg.acl file: only the package owner [1] is allowed access. > - packages, by default, on import will have a empty pkg.acl added. > These can be removed by the owner if they truly wish. Why not have a default of open access? It would allow to follow the guidelines: http://fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages#afterinclude (As a side note, I don't see a reason to restrict acces to the cvs in general case: when roles are clearly defined people don't mess with others packages, even though they have access). -- Pat From pertusus at free.fr Wed Jan 31 09:02:24 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 31 Jan 2007 10:02:24 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <45C05769.8060702@hhs.nl> References: <200701292306.51269.ville.skytta@iki.fi> <20070129230106.GA24020@free.fr> <45C04A77.7050007@hhs.nl> <20070131083336.GA2687@free.fr> <45C05769.8060702@hhs.nl> Message-ID: <20070131090224.GC2687@free.fr> On Wed, Jan 31, 2007 at 09:46:33AM +0100, Hans de Goede wrote: > > Agreed, you should always ask upstream but in some cases, upstream is > either dead or simply refuses todo dynamic libs (plib for example). In case of libnet, upstream seems to be dead, but development resumed at alioth, however this doesn't seems to hae really kickoff. I think that it is very possible that the project really restarts somewhere, so I'll wait before doing a move. (I don't always do that, for the cernlib, I use the debian patches to build shared libraries). -- Pat From Christian.Iseli at licr.org Wed Jan 31 09:41:06 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 31 Jan 2007 10:41:06 +0100 Subject: new features in package CVS In-Reply-To: <20070131084705.GB2687@free.fr> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <20070131084705.GB2687@free.fr> Message-ID: <20070131104106.4bf25065@ludwig-alpha.unil.ch> On Wed, 31 Jan 2007 09:47:05 +0100, Patrice Dumas wrote: > Why not have a default of open access? It would allow to follow the > guidelines: > > http://fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages#afterinclude > > (As a side note, I don't see a reason to restrict acces to the cvs in general > case: when roles are clearly defined people don't mess with others > packages, even though they have access). +1 This whole thing feels a bit like "Ok, the rest of the RH people now flood in, but they won't trust the people already in cvsextras, so let's close everything down"... I semi understand that a few very specific packages are really sensitive stuff (kernel, gcc, basic system security stuff), but the rest is just ... well ... like what we already have in Extras. Somewhat unhappy, C From Christian.Iseli at licr.org Wed Jan 31 09:47:26 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 31 Jan 2007 10:47:26 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C015AA.6070008@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> Message-ID: <20070131104726.473e3963@ludwig-alpha.unil.ch> On Tue, 30 Jan 2007 23:06:02 -0500, Warren Togami wrote: > I'd like to go ahead with filing step #1 on Wednesday. > > Thoughts? Sure. We are short on time anyway, and I don't have a better schema to offer... C From mtasaka at ioa.s.u-tokyo.ac.jp Wed Jan 31 09:50:20 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 31 Jan 2007 18:50:20 +0900 Subject: new features in package CVS In-Reply-To: <20070131084705.GB2687@free.fr> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <20070131084705.GB2687@free.fr> Message-ID: <45C0665C.90804@ioa.s.u-tokyo.ac.jp> Patrice Dumas wrote: > Why not have a default of open access? It would allow to follow the > guidelines: > > http://fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages#afterinclude > > (As a side note, I don't see a reason to restrict acces to the cvs in general > case: when roles are clearly defined people don't mess with others > packages, even though they have access). +1 I think restricting CVS access makes people who want to contribute themselves to Fedora less cooperative. Mamoru Tasaka From a.badger at gmail.com Wed Jan 31 10:10:51 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 31 Jan 2007 02:10:51 -0800 Subject: new features in package CVS In-Reply-To: <15572.1170219164@sss.pgh.pa.us> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> Message-ID: <1170238251.18675.254.camel@localhost.localdomain> On Tue, 2007-01-30 at 23:52 -0500, Tom Lane wrote: > Jeff Garzik writes: > > On Tue, Jan 30, 2007 at 07:05:42PM -0500, Tom Lane wrote: > >> OK, but then the default for existing packages is to be wide open :-(. > > > That's the current default, from the beginning of time until today. > > Yeah, but that default has been for developers *within Red Hat* to have > open access to each other's packages. Perhaps I'm not understanding > something, but I thought that the brave new world was going to involve > anyone who'd signed up for a Fedora account to have commit access to our > CVS. No. Anyone who has a cvsextras account. The "anyone who's signed up" would be the cla_done group. And hopefully in the future, there will be a group even outside of that so community contributors who just want to watch what's going on inside of Fedora Packages/in Fedora Bug reports can sign up. In any case, the group that has cvs access is much more stringent than "signed up for a Fedora Account". It's also currently more stringent than "works for Red Hat". Not sure how that's going to play out in the next two or three weeks as we start in earnest to merge Core and Extras. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Wed Jan 31 10:26:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 31 Jan 2007 11:26:14 +0100 Subject: new features in package CVS In-Reply-To: <20070131104106.4bf25065@ludwig-alpha.unil.ch> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <20070131084705.GB2687@free.fr> <20070131104106.4bf25065@ludwig-alpha.unil.ch> Message-ID: <45C06EC6.5060708@leemhuis.info> On 31.01.2007 10:41, Christian Iseli wrote: > On Wed, 31 Jan 2007 09:47:05 +0100, Patrice Dumas wrote: >> Why not have a default of open access? It would allow to follow the >> guidelines: >> >> http://fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages#afterinclude >> >> (As a side note, I don't see a reason to restrict acces to the cvs in general >> case: when roles are clearly defined people don't mess with others >> packages, even though they have access). > +1 Yes and no IMHO. As I said somewhere else some weeks ago: I'd prefer some kind of wiki-like-style approach for my packages and the repo in general. But well, a real wiki scheme simply is not possible, as everyone could modify stuff in CVS, put a Trojan into some package, build it. Then it gets pushed and a lot of systems will get infected quickly :-/ > I semi understand that a few very specific packages are really > sensitive stuff (kernel, gcc, basic system security stuff), but the > rest is just ... well ... like what we already have in Extras. Just wondering: are those really that more "sensitive" then the rest? Yes, those are probably on most systems out there, so placing something bad in one of those (and getting it out to the users) might be more attractive than in other packages -- but we don't want bad stuff in lesser used packages, too. My 2 cent on the whole issue: - give everyone (and especially new contributors that just got sponsored) write access everywhere is to dangerous (remember: The "hit CTRL+C at the right moment and no commit mails will be send"-problem is afaik still unfixed!) - have restrictive ACLs that only allows owners to modify stuff is to restrictive and makes stuff to complicated Proposed middle ground (that was discussed here in the past days already): create a *big* group (Sponsors, FESCo Members, Packaging Committee members and some long term Red Hat employees and packages) and give them write access everywhere while new contributors get only write access where they need it. CU thl From Christian.Iseli at licr.org Wed Jan 31 10:49:44 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 31 Jan 2007 11:49:44 +0100 Subject: new features in package CVS In-Reply-To: <45C06EC6.5060708@leemhuis.info> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <20070131084705.GB2687@free.fr> <20070131104106.4bf25065@ludwig-alpha.unil.ch> <45C06EC6.5060708@leemhuis.info> Message-ID: <20070131114944.0ab3bb75@ludwig-alpha.unil.ch> On Wed, 31 Jan 2007 11:26:14 +0100, Thorsten Leemhuis wrote: > Proposed middle ground (that was discussed here in the past days > already): create a *big* group (Sponsors, FESCo Members, Packaging > Committee members and some long term Red Hat employees and packages) and > give them write access everywhere while new contributors get only write > access where they need it. That sounds sensible to me (guess I didn' follow the whole discussion closely enough). +1 C From opensource at till.name Wed Jan 31 11:00:57 2007 From: opensource at till.name (Till Maas) Date: Wed, 31 Jan 2007 12:00:57 +0100 Subject: Packages with optflags and/or debuginfo issues In-Reply-To: <1170213312.5838.291.camel@mccallum.corsepiu.local> References: <200701292306.51269.ville.skytta@iki.fi> <200701301958.23203.opensource@till.name> <1170213312.5838.291.camel@mccallum.corsepiu.local> Message-ID: <200701311201.05022.opensource@till.name> On Wednesday 31 January 2007 04:15, Ralf Corsepius wrote: > Yes. Probably 99.9% of all existing Makefiles automatically do so. Bad luck for me, 2 of my 5 packages have Makefiles that do not do so. > > Or how do I know whether or not to tweak LDFLAGS? > > By checking build logs. > > Normally you'll see build errors ("Missing symbols", "wrong > architecture" or similar if something doesn't work. So it is only needed when building breaks or may this also cause unexpected beheavior of the running application? I thought it may be needed to enable the security features. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Christian.Iseli at licr.org Wed Jan 31 12:53:38 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 31 Jan 2007 13:53:38 +0100 Subject: Fedora Release Engineering In-Reply-To: <200701301747.48619.jkeating@redhat.com> References: <200701301747.48619.jkeating@redhat.com> Message-ID: <20070131135338.150a61a5@ludwig-alpha.unil.ch> Hi Jesse, On Tue, 30 Jan 2007 17:47:45 -0500, Jesse Keating wrote: > Anyway, here is the "manifesto": > http://fedoraproject.org/wiki/JesseKeating/RelEng Read it and it looks good so far. I'll be happy to help where I can. Cheers, C From bpepple at fedoraproject.org Wed Jan 31 12:35:59 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 31 Jan 2007 07:35:59 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C015AA.6070008@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> Message-ID: <1170246959.1867.6.camel@Chuck> On Tue, 2007-01-30 at 23:06 -0500, Warren Togami wrote: > > Steps to make this happen: > 1) File the mass review bugs, auto-assigned to the package owners. > 2) FESCO should discuss and vote to ratify this process change. > 3) Documentation should be updated. > > I'd like to go ahead with filing step #1 on Wednesday. Seems fine to me. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Wed Jan 31 13:12:47 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 31 Jan 2007 08:12:47 -0500 Subject: new features in package CVS In-Reply-To: <15572.1170219164@sss.pgh.pa.us> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> Message-ID: <20070131131247.GA29172@devserv.devel.redhat.com> On Tue, Jan 30, 2007 at 11:52:44PM -0500, Tom Lane wrote: > I am prepared to trust other people within Red Hat, but not just any > J. Random Hacker. Seconded. I'm not sure I'm going to even consider running FC7 based on this policy. It's too risky for the kind of stuff I have to keep around. Alan From alan at redhat.com Wed Jan 31 13:15:41 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 31 Jan 2007 08:15:41 -0500 Subject: new features in package CVS In-Reply-To: <45C04967.8060608@hhs.nl> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> Message-ID: <20070131131541.GB29172@devserv.devel.redhat.com> On Wed, Jan 31, 2007 at 08:46:47AM +0100, Hans de Goede wrote: > touched in a harmfull way. Just because someone is a beginning packager > doesn't mean that he will start submitting random changes to other > peoples packages. Your risk model is wrong. One of your beginning programmers (probably a beginner but it could be any of us) gets trojanned. The attacker then inserts a worm into the autoconf scripts for that package which goes around committing itself to other packages while infecting anyone who builds the package and adding backdoors to their machines Within a couple of days you'll have chaos. If users can only touch packages they have access to then the ability for this kind of attack drops dramatically and its more likely to be picked up early. And people *WILL* try this sort of stuff because the prize (breaking into the Red Hat internal network) is so high Alan From opensource at till.name Wed Jan 31 13:45:09 2007 From: opensource at till.name (Till Maas) Date: Wed, 31 Jan 2007 14:45:09 +0100 Subject: new features in package CVS In-Reply-To: <20070130230311.GA16319@nostromo.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> Message-ID: <200701311445.23094.opensource@till.name> On Wednesday 31 January 2007 00:03, Bill Nottingham wrote: > 2) E-mail notification > > By defalt, e-mail notification will now be sent on all package > commits to the package owner, and any co-maintainers listed in > the pkg.acl files. The format will be exactly the same format > as is sent to the commits list. Will there also be e-mail notifications when any information in owners.list about one's package is changed, e.g. when changing to a new e-mail address (in which way a notification should go to the old address)? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed Jan 31 14:05:45 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 31 Jan 2007 15:05:45 +0100 Subject: Fedora Release Engineering In-Reply-To: <200701301747.48619.jkeating@redhat.com> References: <200701301747.48619.jkeating@redhat.com> Message-ID: <20070131140545.GL3266@neu.nirvana> On Tue, Jan 30, 2007 at 05:47:45PM -0500, Jesse Keating wrote: > As we gear up toward a merged world where the entire Fedora community gets to > play in the same sandbox, I wanted to create a document that outlines some of > what Release Engineering means to Fedora, as well as give folks an idea of > what it might mean to be a part of the team. I've created something of a > rough draft that I would like to fine tune over the next few months, and I'm > happy to talk to anybody about any particular part of it. I know that some > of you have expressed interest in helping me to accomplish some of these > tasks, as such I've signed up to do a FUDCon session on Friday regarding > Fedora release engineering. I hope to have somebody in the audience also be > on IRC to relay questions/answers much like during Fedora Board meetings and > such. > > Anyway, here is the "manifesto": > http://fedoraproject.org/wiki/JesseKeating/RelEng > > This obviously isn't going to be the final home, but it is just the working > home for it. Should the release process documentation also enclose policies and procedures for updates to the release? I think this (the post-release policies for updates) is one of the largest differences between core and extras and it would be nice to have some guidance. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Wed Jan 31 14:45:52 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 31 Jan 2007 09:45:52 -0500 Subject: new features in package CVS In-Reply-To: <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> Message-ID: <1170254752.2860.6.camel@localhost.localdomain> On Tue, 2007-01-30 at 15:48 -0800, Peter Gordon wrote: > Bill Nottingham wrote: > > To add an ACL to your package, add a 'pkg.acl' file to either > > the package toplevel, or to a particular branch, such as FC-6 > > or devel. ACLs are inherited; branches will inherit ACLs from > > the toplevel. > > > > Is this ACL for CVS access only, or also for build submissions? For build submissions, it would seem fairly easy to have the build system check the pkg.acl from it's pristine pkgcvs checkout and ensure that the job owner is listed in the pkg.acl file, and otherwise fail the job. That's not as ideal as a real accounts system, since the buildsys would have to do some work before it could check the ACL, but it ensures that a build not requested by one of the owners would not be allowed. Those in the job_admin group might still be allowed to build any package, like they can kill/requeue/finish any job already. Thoughts? Dan > > What about the current initialcclist column of owners.list? That's how I > comaintain a package (epiphany-extensions). > > Thanks. From opensource at till.name Wed Jan 31 14:54:54 2007 From: opensource at till.name (Till Maas) Date: Wed, 31 Jan 2007 15:54:54 +0100 Subject: new features in package CVS In-Reply-To: <1170254752.2860.6.camel@localhost.localdomain> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> <1170254752.2860.6.camel@localhost.localdomain> Message-ID: <200701311555.20434.opensource@till.name> On Wednesday 31 January 2007 15:45, Dan Williams wrote: > For build submissions, it would seem fairly easy to have the build > system check the pkg.acl from it's pristine pkgcvs checkout and ensure > that the job owner is listed in the pkg.acl file, and otherwise fail the > job. That's not as ideal as a real accounts system, since the buildsys Is this really needed? As far as I understand how the buildsystem works, it checks the cvs out with the requested tag. So it would always only build the stuff that someone who is authorized by cvs acls commited and tagged. Or am I wrong here? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Wed Jan 31 14:55:25 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 31 Jan 2007 09:55:25 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C015AA.6070008@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> Message-ID: <45C0ADDD.4060401@redhat.com> Another thought... 1) ASSIGNED is always to the package owner. or 2) ASSIGNED begins to nobody at fedoraproject.org. ASSIGNED to reviewer during the review, ASSIGNED to package owner after review. ASSIGNED is to whoever needs to be doing work in the next step of getting the package out. Perhaps #2 makes more sense, but is it too confusing? Either way, Flags track *who* did the review and *who* approved it, and flags are independently query-able. Warren Togami wtogami at redhat.com From ajackson at redhat.com Wed Jan 31 14:46:39 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 31 Jan 2007 09:46:39 -0500 Subject: new features in package CVS In-Reply-To: <1170254752.2860.6.camel@localhost.localdomain> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> <1170254752.2860.6.camel@localhost.localdomain> Message-ID: <1170254799.17252.68.camel@localhost.localdomain> On Wed, 2007-01-31 at 09:45 -0500, Dan Williams wrote: > On Tue, 2007-01-30 at 15:48 -0800, Peter Gordon wrote: > > Bill Nottingham wrote: > > > To add an ACL to your package, add a 'pkg.acl' file to either > > > the package toplevel, or to a particular branch, such as FC-6 > > > or devel. ACLs are inherited; branches will inherit ACLs from > > > the toplevel. > > > > > > > Is this ACL for CVS access only, or also for build submissions? > > For build submissions, it would seem fairly easy to have the build > system check the pkg.acl from it's pristine pkgcvs checkout and ensure > that the job owner is listed in the pkg.acl file, and otherwise fail the > job. That's not as ideal as a real accounts system, since the buildsys > would have to do some work before it could check the ACL, but it ensures > that a build not requested by one of the owners would not be allowed. > > Those in the job_admin group might still be allowed to build any > package, like they can kill/requeue/finish any job already. Thoughts? On the one hand I like the idea of anyone being able to handle trivial rebuilds. On the other this gives the opportunity for anyone in the BuildRequires path to potentially inject something malicious into your program, but they pretty much have that anyway. So I think overall it's better to leave the ACL as CVS only. - ajax From Christian.Iseli at licr.org Wed Jan 31 15:08:15 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 31 Jan 2007 16:08:15 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C0ADDD.4060401@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C0ADDD.4060401@redhat.com> Message-ID: <20070131160815.759b0a88@ludwig-alpha.unil.ch> On Wed, 31 Jan 2007 09:55:25 -0500, Warren Togami wrote: > 2) ASSIGNED begins to nobody at fedoraproject.org. ASSIGNED to reviewer > during the review, ASSIGNED to package owner after review. ASSIGNED is > to whoever needs to be doing work in the next step of getting the > package out. Makes some amount of sense, thinking about it... > Perhaps #2 makes more sense, but is it too confusing? Well, I got used to the current schema, so this new schema is confusing me a bit anyway... > Either way, Flags track *who* did the review and *who* approved it, and > flags are independently query-able. Yes. But they won't show who the package owner is AFAICT... So I think the owner should be the assignee at least when the package is approved. Dunno how we will know who the package owner is during review with option 2. I think you should name the owner in the initial comment in this case. Did you intend to still have all accepted packages block FE-ACCEPT ? C From dcbw at redhat.com Wed Jan 31 15:19:22 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 31 Jan 2007 10:19:22 -0500 Subject: new features in package CVS In-Reply-To: <200701311555.20434.opensource@till.name> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> <1170254752.2860.6.camel@localhost.localdomain> <200701311555.20434.opensource@till.name> Message-ID: <1170256762.2860.39.camel@localhost.localdomain> On Wed, 2007-01-31 at 15:54 +0100, Till Maas wrote: > On Wednesday 31 January 2007 15:45, Dan Williams wrote: > > > For build submissions, it would seem fairly easy to have the build > > system check the pkg.acl from it's pristine pkgcvs checkout and ensure > > that the job owner is listed in the pkg.acl file, and otherwise fail the > > job. That's not as ideal as a real accounts system, since the buildsys > > Is this really needed? As far as I understand how the buildsystem works, it > checks the cvs out with the requested tag. So it would always only build the > stuff that someone who is authorized by cvs acls commited and tagged. Or am I > wrong here? Right, but anyone can request a build from any tag at any time. So if you tag something, but don't build it, then figure out that a security issues requires a new version, somebody else could have built your other one in the mean time. The attack is a lot less serious than allowing anyone to build anything, of course (since only the package owner can tag) but it does leave a few "holes" like this lying around. Dan From jkeating at redhat.com Wed Jan 31 15:22:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 31 Jan 2007 10:22:41 -0500 Subject: Fedora Release Engineering In-Reply-To: <20070131140545.GL3266@neu.nirvana> References: <200701301747.48619.jkeating@redhat.com> <20070131140545.GL3266@neu.nirvana> Message-ID: <200701311022.41722.jkeating@redhat.com> On Wednesday 31 January 2007 09:05, Axel Thimm wrote: > Should the release process documentation also enclose policies and > procedures for updates to the release? I think this (the post-release > policies for updates) is one of the largest differences between core > and extras and it would be nice to have some guidance. Yes it should, I just haven't gotten to that yet, largely because the policy is very very loose in Core right now too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dominik at greysector.net Wed Jan 31 15:19:55 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 31 Jan 2007 16:19:55 +0100 Subject: new features in package CVS In-Reply-To: <20070130230311.GA16319@nostromo.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> Message-ID: <20070131151955.GA21304@ryvius.pekin.waw.pl> On Wednesday, 31 January 2007 at 00:03, Bill Nottingham wrote: [...] > As part of this change, there are two changes to how certain > processes will work: > > - owners.list and owners.epel.list are now locked down. To request > changes, please send mail to cvsadmin-members at fedoraproject.org. > (This may be replaced with the wiki or the ticketing system really > fast.) This is a turn for worse. It adds yet another thing to be done after importing a package. I'd agree to this only if the CVSSyncNeeded wiki page and the above are merged. I don't want to have to look in three places instead of two. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From opensource at till.name Wed Jan 31 15:23:17 2007 From: opensource at till.name (Till Maas) Date: Wed, 31 Jan 2007 16:23:17 +0100 Subject: new features in package CVS In-Reply-To: <1170256762.2860.39.camel@localhost.localdomain> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <200701311555.20434.opensource@till.name> <1170256762.2860.39.camel@localhost.localdomain> Message-ID: <200701311623.43664.opensource@till.name> On Wednesday 31 January 2007 16:19, Dan Williams wrote: > Right, but anyone can request a build from any tag at any time. So if > you tag something, but don't build it, then figure out that a security > issues requires a new version, somebody else could have built your other > one in the mean time. The attack is a lot less serious than allowing > anyone to build anything, of course (since only the package owner can > tag) but it does leave a few "holes" like this lying around. Is there any reason to tag something other than to build it? If there is not than maybe it would be better to reduce complexity and add the functionality of "make tag" to "make build". Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dominik at greysector.net Wed Jan 31 15:24:46 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 31 Jan 2007 16:24:46 +0100 Subject: new features in package CVS In-Reply-To: <200701311623.43664.opensource@till.name> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <200701311555.20434.opensource@till.name> <1170256762.2860.39.camel@localhost.localdomain> <200701311623.43664.opensource@till.name> Message-ID: <20070131152446.GC21304@ryvius.pekin.waw.pl> On Wednesday, 31 January 2007 at 16:23, Till Maas wrote: > On Wednesday 31 January 2007 16:19, Dan Williams wrote: > > > Right, but anyone can request a build from any tag at any time. So if > > you tag something, but don't build it, then figure out that a security > > issues requires a new version, somebody else could have built your other > > one in the mean time. The attack is a lot less serious than allowing > > anyone to build anything, of course (since only the package owner can > > tag) but it does leave a few "holes" like this lying around. > > Is there any reason to tag something other than to build it? If there is not > than maybe it would be better to reduce complexity and add the functionality > of "make tag" to "make build". Seconded. I always do "make tag build" anyway. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From katzj at redhat.com Wed Jan 31 15:48:33 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 31 Jan 2007 10:48:33 -0500 Subject: rawhide unfrozen In-Reply-To: <200701302216.59497.jkeating@redhat.com> References: <200701302216.59497.jkeating@redhat.com> Message-ID: <1170258513.2880.11.camel@aglarond.local> On Tue, 2007-01-30 at 22:16 -0500, Jesse Keating wrote: > This evening I "unfroze" rawhide. This is because the F7 Test1 bits are > finally on their way to the mirrors. Tonight's rawhide spin will pick up all > the new packages that have been built over the past week~ during the freeze. > This will make rawhide newer than test 1, for those of you thinking about > doing an upgrade. And, as a reminder, remember that the freeze for test2 is scheduled[1] for February 20. This is also the date for both the feature freeze and the string freeze for the release. After this date 1) New features shouldn't be added for packages that are planned for the major F7 spins 2) Strings shouldn't change in packages where the translations are done by the Fedora community (this is packages with their upstream source currently on rhlinux.redhat.com) So get your UI and feature changes in soon! Jeremy [1] http://fedoraproject.org/wiki/Releases/7/Schedule From rc040203 at freenet.de Wed Jan 31 15:53:18 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 31 Jan 2007 16:53:18 +0100 Subject: new features in package CVS In-Reply-To: <20070131131541.GB29172@devserv.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> Message-ID: <1170258799.5838.449.camel@mccallum.corsepiu.local> On Wed, 2007-01-31 at 08:15 -0500, Alan Cox wrote: > On Wed, Jan 31, 2007 at 08:46:47AM +0100, Hans de Goede wrote: > > touched in a harmfull way. Just because someone is a beginning packager > > doesn't mean that he will start submitting random changes to other > > peoples packages. > > Your risk model is wrong. One of your beginning programmers (probably a beginner > but it could be any of us) gets trojanned. The attacker then inserts a worm > into the autoconf scripts for that package which goes around committing itself > to other packages while infecting anyone who builds the package and adding > backdoors to their machines > > Within a couple of days you'll have chaos. > > If users can only touch packages they have access to then the ability for this > kind of attack drops dramatically and its more likely to be picked up early. I don't see this. We all signed the CLI, we all log in through ssl, the VCS will log all changes, so everybody committing something already should be traceable. Whether somebody deliberately/non-deliberately places a trojan into a package not owned by him or owned by somebody else, or imports an infected tarball, doesn't make much of a difference. > And people *WILL* try this sort of stuff because the prize (breaking into the > Red Hat internal network) is so high The only thing that really changes with a merged Core/Extras is the impact infecting a central package, which nowadays is in Core would have, would likely be larger. E.g. a thief having stolen a Fedora maintainers's notebook or somebody having intruded into a system with his "secret ssl keys, passwd, etc." will find 2000-3000 packages more, he can place his malware on, than he could do until now. But .. isn't the likelihood of somebody intruding a Fedora mirror and placing malicious packages there, much larger? Ralf From chris.stone at gmail.com Wed Jan 31 15:55:51 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 31 Jan 2007 07:55:51 -0800 Subject: new features in package CVS In-Reply-To: <20070131131541.GB29172@devserv.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> Message-ID: On 1/31/07, Alan Cox wrote: > On Wed, Jan 31, 2007 at 08:46:47AM +0100, Hans de Goede wrote: > > touched in a harmfull way. Just because someone is a beginning packager > > doesn't mean that he will start submitting random changes to other > > peoples packages. > > Your risk model is wrong. One of your beginning programmers (probably a beginner > but it could be any of us) gets trojanned. The attacker then inserts a worm > into the autoconf scripts for that package which goes around committing itself > to other packages while infecting anyone who builds the package and adding > backdoors to their machines > > Within a couple of days you'll have chaos. > > If users can only touch packages they have access to then the ability for this > kind of attack drops dramatically and its more likely to be picked up early. > > > And people *WILL* try this sort of stuff because the prize (breaking into the > Red Hat internal network) is so high Riiiiiiiiiiiiiiiight. And people at redhat are completely immune to such attacks while the extra packagers are so nieve that it is very likely to happen once we open up the core cvs. I'm sorry, but this part of the discussion just seems completely laughable to me. From alan at redhat.com Wed Jan 31 16:01:47 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 31 Jan 2007 11:01:47 -0500 Subject: new features in package CVS In-Reply-To: <1170258799.5838.449.camel@mccallum.corsepiu.local> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> <1170258799.5838.449.camel@mccallum.corsepiu.local> Message-ID: <20070131160147.GA7189@devserv.devel.redhat.com> On Wed, Jan 31, 2007 at 04:53:18PM +0100, Ralf Corsepius wrote: > I don't see this. We all signed the CLI, we all log in through ssl, the > VCS will log all changes, so everybody committing something already > should be traceable. Which is frequently too late. It is for the same reason you have file permissions. I trust the users of my external box absolutely, but they all have their own file permissions - because people make mistakes, because that way trojans can be isolated and attacks limited > Whether somebody deliberately/non-deliberately places a trojan into a > package not owned by him or owned by somebody else, or imports an > infected tarball, doesn't make much of a difference. The import tar ball is watched by a lot more people in a lot more places. > But .. isn't the likelihood of somebody intruding a Fedora mirror and > placing malicious packages there, much larger? Guess why rpm packages are digitally signed. From alan at redhat.com Wed Jan 31 16:03:42 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 31 Jan 2007 11:03:42 -0500 Subject: new features in package CVS In-Reply-To: References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> Message-ID: <20070131160342.GB7189@devserv.devel.redhat.com> On Wed, Jan 31, 2007 at 07:55:51AM -0800, Christopher Stone wrote: > And people at redhat are completely immune to such attacks while the > extra packagers are so nieve that it is very likely to happen once we naiive ?? > open up the core cvs. No Red Hat people can make mistakes too, there is better internal security that a random end user's box but it doesn't stop it. The same ACLS should be used internally to stop mistakes as well as externally. Very few people need blanket access (folks like notting) Alan From skvidal at linux.duke.edu Wed Jan 31 16:07:01 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 31 Jan 2007 11:07:01 -0500 Subject: new features in package CVS In-Reply-To: <20070131160342.GB7189@devserv.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> <20070131160342.GB7189@devserv.devel.redhat.com> Message-ID: <1170259621.24910.45.camel@cutter> On Wed, 2007-01-31 at 11:03 -0500, Alan Cox wrote: > On Wed, Jan 31, 2007 at 07:55:51AM -0800, Christopher Stone wrote: > > And people at redhat are completely immune to such attacks while the > > extra packagers are so nieve that it is very likely to happen once we > > naiive ?? > > > open up the core cvs. > > No Red Hat people can make mistakes too, there is better internal security > that a random end user's box but it doesn't stop it. The same ACLS should > be used internally to stop mistakes as well as externally. Very few people > need blanket access (folks like notting) > Not a random end user. A random end contributor. You're confusing people-outside-of-rh as only users. They're developers and contributors, too. Also how is the new state of things worse than before wrt rh's network compromises? If you ever used an extra package on your machine and you had access to the rh vpn then you were in the same boat. How does it magically change b/c we're adding core? -sv From chris.stone at gmail.com Wed Jan 31 16:08:38 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 31 Jan 2007 08:08:38 -0800 Subject: new features in package CVS In-Reply-To: <20070131160342.GB7189@devserv.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> <20070131160342.GB7189@devserv.devel.redhat.com> Message-ID: On 1/31/07, Alan Cox wrote: > On Wed, Jan 31, 2007 at 07:55:51AM -0800, Christopher Stone wrote: > > And people at redhat are completely immune to such attacks while the > > extra packagers are so nieve that it is very likely to happen once we > > naiive ?? Actually I mean naive. Proof that programmers cannot spell. Nor can they do simple math without a calculator, but that is for another discussion... > > > open up the core cvs. > > No Red Hat people can make mistakes too, there is better internal security > that a random end user's box but it doesn't stop it. The same ACLS should > be used internally to stop mistakes as well as externally. Very few people > need blanket access (folks like notting) Yea I agree ACLs are a good thing and very few people need blanket access. But if this type of attack were likely, then extras is probably already infected. From tibbs at math.uh.edu Wed Jan 31 16:08:37 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 31 Jan 2007 10:08:37 -0600 Subject: qemu optflags In-Reply-To: <1170233104.29759.233.camel@pmac.infradead.org> References: <200701292306.51269.ville.skytta@iki.fi> <200701302004.01797.opensource@till.name> <200701302018.01307.opensource@till.name> <20070130202113.GA2685@free.fr> <45C04C38.1070704@hhs.nl> <1170233104.29759.233.camel@pmac.infradead.org> Message-ID: >>>>> "DW" == David Woodhouse writes: DW> Qemu is, as stated, a pain in the arse. It's _very_ dependent on DW> compiler output, because of the way it takes 'snippets' of code DW> from tiny functions and uses those as the building blocks for its DW> translation. I think the qemu spec is very clean; the only thing it's really lacking is a bit of comment explaining why it has to use the -compat compiler. How about something like this? # At this time, GCC4 is simply not compatible with the way qemu works, # so the compat-gcc-XX compiler must be used. This also requires that # $RPM_OPT_FLAGS not be used, because some of those flags are not # compatible with the version of the compiler that compat-gcc-XX # provides. And as for the meta-discussion here, I think it's important to realize that there's always going to be some package that's a legitimate exception to just about any guideline. As long as this stuff is accepted by review (or by committee where necessary) and properly documented in the specfile then everything should be fine. - J< From fedora at camperquake.de Wed Jan 31 16:08:57 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 31 Jan 2007 17:08:57 +0100 Subject: new features in package CVS In-Reply-To: <20070131160147.GA7189@devserv.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> <1170258799.5838.449.camel@mccallum.corsepiu.local> <20070131160147.GA7189@devserv.devel.redhat.com> Message-ID: <20070131170857.5add123a@banea.int.addix.net> Hi. On Wed, 31 Jan 2007 11:01:47 -0500, Alan Cox wrote: > > But .. isn't the likelihood of somebody intruding a Fedora mirror > > and placing malicious packages there, much larger? > > Guess why rpm packages are digitally signed. Guess whether rawhide packages are signed. From wtogami at redhat.com Wed Jan 31 16:18:41 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 31 Jan 2007 11:18:41 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070131160815.759b0a88@ludwig-alpha.unil.ch> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C0ADDD.4060401@redhat.com> <20070131160815.759b0a88@ludwig-alpha.unil.ch> Message-ID: <45C0C161.3000309@redhat.com> Christian Iseli wrote: > On Wed, 31 Jan 2007 09:55:25 -0500, Warren Togami wrote: >> 2) ASSIGNED begins to nobody at fedoraproject.org. ASSIGNED to reviewer >> during the review, ASSIGNED to package owner after review. ASSIGNED is >> to whoever needs to be doing work in the next step of getting the >> package out. > > Makes some amount of sense, thinking about it... > >> Perhaps #2 makes more sense, but is it too confusing? > > Well, I got used to the current schema, so this new schema is confusing > me a bit anyway... > >> Either way, Flags track *who* did the review and *who* approved it, and >> flags are independently query-able. > > Yes. But they won't show who the package owner is AFAICT... So I > think the owner should be the assignee at least when the package is > approved. Dunno how we will know who the package owner is during > review with option 2. I think you should name the owner in the > initial comment in this case. Good idea, I can include "Initial Owner: foouser" in the auto-filings. > > Did you intend to still have all accepted packages block > FE-ACCEPT ? No, the purpose of the flags is to improve the performance of this process by getting rid of tracker bugs. Warren Togami wtogami at redhat.com From rc040203 at freenet.de Wed Jan 31 16:21:30 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 31 Jan 2007 17:21:30 +0100 Subject: new features in package CVS In-Reply-To: <20070131160147.GA7189@devserv.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> <1170258799.5838.449.camel@mccallum.corsepiu.local> <20070131160147.GA7189@devserv.devel.redhat.com> Message-ID: <1170260490.5838.474.camel@mccallum.corsepiu.local> On Wed, 2007-01-31 at 11:01 -0500, Alan Cox wrote: > On Wed, Jan 31, 2007 at 04:53:18PM +0100, Ralf Corsepius wrote: > > I don't see this. We all signed the CLI, we all log in through ssl, the > > VCS will log all changes, so everybody committing something already > > should be traceable. > > Which is frequently too late. Yes, but do acls change something anything about this? Except that a maintainer won't be able to place a trojan into your packages, he still could place them into his. The end result would be the same: He would have infected Fedora and he would be traced down the same way. > > Whether somebody deliberately/non-deliberately places a trojan into a > > package not owned by him or owned by somebody else, or imports an > > infected tarball, doesn't make much of a difference. > > The import tar ball is watched by a lot more people in a lot more places. Really? Does anybody verify the tarballs a maintainer submitted against those on an external site - post-review? Many packages even don't have an upstream, or their upstream is hidden in a VCS and therefore are not really monitored. Does anybody check the patches inside of the look-a-side cache (They are invisible on fedora-commits, the list that nobody reads ;) )? Ralf From pertusus at free.fr Wed Jan 31 16:19:48 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 31 Jan 2007 17:19:48 +0100 Subject: new features in package CVS In-Reply-To: <20070131131541.GB29172@devserv.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> Message-ID: <20070131161947.GB2884@free.fr> On Wed, Jan 31, 2007 at 08:15:41AM -0500, Alan Cox wrote: > On Wed, Jan 31, 2007 at 08:46:47AM +0100, Hans de Goede wrote: > > touched in a harmfull way. Just because someone is a beginning packager > > doesn't mean that he will start submitting random changes to other > > peoples packages. > > Your risk model is wrong. One of your beginning programmers (probably a beginner > but it could be any of us) gets trojanned. The attacker then inserts a worm > into the autoconf scripts for that package which goes around committing itself > to other packages while infecting anyone who builds the package and adding > backdoors to their machines That could happen to anybody, and I don't think that it is a practical attack. In mock, packages are built in a chroot and not by root. We look (or should look) at the commit list for packages we are interested in. Trojaned packages would only hurt those who rebuild packages without looking at the import. In my opinion, and I still may be wrong, most of the fedora contributors are experienced and less prone to be hurt by trojans than other people. And lastly I believe is that upstream sources at least as prone as this kind of attack than a fedora without ACLs on CVS. Of course there is still more risks without ACLs on cvs, but I think that in the balance of risk versus practicability, having something open is better. For gcc, kernel, libc, maybe perl and python, sure there could be ACLs, for more collaborative stuff, especially what comes from fedora extras, I think it is better to keep things open. -- Pat From fedora at leemhuis.info Wed Jan 31 16:36:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 31 Jan 2007 17:36:29 +0100 Subject: new features in package CVS In-Reply-To: <1170254752.2860.6.camel@localhost.localdomain> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <12419.65.223.36.19.1170200880.squirrel@thecodergeek.com> <1170254752.2860.6.camel@localhost.localdomain> Message-ID: <45C0C58D.6030109@leemhuis.info> Dan Williams schrieb: > On Tue, 2007-01-30 at 15:48 -0800, Peter Gordon wrote: >> Bill Nottingham wrote: >>> To add an ACL to your package, add a 'pkg.acl' file to either >>> the package toplevel, or to a particular branch, such as FC-6 >>> or devel. ACLs are inherited; branches will inherit ACLs from >>> the toplevel. >> Is this ACL for CVS access only, or also for build submissions? > For build submissions, it would seem fairly easy to have the build > system check the pkg.acl from it's pristine pkgcvs checkout and ensure > that the job owner is listed in the pkg.acl file, and otherwise fail the > job. That's not as ideal as a real accounts system, since the buildsys > would have to do some work before it could check the ACL, but it ensures > that a build not requested by one of the owners would not be allowed. > > Those in the job_admin group might still be allowed to build any > package, like they can kill/requeue/finish any job already. Thoughts? I'd prefer if we could have different ACL lists for committing to packages and building *in the longer term* (e.g. probably get that info from the package database). That way we can give a new contributors access to a package in cvs, but no access to build the stuff (that could do his sponsor or a primary maintainer). CU thl From Christian.Iseli at licr.org Wed Jan 31 16:38:42 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 31 Jan 2007 17:38:42 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C0C161.3000309@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C0ADDD.4060401@redhat.com> <20070131160815.759b0a88@ludwig-alpha.unil.ch> <45C0C161.3000309@redhat.com> Message-ID: <20070131173842.2443d068@ludwig-alpha.unil.ch> On Wed, 31 Jan 2007 11:18:41 -0500, Warren Togami wrote: > No, the purpose of the flags is to improve the performance of this > process by getting rid of tracker bugs. Ok. Fine with me. C From tibbs at math.uh.edu Wed Jan 31 16:41:56 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 31 Jan 2007 10:41:56 -0600 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C015AA.6070008@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> Message-ID: >>>>> "WT" == Warren Togami writes: WT> OK, it seems the only real drawback to "ASSIGNED to owner instead WT> of reviewer" is Tibbs' good point about being able to see it on WT> frontpage.cgi. I'm happy as long as I can get to the list of packages I'm reviewing it via some query, although I do admit that the frontpage view is quite convenient. WT> https://bugzilla.redhat.com/bugzilla/request.cgi dkl mentioned WT> this interface that provides a way to query for flags. That page seems to take ages upon ages to load; does it include some sort of default query? Just a query for the extras-review flag takes well over half a minute, butt does show one ticket (which must have been some sort of experiment from many months ago). So, can someone who knows the details fill me in on the proper way for doing the following tasks? There don't seem to be any fedora-review flags set in the database so at the moment it's tough to experiment. Get a list of all tickets up for review which do not currently have reviewers. Sign myself up to review one of those packages. Get a list of all the packages I'm currently reviewing. Get a list of all tickets up for review which have reviewers. (Sometimes I like to browse them and help if I can.) Currently it doesn't look like you only query on the presence of a flag and not its status, which could be problematic. I'm sure I'm missing something. Also, the request.cgi interface seems to have no way to query only open bugs. If there really is no way to do this then we'll have to come up with something, because things are going to break down badly with 1000 packages up for review. - J< From wtogami at redhat.com Wed Jan 31 16:48:36 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 31 Jan 2007 11:48:36 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> Message-ID: <45C0C864.2050303@redhat.com> Jason L Tibbitts III wrote: >>>>>> "WT" == Warren Togami writes: > > WT> OK, it seems the only real drawback to "ASSIGNED to owner instead > WT> of reviewer" is Tibbs' good point about being able to see it on > WT> frontpage.cgi. > > I'm happy as long as I can get to the list of packages I'm reviewing > it via some query, although I do admit that the frontpage view is > quite convenient. > Although given the updated process, ASSIGNED goes to the reviewer during the review, so I believe this satisfies your desired work-flow immediately? Warren From notting at redhat.com Wed Jan 31 16:48:26 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 31 Jan 2007 11:48:26 -0500 Subject: new features in package CVS In-Reply-To: <20070131084705.GB2687@free.fr> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <20070131084705.GB2687@free.fr> Message-ID: <20070131164826.GC26542@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > On Tue, Jan 30, 2007 at 06:03:11PM -0500, Bill Nottingham wrote: > > > > Empty pkg.acl file: only the package owner [1] is allowed access. > > > - packages, by default, on import will have a empty pkg.acl added. > > These can be removed by the owner if they truly wish. > > Why not have a default of open access? It would allow to follow the > guidelines: > > http://fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages#afterinclude Bring it up to FESCo; the import default could change. Bill From tibbs at math.uh.edu Wed Jan 31 17:00:27 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 31 Jan 2007 11:00:27 -0600 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C0C864.2050303@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C0C864.2050303@redhat.com> Message-ID: >>>>> "WT" == Warren Togami writes: WT> Although given the updated process, ASSIGNED goes to the reviewer WT> during the review, so I believe this satisfies your desired WT> work-flow immediately? Yes, if we're now assigning things to the reviewer then that portion doesn't change. I'd still like to see how to do the usual set of queries under the new system. - J< From dlutter at redhat.com Wed Jan 31 17:45:11 2007 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 31 Jan 2007 09:45:11 -0800 Subject: new features in package CVS In-Reply-To: References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> Message-ID: <1170265511.24867.7.camel@localhost.localdomain> On Wed, 2007-01-31 at 07:55 -0800, Christopher Stone wrote: > And people at redhat are completely immune to such attacks while the > extra packagers are so nieve that it is very likely to happen once we > open up the core cvs. Don't look at this as a Red Hat vs. the rest of the world thing: even though I have a redhat.com mailing address, I don't expect to get commit access to the kernel, or glibc or 99% of the rest of the Fedora packages. And I don't want it: not having that access limits the things I need to worry about if my account gets compromised. My packages could still have been messed with, but at least it won't ripple into _all_ of Fedora needing an audit to make sure that a break into my account didn't compromise the distro. David From alan at redhat.com Wed Jan 31 17:50:02 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 31 Jan 2007 12:50:02 -0500 Subject: new features in package CVS In-Reply-To: <1170259621.24910.45.camel@cutter> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> <20070131160342.GB7189@devserv.devel.redhat.com> <1170259621.24910.45.camel@cutter> Message-ID: <20070131175002.GA16252@devserv.devel.redhat.com> On Wed, Jan 31, 2007 at 11:07:01AM -0500, seth vidal wrote: > Also how is the new state of things worse than before wrt rh's network > compromises? If you ever used an extra package on your machine and you > had access to the rh vpn then you were in the same boat. Some of us don't do that, unless we've verified the code carefully From dkl at redhat.com Wed Jan 31 18:44:37 2007 From: dkl at redhat.com (Dave Lawrence) Date: Wed, 31 Jan 2007 13:44:37 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C0C864.2050303@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C0C864.2050303@redhat.com> Message-ID: <45C0E395.9060706@redhat.com> Flag information is now available from the frontpage view as well. Dave Warren Togami wrote: > Jason L Tibbitts III wrote: >>>>>>> "WT" == Warren Togami writes: >> >> WT> OK, it seems the only real drawback to "ASSIGNED to owner instead >> WT> of reviewer" is Tibbs' good point about being able to see it on >> WT> frontpage.cgi. >> >> I'm happy as long as I can get to the list of packages I'm reviewing >> it via some query, although I do admit that the frontpage view is >> quite convenient. >> > > Although given the updated process, ASSIGNED goes to the reviewer > during the review, so I believe this satisfies your desired work-flow > immediately? > > Warren > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers -- David Lawrence, RHCE dkl at redhat.com ------------------------------------ Red Hat, Inc. Web: www.redhat.com 1801 Varsity Drive Raleigh, NC 27606 Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 From skvidal at linux.duke.edu Wed Jan 31 18:50:26 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 31 Jan 2007 13:50:26 -0500 Subject: new features in package CVS In-Reply-To: <20070131175002.GA16252@devserv.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> <20070131160342.GB7189@devserv.devel.redhat.com> <1170259621.24910.45.camel@cutter> <20070131175002.GA16252@devserv.devel.redhat.com> Message-ID: <1170269426.29190.3.camel@cutter> On Wed, 2007-01-31 at 12:50 -0500, Alan Cox wrote: > On Wed, Jan 31, 2007 at 11:07:01AM -0500, seth vidal wrote: > > Also how is the new state of things worse than before wrt rh's network > > compromises? If you ever used an extra package on your machine and you > > had access to the rh vpn then you were in the same boat. > > Some of us don't do that, unless we've verified the code carefully > That's special and all, but even at your company I'm certain you're in the minority. -sv From jwboyer at jdub.homelinux.org Wed Jan 31 18:51:40 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 31 Jan 2007 12:51:40 -0600 Subject: new features in package CVS In-Reply-To: <1170265511.24867.7.camel@localhost.localdomain> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> <1170265511.24867.7.camel@localhost.localdomain> Message-ID: <1170269500.5533.63.camel@zod.rchland.ibm.com> On Wed, 2007-01-31 at 09:45 -0800, David Lutterkort wrote: > On Wed, 2007-01-31 at 07:55 -0800, Christopher Stone wrote: > > And people at redhat are completely immune to such attacks while the > > extra packagers are so nieve that it is very likely to happen once we > > open up the core cvs. > > Don't look at this as a Red Hat vs. the rest of the world thing: even > though I have a redhat.com mailing address, I don't expect to get commit > access to the kernel, or glibc or 99% of the rest of the Fedora > packages. > > And I don't want it: not having that access limits the things I need to > worry about if my account gets compromised. My packages could still have > been messed with, but at least it won't ripple into _all_ of Fedora > needing an audit to make sure that a break into my account didn't > compromise the distro. This is, perhaps, the sanest explanation of why the ACLs aren't entirely a bad thing. Thanks, josh From skvidal at linux.duke.edu Wed Jan 31 18:55:32 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 31 Jan 2007 13:55:32 -0500 Subject: new features in package CVS In-Reply-To: <1170269500.5533.63.camel@zod.rchland.ibm.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> <1170265511.24867.7.camel@localhost.localdomain> <1170269500.5533.63.camel@zod.rchland.ibm.com> Message-ID: <1170269732.29190.6.camel@cutter> On Wed, 2007-01-31 at 12:51 -0600, Josh Boyer wrote: > On Wed, 2007-01-31 at 09:45 -0800, David Lutterkort wrote: > > On Wed, 2007-01-31 at 07:55 -0800, Christopher Stone wrote: > > > And people at redhat are completely immune to such attacks while the > > > extra packagers are so nieve that it is very likely to happen once we > > > open up the core cvs. > > > > Don't look at this as a Red Hat vs. the rest of the world thing: even > > though I have a redhat.com mailing address, I don't expect to get commit > > access to the kernel, or glibc or 99% of the rest of the Fedora > > packages. > > > > And I don't want it: not having that access limits the things I need to > > worry about if my account gets compromised. My packages could still have > > been messed with, but at least it won't ripple into _all_ of Fedora > > needing an audit to make sure that a break into my account didn't > > compromise the distro. > > This is, perhaps, the sanest explanation of why the ACLs aren't entirely > a bad thing. > I don't think anyone is arguing that they are entirely a bad thing. In fact I'm completely cool w/them. I just don't like the attitude coming from some of the posters to this thread that the unwashed masses outside of red hat will have their accounts cracked and that will allow the crackers to compromise red hat's internal network. Maybe then the crackers will have control of the weather manipulation machine. -sv From a.badger at gmail.com Wed Jan 31 18:56:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 31 Jan 2007 10:56:34 -0800 Subject: new features in package CVS In-Reply-To: <20070131164826.GC26542@nostromo.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <20070131084705.GB2687@free.fr> <20070131164826.GC26542@nostromo.devel.redhat.com> Message-ID: <1170269794.18675.343.camel@localhost.localdomain> On Wed, 2007-01-31 at 11:48 -0500, Bill Nottingham wrote: > Patrice Dumas (pertusus at free.fr) said: > > On Tue, Jan 30, 2007 at 06:03:11PM -0500, Bill Nottingham wrote: > > > > > > Empty pkg.acl file: only the package owner [1] is allowed access. > > > > > - packages, by default, on import will have a empty pkg.acl added. > > > These can be removed by the owner if they truly wish. > > > > Why not have a default of open access? It would allow to follow the > > guidelines: > > > > http://fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages#afterinclude > > Bring it up to FESCo; the import default could change. FYI: The FESCo meeting this week will be occurring at FudCon (as many FESCo members will be traveling there on Thursday). If you want to bring this up, send a message to bpepple with what you propose. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From blizzard at redhat.com Wed Jan 31 20:14:28 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 31 Jan 2007 15:14:28 -0500 Subject: Fedora Release Engineering In-Reply-To: <200701301747.48619.jkeating@redhat.com> References: <200701301747.48619.jkeating@redhat.com> Message-ID: <45C0F8A4.6080602@redhat.com> Hmm, another thought. Might be good to include "if you want to help us out, here are the contact points and the kinds of things that we need help with"? Not sure if that's part of the process, exactly, but there's certainly room for people to help with testing and making sure a release works? --Chris From jkeating at redhat.com Wed Jan 31 20:22:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 31 Jan 2007 15:22:41 -0500 Subject: Fedora Release Engineering In-Reply-To: <45C0F8A4.6080602@redhat.com> References: <200701301747.48619.jkeating@redhat.com> <45C0F8A4.6080602@redhat.com> Message-ID: <200701311522.41958.jkeating@redhat.com> On Wednesday 31 January 2007 15:14, Christopher Blizzard wrote: > Hmm, another thought. ?Might be good to include "if you want to help us > out, here are the contact points and the kinds of things that we need > help with"? Sure, I imagine there will eventually be a Wiki section on Releng, as a SIG, complete with task lists and all that. > Not sure if that's part of the process, exactly, but > there's certainly room for people to help with testing and making sure a > release works? Well, testing and such goes to QA, releng is more about making the bits show up for QA to beat on, but often times in Fedora space I play both roles, while QA plays them too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jan 31 20:57:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 31 Jan 2007 15:57:20 -0500 Subject: Drop pump. Message-ID: <200701311557.20809.jkeating@redhat.com> Our pump guys claim nothing at all is using it and we'd like to remove it from the collection. This is just a heads up, it is being dropped. If anybody wants it, they're welcome to it (you'll need to become the upstream for it as well). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From overholt at redhat.com Wed Jan 31 20:48:18 2007 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 31 Jan 2007 15:48:18 -0500 Subject: Dropping eclipse-bugzilla Message-ID: <20070131204817.GG23642@redhat.com> Hi, I'd like to drop eclipse-bugzilla from Fedora. It's no longer maintained and the Java 1.5 stuff we're getting will allow us to build and ship Mylar which has better BZ integration. Anyone have any problems with this? How should we go about this? It's currently in Core but I don't want it merged into the BNF. Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jan 31 21:07:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 31 Jan 2007 16:07:03 -0500 Subject: Dropping eclipse-bugzilla In-Reply-To: <20070131204817.GG23642@redhat.com> References: <20070131204817.GG23642@redhat.com> Message-ID: <200701311607.03897.jkeating@redhat.com> On Wednesday 31 January 2007 15:48, Andrew Overholt wrote: > How should we go about this? ?It's currently in Core but I don't want it > merged into the BNF. I'll block it from Core now. If anybody wants it, they can revive it after the merger. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Wed Jan 31 21:28:22 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 31 Jan 2007 16:28:22 -0500 Subject: Querying for fedora-review BLANK In-Reply-To: <45C0E395.9060706@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C0C864.2050303@redhat.com> <45C0E395.9060706@redhat.com> Message-ID: <45C109F6.1070500@redhat.com> Hey Dave, Bugzilla errors out when I try to query for fedora-review flag BLANK. Yesterday you suggested querying for a NOT of (fedora-review? AND fedora-review- AND fedora-review+). Any suggestion? Warren Togami wtogami at redhat.com Software error: DBD::Pg::st execute failed: ERROR: table name "flags_0" specified more than once [for Statement "SELECT bugs.bug_id, bugs.bug_severity, bugs.priority, bugs.bug_status, bugs.resolution, bugs.alias, bugs.bug_severity, bugs.priority, bugs.rep_platform, map_assigned_to.login_name, bugs.bug_status, bugs.resolution, bugs.short_desc FROM bugs LEFT JOIN bug_group_map ON bug_group_map.bug_id = bugs.bug_id LEFT JOIN cc ON cc.bug_id = bugs.bug_id AND cc.who = 40567 LEFT JOIN flags AS flags_0 ON bugs.bug_id = flags_0.bug_id AND flags_0.is_active = 1 LEFT JOIN flagtypes AS flagtypes_0 ON flags_0.type_id = flagtypes_0.id LEFT JOIN flags AS flags_0 ON bugs.bug_id = flags_0.bug_id AND flags_0.is_active = 1 LEFT JOIN flagtypes AS flagtypes_0 ON flags_0.type_id = flagtypes_0.id LEFT JOIN flags AS flags_0 ON bugs.bug_id = flags_0.bug_id AND flags_0.is_active = 1 LEFT JOIN flagtypes AS flagtypes_0 ON flags_0.type_id = flagtypes_0.id , profiles AS map_assigned_to WHERE bugs.assigned_to = map_assigned_to.userid AND ((bugs.product_id IN (59)) AND (bugs.component_id IN (18187,18186,16465)) AND (bugs.bug_status IN ('NEW','ASSIGNED','REOPENED'))) AND NOT(((flagtypes_0.name || flags_0.status) = 'fedora-review?') AND ((flagtypes_0.name || flags_0.status) = 'fedora-review-') AND ((flagtypes_0.name || flags_0.status) = 'fedora-review+')) AND ((bug_group_map.group_id IS NULL) OR bug_group_map.group_id IN (81,134,106,149,75,68,138,148,140,12,144,79,67,76,41,127,58,122,35,133,7,62,93,126,17,11,50,72,146,71,84,39,10,33,107,22,4,78,123,145,108,139,44,124,150,121,119,85,92,91,15,25,80,21,142,61,155,83,74,5,38,94,147) OR (bugs.reporter_accessible = 1 AND bugs.reporter = 40567) OR (bugs.cclist_accessible = 1 AND cc.who IS NOT NULL) OR (bugs.assigned_to = 40567) OR (bugs.qa_contact = 40567) ) GROUP BY bugs.bug_id, bugs.bug_id,bugs.bug_severity,bugs.priority,bugs.bug_status,bugs.resolution,bugs.alias,bugs.bug_severity,bugs.priority,bugs.rep_platform,map_assigned_to.login_name,bugs.bug_status,bugs.resolution,bugs.short_desc ORDER BY bugs.bug_id"] at Bugzilla/DB.pm line 71 Bugzilla::DB::SendSQL('SELECT bugs.bug_id, bugs.bug_severity, bugs.priority, bugs.bu...') called at /var/www/html/bugzilla/buglist.cgi line 651 From jwboyer at jdub.homelinux.org Wed Jan 31 20:07:45 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 31 Jan 2007 14:07:45 -0600 Subject: new features in package CVS In-Reply-To: <1170269732.29190.6.camel@cutter> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <13526.1170201942@sss.pgh.pa.us> <20070131010501.GN893@devserv.devel.redhat.com> <15572.1170219164@sss.pgh.pa.us> <45C04967.8060608@hhs.nl> <20070131131541.GB29172@devserv.devel.redhat.com> <1170265511.24867.7.camel@localhost.localdomain> <1170269500.5533.63.camel@zod.rchland.ibm.com> <1170269732.29190.6.camel@cutter> Message-ID: <1170274065.5533.66.camel@zod.rchland.ibm.com> On Wed, 2007-01-31 at 13:55 -0500, seth vidal wrote: > On Wed, 2007-01-31 at 12:51 -0600, Josh Boyer wrote: > > On Wed, 2007-01-31 at 09:45 -0800, David Lutterkort wrote: > > > On Wed, 2007-01-31 at 07:55 -0800, Christopher Stone wrote: > > > > And people at redhat are completely immune to such attacks while the > > > > extra packagers are so nieve that it is very likely to happen once we > > > > open up the core cvs. > > > > > > Don't look at this as a Red Hat vs. the rest of the world thing: even > > > though I have a redhat.com mailing address, I don't expect to get commit > > > access to the kernel, or glibc or 99% of the rest of the Fedora > > > packages. > > > > > > And I don't want it: not having that access limits the things I need to > > > worry about if my account gets compromised. My packages could still have > > > been messed with, but at least it won't ripple into _all_ of Fedora > > > needing an audit to make sure that a break into my account didn't > > > compromise the distro. > > > > This is, perhaps, the sanest explanation of why the ACLs aren't entirely > > a bad thing. > > > > I don't think anyone is arguing that they are entirely a bad thing. In > fact I'm completely cool w/them. I just don't like the attitude coming > from some of the posters to this thread that the unwashed masses outside > of red hat will have their accounts cracked and that will allow the > crackers to compromise red hat's internal network. Yeah, I know. And I agree. I was just trying not to add more fuel to the flames ;) > Maybe then the crackers will have control of the weather manipulation > machine. Hopefully they'll have the sense to warm things up here in MN. josh