From stickster at gmail.com Thu Feb 1 03:34:28 2007 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 31 Jan 2007 22:34:28 -0500 Subject: Package EVR problems in FC+FE 2007-01-29 In-Reply-To: <1170124090.8217.4.camel@localhost> References: <20070129134255.A627415212E@buildsys.fedoraproject.org> <1170117131.15526.5.camel@localhost.localdomain> <1170124090.8217.4.camel@localhost> Message-ID: <1170300868.29469.13.camel@localhost.localdomain> On Mon, 2007-01-29 at 18:28 -0800, Peter Gordon wrote: > 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.) The gnome-games spec has this IIRC. I had everything but the branch removal done. Took care of it this evening, thanks; I'll be watching the report tomorrow to see that this disappears. -- 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 giallu at gmail.com Thu Feb 1 08:31:54 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 1 Feb 2007 09:31:54 +0100 Subject: qemu optflags In-Reply-To: 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: On 31 Jan 2007 10:08:37 -0600, Jason L Tibbitts III wrote: > # 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. +1 No need to start an argument when things out of guidelines are done for a (documented) reason From giallu at gmail.com Thu Feb 1 08:41:31 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 1 Feb 2007 09:41:31 +0100 Subject: rawhide unfrozen In-Reply-To: <1170258513.2880.11.camel@aglarond.local> References: <200701302216.59497.jkeating@redhat.com> <1170258513.2880.11.camel@aglarond.local> Message-ID: On 1/31/07, Jeremy Katz wrote: > > 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 Is there a quick way to know if my packages are going to be included in any of those spins? From bugs.michael at gmx.net Thu Feb 1 11:19:59 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 1 Feb 2007 12:19:59 +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: <20070201121959.d464ebdc.bugs.michael@gmx.net> On Tue, 30 Jan 2007 23:04:08 -0500, Bill Nottingham wrote: [owners.list] > 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. And that's all that stops you from changing the format? ;) Can't we find out what scripts parse owners.list and change those scripts in a coordinated fashion? * owners.list -> bugzilla db cron job http://cvs.fedora.redhat.com/viewcvs/fedora-accounts/bz-make-components.py?root=fedora&rev=1.9&view=log * extras repoclosure / upgradepath checks http://cvs.fedora.redhat.com/viewcvs/extras-repoclosure/PackageOwners.py?root=fedora&rev=1.9&view=log * c4chris' package status report scripts http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/check_owners?root=fedora&rev=1.3&view=log What else? From dwmw2 at infradead.org Thu Feb 1 12:37:35 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 01 Feb 2007 12:37:35 +0000 Subject: qemu optflags In-Reply-To: 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: <1170333455.744.23.camel@hades.cambridge.redhat.com> On Thu, 2007-02-01 at 09:31 +0100, Gianluca Sforna wrote: > > 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. > > +1 > No need to start an argument when things out of guidelines are done > for a (documented) reason Just to avoid any doubt: I'd like to reiterate what I already told Till in private -- he was entirely _correct_ to raise the question here, since I was overly terse when I closed the original bug and _didn't_ provide fully coherent reasoning. Hopefully I've done that sufficiently now, and if anyone disagrees with my decision then they have enough information with which to argue. I'm entirely unoffended by being questioned -- what _would_ offend me, on the other hand, would be to ever hear that someone _refrained_ from asking questions because they thought I might react poorly. -- dwmw2 From Christian.Iseli at licr.org Thu Feb 1 12:58:58 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 1 Feb 2007 13:58:58 +0100 Subject: new features in package CVS In-Reply-To: <20070201121959.d464ebdc.bugs.michael@gmx.net> 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> <20070201121959.d464ebdc.bugs.michael@gmx.net> Message-ID: <20070201135858.6cf2bfa4@ludwig-alpha.unil.ch> On Thu, 1 Feb 2007 12:19:59 +0100, Michael Schwendt wrote: > Can't we find out what scripts parse owners.list and change those scripts > in a coordinated fashion? Fine with me FWIW... Just say the word and I'll change my scripts. Cheers, C From jkeating at redhat.com Thu Feb 1 13:05:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Feb 2007 08:05:19 -0500 Subject: When bumping tcl... Message-ID: <200702010805.19720.jkeating@redhat.com> Please alert folks you're doing this. fedora-maintainers at redhat.com is the right place (you should be subscribed!!). expect - 5.43.0-5.1.i386 requires libtcl8.4.so expectk - 5.43.0-5.1.i386 requires libtk8.4.so expectk - 5.43.0-5.1.i386 requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.i386 requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtcl8.4.so isdn4k-utils-vboxgetty - 3.2-53.fc7.i386 requires libtcl8.4.so postgresql-pltcl - 8.2.1-2.fc7.i386 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtk8.4.so ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtcl8.4.so setools-gui - 3.0-2.fc7.i386 requires libtk8.4.so setools-gui - 3.0-2.fc7.i386 requires libtcl8.4.so tkinter - 2.5-9.fc7.i386 requires libtk8.4.so tkinter - 2.5-9.fc7.i386 requires libtcl8.4.so That's just the list in core, I suspect many more broken in 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 jkeating at redhat.com Thu Feb 1 13:07:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Feb 2007 08:07:48 -0500 Subject: rawhide unfrozen In-Reply-To: References: <200701302216.59497.jkeating@redhat.com> <1170258513.2880.11.camel@aglarond.local> Message-ID: <200702010807.48941.jkeating@redhat.com> On Thursday 01 February 2007 03:41, Gianluca Sforna wrote: > Is there a quick way to know if my packages are going to be included > in any of those spins? In the wiki Release/ pages I'll be keeping the manifest updates for the various spins. You can use this manifest to do the spin yourself with pungi, or look at the full package list pulled in via deps. -- 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 Thu Feb 1 16:07:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Feb 2007 11:07:09 -0500 Subject: new features in package CVS In-Reply-To: <20070201121959.d464ebdc.bugs.michael@gmx.net> 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> <20070201121959.d464ebdc.bugs.michael@gmx.net> Message-ID: <20070201160709.GC12074@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > > 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. > > And that's all that stops you from changing the format? ;) Yep. I'll bring it up with FESCo this week, and check with Toshio on how far out we are with packagedb - if it's just a matter of a few weeks, it may not be worth it. Bill From tibbs at math.uh.edu Thu Feb 1 16:13:12 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Feb 2007 10:13:12 -0600 Subject: new features in package CVS In-Reply-To: <20070201121959.d464ebdc.bugs.michael@gmx.net> 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> <20070201121959.d464ebdc.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> What else? I think there are some bits the security team uses for doing quick lookups on owners.list, but I don't think they'll break from this change. - J< From seg at haxxed.com Thu Feb 1 16:14:01 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 01 Feb 2007 10:14:01 -0600 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: <1170346441.28023.25.camel@localhost.localdomain> On Wed, 2007-01-31 at 08:15 -0500, Alan Cox wrote: > 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 Because a bazillion suspicious commits across thousands of packages from the same person would NEVER get noticed before the repo push... The place to stop this is to have package signing/pushes continue to be a manual process in some way. If something suspicious happens, just don't push the packages to the repos until you're certain you can trust them. I feel fascist ACLs everywhere is damaging to the community. Its a big glowing neon sign saying we DON'T trust each other. It only hides problems. Its the difference between being in the same room with a bunch of people, each holding a knife, and everyone locking themselves in separate rooms holding a knife. Sure, you might not get stabbed in the back right away, but for all you know, someone else might be sitting in their room, stewing and frothing, just waiting for the chance to stab you in the back the second you open the door. I'd rather, err, get stabbed in the back right away. I guess. Okay so that's a bizarre analogy but its all I can think of right now... ... On the other hand, I don't think locking down certain critical packages, like the gcc toolchain and the kernel, is entirely unreasonable. The key here is we should have the tools for detection and prevention to be a community process. It should be a HUMAN process based on trust, not a distrustful, paranoid process based on barriers, fences and walls. -------------- 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 Thu Feb 1 16:20:51 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 01 Feb 2007 10:20:51 -0600 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: <1170346851.28023.27.camel@localhost.localdomain> On Wed, 2007-01-31 at 11:26 +0100, Thorsten Leemhuis wrote: > - 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!) Well then frickin' fix this then. Aren't we moving to a new SCM (git plz) 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 jwboyer at jdub.homelinux.org Thu Feb 1 16:28:17 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 01 Feb 2007 10:28:17 -0600 Subject: new features in package CVS In-Reply-To: <1170346851.28023.27.camel@localhost.localdomain> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <20070131084705.GB2687@free.fr> <20070131104106.4bf25065@ludwig-alpha.unil.ch> <45C06EC6.5060708@leemhuis.info> <1170346851.28023.27.camel@localhost.localdomain> Message-ID: <1170347297.3017.0.camel@vader.jdub.homelinux.org> On Thu, 2007-02-01 at 10:20 -0600, Callum Lerwick wrote: > On Wed, 2007-01-31 at 11:26 +0100, Thorsten Leemhuis wrote: > > - 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!) > > Well then frickin' fix this then. Aren't we moving to a new SCM (git > plz) anyway? The scripts are in CVS. If you'd like to attempt fixing it, that would be great. josh From notting at redhat.com Thu Feb 1 17:04:54 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Feb 2007 12:04:54 -0500 Subject: ACL & notification code... Message-ID: <20070201170454.GA13762@nostromo.devel.redhat.com> ... is now live. *Please* report any issues that you see. Bill From chris.stone at gmail.com Thu Feb 1 17:47:25 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 1 Feb 2007 09:47:25 -0800 Subject: ACL & notification code... In-Reply-To: <20070201170454.GA13762@nostromo.devel.redhat.com> References: <20070201170454.GA13762@nostromo.devel.redhat.com> Message-ID: On 2/1/07, Bill Nottingham wrote: > ... is now live. *Please* report any issues that you see. Well I just did a commit, and the e-mail did not go to the standard e-mail that I normally subscribe to. I currently subscribe to fedora-extras-commits at redhat.com has this changed? From notting at redhat.com Thu Feb 1 18:41:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Feb 2007 13:41:33 -0500 Subject: ACL & notification code... In-Reply-To: References: <20070201170454.GA13762@nostromo.devel.redhat.com> Message-ID: <20070201184133.GA16862@nostromo.devel.redhat.com> Christopher Stone (chris.stone at gmail.com) said: > Well I just did a commit, and the e-mail did not go to the standard > e-mail that I normally subscribe to. > > I currently subscribe to fedora-extras-commits at redhat.com has this changed? I've tried a test commit, and it worked fine for me - both the to-owner notification and the fedora-extras-commits notification came through. Are others seeing this? Bill From chris.stone at gmail.com Thu Feb 1 18:56:51 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 1 Feb 2007 10:56:51 -0800 Subject: ACL & notification code... In-Reply-To: <20070201184133.GA16862@nostromo.devel.redhat.com> References: <20070201170454.GA13762@nostromo.devel.redhat.com> <20070201184133.GA16862@nostromo.devel.redhat.com> Message-ID: On 2/1/07, Bill Nottingham wrote: > Christopher Stone (chris.stone at gmail.com) said: > > Well I just did a commit, and the e-mail did not go to the standard > > e-mail that I normally subscribe to. > > > > I currently subscribe to fedora-extras-commits at redhat.com has this changed? > > I've tried a test commit, and it worked fine for me - both the to-owner > notification and the fedora-extras-commits notification came through. > > Are others seeing this? Your test commit also worked for me here, and I saw josef's attempt to commit. It might be fixed now. However, I never received the yafc commit e-mail. I think I want to see a few more commits come in before I'm convinced its fixed though. From dwmw2 at infradead.org Thu Feb 1 20:12:09 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 01 Feb 2007 20:12:09 +0000 Subject: new features in package CVS In-Reply-To: <20070130230311.GA16319@nostromo.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> Message-ID: <1170360729.29759.481.camel@pmac.infradead.org> On Tue, 2007-01-30 at 18:03 -0500, Bill Nottingham wrote: > - packages, by default, on import will have a empty pkg.acl added. > These can be removed by the owner if they truly wish. Please don't do it this way round by default. Have _no_ pkg.acl by default. If a maintainer _wants_ to avoid teamwork then let him/her add it for themselves. -- dwmw2 From chris.stone at gmail.com Thu Feb 1 20:25:47 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 1 Feb 2007 12:25:47 -0800 Subject: new features in package CVS In-Reply-To: <1170360729.29759.481.camel@pmac.infradead.org> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <1170360729.29759.481.camel@pmac.infradead.org> Message-ID: On 2/1/07, David Woodhouse wrote: > On Tue, 2007-01-30 at 18:03 -0500, Bill Nottingham wrote: > > - packages, by default, on import will have a empty pkg.acl added. > > These can be removed by the owner if they truly wish. > > Please don't do it this way round by default. Have _no_ pkg.acl by > default. If a maintainer _wants_ to avoid teamwork then let him/her add > it for themselves. Yea, I don't understand why the new default is different than the old default? Shouldn't we be consistent? From wart at kobold.org Thu Feb 1 21:04:59 2007 From: wart at kobold.org (Michael Thomas) Date: Thu, 01 Feb 2007 13:04:59 -0800 Subject: When bumping tcl... In-Reply-To: <200702010805.19720.jkeating@redhat.com> References: <200702010805.19720.jkeating@redhat.com> Message-ID: <45C255FB.6010909@kobold.org> Jesse Keating wrote: > Please alert folks you're doing this. fedora-maintainers at redhat.com is the > right place (you should be subscribed!!). > [...] > > That's just the list in core, I suspect many more broken in Extras. I've fixed tcllib in Extras. Even though it doesn't have a dependency on libtcl8.4.so, it does have a directory dependency on the /usr/lib/tcl8.4 directory. This leads me to a related issue: Tcl searches for packages in 3 directories: * /usr/share/tcl8.5 * /usr/share * /usr/lib The search algorithm involves going into each subdirectory of these three directories, looking for a file named 'pkgIndex.tcl', and then reading it. Since there are quite a few subdirectories in /usr/share and /usr/lib that aren't tcl-related, this results in a lot of wasted time and effort. To fix, the default value for 'auto_path' in Tcl needs to be reduced to 2 directories: /usr/lib{64}/tcl8.x and /usr/share/tcl8.x. My informal tests have shown that this can reduce the initial load time for Tcl scripts from 3.7s to 0.2s. Tcl extension packages in Fedora would also have to be modified to install into these version-specific tcl directories, instead of the current convention of /usr/lib|/usr/share. A 'tcl-sitearch' macro would also be needed in Tcl package spec files to detect the correct install directory. This would bring Tcl more in line with the directory structure used by other scripting languages (perl, python) in Fedora, and give Tcl applications a boost in startup times. I'll file this request in Bugzilla, but was hoping to get feedback from the Fedora devs, especially those who maintain Tcl extensions, before any changes were made. --Wart From opensource at till.name Thu Feb 1 22:24:07 2007 From: opensource at till.name (Till Maas) Date: Thu, 01 Feb 2007 23:24:07 +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: <200702012324.22985.opensource@till.name> On Wednesday 31 January 2007 00:03, Bill Nottingham wrote: > Access is determined as follows: > > No pkg.acl file: all are allowed access How about changing this to "all that are sponsors or fesco members or maintain at least x packages / are maintainer for at least y months are allowed access" with maybe x = 5 and y = 6? And then change the default of new packages to to pkg.acl file. 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 Thu Feb 1 23:12:47 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 2 Feb 2007 00:12:47 +0100 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: <20070202001247.2d52fab6@ludwig-alpha.unil.ch> Hey, all you happy reviewers :-) I think I have an XML-RPC script working to query them flags... Warren wanted to setup a static web page with the current BZ ticket status and update it every half hour. Unfortunately, he's disappeared from IRC and I'll soon go catch some Zs, so I put up a quick wiki page here with the output of the script: http://fedoraproject.org/wiki/ChristianIseli/ReviewFlagStatus I'm not aware of a possibility to update the wiki page from a cron job on my machine, but if there's one, just shout... I guess by tomorrow we'll figure out something better. Cheers, C From rc040203 at freenet.de Fri Feb 2 03:07:32 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Feb 2007 04:07:32 +0100 Subject: core review status? Message-ID: <1170385652.2588.321.camel@mccallum.corsepiu.local> Hi, What's the status with the Core review? How are contributors supposed to proceed? ATM, at least to me, the situation is pretty unclear. Particular problems: - Warren's Core Merge reviews point into cvsview, i.e. into RH's internal cvs. This is very inconvenient to use. Is this CVS publicly directly accessible? - Unlike with ordinary reviews there are no src.rpms to check. How are non-redhatters supposed to get the files? rawhide? - I am suspecting Warren's flag'ed reviews to loose mails. Amongst the flood of mails it had triggered (unless I am missing something) I am receiving fragments seemingly stemming from comments on package reviews. - I am seeing strange "state changes", e.g. owners closing their own reviews, review requests with "FE-NEW" and some without. To cut a long story short: Is there a document/wiki/README describing how this is supposed to be continued? Ralf From jeff at ocjtech.us Fri Feb 2 03:14:03 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 01 Feb 2007 21:14:03 -0600 Subject: core review status? In-Reply-To: <1170385652.2588.321.camel@mccallum.corsepiu.local> References: <1170385652.2588.321.camel@mccallum.corsepiu.local> Message-ID: <1170386043.3608.9.camel@lt21223.campus.dmacc.edu> On Fri, 2007-02-02 at 04:07 +0100, Ralf Corsepius wrote: > > Particular problems: > - Warren's Core Merge reviews point into cvsview, i.e. into RH's > internal cvs. This is very inconvenient to use. > Is this CVS publicly directly accessible? cvs -d :pserver:anonymous at cvs.fedora.redhat.com:/cvs/dist co > - Unlike with ordinary reviews there are no src.rpms to check. > How are non-redhatters supposed to get the files? rawhide? Once you have the code checked out, you can "make srpm" or "make " in the branch subdirectory. Jeff -------------- 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 Fri Feb 2 03:57:52 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Feb 2007 04:57:52 +0100 Subject: core review status? In-Reply-To: <1170386043.3608.9.camel@lt21223.campus.dmacc.edu> References: <1170385652.2588.321.camel@mccallum.corsepiu.local> <1170386043.3608.9.camel@lt21223.campus.dmacc.edu> Message-ID: <1170388672.2588.327.camel@mccallum.corsepiu.local> On Thu, 2007-02-01 at 21:14 -0600, Jeffrey C. Ollie wrote: > On Fri, 2007-02-02 at 04:07 +0100, Ralf Corsepius wrote: > > > > Particular problems: > > - Warren's Core Merge reviews point into cvsview, i.e. into RH's > > internal cvs. This is very inconvenient to use. > > Is this CVS publicly directly accessible? > > cvs -d :pserver:anonymous at cvs.fedora.redhat.com:/cvs/dist co Ah! /dist/ that's the trick! > > - Unlike with ordinary reviews there are no src.rpms to check. > > How are non-redhatters supposed to get the files? rawhide? > > Once you have the code checked out, you can "make srpm" or "make " > in the branch subdirectory. Thanks Ralf From j.w.r.degoede at hhs.nl Fri Feb 2 07:31:30 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 02 Feb 2007 08:31:30 +0100 Subject: core review status? In-Reply-To: <1170388672.2588.327.camel@mccallum.corsepiu.local> References: <1170385652.2588.321.camel@mccallum.corsepiu.local> <1170386043.3608.9.camel@lt21223.campus.dmacc.edu> <1170388672.2588.327.camel@mccallum.corsepiu.local> Message-ID: <45C2E8D2.2040509@hhs.nl> Ralf Corsepius wrote: > On Thu, 2007-02-01 at 21:14 -0600, Jeffrey C. Ollie wrote: >> On Fri, 2007-02-02 at 04:07 +0100, Ralf Corsepius wrote: >>> Particular problems: >>> - Warren's Core Merge reviews point into cvsview, i.e. into RH's >>> internal cvs. This is very inconvenient to use. >>> Is this CVS publicly directly accessible? >> cvs -d :pserver:anonymous at cvs.fedora.redhat.com:/cvs/dist co > > Ah! /dist/ that's the trick! > >>> - Unlike with ordinary reviews there are no src.rpms to check. >>> How are non-redhatters supposed to get the files? rawhide? >> Once you have the code checked out, you can "make srpm" or "make " >> in the branch subdirectory. > > Thanks > Ralf > That may solve this particular question, but I for one would still very much like to see the whole process documented in a clear step by step way, much like the FE contributers guide. (Unlike others?) I haven't had the time to follow all the threads abouts this and I would still like to help. Also I believe that one should NEED to read all the threads to be able to contribute, thus we need some documentation on this. Regards, Hans From fedora at camperquake.de Fri Feb 2 07:40:11 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 2 Feb 2007 08:40:11 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070202001247.2d52fab6@ludwig-alpha.unil.ch> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C0C864.2050303@redhat.com> <20070202001247.2d52fab6@ludwig-alpha.unil.ch> Message-ID: <20070202084011.3b8ce8c9@banea.int.addix.net> Hi. On Fri, 2 Feb 2007 00:12:47 +0100, Christian Iseli wrote: > I think I have an XML-RPC script working to query them flags... If you have some spare time in the future, could you produce a writeup about what RPC calls you know for redhat bugzilla? This seems to be gloriously undocumented, at least I have not been able to find docs about it, and I'd really like to ditch the web interface for as much tasks as possible. From rc040203 at freenet.de Fri Feb 2 07:53:19 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Feb 2007 08:53:19 +0100 Subject: core review status? In-Reply-To: <45C2E8D2.2040509@hhs.nl> References: <1170385652.2588.321.camel@mccallum.corsepiu.local> <1170386043.3608.9.camel@lt21223.campus.dmacc.edu> <1170388672.2588.327.camel@mccallum.corsepiu.local> <45C2E8D2.2040509@hhs.nl> Message-ID: <1170402799.2588.348.camel@mccallum.corsepiu.local> On Fri, 2007-02-02 at 08:31 +0100, Hans de Goede wrote: > That may solve this particular question, but I for one would still very > much like to see the whole process documented in a clear step by step > way, much like the FE contributers guide. > > (Unlike others?) No, you're not alone. Though I hope to have been able to follow (at least most of it), I am also quite confused when it comes to details, e.g.: * How is this "flags thing" supposed to work/to be used? Why was this necessary at all? Though I believe to have understood the idea, ATM, I find it more confusing than helpful. * Some people mentioned some "overview wiki" - where is it? * Will Core packages physically be moved into Extras CVS after they passed review? If yes, when will this happen? * I am observing RH/Core people more or less _silently_ abandoning/ orphaning packages as part of the Core/Extras review. Though it's natural to see packages being abandoned/adopted during release preps. I'd really prefer @redhat.com's doing this openly in public with a loud and clear "abandoning mail" * How are Extra->Core mergers, respective RH adoptions of current Extra packages supposed to be handled? ... Ralf From Christian.Iseli at licr.org Fri Feb 2 09:30:37 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 2 Feb 2007 10:30:37 +0100 Subject: core review status? In-Reply-To: <1170385652.2588.321.camel@mccallum.corsepiu.local> References: <1170385652.2588.321.camel@mccallum.corsepiu.local> Message-ID: <20070202103037.1db18c13@ludwig-alpha.unil.ch> On Fri, 02 Feb 2007 04:07:32 +0100, Ralf Corsepius wrote: > To cut a long story short: Is there a document/wiki/README describing > how this is supposed to be continued? The closest there is atm is this message: https://www.redhat.com/archives/fedora-maintainers/2007-January/msg00340.html AFAIK, warren will put something up on the wiki RSN... Cheers, C From Christian.Iseli at licr.org Fri Feb 2 09:35:16 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 2 Feb 2007 10:35:16 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070202084011.3b8ce8c9@banea.int.addix.net> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C0C864.2050303@redhat.com> <20070202001247.2d52fab6@ludwig-alpha.unil.ch> <20070202084011.3b8ce8c9@banea.int.addix.net> Message-ID: <20070202103516.4967fed0@ludwig-alpha.unil.ch> On Fri, 2 Feb 2007 08:40:11 +0100, Ralf Ertzinger wrote: > If you have some spare time in the future, could you produce a > writeup about what RPC calls you know for redhat bugzilla? This > seems to be gloriously undocumented, at least I have not been able to > find docs about it, and I'd really like to ditch the web interface > for as much tasks as possible. I can feel your pain. I hope some docs can be made public RSN... C From sander at hoentjen.eu Fri Feb 2 11:23:10 2007 From: sander at hoentjen.eu (Sander Hoentjen) Date: Fri, 2 Feb 2007 12:23:10 +0100 (CET) Subject: When bumping tcl... Message-ID: <62317.213.84.157.18.1170415390.squirrel@hoentjen.eu> Thomas wrote: > > This leads me to a related issue: > > Tcl searches for packages in 3 directories: > * /usr/share/tcl8.5 > * /usr/share > * /usr/lib > > The search algorithm involves going into each subdirectory of these three directories, looking for a file named 'pkgIndex.tcl', and then reading it. Since there are quite a few subdirectories in /usr/share and /usr/lib that aren't tcl-related, this results in a lot of wasted time and effort. > > To fix, the default value for 'auto_path' in Tcl needs to be reduced to 2 directories: /usr/lib{64}/tcl8.x and /usr/share/tcl8.x. My informal tests have shown that this can reduce the initial load time for Tcl scripts from 3.7s to 0.2s. > Although I am not a tcl maintainer, I would like to say that this sounds like a very good idea to me. It will probably create some breakage (packages that have to be updated), so we should do it sooner rather then later to have it working perfectly by the time Fedora 7 comes out. I can't see any downsides except for the fact that it will be a tad more difficult to get non-fedora packaged packages to work. Would it be ok to already change my tcl packages to go to /usr/lib{64}/tcl8.x ? This will not affect anything at all, except for reduced polution of libdir. Sander From Christian.Iseli at licr.org Fri Feb 2 15:14:19 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 2 Feb 2007 16:14:19 +0100 Subject: disclaimed ownership of core packages Message-ID: <20070202161419.20a3bdd5@ludwig-alpha.unil.ch> Hi folks, It seems there are a few cases of disclaimed ownership of core packages, e.g.: https://bugzilla.redhat.com/226558 I was wondering if maybe it would be a good idea to mark those as fedora?review- until they find a new owner ? Thoughts ? C From notting at redhat.com Fri Feb 2 15:38:23 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 Feb 2007 10:38:23 -0500 Subject: core review status? In-Reply-To: <1170402799.2588.348.camel@mccallum.corsepiu.local> References: <1170385652.2588.321.camel@mccallum.corsepiu.local> <1170386043.3608.9.camel@lt21223.campus.dmacc.edu> <1170388672.2588.327.camel@mccallum.corsepiu.local> <45C2E8D2.2040509@hhs.nl> <1170402799.2588.348.camel@mccallum.corsepiu.local> Message-ID: <20070202153823.GD6613@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > * Will Core packages physically be moved into Extras CVS after they > passed review? If yes, when will this happen? Eventually. Due to build dependency chains, we can't move things willy nilly. Bill From fedora at camperquake.de Fri Feb 2 15:47:51 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 2 Feb 2007 16:47:51 +0100 Subject: core review status? In-Reply-To: <20070202153823.GD6613@nostromo.devel.redhat.com> References: <1170385652.2588.321.camel@mccallum.corsepiu.local> <1170386043.3608.9.camel@lt21223.campus.dmacc.edu> <1170388672.2588.327.camel@mccallum.corsepiu.local> <45C2E8D2.2040509@hhs.nl> <1170402799.2588.348.camel@mccallum.corsepiu.local> <20070202153823.GD6613@nostromo.devel.redhat.com> Message-ID: <20070202164751.756a46e1@banea.int.addix.net> Hi. On Fri, 2 Feb 2007 10:38:23 -0500, Bill Nottingham wrote: > Eventually. Due to build dependency chains, we can't move things > willy nilly. Maybe review from the leaves of the dependency tree down, as far as possible? From rc040203 at freenet.de Fri Feb 2 15:57:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Feb 2007 16:57:36 +0100 Subject: core review status? In-Reply-To: <20070202153823.GD6613@nostromo.devel.redhat.com> References: <1170385652.2588.321.camel@mccallum.corsepiu.local> <1170386043.3608.9.camel@lt21223.campus.dmacc.edu> <1170388672.2588.327.camel@mccallum.corsepiu.local> <45C2E8D2.2040509@hhs.nl> <1170402799.2588.348.camel@mccallum.corsepiu.local> <20070202153823.GD6613@nostromo.devel.redhat.com> Message-ID: <1170431856.2588.376.camel@mccallum.corsepiu.local> On Fri, 2007-02-02 at 10:38 -0500, Bill Nottingham wrote: > Ralf Corsepius (rc040203 at freenet.de) said: > > * Will Core packages physically be moved into Extras CVS after they > > passed review? If yes, when will this happen? > > Eventually. Due to build dependency chains, we can't move things > willy nilly. I don't have to understand everything ;) If Core packages will be moved to Extras CVS, I would expect this not to be any different from adding an arbitrary package to Extras rsp. not to be any different from as Extra->Core package movers had been handled so far ?!? Nor would I expect this to be of any importance to the buildsystem, because it's yum-based, which would mean it should not matter from where/which repo a package is being pulled from - It will simply pickup the newest. But this wasn't the actual question I wanted to ask - My question actually was: Where (in which CVS/VCS) can which packages be found at which stage of the review/merger? Ralf From Axel.Thimm at ATrpms.net Fri Feb 2 15:57:50 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 2 Feb 2007 16:57:50 +0100 Subject: owners Message-ID: <20070202155750.GA24394@neu.nirvana> Hi, I remember that something was done about owners.list these days, but the instructions on the wiki on how to proceed differently are missing. **** Access denied: athimm is not in ACL for owners cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! Could someone please add me to the proper group for owners? Thanks! -- 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 Feb 2 15:59:34 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Feb 2007 16:59:34 +0100 Subject: core review status? In-Reply-To: <1170431856.2588.376.camel@mccallum.corsepiu.local> References: <1170385652.2588.321.camel@mccallum.corsepiu.local> <1170386043.3608.9.camel@lt21223.campus.dmacc.edu> <1170388672.2588.327.camel@mccallum.corsepiu.local> <45C2E8D2.2040509@hhs.nl> <1170402799.2588.348.camel@mccallum.corsepiu.local> <20070202153823.GD6613@nostromo.devel.redhat.com> <1170431856.2588.376.camel@mccallum.corsepiu.local> Message-ID: <1170431974.2588.379.camel@mccallum.corsepiu.local> On Fri, 2007-02-02 at 16:57 +0100, Ralf Corsepius wrote: > On Fri, 2007-02-02 at 10:38 -0500, Bill Nottingham wrote: > > Ralf Corsepius (rc040203 at freenet.de) said: > > > * Will Core packages physically be moved into Extras CVS after they > > > passed review? If yes, when will this happen? > > > > Eventually. Due to build dependency chains, we can't move things > > willy nilly. > If Core packages will be moved to Extras CVS, I would expect this not to > be any different from adding an arbitrary package to Extras rsp. not to > be any different from as Extra->Core package movers had been handled so Stupid me: Of cause conversely: Core->Extra Ralf From wtogami at redhat.com Fri Feb 2 16:33:55 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 02 Feb 2007 11:33:55 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070202001247.2d52fab6@ludwig-alpha.unil.ch> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C0C864.2050303@redhat.com> <20070202001247.2d52fab6@ludwig-alpha.unil.ch> Message-ID: <45C367F3.5050700@redhat.com> Christian Iseli wrote: > Hey, all you happy reviewers :-) > > I think I have an XML-RPC script working to query them flags... > > Warren wanted to setup a static web page with the current BZ ticket > status and update it every half hour. Unfortunately, he's disappeared > from IRC and I'll soon go catch some Zs, so I put up a quick wiki page > here with the output of the script: > http://fedoraproject.org/wiki/ChristianIseli/ReviewFlagStatus We talked about this in #fedora-admin, and Christian agreed to tweak his script to output to a static HTML page. This will be put online somewhere and auto-generated on a regular basis. Warren Togami wtogami at redhat.com From rc040203 at freenet.de Fri Feb 2 16:42:17 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Feb 2007 17:42:17 +0100 Subject: core review status? In-Reply-To: <1170386043.3608.9.camel@lt21223.campus.dmacc.edu> References: <1170385652.2588.321.camel@mccallum.corsepiu.local> <1170386043.3608.9.camel@lt21223.campus.dmacc.edu> Message-ID: <1170434537.2588.404.camel@mccallum.corsepiu.local> On Thu, 2007-02-01 at 21:14 -0600, Jeffrey C. Ollie wrote: > On Fri, 2007-02-02 at 04:07 +0100, Ralf Corsepius wrote: > > > > Particular problems: > > - Warren's Core Merge reviews point into cvsview, i.e. into RH's > > internal cvs. This is very inconvenient to use. > > Is this CVS publicly directly accessible? > > cvs -d :pserver:anonymous at cvs.fedora.redhat.com:/cvs/dist co > > > - Unlike with ordinary reviews there are no src.rpms to check. > > How are non-redhatters supposed to get the files? rawhide? > > Once you have the code checked out, you can "make srpm" or "make " > in the branch subdirectory. Apparently, this anonymous-cvs server is a mirror of something inside of redhat and only sync'ed at intervals :( Would have been nice if somebody had communicated this, beforehand. Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 2 17:08:33 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 2 Feb 2007 18:08:33 +0100 Subject: owners In-Reply-To: <20070202155750.GA24394@neu.nirvana> References: <20070202155750.GA24394@neu.nirvana> Message-ID: <20070202180833.79766559@python3.es.egwn.lan> Axel Thimm wrote : > I remember that something was done about owners.list these days, but > the instructions on the wiki on how to proceed differently are > missing. > > **** Access denied: athimm is not in ACL for owners > cvs commit: Pre-commit check failed > cvs [commit aborted]: correct above errors first! > > Could someone please add me to the proper group for owners? Thanks! Actually : - 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.) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.84 1.05 1.24 From chris.stone at gmail.com Fri Feb 2 17:20:15 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 2 Feb 2007 09:20:15 -0800 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: On 1/29/07, Ville Skytt? wrote: > Quite a few packages produce useless -debuginfos nowadays. In addition to Hi, is it possible to add a check for this when running rpmlint against a debuginfo package? Regards, Chris From Christian.Iseli at licr.org Fri Feb 2 17:36:42 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 2 Feb 2007 18:36:42 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C367F3.5050700@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C0C864.2050303@redhat.com> <20070202001247.2d52fab6@ludwig-alpha.unil.ch> <45C367F3.5050700@redhat.com> Message-ID: <20070202183642.45853c2c@ludwig-alpha.unil.ch> On Fri, 02 Feb 2007 11:33:55 -0500, Warren Togami wrote: > We talked about this in #fedora-admin, and Christian agreed to tweak his > script to output to a static HTML page. This will be put online > somewhere and auto-generated on a regular basis. The script is now in CVS here: http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/getReviewByFlags?root=fedora&rev=1.1&view=auto Can you or mmcgrath put it in a cron job somewhere ? /me will be afk for a while now... Cheers, C From Axel.Thimm at ATrpms.net Fri Feb 2 18:15:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 2 Feb 2007 19:15:40 +0100 Subject: owners In-Reply-To: <20070202180833.79766559@python3.es.egwn.lan> References: <20070202155750.GA24394@neu.nirvana> <20070202180833.79766559@python3.es.egwn.lan> Message-ID: <20070202181540.GB27211@neu.nirvana> On Fri, Feb 02, 2007 at 06:08:33PM +0100, Matthias Saou wrote: > Axel Thimm wrote : > > > I remember that something was done about owners.list these days, but > > the instructions on the wiki on how to proceed differently are > > missing. > > > > **** Access denied: athimm is not in ACL for owners > > cvs commit: Pre-commit check failed > > cvs [commit aborted]: correct above errors first! > > > > Could someone please add me to the proper group for owners? Thanks! > > Actually : > > - 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.) Thanks, I sent an email with a diff. -- 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 wart at kobold.org Fri Feb 2 18:29:51 2007 From: wart at kobold.org (Michael Thomas) Date: Fri, 02 Feb 2007 10:29:51 -0800 Subject: When bumping tcl... In-Reply-To: <62317.213.84.157.18.1170415390.squirrel@hoentjen.eu> References: <62317.213.84.157.18.1170415390.squirrel@hoentjen.eu> Message-ID: <45C3831F.4080204@kobold.org> Sander Hoentjen wrote: > Thomas wrote: >> This leads me to a related issue: >> >> Tcl searches for packages in 3 directories: >> * /usr/share/tcl8.5 >> * /usr/share >> * /usr/lib >> >> The search algorithm involves going into each subdirectory of these > three directories, looking for a file named 'pkgIndex.tcl', and then > reading it. Since there are quite a few subdirectories in /usr/share > and /usr/lib that aren't tcl-related, this results in a lot of wasted > time and effort. >> To fix, the default value for 'auto_path' in Tcl needs to be reduced to > 2 directories: /usr/lib{64}/tcl8.x and /usr/share/tcl8.x. My informal > tests have shown that this can reduce the initial load time for Tcl > scripts from 3.7s to 0.2s. > Although I am not a tcl maintainer, I would like to say that this sounds > like a very good idea to me. It will probably create some breakage > (packages that have to be updated), so we should do it sooner rather then > later to have it working perfectly by the time Fedora 7 comes out. I can't > see any downsides except for the fact that it will be a tad more difficult > to get non-fedora packaged packages to work. > > Would it be ok to already change my tcl packages to go to > /usr/lib{64}/tcl8.x ? > This will not affect anything at all, except for reduced polution of libdir. This should be fine since the current package path for Tcl will find these in /usr/lib{64}/tcl8.x. If these are noarch packages, however, you should use /usr/share/tcl8.x. Even though /usr/lib/tcl8.x is currently a symlink to /usr/share/tcl8.x, this may change in the future if we ever properly separate arch-specific and noarch packages. --Wart From tmz at pobox.com Fri Feb 2 20:08:24 2007 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 2 Feb 2007 15:08:24 -0500 Subject: Merge Review: libgpod Message-ID: <20070202200824.GQ14777@psilocybe.teonanacatl.org> Hi all, I just completed a review for the libgpod package. I'm fairly green at doing reviews so if anyone would care to look over it and double check my work it would be appreciated (though hopefully unnecessary). My main question is on resolving the bug. Will the process be similar to current Extras policy and closing the bug left up to the package owner or is there another method for the mass review? Overall I think I did the flags and assignments correctly based on what I've read here about the process. Please correct me if that's not the case. (I did find the mail stating that I had granted my own request for the review to be mildly amusing... :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== Learn from the mistakes of others--you can never live long enough to make them all yourself. -- John Luther -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From stickster at gmail.com Fri Feb 2 21:28:55 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 02 Feb 2007 16:28:55 -0500 Subject: rawhide unfrozen In-Reply-To: <1170258513.2880.11.camel@aglarond.local> References: <200701302216.59497.jkeating@redhat.com> <1170258513.2880.11.camel@aglarond.local> Message-ID: <1170451735.21668.14.camel@localhost.localdomain> On Wed, 2007-01-31 at 10:48 -0500, Jeremy Katz wrote: > 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 ...[snip]... > 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) /me meekly raises hand: ...with the exception, I would think, of fedora-release-notes, for obvious reasons. I'm pretty sure you intended that meaning, but if someone has any related check/validation script or tool in the works using this policy, that would be an exception. I have no idea what sort of tool that might be, but, you know, just in case. ;-) -- 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 buildsys at fedoraproject.org Fri Feb 2 22:15:51 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 2 Feb 2007 17:15:51 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-02-02 Message-ID: <20070202221551.2A27D15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.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) libxslt FC6-updates > FC7 (0:1.1.20-1.fc6 > 0:1.1.20-1) 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) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.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) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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) 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) lists AT forevermore.net: yafc FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.fc6) mdehaan AT redhat.com: cobbler FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.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 linux.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) cobbler: mdehaan AT redhat.com FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.fc6) 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) 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) 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) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) 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 linux.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.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) 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) yafc: lists AT forevermore.net FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.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 denis at poolshark.org Fri Feb 2 23:10:21 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 02 Feb 2007 15:10:21 -0800 Subject: Merge Review: libgpod In-Reply-To: <20070202200824.GQ14777@psilocybe.teonanacatl.org> References: <20070202200824.GQ14777@psilocybe.teonanacatl.org> Message-ID: <45C3C4DD.4050804@poolshark.org> Todd Zullinger wrote: > Hi all, > > I just completed a review for the libgpod package. I'm fairly green > at doing reviews so if anyone would care to look over it and double > check my work it would be appreciated (though hopefully unnecessary). The package seems to deal with two different tarballs, and generate libgpod (0.4.2) and compat-libgpod (0.3.2) from the same spec file. This is somewhat unusual, should this get review approval ? I would prefer if the package were split in two personally. -denis From pertusus at free.fr Fri Feb 2 23:16:15 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 3 Feb 2007 00:16:15 +0100 Subject: Merge Review: libgpod In-Reply-To: <45C3C4DD.4050804@poolshark.org> References: <20070202200824.GQ14777@psilocybe.teonanacatl.org> <45C3C4DD.4050804@poolshark.org> Message-ID: <20070202231615.GA3111@free.fr> On Fri, Feb 02, 2007 at 03:10:21PM -0800, Denis Leroy wrote: > Todd Zullinger wrote: > >Hi all, > > > >I just completed a review for the libgpod package. I'm fairly green > >at doing reviews so if anyone would care to look over it and double > >check my work it would be appreciated (though hopefully unnecessary). > > The package seems to deal with two different tarballs, and generate > libgpod (0.4.2) and compat-libgpod (0.3.2) from the same spec file. > > This is somewhat unusual, should this get review approval ? I would > prefer if the package were split in two personally. Indeed, this is much better. To me this is a blocker. -- Pat From tmz at pobox.com Fri Feb 2 23:38:54 2007 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 2 Feb 2007 18:38:54 -0500 Subject: Merge Review: libgpod In-Reply-To: <45C3C4DD.4050804@poolshark.org> References: <20070202200824.GQ14777@psilocybe.teonanacatl.org> <45C3C4DD.4050804@poolshark.org> Message-ID: <20070202233854.GR14777@psilocybe.teonanacatl.org> Denis Leroy wrote: > The package seems to deal with two different tarballs, and generate > libgpod (0.4.2) and compat-libgpod (0.3.2) from the same spec file. > > This is somewhat unusual, should this get review approval ? I would > prefer if the package were split in two personally. The compat-libgpod package is only generated for FC6 and isn't part of the F7/devel branch. I did the review on the devel branch only, as it seemed to me that the other branches weren't relevant for the purposes of the merge. Is that not the case? I was the one who submitted the changes to Alex for the compat-libgpod package in the FC6 spec. I believe Alex suggested that since it was going to be short-lived there wasn't too much reason to make it a separate package. I'm not sure what the policy or standard practice is regarding compat- packages. Pointers and examples would be welcome, of course, even if it's not totally relevant in this case. BTW, apologies for not adding a link to the bug in my previous post. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226022 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe. -- Albert Einstein (1879-1955) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From denis at poolshark.org Sat Feb 3 00:15:07 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 02 Feb 2007 16:15:07 -0800 Subject: Merge Review: libgpod In-Reply-To: <20070202233854.GR14777@psilocybe.teonanacatl.org> References: <20070202200824.GQ14777@psilocybe.teonanacatl.org> <45C3C4DD.4050804@poolshark.org> <20070202233854.GR14777@psilocybe.teonanacatl.org> Message-ID: <45C3D40B.2050004@poolshark.org> Todd Zullinger wrote: > Denis Leroy wrote: >> The package seems to deal with two different tarballs, and generate >> libgpod (0.4.2) and compat-libgpod (0.3.2) from the same spec file. >> >> This is somewhat unusual, should this get review approval ? I would >> prefer if the package were split in two personally. > > The compat-libgpod package is only generated for FC6 and isn't part of > the F7/devel branch. I did the review on the devel branch only, as it > seemed to me that the other branches weren't relevant for the purposes > of the merge. Is that not the case? > > I was the one who submitted the changes to Alex for the compat-libgpod > package in the FC6 spec. I believe Alex suggested that since it was > going to be short-lived there wasn't too much reason to make it a > separate package. I'm not sure what the policy or standard practice > is regarding compat- packages. Pointers and examples would be > welcome, of course, even if it's not totally relevant in this case. > > BTW, apologies for not adding a link to the bug in my previous post. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226022 I'm sorry, yes i was looking at the fc-6 spec file. The devel spec file looks much better. Review looks good to me. From tmz at pobox.com Sat Feb 3 00:31:35 2007 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 2 Feb 2007 19:31:35 -0500 Subject: Merge Review: libgpod In-Reply-To: <45C3D40B.2050004@poolshark.org> References: <20070202200824.GQ14777@psilocybe.teonanacatl.org> <45C3C4DD.4050804@poolshark.org> <20070202233854.GR14777@psilocybe.teonanacatl.org> <45C3D40B.2050004@poolshark.org> Message-ID: <20070203003134.GS14777@psilocybe.teonanacatl.org> Denis Leroy wrote: > I'm sorry, yes i was looking at the fc-6 spec file. The devel spec > file looks much better. Review looks good to me. My fault for not adding a link to the review and making you have to dig manually. :) Thanks for looking it over Denis. If anyone knows about the process of closing the merge reviews a pointer would be very helpful. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== Never was a government that was not composed of liars, malefactors and thieves. -- Cicero, last Free Consul of Rome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From chitlesh at fedoraproject.org Sat Feb 3 02:39:57 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 3 Feb 2007 03:39:57 +0100 Subject: CVS upload failed Message-ID: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> Hello there, I was uploading my approved package, but it didn't turn to be successfully. What should I do overcome this ? Chitlesh chitlesh(~)[2]$./common/cvs-import.sh /home/chitlesh/rpmbuild/SRPMS/liborigin-20070115-3.src.rpm Checking out the modules file... Creating new module: liborigin cvs diff: [02:32:39] waiting for chitlesh's lock in /cvs/extras/CVSROOT cvs diff: [02:33:09] obtained lock in /cvs/extras/CVSROOT Running syncmail... Mailing cvsextras at fedora.redhat.com ... ...syncmail done. Running syncmail... Mailing relnotes at fedoraproject.org... ...syncmail done. Running syncmail... Mailing cvsextras at fedora.redhat.com ... ...syncmail done. Running syncmail... Mailing relnotes at fedoraproject.org... ...syncmail done. cvs commit: Pre-commit check failed cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! Entry for module 'liborigin' created. Checking out module: 'liborigin' Unpacking source package: liborigin-20070115-3.src.rpm... L liborigin-20070115.tgz A liborigin.spec make: *** No rule to make target `upload'. Stop. ERROR: Uploading the source tarballs failed! -- http://clunixchit.blogspot.com From mtasaka at ioa.s.u-tokyo.ac.jp Sat Feb 3 02:49:29 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 03 Feb 2007 11:49:29 +0900 Subject: CVS upload failed In-Reply-To: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> Message-ID: <45C3F839.9010107@ioa.s.u-tokyo.ac.jp> Chitlesh GOORAH wrote: > Hello there, > > I was uploading my approved package, but it didn't turn to be successfully. > What should I do overcome this ? I met the same problem as you when I tried to import _new_ package "kazehakase". It seems that somehow kazehakase directory is created, so I had to * copy the necessary files (Makefiles, etc..) from other package * rename module name in Makefile * upload source, add spec file... all manually. Currently the problem you are seeing seems to happed on every _new_ package. Mamoru Tasaka From jeff at ocjtech.us Sat Feb 3 02:52:51 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 02 Feb 2007 20:52:51 -0600 Subject: CVS upload failed In-Reply-To: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> Message-ID: <1170471171.4339.5.camel@lt21223.campus.dmacc.edu> On Sat, 2007-02-03 at 03:39 +0100, Chitlesh GOORAH wrote: > Hello there, > > I was uploading my approved package, but it didn't turn to be successfully. > What should I do overcome this ? I've seen the same thing. When I tried to overcome the problem by simulating the import by hand, I get: **** Access denied: jcollie is not in ACL for rpms/bcfg2/devel I think that there's a bug somewhere in the new ACL system... Too bad most of the people that might be able to fix the problem are at FUDCon (and at the time I'm writing this are probably out at a pub somewhere). Jeff -------------- 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 jeff at ocjtech.us Sat Feb 3 02:55:44 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 02 Feb 2007 20:55:44 -0600 Subject: CVS upload failed In-Reply-To: <45C3F839.9010107@ioa.s.u-tokyo.ac.jp> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> <45C3F839.9010107@ioa.s.u-tokyo.ac.jp> Message-ID: <1170471344.4339.9.camel@lt21223.campus.dmacc.edu> On Sat, 2007-02-03 at 11:49 +0900, Mamoru Tasaka wrote: > Chitlesh GOORAH wrote: > > Hello there, > > > > I was uploading my approved package, but it didn't turn to be successfully. > > What should I do overcome this ? > > I met the same problem as you when I tried to import > _new_ package "kazehakase". > > It seems that somehow kazehakase directory is created, so > I had to > > * copy the necessary files (Makefiles, etc..) from other > package > * rename module name in Makefile > * upload source, add spec file... all manually. > > Currently the problem you are seeing seems to happed on > every _new_ package. I wasn't even able to manually add the files, I get a access denied error: **** Access denied: jcollie is not in ACL for rpms/bcfg2/devel Jeff -------------- 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 chitlesh at fedoraproject.org Sat Feb 3 03:35:32 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 3 Feb 2007 04:35:32 +0100 Subject: CVS upload failed In-Reply-To: <45C3F839.9010107@ioa.s.u-tokyo.ac.jp> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> <45C3F839.9010107@ioa.s.u-tokyo.ac.jp> Message-ID: <13dbfe4f0702021935i6adbb5e5qe9eeb9321a059ff2@mail.gmail.com> On 2/3/07, Mamoru Tasaka wrote: > It seems that somehow kazehakase directory is created, so > I had to > > * copy the necessary files (Makefiles, etc..) from other > package > * rename module name in Makefile > * upload source, add spec file... all manually. Can you tell us how you did it so that we may have a temporary fix meanwhile :) ? Chitlesh -- http://clunixchit.blogspot.com From mtasaka at ioa.s.u-tokyo.ac.jp Sat Feb 3 04:04:37 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 03 Feb 2007 13:04:37 +0900 Subject: CVS upload failed In-Reply-To: <13dbfe4f0702021935i6adbb5e5qe9eeb9321a059ff2@mail.gmail.com> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> <45C3F839.9010107@ioa.s.u-tokyo.ac.jp> <13dbfe4f0702021935i6adbb5e5qe9eeb9321a059ff2@mail.gmail.com> Message-ID: <45C409D5.8090904@ioa.s.u-tokyo.ac.jp> Chitlesh GOORAH wrote: > Can you tell us how you did it so that we may have a temporary fix > meanwhile :) ? > > > Chitlesh What I did was: 1. Firstly "./common/cvs-import.sh " This used to send 6 mails to me before, but this time only 2 mails were sent to me and 4 other necessary process seemed to have failed. 2. mail to cvs admin so as to have package name added to owners.list 3. Anyway try "cvs co foo" (foo is the new package) You can see the new directory for the new package seems to be created. 4. Well, then checkout another existing package, for example "cvs co comix" 5. "cp comix/devel/Makefile foo/devel/" and go to foo/deve/ directory 6. Change the line of "NAME :=" in foo/devel/Makefile correctly 7 Do: cvs add Makefile -> make commit -m "firstly add Makefile" 8. cp all files in your srpm (srpm itself is not needed) to foo/devel/ directory 9. Do: make new-sources files="" 10. cvs add "" 11 cvs add .cvsignore sources 12 cvs diff -u ; make clog ; cvs commit -F clog Then perhaps okay... From jeff at ocjtech.us Sat Feb 3 05:58:04 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 02 Feb 2007 23:58:04 -0600 Subject: new features in package CVS In-Reply-To: <20070130230311.GA16319@nostromo.devel.redhat.com> References: <20070130230311.GA16319@nostromo.devel.redhat.com> Message-ID: <1170482284.4339.32.camel@lt21223.campus.dmacc.edu> On Tue, 2007-01-30 at 18:03 -0500, Bill Nottingham wrote: > > 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. After trying to import a new package tonight, I'd have to say something is broken in this process. The package import didn't work, leaving a partial directory structure in place. No pkg.acl was created as far as I can tell, yet I'm locked out: **** Access denied: jcollie is not in ACL for rpms/bcfg2/devel cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! Since I'm locked out, I can't fix the partial import. Jeff -------------- 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 Sat Feb 3 10:53:46 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 3 Feb 2007 11:53:46 +0100 Subject: CVS upload failed In-Reply-To: <1170471171.4339.5.camel@lt21223.campus.dmacc.edu> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> <1170471171.4339.5.camel@lt21223.campus.dmacc.edu> Message-ID: <20070203115346.f673df02.bugs.michael@gmx.net> On Fri, 02 Feb 2007 20:52:51 -0600, Jeffrey C. Ollie wrote: > On Sat, 2007-02-03 at 03:39 +0100, Chitlesh GOORAH wrote: > > Hello there, > > > > I was uploading my approved package, but it didn't turn to be successfully. > > What should I do overcome this ? > > I've seen the same thing. When I tried to overcome the problem by > simulating the import by hand, I get: > > **** Access denied: jcollie is not in ACL for rpms/bcfg2/devel > > I think that there's a bug somewhere in the new ACL system... It looks very much like that. The "liborigin" import is partial and without a "Makefile". > Too bad > most of the people that might be able to fix the problem are at FUDCon > (and at the time I'm writing this are probably out at a pub somewhere). Previously, it used to be easy to fix such problems manually. The ACLs have made that impossible. From chris.stone at gmail.com Sat Feb 3 16:26:47 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 3 Feb 2007 08:26:47 -0800 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: On 1/30/07, Warren Togami wrote: > 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. Guys, I have to say this constant switching back and forth of ASIGNEE is not a good idea. Not only is it a pain in the keister to keep on switching the ASIGNEE back and forth like a tennis ball, but if the packager forgets to do this, then the reviewer will never get e-mails on the bug. From notting at redhat.com Sat Feb 3 16:31:00 2007 From: notting at redhat.com (Bill Nottingham) Date: Sat, 3 Feb 2007 11:31:00 -0500 Subject: new features in package CVS In-Reply-To: <1170482284.4339.32.camel@lt21223.campus.dmacc.edu> References: <20070130230311.GA16319@nostromo.devel.redhat.com> <1170482284.4339.32.camel@lt21223.campus.dmacc.edu> Message-ID: <20070203163100.GA4293@nostromo.devel.redhat.com> Jeffrey C. Ollie (jeff at ocjtech.us) said: > After trying to import a new package tonight, I'd have to say something > is broken in this process. The package import didn't work, leaving a > partial directory structure in place. No pkg.acl was created as far as > I can tell, yet I'm locked out: What errors were there in the import? Bill From notting at redhat.com Sat Feb 3 16:42:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Sat, 3 Feb 2007 11:42:03 -0500 Subject: CVS upload failed In-Reply-To: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> Message-ID: <20070203164203.GA4576@nostromo.devel.redhat.com> Chitlesh GOORAH (chitlesh at fedoraproject.org) said: > I was uploading my approved package, but it didn't turn to be successfully. > What should I do overcome this ? I know what's going on here, and I apologize for the inconvenience. Working on getting this fixed sanely. Bill From bugs.michael at gmx.net Sat Feb 3 19:15:24 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 3 Feb 2007 20:15:24 +0100 Subject: Broken deps in FC6 Updates Message-ID: <20070203201524.8fd1667f.bugs.michael@gmx.net> Noticed by coincidence, since they are filtered out by extras-repoclosure. All except for the first one is multi-lib breakage: source rpm: python-virtinst-0.98.0-1.fc6.src.rpm package: python-virtinst - 0.98.0-1.fc6.noarch from fedora-core-updates-6-ppc unresolved deps: libvirt-python >= 0:0.1.4-4 source rpm: bind-9.3.4-1.fc6.src.rpm package: bind-devel - 31:9.3.4-1.fc6.i386 from fedora-core-updates-6-x86_64 unresolved deps: libdns.so.22 libbind9.so.0 libisccc.so.0 liblwres.so.9 libisccfg.so.1 libisc.so.11 source rpm: kdeedu-3.5.5-0.1.fc6.src.rpm package: kdeedu - 3.5.5-0.1.fc6.i386 from fedora-core-updates-6-x86_64 unresolved deps: libpython2.4.so.1.0 source rpm: kdeutils-3.5.5-0.1.fc6.src.rpm package: kdeutils-devel - 6:3.5.5-0.1.fc6.i386 from fedora-core-updates-6-x86_64 unresolved deps: libkmilo.so.1 libkregexpeditorcommon.so.1 libksimcore.so.1 libkhexeditcommon.so.0 libkcmlaptop.so.0 source rpm: poppler-0.5.4-5.fc6.src.rpm package: poppler-devel - 0.5.4-5.fc6.i386 from fedora-core-updates-6-x86_64 unresolved deps: libpoppler-qt.so.1 From berrange at redhat.com Sat Feb 3 19:26:52 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 3 Feb 2007 19:26:52 +0000 Subject: Broken deps in FC6 Updates In-Reply-To: <20070203201524.8fd1667f.bugs.michael@gmx.net> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> Message-ID: <20070203192652.GA1179@redhat.com> On Sat, Feb 03, 2007 at 08:15:24PM +0100, Michael Schwendt wrote: > Noticed by coincidence, since they are filtered out by extras-repoclosure. > All except for the first one is multi-lib breakage: > > source rpm: python-virtinst-0.98.0-1.fc6.src.rpm > package: python-virtinst - 0.98.0-1.fc6.noarch from fedora-core-updates-6-ppc > unresolved deps: > libvirt-python >= 0:0.1.4-4 No clue why that's complaining. The python-virtinst spec file has an explict 'ExcludeArch: ppc ppc64' rule in there, so it shouldn't ever make it to the fedora-core-updates-6-ppc collection. 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 chitlesh at fedoraproject.org Sat Feb 3 20:28:12 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 3 Feb 2007 21:28:12 +0100 Subject: CVS upload failed In-Reply-To: <20070203164203.GA4576@nostromo.devel.redhat.com> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> <20070203164203.GA4576@nostromo.devel.redhat.com> Message-ID: <13dbfe4f0702031228m6f1e1c8elda6874d82b4dee77@mail.gmail.com> On 2/3/07, Bill Nottingham wrote: > I know what's going on here, and I apologize for the inconvenience. Working > on getting this fixed sanely. Thanks, let us know when it's done. Chitlesh -- http://clunixchit.blogspot.com From bugs.michael at gmx.net Sat Feb 3 22:39:23 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 3 Feb 2007 23:39:23 +0100 Subject: Broken deps in FC6 Updates In-Reply-To: <20070203192652.GA1179@redhat.com> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <20070203192652.GA1179@redhat.com> Message-ID: <20070203233923.73aa3f73.bugs.michael@gmx.net> On Sat, 3 Feb 2007 19:26:52 +0000, Daniel P. Berrange wrote: > > Noticed by coincidence, since they are filtered out by extras-repoclosure. > > All except for the first one is multi-lib breakage: > > > > source rpm: python-virtinst-0.98.0-1.fc6.src.rpm > > package: python-virtinst - 0.98.0-1.fc6.noarch from fedora-core-updates-6-ppc > > unresolved deps: > > libvirt-python >= 0:0.1.4-4 > > No clue why that's complaining. The python-virtinst spec file has an > explict 'ExcludeArch: ppc ppc64' rule in there, so it shouldn't ever > make it to the fedora-core-updates-6-ppc collection. Ack. $ rpm -qp --qf %{excludearch}\\n python-virtinst-0.98.0-1.fc6.src.rpm ppc But since the build is in the ppc repo, then there's a bug in the push process somewhere. From bugs.michael at gmx.net Sat Feb 3 22:39:23 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 3 Feb 2007 23:39:23 +0100 Subject: Broken deps in FC6 Updates In-Reply-To: <20070203192652.GA1179@redhat.com> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <20070203192652.GA1179@redhat.com> Message-ID: <20070203233923.73aa3f73.bugs.michael@gmx.net> On Sat, 3 Feb 2007 19:26:52 +0000, Daniel P. Berrange wrote: > > Noticed by coincidence, since they are filtered out by extras-repoclosure. > > All except for the first one is multi-lib breakage: > > > > source rpm: python-virtinst-0.98.0-1.fc6.src.rpm > > package: python-virtinst - 0.98.0-1.fc6.noarch from fedora-core-updates-6-ppc > > unresolved deps: > > libvirt-python >= 0:0.1.4-4 > > No clue why that's complaining. The python-virtinst spec file has an > explict 'ExcludeArch: ppc ppc64' rule in there, so it shouldn't ever > make it to the fedora-core-updates-6-ppc collection. Ack. $ rpm -qp --qf %{excludearch}\\n python-virtinst-0.98.0-1.fc6.src.rpm ppc But since the build is in the ppc repo, then there's a bug in the push process somewhere. From jkeating at redhat.com Sat Feb 3 22:59:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 17:59:22 -0500 Subject: Broken deps in FC6 Updates In-Reply-To: <20070203233923.73aa3f73.bugs.michael@gmx.net> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <20070203192652.GA1179@redhat.com> <20070203233923.73aa3f73.bugs.michael@gmx.net> Message-ID: <200702031759.22970.jkeating@redhat.com> On Saturday 03 February 2007 17:39, Michael Schwendt wrote: > But since the build is in the ppc repo, then there's a bug in the push > process somewhere. Uh, how did it get built in the first place? Doesn't ExcludeArch mean it won't get built there? -- 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 Sat Feb 3 23:08:33 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 4 Feb 2007 00:08:33 +0100 Subject: Broken deps in FC6 Updates In-Reply-To: <200702031759.22970.jkeating@redhat.com> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <20070203192652.GA1179@redhat.com> <20070203233923.73aa3f73.bugs.michael@gmx.net> <200702031759.22970.jkeating@redhat.com> Message-ID: <20070204000833.3a5e86ba.bugs.michael@gmx.net> On Sat, 3 Feb 2007 17:59:22 -0500, Jesse Keating wrote: > On Saturday 03 February 2007 17:39, Michael Schwendt wrote: > > But since the build is in the ppc repo, then there's a bug in the push > > process somewhere. > > Uh, how did it get built in the first place? Doesn't ExcludeArch mean it > won't get built there? BuildArch: noarch ExcludeArch: ppc [In comparison, the Extras push script examines the src.rpm for the ExcludeArch tag and doesn't push such noarch packages to the excluded target repos. That is something that has been said is done for Core, too. IIRC, either jkatz or sopwith has said that.] From Christian.Iseli at licr.org Sun Feb 4 00:20:16 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sun, 4 Feb 2007 01:20:16 +0100 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: <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> On Sat, 3 Feb 2007 08:26:47 -0800, Christopher Stone wrote: > Guys, I have to say this constant switching back and forth of ASIGNEE > is not a good idea. Not only is it a pain in the keister to keep on > switching the ASIGNEE back and forth like a tennis ball, but if the > packager forgets to do this, then the reviewer will never get e-mails > on the bug. prolly a good idea to have both in the CC field... From Christian.Iseli at licr.org Sun Feb 4 00:38:45 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sun, 4 Feb 2007 01:38:45 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C367F3.5050700@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C0C864.2050303@redhat.com> <20070202001247.2d52fab6@ludwig-alpha.unil.ch> <45C367F3.5050700@redhat.com> Message-ID: <20070204013845.5117cb6c@ludwig-alpha.unil.ch> On Fri, 02 Feb 2007 11:33:55 -0500, Warren Togami wrote: > We talked about this in #fedora-admin, and Christian agreed to tweak his > script to output to a static HTML page. This will be put online > somewhere and auto-generated on a regular basis. It seems the perl-SOAP-Lite requirement of the perl script was problematic for the EL-4 servers, so I attempted a translation to python of the script. The result is here: http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/pyGetReviewByFlags?root=fedora&rev=1.1&view=auto My python-fu is real low, so feel free to improve and tweak to taste... Cheers, C From dgregor at redhat.com Sun Feb 4 00:51:53 2007 From: dgregor at redhat.com (Dennis Gregorovic) Date: Sat, 03 Feb 2007 19:51:53 -0500 Subject: Broken deps in FC6 Updates In-Reply-To: <20070204000833.3a5e86ba.bugs.michael@gmx.net> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <20070203192652.GA1179@redhat.com> <20070203233923.73aa3f73.bugs.michael@gmx.net> <200702031759.22970.jkeating@redhat.com> <20070204000833.3a5e86ba.bugs.michael@gmx.net> Message-ID: <1170550313.5370.18.camel@dennis.gregorovic.net> On Sun, 2007-02-04 at 00:08 +0100, Michael Schwendt wrote: > On Sat, 3 Feb 2007 17:59:22 -0500, Jesse Keating wrote: > > > On Saturday 03 February 2007 17:39, Michael Schwendt wrote: > > > But since the build is in the ppc repo, then there's a bug in the push > > > process somewhere. > > > > Uh, how did it get built in the first place? Doesn't ExcludeArch mean it > > won't get built there? > > BuildArch: noarch > ExcludeArch: ppc > > > [In comparison, the Extras push script examines the src.rpm for the > ExcludeArch tag and doesn't push such noarch packages to the excluded > target repos. That is something that has been said is done for Core, > too. IIRC, either jkatz or sopwith has said that.] Looks like this needs to be fixed in the current Fedora Core updates scripts. I've sent a patch to Luke. -- Dennis From kevin at tummy.com Sun Feb 4 03:18:10 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Sat, 3 Feb 2007 20:18:10 -0700 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> Message-ID: <20070203201810.6bdd8141@ningauble.scrye.com> On Sun, 4 Feb 2007 01:20:16 +0100 Christian.Iseli at licr.org (Christian Iseli) wrote: > On Sat, 3 Feb 2007 08:26:47 -0800, Christopher Stone wrote: > > Guys, I have to say this constant switching back and forth of > > ASIGNEE is not a good idea. Not only is it a pain in the keister > > to keep on switching the ASIGNEE back and forth like a tennis ball, > > but if the packager forgets to do this, then the reviewer will > > never get e-mails on the bug. > > prolly a good idea to have both in the CC field... At least for the core merge review requests, the redhat "owner" of the package is already in the CC, so they at least will get all emails from it even if they aren't assigned. I kind of like the moving of assigned. It shows who next needs to take action. Of course something like NEEDINFO (emailaddress) might work as well. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Sun Feb 4 05:10:31 2007 From: notting at redhat.com (Bill Nottingham) Date: Sun, 4 Feb 2007 00:10:31 -0500 Subject: CVS upload failed In-Reply-To: <13dbfe4f0702031228m6f1e1c8elda6874d82b4dee77@mail.gmail.com> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> <20070203164203.GA4576@nostromo.devel.redhat.com> <13dbfe4f0702031228m6f1e1c8elda6874d82b4dee77@mail.gmail.com> Message-ID: <20070204051030.GB11824@nostromo.devel.redhat.com> Chitlesh GOORAH (chitlesh at fedoraproject.org) said: > On 2/3/07, Bill Nottingham wrote: > >I know what's going on here, and I apologize for the inconvenience. Working > >on getting this fixed sanely. > > Thanks, > let us know when it's done. So, the simple solution is to send the request for owners.list/etc addtion *before* the import, and the basic directory structure can then be laid down by the admin. I've updated the new package process; it involves adding requests to CVSSyncNeeded. Bill From chris.stone at gmail.com Sun Feb 4 05:30:11 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 3 Feb 2007 21:30:11 -0800 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070203201810.6bdd8141@ningauble.scrye.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> Message-ID: On 2/3/07, Kevin Fenzi wrote: > I kind of like the moving of assigned. It shows who next needs to take > action. Of course something like NEEDINFO (emailaddress) might work as > well. I don't. It's an extra step that most people will forget to do. I'm just not going to bother, I'm going to assign it to me (the reviewer) and be done with it. Plus, was there *ever* any confusion before this change as to who next needs to take action?? I simply do not see any extra benefit from all this extra work. We are supposed to be making things *easier*, not more difficult. Another case is all these extras steps, now not only do we have to rely on someone to make cvs branches, we also have to rely on someone to add entries to owners.list, next it will be comps, then we will have to get permissions just to edit our own packages! I do *not* like the direction things have been moving recently. I sincerely hope that these problems will be worked out and things will eventually get simpler and more streamlined. I want to see less red tape, not more. From chris.stone at gmail.com Sun Feb 4 05:36:30 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 3 Feb 2007 21:36:30 -0800 Subject: CVS upload failed In-Reply-To: <20070204051030.GB11824@nostromo.devel.redhat.com> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> <20070203164203.GA4576@nostromo.devel.redhat.com> <13dbfe4f0702031228m6f1e1c8elda6874d82b4dee77@mail.gmail.com> <20070204051030.GB11824@nostromo.devel.redhat.com> Message-ID: On 2/3/07, Bill Nottingham wrote: > Chitlesh GOORAH (chitlesh at fedoraproject.org) said: > > On 2/3/07, Bill Nottingham wrote: > > >I know what's going on here, and I apologize for the inconvenience. Working > > >on getting this fixed sanely. > > > > Thanks, > > let us know when it's done. > > So, the simple solution is to send the request for owners.list/etc > addtion *before* the import, and the basic directory structure can > then be laid down by the admin. I've updated the new package process; > it involves adding requests to CVSSyncNeeded. ummmmm, yeah. So, anyone want to e-mail me when things are actually working again and packagers don't have to jump through a half dozen different hoops and email 14 different people just to check in their packages? Thanks. From mtasaka at ioa.s.u-tokyo.ac.jp Sun Feb 4 06:04:27 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 04 Feb 2007 15:04:27 +0900 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> Message-ID: <45C5776B.3020009@ioa.s.u-tokyo.ac.jp> Christian Iseli wrote: > prolly a good idea to have both in the CC field... > By the way, is there any way to check who approved the package (i.e. currently who marked the bug block FE-ACCEPT -> in the future who changed the flag to fedora-review+ ) by *everyone*? For example, can the person who are not fedorabug group (perhaps a newbie people is in this state) check this? And.. when the flag is changed to fedora-review- and assingee is changed to the review submitter, can *other* people check who is reviewing the review currently? There are some cases in that submitter changed something according to the reviewer's comments, however the reviewer does not respond to the submitter. Currently when I found the case, I change the status to "NEEDINFO from ASSIGNEE", however, when using fedora-review flag method, can this be done, even if the flag is fedora-review- and the bug is assinged to the reporter, not the potential reviewer, by _other_ people? From dan at danny.cz Sun Feb 4 09:42:19 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sun, 04 Feb 2007 10:42:19 +0100 Subject: %find_lang and localized man pages Message-ID: <1170582139.3668.11.camel@eagle.danny.cz> Hello, when doing some "merge" reviews I have found out, that it could be useful to extend the functionality of the %find_lang macro to process also localized man pages or to create a new macro (e.g. %find_man). It would solve manual writing of %lang($lang) %{_mandir}/$lang/man?/* in the files section. Somebody from Mandriva already had the same idea (http://archives.mandrivalinux.com/cooker/2006-08/msg00907.php) ;-) Dan From bugs.michael at gmx.net Sun Feb 4 10:20:51 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 4 Feb 2007 11:20:51 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> Message-ID: <20070204112051.612bcbeb.bugs.michael@gmx.net> On Sat, 3 Feb 2007 21:30:11 -0800, Christopher Stone wrote: > I do *not* like the direction things have been moving recently. Me neither. Too many symptoms of a construction yard that has grown out of proportions. fedora-package-review list has become even less readable due to the jump in traffic and superfluous bugzilla spam (like switching the assignee back and forth). The locked down owners.list makes it impossible to fix typos in it. Sections of the Wiki are locked, too, even for people with valid Wiki accounts. Mailing the people who have edited the locked pages last doesn't lead to anything as they don't reply. Replys to fedora-extras-commits list are directed to a list that is not read by the people who should read it. Resurrecting dead packages has become more difficult, too, especially for new contributors. Too many steps and points of failure that can easily become an unpleasant experience for the new contributors. From mtasaka at ioa.s.u-tokyo.ac.jp Sun Feb 4 10:36:36 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 04 Feb 2007 19:36:36 +0900 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070204112051.612bcbeb.bugs.michael@gmx.net> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> Message-ID: <45C5B734.60204@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote: > On Sat, 3 Feb 2007 21:30:11 -0800, Christopher Stone wrote: > >> I do *not* like the direction things have been moving recently. > > Me neither. And me neither... More and more the package review process, the process of importing new/existing packages etc... become complicated, just more and more it becomes difficult for people to participating in Fedora. Recent movement may be aimed for the refinement of review process, however, for me it is just a obstacle to contribute to Fedora. Mamoru From chitlesh at fedoraproject.org Sun Feb 4 11:01:16 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 4 Feb 2007 12:01:16 +0100 Subject: CVS upload failed In-Reply-To: <20070204051030.GB11824@nostromo.devel.redhat.com> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> <20070203164203.GA4576@nostromo.devel.redhat.com> <13dbfe4f0702031228m6f1e1c8elda6874d82b4dee77@mail.gmail.com> <20070204051030.GB11824@nostromo.devel.redhat.com> Message-ID: <13dbfe4f0702040301g47d777dfw231da5879a9abdea@mail.gmail.com> On 2/4/07, Bill Nottingham wrote: > I've updated the new package process; > it involves adding requests to CVSSyncNeeded. Sounds fair enough. but I still get even if liborigin and dolphin have been added to ownerlist: chitlesh(~)[0]$./common/cvs-import.sh rpmbuild/SRPMS/liborigin-20070115-3.src.rpm Checking out the modules file... Module 'liborigin' already exists... Checking out module: 'liborigin' Unpacking source package: liborigin-20070115-3.src.rpm... L liborigin-20070115.tgz A liborigin.spec make: *** No rule to make target `upload'. Stop. ERROR: Uploading the source tarballs failed! same for dolphin Chitlesh -- http://clunixchit.blogspot.com From mtasaka at ioa.s.u-tokyo.ac.jp Sun Feb 4 11:02:00 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 04 Feb 2007 20:02:00 +0900 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C5B734.60204@ioa.s.u-tokyo.ac.jp> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <45C5B734.60204@ioa.s.u-tokyo.ac.jp> Message-ID: <45C5BD28.2060906@ioa.s.u-tokyo.ac.jp> Mamoru Tasaka wrote: > And me neither... > More and more the package review process, the process of importing > new/existing packages etc... become complicated, just more and more > it becomes difficult for people to participating in Fedora. > And more and more slowly it becomes to do something on Fedora.. doing some immediate fix (like fixing typo as Michael said). Even now, it is already!! Mamoru From buildsys at fedoraproject.org Sun Feb 4 11:32:05 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 4 Feb 2007 06:32:05 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-02-04 Message-ID: <20070204113205.351E715212F@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.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) libxslt FC6-updates > FC7 (0:1.1.20-1.fc6 > 0:1.1.20-1) 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) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) cgoorah AT yahoo.com.au: kdmtheme FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) 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) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) dlutter AT redhat.com: puppet FE5 > FE7 (0:0.22.1-1.fc5 > 0:0.22.0-1.fc7) FE6 > FE7 (0:0.22.1-1.fc6 > 0:0.22.0-1.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: 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) 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) gemi AT bluewin.ch: genius FE5 > FE7 (0:0.7.7-1.fc5 > 0:0.7.6.1-3.fc6) FE6 > FE7 (0:0.7.7-1.fc6 > 0:0.7.6.1-3.fc6) skencil FE6 > FE7 (0:0.6.17-10.fc6 > 0:0.6.17-8.fc6) jfontain AT free.fr: moomps FE5 > FE7 (0:5.8-2.fc5 > 0:5.8-1.fc7) FE6 > FE7 (0:5.8-2.fc6 > 0:5.8-1.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) lists AT forevermore.net: yafc FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.fc6) mdehaan AT redhat.com: cobbler FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.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 linux.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) boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.fc6) 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) genius: gemi AT bluewin.ch FE5 > FE7 (0:0.7.7-1.fc5 > 0:0.7.6.1-3.fc6) FE6 > FE7 (0:0.7.7-1.fc6 > 0:0.7.6.1-3.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) 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) kdmtheme: cgoorah AT yahoo.com.au FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) moomps: jfontain AT free.fr FE5 > FE7 (0:5.8-2.fc5 > 0:5.8-1.fc7) FE6 > FE7 (0:5.8-2.fc6 > 0:5.8-1.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) puppet: dlutter AT redhat.com FE5 > FE7 (0:0.22.1-1.fc5 > 0:0.22.0-1.fc7) FE6 > FE7 (0:0.22.1-1.fc6 > 0:0.22.0-1.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 linux.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) skencil: gemi AT bluewin.ch FE6 > FE7 (0:0.6.17-10.fc6 > 0:0.6.17-8.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) 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) yafc: lists AT forevermore.net FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.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 Feb 4 11:55:11 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 4 Feb 2007 12:55:11 +0100 Subject: CVS upload failed In-Reply-To: <13dbfe4f0702040301g47d777dfw231da5879a9abdea@mail.gmail.com> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> <20070203164203.GA4576@nostromo.devel.redhat.com> <13dbfe4f0702031228m6f1e1c8elda6874d82b4dee77@mail.gmail.com> <20070204051030.GB11824@nostromo.devel.redhat.com> <13dbfe4f0702040301g47d777dfw231da5879a9abdea@mail.gmail.com> Message-ID: <20070204125511.dfba8b97.bugs.michael@gmx.net> On Sun, 4 Feb 2007 12:01:16 +0100, Chitlesh GOORAH wrote: > On 2/4/07, Bill Nottingham wrote: > > I've updated the new package process; > > it involves adding requests to CVSSyncNeeded. > > Sounds fair enough. > > but I still get even if liborigin and dolphin have been added to ownerlist: > chitlesh(~)[0]$./common/cvs-import.sh > rpmbuild/SRPMS/liborigin-20070115-3.src.rpm > Checking out the modules file... > Module 'liborigin' already exists... > Checking out module: 'liborigin' > Unpacking source package: liborigin-20070115-3.src.rpm... > L liborigin-20070115.tgz > A liborigin.spec > make: *** No rule to make target `upload'. Stop. > ERROR: Uploading the source tarballs failed! > > same for dolphin Return to Mamoru Tasaka's reply earlier in this thread. You need to copy+modify+add+commit a proper Makefile, which is where the import ended prematurely. With ACLs in place, you need to fix it yourself. From opensource at till.name Sun Feb 4 12:22:18 2007 From: opensource at till.name (Till Maas) Date: Sun, 04 Feb 2007 13:22:18 +0100 Subject: Encoding of text-files / documentation Message-ID: <200702041322.28450.opensource@till.name> Hiyas, currently the Package Guidelines only mentions the encoding of the spec and .desktop files. Iirc I saw in some reviews that the encoding of documentation (/usr/doc/*) should be UTF-8, too. When it is not, the non ascii characters are not displayed correctly in less. This is why I want to propose to add to the guidlines that UTF-8 should be used unless it breaks a program. 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 chitlesh at fedoraproject.org Sun Feb 4 12:57:53 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 4 Feb 2007 13:57:53 +0100 Subject: CVS upload failed In-Reply-To: <45C409D5.8090904@ioa.s.u-tokyo.ac.jp> References: <13dbfe4f0702021839o67d4443fw41457606e14d71ac@mail.gmail.com> <45C3F839.9010107@ioa.s.u-tokyo.ac.jp> <13dbfe4f0702021935i6adbb5e5qe9eeb9321a059ff2@mail.gmail.com> <45C409D5.8090904@ioa.s.u-tokyo.ac.jp> Message-ID: <13dbfe4f0702040457w1a569173ye121d91868d665b7@mail.gmail.com> On 2/3/07, Mamoru Tasaka wrote: > What I did was: > 1. Firstly "./common/cvs-import.sh " > This used to send 6 mails to me before, but this time only > 2 mails were sent to me and 4 other necessary process seemed > to have failed. > 2. mail to cvs admin so as to have package name added to owners.list > 3. Anyway try "cvs co foo" (foo is the new package) > You can see the new directory for the new package seems to > be created. > 4. Well, then checkout another existing package, for example > "cvs co comix" > 5. "cp comix/devel/Makefile foo/devel/" and go to foo/deve/ directory > 6. Change the line of "NAME :=" in foo/devel/Makefile correctly > 7 Do: cvs add Makefile -> make commit -m "firstly add Makefile" > 8. cp all files in your srpm (srpm itself is not needed) to foo/devel/ > directory > 9. Do: make new-sources files="" > 10. cvs add "" > 11 cvs add .cvsignore sources > 12 cvs diff -u ; make clog ; cvs commit -F clog > > Then perhaps okay... I replace your steps 7 to 12 by: cvs add Makefile cvs commit ./common/cvs-import-.sh MYSRPM.src.rpm cvs co MYSRPM make tag make build Chitlesh -- http://clunixchit.blogspot.com From jkeating at redhat.com Sun Feb 4 14:52:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 4 Feb 2007 09:52:56 -0500 Subject: Broken deps in FC6 Updates In-Reply-To: <20070204000833.3a5e86ba.bugs.michael@gmx.net> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <200702031759.22970.jkeating@redhat.com> <20070204000833.3a5e86ba.bugs.michael@gmx.net> Message-ID: <200702040952.56905.jkeating@redhat.com> On Saturday 03 February 2007 18:08, Michael Schwendt wrote: > BuildArch: noarch > ExcludeArch: ppc > > > [In comparison, the Extras push script examines the src.rpm for the > ExcludeArch tag and doesn't push such noarch packages to the excluded > target repos. That is something that has been said is done for Core, > too. IIRC, either jkatz or sopwith has said that.] I'd really like to start discussion again on stop calling these things 'noarch' when they aren't 'noarch'. If your package doesn't work on other arches, it can't be noarch. It either needs to no-op on other arches, or not be noarch. I'm really tired of having to play games with digging at a sourcerpm to figure out what arches a package is suitable for, since this information isn't carried forward in the resultant rpm. We either need to fix rpm so that this information is carried forward, or just stop calling these things noarch. -- 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 Sun Feb 4 15:21:51 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 4 Feb 2007 16:21:51 +0100 Subject: Broken deps in FC6 Updates In-Reply-To: <200702040952.56905.jkeating@redhat.com> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <200702031759.22970.jkeating@redhat.com> <20070204000833.3a5e86ba.bugs.michael@gmx.net> <200702040952.56905.jkeating@redhat.com> Message-ID: <20070204162151.6e35be12.bugs.michael@gmx.net> On Sun, 4 Feb 2007 09:52:56 -0500, Jesse Keating wrote: > On Saturday 03 February 2007 18:08, Michael Schwendt wrote: > > BuildArch: noarch > > ExcludeArch: ppc > > > > > > [In comparison, the Extras push script examines the src.rpm for the > > ExcludeArch tag and doesn't push such noarch packages to the excluded > > target repos. That is something that has been said is done for Core, > > too. IIRC, either jkatz or sopwith has said that.] > > I'd really like to start discussion again on stop calling these > things 'noarch' when they aren't 'noarch'. If your package doesn't work on > other arches, it can't be noarch. It either needs to no-op on other arches, > or not be noarch. I'm really tired of having to play games with digging at a > sourcerpm to figure out what arches a package is suitable for, since this > information isn't carried forward in the resultant rpm. We either need to > fix rpm so that this information is carried forward, or just stop calling > these things noarch. That would make some packaging scenarios impossible, unfortunately. E.g. noarch [data/script/plugin/backend] packages, which are useless without their arch-specific main programs. When we faced this topic in Extras and FESCo, nobody showed any interest in it. --- Begin forwarded message: From: Michael Schwendt To: fesco Subject: ExcludeArch for noarch (was: Re: nx requires and provides) Date: Sat, 10 Jun 2006 23:32:43 +0200 In-Reply-To: <448A7CBD.9080402 at gmail.com> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.18; i386-redhat-linux-gnu) On Sat, 10 Jun 2006 12:13:24 -0400, Jeremy Katz wrote: > On Sat, 2006-06-10 at 01:03 -0700, Rick Stout wrote: > > First, nx *does not* work on x86_64, so it has an Excludearch: x86_64 in > > the spec. This is fine for the arch exclusion, but there is a package > > that depends on nx, freenx which is noarch (its just a bunch of > > scripts), so the build reports show that freenx has a broken dependency > > on x86_64. What is the best way to handle this? Can I Excludearch: > > x86_64 on a noarch package? How about a requires: wrapped in an ifnarch > > conditional? > > The way we handle this with Core at the moment is an ExcludeArch in the > noarch package and then the tree composition scripts use that to say > "no, don't pull this package into the $arch tree". Similar in the > Extras scripts may well make a lot of sense. Done. [However, I cannot get excludearch information from the noarch rpm, but only from the srcrpm. "rpm" itself also returns "(none)" when querying ExcludeArch noarch packages with querytag %{excludearch} and succeeds only for src.rpm files.] Shall we turn this on in the push script? --- End forwarded message From ville.skytta at iki.fi Sun Feb 4 15:59:11 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 4 Feb 2007 17:59:11 +0200 Subject: Missing merge review tickets, core->extras dependencies Message-ID: <200702041759.11322.ville.skytta@iki.fi> A couple of questions regarding merge reviews that I haven't spotted an answer for anywhere: 1) It looks like there are some merge review tickets missing. For example, I thought I'd take a look at reviewing pcsc-lite and ccid, but couldn't find tickets for them in Bugzilla. Is this intentional? If yes, is there a list of those packages somewhere? 2) Are Core packages under review allowed to have build and install time dependencies to packages in Extras nowadays or (still) not? From berrange at redhat.com Sun Feb 4 16:06:00 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 4 Feb 2007 16:06:00 +0000 Subject: Broken deps in FC6 Updates In-Reply-To: <200702040952.56905.jkeating@redhat.com> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <200702031759.22970.jkeating@redhat.com> <20070204000833.3a5e86ba.bugs.michael@gmx.net> <200702040952.56905.jkeating@redhat.com> Message-ID: <20070204160600.GB19290@redhat.com> On Sun, Feb 04, 2007 at 09:52:56AM -0500, Jesse Keating wrote: > On Saturday 03 February 2007 18:08, Michael Schwendt wrote: > > BuildArch: noarch > > ExcludeArch: ppc > > > > > > [In comparison, the Extras push script examines the src.rpm for the > > ExcludeArch tag and doesn't push such noarch packages to the excluded > > target repos. That is something that has been said is done for Core, > > too. IIRC, either jkatz or sopwith has said that.] > > I'd really like to start discussion again on stop calling these > things 'noarch' when they aren't 'noarch'. If your package doesn't work on > other arches, it can't be noarch. It either needs to no-op on other arches, > or not be noarch. I'm really tired of having to play games with digging at a > sourcerpm to figure out what arches a package is suitable for, since this > information isn't carried forward in the resultant rpm. We either need to > fix rpm so that this information is carried forward, or just stop calling > these things noarch. Well in the case of 'python-virtinst' the package itself works just fine on ppc, and being pure python noarch is the right thing. We only had to add in the ExcludeArch: ppc stuff because one of the packages it depends on (libvirt) is not available on ppc. I don't see that we should switch the package to be arch dependnant in this case. The build tools should be able to figure out that a dependant package is not available on ppc and automatically skip this python-virtinst, whether its noarch or not. 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 tcallawa at redhat.com Sun Feb 4 16:35:58 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 04 Feb 2007 10:35:58 -0600 Subject: Missing merge review tickets, core->extras dependencies In-Reply-To: <200702041759.11322.ville.skytta@iki.fi> References: <200702041759.11322.ville.skytta@iki.fi> Message-ID: <1170606958.9171.8.camel@localhost.localdomain> On Sun, 2007-02-04 at 17:59 +0200, Ville Skytt? wrote: > A couple of questions regarding merge reviews that I haven't spotted an answer > for anywhere: > > 1) It looks like there are some merge review tickets missing. For example, I > thought I'd take a look at reviewing pcsc-lite and ccid, but couldn't find > tickets for them in Bugzilla. Is this intentional? If yes, is there a list > of those packages somewhere? Were those packages already reviewed? Some of the late entries into core were actually reviewed. > 2) Are Core packages under review allowed to have build and install time > dependencies to packages in Extras nowadays or (still) not? I think yes, since post-merge, there will be no difference. ~spot From ville.skytta at iki.fi Sun Feb 4 16:51:55 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 4 Feb 2007 18:51:55 +0200 Subject: Missing merge review tickets, core->extras dependencies In-Reply-To: <1170606958.9171.8.camel@localhost.localdomain> References: <200702041759.11322.ville.skytta@iki.fi> <1170606958.9171.8.camel@localhost.localdomain> Message-ID: <200702041851.55510.ville.skytta@iki.fi> On Sunday 04 February 2007 18:35, Tom 'spot' Callaway wrote: > On Sun, 2007-02-04 at 17:59 +0200, Ville Skytt? wrote: > > > 1) It looks like there are some merge review tickets missing. For > > example, I thought I'd take a look at reviewing pcsc-lite and ccid, but > > couldn't find tickets for them in Bugzilla. Is this intentional? If > > yes, is there a list of those packages somewhere? > > Were those packages already reviewed? Some of the late entries into core > were actually reviewed. Hm, right, there's a review from May-June 2006, #193187. If someone has a list of the already reviewed cases which aren't participating in the current review, it'd be useful to have it somewhere in public. > > 2) Are Core packages under review allowed to have build and install time > > dependencies to packages in Extras nowadays or (still) not? > > I think yes, since post-merge, there will be no difference. That'd be nice. Does the Core build system have Extras repos configured already now? From Christian.Iseli at licr.org Sun Feb 4 17:14:26 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sun, 4 Feb 2007 18:14:26 +0100 Subject: Missing merge review tickets, core->extras dependencies In-Reply-To: <200702041851.55510.ville.skytta@iki.fi> References: <200702041759.11322.ville.skytta@iki.fi> <1170606958.9171.8.camel@localhost.localdomain> <200702041851.55510.ville.skytta@iki.fi> Message-ID: <20070204181426.55f86fdd@ludwig-alpha.unil.ch> On Sun, 4 Feb 2007 18:51:55 +0200, Ville Skytt? wrote: > If someone has a > list of the already reviewed cases which aren't participating in the current > review, it'd be useful to have it somewhere in public. I put up something here: http://fedoraproject.org/wiki/ChristianIseli/CorePackagesToReview A bit rough (and a bit old) but you might find some answers in there Cheers, C From rc040203 at freenet.de Sun Feb 4 17:51:20 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 04 Feb 2007 18:51:20 +0100 Subject: Broken deps in FC6 Updates In-Reply-To: <20070204162151.6e35be12.bugs.michael@gmx.net> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <200702031759.22970.jkeating@redhat.com> <20070204000833.3a5e86ba.bugs.michael@gmx.net> <200702040952.56905.jkeating@redhat.com> <20070204162151.6e35be12.bugs.michael@gmx.net> Message-ID: <1170611481.2588.622.camel@mccallum.corsepiu.local> On Sun, 2007-02-04 at 16:21 +0100, Michael Schwendt wrote: > On Sun, 4 Feb 2007 09:52:56 -0500, Jesse Keating wrote: > > > On Saturday 03 February 2007 18:08, Michael Schwendt wrote: > > > BuildArch: noarch > > > ExcludeArch: ppc > > > > > > > > > [In comparison, the Extras push script examines the src.rpm for the > > > ExcludeArch tag and doesn't push such noarch packages to the excluded > > > target repos. That is something that has been said is done for Core, > > > too. IIRC, either jkatz or sopwith has said that.] > > > > I'd really like to start discussion again on stop calling these > > things 'noarch' when they aren't 'noarch'. If your package doesn't work on > > other arches, it can't be noarch. It either needs to no-op on other arches, > > or not be noarch. If what you say applies, something is very broken in the buildsystem. 1. Noarch is the architecture a package had been designed for, not the architecture a package actually runs on and doesn't have to imply a package is usable on a certain arch. 2. A noarch package can depend on arch'ed packages, which might not be available for all arches - Nevertheless the package itself is still noarch. Ralf From jkeating at redhat.com Sun Feb 4 18:15:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 4 Feb 2007 13:15:32 -0500 Subject: Broken deps in FC6 Updates In-Reply-To: <1170611481.2588.622.camel@mccallum.corsepiu.local> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <20070204162151.6e35be12.bugs.michael@gmx.net> <1170611481.2588.622.camel@mccallum.corsepiu.local> Message-ID: <200702041315.35205.jkeating@redhat.com> On Sunday 04 February 2007 12:51, Ralf Corsepius wrote: > If what you say applies, something is very broken in the buildsystem. > > 1. Noarch is the architecture a package had been designed for, not the > architecture a package actually runs on and doesn't have to imply a > package is usable on a certain arch. > > 2. A noarch package can depend on arch'ed packages, which might not be > available for all arches - Nevertheless the package itself is still > noarch. RPM does _not_ put this "ExcludeArch" information INTO the .noarch package. It lives in the srpm/spec only. Thus at compose time, we have to track back from a noarch rpm to the srpm that created it, query it and find the Exclude/ExclusiveArch stuff to decide if this 'noarch' package is suitable for this arch collection. -- 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 jpo at di.uminho.pt Sun Feb 4 21:58:21 2007 From: jpo at di.uminho.pt (jpo) Date: Sun, 4 Feb 2007 21:58:21 +0000 Subject: Missing merge review tickets, core->extras dependencies In-Reply-To: <1170606958.9171.8.camel@localhost.localdomain> References: <200702041759.11322.ville.skytta@iki.fi> <1170606958.9171.8.camel@localhost.localdomain> Message-ID: <8DA1DCA0-286C-47D7-A9C8-68C5E9A2EF16@di.uminho.pt> On 2007/02/04, at 16:35, Tom 'spot' Callaway wrote: > On Sun, 2007-02-04 at 17:59 +0200, Ville Skytt? wrote: > >> 2) Are Core packages under review allowed to have build and >> install time >> dependencies to packages in Extras nowadays or (still) not? > > I think yes, since post-merge, there will be no difference. I don't think so. Apparently perl-HTML-Tagset failed to build with an Extras' build requirement (perl-Test-Pod). See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226261 jpo -- Jose Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/members/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3082 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Mon Feb 5 08:28:24 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 05 Feb 2007 09:28:24 +0100 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: <45C6EAA8.7040401@hhs.nl> Christopher Stone wrote: > On 1/30/07, Warren Togami wrote: >> 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. > > Guys, I have to say this constant switching back and forth of ASIGNEE > is not a good idea. Not only is it a pain in the keister to keep on > switching the ASIGNEE back and forth like a tennis ball, but if the > packager forgets to do this, then the reviewer will never get e-mails > on the bug. > I fully agree this new process is a PITA. The old process worked very well, what problems where there with the old process that this new process is trying to fix? And leave the bug open ? WTF? I don't want to have open bugs on my front page for completed package reviews. Unlike others I actually try to keep my open bug count close to 0. This _really_ is a change for the bad. Why o why? Aren't we all engineers, what happened to first defining the problem (I see no problem with the current process), then generating possible solutions and criteria for these (like simpleness, as little actions / mouse clicks as needed) and then match the solutions to the requirements and criteria? THAT clearly didn't happen here! Regards, Hans From bugs.michael at gmx.net Mon Feb 5 11:51:19 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 5 Feb 2007 12:51:19 +0100 Subject: Is owners.list now broken, too? Message-ID: <20070205125119.2539b148.bugs.michael@gmx.net> Is owners.list now broken, too? revision 1.2274 date: 2007/01/22 22:18:40; author: ajax; state: Exp; lines: +1 -1 Claim deltarpm Still, two weeks later, a new bug report (#227326) was assigned to Orphan Owner today. From chitlesh at fedoraproject.org Mon Feb 5 11:55:00 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 5 Feb 2007 12:55:00 +0100 Subject: Is owners.list now broken, too? In-Reply-To: <20070205125119.2539b148.bugs.michael@gmx.net> References: <20070205125119.2539b148.bugs.michael@gmx.net> Message-ID: <13dbfe4f0702050355w3cd3d155h99c17096ce42b93@mail.gmail.com> On 2/5/07, Michael Schwendt wrote: > Is owners.list now broken, too? > > revision 1.2274 > date: 2007/01/22 22:18:40; author: ajax; state: Exp; lines: +1 -1 > Claim deltarpm > > Still, two weeks later, a new bug report (#227326) was assigned to > Orphan Owner today. You should now use http://fedoraproject.org/wiki/Extras/CVSSyncNeeded to assign the owner to a particulat package. Chitlesh -- http://clunixchit.blogspot.com From bugs.michael at gmx.net Mon Feb 5 12:03:32 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 5 Feb 2007 13:03:32 +0100 Subject: Is owners.list now broken, too? In-Reply-To: <13dbfe4f0702050355w3cd3d155h99c17096ce42b93@mail.gmail.com> References: <20070205125119.2539b148.bugs.michael@gmx.net> <13dbfe4f0702050355w3cd3d155h99c17096ce42b93@mail.gmail.com> Message-ID: <20070205130332.9059c76d.bugs.michael@gmx.net> On Mon, 5 Feb 2007 12:55:00 +0100, Chitlesh GOORAH wrote: > On 2/5/07, Michael Schwendt wrote: > > Is owners.list now broken, too? > > > > revision 1.2274 > > date: 2007/01/22 22:18:40; author: ajax; state: Exp; lines: +1 -1 > > Claim deltarpm > > > > Still, two weeks later, a new bug report (#227326) was assigned to > > Orphan Owner today. > > You should now use > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded > to assign the owner to a particulat package. Please re-read my message. I refer to Jan 22nd, not "now". Plus: $ grep deltarpm owners.list|sed -s 's|@|[AT]|g' Fedora Extras|deltarpm|Create deltas between rpms|ajackson[AT]redhat.com|extras-qa[AT]fedoraproject.org| From tcallawa at redhat.com Mon Feb 5 13:33:37 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 05 Feb 2007 07:33:37 -0600 Subject: Missing merge review tickets, core->extras dependencies In-Reply-To: <8DA1DCA0-286C-47D7-A9C8-68C5E9A2EF16@di.uminho.pt> References: <200702041759.11322.ville.skytta@iki.fi> <1170606958.9171.8.camel@localhost.localdomain> <8DA1DCA0-286C-47D7-A9C8-68C5E9A2EF16@di.uminho.pt> Message-ID: <1170682417.9066.8.camel@localhost.localdomain> On Sun, 2007-02-04 at 21:58 +0000, jpo wrote: > > On 2007/02/04, at 16:35, Tom 'spot' Callaway wrote: > > > On Sun, 2007-02-04 at 17:59 +0200, Ville Skytt? wrote: > > > > > > > 2) Are Core packages under review allowed to have build and > > > install time > > > dependencies to packages in Extras nowadays or (still) not? > > > > > > I think yes, since post-merge, there will be no difference. > > > I don't think so. Apparently perl-HTML-Tagset failed to build with an > Extras' > build requirement (perl-Test-Pod). > > > See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226261 We're not merged yet. :) ~spot From rdieter at math.unl.edu Mon Feb 5 13:48:50 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Feb 2007 07:48:50 -0600 Subject: Missing merge review tickets, core->extras dependencies In-Reply-To: <1170682417.9066.8.camel@localhost.localdomain> References: <200702041759.11322.ville.skytta@iki.fi> <1170606958.9171.8.camel@localhost.localdomain> <8DA1DCA0-286C-47D7-A9C8-68C5E9A2EF16@di.uminho.pt> <1170682417.9066.8.camel@localhost.localdomain> Message-ID: <45C735C2.3000600@math.unl.edu> Tom 'spot' Callaway wrote: > On Sun, 2007-02-04 at 21:58 +0000, jpo wrote: >> On 2007/02/04, at 16:35, Tom 'spot' Callaway wrote: >> >>> On Sun, 2007-02-04 at 17:59 +0200, Ville Skytt? wrote: >>> >>> >>>> 2) Are Core packages under review allowed to have build and >>>> install time >>>> dependencies to packages in Extras nowadays or (still) not? >>> >>> I think yes, since post-merge, there will be no difference. >> >> I don't think so. Apparently perl-HTML-Tagset failed to build with an >> Extras' >> build requirement (perl-Test-Pod). >> >> >> See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226261 > > We're not merged yet. :) Arg, stupid question, what if say, someone were wanting to Review some previously Core package, that now would want/need new Extras' dependencies? OK, review wouldn't be much of a problem (reviewers likely could figure that out), but building after-the-fact would be. (?) Any hints/timetable when/if this can be fixed/resolved? I realize this is kind of a chicken-and-egg problem, but it's an important one. -- Rex From mclasen at redhat.com Mon Feb 5 14:03:09 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 05 Feb 2007 09:03:09 -0500 Subject: Missing merge review tickets, core->extras dependencies In-Reply-To: <45C735C2.3000600@math.unl.edu> References: <200702041759.11322.ville.skytta@iki.fi> <1170606958.9171.8.camel@localhost.localdomain> <8DA1DCA0-286C-47D7-A9C8-68C5E9A2EF16@di.uminho.pt> <1170682417.9066.8.camel@localhost.localdomain> <45C735C2.3000600@math.unl.edu> Message-ID: <1170684190.9637.33.camel@golem.boston.devel.redhat.com> On Mon, 2007-02-05 at 07:48 -0600, Rex Dieter wrote: > Tom 'spot' Callaway wrote: > > On Sun, 2007-02-04 at 21:58 +0000, jpo wrote: > >> On 2007/02/04, at 16:35, Tom 'spot' Callaway wrote: > >> > >>> On Sun, 2007-02-04 at 17:59 +0200, Ville Skytt? wrote: > >>> > >>> > >>>> 2) Are Core packages under review allowed to have build and > >>>> install time > >>>> dependencies to packages in Extras nowadays or (still) not? > >>> > >>> I think yes, since post-merge, there will be no difference. > >> > >> I don't think so. Apparently perl-HTML-Tagset failed to build with an > >> Extras' > >> build requirement (perl-Test-Pod). > >> > >> > >> See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226261 > > > > We're not merged yet. :) > > Arg, stupid question, what if say, someone were wanting to Review some > previously Core package, that now would want/need new Extras' dependencies? > OK, review wouldn't be much of a problem (reviewers likely could figure > that out), but building after-the-fact would be. (?) > > Any hints/timetable when/if this can be fixed/resolved? I realize this is > kind of a chicken-and-egg problem, but it's an important one. Well, review is all about existing packages, not about possible future changes. I don't think it is a good idea to mix the two. From rdieter at math.unl.edu Mon Feb 5 14:00:10 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Feb 2007 08:00:10 -0600 Subject: Missing merge review tickets, core->extras dependencies In-Reply-To: <1170684190.9637.33.camel@golem.boston.devel.redhat.com> References: <200702041759.11322.ville.skytta@iki.fi> <1170606958.9171.8.camel@localhost.localdomain> <8DA1DCA0-286C-47D7-A9C8-68C5E9A2EF16@di.uminho.pt> <1170682417.9066.8.camel@localhost.localdomain> <45C735C2.3000600@math.unl.edu> <1170684190.9637.33.camel@golem.boston.devel.redhat.com> Message-ID: <45C7386A.8000506@math.unl.edu> Matthias Clasen wrote: > On Mon, 2007-02-05 at 07:48 -0600, Rex Dieter wrote: >> Arg, stupid question, what if say, someone were wanting to Review some >> previously Core package, that now would want/need new Extras' dependencies? >> OK, review wouldn't be much of a problem (reviewers likely could figure >> that out), but building after-the-fact would be. (?) >> >> Any hints/timetable when/if this can be fixed/resolved? I realize this is >> kind of a chicken-and-egg problem, but it's an important one. > > Well, review is all about existing packages, not about possible future > changes. I don't think it is a good idea to mix the two. That may well be in the vast majority of cases, but I do plan on adding at least a few functionality/features to KDE that require access-to/use-of (existing) Extras packages. Imo, I would much rather see these additions and modifications get reviewed for feedback. -- Rex From michel.salim at gmail.com Sun Feb 4 01:35:10 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 3 Feb 2007 20:35:10 -0500 Subject: Impending FLAC update warning: rebuilds required Message-ID: <883cfe6d0702031735m5f043a59ja1e3b5c8089d98ff@mail.gmail.com> Hi all, FLAC 1.1.3 has been out for a while, and due to API changes a lot of ex-Extras packages are affected. Matthias Clasen has all the required patches prepared, but suggested warning this list first and letting package maintainers know. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222946 This is the current list of affected packages: akode audacious-plugins audacity easytag flac123 gstreamer08-plugins gstreamer-plugins-good k3b kdemultimedia kid3 libtunepimp mkvtoolnix muine scummvm stratagus xine-lib xmms-flac If your package is on this list, and the new FLAC does not work with you without further workaround, please follow-up at the Bugzilla entry. I'll ask Matthias if he can provide a test SRPM. Regards, -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From katzj at redhat.com Mon Feb 5 17:49:14 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 05 Feb 2007 12:49:14 -0500 Subject: Is owners.list->bugzilla ownership now broken, too? In-Reply-To: <20070205125119.2539b148.bugs.michael@gmx.net> References: <20070205125119.2539b148.bugs.michael@gmx.net> Message-ID: <1170697754.5207.10.camel@aglarond.local> On Mon, 2007-02-05 at 12:51 +0100, Michael Schwendt wrote: > Is owners.list now broken, too? [snip] > Still, two weeks later, a new bug report (#227326) was assigned to > Orphan Owner today. Hrmm... I thought the script was running fine. But looking at cron logs on the box, it looks like cron fell over at some point. Kicked it and I'll keep a closer eye on it for a bit Jeremy From ville.skytta at iki.fi Mon Feb 5 18:48:53 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 5 Feb 2007 20:48:53 +0200 Subject: Is owners.list->bugzilla ownership now broken, too? In-Reply-To: <1170697754.5207.10.camel@aglarond.local> References: <20070205125119.2539b148.bugs.michael@gmx.net> <1170697754.5207.10.camel@aglarond.local> Message-ID: <200702052048.53428.ville.skytta@iki.fi> On Monday 05 February 2007 19:49, Jeremy Katz wrote: > On Mon, 2007-02-05 at 12:51 +0100, Michael Schwendt wrote: > > Is owners.list now broken, too? > > [snip] > > > Still, two weeks later, a new bug report (#227326) was assigned to > > Orphan Owner today. > > Hrmm... I thought the script was running fine. But looking at cron logs > on the box, it looks like cron fell over at some point. Kicked it and > I'll keep a closer eye on it for a bit Still happened with bug #227380 a couple of minutes ago. From dominik at greysector.net Mon Feb 5 19:03:52 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 5 Feb 2007 20:03:52 +0100 Subject: Impending FLAC update warning: rebuilds required In-Reply-To: <883cfe6d0702031735m5f043a59ja1e3b5c8089d98ff@mail.gmail.com> References: <883cfe6d0702031735m5f043a59ja1e3b5c8089d98ff@mail.gmail.com> Message-ID: <20070205190352.GA18421@ryvius.pekin.waw.pl> Hi, On Sunday, 04 February 2007 at 02:35, Michel Salim wrote: > Hi all, > > FLAC 1.1.3 has been out for a while, and due to API changes a lot of > ex-Extras packages are affected. Matthias Clasen has all the required > patches prepared, but suggested warning this list first and letting > package maintainers know. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222946 > > This is the current list of affected packages: > > akode > audacious-plugins > audacity > easytag > flac123 > gstreamer08-plugins > gstreamer-plugins-good > k3b > kdemultimedia > kid3 > libtunepimp > mkvtoolnix That one is mine. > muine > scummvm > stratagus > xine-lib > xmms-flac > > If your package is on this list, and the new FLAC does not work with > you without further workaround, please follow-up at the Bugzilla > entry. I'll ask Matthias if he can provide a test SRPM. Do you have an updated flac spec somewhere? Thanks for the notice. 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 wtogami at redhat.com Mon Feb 5 19:29:16 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 05 Feb 2007 14:29:16 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> Message-ID: <45C7858C.8030907@redhat.com> Christopher Stone wrote: > On 2/3/07, Kevin Fenzi wrote: >> I kind of like the moving of assigned. It shows who next needs to take >> action. Of course something like NEEDINFO (emailaddress) might work as >> well. > > I don't. It's an extra step that most people will forget to do. I'm > just not going to bother, I'm going to assign it to me (the reviewer) > and be done with it. Plus, was there *ever* any confusion before this > change as to who next needs to take action?? I simply do not see any > extra benefit from all this extra work. Yes, there is confusion about who needs to take action, because the filer of the Mass Review tickets was not the owner. > > We are supposed to be making things *easier*, not more difficult. > Another case is all these extras steps, now not only do we have to > rely on someone to make cvs branches, we also have to rely on someone > to add entries to owners.list, next it will be comps, The current process sucks because the implementation is not complete. Toshio and Notting during the weekend were discussing how to better automate this process. Meanwhile, I'm trying to sort out exactly the status of this. I suspect the type of automation they want is too far off, so I am thinking about how simplify the interim process in the mean time. (Waiting for notting to get back, I have to discuss this with him.) > then we will > have to get permissions just to edit our own packages! I have to call bullshit on this assertion. The owner always has access to their own package, and may grant access of their package to anyone else, or everyone. Warren Togami wtogami at redhat.com From limb at jcomserv.net Mon Feb 5 20:27:34 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 5 Feb 2007 14:27:34 -0600 (CST) Subject: [Fwd: Fedora Core 6 Update: thunderbird-1.5.0.9-7.fc6] Message-ID: <21543.65.192.24.190.1170707254.squirrel@mail.jcomserv.net> I can't seem to pull this update from any yum repo, including my own which is mirrored from an upstream repo. I seem to be able to get all the other recent updates, but not this one. Is there a repo metadata issue? I've verified this across multiple machines and repos, all with thunderbird 1.5.0.9-2 installed. I could install manually, but if there's a larger problem, I'd like it brought to light. So far, this is the only package I've noticed this with. Thanks, Jon ---------------------------- Original Message ---------------------------- Subject: Fedora Core 6 Update: thunderbird-1.5.0.9-7.fc6 From: "Christopher Aillon" Date: Sat, February 3, 2007 11:24 pm To: fedora-package-announce at redhat.com -------------------------------------------------------------------------- --------------------------------------------------------------------- Fedora Update Notification FEDORA-2007-188 2007-02-04 --------------------------------------------------------------------- Product : Fedora Core 6 Name : thunderbird Version : 1.5.0.9 Release : 7.fc6 Summary : Mozilla Thunderbird mail/newsgroup client Description : Mozilla Thunderbird is a standalone mail and newsgroup client. --------------------------------------------------------------------- * Tue Jan 30 2007 Christopher Aillon 1.5.0.9-7 - Updated cursor position patch from tagoh to fix issue with "jumping" cursor when in a textfield with tabs. * Tue Jan 30 2007 Christopher Aillon 1.5.0.9-6 - Fix the DND implementation to not grab, so it works with new GTK+. * Thu Dec 21 2006 Behdad Esfahbod 1.5.0.9-5 - Added firefox-1.5-pango-underline.patch * Wed Dec 20 2006 Behdad Esfahbod 1.5.0.9-4 - Added firefox-1.5-pango-justified-range.patch --------------------------------------------------------------------- This update can be downloaded from: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6/ 2b54930ddf8b42a25d6e635e7b9394d4bffe7da9 SRPMS/thunderbird-1.5.0.9-7.fc6.src.rpm 2b54930ddf8b42a25d6e635e7b9394d4bffe7da9 noarch/thunderbird-1.5.0.9-7.fc6.src.rpm ee95656a5d3ce5e70b6031921155806068148c32 ppc/thunderbird-1.5.0.9-7.fc6.ppc.rpm bc0c99606a515fd0dfd74e42e005397b6b9fe774 ppc/debug/thunderbird-debuginfo-1.5.0.9-7.fc6.ppc.rpm b33447af389232049e17e5a1bd6fb7e01e569a41 x86_64/debug/thunderbird-debuginfo-1.5.0.9-7.fc6.x86_64.rpm 20f15d87adefa5ad62a04c599adb004b466f9642 x86_64/thunderbird-1.5.0.9-7.fc6.x86_64.rpm 678ed66f67343ddb37e44eb8ce956c805f8ca279 i386/debug/thunderbird-debuginfo-1.5.0.9-7.fc6.i386.rpm 6af794b2d7f40988c65563dbcbff23a1afa5c199 i386/thunderbird-1.5.0.9-7.fc6.i386.rpm This update can be installed with the 'yum' update program. Use 'yum update package-name' at the command line. For more information, refer to 'Managing Software with yum,' available at http://fedora.redhat.com/docs/yum/. --------------------------------------------------------------------- _______________________________________________ Fedora-package-announce mailing list Fedora-package-announce at redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-announce -- novus ordo absurdum From caillon at redhat.com Mon Feb 5 20:41:55 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 05 Feb 2007 15:41:55 -0500 Subject: Missing merge review tickets, core->extras dependencies In-Reply-To: <45C7386A.8000506@math.unl.edu> References: <200702041759.11322.ville.skytta@iki.fi> <1170606958.9171.8.camel@localhost.localdomain> <8DA1DCA0-286C-47D7-A9C8-68C5E9A2EF16@di.uminho.pt> <1170682417.9066.8.camel@localhost.localdomain> <45C735C2.3000600@math.unl.edu> <1170684190.9637.33.camel@golem.boston.devel.redhat.com> <45C7386A.8000506@math.unl.edu> Message-ID: <45C79693.1060002@redhat.com> Rex Dieter wrote: > Matthias Clasen wrote: >> Well, review is all about existing packages, not about possible future >> changes. I don't think it is a good idea to mix the two. > > That may well be in the vast majority of cases, but I do plan on adding > at least a few functionality/features to KDE that require > access-to/use-of (existing) Extras packages. Imo, I would much rather > see these additions and modifications get reviewed for feedback. Is there anything stopping you from asking for review on them, post facto? From notting at redhat.com Mon Feb 5 20:45:59 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 Feb 2007 15:45:59 -0500 Subject: Missing merge review tickets, core->extras dependencies In-Reply-To: <200702041851.55510.ville.skytta@iki.fi> References: <200702041759.11322.ville.skytta@iki.fi> <1170606958.9171.8.camel@localhost.localdomain> <200702041851.55510.ville.skytta@iki.fi> Message-ID: <20070205204559.GF4858@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > > > 2) Are Core packages under review allowed to have build and install time > > > dependencies to packages in Extras nowadays or (still) not? > > > > I think yes, since post-merge, there will be no difference. > > That'd be nice. Does the Core build system have Extras repos configured > already now? No. Bill From notting at redhat.com Mon Feb 5 21:32:36 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 Feb 2007 16:32:36 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070204112051.612bcbeb.bugs.michael@gmx.net> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> Message-ID: <20070205213236.GI4858@nostromo.devel.redhat.com> Not commenting on the review process, I haven't reviewed (ugh) it. Michael Schwendt (bugs.michael at gmx.net) said: > The locked down owners.list makes it impossible to fix typos in it. Is this *really* a problem? Considering I fixed a typo that was there for over 30 days with it open, not sure that it's the biggest concern. Obviously, 'don't break it' is the answer; the best solution is to get the package db up and running. > Resurrecting dead packages has become more > difficult, too, especially for new contributors. Too many steps and > points of failure that can easily become an unpleasant experience for the > new contributors. What's the failure point here now? As for the import process, we can change how that works - instead of CVSSyncNeeded, for example, we could just, after APPROVED, assign the review bug to the CVS admins to do the magic, at which point they assign it back to the owner to do the initial import/build. Is this a better interface for users? Bill From wtogami at redhat.com Mon Feb 5 22:45:54 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 05 Feb 2007 17:45:54 -0500 Subject: Theoretical: CVS Admin with Flags In-Reply-To: <20070205213236.GI4858@nostromo.devel.redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> Message-ID: <45C7B3A2.3070306@redhat.com> Bill Nottingham wrote: > > What's the failure point here now? > > As for the import process, we can change how that works - instead > of CVSSyncNeeded, for example, we could just, after APPROVED, assign > the review bug to the CVS admins to do the magic, at which point they > assign it back to the owner to do the initial import/build. Is this > a better interface for users? > Folks seem to be confused by the ASSIGNED bouncing around. I am currently thinking about potential ways to improve the review process to remove this confusion. A big legitimate problem with changing ASSIGNED is that it must be done manually, which is too easy to not happen because it is not obvious. http://fedoraproject.org/wiki/Extras/CVSSyncNeeded I made some changes to this page in an attempt to simplify this temporary process until we have the PackageDB online. Unfortunately, I suspect even this simplified process is too complicated. 1. Request new package and branch. 2. Wait until somebody creates empty directories and edits owners.list. 3. Owner checks stuff in and builds. Perhaps a better idea than setting ASSIGNED to the CVS admins is to have a fedora-cvs flag? Theoretical process: 1) Review is complete, fedora-review+ 2) Owner writes in the Bugzilla comment something like: FC-5 FC-6 foopackage bobjoe bobjoebugzilla at gmail.com 3) Set fedora-cvs flag 4) CVS Admins get e-mail about fedora-cvs flag. All context of the review is within the bug itself. Admin creates CVS directories and sets owner. Removes fedora-cvs flag. (This is especially nice because CVS admin queue can be seen by a bugzilla query.) 5) Owner checks in and builds. Effectively, this fedora-cvs flag eliminates the need for CVSSyncNeeded entirely. You could also use the fedora-cvs flag with explicitly instructions within any bug to do special requests, like: "Please remove audacious-itouch. We made some mistake. Blah blah." Thoughts? This does not yet fix the review process yet (I'm working on that next), but should make things smoother and easier in the CVS processing for both contributors and admins. Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Mon Feb 5 22:50:41 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 5 Feb 2007 23:50:41 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070205213236.GI4858@nostromo.devel.redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> Message-ID: <20070205235041.d082c497.bugs.michael@gmx.net> On Mon, 5 Feb 2007 16:32:36 -0500, Bill Nottingham wrote: > > The locked down owners.list makes it impossible to fix typos in it. > > Is this *really* a problem? Considering I fixed a typo that was there > for over 30 days with it open, not sure that it's the biggest concern. > Obviously, 'don't break it' is the answer; the best solution is to > get the package db up and running. Some of us [including me] have fixed tons of typos which broke available parsers. Now that it's locked, "don't break it" sounds like a nice rule of thumb, but considering how often other locked things have been damaged nevertheless (e.g. CVSROOT/modules) and required a fix, I prefer it when more people can keep things running with a lower turn-around time rather than only a very few. > > Resurrecting dead packages has become more > > difficult, too, especially for new contributors. Too many steps and > > points of failure that can easily become an unpleasant experience for the > > new contributors. > > What's the failure point here now? Packages marked as "dead.package" lack the "Makefile", which breaks cvs-import.sh. There is a patch by me (posted to fesco in June last year) which I've resent a few days ago, because it has not been applied so far. > As for the import process, we can change how that works - instead > of CVSSyncNeeded, for example, we could just, after APPROVED, assign > the review bug to the CVS admins to do the magic, at which point they > assign it back to the owner to do the initial import/build. Is this > a better interface for users? Urks. Even more reassignments inside bugzilla? That is error-prone. The Wiki is also a very poor solution for such requests, because in it you cannot communicate with the requester. Why is it that the ticketing system is not used for such requests? From mr.ecik at gmail.com Mon Feb 5 22:53:12 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Mon, 5 Feb 2007 23:53:12 +0100 Subject: Theoretical: CVS Admin with Flags In-Reply-To: <45C7B3A2.3070306@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45C7B3A2.3070306@redhat.com> Message-ID: <668bb39a0702051453y5491d07fp978ecd1223192634@mail.gmail.com> 2007/2/5, Warren Togami : > > FC-5 FC-6 foopackage bobjoe bobjoebugzilla at gmail.com Don't you mean FC-5 FC-6 foopackage bobjoe 123456? Why BugName, not e.g. BugId? > 3) Set fedora-cvs flag Where it can be set? -- Micha? Bentkowski mr.ecik at gmail.com From wtogami at redhat.com Mon Feb 5 23:41:23 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 05 Feb 2007 18:41:23 -0500 Subject: RFC: Review with Flags (Version 3) Message-ID: <45C7C0A3.3010808@redhat.com> Raw notes... your comments would be very much appreciated. Key Changes from Previous Procedures ==================================== 1) Assigned to pointer indicates that there is a reviewer. Assigned pointer to nobody means there is no reviewer yet. 2) BLANK means review not requested. ? means review requested. This makes it easier to query, because querying for BLANK is a bit inefficient. (Good idea, bad idea?) 3) NEEDINFO is used to avoid changing the Assigned pointer when fixes are needed. 4) Assigned pointer DOES NOT CHANGE during and after the review. Fedora Review Flag States ========================= fedora-review BLANK (Not under review at all!) fedora-review? (I want a review) fedora-review- (rejected, needs work, set NEEDINFO to person who needs to fix it) fedora-review+ (APPROVED) Assigned Pointer ================ (Note, Assigned pointer is different from the ASSIGNED state.) - Assigned pointer to nobody at fedoraproject.org if no reviewer yet. - Assigned pointer to reviewer, during and after review. - Set Assigned pointer back to nobody if reviewer gave up. Bugzilla States =============== NEW ASSIGNED REOPENED (rather meaningless distinction?) NEEDINFO (to owner or somebody who needs to act to fix) MODIFIED (seems to be fixed, please test it) CLOSED (ticket is done) Process ======= 1. Review Request is filed. 2. Set fedora-review? flag to signify that the ticket is ready for review. 3. Reviewer takes bug, Assigned pointer set to self. 4. If APPROVED, fedora-review+. 5. If rejected, fedora-review- and NEEDINFO owner to fix it. 6. If fedora-review- and owner fixes something, set back to ? to request review again. 7. After fedora-review+, initiate the fedora-cvs request procedure. 8. After fedora-cvs, checkin, build, and set to CLOSED. Drawbacks ========= Since the mass review tickets were not filed by the package owners, it is less than obvious. Most reviews however are filed by owners, so this is less of a problem beyond this mass review. Other Possibilities =================== fedora-review? could also be used on any other Fedora bug when a horrible mess is found in an existing package, and attention for a re-review would be desired to fix it. (Good idea, bad idea?) Possible Process Optimizations ============================== (These might possibly help... although they might require hacks in Bugzilla's code, so we only request these optimizations only if they would make a huge positive difference. Your thoughts?) 1. Changing fedora-review in any way should auto-CC yourself automatically. 2. Changing fedora-review to + should auto-set Assigned pointer to self. Your feedback is needed! Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Feb 5 23:55:24 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 05 Feb 2007 18:55:24 -0500 Subject: RFC: CVS Admin with Flags (Version 1) In-Reply-To: <20070205213236.GI4858@nostromo.devel.redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> Message-ID: <45C7C3EC.1010300@redhat.com> Your comments would be very much appreciated. Current Crappy CVSSyncNeeded Wiki Procedure =========================================== http://fedoraproject.org/wiki/Extras/CVSSyncNeeded 1. Request new package and branch. 2. Wait until somebody creates empty directories and edits owners.list. 3. Owner checks stuff in and builds. Using the Wiki for this process has always sucked. We could embed this process within the Bugzilla review tickets themselves. Proposal: CVS Admin with Flags ============================== 1) Review is complete, fedora-review+ 2) Owner writes in the Bugzilla comment something like: FC-5 FC-6 foopackage bobjoe bobjoebugzilla at gmail.com 3) Set fedora-cvs flag to ? 4) CVS Admins get e-mail about fedora-cvs flag. All context of the review is within the bug itself, so they can easily read all details about the package and verify approval validity. The Admin then creates CVS directories and sets owner. Sets fedora-cvs flag to BLANK. 5) Owner checks in and builds. Benefits ======== - This fedora-cvs flag eliminates the need for CVSSyncNeeded entirely. An actual work queue with tickets! - fedora-cvs can be a simple canned query for CVS admins to see. Awesome possibilities offered via RSS too... =) - You could also use the fedora-cvs flag with explicit instructions within any bug to do special requests, like: "Please remove audacious-itouch. We made some mistake. Blah blah." Notes ===== - Unlike other flags, fedora-cvs is only BLANK or ?. fedorabugs members may request fedora-cvs by setting it to ?. This sends an e-mail to CVS Admins, signifying that attention is required. Warren Togami wtogami at redhat.com From dominik at greysector.net Tue Feb 6 00:23:23 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 6 Feb 2007 01:23:23 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070205213236.GI4858@nostromo.devel.redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> Message-ID: <20070206002323.GG21605@ryvius.pekin.waw.pl> On Monday, 05 February 2007 at 22:32, Bill Nottingham wrote: > Not commenting on the review process, I haven't reviewed (ugh) it. > > Michael Schwendt (bugs.michael at gmx.net) said: > > The locked down owners.list makes it impossible to fix typos in it. > > Is this *really* a problem? Considering I fixed a typo that was there > for over 30 days with it open, not sure that it's the biggest concern. > Obviously, 'don't break it' is the answer; the best solution is to > get the package db up and running. > > > Resurrecting dead packages has become more > > difficult, too, especially for new contributors. Too many steps and > > points of failure that can easily become an unpleasant experience for the > > new contributors. > > What's the failure point here now? > > As for the import process, we can change how that works - instead > of CVSSyncNeeded, for example, we could just, after APPROVED, assign > the review bug to the CVS admins to do the magic, at which point they > assign it back to the owner to do the initial import/build. Is this > a better interface for users? No. It adds a hurdle that wasn't there before. Personally, I'm probably going to postpone importing any packages I have queued up until this is changed back. What was so wrong with anyone in cvsextras group being able to modify owners.list that you had to change it? And changing assignment of the review bug is not good either. Too easy to forget. Look how often people forget to change bug state during review or close it afterwards. This, along with the new ACL policy is beginning to seriously annoy me. Please stop adding hoops for contributors to jump through. 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 dominik at greysector.net Tue Feb 6 00:27:15 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 6 Feb 2007 01:27:15 +0100 Subject: Theoretical: CVS Admin with Flags In-Reply-To: <45C7B3A2.3070306@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45C7B3A2.3070306@redhat.com> Message-ID: <20070206002715.GH21605@ryvius.pekin.waw.pl> On Monday, 05 February 2007 at 23:45, Warren Togami wrote: > Bill Nottingham wrote: > > > >What's the failure point here now? > > > >As for the import process, we can change how that works - instead > >of CVSSyncNeeded, for example, we could just, after APPROVED, assign > >the review bug to the CVS admins to do the magic, at which point they > >assign it back to the owner to do the initial import/build. Is this > >a better interface for users? > > > > Folks seem to be confused by the ASSIGNED bouncing around. I am > currently thinking about potential ways to improve the review process to > remove this confusion. A big legitimate problem with changing ASSIGNED > is that it must be done manually, which is too easy to not happen > because it is not obvious. My point exactly. > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded > I made some changes to this page in an attempt to simplify this > temporary process until we have the PackageDB online. Unfortunately, I > suspect even this simplified process is too complicated. > 1. Request new package and branch. > 2. Wait until somebody creates empty directories and edits owners.list. > 3. Owner checks stuff in and builds. > > Perhaps a better idea than setting ASSIGNED to the CVS admins is to have > a fedora-cvs flag? Theoretical process: > > 1) Review is complete, fedora-review+ > 2) Owner writes in the Bugzilla comment something like: > > FC-5 FC-6 foopackage bobjoe bobjoebugzilla at gmail.com > 3) Set fedora-cvs flag > 4) CVS Admins get e-mail about fedora-cvs flag. All context of the > review is within the bug itself. Admin creates CVS directories and sets > owner. Removes fedora-cvs flag. (This is especially nice because CVS > admin queue can be seen by a bugzilla query.) > 5) Owner checks in and builds. > > Effectively, this fedora-cvs flag eliminates the need for CVSSyncNeeded > entirely. You could also use the fedora-cvs flag with explicitly > instructions within any bug to do special requests, like: > "Please remove audacious-itouch. We made some mistake. Blah blah." > > Thoughts? Remove 2-4 and we're back to where we were. Why can't things stay that way? > This does not yet fix the review process yet (I'm working on that next), > but should make things smoother and easier in the CVS processing for > both contributors and admins. Please make it so that contributors have less things to worry about, not more. Otherwise this is going to scare people away. It's already discouraging to me. 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 jkeating at redhat.com Tue Feb 6 00:45:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Feb 2007 19:45:21 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070205235041.d082c497.bugs.michael@gmx.net> References: <45BE7342.1070005@redhat.com> <20070205213236.GI4858@nostromo.devel.redhat.com> <20070205235041.d082c497.bugs.michael@gmx.net> Message-ID: <200702051945.21824.jkeating@redhat.com> On Monday 05 February 2007 17:50, Michael Schwendt wrote: > Urks. Even more reassignments inside bugzilla? That is error-prone. The > Wiki is also a very poor solution for such requests, because in it you > cannot communicate with the requester. Why is it that the ticketing system > is not used for such requests? Probably because our ticketing system is ass. -- 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 tibbs at math.uh.edu Tue Feb 6 01:28:49 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Feb 2007 19:28:49 -0600 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C6EAA8.7040401@hhs.nl> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C6EAA8.7040401@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> I fully agree this new process is a PITA. The old process worked HdG> very well, what problems where there with the old process that HdG> this new process is trying to fix? The fact that bugzilla creaks, groans and ultimately dies when faced with a blocker bug having 1500 dependencies. The previous system just doesn't scale to all of the core review stuff. Now, we could just treat the core review as an anomaly and go back to the old system for old reviews. Or we could move forward with a refinement of the new process that works better. Either way is fine with me as long as it works. What's annoying is that people whining because something has changed. We've tried something new because we needed to. The whole thing is a work in progress. Deal. If we never try anything new, we'll never do worse but we also won't ever do any better. - J< From michel.salim at gmail.com Tue Feb 6 01:58:18 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 5 Feb 2007 20:58:18 -0500 Subject: Impending FLAC update warning: rebuilds required In-Reply-To: <20070205190352.GA18421@ryvius.pekin.waw.pl> References: <883cfe6d0702031735m5f043a59ja1e3b5c8089d98ff@mail.gmail.com> <20070205190352.GA18421@ryvius.pekin.waw.pl> Message-ID: <883cfe6d0702051758i60833642oaecd4207e5ca3525@mail.gmail.com> 2007/2/5, Dominik 'Rathann' Mierzejewski : > > mkvtoolnix > > That one is mine. > > > muine > > scummvm > > stratagus > > xine-lib > > xmms-flac > > > > If your package is on this list, and the new FLAC does not work with > > you without further workaround, please follow-up at the Bugzilla > > entry. I'll ask Matthias if he can provide a test SRPM. > > Do you have an updated flac spec somewhere? > Matthias has put them up (URL is also at the Bugzilla entry): http://people.redhat.com/mclasen/flac/ Regards, -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From tibbs at math.uh.edu Tue Feb 6 02:13:27 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Feb 2007 20:13:27 -0600 Subject: Broken deps in FC6 Updates In-Reply-To: <20070204162151.6e35be12.bugs.michael@gmx.net> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <200702031759.22970.jkeating@redhat.com> <20070204000833.3a5e86ba.bugs.michael@gmx.net> <200702040952.56905.jkeating@redhat.com> <20070204162151.6e35be12.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> When we faced this topic in Extras and FESCo, nobody showed any MS> interest in it. Actually the packaging committee had some significant discussions about it. I recall that I was against changing the meaning of noarch. I'm always willing to reevaluate my positions on such things if new arguments are available. - J< From bpepple at fedoraproject.org Tue Feb 6 01:43:51 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 05 Feb 2007 20:43:51 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C6EAA8.7040401@hhs.nl> Message-ID: <1170726231.28720.0.camel@Chuck> On Mon, 2007-02-05 at 19:28 -0600, Jason L Tibbitts III wrote: > >>>>> "HdG" == Hans de Goede writes: > > HdG> I fully agree this new process is a PITA. The old process worked > HdG> very well, what problems where there with the old process that > HdG> this new process is trying to fix? > > The fact that bugzilla creaks, groans and ultimately dies when faced > with a blocker bug having 1500 dependencies. The previous system just > doesn't scale to all of the core review stuff. > > Now, we could just treat the core review as an anomaly and go back to > the old system for old reviews. Or we could move forward with a > refinement of the new process that works better. Either way is fine > with me as long as it works. > > What's annoying is that people whining because something has changed. > We've tried something new because we needed to. The whole thing is a > work in progress. Deal. If we never try anything new, we'll never do > worse but we also won't ever do any better. +1 /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 tibbs at math.uh.edu Tue Feb 6 02:20:06 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Feb 2007 20:20:06 -0600 Subject: disclaimed ownership of core packages In-Reply-To: <20070202161419.20a3bdd5@ludwig-alpha.unil.ch> References: <20070202161419.20a3bdd5@ludwig-alpha.unil.ch> Message-ID: >>>>> "CI" == Christian Iseli writes: CI> Hi folks, It seems there are a few cases of disclaimed ownership CI> of core packages, e.g.: https://bugzilla.redhat.com/226558 Hmm, no replies to this and I didn't see the question raised during fudcon. I think there shouldn't be any question that such packages should be kept out of F7 until they find maintainers. If there's nobody to review the package, perhaps as we get closer to release without seeing a maintainer for those bugs, we should just close them and block something analogous to FE-DEADREVIEW that doesn't actually exist. Perhaps FE-DEADREVIEW can be overloaded for this. - J< From kevin at tummy.com Tue Feb 6 02:25:35 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 5 Feb 2007 19:25:35 -0700 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <45C7C0A3.3010808@redhat.com> References: <45C7C0A3.3010808@redhat.com> Message-ID: <20070205192535.63487057@ningauble.scrye.com> On Mon, 05 Feb 2007 18:41:23 -0500 wtogami at redhat.com (Warren Togami) wrote: > Raw notes... your comments would be very much appreciated. Just up front, I think one important thing we should do in any review procedure is to push as much of the processing and dealing with bugzilla off on the reviewer, and make it easy for the submitter to just deal with getting their package up to meeting guidelines and getting approved. It's much more likely the reviewer will know the process, where the submitter won't, so we need to make it easy for them to see what to do. > Key Changes from Previous Procedures > ==================================== > 1) Assigned to pointer indicates that there is a reviewer. Assigned > pointer to nobody means there is no reviewer yet. > 2) BLANK means review not requested. ? means review requested. This > makes it easier to query, because querying for BLANK is a bit > inefficient. (Good idea, bad idea?) If it requires the submitter to set, I think it's a bad idea. > 3) NEEDINFO is used to avoid changing the Assigned pointer when fixes > are needed. > 4) Assigned pointer DOES NOT CHANGE during and after the review. > > Fedora Review Flag States > ========================= > fedora-review BLANK (Not under review at all!) > fedora-review? (I want a review) > fedora-review- (rejected, needs work, set NEEDINFO to person who > needs to fix it) > fedora-review+ (APPROVED) How about instead: fedora-review BLANK (I want a review) (so it doesn't need to be set) fedora-review ? (in process of review, questions for submitter or reviewer pending) fedora-review - (submitter stopped responding, withdrew package, decided to let someone else submit, etc) fedora-review + (APPROVED) I think we should try and avoid the "rejected" word in the flow. I suspect people will see that as "this package is no good, we don't want it". > > Assigned Pointer > ================ > (Note, Assigned pointer is different from the ASSIGNED state.) > - Assigned pointer to nobody at fedoraproject.org if no reviewer yet. > - Assigned pointer to reviewer, during and after review. > - Set Assigned pointer back to nobody if reviewer gave up. Sounds good. > Bugzilla States > =============== > NEW ASSIGNED REOPENED (rather meaningless distinction?) > NEEDINFO (to owner or somebody who needs to act to fix) > MODIFIED (seems to be fixed, please test it) What does this state do? > CLOSED (ticket is done) > > Process > ======= > 1. Review Request is filed. > 2. Set fedora-review? flag to signify that the ticket is ready for > review. I'm sure this will get missed by people who don't know the process that well (submitters). > 3. Reviewer takes bug, Assigned pointer set to self. > 4. If APPROVED, fedora-review+. > 5. If rejected, fedora-review- and NEEDINFO owner to fix it. > 6. If fedora-review- and owner fixes something, set back to ? to > request review again. I think it might make more sense to just move from BLANK (new request) to ? (in process) To my mind, ? makes it more obvious that there is a question, and things are pending, but - makes it sound like it was unacceptable at all. to + (APPROVED) > 7. After fedora-review+, initiate the fedora-cvs request procedure. > 8. After fedora-cvs, checkin, build, and set to CLOSED. Could the admin that processes the fedora-cvs request also close the bug? That would take another step away from a submitter who might not know the process well. > Drawbacks > ========= > Since the mass review tickets were not filed by the package owners, > it is less than obvious. Most reviews however are filed by owners, > so this is less of a problem beyond this mass review. Agreed. > Other Possibilities > =================== > fedora-review? could also be used on any other Fedora bug when a > horrible mess is found in an existing package, and attention for a > re-review would be desired to fix it. (Good idea, bad idea?) Might work... but it would add a bunch of comments to a bug that might be un-related to other review cleanups. Perhaps a 're-review' request could be filed for the package. > Possible Process Optimizations > ============================== > (These might possibly help... although they might require hacks in > Bugzilla's code, so we only request these optimizations only if they > would make a huge positive difference. Your thoughts?) > 1. Changing fedora-review in any way should auto-CC yourself > automatically. 2. Changing fedora-review to + should auto-set > Assigned pointer to self. Those might be nice if easy to do.. > Warren Togami kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at tummy.com Tue Feb 6 02:28:39 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 5 Feb 2007 19:28:39 -0700 Subject: RFC: CVS Admin with Flags (Version 1) In-Reply-To: <45C7C3EC.1010300@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45C7C3EC.1010300@redhat.com> Message-ID: <20070205192839.38fe8004@ningauble.scrye.com> On Mon, 05 Feb 2007 18:55:24 -0500 wtogami at redhat.com (Warren Togami) wrote: > Your comments would be very much appreciated. > > Current Crappy CVSSyncNeeded Wiki Procedure > =========================================== > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded > 1. Request new package and branch. > 2. Wait until somebody creates empty directories and edits > owners.list. 3. Owner checks stuff in and builds. > > Using the Wiki for this process has always sucked. We could embed > this process within the Bugzilla review tickets themselves. Great. One less weird place to deal with sounds good to me. > Proposal: CVS Admin with Flags > ============================== > 1) Review is complete, fedora-review+ > 2) Owner writes in the Bugzilla comment something like: > > FC-5 FC-6 foopackage bobjoe bobjoebugzilla at gmail.com > 3) Set fedora-cvs flag to ? > 4) CVS Admins get e-mail about fedora-cvs flag. All context of the > review is within the bug itself, so they can easily read all details > about the package and verify approval validity. The Admin then > creates CVS directories and sets owner. Sets fedora-cvs flag to > BLANK. 5) Owner checks in and builds. Sounds great. How about also having the admin close the bug when they set the flag back to BLANK in step 4? One less thing for the submitter to forget to do. > > Benefits > ======== > - This fedora-cvs flag eliminates the need for CVSSyncNeeded > entirely. An actual work queue with tickets! > - fedora-cvs can be a simple canned query for CVS admins to see. > Awesome possibilities offered via RSS too... =) > - You could also use the fedora-cvs flag with explicit instructions > within any bug to do special requests, like: > "Please remove audacious-itouch. We made some mistake. Blah blah." > > Notes > ===== > - Unlike other flags, fedora-cvs is only BLANK or ?. fedorabugs > members may request fedora-cvs by setting it to ?. This sends an > e-mail to CVS Admins, signifying that attention is required. Sounds great. > Warren Togami kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Feb 6 02:50:35 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Feb 2007 03:50:35 +0100 Subject: ACL and sponsorship Message-ID: <1170730235.1254.163.camel@mccallum.corsepiu.local> Hi, One motiviation behind the FE sponsorship model was sponsors to be able to help and assist "newcomers" during their initial encounters with the Fedora buildsystem. In many cases this had required to directly intervene into CVS? Am I correct in presuming this not to be possible with the ACLs anymore? Ralf From rc040203 at freenet.de Tue Feb 6 02:53:50 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Feb 2007 03:53:50 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C6EAA8.7040401@hhs.nl> Message-ID: <1170730431.1254.168.camel@mccallum.corsepiu.local> On Mon, 2007-02-05 at 19:28 -0600, Jason L Tibbitts III wrote: > What's annoying is that people whining because something has changed. People are complaining, because * things are being changed without them having been informed in advance * things are being unleashed apparently prematurely/without sufficient prior testing * there was/is no real documentation * questions stay unanswered, when trying to dig for understanding. * there are no apparent benefits to reviewers. * things appear broken. * the infrastructure this "Merge Reviews" require, is unusable (cvs/cvsview) rsp. broken (acls). ... > We've tried something new because we needed to. Here you say it: "trying" == "is not guaranteed to be a success", "temporarily breaks things". > The whole thing is a > work in progress. Deal. If we never try anything new, we'll never do > worse but we also won't ever do any better. You are performing a kidney transplant without anaesthesia, without the patient's informed consent and are pushing aside the relatives when asking questions. Ralf From lmacken at redhat.com Tue Feb 6 02:57:04 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 5 Feb 2007 21:57:04 -0500 Subject: [Fwd: Fedora Core 6 Update: thunderbird-1.5.0.9-7.fc6] In-Reply-To: <21543.65.192.24.190.1170707254.squirrel@mail.jcomserv.net> References: <21543.65.192.24.190.1170707254.squirrel@mail.jcomserv.net> Message-ID: <20070206025704.GH20991@tomservo.rh.rit.edu> On Mon, Feb 05, 2007 at 02:27:34PM -0600, Jon Ciesla wrote: > I can't seem to pull this update from any yum repo, including my own which > is mirrored from an upstream repo. I seem to be able to get all the other > recent updates, but not this one. Is there a repo metadata issue? I've > verified this across multiple machines and repos, all with thunderbird > 1.5.0.9-2 installed. I could install manually, but if there's a larger > problem, I'd like it brought to light. > > So far, this is the only package I've noticed this with. Something exploded during that push, which prevented thunderbird-1.5.0.9-7.fc6 from seeing the light of day. I repushed it a couple of days ago, and it is current in the repos and metadata. My FC6 machines are also pulling it down now as we speak. luke From wtogami at redhat.com Tue Feb 6 03:56:48 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 05 Feb 2007 22:56:48 -0500 Subject: ACL and sponsorship In-Reply-To: <1170730235.1254.163.camel@mccallum.corsepiu.local> References: <1170730235.1254.163.camel@mccallum.corsepiu.local> Message-ID: <45C7FC80.8090803@redhat.com> Ralf Corsepius wrote: > Hi, > > One motiviation behind the FE sponsorship model was sponsors to be able > to help and assist "newcomers" during their initial encounters with the > Fedora buildsystem. > > In many cases this had required to directly intervene into CVS? > > Am I correct in presuming this not to be possible with the ACLs anymore? > A flaw in your reasoning is perhaps, that how it is today is how it will be forever. The current implementation is nowhere near complete. We are working on the Package Database system, which will allow all kinds of automations of policies that we decide upon. Please help us to build the design of this future, instead of only complain about the present. Warren Togami wtogami at redhat.com From Matt_Domsch at dell.com Tue Feb 6 04:05:13 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 5 Feb 2007 22:05:13 -0600 Subject: Missing merge review tickets, core->extras dependencies In-Reply-To: <20070205204559.GF4858@nostromo.devel.redhat.com> References: <200702041759.11322.ville.skytta@iki.fi> <1170606958.9171.8.camel@localhost.localdomain> <200702041851.55510.ville.skytta@iki.fi> <20070205204559.GF4858@nostromo.devel.redhat.com> Message-ID: <20070206040513.GB32250@lists.us.dell.com> On Mon, Feb 05, 2007 at 03:45:59PM -0500, Bill Nottingham wrote: > Ville Skytt? (ville.skytta at iki.fi) said: > > > > 2) Are Core packages under review allowed to have build and install time > > > > dependencies to packages in Extras nowadays or (still) not? > > > > > > I think yes, since post-merge, there will be no difference. > > > > That'd be nice. Does the Core build system have Extras repos configured > > already now? My mass rebuild system does, if that helps you, even though the formal buildsystems don't (yet). -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From rc040203 at freenet.de Tue Feb 6 04:20:55 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Feb 2007 05:20:55 +0100 Subject: ACL and sponsorship In-Reply-To: <45C7FC80.8090803@redhat.com> References: <1170730235.1254.163.camel@mccallum.corsepiu.local> <45C7FC80.8090803@redhat.com> Message-ID: <1170735655.21576.20.camel@mccallum.corsepiu.local> On Mon, 2007-02-05 at 22:56 -0500, Warren Togami wrote: > Ralf Corsepius wrote: > > Hi, > > > > One motiviation behind the FE sponsorship model was sponsors to be able > > to help and assist "newcomers" during their initial encounters with the > > Fedora buildsystem. > > > > In many cases this had required to directly intervene into CVS? > > > > Am I correct in presuming this not to be possible with the ACLs anymore? > > > > A flaw in your reasoning is perhaps, that how it is today is how it will > be forever. The current situation is a severe behavioral regression, imposing a heavy drawback to the foundations FE is based on. It renders a fundamental aspect of sponsorship inapplicable. > Please help us to build the design of this future, > instead of only complain about the present. The problem is the present - You have introduced a regression. In most other projects, you'd hear a "revert this change"/"Back to the drawing board" or "fix your bugs". Ralf From Christian.Iseli at licr.org Tue Feb 6 08:12:57 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 6 Feb 2007 09:12:57 +0100 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <45C7C0A3.3010808@redhat.com> References: <45C7C0A3.3010808@redhat.com> Message-ID: <20070206091257.63aa94bf@ludwig-alpha.unil.ch> On Mon, 05 Feb 2007 18:41:23 -0500, Warren Togami wrote: > 2) BLANK means review not requested. ? means review requested. This > makes it easier to query, because querying for BLANK is a bit inefficient. > (Good idea, bad idea?) bad idea IMHO. Filing the ticket *does* mean I want a review. I much prefer nirik's suggestion: blank -> I want a reviewer ? -> normal review under way (can use NEEDINFO if wanted) + -> ACCEPT - -> something bad happened (stalled review, bad license, ...) The rest sounds fine. C From Christian.Iseli at licr.org Tue Feb 6 08:15:34 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 6 Feb 2007 09:15:34 +0100 Subject: RFC: CVS Admin with Flags (Version 1) In-Reply-To: <45C7C3EC.1010300@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45C7C3EC.1010300@redhat.com> Message-ID: <20070206091534.1cdd0382@ludwig-alpha.unil.ch> On Mon, 05 Feb 2007 18:55:24 -0500, Warren Togami wrote: > Your comments would be very much appreciated. Sounds good to me. C From bugs.michael at gmx.net Tue Feb 6 09:34:03 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 6 Feb 2007 10:34:03 +0100 Subject: Broken deps in FC6 Updates In-Reply-To: References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <200702031759.22970.jkeating@redhat.com> <20070204000833.3a5e86ba.bugs.michael@gmx.net> <200702040952.56905.jkeating@redhat.com> <20070204162151.6e35be12.bugs.michael@gmx.net> Message-ID: <20070206103403.f04b46f8.bugs.michael@gmx.net> On 05 Feb 2007 20:13:27 -0600, Jason L Tibbitts III wrote: > >>>>> "MS" == Michael Schwendt writes: > > MS> When we faced this topic in Extras and FESCo, nobody showed any > MS> interest in it. > > Actually the packaging committee had some significant discussions > about it. Strangely, the results of that discussion are unknown and/or have not been communicated back in an appropriate way. Fesco list was silent with regard to that matter, and that was one week before the elections and four days before receiving spot's first mail about the foundation of the packaging committee. > I recall that I was against changing the meaning of noarch. What is the "meaning of noarch" in your point of view? I've not seen a single comment on the topic from anyone inside fesco except jkatz, who briefly outlined what's done in core. Don't get me wrong, please. I don't care much about the meaning of it, and I've had fun adding the ExcludeArch for noarch stuff to the extras pushscript even if I think RPM is flawed in that it doesn't propagate the ExcludeArch tag into the binary package. But if you see in me somebody who seems to complain often, even about past issues, this is because I very much dislike all the unpleasant experience and the "walls out of concrete" that turn up in the project. From bugs.michael at gmx.net Tue Feb 6 09:34:01 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 6 Feb 2007 10:34:01 +0100 Subject: ACL and sponsorship In-Reply-To: <45C7FC80.8090803@redhat.com> References: <1170730235.1254.163.camel@mccallum.corsepiu.local> <45C7FC80.8090803@redhat.com> Message-ID: <20070206103401.6b190f0a.bugs.michael@gmx.net> On Mon, 05 Feb 2007 22:56:48 -0500, Warren Togami wrote: > Ralf Corsepius wrote: > > Hi, > > > > One motiviation behind the FE sponsorship model was sponsors to be able > > to help and assist "newcomers" during their initial encounters with the > > Fedora buildsystem. > > > > In many cases this had required to directly intervene into CVS? > > > > Am I correct in presuming this not to be possible with the ACLs anymore? > > > > A flaw in your reasoning is perhaps, that how it is today is how it will > be forever. > > The current implementation is nowhere near complete. It's a premature roll-out that introduces regression and is a slap into the face of FE sponsors. From limb at jcomserv.net Tue Feb 6 12:41:50 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 6 Feb 2007 06:41:50 -0600 (CST) Subject: [Fwd: Fedora Core 6 Update: thunderbird-1.5.0.9-7.fc6] In-Reply-To: <20070206025704.GH20991@tomservo.rh.rit.edu> References: <21543.65.192.24.190.1170707254.squirrel@mail.jcomserv.net> <20070206025704.GH20991@tomservo.rh.rit.edu> Message-ID: <31821.65.192.24.190.1170765710.squirrel@mail.jcomserv.net> Looks great. Thanks! > On Mon, Feb 05, 2007 at 02:27:34PM -0600, Jon Ciesla wrote: >> I can't seem to pull this update from any yum repo, including my own >> which >> is mirrored from an upstream repo. I seem to be able to get all the >> other >> recent updates, but not this one. Is there a repo metadata issue? I've >> verified this across multiple machines and repos, all with thunderbird >> 1.5.0.9-2 installed. I could install manually, but if there's a larger >> problem, I'd like it brought to light. >> >> So far, this is the only package I've noticed this with. > > Something exploded during that push, which prevented > thunderbird-1.5.0.9-7.fc6 > from seeing the light of day. I repushed it a couple of days ago, and > it is current in the repos and metadata. My FC6 machines are also > pulling it down now as we speak. > > luke > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From tibbs at math.uh.edu Tue Feb 6 13:55:22 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Feb 2007 07:55:22 -0600 Subject: Broken deps in FC6 Updates In-Reply-To: <20070206103403.f04b46f8.bugs.michael@gmx.net> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <200702031759.22970.jkeating@redhat.com> <20070204000833.3a5e86ba.bugs.michael@gmx.net> <200702040952.56905.jkeating@redhat.com> <20070204162151.6e35be12.bugs.michael@gmx.net> <20070206103403.f04b46f8.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Strangely, the results of that discussion are unknown and/or have MS> not been communicated back in an appropriate way. I don't know that it came to any specific end; it was just something that came up on IRC (or was it the mailing list?) and was discussed. It didn't produce a draft or anything (probably because we couldn't agree). Ah, my logs show a discussion on July 13, 2006. See http://fedoraproject.org/wiki/Packaging/IRCLog20060713, scroll down to "(09:52:34)". MS> What is the "meaning of noarch" in your point of view? To me it means that the files inside the package don't contain host-executable binary components. Others don't agree. The simplest example that illustrates the contention is a shell script that parses /proc/cpuinfo on, say, a Sparc and will do nothing useful on any other machine. noarch or not? Back then I said noarch, others disagree. I'm open to discussion, especially since then I admit I didn't fully consider the necessary hacks that were required to get this to work. Note that the proposal was very close to passing and may pass again if discussed again. - J< From lmacken at redhat.com Tue Feb 6 15:30:29 2007 From: lmacken at redhat.com (Luke Macken) Date: Tue, 6 Feb 2007 10:30:29 -0500 Subject: Broken deps in FC6 Updates In-Reply-To: <1170550313.5370.18.camel@dennis.gregorovic.net> References: <20070203201524.8fd1667f.bugs.michael@gmx.net> <20070203192652.GA1179@redhat.com> <20070203233923.73aa3f73.bugs.michael@gmx.net> <200702031759.22970.jkeating@redhat.com> <20070204000833.3a5e86ba.bugs.michael@gmx.net> <1170550313.5370.18.camel@dennis.gregorovic.net> Message-ID: <20070206153029.GA2466@tomservo.rh.rit.edu> On Sat, Feb 03, 2007 at 07:51:53PM -0500, Dennis Gregorovic wrote: > On Sun, 2007-02-04 at 00:08 +0100, Michael Schwendt wrote: > > On Sat, 3 Feb 2007 17:59:22 -0500, Jesse Keating wrote: > > > > > On Saturday 03 February 2007 17:39, Michael Schwendt wrote: > > > > But since the build is in the ppc repo, then there's a bug in the push > > > > process somewhere. > > > > > > Uh, how did it get built in the first place? Doesn't ExcludeArch mean it > > > won't get built there? > > > > BuildArch: noarch > > ExcludeArch: ppc > > > > > > [In comparison, the Extras push script examines the src.rpm for the > > ExcludeArch tag and doesn't push such noarch packages to the excluded > > target repos. That is something that has been said is done for Core, > > too. IIRC, either jkatz or sopwith has said that.] > > Looks like this needs to be fixed in the current Fedora Core updates > scripts. I've sent a patch to Luke. Thanks for the patch Dennis; it has been applied. luke From jwboyer at jdub.homelinux.org Tue Feb 6 14:38:02 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 6 Feb 2007 08:38:02 -0600 Subject: disclaimed ownership of core packages In-Reply-To: References: <20070202161419.20a3bdd5@ludwig-alpha.unil.ch> Message-ID: <20070206143802.GA4157@yoda.jdub.homelinux.org> On Mon, Feb 05, 2007 at 08:20:06PM -0600, Jason L Tibbitts III wrote: > >>>>> "CI" == Christian Iseli writes: > > CI> Hi folks, It seems there are a few cases of disclaimed ownership > CI> of core packages, e.g.: https://bugzilla.redhat.com/226558 > > Hmm, no replies to this and I didn't see the question raised during > fudcon. > > I think there shouldn't be any question that such packages should be > kept out of F7 until they find maintainers. If there's nobody to > review the package, perhaps as we get closer to release without seeing > a maintainer for those bugs, we should just close them and block > something analogous to FE-DEADREVIEW that doesn't actually exist. > Perhaps FE-DEADREVIEW can be overloaded for this. I actually ran into this for a package I'd like to take over myself. Jeff orphaned jfsutils... so I'll claim it. But now what? After the review, do I bring it into Extras CVS? Oh, and I was planning on reviewing this but now I'm taking ownership. I guess I need another reviewer. Any takers? :) josh From jkeating at redhat.com Tue Feb 6 15:43:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 10:43:26 -0500 Subject: RFC: CVS Admin with Flags (Version 1) In-Reply-To: <20070205192839.38fe8004@ningauble.scrye.com> References: <45BE7342.1070005@redhat.com> <45C7C3EC.1010300@redhat.com> <20070205192839.38fe8004@ningauble.scrye.com> Message-ID: <200702061043.26193.jkeating@redhat.com> On Monday 05 February 2007 21:28, Kevin Fenzi wrote: > Sounds great. > How about also having the admin close the bug when they set the flag > back to BLANK in step 4? One less thing for the submitter to forget to > do. Well, the admin doesn't know if/when the developer A) did the import, and B) actually built the package for rawhide. That is when the bug should be closed, once the package is actually _in_ the collection. -- 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 roozbeh at farsiweb.info Tue Feb 6 16:02:21 2007 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Tue, 06 Feb 2007 19:32:21 +0330 Subject: Problems with core review Message-ID: <1170777741.3333.76.camel@shalil.farsiweb.info> I have been trying to help with the core review, and I wish to share the major burdens I encountered: 1) Online CVS access is not available to reviewers. There is a delay of about two hours, I believe. Packager says "I fixed it", reviewer says "did you not forget to commit, because I don't see it"? 2) Core package owners may not be very familiar with the packaging guidelines, or why they are actually there. Some may even think it's just some level of bureaucracy/extra burden (in short, not very exciting). 3) Core package owners were not asked to clean up their packages before putting them up for review. Packages have been sitting there and then suddenly a horde of odd and demanding people have jumped on to review them. This also means that the quality of what being reviewed is quite random, when a quick look at the guidelines (and doing some related action) may have minimized the extra communication and the possibility of reviewers burning out because of repeating the same basic things instead of finding/fixing the more interesting issues. 4) The process is not very clear. Packagers have fixed some of the mentioned issues and change the status to MODIFIED, packagers have fixed some of the mentioned issues and change the status to FIXED/RAWHIDE, ... But I assume that's getting fixed. 5) Since this is Core and includes things that are basic to the system or have been done in some certain ways for a while, some things are more complicated: Should Prereq be used for the very basic packages of the system? Who should really own /usr/share/gtk-doc? If files in /etc/profile.d should not be executable, why is every file already there executable?! 6) Since the spec files are rarely based on rpmdev-newspec templates, the files are not as readable as they should be. When one reviews un-styled C code, he can simply run 'indent' on it and read it. But the same is not easy with spec files. Roozbeh PS: I guess I should thank all the core packagers who were so understanding with the early reviews, specially Matthias Clasen. From mtasaka at ioa.s.u-tokyo.ac.jp Tue Feb 6 16:14:16 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 07 Feb 2007 01:14:16 +0900 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <45C7C0A3.3010808@redhat.com> References: <45C7C0A3.3010808@redhat.com> Message-ID: <45C8A958.6060809@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > Raw notes... your comments would be very much appreciated. By the way.... On current bugzilla system, who can change fedora-review or fedora-cvs flags? Especially can new contributor (i.e. who want to get sponsored by someone) change the flags? A new contributor does not have cvsextras nor fedorabug. If no: * submitter (new contributor) cannot revise the flag to fedora-review? from fedora-review- when submitter modified his/her srpm/spec and want to make them checked. * And.. who should (and can) change the fedora-cvs flags? A submitter or the reviewer(assignee)? At this time, a new contributor(submitter) should have cvsextras, however, normally he/she does not have fedorabug. Currently, the _submitter_ (new contributor) writes the request on SyncNeeded wiki, however, if submitter _cannot_ change fedora-cvs flags, the _reviewer_(assignee) has to change fedora-cvs flags, as long as only fedorabugs member can change the flag. Mamoru From wtogami at redhat.com Tue Feb 6 17:13:49 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Feb 2007 12:13:49 -0500 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <45C8A958.6060809@ioa.s.u-tokyo.ac.jp> References: <45C7C0A3.3010808@redhat.com> <45C8A958.6060809@ioa.s.u-tokyo.ac.jp> Message-ID: <45C8B74D.6090909@redhat.com> Mamoru Tasaka wrote: > Warren Togami wrote: >> Raw notes... your comments would be very much appreciated. > > By the way.... > On current bugzilla system, who can change fedora-review or > fedora-cvs flags? Especially can new contributor (i.e. who > want to get sponsored by someone) change the flags? > A new contributor does not have cvsextras nor fedorabug. fedora-cvs and fedora-review may be seen by all. fedora-review? may be set by anyone. fedora-review- or + may be set only by fedora contributors. (this will change in the future to be cvsextras or something) fedora-cvs? may be set only by fedora contributors. > > If no: > * submitter (new contributor) cannot revise the flag to > fedora-review? from fedora-review- when submitter modified > his/her srpm/spec and want to make them checked. > > * And.. who should (and can) change the fedora-cvs flags? A > submitter or the reviewer(assignee)? At this time, a new > contributor(submitter) should have cvsextras, however, > normally he/she does not have fedorabug. > Currently, the _submitter_ (new contributor) writes the > request on SyncNeeded wiki, > however, if submitter _cannot_ change fedora-cvs flags, > the _reviewer_(assignee) has to change fedora-cvs flags, as long > as only fedorabugs member can change the flag. > Shouldn't the submitter become sponsored before committing? In any case only fedorabugs group membership is necessary currently in order to flip fedora-review and fedora-cvs, although I think we should change that to cvsextras later. (Currently cvsextras does not sync to a Bugzilla group. Several things we have to fix before that is possible. Warren Togami wtogami at redhat.com From tmz at pobox.com Tue Feb 6 17:32:19 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 6 Feb 2007 12:32:19 -0500 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <45C8B74D.6090909@redhat.com> References: <45C7C0A3.3010808@redhat.com> <45C8A958.6060809@ioa.s.u-tokyo.ac.jp> <45C8B74D.6090909@redhat.com> Message-ID: <20070206173219.GA1174@psilocybe.teonanacatl.org> Warren Togami wrote: > fedora-cvs and fedora-review may be seen by all. > fedora-review? may be set by anyone. > fedora-review- or + may be set only by fedora contributors. (this > will change in the future to be cvsextras or something) Perhaps I've hit a bug somewhere then or I am simply misunderstanding something here... (quite likely the latter) I am a relatively new contributor but I am in both cvsextras and fedorabugs. I have done merge reviews for libgpod (226022) and gnupg (225847). I was able to set fedora-review? and then fedora-review+ for libgpod. But setting fedora-review? for gnupg has left it in the "Issues with Flags You Have Requested" section on my bugzilla front page and the Requestee is blank. Is that the intended state for fedora-review? or has something gone askew? It does appear correct in the bug's Flags section, showing "tmz: fedora-review ?". Pardon the noise from my confusion if this is all as it should be. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== Life may have no meaning. Or even worse, it may have a meaning of which I disapprove. -- Ashleigh Brilliant -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From wtogami at redhat.com Tue Feb 6 17:46:24 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Feb 2007 12:46:24 -0500 Subject: Problems with core review In-Reply-To: <1170777741.3333.76.camel@shalil.farsiweb.info> References: <1170777741.3333.76.camel@shalil.farsiweb.info> Message-ID: <45C8BEF0.2000501@redhat.com> Roozbeh Pournader wrote: > I have been trying to help with the core review, and I wish to share the > major burdens I encountered: > > 1) Online CVS access is not available to reviewers. There is a delay of > about two hours, I believe. Packager says "I fixed it", reviewer says > "did you not forget to commit, because I don't see it"? I agree this is a problem, but not one that we can solve easily. This problem is already scheduled to go away in the near future when the CVS move happens. Can we just deal for now and focus on the tougher problems? > > 2) Core package owners may not be very familiar with the packaging > guidelines, or why they are actually there. Some may even think it's > just some level of bureaucracy/extra burden (in short, not very > exciting). They need to just deal with it. If they haven't heard about the packaging guidelines by now, they are not doing their job properly and they need some education. /me prepares the cluebat. > > 3) Core package owners were not asked to clean up their packages before > putting them up for review. Packages have been sitting there and then > suddenly a horde of odd and demanding people have jumped on to review > them. This also means that the quality of what being reviewed is quite > random, when a quick look at the guidelines (and doing some related > action) may have minimized the extra communication and the possibility > of reviewers burning out because of repeating the same basic things > instead of finding/fixing the more interesting issues. > > 4) The process is not very clear. Packagers have fixed some of the > mentioned issues and change the status to MODIFIED, packagers have fixed > some of the mentioned issues and change the status to FIXED/RAWHIDE, ... > But I assume that's getting fixed. This needs to be addressed in the next version of the process. I think the states like MODIFIED, CLOSED RAWHIDE, should become irrelevant. What matters is the fedora-review+ flag, and if it happened properly or not. Warren From wtogami at redhat.com Tue Feb 6 17:57:41 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Feb 2007 12:57:41 -0500 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <20070206173219.GA1174@psilocybe.teonanacatl.org> References: <45C7C0A3.3010808@redhat.com> <45C8A958.6060809@ioa.s.u-tokyo.ac.jp> <45C8B74D.6090909@redhat.com> <20070206173219.GA1174@psilocybe.teonanacatl.org> Message-ID: <45C8C195.9010307@redhat.com> Todd Zullinger wrote: > Warren Togami wrote: >> fedora-cvs and fedora-review may be seen by all. >> fedora-review? may be set by anyone. >> fedora-review- or + may be set only by fedora contributors. (this >> will change in the future to be cvsextras or something) > > Perhaps I've hit a bug somewhere then or I am simply misunderstanding > something here... (quite likely the latter) > > I am a relatively new contributor but I am in both cvsextras and > fedorabugs. I have done merge reviews for libgpod (226022) and gnupg > (225847). I was able to set fedora-review? and then fedora-review+ > for libgpod. But setting fedora-review? for gnupg has left it in the > "Issues with Flags You Have Requested" section on my bugzilla front > page and the Requestee is blank. > > Is that the intended state for fedora-review? or has something gone > askew? It does appear correct in the bug's Flags section, showing > "tmz: fedora-review ?". > > Pardon the noise from my confusion if this is all as it should be. > The way it is interpreted to be displayed by frontpage.cgi might be incorrect. We can fix that after we agree upon these new process changes. Warren Togami wtogami at redhat.com From chris.stone at gmail.com Tue Feb 6 18:04:07 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 6 Feb 2007 10:04:07 -0800 Subject: Problems with core review In-Reply-To: <45C8BEF0.2000501@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> Message-ID: On 2/6/07, Warren Togami wrote: > Roozbeh Pournader wrote: > > 2) Core package owners may not be very familiar with the packaging > > guidelines, or why they are actually there. Some may even think it's > > just some level of bureaucracy/extra burden (in short, not very > > exciting). > > They need to just deal with it. If they haven't heard about the > packaging guidelines by now, they are not doing their job properly and > they need some education. > > /me prepares the cluebat. Can you please whammy Joe Orton with it? There are several problems I've had with this person. 1) php-pear has a major upgrade (1.5.0) and the current version is 1.4.11 in cvs. The 1.5.0 upgrade is going to bring on significant changes. I am asking him to make these significant changes _before_ I do a formal review. However, he insists that I must do my review on the version that is currently in CVS. 2) Joe refuses to make benign trivial changes to the spec file. These are changes that were suggested by members of the packaging committee, for example f13 suggested to use %{SOURCEx} notation when installing sources instead of $RPM_SOURCE_DIR. Joe refuses to make simple changes like this and would rather bring the issues back up with the packaging committee. I think he feels wasting the committe's time is more important than ten seconds of his time to make the change. 3) There is a major change that needs to be made with php-pear package. Essentially the pear installer needs to be included as a sub package of the main php package. This is technically required for the new 1.5.0 upgrade in order to prevent clashing with existing packages. The current method Joe uses lumps a ton of packages together into a single package using a bootstrapping method which is not even required. His excuse for not making the change is because he thinks the pear installer needs to be updated outside of php which is not the case. The pear installer is included as part of php from upstream and they do that for a reason. I have to say Joe has been the most stubbon and diffucult packager I have ever had to deal with as a reviewer, and I have reviewed over fifty packages. I sure hope not all core packagers are this way! https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226295 From notting at redhat.com Tue Feb 6 18:30:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 13:30:22 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070205235041.d082c497.bugs.michael@gmx.net> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <20070205235041.d082c497.bugs.michael@gmx.net> Message-ID: <20070206183022.GA29861@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > > What's the failure point here now? > > Packages marked as "dead.package" lack the "Makefile", which breaks > cvs-import.sh. There is a patch by me (posted to fesco in June last year) > which I've resent a few days ago, because it has not been applied so far. Hm. Why does dead.package not have a makefile? To prevent accidental builds? Bill From notting at redhat.com Tue Feb 6 18:32:12 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 13:32:12 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070206002323.GG21605@ryvius.pekin.waw.pl> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <20070206002323.GG21605@ryvius.pekin.waw.pl> Message-ID: <20070206183212.GB29861@nostromo.devel.redhat.com> Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: > No. It adds a hurdle that wasn't there before. Personally, I'm probably > going to postpone importing any packages I have queued up until this is > changed back. What was so wrong with anyone in cvsextras group being able > to modify owners.list that you had to change it? Simple - by allowing any edits, you allow anyone to change the ownership, and therefore allow/grant access, to packages they don't own. Bill From wart at kobold.org Tue Feb 6 18:42:28 2007 From: wart at kobold.org (Michael Thomas) Date: Tue, 06 Feb 2007 10:42:28 -0800 Subject: Tcl packaging guidelines Message-ID: <45C8CC14.1090707@kobold.org> Following the precedent set by perl, python, and ruby, I've drafted a set of proposed guidelines for Tcl packages. http://fedoraproject.org/wiki/MichaelThomas/Tcl The main motivation behind these guidelines is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226893 These proposed guidelines will require changes to most of the existing Tcl extensions in Fedora, as the installation directory for arch-specific packages will need to be changed from %{_libdir} to %{_libdir/tcl8.x. Since Tcl was recently upgraded from 8.4 to 8.5a5 in rawhide, this seemed like a suitable time to make such changes. I'd like to get any feedback on this proposal before I submit it to the Fedora packaging committee, hopefully in time so that the changes can be made before the F7 release. --Wart From notting at redhat.com Tue Feb 6 18:52:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 13:52:06 -0500 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <45C7C0A3.3010808@redhat.com> References: <45C7C0A3.3010808@redhat.com> Message-ID: <20070206185206.GE29861@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > Fedora Review Flag States > ========================= > fedora-review BLANK (Not under review at all!) > fedora-review? (I want a review) What's the point of the distinction here. I'm not seeing when a package would ever need to have this blank. Bill From notting at redhat.com Tue Feb 6 18:53:56 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 13:53:56 -0500 Subject: ACL and sponsorship In-Reply-To: <1170730235.1254.163.camel@mccallum.corsepiu.local> References: <1170730235.1254.163.camel@mccallum.corsepiu.local> Message-ID: <20070206185356.GF29861@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > Am I correct in presuming this not to be possible with the ACLs anymore? Only if you choose to have an ACL and not add the sponsor. Bill From wtogami at redhat.com Tue Feb 6 18:57:15 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Feb 2007 13:57:15 -0500 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <20070206185206.GE29861@nostromo.devel.redhat.com> References: <45C7C0A3.3010808@redhat.com> <20070206185206.GE29861@nostromo.devel.redhat.com> Message-ID: <45C8CF8B.7070503@redhat.com> Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: >> Fedora Review Flag States >> ========================= >> fedora-review BLANK (Not under review at all!) >> fedora-review? (I want a review) > > What's the point of the distinction here. I'm not seeing when > a package would ever need to have this blank. > Correct, next version fixes this. Warren From ruben at rubenkerkhof.com Tue Feb 6 19:19:44 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Tue, 6 Feb 2007 20:19:44 +0100 Subject: ACL and sponsorship In-Reply-To: <20070206185356.GF29861@nostromo.devel.redhat.com> References: <1170730235.1254.163.camel@mccallum.corsepiu.local> <20070206185356.GF29861@nostromo.devel.redhat.com> Message-ID: On 6-feb-2007, at 19:53, Bill Nottingham wrote: > Ralf Corsepius (rc040203 at freenet.de) said: >> Am I correct in presuming this not to be possible with the ACLs >> anymore? > > Only if you choose to have an ACL and not add the sponsor. > > Bill > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers Wouldn't it be possible to add someone's sponsor to the ACL by default? Ruben From jorton at redhat.com Tue Feb 6 19:20:04 2007 From: jorton at redhat.com (Joe Orton) Date: Tue, 6 Feb 2007 19:20:04 +0000 Subject: Problems with core review In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> Message-ID: <20070206192004.GB6857@redhat.com> On Tue, Feb 06, 2007 at 10:04:07AM -0800, Christopher Stone wrote: > Can you please whammy Joe Orton with it? There are several problems > I've had with this person. I am very happy to make changes to all the packages I maintain to ensure they meet the packaging guidelines, and greatly appreciate the efforts of yourself and others in doing that. I know many of the Core packages are a mess, so it really is great that you guys spend the time helping us clean them up. But I will always resist arbitrary changes which lack technical justification (or are just plain undesirable); the fact that such changes are proposed as part of the Review Process does not make them sacrosanct. Regards, joe From notting at redhat.com Tue Feb 6 19:21:07 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 14:21:07 -0500 Subject: ACL and sponsorship In-Reply-To: References: <1170730235.1254.163.camel@mccallum.corsepiu.local> <20070206185356.GF29861@nostromo.devel.redhat.com> Message-ID: <20070206192107.GA30933@nostromo.devel.redhat.com> Ruben Kerkhof (ruben at rubenkerkhof.com) said: > Wouldn't it be possible to add someone's sponsor to the ACL by default? If the information was available in a programmatic way, sure! (AFAIK, it's not.) Bill From tibbs at math.uh.edu Tue Feb 6 19:33:25 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Feb 2007 13:33:25 -0600 Subject: ACL and sponsorship In-Reply-To: <20070206192107.GA30933@nostromo.devel.redhat.com> References: <1170730235.1254.163.camel@mccallum.corsepiu.local> <20070206185356.GF29861@nostromo.devel.redhat.com> <20070206192107.GA30933@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> If the information was available in a programmatic way, sure! BN> (AFAIK, it's not.) The account system certainly knows it. - J< From chris.stone at gmail.com Tue Feb 6 19:49:11 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 6 Feb 2007 11:49:11 -0800 Subject: Problems with core review In-Reply-To: <20070206192004.GB6857@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> Message-ID: On 2/6/07, Joe Orton wrote: > On Tue, Feb 06, 2007 at 10:04:07AM -0800, Christopher Stone wrote: > > Can you please whammy Joe Orton with it? There are several problems > > I've had with this person. > > I am very happy to make changes to all the packages I maintain to ensure > they meet the packaging guidelines, and greatly appreciate the efforts > of yourself and others in doing that. I know many of the Core packages > are a mess, so it really is great that you guys spend the time helping > us clean them up. > > But I will always resist arbitrary changes which lack technical > justification (or are just plain undesirable); the fact that such > changes are proposed as part of the Review Process does not make them > sacrosanct. Here are the issues in question: 1) Replace use of $RPM_SOURCE_DIR with %{SOURCEx} I asked about this in #fedora-extras since I did not understand rpmlints Error message. f13 responded by saying you should just use %{SOURCEx}. I agree with f13 on this issue because it is easier to identify in the spec file where the source files are used. Pros: Easier to spot SOURCE references in spec file Cons: None Time to implement change: approximately 30 seconds Time to complain vociferously about it and bring issue up with Packaging Committee: days if not weeks Benefits of running it through PC: None 2) Add empty %build section even though its not required All php-pear packages include an empty %build section and php-pear should not be an exception. This was disccussed at length when creating the php-pear spec file template. Ville has real world examples how this can cause problems. Technical reason for changing: rpm is unpredictable with no %build, consistency among all pear packages Technical reason for not changing: None Time requried to implement: 5 seconds Time required to complain vociferously about it and bring issue up with Packaging Committee: days if not weeks Benefits of running it through PC: None 3) License tag should change to just "PHP License 3.0" Technical reason for changing: consistency with all other php/php-pear packages Technical reason for not changing: None Time requried to implement: 5 seconds From fedora at leemhuis.info Tue Feb 6 20:23:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 06 Feb 2007 21:23:43 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070206183022.GA29861@nostromo.devel.redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <20070205235041.d082c497.bugs.michael@gmx.net> <20070206183022.GA29861@nostromo.devel.redhat.com> Message-ID: <45C8E3CF.8040003@leemhuis.info> Bill Nottingham schrieb: > Michael Schwendt (bugs.michael at gmx.net) said: >>> What's the failure point here now? >> Packages marked as "dead.package" lack the "Makefile", which breaks >> cvs-import.sh. There is a patch by me (posted to fesco in June last year) >> which I've resent a few days ago, because it has not been applied so far. > Hm. Why does dead.package not have a makefile? To prevent accidental > builds? I don't think there was a strong reasons why we wanted it do be deleted (at least I can't remember one). I was more a "delete everything and put a file dead.package into the directory" iirc. CU thl From jwboyer at jdub.homelinux.org Tue Feb 6 19:41:16 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 6 Feb 2007 13:41:16 -0600 Subject: Problems with core review In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> Message-ID: <20070206194116.GA6262@yoda.jdub.homelinux.org> On Tue, Feb 06, 2007 at 10:04:07AM -0800, Christopher Stone wrote: > > 1) php-pear has a major upgrade (1.5.0) and the current version is > 1.4.11 in cvs. The 1.5.0 upgrade is going to bring on significant > changes. I am asking him to make these significant changes _before_ I > do a formal review. However, he insists that I must do my review on > the version that is currently in CVS. You need to review what he intends to put in F7. If that's not 1.5.0, then oh well. Asking someone to do a major upgrade just for you to review it is silly. Especially given that we're driving towards a test2 release! > 2) Joe refuses to make benign trivial changes to the spec file. These > are changes that were suggested by members of the packaging committee, > for example f13 suggested to use %{SOURCEx} notation when installing > sources instead of $RPM_SOURCE_DIR. Joe refuses to make simple > changes like this and would rather bring the issues back up with the > packaging committee. I think he feels wasting the committe's time is > more important than ten seconds of his time to make the change. If they are only _suggested_ changes, and not _required_ changes, then he doesn't have to change. Period. As a review, you can suggest so but when someone says no, then drop it. josh From jorton at redhat.com Tue Feb 6 20:34:05 2007 From: jorton at redhat.com (Joe Orton) Date: Tue, 6 Feb 2007 20:34:05 +0000 Subject: Problems with core review In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> Message-ID: <20070206203404.GC6857@redhat.com> On Tue, Feb 06, 2007 at 11:49:11AM -0800, Christopher Stone wrote: > Here are the issues in question: > > 1) Replace use of $RPM_SOURCE_DIR with %{SOURCEx} > > I asked about this in #fedora-extras since I did not understand > rpmlints Error message. f13 responded by saying you should just use > %{SOURCEx}. > > I agree with f13 on this issue because it is easier to identify in the > spec file where the source files are used. Con: it makes renumering Sources a pain, it's harder to use since you have to remember numbers not filenames. This number/filename mapping trick doesn't scale well as anybody who has maintained spec files with more than a handful of patches knows. Insufficient justification for change. > 2) Add empty %build section even though its not required > > All php-pear packages include an empty %build section and php-pear > should not be an exception. This was disccussed at length when > creating the php-pear spec file template. Ville has real world > examples how this can cause problems. What are they, how do they apply to this package? > Technical reason for changing: rpm is unpredictable with no %build, > consistency among all pear packages It's worked predictably for the history of this package. Insufficient justification for change. > 3) License tag should change to just "PHP License 3.0" I'm not making changes here until a license tag standard is agreed. The current draft proposal on the wiki drops the version altogether. joe From bugs.michael at gmx.net Tue Feb 6 20:38:13 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 6 Feb 2007 21:38:13 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070206183022.GA29861@nostromo.devel.redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <20070205235041.d082c497.bugs.michael@gmx.net> <20070206183022.GA29861@nostromo.devel.redhat.com> Message-ID: <20070206213813.c4400290.bugs.michael@gmx.net> On Tue, 6 Feb 2007 13:30:22 -0500, Bill Nottingham wrote: > > Packages marked as "dead.package" lack the "Makefile", which breaks > > cvs-import.sh. There is a patch by me (posted to fesco in June last year) > > which I've resent a few days ago, because it has not been applied so far. > > Hm. Why does dead.package not have a makefile? To prevent accidental > builds? Because all files are removed in accordance with this process: http://fedoraproject.org/wiki/Extras/PackageEndOfLife As why the files are removed, I can't answer that question. Accidental builds can be prevent like this: http://cvs.fedora.redhat.com/viewcvs/devel/gdome2/gdome2.spec?root=extras&r1=1.8&r2=1.9 From peter at thecodergeek.com Tue Feb 6 20:49:21 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 06 Feb 2007 12:49:21 -0800 Subject: Problems with core review In-Reply-To: <20070206203404.GC6857@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> Message-ID: <1170794961.3836.8.camel@localhost> On Tue, 2007-02-06 at 20:34 +0000, Joe Orton wrote: > Con: it makes [renumbering] Sources a pain, it's harder to use since you > have to remember numbers not filenames. This number/filename mapping > trick doesn't scale well as anybody who has maintained spec files with > more than a handful of patches knows. > I'm sorry but this is absolute hilarity. If you have to remember which %SOURCEN macro corresponds to which file, then just scroll up in your favorite editor to the part that lists each Source/Patch file. If these names aren't descriptive enough, then that's an issue you need to resolve by renaming to something more appropriate (for example, "fix-BZ123456-config-error.patch" is a lot nicer than "fix-stupid-bug.patch"). And if you need to renumber them, just use the search/replace capabilities of your preferred editor...or even a simple 'sed -i' invocation... -- 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 Feb 6 20:51:44 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Feb 2007 15:51:44 -0500 Subject: ACL and sponsorship In-Reply-To: References: <1170730235.1254.163.camel@mccallum.corsepiu.local> <20070206185356.GF29861@nostromo.devel.redhat.com> Message-ID: <45C8EA60.7010104@redhat.com> Ruben Kerkhof wrote: > > On 6-feb-2007, at 19:53, Bill Nottingham wrote: > >> Ralf Corsepius (rc040203 at freenet.de) said: >>> Am I correct in presuming this not to be possible with the ACLs anymore? >> >> Only if you choose to have an ACL and not add the sponsor. >> > Wouldn't it be possible to add someone's sponsor to the ACL by default? > Yes, when we have greater automation potential with the Package Database. Currently it is not trivial to do this. Warren From wtogami at redhat.com Tue Feb 6 20:53:49 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Feb 2007 15:53:49 -0500 Subject: Problems with core review In-Reply-To: <20070206192004.GB6857@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> Message-ID: <45C8EADD.9040905@redhat.com> Joe Orton wrote: > > But I will always resist arbitrary changes which lack technical > justification (or are just plain undesirable); the fact that such > changes are proposed as part of the Review Process does not make them > sacrosanct. Regarding RPM_SOURCE_DIR vs. SOURCEn, doesn't the latter make it simply easier to read and maintain? The former requires you to have file names written in two or more places. Sure it isn't against the rules to use the former, but why not make it cleaner and easier to read? Warren From caillon at redhat.com Tue Feb 6 20:58:20 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 06 Feb 2007 15:58:20 -0500 Subject: Problems with core review In-Reply-To: <45C8EADD.9040905@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <45C8EADD.9040905@redhat.com> Message-ID: <45C8EBEC.504@redhat.com> Warren Togami wrote: > Joe Orton wrote: >> >> But I will always resist arbitrary changes which lack technical >> justification (or are just plain undesirable); the fact that such >> changes are proposed as part of the Review Process does not make them >> sacrosanct. > > Regarding RPM_SOURCE_DIR vs. SOURCEn, doesn't the latter make it simply > easier to read and maintain? The former requires you to have file names > written in two or more places. > > Sure it isn't against the rules to use the former, but why not make it > cleaner and easier to read? Maybe in packages with like two source files. In the gecko packages, it's sort of a pain. I have always loathed the numbering myself in these packages, not only for source files but also for patch files. I suppose I hadn't realized there was an alternative else I'd have probably switched a while ago. From Axel.Thimm at ATrpms.net Tue Feb 6 21:10:20 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 6 Feb 2007 22:10:20 +0100 Subject: Reviews with flags and notification mails Message-ID: <20070206211020.GB31898@neu.nirvana> Hi, RH's bugzilla has some In-Reply-To: magic to allow notification mails to nicely thread up on bugzilla # to allow for easier reading through them. The new flag mechanism does not yet thread the flagging, so one can easily miss "APPROVED" flagging (at least I missed them until I saw them lingering in the mbox a single posts). Could someone fix that? Thanks! -- 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 ville.skytta at iki.fi Tue Feb 6 21:23:15 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 6 Feb 2007 23:23:15 +0200 Subject: Problems with core review In-Reply-To: <45C8EADD.9040905@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <20070206192004.GB6857@redhat.com> <45C8EADD.9040905@redhat.com> Message-ID: <200702062323.16089.ville.skytta@iki.fi> On Tuesday 06 February 2007 22:53, Warren Togami wrote: > Joe Orton wrote: > > But I will always resist arbitrary changes which lack technical > > justification (or are just plain undesirable); the fact that such > > changes are proposed as part of the Review Process does not make them > > sacrosanct. > > Regarding RPM_SOURCE_DIR vs. SOURCEn, doesn't the latter make it simply > easier to read and maintain? The former requires you to have file names > written in two or more places. Indeed, and makes it easier for a build that uses files that are not included in the SRPM to succeed. If the files are versioned, this can happen pretty easily when upgrading the package if one is not careful and forgets to change all occurrences of that file when its name changes due to whatever reason. It'll of course fail in clean build roots so such packages won't sneak into the repos, so the issue is not that critical. FWIW, I think rpmlint's error about use of RPM_SOURCE_DIR is there to remind that files in it should not be modified nor should it be used for build output. From chris.stone at gmail.com Tue Feb 6 21:29:08 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 6 Feb 2007 13:29:08 -0800 Subject: Problems with core review In-Reply-To: <20070206194116.GA6262@yoda.jdub.homelinux.org> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206194116.GA6262@yoda.jdub.homelinux.org> Message-ID: On 2/6/07, Josh Boyer wrote: > On Tue, Feb 06, 2007 at 10:04:07AM -0800, Christopher Stone wrote: > > > > 1) php-pear has a major upgrade (1.5.0) and the current version is > > 1.4.11 in cvs. The 1.5.0 upgrade is going to bring on significant > > changes. I am asking him to make these significant changes _before_ I > > do a formal review. However, he insists that I must do my review on > > the version that is currently in CVS. > > You need to review what he intends to put in F7. If that's not 1.5.0, then > oh well. Asking someone to do a major upgrade just for you to review it > is silly. Especially given that we're driving towards a test2 release! F7 will have 1.5.0 > > > 2) Joe refuses to make benign trivial changes to the spec file. These > > are changes that were suggested by members of the packaging committee, > > for example f13 suggested to use %{SOURCEx} notation when installing > > sources instead of $RPM_SOURCE_DIR. Joe refuses to make simple > > changes like this and would rather bring the issues back up with the > > packaging committee. I think he feels wasting the committe's time is > > more important than ten seconds of his time to make the change. > > If they are only _suggested_ changes, and not _required_ changes, then he > doesn't have to change. Period. As a review, you can suggest so but when > someone says no, then drop it. rpmlint suggested it be fixed, and I even verified it with a packaging committee member and he too suggested it be fixed in the spec. What am I to do? override both what rpmlint and PC memebers are telling me? Joe's refusal to fix this after both rpmlint and f13 suggested he fix it basically forces me to bring the issue up here. I do not have the authority to override both the packaging committee and rpmlint. From jkeating at redhat.com Tue Feb 6 21:31:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 16:31:18 -0500 Subject: Problems with core review In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <20070206194116.GA6262@yoda.jdub.homelinux.org> Message-ID: <200702061631.22944.jkeating@redhat.com> On Tuesday 06 February 2007 16:29, Christopher Stone wrote: > rpmlint suggested it be fixed, and I even verified it with a packaging > committee member and he too suggested it be fixed in the spec. > > What am I to do? override both what rpmlint and PC memebers are > telling me? ?Joe's refusal to fix this after both rpmlint and f13 > suggested he fix it basically forces me to bring the issue up here. ?I > do not have the authority to override both the packaging committee and > rpmlint. These are all SUGGESTIONS. Not REQUIREMENTS. We suggested, it doesn't work well for Joe, therefor he can choose to NOT FOLLOW our suggestions. -- 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 Feb 6 21:59:15 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 6 Feb 2007 15:59:15 -0600 Subject: Problems with core review In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206194116.GA6262@yoda.jdub.homelinux.org> Message-ID: <20070206215915.GC6262@yoda.jdub.homelinux.org> On Tue, Feb 06, 2007 at 01:29:08PM -0800, Christopher Stone wrote: > On 2/6/07, Josh Boyer wrote: > >On Tue, Feb 06, 2007 at 10:04:07AM -0800, Christopher Stone wrote: > >> > >> 1) php-pear has a major upgrade (1.5.0) and the current version is > >> 1.4.11 in cvs. The 1.5.0 upgrade is going to bring on significant > >> changes. I am asking him to make these significant changes _before_ I > >> do a formal review. However, he insists that I must do my review on > >> the version that is currently in CVS. > > > >You need to review what he intends to put in F7. If that's not 1.5.0, then > >oh well. Asking someone to do a major upgrade just for you to review it > >is silly. Especially given that we're driving towards a test2 release! > > F7 will have 1.5.0 I find that very odd. Jesse, any comments on this from a releng point? > >If they are only _suggested_ changes, and not _required_ changes, then he > >doesn't have to change. Period. As a review, you can suggest so but when > >someone says no, then drop it. > > rpmlint suggested it be fixed, and I even verified it with a packaging > committee member and he too suggested it be fixed in the spec. > > What am I to do? override both what rpmlint and PC memebers are > telling me? Joe's refusal to fix this after both rpmlint and f13 > suggested he fix it basically forces me to bring the issue up here. I > do not have the authority to override both the packaging committee and > rpmlint. It's not required. Just move on with life and log it in the bug. It's not something to hold a review up on. josh From jkeating at redhat.com Tue Feb 6 22:23:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 17:23:59 -0500 Subject: Problems with core review In-Reply-To: <20070206215915.GC6262@yoda.jdub.homelinux.org> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <20070206215915.GC6262@yoda.jdub.homelinux.org> Message-ID: <200702061723.59251.jkeating@redhat.com> On Tuesday 06 February 2007 16:59, Josh Boyer wrote: > > F7 will have 1.5.0 > > I find that very odd. ?Jesse, any comments on this from a releng point? *shrug* its before the feature freeze, and if 1.5.0 is actually released from upstream before then, I'm fine with it. We do this with gnome and gnome betas, where the features for the next gnome releases are released upstream earlier in beta form, we include those in the Test release. The "official" gnome release may not actually happen until very near Test3, but by then it isn't any feature change from the beta we shipped to the final bits, just last minute bug fixes. -- 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 Feb 6 22:34:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 17:34:22 -0500 Subject: ACL and sponsorship In-Reply-To: References: <1170730235.1254.163.camel@mccallum.corsepiu.local> <20070206185356.GF29861@nostromo.devel.redhat.com> <20070206192107.GA30933@nostromo.devel.redhat.com> Message-ID: <20070206223422.GE331@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > BN> If the information was available in a programmatic way, sure! > BN> (AFAIK, it's not.) > > The account system certainly knows it. It's not exported to the CVS box, though. Bill From tcallawa at redhat.com Wed Feb 7 00:04:24 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Feb 2007 18:04:24 -0600 Subject: Problems with core review In-Reply-To: <1170794961.3836.8.camel@localhost> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170794961.3836.8.camel@localhost> Message-ID: <1170806664.19237.6.camel@localhost.localdomain> On Tue, 2007-02-06 at 12:49 -0800, Peter Gordon wrote: > On Tue, 2007-02-06 at 20:34 +0000, Joe Orton wrote: > > > Con: it makes [renumbering] Sources a pain, it's harder to use since you > > have to remember numbers not filenames. This number/filename mapping > > trick doesn't scale well as anybody who has maintained spec files with > > more than a handful of patches knows. > > > > I'm sorry but this is absolute hilarity. If you have to remember which > %SOURCEN macro corresponds to which file, then just scroll up in your > favorite editor to the part that lists each Source/Patch file. If these > names aren't descriptive enough, then that's an issue you need to > resolve by renaming to something more appropriate (for example, > "fix-BZ123456-config-error.patch" is a lot nicer than > "fix-stupid-bug.patch"). Indeed. By not using %{SOURCE} macros, you're setting yourself up for pain. Whenever reasonable, use macros. ~spot From dominik at greysector.net Wed Feb 7 00:17:31 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 7 Feb 2007 01:17:31 +0100 Subject: Impending FLAC update warning: rebuilds required In-Reply-To: <883cfe6d0702051758i60833642oaecd4207e5ca3525@mail.gmail.com> References: <883cfe6d0702031735m5f043a59ja1e3b5c8089d98ff@mail.gmail.com> <20070205190352.GA18421@ryvius.pekin.waw.pl> <883cfe6d0702051758i60833642oaecd4207e5ca3525@mail.gmail.com> Message-ID: <20070207001731.GB29173@ryvius.pekin.waw.pl> On Tuesday, 06 February 2007 at 02:58, Michel Salim wrote: > 2007/2/5, Dominik 'Rathann' Mierzejewski : > >> mkvtoolnix > > > >That one is mine. > > > >> muine > >> scummvm > >> stratagus > >> xine-lib > >> xmms-flac > >> > >> If your package is on this list, and the new FLAC does not work with > >> you without further workaround, please follow-up at the Bugzilla > >> entry. I'll ask Matthias if he can provide a test SRPM. > > > >Do you have an updated flac spec somewhere? > > > Matthias has put them up (URL is also at the Bugzilla entry): > http://people.redhat.com/mclasen/flac/ rpmlint complains loudly about them: W: flac-devel summary-ended-with-dot Static libraries and header files from FLAC. W: flac summary-ended-with-dot An encoder/decoder for the Free Lossless Audio Codec. W: flac unversioned-explicit-obsoletes flac-libs W: flac summary-ended-with-dot An encoder/decoder for the Free Lossless Audio Codec. W: flac incoherent-version-in-changelog 1.1.2-27 1.1.3-1.fc7 E: flac obsolete-not-provided flac-libs E: flac obsolete-not-provided xmms-flac mkvtoolnix builds fine against it though. 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 dominik at greysector.net Wed Feb 7 00:24:35 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 7 Feb 2007 01:24:35 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070206183212.GB29861@nostromo.devel.redhat.com> References: <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <20070206002323.GG21605@ryvius.pekin.waw.pl> <20070206183212.GB29861@nostromo.devel.redhat.com> Message-ID: <20070207002435.GC29173@ryvius.pekin.waw.pl> On Tuesday, 06 February 2007 at 19:32, Bill Nottingham wrote: > Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: > > No. It adds a hurdle that wasn't there before. Personally, I'm probably > > going to postpone importing any packages I have queued up until this is > > changed back. What was so wrong with anyone in cvsextras group being able > > to modify owners.list that you had to change it? > > Simple - by allowing any edits, you allow anyone to change the ownership, > and therefore allow/grant access, to packages they don't own. And we had... how many incidents with people making themselves owners of others' packages, exactly? AFAIR the problem was mostly with people forgetting to add themselves to that file after importing a package. I'm not convinced this is a necessary change. 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 jkeating at redhat.com Wed Feb 7 00:34:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 19:34:49 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070207002435.GC29173@ryvius.pekin.waw.pl> References: <45BEC555.8050908@redhat.com> <20070206183212.GB29861@nostromo.devel.redhat.com> <20070207002435.GC29173@ryvius.pekin.waw.pl> Message-ID: <200702061934.49543.jkeating@redhat.com> On Tuesday 06 February 2007 19:24, Dominik 'Rathann' Mierzejewski wrote: > And we had... how many incidents with people making themselves owners > of others' packages, exactly? AFAIR the problem was mostly with people > forgetting to add themselves to that file after importing a package. > > I'm not convinced this is a necessary change. It is not a matter of what HAS been done, it's a matter of what _could_ be done. You don't lock the door to your house because somebody has already broken in, you lock it to prevent somebody from breaking in. Other people HAVE broken into other distributions and caused problems. This is closing a hole and narrowing the potential effect. Nothing stops a rouge user from going through the review process for some innoculous piece of software, just to get CVS access, then changing ownership of say kernel, or gcc, or glibc, building something that will infect users and pushing it out, all because our system was open enough to let them. This is a very real concern, especially with the hype and media coverage the merger is bringing. I'd rather not sheepishly implement security after the fact when we can easily do it before the fact. -- 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 Wed Feb 7 01:35:54 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 6 Feb 2007 19:35:54 -0600 Subject: Problems with core review In-Reply-To: <200702061723.59251.jkeating@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <20070206215915.GC6262@yoda.jdub.homelinux.org> <200702061723.59251.jkeating@redhat.com> Message-ID: <20070207013554.GB8713@yoda.jdub.homelinux.org> On Tue, Feb 06, 2007 at 05:23:59PM -0500, Jesse Keating wrote: > On Tuesday 06 February 2007 16:59, Josh Boyer wrote: > > > F7 will have 1.5.0 > > > > I find that very odd. ?Jesse, any comments on this from a releng point? > > *shrug* its before the feature freeze, and if 1.5.0 is actually released from > upstream before then, I'm fine with it. We do this with gnome and gnome > betas, where the features for the next gnome releases are released upstream > earlier in beta form, we include those in the Test release. The "official" > gnome release may not actually happen until very near Test3, but by then it > isn't any feature change from the beta we shipped to the final bits, just > last minute bug fixes. Ok, my mistake. I was somehow thinking we were already under feature freeze. josh From rc040203 at freenet.de Wed Feb 7 02:05:21 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Feb 2007 03:05:21 +0100 Subject: Problems with core review In-Reply-To: <20070206203404.GC6857@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> Message-ID: <1170813921.21576.66.camel@mccallum.corsepiu.local> On Tue, 2007-02-06 at 20:34 +0000, Joe Orton wrote: > On Tue, Feb 06, 2007 at 11:49:11AM -0800, Christopher Stone wrote: > > Here are the issues in question: > > > > 1) Replace use of $RPM_SOURCE_DIR with %{SOURCEx} > > > > I asked about this in #fedora-extras since I did not understand > > rpmlints Error message. f13 responded by saying you should just use > > %{SOURCEx}. > > > > I agree with f13 on this issue because it is easier to identify in the > > spec file where the source files are used. > > Con: it makes renumering Sources a pain, it's harder to use since you > have to remember numbers not filenames. This number/filename mapping > trick doesn't scale well as anybody who has maintained spec files with > more than a handful of patches knows. > > Insufficient justification for change. > > > 2) Add empty %build section even though its not required > > > > All php-pear packages include an empty %build section and php-pear > > should not be an exception. This was disccussed at length when > > creating the php-pear spec file template. Ville has real world > > examples how this can cause problems. > > What are they, how do they apply to this package? rpm doesn't generate debug-infos if %build is not present. > > Technical reason for changing: rpm is unpredictable with no %build, > > consistency among all pear packages > > It's worked predictably for the history of this package. Only if all those package had been noarch'ed. If not, you surely have broken debug-infos. Ralf From opensource at till.name Wed Feb 7 03:40:50 2007 From: opensource at till.name (Till Maas) Date: Wed, 07 Feb 2007 04:40:50 +0100 Subject: disclaimed ownership of core packages In-Reply-To: <20070206143802.GA4157@yoda.jdub.homelinux.org> References: <20070202161419.20a3bdd5@ludwig-alpha.unil.ch> <20070206143802.GA4157@yoda.jdub.homelinux.org> Message-ID: <200702070440.58268.opensource@till.name> On Tuesday 06 February 2007 15:38, Josh Boyer wrote: > I actually ran into this for a package I'd like to take over myself. > Jeff orphaned jfsutils... so I'll claim it. But now what? After the > review, do I bring it into Extras CVS? In this case, the easiest way may be submitting the package for normal Extras Review and import it into Extras after approval. 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 notting at redhat.com Wed Feb 7 05:01:30 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Feb 2007 00:01:30 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070205235041.d082c497.bugs.michael@gmx.net> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <20070205235041.d082c497.bugs.michael@gmx.net> Message-ID: <20070207050130.GA12725@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > Packages marked as "dead.package" lack the "Makefile", which breaks > cvs-import.sh. There is a patch by me (posted to fesco in June last year) > which I've resent a few days ago, because it has not been applied so far. Applied. Bill From chris.stone at gmail.com Wed Feb 7 05:18:11 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 6 Feb 2007 21:18:11 -0800 Subject: Problems with core review In-Reply-To: <1170813921.21576.66.camel@mccallum.corsepiu.local> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170813921.21576.66.camel@mccallum.corsepiu.local> Message-ID: On 2/6/07, Ralf Corsepius wrote: > On Tue, 2007-02-06 at 20:34 +0000, Joe Orton wrote: > > On Tue, Feb 06, 2007 at 11:49:11AM -0800, Christopher Stone wrote: > > > Here are the issues in question: > > > > > > 1) Replace use of $RPM_SOURCE_DIR with %{SOURCEx} > > > > > > I asked about this in #fedora-extras since I did not understand > > > rpmlints Error message. f13 responded by saying you should just use > > > %{SOURCEx}. > > > > > > I agree with f13 on this issue because it is easier to identify in the > > > spec file where the source files are used. > > > > Con: it makes renumering Sources a pain, it's harder to use since you > > have to remember numbers not filenames. This number/filename mapping > > trick doesn't scale well as anybody who has maintained spec files with > > more than a handful of patches knows. > > > > Insufficient justification for change. > > > > > 2) Add empty %build section even though its not required > > > > > > All php-pear packages include an empty %build section and php-pear > > > should not be an exception. This was disccussed at length when > > > creating the php-pear spec file template. Ville has real world > > > examples how this can cause problems. > > > > What are they, how do they apply to this package? > rpm doesn't generate debug-infos if %build is not present. > > > > Technical reason for changing: rpm is unpredictable with no %build, > > > consistency among all pear packages > > > > It's worked predictably for the history of this package. > Only if all those package had been noarch'ed. > > If not, you surely have broken debug-infos. I brought up the fact that all php-pear packages are noarch, yet this requirement was imposed on all php-pear packages anyway. The php-pear default spec template adds an empty %build section even though I argued against such an addition. Therefore, I do not see why php-pear should be an exception to this rule. Why is it imposed on all other php-pear packages except for php-pear itself? From chris.stone at gmail.com Wed Feb 7 05:34:20 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 6 Feb 2007 21:34:20 -0800 Subject: Problems with core review In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170813921.21576.66.camel@mccallum.corsepiu.local> Message-ID: On 2/6/07, Christopher Stone wrote: > On 2/6/07, Ralf Corsepius wrote: > > On Tue, 2007-02-06 at 20:34 +0000, Joe Orton wrote: > > > On Tue, Feb 06, 2007 at 11:49:11AM -0800, Christopher Stone wrote: > > > > Here are the issues in question: > > > > > > > > 1) Replace use of $RPM_SOURCE_DIR with %{SOURCEx} > > > > > > > > I asked about this in #fedora-extras since I did not understand > > > > rpmlints Error message. f13 responded by saying you should just use > > > > %{SOURCEx}. > > > > > > > > I agree with f13 on this issue because it is easier to identify in the > > > > spec file where the source files are used. > > > > > > Con: it makes renumering Sources a pain, it's harder to use since you > > > have to remember numbers not filenames. This number/filename mapping > > > trick doesn't scale well as anybody who has maintained spec files with > > > more than a handful of patches knows. > > > > > > Insufficient justification for change. > > > > > > > 2) Add empty %build section even though its not required > > > > > > > > All php-pear packages include an empty %build section and php-pear > > > > should not be an exception. This was disccussed at length when > > > > creating the php-pear spec file template. Ville has real world > > > > examples how this can cause problems. > > > > > > What are they, how do they apply to this package? > > rpm doesn't generate debug-infos if %build is not present. > > > > > > Technical reason for changing: rpm is unpredictable with no %build, > > > > consistency among all pear packages > > > > > > It's worked predictably for the history of this package. > > Only if all those package had been noarch'ed. > > > > If not, you surely have broken debug-infos. > > I brought up the fact that all php-pear packages are noarch, yet this > requirement was imposed on all php-pear packages anyway. > > The php-pear default spec template adds an empty %build section even > though I argued against such an addition. > > Therefore, I do not see why php-pear should be an exception to this > rule. Why is it imposed on all other php-pear packages except for > php-pear itself? > It should also be noted, that if rpm can't figure out how to do things correctly with arch specific packages that do not have a %build, then can we really trust rpm to function properly on packages that are noarch? I think this is a valid argument. If the logic inside rpm is so bad that it can't handle things properly without certain tags, then we better be really careful about how we format our spec files. From peter at thecodergeek.com Wed Feb 7 05:50:01 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 06 Feb 2007 21:50:01 -0800 Subject: Problems with core review In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170813921.21576.66.camel@mccallum.corsepiu.local> Message-ID: <1170827401.3692.10.camel@localhost> On Tue, 2007-02-06 at 21:34 -0800, Christopher Stone wrote: > I think this is a valid argument. If the logic inside rpm is so bad > that it can't handle things properly without certain tags, then we > better be really careful about how we format our spec files. Well then instead of worrying about spec files, shouldn't this be fixed in RPM proper, similar to the BuildRoot dilemma? -- 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 Wed Feb 7 05:56:50 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Feb 2007 06:56:50 +0100 Subject: Problems with core review In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170813921.21576.66.camel@mccallum.corsepiu.local> Message-ID: <1170827811.21576.91.camel@mccallum.corsepiu.local> On Tue, 2007-02-06 at 21:34 -0800, Christopher Stone wrote: > On 2/6/07, Christopher Stone wrote: > > On 2/6/07, Ralf Corsepius wrote: > > > On Tue, 2007-02-06 at 20:34 +0000, Joe Orton wrote: > > > > On Tue, Feb 06, 2007 at 11:49:11AM -0800, Christopher Stone wrote: > > > > > Here are the issues in question: > > > > > > > > > > 1) Replace use of $RPM_SOURCE_DIR with %{SOURCEx} > > > > > > > > > > I asked about this in #fedora-extras since I did not understand > > > > > rpmlints Error message. f13 responded by saying you should just use > > > > > %{SOURCEx}. > > > > > > > > > > I agree with f13 on this issue because it is easier to identify in the > > > > > spec file where the source files are used. > > > > > > > > Con: it makes renumering Sources a pain, it's harder to use since you > > > > have to remember numbers not filenames. This number/filename mapping > > > > trick doesn't scale well as anybody who has maintained spec files with > > > > more than a handful of patches knows. > > > > > > > > Insufficient justification for change. > > > > > > > > > 2) Add empty %build section even though its not required > > > > > > > > > > All php-pear packages include an empty %build section and php-pear > > > > > should not be an exception. This was disccussed at length when > > > > > creating the php-pear spec file template. Ville has real world > > > > > examples how this can cause problems. > > > > > > > > What are they, how do they apply to this package? > > > rpm doesn't generate debug-infos if %build is not present. > > > > > > > > Technical reason for changing: rpm is unpredictable with no %build, > > > > > consistency among all pear packages > > > > > > > > It's worked predictably for the history of this package. > > > Only if all those package had been noarch'ed. > > > > > > If not, you surely have broken debug-infos. > > > > I brought up the fact that all php-pear packages are noarch, yet this > > requirement was imposed on all php-pear packages anyway. > > > > The php-pear default spec template adds an empty %build section even > > though I argued against such an addition. > > > > Therefore, I do not see why php-pear should be an exception to this > > rule. Why is it imposed on all other php-pear packages except for > > php-pear itself? > > > > It should also be noted, that if rpm can't figure out how to do things > correctly with arch specific packages that do not have a %build, then > can we really trust rpm to function properly on packages that are > noarch? There isn't much I can add to this ;) I've brought up the %build/debug-info bug several times before (IIRC, I even bugzilla'ed it), as well as the general unreliability of debug-info generation, but so far, I have seen no indication of improvement - Instead, people preferred to shoot at me. > I think this is a valid argument. If the logic inside rpm is so bad > that it can't handle things properly without certain tags, then we > better be really careful about how we format our spec files. Well, I am not sure about this - Instead of playing with symptoms (missing %build) we should aim at getting the real causes fixed (read: redhat-rpm-config). Ralf From sander at hoentjen.eu Wed Feb 7 07:16:49 2007 From: sander at hoentjen.eu (Sander Hoentjen) Date: Wed, 07 Feb 2007 08:16:49 +0100 Subject: Tcl packaging guidelines In-Reply-To: <45C8CC14.1090707@kobold.org> References: <45C8CC14.1090707@kobold.org> Message-ID: <1170832610.2933.13.camel@peecee.hoentjen.eu> On Tue, 2007-02-06 at 10:42 -0800, Michael Thomas wrote: > Following the precedent set by perl, python, and ruby, I've drafted a > set of proposed guidelines for Tcl packages. > > http://fedoraproject.org/wiki/MichaelThomas/Tcl > > The main motivation behind these guidelines is > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226893 > > These proposed guidelines will require changes to most of the existing > Tcl extensions in Fedora, as the installation directory for > arch-specific packages will need to be changed from %{_libdir} to > %{_libdir/tcl8.x. Since Tcl was recently upgraded from 8.4 to 8.5a5 in > rawhide, this seemed like a suitable time to make such changes. > > I'd like to get any feedback on this proposal before I submit it to the > Fedora packaging committee, hopefully in time so that the changes can be > made before the F7 release. > I cannot give anymore feedback then +1. I hope this Proposal will be accepted, it is something I missed when starting to package tcl packages. Sander From j.w.r.degoede at hhs.nl Wed Feb 7 08:08:42 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Feb 2007 09:08:42 +0100 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <45C7C0A3.3010808@redhat.com> References: <45C7C0A3.3010808@redhat.com> Message-ID: <45C9890A.6050002@hhs.nl> Warren Togami wrote: First of all let me say that I'm very happy that this process is still being worked on / streamlined! > Raw notes... your comments would be very much appreciated. > > Key Changes from Previous Procedures > ==================================== > 1) Assigned to pointer indicates that there is a reviewer. Assigned > pointer to nobody means there is no reviewer yet. > 2) BLANK means review not requested. ? means review requested. This > makes it easier to query, because querying for BLANK is a bit inefficient. > (Good idea, bad idea?) > 3) NEEDINFO is used to avoid changing the Assigned pointer when fixes > are needed. > 4) Assigned pointer DOES NOT CHANGE during and after the review. > > Fedora Review Flag States > ========================= > fedora-review BLANK (Not under review at all!) > fedora-review? (I want a review) > fedora-review- (rejected, needs work, set NEEDINFO to person who needs > to fix it) > fedora-review+ (APPROVED) > Why all the ping-ponging between ? and - during the review and all the ping-ponging between ASSIGNED and NEEDINFO. In FE we've never done this ping-ponging and we've never felt a need to introduce this IMHO this are just unnecesarry mouse clicks. NEEDINFO and fedora-review- may be a good idea if either the person requesting the review or the reviewer are slow to respond. But in my experience there is a bit of quick discussion between the two and the whole review process is finished with a day or two (for normal packages) I really feel that all this changing of flags and status is just unnecesarry mouse clicks. > Assigned Pointer > ================ > (Note, Assigned pointer is different from the ASSIGNED state.) > - Assigned pointer to nobody at fedoraproject.org if no reviewer yet. > - Assigned pointer to reviewer, during and after review. > - Set Assigned pointer back to nobody if reviewer gave up. > Good. > Bugzilla States > =============== > NEW ASSIGNED REOPENED (rather meaningless distinction?) > NEEDINFO (to owner or somebody who needs to act to fix) > MODIFIED (seems to be fixed, please test it) > CLOSED (ticket is done) > > Process > ======= > 1. Review Request is filed. > 2. Set fedora-review? flag to signify that the ticket is ready for review. Shouldn't the review request form also set this flag for us, I see no gain in having todo this manually. > 3. Reviewer takes bug, Assigned pointer set to self. > 4. If APPROVED, fedora-review+. > 5. If rejected, fedora-review- and NEEDINFO owner to fix it. What is rejected? See above, often there are a couple of small must FIX / should fix items, which usually get fixed really soon. > 6. If fedora-review- and owner fixes something, set back to ? to request > review again. Ping-pong-ping-pong, /me no like > 7. After fedora-review+, initiate the fedora-cvs request procedure. > 8. After fedora-cvs, checkin, build, and set to CLOSED. > > Drawbacks > ========= > Since the mass review tickets were not filed by the package owners, it > is less than obvious. Most reviews however are filed by owners, so this > is less of a problem beyond this mass review. > to much ping-pong > Other Possibilities > =================== > fedora-review? could also be used on any other Fedora bug when a > horrible mess is found in an existing package, and attention for a > re-review would be desired to fix it. (Good idea, bad idea?) > In general I like being able to say this is a mess, this needs a re-review, but we need some rules for this, like whom may initiate this? > Possible Process Optimizations > ============================== > (These might possibly help... although they might require hacks in > Bugzilla's code, so we only request these optimizations only if they > would make a huge positive difference. Your thoughts?) > 1. Changing fedora-review in any way should auto-CC yourself automatically. Not necessary with the new assigned rules, the review requester is the reporter and thus get mails, the reviewer is the assignee and thus gets mail. > 2. Changing fedora-review to + should auto-set Assigned pointer to self. > ? You write above "Assigned pointer to reviewer, during and after review." notice the and after, thus this also isn't needed. Regards, Hans From j.w.r.degoede at hhs.nl Wed Feb 7 08:42:15 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Feb 2007 09:42:15 +0100 Subject: Theoretical: CVS Admin with Flags In-Reply-To: <45C7B3A2.3070306@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45C7B3A2.3070306@redhat.com> Message-ID: <45C990E7.5040307@hhs.nl> Warren Togami wrote: > Bill Nottingham wrote: >> >> What's the failure point here now? >> >> As for the import process, we can change how that works - instead >> of CVSSyncNeeded, for example, we could just, after APPROVED, assign >> the review bug to the CVS admins to do the magic, at which point they >> assign it back to the owner to do the initial import/build. Is this >> a better interface for users? >> > > Folks seem to be confused by the ASSIGNED bouncing around. Did I misread your last version (top post of this thread) isn't the ASSIGNED bouncing around no more in this version? ? I am > currently thinking about potential ways to improve the review process to > remove this confusion. A big legitimate problem with changing ASSIGNED > is that it must be done manually, which is too easy to not happen > because it is not obvious. > > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded > I made some changes to this page in an attempt to simplify this > temporary process until we have the PackageDB online. Unfortunately, I > suspect even this simplified process is too complicated. > 1. Request new package and branch. > 2. Wait until somebody creates empty directories and edits owners.list. > 3. Owner checks stuff in and builds. > > Perhaps a better idea than setting ASSIGNED to the CVS admins is to have > a fedora-cvs flag? Theoretical process: > > 1) Review is complete, fedora-review+ > 2) Owner writes in the Bugzilla comment something like: > > FC-5 FC-6 foopackage bobjoe bobjoebugzilla at gmail.com > 3) Set fedora-cvs flag > 4) CVS Admins get e-mail about fedora-cvs flag. All context of the > review is within the bug itself. Admin creates CVS directories and sets > owner. Removes fedora-cvs flag. (This is especially nice because CVS > admin queue can be seen by a bugzilla query.) > 5) Owner checks in and builds. > > Effectively, this fedora-cvs flag eliminates the need for CVSSyncNeeded > entirely. You could also use the fedora-cvs flag with explicitly > instructions within any bug to do special requests, like: > "Please remove audacious-itouch. We made some mistake. Blah blah." > > Thoughts? > I really dislike needing to ask a CVS admin in for anything, IMHO this needing a CVS-admin for initial import is a serious regression, can't we think of some other way to get this fixed? I never liked the manual requesting of CVS-branches and now things have been made worse. Regards, Hans From j.w.r.degoede at hhs.nl Wed Feb 7 09:03:47 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Feb 2007 10:03:47 +0100 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <20070206091257.63aa94bf@ludwig-alpha.unil.ch> References: <45C7C0A3.3010808@redhat.com> <20070206091257.63aa94bf@ludwig-alpha.unil.ch> Message-ID: <45C995F3.2070304@hhs.nl> Christian Iseli wrote: > On Mon, 05 Feb 2007 18:41:23 -0500, Warren Togami wrote: >> 2) BLANK means review not requested. ? means review requested. This >> makes it easier to query, because querying for BLANK is a bit inefficient. >> (Good idea, bad idea?) > > bad idea IMHO. Filing the ticket *does* mean I want a review. I much > prefer nirik's suggestion: > blank -> I want a reviewer > ? -> normal review under way (can use NEEDINFO if wanted) > + -> ACCEPT > - -> something bad happened (stalled review, bad license, ...) > > The rest sounds fine. > +1 Although I'm not sure about the BLANK vs ? difference, don't we already have NEW versus ASSIGNED for this? Regards, Hans From j.w.r.degoede at hhs.nl Wed Feb 7 09:09:54 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 07 Feb 2007 10:09:54 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <45C6EAA8.7040401@hhs.nl> Message-ID: <45C99762.3030505@hhs.nl> Jason L Tibbitts III wrote: >>>>>> "HdG" == Hans de Goede writes: > > HdG> I fully agree this new process is a PITA. The old process worked > HdG> very well, what problems where there with the old process that > HdG> this new process is trying to fix? > > The fact that bugzilla creaks, groans and ultimately dies when faced > with a blocker bug having 1500 dependencies. The previous system just > doesn't scale to all of the core review stuff. > That much I understand, but why then not only change blocker bug to flags and leave the rest as is? Its the ASSIGNEE bouncing, ASSIGNED <-> NEEDINFO ping-pong in the current process that annoys and confuses people. > What's annoying is that people whining because something has changed. > We've tried something new because we needed to. The whole thing is a > work in progress. Deal. If we never try anything new, we'll never do > worse but we also won't ever do any better. > You should know me long enough to know that I'm not a winer, also lets please not make this personal. I've started screaming loudly about this, because I don't like it and have heard from many other people that they don't like it either (Chris Stone, Ralph Corsepius, Michael Schwendt to name a few). The new process annoys and confuses people and makes the barrier to entry for new packages and for new maintainers higher, which is a BAD thing. Let me add to that that I'm very happy to see that as a result of my (and others) "wining" the process is being refined for the better. Also if the people making the changes want to avoid such "wining" in the future, they should think things through and properly communicate them before implementing them. Regards, Hans From mtasaka at ioa.s.u-tokyo.ac.jp Wed Feb 7 09:24:43 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 07 Feb 2007 18:24:43 +0900 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <45C9890A.6050002@hhs.nl> References: <45C7C0A3.3010808@redhat.com> <45C9890A.6050002@hhs.nl> Message-ID: <45C99ADB.8050009@ioa.s.u-tokyo.ac.jp> Hans de Goede wrote: > Warren Togami wrote: >> 3) NEEDINFO is used to avoid changing the Assigned pointer when fixes >> are needed. >> >> Fedora Review Flag States >> ========================= >> fedora-review BLANK (Not under review at all!) >> fedora-review? (I want a review) >> fedora-review- (rejected, needs work, set NEEDINFO to person who needs >> to fix it) >> fedora-review+ (APPROVED) >> > > Why all the ping-ponging between ? and - during the review and all the > ping-ponging between ASSIGNED and NEEDINFO. In FE we've never done this > ping-ponging and we've never felt a need to introduce this IMHO this are > just unnecesarry mouse clicks. NEEDINFO and fedora-review- may be a good > idea if either the person requesting the review or the reviewer are slow > to respond. But in my experience there is a bit of quick discussion > between the two and the whole review process is finished with a day or > two (for normal packages) I really feel that all this changing of flags > and status is just unnecesarry mouse clicks. +1 NEEDINFO or fedora-review- should be used when the new information from the submitter or the reviewer who should respond is lacking, and currently I use NEEDINFO status for this purpose. For review request which is rather active and in which the submitter and the reviewer are communitating well, NEEDINFO or fedora-review is not needed. Usually I set the status as NEEDINFO when the new information lacks for one week. Mamoru From dan at danny.cz Wed Feb 7 10:57:38 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 07 Feb 2007 11:57:38 +0100 Subject: Impending FLAC update warning: rebuilds required In-Reply-To: <883cfe6d0702051758i60833642oaecd4207e5ca3525@mail.gmail.com> References: <883cfe6d0702031735m5f043a59ja1e3b5c8089d98ff@mail.gmail.com> <20070205190352.GA18421@ryvius.pekin.waw.pl> <883cfe6d0702051758i60833642oaecd4207e5ca3525@mail.gmail.com> Message-ID: <1170845858.3660.9.camel@eagle.danny.cz> > > Do you have an updated flac spec somewhere? > > > Matthias has put them up (URL is also at the Bugzilla entry): > http://people.redhat.com/mclasen/flac/ > > Regards, > I was going to do Merge Review for FLAC, should I set the owner to Matthias? Current owner in the Bugzilla is "davidz at redhat.com". Also having the new version in the CVS would be nice. Dan From mmaslano at redhat.com Wed Feb 7 11:25:04 2007 From: mmaslano at redhat.com (Marcela Maslanova) Date: Wed, 07 Feb 2007 12:25:04 +0100 Subject: Tcl packaging guidelines In-Reply-To: <1170832610.2933.13.camel@peecee.hoentjen.eu> References: <45C8CC14.1090707@kobold.org> <1170832610.2933.13.camel@peecee.hoentjen.eu> Message-ID: <45C9B710.9080707@redhat.com> This problem is already discussed on fedora-devel and they are worried about "alpha" version. I think we should use this version, because it could take a long time, when they made a new version. Especially they spoke about blt package, which is not ready. I think we should start the changes now, because no one will be doing changes in paths etc. when he's not forced to. Marcela Maslanova From bugs.michael at gmx.net Wed Feb 7 11:37:00 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 7 Feb 2007 12:37:00 +0100 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <45C99ADB.8050009@ioa.s.u-tokyo.ac.jp> References: <45C7C0A3.3010808@redhat.com> <45C9890A.6050002@hhs.nl> <45C99ADB.8050009@ioa.s.u-tokyo.ac.jp> Message-ID: <20070207123700.6ebe9947.bugs.michael@gmx.net> On Wed, 07 Feb 2007 18:24:43 +0900, Mamoru Tasaka wrote: > NEEDINFO or fedora-review- should be used when the new information from > the submitter or the reviewer who should respond is lacking, and currently > I use NEEDINFO status for this purpose. For review request which is rather > active and in which the submitter and the reviewer are communitating well, > NEEDINFO or fedora-review is not needed. Usually I set the status as > NEEDINFO when the new information lacks for one week. The packages from "Merge Review" are included in the distribution already. Some pkg maintainers apply changes within internal fedora cvs shortly after a reviewer had posted comments. Ongoing review activity doesn't block the maintainers from building their packages and from publishing them. There is no need to "reject" anything temporarily with the help of special flags intead of with your own words. Unless you find any justification to pull a package from the distribution, there is absolutely no need to increase the bureaucracy inside bugzilla and to lower the s/n ratio in bugzilla mails. Let's continue with using bugzilla for simple communication between packager and reviewer(s) without the requirement to turn too many knobs. Only the flag for the approval makes sense IMO. For reminders and occasional ticket status, stuff like NEEDINFO is enough. WRT new contributors: The more bureaucracy, the more questions are raised and require even additional communication outside bugzilla. New contributors and silent observers shake their head in disbelieve, because we make something more complex than it needs to be. Moving the cvs branch requests from the Wiki into bugzilla tickets is a good idea. From rc040203 at freenet.de Wed Feb 7 12:18:49 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Feb 2007 13:18:49 +0100 Subject: RFC: Review with Flags (Version 3) In-Reply-To: <20070207123700.6ebe9947.bugs.michael@gmx.net> References: <45C7C0A3.3010808@redhat.com> <45C9890A.6050002@hhs.nl> <45C99ADB.8050009@ioa.s.u-tokyo.ac.jp> <20070207123700.6ebe9947.bugs.michael@gmx.net> Message-ID: <1170850729.21576.120.camel@mccallum.corsepiu.local> On Wed, 2007-02-07 at 12:37 +0100, Michael Schwendt wrote: > On Wed, 07 Feb 2007 18:24:43 +0900, Mamoru Tasaka wrote: > Let's continue with using bugzilla for simple communication between > packager and reviewer(s) without the requirement to turn too many > knobs. Only the flag for the approval makes sense IMO. For reminders and > occasional ticket status, stuff like NEEDINFO is enough. ACK. Did somebody notice that many (all?) "fedora-review granted" mails are sent twice? Ralf From roozbeh at farsiweb.info Wed Feb 7 12:54:37 2007 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Wed, 07 Feb 2007 16:24:37 +0330 Subject: Process Change: Package Reviews with Flags In-Reply-To: <200702061934.49543.jkeating@redhat.com> References: <45BEC555.8050908@redhat.com> <20070206183212.GB29861@nostromo.devel.redhat.com> <20070207002435.GC29173@ryvius.pekin.waw.pl> <200702061934.49543.jkeating@redhat.com> Message-ID: <1170852877.3313.34.camel@shalil.farsiweb.info> On Tue, 2007-02-06 at 19:34 -0500, Jesse Keating wrote: > It is not a matter of what HAS been done, it's a matter of what _could_ be > done. You don't lock the door to your house because somebody has already > broken in, you lock it to prevent somebody from breaking in. Well, don't get me wrong, but that is exactly what some people like me do. We don't put locks somewhere unless it's really necessary (I highly recommend the Canadian unlocked door part of the movie Bowling for Columbine, to see how these people who don't lock their door think). This is a way of life, and a way of thinking about life. We like to think that there are not many bad people: otherwise, we turn into freaks and will fear everybody. Let me put it another way. If the United States has never attacked your country, may be they never will? Why develop atomic capabilities? Really, why? Of course one can be on the very cautious side and develop the atomic capabilities ("for peaceful purposes only", and who is to deny that defending one's country is not a peaceful purpose). But we hippie types prefer to assume that the US will not attack us and we can actually live better with that assumption on our minds. (Please bare with my analogies.) > Other people HAVE broken into other distributions and caused problems. That of course is a very good reason to worry and then add locks. With my example, having seen that the US actually attacked Iraq for no reasonable reason, one can also assume that the same will happen to Iran if we let that happen. But still, people like me prefer to think "Oh, but Iran is different from Iraq!" (and Fedora from all the guys who were attacked, for all the reasons there may be, like having better and more security-minded system administrators). These rants are of course relevant only because I was the person whose laptop with the SSH keys was stolen, which could theoretically be used to find a way into the Extras system. The keys were of course password protected and I reported the situation to Fedora people as soon as possible on IRC, by email, and every other way I thought before a brute force could be used to find the passwords, but if we want to think about all the possible scenarios, a targeted attack could even have used my collaboration. Theoretically, someone may still use physical force on me and get me to type my password and insert whatever code he sees appropriate where he wishes. Do I value the security of Fedora users more than my life or my family's? Definitely not! Roozbeh From jkeating at redhat.com Wed Feb 7 14:47:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 09:47:25 -0500 Subject: Theoretical: CVS Admin with Flags In-Reply-To: <45C990E7.5040307@hhs.nl> References: <45BE7342.1070005@redhat.com> <45C7B3A2.3070306@redhat.com> <45C990E7.5040307@hhs.nl> Message-ID: <200702070947.25673.jkeating@redhat.com> On Wednesday 07 February 2007 03:42, Hans de Goede wrote: > I really dislike needing to ask a CVS admin in for anything, IMHO this > needing a CVS-admin for initial import is a serious regression, can't we > think of some other way to get this fixed? I never liked the manual > requesting of CVS-branches and now things have been made worse. You're going to need _some_ sort of admin interaction before you can build your package for any collection. The package has to be added to the build database, and that requires some level of admin task. If that task is rolled into preparing the CVS tree for the import of your package, then all the better. -- 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 Feb 7 14:51:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 09:51:04 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <1170852877.3313.34.camel@shalil.farsiweb.info> References: <45BEC555.8050908@redhat.com> <200702061934.49543.jkeating@redhat.com> <1170852877.3313.34.camel@shalil.farsiweb.info> Message-ID: <200702070951.04877.jkeating@redhat.com> On Wednesday 07 February 2007 07:54, Roozbeh Pournader wrote: > These rants are of course relevant only because I was the person whose > laptop with the SSH keys was stolen, which could theoretically be used > to find a way into the Extras system. The keys were of course password > protected and I reported the situation to Fedora people as soon as > possible on IRC, by email, and every other way I thought before a brute > force could be used to find the passwords, but if we want to think about > all the possible scenarios, a targeted attack could even have used my > collaboration. > > Theoretically, someone may still use physical force on me and get me to > type my password and insert whatever code he sees appropriate where he > wishes. Do I value the security of Fedora users more than my life or my > family's? Definitely not! it is not so much about somebody stealing your account, it's about somebody going through the process to create their _own_ account. Once that has been done ( and we keep wanting to LOWER the barrier for this!! ), if there are no barriers in place, that person can now run roughshod all over all the packages, making any changes they want, building anything they want, causing automated pushes to push out whatever they built, leading to people grabbing packages and getting rooted, or even worse, insert some small thing in a package that gets pulled into most buildroots that will further taint any more builds. Could be hard to detect until it is far far too late. With proper barriers in place, the most damage a rouge user can do is to their own package, or to any packages foolishly left wide open. -- 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 Wed Feb 7 15:08:15 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 7 Feb 2007 16:08:15 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <200702070951.04877.jkeating@redhat.com> References: <45BEC555.8050908@redhat.com> <200702061934.49543.jkeating@redhat.com> <1170852877.3313.34.camel@shalil.farsiweb.info> <200702070951.04877.jkeating@redhat.com> Message-ID: <20070207150815.GB2667@free.fr> On Wed, Feb 07, 2007 at 09:51:04AM -0500, Jesse Keating wrote: > > going through the process to create their _own_ account. Once that has been > done ( and we keep wanting to LOWER the barrier for this!! ), if there are no I don't think we should lower the barrier. On the contrary, I think that we should be very cautious when sponsoring people -- although I don't think that the main reason why we should be cautious is security, but rather long-term involvment and the burden a contributor leave behind when leaving. Also we should always try to be able to identify the real person behind the fedora contributor. That way the contributor may be blamed in case of bad things done on purpose. > barriers in place, that person can now run roughshod all over all the > packages, making any changes they want, building anything they want, causing > automated pushes to push out whatever they built, leading to people grabbing > packages and getting rooted, or even worse, insert some small thing in a > package that gets pulled into most buildroots that will further taint any > more builds. Could be hard to detect until it is far far too late. Of course it will always be hard to check everything, but currently (and for extras, with core it may not be possible anymore) it is possible to keep an eye on the cvs commits, and on the build report for a range of packages we are interested in and verify that everything is right. (as a side note, I think that what is missing is a check of the checksum against what can be downloaded from the net, for packages that have a real Source on the net). > With > proper barriers in place, the most damage a rouge user can do is to their own > package, or to any packages foolishly left wide open. I don't like "foolishly". There are packages that have reasons to be closed, especially those that are frequently in the buildroot, there are also packages that don't have that much security requirements, or a maintainer reactive enough to track everything that happens to the package. Closing packages also has a cost. -- Pat From dominik at greysector.net Wed Feb 7 16:04:49 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 7 Feb 2007 17:04:49 +0100 Subject: Theoretical: CVS Admin with Flags In-Reply-To: <200702070947.25673.jkeating@redhat.com> References: <45BE7342.1070005@redhat.com> <45C7B3A2.3070306@redhat.com> <45C990E7.5040307@hhs.nl> <200702070947.25673.jkeating@redhat.com> Message-ID: <20070207160449.GB14694@ryvius.pekin.waw.pl> On Wednesday, 07 February 2007 at 15:47, Jesse Keating wrote: > On Wednesday 07 February 2007 03:42, Hans de Goede wrote: > > I really dislike needing to ask a CVS admin in for anything, IMHO this > > needing a CVS-admin for initial import is a serious regression, can't we > > think of some other way to get this fixed? I never liked the manual > > requesting of CVS-branches and now things have been made worse. > > You're going to need _some_ sort of admin interaction before you can build > your package for any collection. You didn't before. Granted, it was only for devel, but still, it was easy and convenient. > The package has to be added to the build database, and that requires some > level of admin task. If that task is rolled into preparing the CVS tree > for the import of your package, then all the better. Can we please keep things no more complicated than they were? Initial import into devel should not require any admin interaction. If it does, why do we need sponsorship? Getting a contributor account was difficult enough, I don't want to jump through hoops with every new package! 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 dominik at greysector.net Wed Feb 7 16:12:34 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 7 Feb 2007 17:12:34 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <200702070951.04877.jkeating@redhat.com> References: <45BEC555.8050908@redhat.com> <200702061934.49543.jkeating@redhat.com> <1170852877.3313.34.camel@shalil.farsiweb.info> <200702070951.04877.jkeating@redhat.com> Message-ID: <20070207161234.GC14694@ryvius.pekin.waw.pl> On Wednesday, 07 February 2007 at 15:51, Jesse Keating wrote: > On Wednesday 07 February 2007 07:54, Roozbeh Pournader wrote: > > These rants are of course relevant only because I was the person whose > > laptop with the SSH keys was stolen, which could theoretically be used > > to find a way into the Extras system. The keys were of course password > > protected and I reported the situation to Fedora people as soon as > > possible on IRC, by email, and every other way I thought before a brute > > force could be used to find the passwords, but if we want to think about > > all the possible scenarios, a targeted attack could even have used my > > collaboration. > > > > Theoretically, someone may still use physical force on me and get me to > > type my password and insert whatever code he sees appropriate where he > > wishes. Do I value the security of Fedora users more than my life or my > > family's? Definitely not! > > it is not so much about somebody stealing your account, it's about somebody > going through the process to create their _own_ account. Once that has been > done ( and we keep wanting to LOWER the barrier for this!! ), if there are no > barriers in place, that person can now run roughshod all over all the > packages, making any changes they want, building anything they want, causing > automated pushes to push out whatever they built, leading to people grabbing > packages and getting rooted, That won't happen THAT easily. Isn't the sign-and-push process manual? Aren't the people who handle it supposed to check what they sign? > or even worse, insert some small thing in a package that gets pulled into > most buildroots that will further taint any more builds. Could be hard > to detect until it is far far too late. It would be stopped at the sign-and-push stage at worst. I'm sure there are many eyes following the cvs commits list. It would be spotted quite fast IMHO. > With proper barriers in place, > the most damage a rouge user can do is to their own > package, or to any packages foolishly left wide open. I don't really mind the ACLs as much as I do mind having to go through another approval (for CVS import) after my package has ALREADY been APPROVED. 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 dominik at greysector.net Wed Feb 7 16:13:42 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 7 Feb 2007 17:13:42 +0100 Subject: Theoretical: CVS Admin with Flags In-Reply-To: <20070207160449.GB14694@ryvius.pekin.waw.pl> References: <45BE7342.1070005@redhat.com> <45C7B3A2.3070306@redhat.com> <45C990E7.5040307@hhs.nl> <200702070947.25673.jkeating@redhat.com> <20070207160449.GB14694@ryvius.pekin.waw.pl> Message-ID: <20070207161342.GD14694@ryvius.pekin.waw.pl> On Wednesday, 07 February 2007 at 17:04, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 07 February 2007 at 15:47, Jesse Keating wrote: > > On Wednesday 07 February 2007 03:42, Hans de Goede wrote: > > > I really dislike needing to ask a CVS admin in for anything, IMHO this > > > needing a CVS-admin for initial import is a serious regression, can't we > > > think of some other way to get this fixed? I never liked the manual > > > requesting of CVS-branches and now things have been made worse. > > > > You're going to need _some_ sort of admin interaction before you can build > > your package for any collection. > > You didn't before. Granted, it was only for devel, but still, it was easy and > convenient. > > > The package has to be added to the build database, and that requires some > > level of admin task. If that task is rolled into preparing the CVS tree > > for the import of your package, then all the better. > > Can we please keep things no more complicated than they were? Initial import > into devel should not require any admin interaction. If it does, why do we > need sponsorship? And review process. > Getting a contributor account was difficult enough, I don't > want to jump through hoops with every new package! After it's already approved, I should've added. 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 tibbs at math.uh.edu Wed Feb 7 16:17:48 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Feb 2007 10:17:48 -0600 Subject: Tcl packaging guidelines In-Reply-To: <45C8CC14.1090707@kobold.org> References: <45C8CC14.1090707@kobold.org> Message-ID: >>>>> "MT" == Michael Thomas writes: MT> Following the precedent set by perl, python, and ruby, I've MT> drafted a set of proposed guidelines for Tcl packages. MT> http://fedoraproject.org/wiki/MichaelThomas/Tcl After a couple of reads I'll say that to me these seem mostly sane and it seems you've done a lot of work, but I know FA about Tcl so I really can't really comment on many of the issues. I'm concerned about how disruptive these are. If every package is going to need to be changed then we really need comments from as many people as possible who are involved with tcl packaging. One concern I do have is the naming guidelines; why not adopt a "tcl-" prefix universally, at least for new packages? - J< From pertusus at free.fr Wed Feb 7 16:18:18 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 7 Feb 2007 17:18:18 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070207161234.GC14694@ryvius.pekin.waw.pl> References: <45BEC555.8050908@redhat.com> <200702061934.49543.jkeating@redhat.com> <1170852877.3313.34.camel@shalil.farsiweb.info> <200702070951.04877.jkeating@redhat.com> <20070207161234.GC14694@ryvius.pekin.waw.pl> Message-ID: <20070207161818.GD2667@free.fr> On Wed, Feb 07, 2007 at 05:12:34PM +0100, Dominik 'Rathann' Mierzejewski wrote: > > That won't happen THAT easily. Isn't the sign-and-push process manual? > Aren't the people who handle it supposed to check what they sign? Although I agree that there are ways to find that the package has been modified, I am not convinced that the fact that sign-and-push is manual is of any help. Indeed I don't think that people doing the sign-and-push can check what they push, it's just too much work. They can be notified, however, that a package has been compromised and remove it from push. > It would be stopped at the sign-and-push stage at worst. I'm sure there are > many eyes following the cvs commits list. It would be spotted quite fast > IMHO. Agreed. And if it is not the case it is what should be corrected. -- Pat From paul at city-fan.org Wed Feb 7 16:27:36 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 07 Feb 2007 16:27:36 +0000 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070207161234.GC14694@ryvius.pekin.waw.pl> References: <45BEC555.8050908@redhat.com> <200702061934.49543.jkeating@redhat.com> <1170852877.3313.34.camel@shalil.farsiweb.info> <200702070951.04877.jkeating@redhat.com> <20070207161234.GC14694@ryvius.pekin.waw.pl> Message-ID: <45C9FDF8.8000408@city-fan.org> Dominik 'Rathann' Mierzejewski wrote: > It would be stopped at the sign-and-push stage at worst. I'm sure there are > many eyes following the cvs commits list. You mean more than just Ralf? I think there are very few people that read most of the cvs commits list (i.e. more than their own packages and any they're specifically interested in). Paul. From pertusus at free.fr Wed Feb 7 16:33:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 7 Feb 2007 17:33:00 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C9FDF8.8000408@city-fan.org> References: <45BEC555.8050908@redhat.com> <200702061934.49543.jkeating@redhat.com> <1170852877.3313.34.camel@shalil.farsiweb.info> <200702070951.04877.jkeating@redhat.com> <20070207161234.GC14694@ryvius.pekin.waw.pl> <45C9FDF8.8000408@city-fan.org> Message-ID: <20070207163300.GE2667@free.fr> On Wed, Feb 07, 2007 at 04:27:36PM +0000, Paul Howarth wrote: > Dominik 'Rathann' Mierzejewski wrote: > >It would be stopped at the sign-and-push stage at worst. I'm sure there are > >many eyes following the cvs commits list. > > You mean more than just Ralf? I think there are very few people that > read most of the cvs commits list (i.e. more than their own packages and > any they're specifically interested in). As long as they read what happens for their own packages things are right (with regard with security...). -- Pat From a.badger at gmail.com Wed Feb 7 16:46:37 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 07 Feb 2007 08:46:37 -0800 Subject: Tcl packaging guidelines In-Reply-To: <45C8CC14.1090707@kobold.org> References: <45C8CC14.1090707@kobold.org> Message-ID: <1170866797.4306.53.camel@localhost.localdomain> On Tue, 2007-02-06 at 10:42 -0800, Michael Thomas wrote: > Following the precedent set by perl, python, and ruby, I've drafted a > set of proposed guidelines for Tcl packages. > Great! > http://fedoraproject.org/wiki/MichaelThomas/Tcl > > The main motivation behind these guidelines is > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226893 > The changes to enable this look sensible to me. > These proposed guidelines will require changes to most of the > existing > Tcl extensions in Fedora, as the installation directory for > arch-specific packages will need to be changed from %{_libdir} to > %{_libdir/tcl8.x. Since Tcl was recently upgraded from 8.4 to 8.5a5 > in > rawhide, this seemed like a suitable time to make such changes. > > I'd like to get any feedback on this proposal before I submit it to > the > Fedora packaging committee, hopefully in time so that the changes can > be > made before the F7 release. I'm not a tcl/tk user so this comment is based on other guidelines rather than the specifics of tcl/tk: ''' == Naming Conventions == It is common for Tcl applications and extensions to begin with a 'tcl' or 'tk' prefix in the upstream name. Fedora Tcl packages should follow this convention. If the upstream name does not contain the 'tcl' or 'tk' prefix, then it is only necessary to add one if the upstream name is inappropriately generic. For example, the 'thread' extension to Tcl is named 'thread' upstream, but is named 'tclthread' in Fedora. The upstream name for the 'bwidget' extension is uncommon enough that it does not need to contain the 'tcl' or 'tk' prefix in the Fedora package name. ''' * Other languages use $LANGUAGE-$MODULE naming. * All modules in perl, ruby, and php are using the $LANGUAGE- prefix, there has been talk of removing the python exception (ie: having python-pygpgme instead of pygpgme) as having all modules use $LANGUAGE-$MODULE makes it easier for endusers to find modules written for the language they are writing their program in. So I'd propose: * For modules, tcl-thread and tcl-bwidget. Possibly tcl-tk but someone with more experience with tcl/tk will have to tell me if that makes sense. Applications do not need to have the language prefix as users of the application do not need to know what language it is written in. -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 bugs.michael at gmx.net Wed Feb 7 17:51:34 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 7 Feb 2007 18:51:34 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070207161234.GC14694@ryvius.pekin.waw.pl> References: <45BEC555.8050908@redhat.com> <200702061934.49543.jkeating@redhat.com> <1170852877.3313.34.camel@shalil.farsiweb.info> <200702070951.04877.jkeating@redhat.com> <20070207161234.GC14694@ryvius.pekin.waw.pl> Message-ID: <20070207185134.d8feeef1.bugs.michael@gmx.net> On Wed, 7 Feb 2007 17:12:34 +0100, Dominik 'Rathann' Mierzejewski wrote: > > it is not so much about somebody stealing your account, it's about somebody > > going through the process to create their _own_ account. Once that has been > > done ( and we keep wanting to LOWER the barrier for this!! ), if there are no > > barriers in place, that person can now run roughshod all over all the > > packages, making any changes they want, building anything they want, causing > > automated pushes to push out whatever they built, leading to people grabbing > > packages and getting rooted, > > That won't happen THAT easily. Isn't the sign-and-push process manual? > Aren't the people who handle it supposed to check what they sign? A few random plausibility checks come to my mind. But checking some >50 builds per day for all sorts of security breaches would be a lot of work. Most likely "Impossible Mission" even for a team of people, considering how long ordinary reviews take. Just think about where you would start examining build-job results (src.rpm, binary rpms, buildsys logs) and what files inside a src.rpm you would trust, if at all. How many packagers trust upstream tarballs? The community (of packagers and users) should follow the cvs commits as much as possible. In particular, packagers ought to observe the changes in build requirements they depend on. Sponsors ought to monitor their new contributors commits (how long? one year? two years? seven years?). A mistake I don't want to make is to discuss possible attack vectors. Packages in the needsign queue are not signed automatically and are not published automatically. But a successful build job enters the needsign queue and is available to all subsequent build jobs automatically. This turns the needsign queue into a two-sided sword. Who examines successful build jobs *before* they are released and before submitting an own build job? How many packagers check the official build logs painstakingly? And if packages from the needsign queue are published [quickly], who examines them before installing them, but after they may have "infected" other build results already? Co-maintainership could increase security. But hoping that a small team of people can guarantee ultimate security via global post-build checks, is Utopian. From dledford at redhat.com Wed Feb 7 17:51:49 2007 From: dledford at redhat.com (Doug Ledford) Date: Wed, 07 Feb 2007 12:51:49 -0500 Subject: Problems with core review In-Reply-To: <20070206203404.GC6857@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> Message-ID: <1170870709.2716.401.camel@fc6.xsintricity.com> On Tue, 2007-02-06 at 20:34 +0000, Joe Orton wrote: > On Tue, Feb 06, 2007 at 11:49:11AM -0800, Christopher Stone wrote: > > Here are the issues in question: > > > > 1) Replace use of $RPM_SOURCE_DIR with %{SOURCEx} > > > > I asked about this in #fedora-extras since I did not understand > > rpmlints Error message. f13 responded by saying you should just use > > %{SOURCEx}. > > > > I agree with f13 on this issue because it is easier to identify in the > > spec file where the source files are used. > > Con: it makes renumering Sources a pain, Eh? RPM is perfectly happy with sparse numbering, your choice to renumber is just you being anal (not to mention the already mentioned alternatives that make it easy, such as sed). > it's harder to use since you > have to remember numbers not filenames. Generally speaking, not if you use complete install commands where the target file name is specified. The target file name should clearly indicate to you what SOURCEx maps to. > This number/filename mapping > trick doesn't scale well as anybody who has maintained spec files with > more than a handful of patches knows. Bullshit. Maintain the kernel rpm for a while. Style and consistency isn't always cheap and it's never free, and it's still worth it for the fact that it makes it easier for *other* people to work on this code and understand it, which is the point of a distributed source management system that people can see into like we are creating now. Are we just doing this to waste time or to make a difference? Take a lesson from the linux kernel community: When working in a distributed fashion, style doesn't need justification to be enforced, breaches of style need justification to exist. Fix it. > Insufficient justification for change. > > > 2) Add empty %build section even though its not required > > > > All php-pear packages include an empty %build section and php-pear > > should not be an exception. This was disccussed at length when > > creating the php-pear spec file template. Ville has real world > > examples how this can cause problems. > > What are they, how do they apply to this package? > > > Technical reason for changing: rpm is unpredictable with no %build, > > consistency among all pear packages > > It's worked predictably for the history of this package. Insufficient > justification for change. OK, time for my soapbox for a bit. The point of this revue process, speaking as someone who's been at Red Hat since 1998 and therefore has packages built *WELL* before all the guidelines were in place and is willing to take care of whatever needs taken care of in those packages, is to bring the packages into sync with the guidelines. The onus is not on the Fedora Review committee to justify the guidelines to every would be kernel RPM maintainer out there, nor is the onus on the fedora reviewers to reject packages. The onus is on the maintainer to get their package accepted and to fix their poor style so that the whole of the Fedora project has a consistent style that allows an individual contributor to work on any RPM in the repo and know enough to be able to jump in and get to work right away. Unless you have significant justification to over ride the review committee suggestions, justification more significant that "I don't wanna!" and justification that supersedes the goal of creating a uniform, distributed source management system that promotes ease of contribution, then I suggest you do the work. To Jesse: the Fedora project will get exactly as much out of this review process as we put into it. No more, no less. If you let sloppy, inconsistent style slide, then this is all just an exercise in finger pointing with no real effect. IMO, the Fedora community is under no obligation to accept crap packages, and has every right to assign their own maintainer to take care of a package should a Red Hat maintainer prove to be unwilling to work cooperatively with the community. Stick to your guidelines and cut this kind of crap off at the knees before it becomes pervasive throughout the review process and part of the benefit of the review is lost to purposeless exceptions. As for the lack of %build, I can understand not needing it, but having it there doesn't hurt, it makes it more obvious that %build does nothing intentionally, and it fixes an admitted bug in rpm debug-info handling. But more importantly, the proper channel to address a disagreement over whether or not packages that don't need built should have a %build section in the spec file is to address the fedora community and try to get the guideline changed, not to just refuse to put it in there. Unless of course you believe that we should *all* just ignore the guidelines we don't like because we are "above the law" so to speak. > > 3) License tag should change to just "PHP License 3.0" > > I'm not making changes here until a license tag standard is agreed. The > current draft proposal on the wiki drops the version altogether. If there's no agreed upon standard, then nothing exists to change to. This is the only exception you've made that holds any water. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 Wed Feb 7 18:11:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 13:11:26 -0500 Subject: Theoretical: CVS Admin with Flags In-Reply-To: <20070207161342.GD14694@ryvius.pekin.waw.pl> References: <45BE7342.1070005@redhat.com> <20070207160449.GB14694@ryvius.pekin.waw.pl> <20070207161342.GD14694@ryvius.pekin.waw.pl> Message-ID: <200702071311.27116.jkeating@redhat.com> On Wednesday 07 February 2007 11:13, Dominik 'Rathann' Mierzejewski wrote: > > > The package has to be added to the build database, and that requires > > > some level of admin task. ?If that task is rolled into preparing the > > > CVS tree for the import of your package, then all the better. > > > > Can we please keep things no more complicated than they were? Initial > > import into devel should not require any admin interaction. If it does, > > why do we need sponsorship? > > And review process. > > > Getting a contributor account was difficult enough, I don't > > want to jump through hoops with every new package! > > After it's already approved, I should've added. Because something has to write to a package database to assign ownership and setup ACLs. We can't let everybody do this, or whats the point of ACLs, anybody could overwrite anybody else's packages. This is just one of the things that has to change when going from an official 3rd party repo to a 1st party collection. -- 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 Feb 7 18:18:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 13:18:19 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070207161234.GC14694@ryvius.pekin.waw.pl> References: <45BEC555.8050908@redhat.com> <200702070951.04877.jkeating@redhat.com> <20070207161234.GC14694@ryvius.pekin.waw.pl> Message-ID: <200702071318.19874.jkeating@redhat.com> On Wednesday 07 February 2007 11:12, Dominik 'Rathann' Mierzejewski wrote: > That won't happen THAT easily. Isn't the sign-and-push process manual? > Aren't the people who handle it supposed to check what they sign? It's only manual because it was chosen to be. We could either A) go the route that Core does now and not sign development packages, or B) introduce a signing server that can sign anything that falls out of the build system. Core pushes to rawhide were 100% automated, just a cron job. There is no reason why Extras couldn't have been for rawhide too, and once we merge, we should make that change so that development as a whole automatically lands every night. > > or even worse, insert some small thing in a package that gets pulled into > > most buildroots that will further taint any more builds. ?Could be hard > > to detect until it is far far too late. > > It would be stopped at the sign-and-push stage at worst. I'm sure there are > many eyes following the cvs commits list. It would be spotted quite fast > IMHO. You can prevent messages from being posted to cvs commits. > > ?With proper barriers in place, > > the most damage a rouge user can do is to their own > > package, or to any packages foolishly left wide open. > > I don't really mind the ACLs as much as I do mind having to go through > another approval (for CVS import) after my package has ALREADY been > APPROVED. You don't. Once your package is approved, appropriate people are notified and setup the location so that you can do your import and build. What is so difficult about this? -- 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 Feb 7 18:27:24 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 13:27:24 -0500 Subject: CVS Admin Sucks Less In-Reply-To: <20070207160449.GB14694@ryvius.pekin.waw.pl> References: <45BE7342.1070005@redhat.com> <45C7B3A2.3070306@redhat.com> <45C990E7.5040307@hhs.nl> <200702070947.25673.jkeating@redhat.com> <20070207160449.GB14694@ryvius.pekin.waw.pl> Message-ID: <45CA1A0C.2080908@redhat.com> Dominik 'Rathann' Mierzejewski wrote: > > Can we please keep things no more complicated than they were? Initial import > into devel should not require any admin interaction. If it does, why do we > need sponsorship? Getting a contributor account was difficult enough, I don't > want to jump through hoops with every new package! > Past: CVSSyncNeeded =================== Wiki sucked a lot for a work queue. 4 steps: 1) fedora-review+ 2) cvs-import.sh 3) CVSSyncNeeded and wait... 4) Fix-up and build Current: CVS Admin ================== You ask cvs admin to create directories for you, then you do everything all at once. This is actually FEWER steps than before. 1) fedora-review+ 2) fedora-cvs? and wait... 3) Check-in and build. Yes, this process still sucks, but it sucks less. Let's just use this for now, and focus on making the ideal system for the future. Future: Better Automation ========================= I think the future infrastructure improvements like next-gen VCS and Package Database will eventually allow us to better automate this, perhaps making it entirely self-serve. No waiting involved. 1) Pre-review, import into a theoretical hosted personal VCS to make it easy for others to review. Changes prior to approval are tracked in history. 2) fedora-review+ in database. 3) System automatically validates fedora-review+. Owner can check boxes of which branches they wish to create. Then build. (There are a number of security considerations we must take into account for this to be possible. The design and implementation for example would need to abstract access from PackageDB to VCS, limiting it to only certain operations like "create new package".) Warren Togami wtogami at redhat.com From wtogami at redhat.com Wed Feb 7 18:32:12 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 13:32:12 -0500 Subject: ACL's, Why a Big Deal? Message-ID: <45CA1B2C.2070906@redhat.com> 1) For all existing packages, pkg.acl file does not exist. So the openness that existed previously DID NOT CHANGE. 2) For newly added packages, pkg.acl exists by default. If you as an owner don't want such protectionism, just cvs remove it. 3) Owners have the *OPTION* to use a pkg.acl file to grant specific other users access to a locked down package. Notes ===== - pkg.acl is synced to the actual acl's once per hour. Warren Togami wtogami at redhat.com From mtasaka at ioa.s.u-tokyo.ac.jp Wed Feb 7 18:33:12 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 08 Feb 2007 03:33:12 +0900 Subject: CVS Admin Sucks Less In-Reply-To: <45CA1A0C.2080908@redhat.com> References: <45BE7342.1070005@redhat.com> <45C7B3A2.3070306@redhat.com> <45C990E7.5040307@hhs.nl> <200702070947.25673.jkeating@redhat.com> <20070207160449.GB14694@ryvius.pekin.waw.pl> <45CA1A0C.2080908@redhat.com> Message-ID: <45CA1B68.3040003@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > > Past: CVSSyncNeeded > =================== > Wiki sucked a lot for a work queue. 4 steps: > 1) fedora-review+ (A-1) > 2) cvs-import.sh (A-2) > 3) CVSSyncNeeded and wait... (A-3) > 4) Fix-up and build (A-4) > > Current: CVS Admin > ================== > You ask cvs admin to create directories for you, then you do everything > all at once. This is actually FEWER steps than before. > 1) fedora-review+ (B-1) > 2) fedora-cvs? and wait... (B-2) > 3) Check-in and build. (B-3) > Then just a check: When using SyncNEEDED, A-3 was done by submitter(reporter). This time B-2 should be done by reviewer(assignee), okay? Mamoru From wart at kobold.org Wed Feb 7 18:37:22 2007 From: wart at kobold.org (Michael Thomas) Date: Wed, 07 Feb 2007 10:37:22 -0800 Subject: Tcl packaging guidelines In-Reply-To: References: <45C8CC14.1090707@kobold.org> Message-ID: <45CA1C62.9060501@kobold.org> Jason L Tibbitts III wrote: >>>>>> "MT" == Michael Thomas writes: > > MT> Following the precedent set by perl, python, and ruby, I've > MT> drafted a set of proposed guidelines for Tcl packages. > > MT> http://fedoraproject.org/wiki/MichaelThomas/Tcl > > After a couple of reads I'll say that to me these seem mostly sane and > it seems you've done a lot of work, but I know FA about Tcl so I > really can't really comment on many of the issues. > > I'm concerned about how disruptive these are. If every package is > going to need to be changed then we really need comments from as many > people as possible who are involved with tcl packaging. Hence my post to fedora-maintainers. > One concern I do have is the naming guidelines; why not adopt a "tcl-" > prefix universally, at least for new packages? I waffled back and forth on this a few times. Most Tcl packages already have a 'tcl' prefix (not 'tcl-') upstream, which seemed good enough. For those that don't have the 'tcl' prefix, users and Tcl developers won't be expecting such naming if they are trying to install the packages manually, especially when the names are well-entrenched in the Tcl community already. For example, 'tcl-bwidget' is a very non-intuitive way to ask for the bwidget extension if I'm getting ready to develop a new Tcl app. Maybe a compromise would be to require the package name change, and accept both the 'tcl' and 'tcl-' prefixes (less disruptive). But packages are allowed to 'Provide: foo' for the more common name. Example: Name: bwidget becomes Name: tcl-bwidget Provides: bwidget ? --Wart From mtasaka at ioa.s.u-tokyo.ac.jp Wed Feb 7 18:38:28 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 08 Feb 2007 03:38:28 +0900 Subject: ACL's, Why a Big Deal? In-Reply-To: <45CA1B2C.2070906@redhat.com> References: <45CA1B2C.2070906@redhat.com> Message-ID: <45CA1CA4.4040106@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > 2) For newly added packages, pkg.acl exists by default. If you as an > owner don't want such protectionism, just cvs remove it. My opinion is, at least the sponsor of the person who maintains the package should have the right to access the package by default. Then: is the idea that to creating a rather big group including sponsors, cvs admin, etc... and to give some more free access right for the people in the group (I remember someone proposed before) is gone away? Mamoru From wtogami at redhat.com Wed Feb 7 18:40:02 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 13:40:02 -0500 Subject: CVS Admin Sucks Less In-Reply-To: <45CA1B68.3040003@ioa.s.u-tokyo.ac.jp> References: <45BE7342.1070005@redhat.com> <45C7B3A2.3070306@redhat.com> <45C990E7.5040307@hhs.nl> <200702070947.25673.jkeating@redhat.com> <20070207160449.GB14694@ryvius.pekin.waw.pl> <45CA1A0C.2080908@redhat.com> <45CA1B68.3040003@ioa.s.u-tokyo.ac.jp> Message-ID: <45CA1D02.5040307@redhat.com> Mamoru Tasaka wrote: > Warren Togami wrote: >> >> Past: CVSSyncNeeded >> =================== >> Wiki sucked a lot for a work queue. 4 steps: >> 1) fedora-review+ (A-1) >> 2) cvs-import.sh (A-2) >> 3) CVSSyncNeeded and wait... (A-3) >> 4) Fix-up and build (A-4) >> >> Current: CVS Admin >> ================== >> You ask cvs admin to create directories for you, then you do >> everything all at once. This is actually FEWER steps than before. >> 1) fedora-review+ (B-1) >> 2) fedora-cvs? and wait... (B-2) >> 3) Check-in and build. (B-3) >> > > Then just a check: > When using SyncNEEDED, A-3 was done by submitter(reporter). This time > B-2 should be done by reviewer(assignee), okay? > Good idea. I suppose either reviewer or submitter can do fedora-cvs?, cutting down the time waiting overhead a bit. Only potential problem, is the reviewer may not know which branches the submitter wished. Any thoughts? Warren Togami wtogami at redhat.com From wart at kobold.org Wed Feb 7 18:42:39 2007 From: wart at kobold.org (Michael Thomas) Date: Wed, 07 Feb 2007 10:42:39 -0800 Subject: Tcl packaging guidelines In-Reply-To: <1170866797.4306.53.camel@localhost.localdomain> References: <45C8CC14.1090707@kobold.org> <1170866797.4306.53.camel@localhost.localdomain> Message-ID: <45CA1D9F.2060203@kobold.org> Toshio Kuratomi wrote: > ''' > == Naming Conventions == > > It is common for Tcl applications and extensions to begin with a 'tcl' > or 'tk' prefix in the upstream name. Fedora Tcl packages should follow > this convention. If the upstream name does not contain the 'tcl' or > 'tk' prefix, then it is only necessary to add one if the upstream name > is inappropriately generic. For example, the 'thread' extension to Tcl > is named 'thread' upstream, but is named 'tclthread' in Fedora. The > upstream name for the 'bwidget' extension is uncommon enough that it > does not need to contain the 'tcl' or 'tk' prefix in the Fedora package > name. > ''' > > * Other languages use $LANGUAGE-$MODULE naming. > * All modules in perl, ruby, and php are using the $LANGUAGE- prefix, > there has been talk of removing the python exception (ie: having > python-pygpgme instead of pygpgme) as having all modules use > $LANGUAGE-$MODULE makes it easier for endusers to find modules written > for the language they are writing their program in. > > So I'd propose: > * For modules, tcl-thread and tcl-bwidget. Possibly tcl-tk but someone > with more experience with tcl/tk will have to tell me if that makes > sense. I would consider Tk a special case, and that the guidelines should allow for either the 'tcl' or 'tk' prefix to be used. Would you agree that if upstream uses a name prefixed by 'tcl' already, that we don't need to change it to a 'tcl-' prefix? For example, we currently have 'tclxml'. I argue that we don't need to change this to 'tcl-xml', or 'tcl-tclxml', but could add an additional 'Provides: tcl-xml' and/or 'Provides: tcl-tclxml' if necessary. > Applications do not need to have the language prefix as users of the > application do not need to know what language it is written in. +1 I'll clarify some of this in the proposal. --Wart From wtogami at redhat.com Wed Feb 7 18:50:35 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 13:50:35 -0500 Subject: ACL's, Why a Big Deal? In-Reply-To: <45CA1CA4.4040106@ioa.s.u-tokyo.ac.jp> References: <45CA1B2C.2070906@redhat.com> <45CA1CA4.4040106@ioa.s.u-tokyo.ac.jp> Message-ID: <45CA1F7B.40201@redhat.com> Mamoru Tasaka wrote: > Warren Togami wrote: >> 2) For newly added packages, pkg.acl exists by default. If you as an >> owner don't want such protectionism, just cvs remove it. > > My opinion is, at least the sponsor of the person who maintains > the package should have the right to access the package by default. > > Then: is the idea that to creating a rather big group including > sponsors, cvs admin, etc... and to give some more free access right > for the people in the group (I remember someone proposed before) > is gone away? > Good point, and I think we should auto-add sponsors to pkg.acl. But extrapolating from this, there are a few potential policy problems. Scenario: Malicious Contributor 1) Malicious Contributor X gets sponsored after making one particularly good package. (Not too hard.) 2) X removes sponsor from pkg.acl and proceeds to add malicious crap, trying to root users' boxes. 3) Sponsor notices, but is unable to fix it. Must wait for a CVS admin to step in. (This brings to mind, we really need super users to be more geographically distributed. Currently all admins are in the American EST. More about this later.) Scenario: Red Hat Engineer 1) davej was sponsored by some Fedora sponsor Y. 2) davej owns kernel. 3) Thus Fedora sponsor Y may change kernel? (In practice this isn't such a big deal, because Y can simply be removed from pkg.acl. Y is also trusted member of the community that at least in theory *should* know and respect ownership rules.) So yes, we can add this kind of stuff in an automated fashion. But we need to think a bit more first about the policy. Warren Togami wtogami at redhat.com From mtasaka at ioa.s.u-tokyo.ac.jp Wed Feb 7 18:51:15 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 08 Feb 2007 03:51:15 +0900 Subject: CVS Admin Sucks Less In-Reply-To: <45CA1D02.5040307@redhat.com> References: <45BE7342.1070005@redhat.com> <45C7B3A2.3070306@redhat.com> <45C990E7.5040307@hhs.nl> <200702070947.25673.jkeating@redhat.com> <20070207160449.GB14694@ryvius.pekin.waw.pl> <45CA1A0C.2080908@redhat.com> <45CA1B68.3040003@ioa.s.u-tokyo.ac.jp> <45CA1D02.5040307@redhat.com> Message-ID: <45CA1FA3.10304@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > Mamoru Tasaka wrote: >> Warren Togami wrote: >>> >>> Past: CVSSyncNeeded >>> =================== >>> Wiki sucked a lot for a work queue. 4 steps: >>> 1) fedora-review+ (A-1) >>> 2) cvs-import.sh (A-2) >>> 3) CVSSyncNeeded and wait... (A-3) >>> 4) Fix-up and build (A-4) >>> >>> Current: CVS Admin >>> ================== >>> You ask cvs admin to create directories for you, then you do >>> everything all at once. This is actually FEWER steps than before. >>> 1) fedora-review+ (B-1) >>> 2) fedora-cvs? and wait... (B-2) >>> 3) Check-in and build. (B-3) >>> >> >> Then just a check: >> When using SyncNEEDED, A-3 was done by submitter(reporter). This time >> B-2 should be done by reviewer(assignee), okay? >> > > Good idea. I suppose either reviewer or submitter can do fedora-cvs?, > cutting down the time waiting overhead a bit. > > Only potential problem, is the reviewer may not know which branches the > submitter wished. > > Any thoughts? Well, then if cvsextras member can set fedora-cvs?, then the sumbitter can do this (because all maintainer should have cvsextras at least). If only fedorabugs member can set fedore-cvs?, this must be done by the reviewer. Mamoru From wtogami at redhat.com Wed Feb 7 18:56:28 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 13:56:28 -0500 Subject: CVS Admin Sucks Less In-Reply-To: <45CA1FA3.10304@ioa.s.u-tokyo.ac.jp> References: <45BE7342.1070005@redhat.com> <45C7B3A2.3070306@redhat.com> <45C990E7.5040307@hhs.nl> <200702070947.25673.jkeating@redhat.com> <20070207160449.GB14694@ryvius.pekin.waw.pl> <45CA1A0C.2080908@redhat.com> <45CA1B68.3040003@ioa.s.u-tokyo.ac.jp> <45CA1D02.5040307@redhat.com> <45CA1FA3.10304@ioa.s.u-tokyo.ac.jp> Message-ID: <45CA20DC.5050608@redhat.com> Mamoru Tasaka wrote: > > Well, then if cvsextras member can set fedora-cvs?, then the sumbitter > can do this (because all maintainer should have cvsextras at least). > If only fedorabugs member can set fedore-cvs?, this must be > done by the reviewer. 1) fedorabugs member used to control access to changing the fedora-cvs flag is only temporary, because Bugzilla lacks an equivalent group of cvsextras. Ideally I believe fedora-cvs flag should allow only cvsextras to set the fedora-cvs? flag. 2) cvsextras as a requirement to set fedora-cvs? is not a problem, because a contributor should *become* sponsored before check-in anyway. Warren Togami wtogami at redhat.com From jorton at redhat.com Wed Feb 7 19:21:21 2007 From: jorton at redhat.com (Joe Orton) Date: Wed, 7 Feb 2007 19:21:21 +0000 Subject: Problems with core review In-Reply-To: <1170870709.2716.401.camel@fc6.xsintricity.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170870709.2716.401.camel@fc6.xsintricity.com> Message-ID: <20070207192120.GA802@redhat.com> On Wed, Feb 07, 2007 at 12:51:49PM -0500, Doug Ledford wrote: > On Tue, 2007-02-06 at 20:34 +0000, Joe Orton wrote: > > This number/filename mapping > > trick doesn't scale well as anybody who has maintained spec files with > > more than a handful of patches knows. > > Bullshit. Maintain the kernel rpm for a while. Great example. $ grep -c RPM_SOURCE_DIR kernel-2.6.spec 16 Seriously guys, I've said it two times already: if you want me to repaint my bikeshed, first convince the central packaging committee on high that your particular choice of bikeshed colour not mine must be mandated across the distro. Then I'll happily tow the party line; otherwise I'll keep my bikesheds in yellow. http://yellow.bikeshed.com/ joe From jkeating at redhat.com Wed Feb 7 19:42:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 14:42:00 -0500 Subject: Problems with core review In-Reply-To: <20070207192120.GA802@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <1170870709.2716.401.camel@fc6.xsintricity.com> <20070207192120.GA802@redhat.com> Message-ID: <200702071442.00862.jkeating@redhat.com> On Wednesday 07 February 2007 14:21, Joe Orton wrote: > Seriously guys, I've said it two times already: if you want me to > repaint my bikeshed, first convince the central packaging committee on > high that your particular choice of bikeshed colour not mine must be > mandated across the distro. Then I'll happily tow the party line; > otherwise I'll keep my bikesheds in yellow. ?http://yellow.bikeshed.com/ We can't fix every single package at the same time, especially if more than one person says "I won't change anything until every other person changes their package.". You get two of those and you're in a deadlock. -- 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 Feb 7 19:47:32 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 7 Feb 2007 20:47:32 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <200702071318.19874.jkeating@redhat.com> References: <45BEC555.8050908@redhat.com> <200702070951.04877.jkeating@redhat.com> <20070207161234.GC14694@ryvius.pekin.waw.pl> <200702071318.19874.jkeating@redhat.com> Message-ID: <20070207194731.GA20204@ryvius.pekin.waw.pl> On Wednesday, 07 February 2007 at 19:18, Jesse Keating wrote: > On Wednesday 07 February 2007 11:12, Dominik 'Rathann' Mierzejewski wrote: [...] > > > or even worse, insert some small thing in a package that gets pulled into > > > most buildroots that will further taint any more builds. ?Could be hard > > > to detect until it is far far too late. > > > > It would be stopped at the sign-and-push stage at worst. I'm sure there are > > many eyes following the cvs commits list. It would be spotted quite fast > > IMHO. > > You can prevent messages from being posted to cvs commits. So why isn't that fixed already? > > > ?With proper barriers in place, > > > the most damage a rouge user can do is to their own > > > package, or to any packages foolishly left wide open. > > > > I don't really mind the ACLs as much as I do mind having to go through > > another approval (for CVS import) after my package has ALREADY been > > APPROVED. > > You don't. Once your package is approved, appropriate people are notified and > setup the location so that you can do your import and build. What is so > difficult about this? Oh really? Since when? The Contributors page still says (after my package is APPROVED): ---cut--- Identify Yourself as the Owner of the Package Place your requests in the 'New Package' section at: * Extras/CVSSyncNeeded with: 1. The name of the package 2. Your bugzilla account e-mail address 3. A list of who, if anyone, should also be CC'd on bug reports 4. A pointer to the review ticket This will be used to set up the proper records in the owners database, which is used for access to build the package, bugzilla population, and other features. Once this is done, you may then import the package. ---cut--- This wasn't necessary before (I could just add myself to owners.list) and THAT's what I have issues with. Now I have to wait until someone manually add something I used to be able to add myself. And I'm NOT notified when this is done (or am I?). And no, subscribing to CVSSyncNeeded changes is NOT an option. 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 wtogami at redhat.com Wed Feb 7 19:51:12 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 14:51:12 -0500 Subject: Pros & Cons of ASSIGNED pointer and NEEDINFO Message-ID: <45CA2DB0.7020504@redhat.com> It seems that bouncing of the ASSIGNED pointer is a polarizing issue. Some people like it, some people hate it. NEEDINFO is a little less polarizing, although some people hate to bounce too. "ASSIGNED to next actor" ======================== PRO: http://rubenkerkhof.com/review This total view of the review status is VERY CLEAR on who needs to act nex. This VERY CLEAR nature is partially lost if we move back to ASSIGNED pointer to only reviewer. CON: User interface is not obvious, thus people forget to do it. This creates inconsistent states and extra bugmail as it is corrected after-the-fact. "ASSIGNED to reviewer, use NEEDINFO as necessary" ================================================= PRO: User interface is less error prone. CON: Unclear that the owner must act in order to finish a ticket, in the common state where neither ASSIGNED nor NEEDINFO is set to the owner when a package needs fixes or a package is done. (I personally think this is a huge detriment.) Frontpage.cgi ============= ASSIGNED or NEEDINFO shows up on frontpage.cgi, making either equally fine for personal work-queue viewing. Decision Making... ================== We can't make everyone happy. The best we can do is compromise within the limits of our current Bugzilla-based review process and settle on a process that sucks less for the short-term. Then focus on building the ideal process using better tools... perhaps within the Package Database schema, application, and other tools that interface with it. Ultimately, I believe "ASSIGNED to next actor" is logical and good, and only the error-prone nature of our current user interface is holding us back from using it smoothly. Could we easily improve this user interface? User Interface Improvement ========================== - fedora-review? set ASSIGNED pointer to self (reviewer takes). - fedora-review- set ASSIGNED pointer to owner. - fedora-review+ set ASSIGNED pointer to owner. Might this work to make "ASSIGNED to next actor" a smooth process? Only problem... who is the owner? Not so easy to automate in Bugzilla. Any ideas? Warren Togami wtogami at redhat.com From jkeating at redhat.com Wed Feb 7 19:53:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 14:53:29 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070207194731.GA20204@ryvius.pekin.waw.pl> References: <45BEC555.8050908@redhat.com> <200702071318.19874.jkeating@redhat.com> <20070207194731.GA20204@ryvius.pekin.waw.pl> Message-ID: <200702071453.36654.jkeating@redhat.com> On Wednesday 07 February 2007 14:47, Dominik 'Rathann' Mierzejewski wrote: > So why isn't that fixed already? Because CVS does this as an external program that can be ^c'd. Many people have said they'd look into fixing it, nobody has. [snip] > > You don't. ?Once your package is approved, appropriate people are > > notified and setup the location so that you can do your import and build. > > ?What is so difficult about this? > > Oh really? Since when? The Contributors page still says (after my package > is APPROVED): > > ---cut--- > Identify Yourself as the Owner of the Package > > Place your requests in the 'New Package' section at: > ? ? * Extras/CVSSyncNeeded > with: > ? ?1. The name of the package > ? ?2. Your bugzilla account e-mail address > ? ?3. A list of who, if anyone, should also be CC'd on bug reports > ? ?4. A pointer to the review ticket > > This will be used to set up the proper records in the owners database, > which is used for access to build the package, bugzilla population, and > other features. Once this is done, you may then import the package. > ---cut--- > > This wasn't necessary before (I could just add myself to owners.list) and > THAT's what I have issues with. Now I have to wait until someone manually > add something I used to be able to add myself. And I'm NOT notified when > this is done (or am I?). And no, subscribing to CVSSyncNeeded changes is > NOT an option. It looks like we will use the review bug to manage this, so you will get notification in the review bug when the necessary footwork has been done on the serverside that will allow you to import/build your package. You had to wait anyway for somebody to make the branches, now you wait the same amount for somebody to create the files so that you can import, and set up the buildsystem to allow you to build the package. owners.list is going away in favor of an actual database, used by the buildsystem and other tools. The use of this database for other tools, such as generating ACLs, means that we can't just let every tom, dick, and harry edit the thing. -- 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 Feb 7 19:53:56 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 7 Feb 2007 20:53:56 +0100 Subject: CVS Admin Sucks Less In-Reply-To: <45CA1A0C.2080908@redhat.com> References: <45BE7342.1070005@redhat.com> <45C7B3A2.3070306@redhat.com> <45C990E7.5040307@hhs.nl> <200702070947.25673.jkeating@redhat.com> <20070207160449.GB14694@ryvius.pekin.waw.pl> <45CA1A0C.2080908@redhat.com> Message-ID: <20070207195356.GB20204@ryvius.pekin.waw.pl> On Wednesday, 07 February 2007 at 19:27, Warren Togami wrote: > Dominik 'Rathann' Mierzejewski wrote: > > > >Can we please keep things no more complicated than they were? Initial > >import > >into devel should not require any admin interaction. If it does, why do we > >need sponsorship? Getting a contributor account was difficult enough, I > >don't > >want to jump through hoops with every new package! > > > > Past: CVSSyncNeeded > =================== > Wiki sucked a lot for a work queue. 4 steps: Not quite. > 1) fedora-review+ > 2) cvs-import.sh 3) build for devel Now if you wanted to package something for non-devel (the most common case, admittedly), then the following applied, too. > 3) CVSSyncNeeded and wait... > 4) Fix-up and build The point is, with this, I could build the package immediately. > Current: CVS Admin > ================== > You ask cvs admin to create directories for you, then you do everything > all at once. This is actually FEWER steps than before. > 1) fedora-review+ > 2) fedora-cvs? and wait... > 3) Check-in and build. > > Yes, this process still sucks, but it sucks less. Let's just use this > for now, and focus on making the ideal system for the future. I want to ask again: why is it necessary to do this NOW? Why can't the changes wait until packagedb is ready? > Future: Better Automation > ========================= > I think the future infrastructure improvements like next-gen VCS and > Package Database will eventually allow us to better automate this, > perhaps making it entirely self-serve. No waiting involved. > > 1) Pre-review, import into a theoretical hosted personal VCS to make it > easy for others to review. Changes prior to approval are tracked in > history. > 2) fedora-review+ in database. > 3) System automatically validates fedora-review+. Owner can check boxes > of which branches they wish to create. Then build. > > (There are a number of security considerations we must take into account > for this to be possible. The design and implementation for example > would need to abstract access from PackageDB to VCS, limiting it to only > certain operations like "create new package".) Sounds promising. I hope we get to see this in action soon. 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 wtogami at redhat.com Wed Feb 7 19:57:45 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 14:57:45 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070207194731.GA20204@ryvius.pekin.waw.pl> References: <45BEC555.8050908@redhat.com> <200702070951.04877.jkeating@redhat.com> <20070207161234.GC14694@ryvius.pekin.waw.pl> <200702071318.19874.jkeating@redhat.com> <20070207194731.GA20204@ryvius.pekin.waw.pl> Message-ID: <45CA2F39.1060602@redhat.com> Dominik 'Rathann' Mierzejewski wrote: > This wasn't necessary before (I could just add myself to owners.list) and > THAT's what I have issues with. Now I have to wait until someone manually > add something I used to be able to add myself. And I'm NOT notified when > this is done (or am I?). And no, subscribing to CVSSyncNeeded changes is > NOT an option. > Please stop bitching. The proposed CVS admin via fedora-cvs flag in Bugzilla will solve this issue as well as simplify the process further. Please see the "CVS Admin Sucks Less" thread. Bugzilla will notify you when the fedora-cvs? flag is unset, meaning you can go ahead, no more waiting for other people. Warren From wtogami at redhat.com Wed Feb 7 20:05:06 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 15:05:06 -0500 Subject: CVS Admin Sucks Less In-Reply-To: <20070207195356.GB20204@ryvius.pekin.waw.pl> References: <45BE7342.1070005@redhat.com> <45C7B3A2.3070306@redhat.com> <45C990E7.5040307@hhs.nl> <200702070947.25673.jkeating@redhat.com> <20070207160449.GB14694@ryvius.pekin.waw.pl> <45CA1A0C.2080908@redhat.com> <20070207195356.GB20204@ryvius.pekin.waw.pl> Message-ID: <45CA30F2.8040009@redhat.com> Dominik 'Rathann' Mierzejewski wrote: > 3) build for devel > > Now if you wanted to package something for non-devel (the most common case, > admittedly), then the following applied, too. > >> 3) CVSSyncNeeded and wait... >> 4) Fix-up and build > > The point is, with this, I could build the package immediately. The most common case is you want to build for both devel and current distros. You might as well build all at once. It is less overhead than building devel, waiting for CVS admin, then building the others. > >> Current: CVS Admin >> ================== >> You ask cvs admin to create directories for you, then you do everything >> all at once. This is actually FEWER steps than before. >> 1) fedora-review+ >> 2) fedora-cvs? and wait... >> 3) Check-in and build. >> >> Yes, this process still sucks, but it sucks less. Let's just use this >> for now, and focus on making the ideal system for the future. > > I want to ask again: why is it necessary to do this NOW? Why can't > the changes wait until packagedb is ready? If you wait for every part of a massive change to be implemented before making any change, then it will take FAR TOO LONG. Instead we are making smaller incremental improvements with a few interim solutions, making it possible to get important parts done in the near-term. (Important parts == Merging core and extras, enabling co-maintainership and easy delegation. BIG WIN for everyone.) > >> Future: Better Automation >> ========================= >> I think the future infrastructure improvements like next-gen VCS and >> Package Database will eventually allow us to better automate this, >> perhaps making it entirely self-serve. No waiting involved. >> >> 1) Pre-review, import into a theoretical hosted personal VCS to make it >> easy for others to review. Changes prior to approval are tracked in >> history. >> 2) fedora-review+ in database. >> 3) System automatically validates fedora-review+. Owner can check boxes >> of which branches they wish to create. Then build. >> >> (There are a number of security considerations we must take into account >> for this to be possible. The design and implementation for example >> would need to abstract access from PackageDB to VCS, limiting it to only >> certain operations like "create new package".) > > Sounds promising. I hope we get to see this in action soon. > http://fedoraproject.org/wiki/Infrastructure/ We need more people participating in this part. If you are interested, please read the Fedora Infrastructure Wiki, join fedora-infrastructure-list and the #fedora-infrastructure meetings every Thursday. Warren Togami wtogami at redhat.com From tibbs at math.uh.edu Wed Feb 7 20:12:24 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Feb 2007 14:12:24 -0600 Subject: $RPM_SOURCE_DIR (Was: Problems with core review) In-Reply-To: <20070207192120.GA802@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170870709.2716.401.camel@fc6.xsintricity.com> <20070207192120.GA802@redhat.com> Message-ID: >>>>> "JO" == Joe Orton writes: JO> Seriously guys, I've said it two times already: if you want me to JO> repaint my bikeshed, first convince the central packaging JO> committee on high that your particular choice of bikeshed colour JO> not mine must be mandated across the distro. Frankly we expected that many Rad Hat folks would simply not want to change things, and I suppose my personal hope of not having to involve the packaging committee in making tons of trivial rules in order to force people to change things is dashed by this very thread. But let's examine this specific situation in detail: The main restriction against using $RPM_SOURCE_DIR is that you can in no way ever write anything to it. That is the primary issue, and is implicitly given in other guidelines. The package in question does not write to $RPM_SOURCE_DIR if I understand correctly. For the package in question, $RPM_SOURCE_DIR can rather trivially be replaced by SourceN: and %{SOURCEN} tags. Is that correct? Are there situations where $RPM_SOURCE_DIR cannot be easily replaced by the use of SourceN: and %{SOURCEN} tags? I can think of situations like looping over source files (which frankly I've wished I could do in the past) which are at best a good bit more difficult, but perhaps someone has the necessary wizardly knowledge. I'm talking about doing things like copying ten source files into the buildroot without actually listing out ten %{SOURCEN} bits. The consistency argument for using SourceN: and %{SOURCEN} tags instead of $RPM_SOURCE_DIR is obvious. Is there a technical argument for using SourceN: and %{SOURCEN} tags instead of $RPM_SOURCE_DIR? I'm afraid I don't know it. - J< From tmraz at redhat.com Wed Feb 7 20:24:12 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 07 Feb 2007 21:24:12 +0100 Subject: $RPM_SOURCE_DIR (Was: Problems with core review) In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170870709.2716.401.camel@fc6.xsintricity.com> <20070207192120.GA802@redhat.com> Message-ID: <1170879852.3229.8.camel@perun.kabelta.loc> On Wed, 2007-02-07 at 14:12 -0600, Jason L Tibbitts III wrote: > Is there a technical argument for using SourceN: and %{SOURCEN} tags > instead of $RPM_SOURCE_DIR? I'm afraid I don't know it. There is one - the number is not mnemotechnical. So when you have really big number of Source files you will have pretty big problem to recognize which number belongs to which file and you'd have to always look up in the (potentially very large) spec file. Maybe there should be some macro so it could be possible to do things like: Source%myfinefile: myfinefile.xxx and then refer to it as %{SOURCE%myfinefile} later. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From dominik at greysector.net Wed Feb 7 20:36:45 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 7 Feb 2007 21:36:45 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45CA2F39.1060602@redhat.com> References: <45BEC555.8050908@redhat.com> <200702070951.04877.jkeating@redhat.com> <20070207161234.GC14694@ryvius.pekin.waw.pl> <200702071318.19874.jkeating@redhat.com> <20070207194731.GA20204@ryvius.pekin.waw.pl> <45CA2F39.1060602@redhat.com> Message-ID: <20070207203645.GC20204@ryvius.pekin.waw.pl> On Wednesday, 07 February 2007 at 20:57, Warren Togami wrote: > Dominik 'Rathann' Mierzejewski wrote: > >This wasn't necessary before (I could just add myself to owners.list) and > >THAT's what I have issues with. Now I have to wait until someone manually > >add something I used to be able to add myself. And I'm NOT notified when > >this is done (or am I?). And no, subscribing to CVSSyncNeeded changes is > >NOT an option. > > > > Please stop bitching. The proposed CVS admin via fedora-cvs flag in > Bugzilla will solve this issue as well as simplify the process further. > Please see the "CVS Admin Sucks Less" thread. Fair enough. > Bugzilla will notify you when the fedora-cvs? flag is unset, meaning you > can go ahead, no more waiting for other people. Now if someone could explain the flags somewhere and update http://fedoraproject.org/wiki/Extras/NewPackageProcess ... I won't because I have no idea what those flags are. 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 tibbs at math.uh.edu Wed Feb 7 20:39:54 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Feb 2007 14:39:54 -0600 Subject: Process Change: Package Reviews with Flags In-Reply-To: <200702071453.36654.jkeating@redhat.com> References: <45BEC555.8050908@redhat.com> <200702071318.19874.jkeating@redhat.com> <20070207194731.GA20204@ryvius.pekin.waw.pl> <200702071453.36654.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> Because CVS does this as an external program that can be ^c'd. JK> Many people have said they'd look into fixing it, nobody has. I think it would be more accurate to replace the second sentence with: Many people have said they'd look into fixing it, but those that have have been unable to manage to actually fix it. I have certainly tried using my own repo, and couldn't fix it. I know someone else tried some things on the Extras CVS server and also had no lock. - J< From tibbs at math.uh.edu Wed Feb 7 20:46:09 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Feb 2007 14:46:09 -0600 Subject: $RPM_SOURCE_DIR (Was: Problems with core review) In-Reply-To: <1170879852.3229.8.camel@perun.kabelta.loc> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170870709.2716.401.camel@fc6.xsintricity.com> <20070207192120.GA802@redhat.com> <1170879852.3229.8.camel@perun.kabelta.loc> Message-ID: >>>>> "TM" == Tomas Mraz writes: TM> On Wed, 2007-02-07 at 14:12 -0600, Jason L Tibbitts III wrote: >> Is there a technical argument for using SourceN: and %{SOURCEN} >> tags instead of $RPM_SOURCE_DIR? I'm afraid I don't know it. TM> There is one - the number is not mnemotechnical. I think your argument is for the opposite of my statement, which is fine. I happen to agree that Source3: is rather far from being mnemonic. - J< From tmraz at redhat.com Wed Feb 7 21:21:24 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 07 Feb 2007 22:21:24 +0100 Subject: $RPM_SOURCE_DIR (Was: Problems with core review) In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170870709.2716.401.camel@fc6.xsintricity.com> <20070207192120.GA802@redhat.com> <1170879852.3229.8.camel@perun.kabelta.loc> Message-ID: <1170883284.3229.10.camel@perun.kabelta.loc> On Wed, 2007-02-07 at 14:46 -0600, Jason L Tibbitts III wrote: > >>>>> "TM" == Tomas Mraz writes: > > TM> On Wed, 2007-02-07 at 14:12 -0600, Jason L Tibbitts III wrote: > >> Is there a technical argument for using SourceN: and %{SOURCEN} > >> tags instead of $RPM_SOURCE_DIR? I'm afraid I don't know it. > > TM> There is one - the number is not mnemotechnical. > > I think your argument is for the opposite of my statement, which is > fine. I happen to agree that Source3: is rather far from being > mnemonic. Ah, yes. I somehow misread your sentence above. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From jdennis at redhat.com Wed Feb 7 21:27:52 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 07 Feb 2007 16:27:52 -0500 Subject: $RPM_SOURCE_DIR (Was: Problems with core review) In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170870709.2716.401.camel@fc6.xsintricity.com> <20070207192120.GA802@redhat.com> Message-ID: <1170883672.5333.462.camel@finch.boston.redhat.com> On Wed, 2007-02-07 at 14:12 -0600, Jason L Tibbitts III wrote: > >>>>> "JO" == Joe Orton writes: > > JO> Seriously guys, I've said it two times already: if you want me to > JO> repaint my bikeshed, first convince the central packaging > JO> committee on high that your particular choice of bikeshed colour > JO> not mine must be mandated across the distro. > > Frankly we expected that many Rad Hat folks would simply not want to > change things, and I suppose my personal hope of not having to > involve the packaging committee in making tons of trivial rules in > order to force people to change things is dashed by this very thread. > But let's examine this specific situation in detail: > > The main restriction against using $RPM_SOURCE_DIR is that you can in > no way ever write anything to it. That is the primary issue, and is > implicitly given in other guidelines. The package in question does > not write to $RPM_SOURCE_DIR if I understand correctly. > > For the package in question, $RPM_SOURCE_DIR can rather trivially be > replaced by SourceN: and %{SOURCEN} tags. Is that correct? > > Are there situations where $RPM_SOURCE_DIR cannot be easily replaced > by the use of SourceN: and %{SOURCEN} tags? I can think of situations > like looping over source files (which frankly I've wished I could do > in the past) which are at best a good bit more difficult, but perhaps > someone has the necessary wizardly knowledge. I'm talking about doing > things like copying ten source files into the buildroot without > actually listing out ten %{SOURCEN} bits. > > The consistency argument for using SourceN: and %{SOURCEN} tags > instead of $RPM_SOURCE_DIR is obvious. > > Is there a technical argument for using SourceN: and %{SOURCEN} tags > instead of $RPM_SOURCE_DIR? I'm afraid I don't know it. Here are reasons for using RPM_SOURCE_DIR over SOURCEn 1) install "${RPM_SOURCE_DIR}/foobar dst" is *much* more readable than "install ${SOURCEN} dst", it means as a mere human being I do not have to act as a macro preprocessor in order to read the spec file and know what is being installed where. Readability is a huge win! 2) you can loop, I do it all the time for f in file1 file2; do install ${RPM_SOURCE_DIR}/$f dst done 3) SOURCEn is a mechanism for source RPM manifests, if you want to use it elsewhere then by all means go for it, but don't lose sight of the fact it's a manifest directive with the side effect of introducing a symbol into the rpm namespace, use of that symbol is purely optional. 4) It's none of your business how I implement something as long as its not broken. Forcing every spec file to replace $RPM_SOURCE_DIR with $SOURCEn is consistency without merit. Ralph Waldo Emerson wrote "foolish consistency is the hobgoblin of little minds" It's my choice as to what constitutes a maintainable spec file based on value judgments and experience. +1 for Joe Orton -1 for the Bureaucrats in People's Central Packaging Committee and their police who seek to banish me to the gulag for crimes against spec files by virtue of improper thinking ;-) -- 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 jkeating at redhat.com Wed Feb 7 21:44:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 16:44:21 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: References: <45BEC555.8050908@redhat.com> <200702071453.36654.jkeating@redhat.com> Message-ID: <200702071644.21672.jkeating@redhat.com> On Wednesday 07 February 2007 15:39, Jason L Tibbitts III wrote: > JK> Because CVS does this as an external program that can be ^c'd. > JK> Many people have said they'd look into fixing it, nobody has. > > I think it would be more accurate to replace the second sentence with: > > Many people have said they'd look into fixing it, but those that have > have been unable to manage to actually fix it. > > I have certainly tried using my own repo, and couldn't fix it. ?I know > someone else tried some things on the Extras CVS server and also had > no lock. Correct. I didn't mean to imply that nobody looked at it. Poor use of phrasing on my part. People HAVE looked and have been unable to fix it. The problem is just really hard. -- 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 Feb 7 21:48:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 16:48:16 -0500 Subject: $RPM_SOURCE_DIR (Was: Problems with core review) In-Reply-To: <1170883672.5333.462.camel@finch.boston.redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <1170883672.5333.462.camel@finch.boston.redhat.com> Message-ID: <200702071648.16979.jkeating@redhat.com> On Wednesday 07 February 2007 16:27, John Dennis wrote: > 4) It's none of your business how I implement something as long as its > not broken. Forcing every spec file to replace $RPM_SOURCE_DIR with > $SOURCEn is consistency without merit. Ralph Waldo Emerson wrote > "foolish consistency is the hobgoblin of little minds" It's my choice as > to what constitutes a maintainable spec file based on value judgments > and experience. > > +1 for Joe Orton > > -1 for the Bureaucrats in People's Central Packaging Committee and their > police who seek to banish me to the gulag for crimes against spec files > by virtue of improper thinking ;-) So I was with you up until here. One thing that I want everybody to remember, these guidelines aren't just for YOU and YOUR Package. They are for ALL of us for ANYBODY who may inherit your package or need to fix your package in a pinch. You can't emphatically say that you will own and manage your package for ever and ever, amen. We don't write code for ourselves, we write code for the person who will inevitably inherit the code and have to deal with it. If everybody wrote code for themselves, most code would be completely unreadable to other people. This is why we introduce things for consistency, so that when a security maintainer has to fix your package while you're on vacation, he can actually READ your specfile and know whats going on. (this is well beyond the use of RPM_SOURCE_DIR vs SOURCEx, but then again so are your comments). It is NOT about you, it's about your eventual replacement. -- 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 luya_tfz at thefinalzone.com Wed Feb 7 22:02:05 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Wed, 07 Feb 2007 14:02:05 -0800 Subject: Laptop running Fedora Core Message-ID: <45CA4C5D.7090802@thefinalzone.com> There is a post of Fedora Forum asking to gather information on laptops running Fedora. Hopefully these kinds of informations will be useful for the laptop maintainers staffs. http://forums.fedoraforum.org/showthread.php?t=137531 -- ??D0 References: <45C8CC14.1090707@kobold.org> <1170866797.4306.53.camel@localhost.localdomain> <45CA1D9F.2060203@kobold.org> Message-ID: <1170885529.4306.74.camel@localhost.localdomain> On Wed, 2007-02-07 at 10:42 -0800, Michael Thomas wrote: > Toshio Kuratomi wrote: > > ''' > > == Naming Conventions == > > > > It is common for Tcl applications and extensions to begin with a 'tcl' > > or 'tk' prefix in the upstream name. Fedora Tcl packages should follow > > this convention. If the upstream name does not contain the 'tcl' or > > 'tk' prefix, then it is only necessary to add one if the upstream name > > is inappropriately generic. For example, the 'thread' extension to Tcl > > is named 'thread' upstream, but is named 'tclthread' in Fedora. The > > upstream name for the 'bwidget' extension is uncommon enough that it > > does not need to contain the 'tcl' or 'tk' prefix in the Fedora package > > name. > > ''' > > > > * Other languages use $LANGUAGE-$MODULE naming. > > * All modules in perl, ruby, and php are using the $LANGUAGE- prefix, > > there has been talk of removing the python exception (ie: having > > python-pygpgme instead of pygpgme) as having all modules use > > $LANGUAGE-$MODULE makes it easier for endusers to find modules written > > for the language they are writing their program in. > > > > So I'd propose: > > * For modules, tcl-thread and tcl-bwidget. Possibly tcl-tk but someone > > with more experience with tcl/tk will have to tell me if that makes > > sense. > > I would consider Tk a special case, and that the guidelines should allow > for either the 'tcl' or 'tk' prefix to be used. > > Would you agree that if upstream uses a name prefixed by 'tcl' already, > that we don't need to change it to a 'tcl-' prefix? For example, we > currently have 'tclxml'. I argue that we don't need to change this to > 'tcl-xml', or 'tcl-tclxml', but could add an additional 'Provides: > tcl-xml' and/or 'Provides: tcl-tclxml' if necessary. > I'm going to waffle on that. In some ways I see it as redundant to write tcl-tclxml. OTOH, the recent discussion[1]_ regarding python-py[name] vs py[name] hinged around making it easy to guess the names of language bindings so tcl-tclxml would be the most consistent in this regard. Anyone else on the Packaging Committee have some thoughts? [1]_: http://www.fedoraproject.org/wiki/Packaging/IRCLog20070123 [09:13:59-09:24:47 AM] [10:12:18-10:25:13AM] -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 wtogami at redhat.com Wed Feb 7 22:13:49 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 17:13:49 -0500 Subject: Laptop running Fedora Core In-Reply-To: <45CA4C5D.7090802@thefinalzone.com> References: <45CA4C5D.7090802@thefinalzone.com> Message-ID: <45CA4F1D.3000801@redhat.com> Luya Tshimbalanga wrote: > There is a post of Fedora Forum asking to gather information on laptops > running Fedora. Hopefully these kinds of informations will be useful > for the laptop maintainers staffs. > > http://forums.fedoraforum.org/showthread.php?t=137531 > This kind of collection method is not very useful. http://smolt.fedoraproject.org/ Why don't you point people to smolt instead? Use smolt, and help to improve it? Warren Togami wtogami at redhat.com From luya_tfz at thefinalzone.com Wed Feb 7 22:24:16 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Wed, 07 Feb 2007 14:24:16 -0800 Subject: Laptop running Fedora Core In-Reply-To: <45CA4F1D.3000801@redhat.com> References: <45CA4C5D.7090802@thefinalzone.com> <45CA4F1D.3000801@redhat.com> Message-ID: <45CA5190.40608@thefinalzone.com> Warren Togami wrote: > Luya Tshimbalanga wrote: >> There is a post of Fedora Forum asking to gather information on laptops >> running Fedora. Hopefully these kinds of informations will be useful >> for the laptop maintainers staffs. >> >> http://forums.fedoraforum.org/showthread.php?t=137531 >> > > This kind of collection method is not very useful. > > http://smolt.fedoraproject.org/ > Why don't you point people to smolt instead? Use smolt, and help to > improve it? > > Warren Togami > wtogami at redhat.com The post was made before the existance of smolt. But you are right, I am going to post. -- ??D0 References: <45BEC555.8050908@redhat.com> <200702071453.36654.jkeating@redhat.com> <200702071644.21672.jkeating@redhat.com> Message-ID: <20070207162239.00701744@ningauble.scrye.com> On Wed, 7 Feb 2007 16:44:21 -0500 jkeating at redhat.com (Jesse Keating) wrote: > On Wednesday 07 February 2007 15:39, Jason L Tibbitts III wrote: > > JK> Because CVS does this as an external program that can be ^c'd. > > JK> Many people have said they'd look into fixing it, nobody has. > > > > I think it would be more accurate to replace the second sentence > > with: > > > > Many people have said they'd look into fixing it, but those that > > have have been unable to manage to actually fix it. > > > > I have certainly tried using my own repo, and couldn't fix it. ?I > > know someone else tried some things on the Extras CVS server and > > also had no lock. > > Correct. I didn't mean to imply that nobody looked at it. Poor use > of phrasing on my part. People HAVE looked and have been unable to > fix it. The problem is just really hard. I'm not a CVS guru, but what about just moving the email sending to the commitinfo file instead of the loginfo file (After the acl checks). commitinfo is run before the files are commited, so if they stopped it, then they would have no commited files. It might be that there is less info available at that point, but I would fine also with 2 emails... user foo is about to commit bar/baz.spec bar/baz.patch then user foo commited bar/baz.spec bar/baz.patch with changelog: "whatever" I'm probibly missing something, but won't that work? 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 Wed Feb 7 23:47:41 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Feb 2007 17:47:41 -0600 Subject: $RPM_SOURCE_DIR (Was: Problems with core review) In-Reply-To: <1170883672.5333.462.camel@finch.boston.redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170870709.2716.401.camel@fc6.xsintricity.com> <20070207192120.GA802@redhat.com> <1170883672.5333.462.camel@finch.boston.redhat.com> Message-ID: I don't want to seem to ignore your other perfectly valid arguments, especially since one of them precisely duplicates an argument made in my original message. I just think this needs to be treated separately: >>>>> "JD" == John Dennis writes: JD> -1 for the Bureaucrats in People's Central Packaging Committee and JD> their police who seek to banish me to the gulag for crimes against JD> spec files by virtue of improper thinking ;-) So there's an emoticon there, but an emoticon isn't enough to hide the fact that there's an attitude here which really needs to be dealt with. So I'll make it plain: I am on the packaging committee. Why on Earth would I have posted my message if I had no interest in gaining input from the people on various sides of the issue? The committee has created no applicable rules here except for the absolute prohibition against writing to $RPM_SOURCE_DIR. I am attempting to gather information so that the committee can consider the issue. It would behoove those who have interest in this to provide balanced information and constructive discussion (as I will note that you did in your message before that bit at the end) instead of inflammatory rhetoric, because the rhetoric tends to drown out the useful bits. Please work with us instead of denigrating us. Don't validate the fears many community members have of Red Hat employees turning their noses up at community-developed guidelines. - J< From petersen at redhat.com Thu Feb 8 00:23:05 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 08 Feb 2007 10:23:05 +1000 Subject: Pros & Cons of ASSIGNED pointer and NEEDINFO In-Reply-To: <45CA2DB0.7020504@redhat.com> References: <45CA2DB0.7020504@redhat.com> Message-ID: <45CA6D69.8090301@redhat.com> Warren Togami wrote: > It seems that bouncing of the ASSIGNED pointer is a polarizing issue. > Some people like it, some people hate it. NEEDINFO is a little less > polarizing, although some people hate to bounce too. I haven't followed all the discussion but it seems to me that > "ASSIGNED to reviewer, use NEEDINFO as necessary" looks more consistent with common bugzilla process and usage. Furthermore for "ASSIGNED to next actor" one has to keep copying'n'pasting the other person's address to reassign to them which can get pretty tedious for quick interchanges IMHO. With NEEDINFO it is easy just to set "from Reporter" or "from Assignee" etc. Jens From tibbs at math.uh.edu Thu Feb 8 00:58:34 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Feb 2007 18:58:34 -0600 Subject: Tcl packaging guidelines In-Reply-To: <1170885529.4306.74.camel@localhost.localdomain> References: <45C8CC14.1090707@kobold.org> <1170866797.4306.53.camel@localhost.localdomain> <45CA1D9F.2060203@kobold.org> <1170885529.4306.74.camel@localhost.localdomain> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> OTOH, the recent discussion[1]_ regarding python-py[name] vs TK> py[name] hinged around making it easy to guess the names of TK> language bindings so tcl-tclxml would be the most consistent in TK> this regard. Note also that we have perl-perlmenu, perl-pmtools, perl-Perl-Critic, perl-Perl6-Bible and perl-PerlIO*. Perl modules are consistently named with a "perl-" prefix regardless of the name of the module. PHP modules are also consistently prefixed as well. (The three packages named starting with php and having no prefix are actually applications.) However, we also have rubygems and not ruby-rubygems, although this may be an actual application instead of a module or extension. - J< From jdennis at redhat.com Thu Feb 8 02:33:13 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 07 Feb 2007 21:33:13 -0500 Subject: $RPM_SOURCE_DIR (Was: Problems with core review) In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170870709.2716.401.camel@fc6.xsintricity.com> <20070207192120.GA802@redhat.com> <1170883672.5333.462.camel@finch.boston.redhat.com> Message-ID: <1170901993.3393.29.camel@junko.usersys.redhat.com> On Wed, 2007-02-07 at 17:47 -0600, Jason L Tibbitts III wrote: > I don't want to seem to ignore your other perfectly valid arguments, > especially since one of them precisely duplicates an argument made in > my original message. I just think this needs to be treated > separately: > > >>>>> "JD" == John Dennis writes: > > JD> -1 for the Bureaucrats in People's Central Packaging Committee and > JD> their police who seek to banish me to the gulag for crimes against > JD> spec files by virtue of improper thinking ;-) > > So there's an emoticon there, but an emoticon isn't enough to hide the > fact that there's an attitude here which really needs to be dealt > with. So I'll make it plain: I am on the packaging committee. So I'll make it plain too, you led your email with this high handed introduction over a trivial issue: Jason> Frankly we expected that many Rad Hat folks would simply not Jason> want to change things, and I suppose my personal hope of not Jason> having to involve the packaging committee in making tons of Jason> trivial rules in order to force people to change things is Jason> dashed by this very thread. Honestly, what response did you expect? Did you consider you might have come across with what in your very words is "attitude here which really needs to be dealt with". Enough said. -- John Dennis From bpepple at fedoraproject.org Thu Feb 8 03:09:16 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 07 Feb 2007 22:09:16 -0500 Subject: Plan for tomorrows (20070208) FESCO meeting Message-ID: <1170904156.28453.7.camel@Chuck> Hi, Sorry about the late notice on this, but I've been sick as a dog since I've gotten back from FUDCon. 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-meeting on irc.freenode.org: /topic FESCO-Meeting -- Opening Core -- jeremy/warren -- status update /topic FESCO-Meeting -- Encourage co-maintainership -- all /topic FESCO-Meeting -- MISC -- disallow cvs-import for everything but the initial import? /topic FESCo-Meeting -- MISC -- kernel-naming - What did davej find out about this? /topic FESCO-Meeting -- MISC -- Extras 7 preparation /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop 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 wtogami at redhat.com Thu Feb 8 04:01:26 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 23:01:26 -0500 Subject: Pros & Cons of ASSIGNED pointer and NEEDINFO In-Reply-To: <45CA6D69.8090301@redhat.com> References: <45CA2DB0.7020504@redhat.com> <45CA6D69.8090301@redhat.com> Message-ID: <45CAA096.4070206@redhat.com> Jens Petersen wrote: > Warren Togami wrote: >> It seems that bouncing of the ASSIGNED pointer is a polarizing issue. >> Some people like it, some people hate it. NEEDINFO is a little less >> polarizing, although some people hate to bounce too. > > I haven't followed all the discussion but it seems to me that > >> "ASSIGNED to reviewer, use NEEDINFO as necessary" > > looks more consistent with common bugzilla process and usage. This is an uncertain point. > > Furthermore for "ASSIGNED to next actor" one has to keep > copying'n'pasting the other person's address to reassign to them which > can get pretty tedious for quick interchanges IMHO. With NEEDINFO it is > easy just to set "from Reporter" or "from Assignee" etc. > I have not heard any valid argument against "ASSIGNED to next actor" beyond this user interface problem. With the current user interface, it can be error prone if reviewers don't read and understand the written documentation. Talked a bit with dkl today about the user interface. There are potential ways to improve the user interface, but it would require Bugzilla coding that he currently doesn't have time to do. My current theory is that most complaints were not specifically about this review process sucking, but rather emotional conflating of objections to ASSIGNED bouncing with the very real brokenness CVS ACL implementation. (If you review most of the vocal list complaints, they were mostly about CVS brokenness and process regressions.) I ask that people here please consider these two processes independently. CVS is a less contentious issue, and will probably be solved sooner as there seems to be general agreement with the "CVS Admin with Flags" proposal. (Please comment there separately, as I intend on making it in effect during Thursday.) This review process I am less certain of. "ASSIGNED to next actor" has been polarizing. On one hand, some believe the benefits and the process itself is more logical. On the other hand, the user interface may make it infeasible to use because it can be error prone if done without proper training. I believe that the user interface problem is only minor. Proper training and documentation make it usable. I believe that the user interface problem is only temporary. We can craft changes to the review interface on top of Bugzilla that uses the existing database fields, but with behavior that we desire. We just have to wait a bit for dkl to get past his current major project, and use the less optimal solution in the meanwhile. Ultimately, we need to figure out if the user interface problem really is bad enough. There is no agreement on this, which is why I am asking for more opinions here. (I am also exploring an entirely different alternative to either option... but this idea is less developed at the moment. I may write about this soon if it pans out.) Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Feb 8 04:20:16 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 23:20:16 -0500 Subject: Eliminate "Bouncing" in Reviews Message-ID: <45CAA500.5080106@redhat.com> New thought. Possibly this compromise process satisfies both camps, by eliminating "bouncing" back and forth, while being assigned to the next actor, and making logical use of NEEDINFO. 1) State 1: Not Yet Reviewed ASSIGNED pointer to nobody at fedoraproject.org 2) State 2: Under Review ASSIGNED pointer to Reviewer When fedora-review? or fedora-review- Use NEEDINFO to request owner to fix something. 3) State 3: Approved ASSIGNED pointer to Owner ONLY when fedora-review+ Benefits ======== - No bouncing back and forth between reviewer and owner. - http://rubenkerkhof.com/review This page continues to show under "Assigned" who is acting. - frontpage.cgi shows both ASSIGNED and NEEDINFO for appropriate actors both during and after the review. Drawbacks ========= - You still have to set ASSIGNED to manually, but only twice. (Self, then to Owner). This is a slight annoyance that I believe we can optimize away with automation later. I suspect this logically works. I will update the full review proposal next. Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Feb 8 04:55:16 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 23:55:16 -0500 Subject: RFC: Review with Flags (Version 4) Message-ID: <45CAAD34.6020303@redhat.com> I think this procedure should be good enough for both Mass Review and general package review for an interim period, prior to a better design in Package Database. I would like to ratify this process late Thursday if possible, so please comment soon if you see problems. Changes since Version 3: ======================== - Hybrid of "ASSIGNED to next actor" and "ASSIGNED to reviewer and use NEEDINFO" as summarized in https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00252.html - Explicit description of MODIFIED and CLOSED states Fedora Review Flag States ========================= fedora-review BLANK I want a review, or a past reviewer gave up. fedora-review? Under Review, ASSIGNED to reviewer fedora-review- Denied and needs work, NEEDINFO to owner fedora-review+ APPROVED, ASSIGNED to owner Assigned Pointer ================ (Note: Assigned pointer is different from the ASSIGNED state.) - Assigned pointer to nobody at fedoraproject.org if no reviewer yet. - Assigned pointer to reviewer, during the review. - Assigned pointer to nobody if reviewer gave up. - Assigned pointer to owner, after APPROVED and fedora-review+. Bugzilla States =============== In practice a bug sitting in these states matter less than the state of the fedora-review flag. Participants are to follow these states as suggested guidelines, but the fedora-review flag has the hard requirements of behavior. NEW ASSIGNED REOPENED - There is no real distinction between these states. The flag and Assigned to pointer is what matters. - Note that ASSIGNED state is different from the Assigned pointer and has no apparent relation for our purposes. NEEDINFO - To owner or other person who needs to fix something or provide needed information in order to proceed further. MODIFIED - Owner seems to have fixed it, but it requires testing. - OPTIONAL: you don't need to use this state. It could sit in ASSIGNED where you do the same thing. - *Special Case: During the Mass Review, the fix may go into rawhide and the reviewer can verify both the CVS contents and package before giving fedora-review+. CLOSED RAWHIDE - fedora-review+ is APPROVED, CVS procedure is done, and package is built and confirmed to be done. - *Special Case*: During the Mass Review, it is fine to set to CLOSED RAWHIDE if it is confirmed to be fixed there. Please use MODIFIED prior to CLOSED RAWHIDE to allow for a verification step. Review Process ============== 1. Review Request is filed fedora-review is BLANK Assigned to nobody 2. Reviewer Takes a Request fedora-review is ? Assigned to reviewer 3a. If review denied and needs work Comment fedora-review- NEEDINFO to whoever needs to fix it. 3b. fedora-review- and owner provides fix fedora-review back to ?, to request re-review 4. If APPROVED fedora-review+ Assign to owner 5. After fedora-review+ initiate the fedora-cvs request procedure 6. After fedora-cvs procedure checkin build verify buids set to CLOSED RAWHIDE Other Possibilities =================== fedora-review? could also be used on any other Fedora bug when a horrible mess is found in an existing package, and attention for a re-review would be desired to fix it. (Good idea, bad idea?) Possible Process Optimizations ============================== 1. Changing fedora-review to ? auto-sets Assigned pointer to self. This is taking the review. 2. Changing fedora-review to + should auto-set Assigned pointer to owner. This is a little more difficult because it isn't always obvious who the owner is (especially in Mass Reviews), but this may be the reporter in regular reviews later. Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Feb 8 05:05:40 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 08 Feb 2007 00:05:40 -0500 Subject: RFC: CVS Admin with Flags (Version 1) In-Reply-To: <20070205213236.GI4858@nostromo.devel.redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> Message-ID: <45CAAFA4.7040307@redhat.com> I think this proposal generally works as-is. But perhaps we can do better with a small optimization. The reviewer setting fedora-review+ could possibly be the one who sets fedora-cvs?. This could reduce the time overhead a bit by eliminating waiting on the owner to request what they presumably they would need to do next. The only drawback of this, how does the reviewer know which branches the owner desires to build to, and who the owner wants as initial co-maintainers? A possible solution, is for the filed review itself to state these things up front. Thoughts? Unless there are any major objections, this is going ahead as the standard process during Thursday. Current Crappy CVSSyncNeeded Wiki Procedure =========================================== http://fedoraproject.org/wiki/Extras/CVSSyncNeeded 1. Request new package and branch. 2. Wait until somebody creates empty directories and edits owners.list. 3. Owner checks stuff in and builds. Using the Wiki for this process has always sucked. We could embed this process within the Bugzilla review tickets themselves. Proposal: CVS Admin with Flags ============================== 1) Review is complete, fedora-review+ 2) Owner writes in the Bugzilla comment something like: FC-5 FC-6 foopackage bobjoe bobjoebugzilla at gmail.com 3) Set fedora-cvs flag to ? 4) CVS Admins get e-mail about fedora-cvs flag. All context of the review is within the bug itself, so they can easily read all details about the package and verify approval validity. The Admin then creates CVS directories and sets owner. Sets fedora-cvs flag to BLANK. 5) Owner checks in and builds. Benefits ======== - This fedora-cvs flag eliminates the need for CVSSyncNeeded entirely. An actual work queue with tickets! - fedora-cvs can be a simple canned query for CVS admins to see. Awesome possibilities offered via RSS too... =) - You could also use the fedora-cvs flag with explicit instructions within any bug to do special requests, like: "Please remove audacious-itouch. We made some mistake. Blah blah." Notes ===== - Unlike other flags, fedora-cvs is only BLANK or ?. fedorabugs members may request fedora-cvs by setting it to ?. This sends an e-mail to CVS Admins, signifying that attention is required. Warren Togami wtogami at redhat.com From a.badger at gmail.com Thu Feb 8 05:26:42 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 07 Feb 2007 21:26:42 -0800 Subject: Problems with core review In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> Message-ID: <1170912402.4306.107.camel@localhost.localdomain> On Tue, 2007-02-06 at 10:04 -0800, Christopher Stone wrote: > 1) php-pear has a major upgrade (1.5.0) and the current version is > 1.4.11 in cvs. The 1.5.0 upgrade is going to bring on significant > changes. I am asking him to make these significant changes _before_ I > do a formal review. However, he insists that I must do my review on > the version that is currently in CVS. > If F7 is going to include 1.5.x, then this is a reasonable request. jorton, could you please upgrade or tell us why you won't upgrade now? > 2) Joe refuses to make benign trivial changes to the spec file. These > are changes that were suggested by members of the packaging committee, > for example f13 suggested to use %{SOURCEx} notation when installing > sources instead of $RPM_SOURCE_DIR. Joe refuses to make simple > changes like this and would rather bring the issues back up with the > packaging committee. I think he feels wasting the committe's time is > more important than ten seconds of his time to make the change. > According to the review bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226295 there are several of these trivial changes which are not listed in the Package guidelines. If they aren't in the Packaging Guidelines the reviewer and the maintainer can either work out what the best solution is, write a proposal for the Packaging Committee to discuss, or agree to disagree (in which case the package will need a new reviewer.) If they are in the Packaging Guidelines, then the issue needs to be addressed or a proposal needs to be sent to the Packaging Committee detailing how and why the guidelines should be changed. > 3) There is a major change that needs to be made with php-pear > package. Essentially the pear installer needs to be included as a sub > package of the main php package. This is technically required for the > new 1.5.0 upgrade in order to prevent clashing with existing packages. > The current method Joe uses lumps a ton of packages together into a > single package using a bootstrapping method which is not even > required. His excuse for not making the change is because he thinks > the pear installer needs to be updated outside of php which is not the > case. The pear installer is included as part of php from upstream and > they do that for a reason. > It looks like this was resolved in the bug report. -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 Thu Feb 8 05:33:38 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 7 Feb 2007 22:33:38 -0700 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <45CAAD34.6020303@redhat.com> References: <45CAAD34.6020303@redhat.com> Message-ID: <20070207223338.4cc99912@ningauble.scrye.com> On Wed, 07 Feb 2007 23:55:16 -0500 wtogami at redhat.com (Warren Togami) wrote: > I think this procedure should be good enough for both Mass Review and > general package review for an interim period, prior to a better > design in Package Database. I would like to ratify this process late > Thursday if possible, so please comment soon if you see problems. I like this plan very much, with one exception. (See below) > > Changes since Version 3: > ======================== > - Hybrid of "ASSIGNED to next actor" and "ASSIGNED to reviewer and > use NEEDINFO" as summarized in > https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00252.html > - Explicit description of MODIFIED and CLOSED states > > Fedora Review Flag States > ========================= > fedora-review BLANK > I want a review, or a past reviewer gave up. > fedora-review? > Under Review, ASSIGNED to reviewer > fedora-review- > Denied and needs work, NEEDINFO to owner I would very much prefer if fedora-review - flag was used when the review was totally rejected only. Ie, the license was unacceptable, or the submitter decided to withdraw the submission. > fedora-review+ > APPROVED, ASSIGNED to owner > > Assigned Pointer > ================ > (Note: Assigned pointer is different from the ASSIGNED state.) > - Assigned pointer to nobody at fedoraproject.org if no reviewer yet. > - Assigned pointer to reviewer, during the review. > - Assigned pointer to nobody if reviewer gave up. > - Assigned pointer to owner, after APPROVED and fedora-review+. > > Bugzilla States > =============== > In practice a bug sitting in these states matter less than the state > of the fedora-review flag. Participants are to follow these states > as suggested guidelines, but the fedora-review flag has the hard > requirements of behavior. > > NEW ASSIGNED REOPENED > - There is no real distinction between these states. The flag and > Assigned to pointer is what matters. > - Note that ASSIGNED state is different from the Assigned pointer and > has no apparent relation for our purposes. > > NEEDINFO > - To owner or other person who needs to fix something or provide > needed information in order to proceed further. > > MODIFIED > - Owner seems to have fixed it, but it requires testing. > - OPTIONAL: you don't need to use this state. It could sit in > ASSIGNED where you do the same thing. > - *Special Case: During the Mass Review, the fix may go into rawhide > and the reviewer can verify both the CVS contents and package before > giving fedora-review+. > > CLOSED RAWHIDE > - fedora-review+ is APPROVED, CVS procedure is done, and package is > built and confirmed to be done. > - *Special Case*: During the Mass Review, it is fine to set to CLOSED > RAWHIDE if it is confirmed to be fixed there. Please use MODIFIED > prior to CLOSED RAWHIDE to allow for a verification step. > > Review Process > ============== > 1. Review Request is filed > fedora-review is BLANK > Assigned to nobody > 2. Reviewer Takes a Request > fedora-review is ? > Assigned to reviewer > 3a. If review denied and needs work > Comment > fedora-review- > NEEDINFO to whoever needs to fix it. I see no value in flipping between - and ? on the fedora-review flag. It doesn't provide any more information really. It will often not get done by the submitter since they don't know they need to do so. It's another bugzilla knob to change on almost every exchange between submitter and reviewer. If it has a 'DENIED' email like it does now for the core reviews, it has a negative connotation and will make the submitter think they aren't getting anywhere and should just give up. > 3b. fedora-review- and owner provides fix > fedora-review back to ?, to request re-review > 4. If APPROVED > fedora-review+ > Assign to owner > 5. After fedora-review+ > initiate the fedora-cvs request procedure > 6. After fedora-cvs procedure > checkin > build > verify buids > set to CLOSED RAWHIDE > > Other Possibilities > =================== > fedora-review? could also be used on any other Fedora bug when a > horrible mess is found in an existing package, and attention for a > re-review would be desired to fix it. (Good idea, bad idea?) > > Possible Process Optimizations > ============================== > 1. Changing fedora-review to ? auto-sets Assigned pointer to self. > This is taking the review. > 2. Changing fedora-review to + should auto-set Assigned pointer to > owner. This is a little more difficult because it isn't always > obvious who the owner is (especially in Mass Reviews), but this may > be the reporter in regular reviews later. Aside from the - flag usage I like this plan quite well... Hopefully some of the folks having problems with the current plans will speak up and help it get fine tuned... kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Thu Feb 8 05:49:12 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 07 Feb 2007 21:49:12 -0800 Subject: $RPM_SOURCE_DIR (Was: Problems with core review) In-Reply-To: <1170883672.5333.462.camel@finch.boston.redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170870709.2716.401.camel@fc6.xsintricity.com> <20070207192120.GA802@redhat.com> <1170883672.5333.462.camel@finch.boston.redhat.com> Message-ID: <1170913752.4306.131.camel@localhost.localdomain> On Wed, 2007-02-07 at 16:27 -0500, John Dennis wrote: > 4) It's none of your business how I implement something as long as its > not broken. Forcing every spec file to replace $RPM_SOURCE_DIR with > $SOURCEn is consistency without merit. Ralph Waldo Emerson wrote > "foolish consistency is the hobgoblin of little minds" It's my choice as > to what constitutes a maintainable spec file based on value judgments > and experience. > It's interesting that you quote Emerson as he has several points which bear on the present discussion. Here's the paragraph the quote is from:: ''' A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do. He may as well concern himself with his shadow on the wall. Speak what you think now in hard words, and to-morrow speak what to-morrow thinks in hard words again, though it contradict every thing you said to-day. ''' In this section Emerson is not, as you imply, telling us to forgo conformity to a standard (he talks about that elsewhere in the essay), rather he is telling us not to hold ourselves hostage to our own past decisions. We should feel free to change our mind if today we don't agree with what we wrote yesterday. A "foolish consistency" is an idea or decision which we made in the past and continue to espouse even though we realize it doesn't agree with our current ideas or understanding of the situation. tibbs has already pointed out that many community reviewers have expressed a fear that Red Hat'ers will hold to their past packaging decisions so tightly that they will be unwilling to change their packages when presented with the changes that need to be made. It's still a bit early to tell if this fear is well-founded but the reviews so far make me hopeful that this is a groundless fear. I have also observed that some packagers both within and without Red Hat fear that the Packaging Committee is married to its own decisions and that there's no way to get bad decisions reverted. This is not true. If there's something in the guidelines that you think should be changed, please submit proposals for changes along with details of why the change needs to be made so that the issue can be considered. It's possible your arguments hadn't been thought of when the guideline was written and the packaging committee will remove or reword the guideline. (It's also possible that the packaging committee already discussed that aspect and felt the arugments for the other side outweighed them. Look through the mailing list archives if you want to see if that's the case.) ''' " 'Ah, so you shall be sure to be misunderstood.' " Is it so bad, then, to be misunderstood? Pythagoras was misunderstood, and Socrates, and Jesus, and Luther, and Copernicus, and Galileo, and Newton, and every pure and wise spirit that ever took flesh. To be great is to be misunderstood. ''' In the second half of this paragraph Emerson points out why it is that we, as open-source developers and packagers, need to value consistency. Consistency is an aid to understanding. It helps reviewers understand what's going on in your spec file and it helps future maintainers of the package understand that the deviations from the consistent approach were done for a good reason that they had best understand. Otherwise your important changes are lost in the noise of small, personal, stylisitc touches. -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 ville.skytta at iki.fi Thu Feb 8 07:42:56 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 8 Feb 2007 09:42:56 +0200 Subject: Plan for tomorrows (20070208) FESCO meeting In-Reply-To: <1170904156.28453.7.camel@Chuck> References: <1170904156.28453.7.camel@Chuck> Message-ID: <200702080942.56427.ville.skytta@iki.fi> On Thursday 08 February 2007 05:09, 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). Incompatible package upgrade policy. A good start that probably wouldn't stir up too heated discussions right from the start would be defining how these cases must be communicated. Recent example: http://www.redhat.com/archives/fedora-extras-list/2007-February/msg00069.html From j.w.r.degoede at hhs.nl Thu Feb 8 07:47:48 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 08 Feb 2007 08:47:48 +0100 Subject: Pros & Cons of ASSIGNED pointer and NEEDINFO In-Reply-To: <45CA2DB0.7020504@redhat.com> References: <45CA2DB0.7020504@redhat.com> Message-ID: <45CAD5A4.7040301@hhs.nl> Warren Togami wrote: > It seems that bouncing of the ASSIGNED pointer is a polarizing issue. > Some people like it, some people hate it. NEEDINFO is a little less > polarizing, although some people hate to bounce too. > I think you're mis representing the amount of people liking it. YOU seem to like the bouncing idea, other then that in the maillist discussion I've only seen people disliking it in varying degrees. Just having ASSIGNED set to the reviewer and leaving it at that has worked well for FE for years. I understand that the tracker bug doesn't scale hence the flags. But what problem with the old way of doing things are you are trying to fix here? Maybe if you can explain that, then things become more clear to the rest of us. Regards, Hans From j.w.r.degoede at hhs.nl Thu Feb 8 07:56:06 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 08 Feb 2007 08:56:06 +0100 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <45CAAD34.6020303@redhat.com> References: <45CAAD34.6020303@redhat.com> Message-ID: <45CAD796.4020306@hhs.nl> Warren Togami wrote: > I think this procedure should be good enough for both Mass Review and > general package review for an interim period, prior to a better design > in Package Database. I would like to ratify this process late Thursday > if possible, so please comment soon if you see problems. > First of all let me say that in general I like this and that I'm glad this is being refined and people are listened too. > Review Process > ============== > 1. Review Request is filed > fedora-review is BLANK > Assigned to nobody > 2. Reviewer Takes a Request > fedora-review is ? > Assigned to reviewer Can't we make this part (3a and 3b) : > 3a. If review denied and needs work > Comment > fedora-review- > NEEDINFO to whoever needs to fix it. > 3b. fedora-review- and owner provides fix > fedora-review back to ?, to request re-review Optional? For many reviews esp. of new packages there are one or 2 small items which need fixing which get fixed very fast, to me this is just unnecessary work in those case. Now for more complicated packages, reviews moving slowly this is a good idea. So why not make this optional and let the reviewer decide wether todo step 3a or not (and when 3a is done the owner is ofcourse oblidged todo 3b). > 4. If APPROVED > fedora-review+ > Assign to owner > 5. After fedora-review+ > initiate the fedora-cvs request procedure > 6. After fedora-cvs procedure > checkin > build > verify buids > set to CLOSED RAWHIDE > Regards, Hans p.s. Who gets to decide on what the final procedure will be. Currently the decission making process is very unclear. Thus FESCO get to vote on this, or some other committee? From j.w.r.degoede at hhs.nl Thu Feb 8 07:58:00 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 08 Feb 2007 08:58:00 +0100 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <20070207223338.4cc99912@ningauble.scrye.com> References: <45CAAD34.6020303@redhat.com> <20070207223338.4cc99912@ningauble.scrye.com> Message-ID: <45CAD808.9020105@hhs.nl> Kevin Fenzi wrote: > On Wed, 07 Feb 2007 23:55:16 -0500 > wtogami at redhat.com (Warren Togami) wrote: > >> Fedora Review Flag States >> ========================= >> fedora-review BLANK >> I want a review, or a past reviewer gave up. >> fedora-review? >> Under Review, ASSIGNED to reviewer >> fedora-review- >> Denied and needs work, NEEDINFO to owner > > I would very much prefer if fedora-review - flag was used when the > review was totally rejected only. Ie, the license was unacceptable, or > the submitter decided to withdraw the submission. > +1 >> Review Process >> ============== >> 1. Review Request is filed >> fedora-review is BLANK >> Assigned to nobody >> 2. Reviewer Takes a Request >> fedora-review is ? >> Assigned to reviewer >> 3a. If review denied and needs work >> Comment >> fedora-review- >> NEEDINFO to whoever needs to fix it. > > I see no value in flipping between - and ? on the fedora-review flag. > It doesn't provide any more information really. > It will often not get done by the submitter since they don't know they > need to do so. > It's another bugzilla knob to change on almost every exchange between > submitter and reviewer. > If it has a 'DENIED' email like it does now for the core reviews, it > has a negative connotation and will make the submitter think they > aren't getting anywhere and should just give up. > +1 It seems that most of us seem to think that way, but we cannot seem to get through to Warren. Warren why do you insist on this. Things were never done in FE this way. What problem with the old procedure are you trying to fix? Regards, Hans From bugs.michael at gmx.net Thu Feb 8 08:00:28 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 8 Feb 2007 09:00:28 +0100 Subject: $RPM_SOURCE_DIR (Was: Problems with core review) In-Reply-To: References: <1170777741.3333.76.camel@shalil.farsiweb.info> <45C8BEF0.2000501@redhat.com> <20070206192004.GB6857@redhat.com> <20070206203404.GC6857@redhat.com> <1170870709.2716.401.camel@fc6.xsintricity.com> <20070207192120.GA802@redhat.com> Message-ID: <20070208090028.a4bfbc4e.bugs.michael@gmx.net> On 07 Feb 2007 14:12:24 -0600, Jason L Tibbitts III wrote: > The consistency argument for using SourceN: and %{SOURCEN} tags > instead of $RPM_SOURCE_DIR is obvious. When _not_ using clean build environments, you can build an rpm with old source files in $RPM_SOURCE_DIR, which are not packaged in %SOURCE tags. So far so good. That used be one of the primary reasons why using %SOURCE tags is preferred. Recommended. Encouraged. However, when using mock or mach builds, this has become less important, although it is still a pitfall when not using clean build envs. What is left? How can you map between %SOURCE tags and files accessed directly in $RPM_SOURCE_DIR? Is rpmlint capable of checking whether all %SOURCE files are used? Even when accessed directly via $RPM_SOURCE_DIR? > Is there a technical argument for using SourceN: and %{SOURCEN} tags > instead of $RPM_SOURCE_DIR? I'm afraid I don't know it. What are the arguments for using %{SOURCEN} and only %{SOURCEN}? What are all arguments against $RPM_SOURCE_DIR? Present the full show before any of this becomes part of packaging policies. I think John Dennis has given at least one good reason that justifies why working directly within $RPM_SOURCE_DIR can be beneficial [point 1)]. As long as N is small, you can map easily between the macro and its expanded value. Still, a spec file which works on %{SOURCEN} macros is not as readable as one that uses full file names in $RPM_SOURCE_DIR. Point 2) is moot, since you can loop over %{SOURCEN} macros in the same way and even run basename %{SOURCEN} where useful. And btw, one could also do "cp %{SOURCE1} %{SOURCE2} ." and then work on the files from within $RPM_BUILD_DIR just as is done with many other extracted tarball files. From bugs.michael at gmx.net Thu Feb 8 08:14:51 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 8 Feb 2007 09:14:51 +0100 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <20070207223338.4cc99912@ningauble.scrye.com> References: <45CAAD34.6020303@redhat.com> <20070207223338.4cc99912@ningauble.scrye.com> Message-ID: <20070208091451.295de2fe.bugs.michael@gmx.net> On Wed, 7 Feb 2007 22:33:38 -0700, Kevin Fenzi wrote: > Aside from the - flag usage I like this plan quite well... > > Hopefully some of the folks having problems with the current plans will > speak up and help it get fine tuned... Well, I could think of better ways to kill my time. With project structures where some persons fill management positions, I'd like to rely on these persons in that they don't set up artificial hurdles. If we are all caught in time-consuming discussions and politics, this hurts productivity. From mtasaka at ioa.s.u-tokyo.ac.jp Thu Feb 8 08:21:12 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 08 Feb 2007 17:21:12 +0900 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <45CAD808.9020105@hhs.nl> References: <45CAAD34.6020303@redhat.com> <20070207223338.4cc99912@ningauble.scrye.com> <45CAD808.9020105@hhs.nl> Message-ID: <45CADD78.5080506@ioa.s.u-tokyo.ac.jp> Hans de Goede wrote: > Kevin Fenzi wrote: >> On Wed, 07 Feb 2007 23:55:16 -0500 >> wtogami at redhat.com (Warren Togami) wrote: >> >>> Fedora Review Flag States >>> ========================= >>> fedora-review BLANK >>> I want a review, or a past reviewer gave up. >>> fedora-review? >>> Under Review, ASSIGNED to reviewer >>> fedora-review- >>> Denied and needs work, NEEDINFO to owner >> >> I would very much prefer if fedora-review - flag was used when the >> review was totally rejected only. Ie, the license was unacceptable, or >> the submitter decided to withdraw the submission. > > +1 Rather I think that if the review must be rejected for some reason the review should be _CLOSED_ with CANTFIX or WONTFIX. Why should be the review left open? Open bug means that this bug is being in process (nor no one are taking action on the bug). So when no one can expect that the bug (review) proceeds anymore (with some reason), the bug must be closed. > >>> Review Process >>> ============== >>> 1. Review Request is filed >>> fedora-review is BLANK >>> Assigned to nobody >>> 2. Reviewer Takes a Request >>> fedora-review is ? >>> Assigned to reviewer >>> 3a. If review denied and needs work >>> Comment >>> fedora-review- >>> NEEDINFO to whoever needs to fix it. >> >> I see no value in flipping between - and ? on the fedora-review flag. >> It doesn't provide any more information really. It will often not get >> done by the submitter since they don't know they >> need to do so. It's another bugzilla knob to change on almost every >> exchange between >> submitter and reviewer. If it has a 'DENIED' email like it does now >> for the core reviews, it >> has a negative connotation and will make the submitter think they >> aren't getting anywhere and should just give up. > > +1 > And +1 Mamoru From jorton at redhat.com Thu Feb 8 09:20:25 2007 From: jorton at redhat.com (Joe Orton) Date: Thu, 8 Feb 2007 09:20:25 +0000 Subject: Problems with core review In-Reply-To: <200702071442.00862.jkeating@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <1170870709.2716.401.camel@fc6.xsintricity.com> <20070207192120.GA802@redhat.com> <200702071442.00862.jkeating@redhat.com> Message-ID: <20070208092025.GA16313@redhat.com> On Wed, Feb 07, 2007 at 02:42:00PM -0500, Jesse Keating wrote: > On Wednesday 07 February 2007 14:21, Joe Orton wrote: > > Seriously guys, I've said it two times already: if you want me to > > repaint my bikeshed, first convince the central packaging committee on > > high that your particular choice of bikeshed colour not mine must be > > mandated across the distro. Then I'll happily tow the party line; > > otherwise I'll keep my bikesheds in yellow. ?http://yellow.bikeshed.com/ > > We can't fix every single package at the same time, especially if more than > one person says "I won't change anything until every other person changes > their package.". You get two of those and you're in a deadlock. I don't follow. "packaging guideline policy" is all I'm blocked on, and that is decided by the packaging committee, not "every other person changing their package". Where is the deadlock? joe From seg at haxxed.com Thu Feb 8 11:49:51 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 08 Feb 2007 05:49:51 -0600 Subject: ACL's, Why a Big Deal? In-Reply-To: <45CA1B2C.2070906@redhat.com> References: <45CA1B2C.2070906@redhat.com> Message-ID: <1170935392.13307.42.camel@localhost.localdomain> On Wed, 2007-02-07 at 13:32 -0500, Warren Togami wrote: > 1) For all existing packages, pkg.acl file does not exist. So the > openness that existed previously DID NOT CHANGE. > > 2) For newly added packages, pkg.acl exists by default. If you as an > owner don't want such protectionism, just cvs remove it. > > 3) Owners have the *OPTION* to use a pkg.acl file to grant specific > other users access to a locked down package. Whats the big deal? Its the camel's nose in the tent, enabling selfish territorialism. -------------- 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 Feb 8 12:57:05 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 8 Feb 2007 13:57:05 +0100 Subject: Eliminate "Bouncing" in Reviews In-Reply-To: <45CAA500.5080106@redhat.com> References: <45CAA500.5080106@redhat.com> Message-ID: <20070208135705.03ab4688@ludwig-alpha.unil.ch> On Wed, 07 Feb 2007 23:20:16 -0500, Warren Togami wrote: > 1) State 1: Not Yet Reviewed > ASSIGNED pointer to nobody at fedoraproject.org Fine > 2) State 2: Under Review > ASSIGNED pointer to Reviewer > When fedora-review? or fedora-review- > Use NEEDINFO to request owner to fix something. Fine > 3) State 3: Approved > ASSIGNED pointer to Owner > ONLY when fedora-review+ I don't understand what is gained here. Why not leave the ASSIGNED to reviewer ? C From jkeating at redhat.com Thu Feb 8 13:20:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 08:20:30 -0500 Subject: Problems with core review In-Reply-To: <20070208092025.GA16313@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702071442.00862.jkeating@redhat.com> <20070208092025.GA16313@redhat.com> Message-ID: <200702080820.30965.jkeating@redhat.com> On Thursday 08 February 2007 04:20, Joe Orton wrote: > I don't follow. ?"packaging guideline policy" is all I'm blocked on, and > that is decided by the packaging committee, not "every other person > changing their package". ?Where is the deadlock? I don't see how you're blocked. The Packaging Committee has set forth a best practice in that you don't use $RPM_SOURCE_DIR, and rather you use $SOURCEx macros. For better or worse, this is the choice we've made to remain consistant across all our 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 jkeating at redhat.com Thu Feb 8 13:25:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 08:25:25 -0500 Subject: Eliminate "Bouncing" in Reviews In-Reply-To: <20070208135705.03ab4688@ludwig-alpha.unil.ch> References: <45CAA500.5080106@redhat.com> <20070208135705.03ab4688@ludwig-alpha.unil.ch> Message-ID: <200702080825.25601.jkeating@redhat.com> On Thursday 08 February 2007 07:57, Christian Iseli wrote: > > 3) State 3: Approved > > ASSIGNED pointer to Owner > > ??????ONLY when fedora-review+ > > I don't understand what is gained here. ?Why not leave the ASSIGNED to > reviewer ? Because at this point the reviewer is done. I no longer want to see things on this bug, I'm done with the review, it is now in the hands of the packager to finish the work. But *shrug* I don't really care either way. -- 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 Thu Feb 8 13:26:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 08:26:51 -0500 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <45CAD796.4020306@hhs.nl> References: <45CAAD34.6020303@redhat.com> <45CAD796.4020306@hhs.nl> Message-ID: <200702080826.51602.jkeating@redhat.com> On Thursday 08 February 2007 02:56, Hans de Goede wrote: > Who gets to decide on what the final procedure will be. Currently the > decission making process is very unclear. Thus FESCO get to vote on > this, or some other committee? I'm all for FESCO making this decision. -- 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 jorton at redhat.com Thu Feb 8 13:30:59 2007 From: jorton at redhat.com (Joe Orton) Date: Thu, 8 Feb 2007 13:30:59 +0000 Subject: Problems with core review In-Reply-To: <200702080820.30965.jkeating@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702071442.00862.jkeating@redhat.com> <20070208092025.GA16313@redhat.com> <200702080820.30965.jkeating@redhat.com> Message-ID: <20070208133059.GA18668@redhat.com> On Thu, Feb 08, 2007 at 08:20:30AM -0500, Jesse Keating wrote: > On Thursday 08 February 2007 04:20, Joe Orton wrote: > > I don't follow. ?"packaging guideline policy" is all I'm blocked on, and > > that is decided by the packaging committee, not "every other person > > changing their package". ?Where is the deadlock? > > I don't see how you're blocked. The Packaging Committee has set forth a best > practice in that you don't use $RPM_SOURCE_DIR, and rather you use $SOURCEx > macros. Use of $RPM_SOURCE_DIR is not covered in the packaging guidelines nor in the review guidelines. It's flagged by rpmlint, which, as the guidelines *do* say, is often wrong. joe From jwboyer at jdub.homelinux.org Thu Feb 8 13:28:54 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 8 Feb 2007 07:28:54 -0600 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <200702080826.51602.jkeating@redhat.com> References: <45CAAD34.6020303@redhat.com> <45CAD796.4020306@hhs.nl> <200702080826.51602.jkeating@redhat.com> Message-ID: <20070208132854.GA13072@yoda.jdub.homelinux.org> On Thu, Feb 08, 2007 at 08:26:51AM -0500, Jesse Keating wrote: > On Thursday 08 February 2007 02:56, Hans de Goede wrote: > > Who gets to decide on what the final procedure will be. Currently the > > decission making process is very unclear. Thus FESCO get to vote on > > this, or some other committee? > > I'm all for FESCO making this decision. That's fine, but I'd rather it not be at today's meeting. Let it go another week so that FESCo can review it more in depth and (more importantly) they get the "final" verison. I personally think the on-going discussions have been great. As much as possible, I want FESCo's decision to be a "rubber stamp" of what the community has already agreed on josh From jkeating at redhat.com Thu Feb 8 13:42:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 08:42:09 -0500 Subject: Problems with core review In-Reply-To: <20070208133059.GA18668@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080820.30965.jkeating@redhat.com> <20070208133059.GA18668@redhat.com> Message-ID: <200702080842.09432.jkeating@redhat.com> On Thursday 08 February 2007 08:30, Joe Orton wrote: > Use of $RPM_SOURCE_DIR is not covered in the packaging guidelines nor in > the review guidelines. ?It's flagged by rpmlint, which, as the > guidelines *do* say, is often wrong. And it has been pointed out to you many times _why_ the use of RPM_SOURCE_DIR is bad. So we didn't write a line item in the rules for that. Sorry. We also didn't write in there many other things, because we don't want a 400 item long checklist. -- 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 Thu Feb 8 13:42:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 08:42:26 -0500 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <20070208132854.GA13072@yoda.jdub.homelinux.org> References: <45CAAD34.6020303@redhat.com> <200702080826.51602.jkeating@redhat.com> <20070208132854.GA13072@yoda.jdub.homelinux.org> Message-ID: <200702080842.26462.jkeating@redhat.com> On Thursday 08 February 2007 08:28, Josh Boyer wrote: > That's fine, but I'd rather it not be at today's meeting. ?Let it go > another week so that FESCo can review it more in depth and (more > importantly) they get the "final" verison. ?I personally think the on-going > discussions have been great. ?As much as possible, I want FESCo's decision > to be a "rubber stamp" of what the community has already agreed on +1 -- 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 jorton at redhat.com Thu Feb 8 14:05:12 2007 From: jorton at redhat.com (Joe Orton) Date: Thu, 8 Feb 2007 14:05:12 +0000 Subject: Problems with core review In-Reply-To: <200702080842.09432.jkeating@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080820.30965.jkeating@redhat.com> <20070208133059.GA18668@redhat.com> <200702080842.09432.jkeating@redhat.com> Message-ID: <20070208140512.GB18668@redhat.com> On Thu, Feb 08, 2007 at 08:42:09AM -0500, Jesse Keating wrote: > On Thursday 08 February 2007 08:30, Joe Orton wrote: > > Use of $RPM_SOURCE_DIR is not covered in the packaging guidelines nor in > > the review guidelines. ?It's flagged by rpmlint, which, as the > > guidelines *do* say, is often wrong. > > And it has been pointed out to you many times _why_ the use of RPM_SOURCE_DIR > is bad. You can't have this both ways, Jesse. The packaging committee has clearly *not* agreed a policy on use of $RPM_SOURCE_DIR since the guidelines are silent on this. Do you agree with that statement? Various people have pointed out some positive and some negative aspects of $RPM_SOURCE_DIR in this thread. Do you agree with that statement? [Truly, we have become debian-devel. Congrats to all.] joe From bpepple at fedoraproject.org Thu Feb 8 14:09:20 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 08 Feb 2007 09:09:20 -0500 Subject: Plan for tomorrows (20070208) FESCO meeting In-Reply-To: <200702080942.56427.ville.skytta@iki.fi> References: <1170904156.28453.7.camel@Chuck> <200702080942.56427.ville.skytta@iki.fi> Message-ID: <1170943760.1234.1.camel@Chuck> On Thu, 2007-02-08 at 09:42 +0200, Ville Skytt? wrote: > On Thursday 08 February 2007 05:09, 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). > > Incompatible package upgrade policy. A good start that probably wouldn't stir > up too heated discussions right from the start would be defining how these > cases must be communicated. Recent example: > http://www.redhat.com/archives/fedora-extras-list/2007-February/msg00069.html Added to todays schedule. 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 Feb 8 14:11:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 08 Feb 2007 15:11:21 +0100 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <20070208132854.GA13072@yoda.jdub.homelinux.org> References: <45CAAD34.6020303@redhat.com> <45CAD796.4020306@hhs.nl> <200702080826.51602.jkeating@redhat.com> <20070208132854.GA13072@yoda.jdub.homelinux.org> Message-ID: <45CB2F89.5010906@leemhuis.info> On 08.02.2007 14:28, Josh Boyer wrote: > On Thu, Feb 08, 2007 at 08:26:51AM -0500, Jesse Keating wrote: >> On Thursday 08 February 2007 02:56, Hans de Goede wrote: >>> Who gets to decide on what the final procedure will be. Currently the >>> decission making process is very unclear. Thus FESCO get to vote on >>> this, or some other committee? >> I'm all for FESCO making this decision. > That's fine, /me agrees that it's a decision for FESCo /me at the same time really wonders why the wiki document where this needs to be integrated is protected by restricting ACLs of the Packaging Committee http://www.fedoraproject.org/wiki/Packaging/ReviewGuidelines That would indicate that it would be stuff for the Packaging Committee. But they want to concentrate around Packaging, and not Policies or Review stuff afaik In other words: We IMHO need to clearer differentiate who is responsible for what in the wiki (and in general, too). My vote: All what is handled by the Packaging Committee gets moved below Packaging/Guidelines/ in the wiki. The ACLs get adjusted, too. After that we move we can move most of the stuff from Extras/ to Packaging/ in the wiki, as that makes the most sense to me. > but I'd rather it not be at today's meeting. Let it go another > week so that FESCo can review it more in depth and (more importantly) they > get the "final" verison. +1 Cu thl From bugs.michael at gmx.net Thu Feb 8 14:30:55 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 8 Feb 2007 15:30:55 +0100 Subject: Problems with core review In-Reply-To: <200702080842.09432.jkeating@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080820.30965.jkeating@redhat.com> <20070208133059.GA18668@redhat.com> <200702080842.09432.jkeating@redhat.com> Message-ID: <20070208153055.bbeba1a4.bugs.michael@gmx.net> On Thu, 8 Feb 2007 08:42:09 -0500, Jesse Keating wrote: > On Thursday 08 February 2007 08:30, Joe Orton wrote: > > Use of $RPM_SOURCE_DIR is not covered in the packaging guidelines nor in > > the review guidelines. ?It's flagged by rpmlint, which, as the > > guidelines *do* say, is often wrong. > > And it has been pointed out to you many times _why_ the use of $RPM_SOURCE_DIR > is bad. Why is it? You put a lot of emphasis into your sentence. Instead, rehash why it is bad, please. There are pros and cons. Why do you fight $RPM_SOURCE_DIR? Why rpmlint looks out for $RPM_SOURCE_DIR becomes clear when you display its explanation. Look: $ rpmlint -I use-of-RPM_SOURCE_DIR use-of-RPM_SOURCE_DIR : You use $RPM_SOURCE_DIR or %{_sourcedir} in your spec file. If you have to use a directory for building, use $RPM_BUILD_ROOT instead. Another pitfall inexperienced packagers can run into with $RPM_SOURCE_DIR has been explained in an older message by me in this thread. Nevertheless, using $RPM_SOURCE_DIR can be beneficial in some cases. From pertusus at free.fr Thu Feb 8 14:34:45 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Feb 2007 15:34:45 +0100 Subject: Eliminate "Bouncing" in Reviews In-Reply-To: <200702080825.25601.jkeating@redhat.com> References: <45CAA500.5080106@redhat.com> <20070208135705.03ab4688@ludwig-alpha.unil.ch> <200702080825.25601.jkeating@redhat.com> Message-ID: <20070208143445.GB2836@free.fr> On Thu, Feb 08, 2007 at 08:25:25AM -0500, Jesse Keating wrote: > > Because at this point the reviewer is done. I no longer want to see things on > this bug, I'm done with the review, it is now in the hands of the packager to > finish the work. But *shrug* I don't really care either way. How is it possible to determine who reviewed the bug, in that case? -- Pat From rdieter at math.unl.edu Thu Feb 8 14:53:19 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Feb 2007 08:53:19 -0600 Subject: Eliminate "Bouncing" in Reviews In-Reply-To: <20070208143445.GB2836@free.fr> References: <45CAA500.5080106@redhat.com> <20070208135705.03ab4688@ludwig-alpha.unil.ch> <200702080825.25601.jkeating@redhat.com> <20070208143445.GB2836@free.fr> Message-ID: <45CB395F.2060409@math.unl.edu> Patrice Dumas wrote: > On Thu, Feb 08, 2007 at 08:25:25AM -0500, Jesse Keating wrote: >> Because at this point the reviewer is done. I no longer want to see things on >> this bug, I'm done with the review, it is now in the hands of the packager to >> finish the work. But *shrug* I don't really care either way. > > How is it possible to determine who reviewed the bug, in that case? Good point, currently Extras'periodically gathers review statistics, and "reviewer" statistics are based on who's assigned (afaik). If that changes, as Patrice points out, it will be different/more-difficult to determine that. -- Rex From tmraz at redhat.com Thu Feb 8 15:06:31 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 08 Feb 2007 16:06:31 +0100 Subject: Eliminate "Bouncing" in Reviews In-Reply-To: <45CB395F.2060409@math.unl.edu> References: <45CAA500.5080106@redhat.com> <20070208135705.03ab4688@ludwig-alpha.unil.ch> <200702080825.25601.jkeating@redhat.com> <20070208143445.GB2836@free.fr> <45CB395F.2060409@math.unl.edu> Message-ID: <1170947191.3182.3.camel@perun.kabelta.loc> On Thu, 2007-02-08 at 08:53 -0600, Rex Dieter wrote: > Patrice Dumas wrote: > > On Thu, Feb 08, 2007 at 08:25:25AM -0500, Jesse Keating wrote: > >> Because at this point the reviewer is done. I no longer want to see things on > >> this bug, I'm done with the review, it is now in the hands of the packager to > >> finish the work. But *shrug* I don't really care either way. > > > > How is it possible to determine who reviewed the bug, in that case? > > Good point, currently Extras'periodically gathers review statistics, and > "reviewer" statistics are based on who's assigned (afaik). If that > changes, as Patrice points out, it will be different/more-difficult to > determine that. Not so much more difficult - just who gave the + flag is the reviewer isn't it? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From jkeating at redhat.com Thu Feb 8 15:28:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 10:28:21 -0500 Subject: Problems with core review In-Reply-To: <20070208153055.bbeba1a4.bugs.michael@gmx.net> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080842.09432.jkeating@redhat.com> <20070208153055.bbeba1a4.bugs.michael@gmx.net> Message-ID: <200702081028.24514.jkeating@redhat.com> On Thursday 08 February 2007 09:30, Michael Schwendt wrote: > Why is it? You put a lot of emphasis into your sentence. Instead, rehash > why it is bad, please. There are pros and cons. Why do you fight > $RPM_SOURCE_DIR? > > Why rpmlint looks out for $RPM_SOURCE_DIR becomes clear when you > display its explanation. Look: > > ? $ rpmlint -I use-of-RPM_SOURCE_DIR > ? use-of-RPM_SOURCE_DIR : > ? You use $RPM_SOURCE_DIR or %{_sourcedir} in your spec file. If you have > to use a directory for building, use $RPM_BUILD_ROOT instead. > > Another pitfall inexperienced packagers can run into with $RPM_SOURCE_DIR > has been explained in an older message by me in this thread. Nevertheless, > using $RPM_SOURCE_DIR can be beneficial in some cases. Gee, I had assumed we were all reading along, but since you pointed it out anyway, yes, that is the main reason why we don't like RPM_SOURCE_DIR to be used. This is one of those things where it is /ok/ in some situations, not in others. By now, I really don't give a crap what Joe does in his spec, he was given reasons why RPM_SOURCE_DIR usage is bad in some cases, why we'd like things to be consistant across packages. If he /still/ doesn't want to play along, there is only so much beating you can do on a dead horse over a silly issue like this. Clearly we need to have something in the guidelines about use of RPM_SOURCE_DIR or else this will come up over and over again. However I lack the energy/time to push that through right now :/ -- 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 Thu Feb 8 15:27:16 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Feb 2007 16:27:16 +0100 Subject: Eliminate "Bouncing" in Reviews In-Reply-To: <1170947191.3182.3.camel@perun.kabelta.loc> References: <45CAA500.5080106@redhat.com> <20070208135705.03ab4688@ludwig-alpha.unil.ch> <200702080825.25601.jkeating@redhat.com> <20070208143445.GB2836@free.fr> <45CB395F.2060409@math.unl.edu> <1170947191.3182.3.camel@perun.kabelta.loc> Message-ID: <20070208152715.GD2836@free.fr> On Thu, Feb 08, 2007 at 04:06:31PM +0100, Tomas Mraz wrote: > Not so much more difficult - just who gave the + flag is the reviewer > isn't it? If it is recorded, then fine. -- Pat From bpepple at fedoraproject.org Thu Feb 8 16:07:21 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 08 Feb 2007 11:07:21 -0500 Subject: Plan for tomorrows (20070208) FESCO meeting In-Reply-To: <200702080942.56427.ville.skytta@iki.fi> References: <1170904156.28453.7.camel@Chuck> <200702080942.56427.ville.skytta@iki.fi> Message-ID: <1170950841.4996.3.camel@Chuck> On Thu, 2007-02-08 at 09:42 +0200, Ville Skytt? wrote: > On Thursday 08 February 2007 05:09, 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). > > Incompatible package upgrade policy. A good start that probably wouldn't stir > up too heated discussions right from the start would be defining how these > cases must be communicated. Recent example: > http://www.redhat.com/archives/fedora-extras-list/2007-February/msg00069.html I've been working on the Maintainer Responsibility policy for a bit, and there is a section about notifying others about changes that may affect their packages. Is this sufficient, or do you think we should address is somewhere else? http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy 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 Thu Feb 8 16:13:26 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 8 Feb 2007 17:13:26 +0100 Subject: Problems with core review In-Reply-To: <200702081028.24514.jkeating@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080842.09432.jkeating@redhat.com> <20070208153055.bbeba1a4.bugs.michael@gmx.net> <200702081028.24514.jkeating@redhat.com> Message-ID: <20070208171326.ef9b997c.bugs.michael@gmx.net> On Thu, 8 Feb 2007 10:28:21 -0500, Jesse Keating wrote: > Clearly we need to have something in the guidelines about use of > RPM_SOURCE_DIR or else this will come up over and over again. However I lack > the energy/time to push that through right now :/ The resistance you run into is a strong hint that the packaging committee ought to keep this issue out of the policies. Strong language doesn't help it. And you are right, the desire to force packagers into macro-madness and less readable spec files is "silly". History: https://www.redhat.com/archives/fedora-extras-list/2006-February/msg01242.html From jkeating at redhat.com Thu Feb 8 16:33:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 11:33:58 -0500 Subject: Problems with core review In-Reply-To: <20070208171326.ef9b997c.bugs.michael@gmx.net> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702081028.24514.jkeating@redhat.com> <20070208171326.ef9b997c.bugs.michael@gmx.net> Message-ID: <200702081133.59090.jkeating@redhat.com> On Thursday 08 February 2007 11:13, Michael Schwendt wrote: > The resistance you run into is a strong hint that the packaging committee > ought to keep this issue out of the policies. Strong language doesn't help > it. And you are right, the desire to force packagers into macro-madness > and less readable spec files is "silly". Well, given that it is an rpmlint check, we should have wording on the wiki that explains why use of it is discouraged (can hurt builds from non-clean buildroots) and what forms of it are "acceptable". -- 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 jdennis at redhat.com Thu Feb 8 17:30:26 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 08 Feb 2007 12:30:26 -0500 Subject: Problems with core review In-Reply-To: <20070208171326.ef9b997c.bugs.michael@gmx.net> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080842.09432.jkeating@redhat.com> <20070208153055.bbeba1a4.bugs.michael@gmx.net> <200702081028.24514.jkeating@redhat.com> <20070208171326.ef9b997c.bugs.michael@gmx.net> Message-ID: <1170955827.3393.88.camel@junko.usersys.redhat.com> On Thu, 2007-02-08 at 17:13 +0100, Michael Schwendt wrote: > On Thu, 8 Feb 2007 10:28:21 -0500, Jesse Keating wrote: > > > Clearly we need to have something in the guidelines about use of > > RPM_SOURCE_DIR or else this will come up over and over again. However I lack > > the energy/time to push that through right now :/ > > The resistance you run into is a strong hint that the packaging committee > ought to keep this issue out of the policies. Strong language doesn't help > it. And you are right, the desire to force packagers into macro-madness > and less readable spec files is "silly". +1 Michael echos my sentiments eloquently. There is a lack of a consensus as well as a lack of clear technical justification whose value trumps spec file readability. I applaud the goal of spec file maintainability and robustness which is the point of the review exercise, this is a good thing and I support it. However what is being expressed is forcing the use of SOURCEn is not necessarily in the service of that goal. Jessie later wrote: Jessie> Well, given that it is an rpmlint check, we should have wording Jessie> on the wiki that explains why use of it is discouraged (can Jessie> hurt builds from non-clean buildroots) and what forms of it are Jessie> "acceptable". It's presence in rpmlint is not a justification. It is true with a non-clean build root you can shoot yourself in the foot, but official builds never have that problem. In fact, if you don't use build tools there are a myriad ways you can make mistakes. Do we need a rule for every mistake one is capable of making outside the defined build environment? Let me give a further example, I'll call it "source collision". There is nothing which prevents two independent packages from using a source file with the same name. The basic default rpm macros do not enforce per package source dirs, by default all packages share a common source dir. One source rpm is capable of overwriting another source rpm's files if they share a common name. There are only three ways to prevent this: 1) establish a rule which says every source file must be prepended with a unique string (i.e. the package name). 2) always use per package source dirs. 3) always clear the src dir prior to building. Options 2 & 3 are supported by build tools, if you use them you won't have this problem. If you don't use build tools you'll have to employ technique #1 and enforce a rule with respect to unique names. Thus because it's possible when not using build tools to have name collisions producing a bad rpm. Are we now going to add a new rule? "All source files must be prepended with their package name" I doubt many people would agree that would be a wise and sensible rule to enforce but it follows logically from the above argument over forced use of $SOURCEn. The point is the guidelines should be common sense for the majority of situations and should not at the expense of the larger goal of usable/maintainable spec files seek to close every possible potential for undesired results. Readability and maintainability are more important. -- John Dennis From pertusus at free.fr Thu Feb 8 17:43:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Feb 2007 18:43:00 +0100 Subject: Problems with core review In-Reply-To: <1170955827.3393.88.camel@junko.usersys.redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080842.09432.jkeating@redhat.com> <20070208153055.bbeba1a4.bugs.michael@gmx.net> <200702081028.24514.jkeating@redhat.com> <20070208171326.ef9b997c.bugs.michael@gmx.net> <1170955827.3393.88.camel@junko.usersys.redhat.com> Message-ID: <20070208174300.GH2836@free.fr> On Thu, Feb 08, 2007 at 12:30:26PM -0500, John Dennis wrote: > > 1) establish a rule which says every source file must be prepended with > a unique string (i.e. the package name). There is no rule to enforce that, but it seems to me to be best practice and, when I don't forget I suggest the submitter to do just that. -- Pat From wtogami at redhat.com Thu Feb 8 19:14:01 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 08 Feb 2007 14:14:01 -0500 Subject: Eliminate "Bouncing" in Reviews In-Reply-To: <20070208143445.GB2836@free.fr> References: <45CAA500.5080106@redhat.com> <20070208135705.03ab4688@ludwig-alpha.unil.ch> <200702080825.25601.jkeating@redhat.com> <20070208143445.GB2836@free.fr> Message-ID: <45CB7679.4010700@redhat.com> Patrice Dumas wrote: > On Thu, Feb 08, 2007 at 08:25:25AM -0500, Jesse Keating wrote: >> Because at this point the reviewer is done. I no longer want to see things on >> this bug, I'm done with the review, it is now in the hands of the packager to >> finish the work. But *shrug* I don't really care either way. > > How is it possible to determine who reviewed the bug, in that case? > Flags have names on them. The history of the bug also tells you if someone formerly set it, and it was unset. Warren From caillon at redhat.com Thu Feb 8 19:22:48 2007 From: caillon at redhat.com (Christopher Ailllon) Date: Thu, 08 Feb 2007 14:22:48 -0500 Subject: Problems with core review In-Reply-To: <1170955827.3393.88.camel@junko.usersys.redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080842.09432.jkeating@redhat.com> <20070208153055.bbeba1a4.bugs.michael@gmx.net> <200702081028.24514.jkeating@redhat.com> <20070208171326.ef9b997c.bugs.michael@gmx.net> <1170955827.3393.88.camel@junko.usersys.redhat.com> Message-ID: <45CB7888.4020009@redhat.com> John Dennis wrote: > Let me give a further example, I'll call it "source collision". There is > nothing which prevents two independent packages from using a source file > with the same name. The basic default rpm macros do not enforce per > package source dirs, by default all packages share a common source dir. > One source rpm is capable of overwriting another source rpm's files if > they share a common name. There are only three ways to prevent this: > > 1) establish a rule which says every source file must be prepended with > a unique string (i.e. the package name). And even this would not be foolproof: a package called foo includes a source of 'bar-blah' that gets changed to 'foo-bar-blah' and then someone adds a foo-bar package with a source of 'blah'... From mtasaka at ioa.s.u-tokyo.ac.jp Thu Feb 8 19:29:51 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 09 Feb 2007 04:29:51 +0900 Subject: Eliminate "Bouncing" in Reviews In-Reply-To: <45CB7679.4010700@redhat.com> References: <45CAA500.5080106@redhat.com> <20070208135705.03ab4688@ludwig-alpha.unil.ch> <200702080825.25601.jkeating@redhat.com> <20070208143445.GB2836@free.fr> <45CB7679.4010700@redhat.com> Message-ID: <45CB7A2F.4030302@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > Patrice Dumas wrote: >> On Thu, Feb 08, 2007 at 08:25:25AM -0500, Jesse Keating wrote: >>> Because at this point the reviewer is done. I no longer want to see >>> things on this bug, I'm done with the review, it is now in the hands >>> of the packager to finish the work. But *shrug* I don't really care >>> either way. >> >> How is it possible to determine who reviewed the bug, in that case? >> > > Flags have names on them. The history of the bug also tells you if > someone formerly set it, and it was unset. Well, no... We want to check also what reviews a person approved, i.e. we want to look at once all the bugs a person approved such as http://fedoraproject.org/wiki/Extras/PackageStatus by posting a query. Checking the history, flags on each review requests is of no sense. Can this be easily done? Mamoru From mtasaka at ioa.s.u-tokyo.ac.jp Thu Feb 8 20:09:04 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 09 Feb 2007 05:09:04 +0900 Subject: Eliminate "Bouncing" in Reviews In-Reply-To: <200702080825.25601.jkeating@redhat.com> References: <45CAA500.5080106@redhat.com> <20070208135705.03ab4688@ludwig-alpha.unil.ch> <200702080825.25601.jkeating@redhat.com> Message-ID: <45CB8360.9090602@ioa.s.u-tokyo.ac.jp> Jesse Keating wrote: > On Thursday 08 February 2007 07:57, Christian Iseli wrote: >>> 3) State 3: Approved >>> ASSIGNED pointer to Owner >>> ONLY when fedora-review+ >> I don't understand what is gained here. Why not leave the ASSIGNED to >> reviewer ? > > Because at this point the reviewer is done. I no longer want to see things on > this bug, Actually there are many cases in that the review got troubled _after_ the bug was approved and the reviewer should have a responsibility for the review request until the review process ends (i.e. the bug is closed) completely IMO. Mamoru From wtogami at redhat.com Thu Feb 8 20:16:26 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 08 Feb 2007 15:16:26 -0500 Subject: Eliminate "Bouncing" in Reviews In-Reply-To: <45CB8360.9090602@ioa.s.u-tokyo.ac.jp> References: <45CAA500.5080106@redhat.com> <20070208135705.03ab4688@ludwig-alpha.unil.ch> <200702080825.25601.jkeating@redhat.com> <45CB8360.9090602@ioa.s.u-tokyo.ac.jp> Message-ID: <45CB851A.6020200@redhat.com> Mamoru Tasaka wrote: > Actually there are many cases in that the review got troubled > _after_ the bug was approved and the reviewer should have > a responsibility for the review request until the review process > ends (i.e. the bug is closed) completely IMO. > > Mamoru > Could you point at specific examples? Warren From ruben at rubenkerkhof.com Thu Feb 8 20:48:48 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Thu, 8 Feb 2007 21:48:48 +0100 Subject: Pros & Cons of ASSIGNED pointer and NEEDINFO In-Reply-To: <45CAD5A4.7040301@hhs.nl> References: <45CA2DB0.7020504@redhat.com> <45CAD5A4.7040301@hhs.nl> Message-ID: On 8-feb-2007, at 8:47, Hans de Goede wrote: > Warren Togami wrote: >> It seems that bouncing of the ASSIGNED pointer is a polarizing >> issue. Some people like it, some people hate it. NEEDINFO is a >> little less polarizing, although some people hate to bounce too. > > I think you're mis representing the amount of people liking it. YOU > seem to like the bouncing idea, other then that in the maillist > discussion I've only seen people disliking it in varying degrees. > > Just having ASSIGNED set to the reviewer and leaving it at that has > worked well for FE for years. I understand that the tracker bug > doesn't scale hence the flags. But what problem with the old way of > doing things are you are trying to fix here? Maybe if you can > explain that, then things become more clear to the rest of us. > > Regards, > > Hans > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers Does it really matter if we like it or not? We have been using it since last Saturday at Fudcon, and it works alright for now. Of course it's not perfect, and maybe the process could have been communicated better, but I (and I speak for myself here) haven't had a lot of problems with it. It's just a few mouseclicks and typing in the name of the owner in the Assigned To field. In general most of the Redhat people who's packages I reviewed understood the process as well, and if not, I just pointed them to Warren's page (http:// fedoraproject.org/wiki/warrenTogami/ReviewWithFlags) There's a relatively small amount of people working very hard to review some 1200 packages, but it seems to me there are many more people arguing about the process. I would be glad if they spend their time helping us review those package, instead of wasting time with this discussion. Just my 2 cents, Ruben From pertusus at free.fr Thu Feb 8 20:55:02 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 8 Feb 2007 21:55:02 +0100 Subject: Pros & Cons of ASSIGNED pointer and NEEDINFO In-Reply-To: References: <45CA2DB0.7020504@redhat.com> <45CAD5A4.7040301@hhs.nl> Message-ID: <20070208205501.GB2821@free.fr> On Thu, Feb 08, 2007 at 09:48:48PM +0100, Ruben Kerkhof wrote: > > I would be glad if they spend their time helping us review those > package, instead of wasting time with this discussion. If it is going to be the process for every new package entering Fedora, it is worth arguing. It is very different from what the fedora extras community is used to and it needs polishing and discussions. -- Pat From dominik at greysector.net Thu Feb 8 21:04:40 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 8 Feb 2007 22:04:40 +0100 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <45CADD78.5080506@ioa.s.u-tokyo.ac.jp> References: <45CAAD34.6020303@redhat.com> <20070207223338.4cc99912@ningauble.scrye.com> <45CAD808.9020105@hhs.nl> <45CADD78.5080506@ioa.s.u-tokyo.ac.jp> Message-ID: <20070208210440.GB11079@ryvius.pekin.waw.pl> On Thursday, 08 February 2007 at 09:21, Mamoru Tasaka wrote: > Hans de Goede wrote: > >Kevin Fenzi wrote: > >>On Wed, 07 Feb 2007 23:55:16 -0500 > >>wtogami at redhat.com (Warren Togami) wrote: > >> > >>>Fedora Review Flag States > >>>========================= > >>>fedora-review BLANK > >>> I want a review, or a past reviewer gave up. > >>>fedora-review? > >>> Under Review, ASSIGNED to reviewer > >>>fedora-review- > >>> Denied and needs work, NEEDINFO to owner > >> > >>I would very much prefer if fedora-review - flag was used when the > >>review was totally rejected only. Ie, the license was unacceptable, or > >>the submitter decided to withdraw the submission. > > > >+1 > Rather I think that if the review must be rejected for some > reason the review should be _CLOSED_ with CANTFIX or WONTFIX. > Why should be the review left open? > Open bug means that this bug is being in process (nor no > one are taking action on the bug). So when no one can expect > that the bug (review) proceeds anymore (with some reason), > the bug must be closed. +1 > >>>Review Process > >>>============== > >>>1. Review Request is filed > >>> fedora-review is BLANK > >>> Assigned to nobody > >>>2. Reviewer Takes a Request > >>> fedora-review is ? > >>> Assigned to reviewer > >>>3a. If review denied and needs work > >>> Comment > >>> fedora-review- > >>> NEEDINFO to whoever needs to fix it. > >> > >>I see no value in flipping between - and ? on the fedora-review flag. > >>It doesn't provide any more information really. It will often not get > >>done by the submitter since they don't know they > >>need to do so. It's another bugzilla knob to change on almost every > >>exchange between > >>submitter and reviewer. If it has a 'DENIED' email like it does now > >>for the core reviews, it > >>has a negative connotation and will make the submitter think they > >>aren't getting anywhere and should just give up. > > > >+1 > > > And +1 +1 too. 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 wtogami at redhat.com Thu Feb 8 21:08:46 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 08 Feb 2007 16:08:46 -0500 Subject: Pros & Cons of ASSIGNED pointer and NEEDINFO In-Reply-To: <20070208205501.GB2821@free.fr> References: <45CA2DB0.7020504@redhat.com> <45CAD5A4.7040301@hhs.nl> <20070208205501.GB2821@free.fr> Message-ID: <45CB915E.70904@redhat.com> Patrice Dumas wrote: > On Thu, Feb 08, 2007 at 09:48:48PM +0100, Ruben Kerkhof wrote: >> I would be glad if they spend their time helping us review those >> package, instead of wasting time with this discussion. > > If it is going to be the process for every new package entering Fedora, > it is worth arguing. It is very different from what the fedora extras > community is used to and it needs polishing and discussions. > Meanwhile could we please follow that proposed process for at least the merge reviews, so we make a dent in the giant pile of reviews? During the FESCO meeting today, the group requested that we continue to discuss the review process on fedora-maintainers and hopefully come to a vote during next week Thursday's FESCO meeting. Warren Togami wtogami at redhat.com From dominik at greysector.net Thu Feb 8 21:09:51 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 8 Feb 2007 22:09:51 +0100 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <45CAAD34.6020303@redhat.com> References: <45CAAD34.6020303@redhat.com> Message-ID: <20070208210951.GC11079@ryvius.pekin.waw.pl> On Thursday, 08 February 2007 at 05:55, Warren Togami wrote: > I think this procedure should be good enough for both Mass Review and > general package review for an interim period, prior to a better design > in Package Database. I would like to ratify this process late Thursday > if possible, so please comment soon if you see problems. > > Changes since Version 3: > ======================== > - Hybrid of "ASSIGNED to next actor" and "ASSIGNED to reviewer and use > NEEDINFO" as summarized in > https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00252.html > - Explicit description of MODIFIED and CLOSED states > > Fedora Review Flag States > ========================= > fedora-review BLANK > I want a review, or a past reviewer gave up. > fedora-review? > Under Review, ASSIGNED to reviewer > fedora-review- > Denied and needs work, NEEDINFO to owner No point in flipping the flag during review, NEEDINFO is enough. > fedora-review+ > APPROVED, ASSIGNED to owner Please let it stay assigned to the reviewer. How do I get a list of packages I reviewed in the past otherwise? > Assigned Pointer > ================ > (Note: Assigned pointer is different from the ASSIGNED state.) > - Assigned pointer to nobody at fedoraproject.org if no reviewer yet. > - Assigned pointer to reviewer, during the review. > - Assigned pointer to nobody if reviewer gave up. > - Assigned pointer to owner, after APPROVED and fedora-review+. See above. > Bugzilla States > =============== > In practice a bug sitting in these states matter less than the state of > the fedora-review flag. Participants are to follow these states as > suggested guidelines, but the fedora-review flag has the hard > requirements of behavior. > > NEW ASSIGNED REOPENED > - There is no real distinction between these states. The flag and > Assigned to pointer is what matters. > - Note that ASSIGNED state is different from the Assigned pointer and > has no apparent relation for our purposes. > > NEEDINFO > - To owner or other person who needs to fix something or provide needed > information in order to proceed further. > > MODIFIED > - Owner seems to have fixed it, but it requires testing. > - OPTIONAL: you don't need to use this state. It could sit in ASSIGNED > where you do the same thing. I vote for staying with ASSIGNED. > - *Special Case: During the Mass Review, the fix may go into rawhide and > the reviewer can verify both the CVS contents and package before giving > fedora-review+. > > CLOSED RAWHIDE > - fedora-review+ is APPROVED, CVS procedure is done, and package is > built and confirmed to be done. > - *Special Case*: During the Mass Review, it is fine to set to CLOSED > RAWHIDE if it is confirmed to be fixed there. Please use MODIFIED prior > to CLOSED RAWHIDE to allow for a verification step. > > Review Process > ============== > 1. Review Request is filed > fedora-review is BLANK > Assigned to nobody > 2. Reviewer Takes a Request > fedora-review is ? > Assigned to reviewer > 3a. If review denied and needs work > Comment > fedora-review- > NEEDINFO to whoever needs to fix it. > 3b. fedora-review- and owner provides fix > fedora-review back to ?, to request re-review > 4. If APPROVED > fedora-review+ > Assign to owner > 5. After fedora-review+ > initiate the fedora-cvs request procedure > 6. After fedora-cvs procedure > checkin > build > verify buids > set to CLOSED RAWHIDE > > Other Possibilities > =================== > fedora-review? could also be used on any other Fedora bug when a > horrible mess is found in an existing package, and attention for a > re-review would be desired to fix it. (Good idea, bad idea?) Good idea IMHO. > Possible Process Optimizations > ============================== > 1. Changing fedora-review to ? auto-sets Assigned pointer to self. This > is taking the review. Yes. > 2. Changing fedora-review to + should auto-set Assigned pointer to > owner. This is a little more difficult because it isn't always obvious > who the owner is (especially in Mass Reviews), but this may be the > reporter in regular reviews later. No. Leave the review assigned to the reviewer. 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 dominik at greysector.net Thu Feb 8 21:12:18 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 8 Feb 2007 22:12:18 +0100 Subject: Pros & Cons of ASSIGNED pointer and NEEDINFO In-Reply-To: <45CAA096.4070206@redhat.com> References: <45CA2DB0.7020504@redhat.com> <45CA6D69.8090301@redhat.com> <45CAA096.4070206@redhat.com> Message-ID: <20070208211218.GD11079@ryvius.pekin.waw.pl> On Thursday, 08 February 2007 at 05:01, Warren Togami wrote: > Jens Petersen wrote: > >Warren Togami wrote: > >>It seems that bouncing of the ASSIGNED pointer is a polarizing issue. > >>Some people like it, some people hate it. NEEDINFO is a little less > >>polarizing, although some people hate to bounce too. > > > >I haven't followed all the discussion but it seems to me that > > > >>"ASSIGNED to reviewer, use NEEDINFO as necessary" > > > >looks more consistent with common bugzilla process and usage. > > This is an uncertain point. Is it? > >Furthermore for "ASSIGNED to next actor" one has to keep > >copying'n'pasting the other person's address to reassign to them which > >can get pretty tedious for quick interchanges IMHO. With NEEDINFO it is > >easy just to set "from Reporter" or "from Assignee" etc. > > > > I have not heard any valid argument against "ASSIGNED to next actor" > beyond this user interface problem. With the current user interface, it > can be error prone if reviewers don't read and understand the written > documentation. I have not heard any valid argument in favour of "ASSIGNED to next actor". 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 dominik at greysector.net Thu Feb 8 21:14:47 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 8 Feb 2007 22:14:47 +0100 Subject: Pros & Cons of ASSIGNED pointer and NEEDINFO In-Reply-To: <45CB915E.70904@redhat.com> References: <45CA2DB0.7020504@redhat.com> <45CAD5A4.7040301@hhs.nl> <20070208205501.GB2821@free.fr> <45CB915E.70904@redhat.com> Message-ID: <20070208211447.GE11079@ryvius.pekin.waw.pl> On Thursday, 08 February 2007 at 22:08, Warren Togami wrote: > Patrice Dumas wrote: > >On Thu, Feb 08, 2007 at 09:48:48PM +0100, Ruben Kerkhof wrote: > >>I would be glad if they spend their time helping us review those > >>package, instead of wasting time with this discussion. > > > >If it is going to be the process for every new package entering Fedora, > >it is worth arguing. It is very different from what the fedora extras > >community is used to and it needs polishing and discussions. > > Meanwhile could we please follow that proposed process for at least the > merge reviews, so we make a dent in the giant pile of reviews? And after we do, are you going to argue that our objections have no merit because the new process is already used and "works"? I don't like being bullied into accepting unjustified changes. 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 ruben at rubenkerkhof.com Thu Feb 8 21:17:42 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Thu, 8 Feb 2007 22:17:42 +0100 Subject: Pros & Cons of ASSIGNED pointer and NEEDINFO In-Reply-To: <20070208205501.GB2821@free.fr> References: <45CA2DB0.7020504@redhat.com> <45CAD5A4.7040301@hhs.nl> <20070208205501.GB2821@free.fr> Message-ID: <319DB325-03AF-41DF-80B4-559CFC86BD38@rubenkerkhof.com> On 8-feb-2007, at 21:55, Patrice Dumas wrote: > On Thu, Feb 08, 2007 at 09:48:48PM +0100, Ruben Kerkhof wrote: >> >> I would be glad if they spend their time helping us review those >> package, instead of wasting time with this discussion. > > If it is going to be the process for every new package entering > Fedora, > it is worth arguing. It is very different from what the fedora extras > community is used to and it needs polishing and discussions. Discussing and refining the process is a good thing, I'm not arguing that. I was under the impression that this was more about how it works at the moment. I now see there's another thread where the refinement is going on, and should have read that one first. Ruben From dominik at greysector.net Thu Feb 8 21:18:05 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 8 Feb 2007 22:18:05 +0100 Subject: Eliminate "Bouncing" in Reviews In-Reply-To: <45CAA500.5080106@redhat.com> References: <45CAA500.5080106@redhat.com> Message-ID: <20070208211805.GF11079@ryvius.pekin.waw.pl> On Thursday, 08 February 2007 at 05:20, Warren Togami wrote: > New thought. > > Possibly this compromise process satisfies both camps, by eliminating > "bouncing" back and forth, while being assigned to the next actor, and > making logical use of NEEDINFO. > > 1) State 1: Not Yet Reviewed > ASSIGNED pointer to nobody at fedoraproject.org > > 2) State 2: Under Review > ASSIGNED pointer to Reviewer > When fedora-review? or fedora-review- > Use NEEDINFO to request owner to fix something. Again: shouldn't fedora-review- be a rather permanent state? I admit that I don't entirely understand the purpose of those flags, whatever they are. > 3) State 3: Approved > ASSIGNED pointer to Owner > ONLY when fedora-review+ Leave assigned to reviewer, please. It's illogical to change it. > Benefits > ======== > - No bouncing back and forth between reviewer and owner. > - http://rubenkerkhof.com/review > This page continues to show under "Assigned" who is acting. > - frontpage.cgi shows both ASSIGNED and NEEDINFO for appropriate actors > both during and after the review. Good! 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 rdieter at math.unl.edu Thu Feb 8 21:22:25 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Feb 2007 15:22:25 -0600 Subject: Pros & Cons of ASSIGNED pointer and NEEDINFO In-Reply-To: <20070208211447.GE11079@ryvius.pekin.waw.pl> References: <45CA2DB0.7020504@redhat.com> <45CAD5A4.7040301@hhs.nl> <20070208205501.GB2821@free.fr> <45CB915E.70904@redhat.com> <20070208211447.GE11079@ryvius.pekin.waw.pl> Message-ID: <45CB9491.3030106@math.unl.edu> Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 08 February 2007 at 22:08, Warren Togami wrote: >> Meanwhile could we please follow that proposed process for at least the >> merge reviews, so we make a dent in the giant pile of reviews? > And after we do, are you going to argue that our objections have no merit > because the new process is already used and "works"? I don't like being > bullied into accepting unjustified changes. Yes, you caught Warren red-handed. Bad, bad, Warren. Seriously, throw your tin-foil hat in the trash. It does not become you. -- Rex From jonathan.underwood at gmail.com Thu Feb 8 22:56:26 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 8 Feb 2007 22:56:26 +0000 Subject: Problems with core review In-Reply-To: <20070208171326.ef9b997c.bugs.michael@gmx.net> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080842.09432.jkeating@redhat.com> <20070208153055.bbeba1a4.bugs.michael@gmx.net> <200702081028.24514.jkeating@redhat.com> <20070208171326.ef9b997c.bugs.michael@gmx.net> Message-ID: <645d17210702081456n425f76a1if9c415c2f4599832@mail.gmail.com> > The resistance you run into is a strong hint that the packaging committee > ought to keep this issue out of the policies. Strong language doesn't help > it. And you are right, the desire to force packagers into macro-madness > and less readable spec files is "silly". > > History: > https://www.redhat.com/archives/fedora-extras-list/2006-February/msg01242.html (a) The goal of the packaging guidelines is to establish a consistent "dialect" of rpm-spec-speak which (i) works and (ii) makes life as simple for all extras contributors to read and maintain packages. (b) SOURCEn and RPM_SOURCE_DIR both have pros and cons, supporters and and objectors. (c) SOURCEn and RPM_SOURCE_DIR both will do the job, and so one could argue on technical merit that the choice is arbitrary. (d) Wherever there are multiple ways to do things, in order to achieve (a)(ii) above, it is helpful to establish a best practice which removes redundancy and lowers the learning curve for new contributors. (e) SOURCEn is ubiquitous within Extras packages. RPM_SOURCE_DIR is much less common. I know what conclusion I draw from these observations. Jonathan. From a.badger at gmail.com Fri Feb 9 00:02:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 08 Feb 2007 16:02:34 -0800 Subject: Core merge and Package Guidelines Message-ID: <1170979354.4306.194.camel@localhost.localdomain> Hey all, I'm trying to smooth out the process of getting changes and clarifications to the guidelines to make the Core Review process go quicker and easier. Here's what I'd like to see: if a reviewer and packager are at an impasse WRT following or not following some aspect of the Guidelines, ping me to look at it. I'll read the issue and let people know if the Guidelines cover the case and if so, whether the packager or the reviewer is currently covered. If the other party thinks the Guidelines should be changed I'll work with them to draft a policy change and then bring it up for discussion with the Packaging Committee. Remember that the burden of proof will be on the person wanting to make the changes to the Guidelines so whoever wants to go this route needs to help me provide convincing arguments as to why the policy should be changed. There's four basic ways that the Guidelines can be changed: 1) The present guideline should not apply to a package because it is a special case. We can make an exception list for these packages. 2) The present guideline poses special problems for implementation with this package at this time. We can make an exception list along with the requirements for the exception to go away. 3) The present guideline does not work for a large number of packages. We remove the guideline. 4) The present guideline does not work for a large number of packages. Since the guidelines do work for a large percentage of packages, we'll clarify wording or add text to take the new issues into account. I'm hoping to minimize the use of #1 as much as possible. #3 will probably have a hard time passing through the committee on short notice. So for the most part I'll be working with you to draft changes of type #2 or #4. The Guideline discussions will take place on #fedora-packaging on freenode and the fedora-packaging redhat.com mailing list. Thing that are controversial will probably be decided on at one of the weekly packaging meetings while those that have wide packaging committee acceptance will be voted on in the mailing list. Here's my contact info: abadger1999 on irc.freenode.net a.badger gmail.com for email. Please include the text: "[Packaging Guideline]" in the subject so I don't miss it in my deluge of email. toshio tiki-lounge.com to add me to a bugzilla ticket If there's too many requests to have guideline reviews I'll try to get others to help but for now it'll just be me. Thanks, -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 seg at haxxed.com Fri Feb 9 00:14:52 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 08 Feb 2007 18:14:52 -0600 Subject: Process Change: Package Reviews with Flags In-Reply-To: <200702071453.36654.jkeating@redhat.com> References: <45BEC555.8050908@redhat.com> <200702071318.19874.jkeating@redhat.com> <20070207194731.GA20204@ryvius.pekin.waw.pl> <200702071453.36654.jkeating@redhat.com> Message-ID: <1170980092.13307.77.camel@localhost.localdomain> On Wed, 2007-02-07 at 14:53 -0500, Jesse Keating wrote: > On Wednesday 07 February 2007 14:47, Dominik 'Rathann' Mierzejewski wrote: > > So why isn't that fixed already? > > Because CVS does this as an external program that can be ^c'd. Many people > have said they'd look into fixing it, nobody has. Okay so I haven't looked into this but does CVS honestly have no way of hooking something in to send the emails, entirely server side so that the client can't mess with it, period? Because anything less is pure crackrock. If the tools are crackrock, the solution is to fix the tools, not destroy the community by breeding paranoia and distrust. Are we or are we not switching to hg or git? I'm pretty sure they can get this right, if CVS can't. -------------- 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 Feb 9 00:55:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 8 Feb 2007 19:55:38 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <1170980092.13307.77.camel@localhost.localdomain> References: <45BEC555.8050908@redhat.com> <200702071453.36654.jkeating@redhat.com> <1170980092.13307.77.camel@localhost.localdomain> Message-ID: <200702081955.41700.jkeating@redhat.com> On Thursday 08 February 2007 19:14, Callum Lerwick wrote: > Okay so I haven't looked into this but does CVS honestly have no way of > hooking something in to send the emails, entirely server side so that > the client can't mess with it, period? Because anything less is pure > crackrock. > > If the tools are crackrock, the solution is to fix the tools, not > destroy the community by breeding paranoia and distrust. Regardless if we fix this or not, just checking emails is reactionary. Something may happen to one of my packages at 10pm EST, but I don't wake up and read email until 9am EST. That's a lot of hours for something to happen to one of my packages and for me to notice. With automated push tools, a package build could go out into the repos and be installed by who knows how many people. Relying on me being able to read email in time is not a very good prospect, as you say 'crackrock'. > Are we or are we not switching to hg or git? I'm pretty sure they can > get this right, if CVS can't. We aren't switching SCMs right now. With all the other things we're changing, this would be just too much. -- 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 Fri Feb 9 01:05:19 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Feb 2007 02:05:19 +0100 Subject: Core merge and Package Guidelines In-Reply-To: <1170979354.4306.194.camel@localhost.localdomain> References: <1170979354.4306.194.camel@localhost.localdomain> Message-ID: <20070209010519.GF2821@free.fr> On Thu, Feb 08, 2007 at 04:02:34PM -0800, Toshio Kuratomi wrote: > Hey all, > > I'm trying to smooth out the process of getting changes and > clarifications to the guidelines to make the Core Review process go > quicker and easier. Here's what I'd like to see: if a reviewer and > packager are at an impasse WRT following or not following some aspect of > the Guidelines, ping me to look at it. I'll read the issue and let I don't know if there are real impasses, but the directory owning is causing trouble -- and in most cases I agree there is a problematic situation. It has also come again and again before the merge, so maybe it won't be solved now. Solving this issue isn't necessarily only a policy issue, since it may be worked around by changes in some packages. The issue arise when a package installs something in a directory, but the package owning the directory isn't a hard requirement for the package. The typical example is for documentation. Many packages install things below /usr/share/omf/ or /usr/share/gtk-doc/ but they don't really require the 'natural' directory owner, which could be here, for example, scrollkeeper or yelp and gtk-doc or devhelp. Similar issues arise with icons, logrotate files, autoconf files. Some case aren't as clear as documentation, for example it could be arguable that automake (for aclocal) is required when autoconf macros are installed. What are exactly the guidelines or best practices? More precisely * when should directories be added to the filesystem package * when should a specific filesystem package be split out * is it right to require a application when it is mostly for dir ownership? It may happen that there is no definite response, but it would be nice if there was some agreement. For an example, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222905 There are many other examples, I could retrieve them if needed. -- Pat From tcallawa at redhat.com Fri Feb 9 01:56:27 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Thu, 08 Feb 2007 19:56:27 -0600 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <45CB2F89.5010906@leemhuis.info> References: <45CAAD34.6020303@redhat.com> <45CAD796.4020306@hhs.nl> <200702080826.51602.jkeating@redhat.com> <20070208132854.GA13072@yoda.jdub.homelinux.org> <45CB2F89.5010906@leemhuis.info> Message-ID: <1170986187.19100.9.camel@dhcp-32-109.ord.redhat.com> On Thu, 2007-02-08 at 15:11 +0100, Thorsten Leemhuis wrote: > On 08.02.2007 14:28, Josh Boyer wrote: > > On Thu, Feb 08, 2007 at 08:26:51AM -0500, Jesse Keating wrote: > >> On Thursday 08 February 2007 02:56, Hans de Goede wrote: > >>> Who gets to decide on what the final procedure will be. Currently the > >>> decission making process is very unclear. Thus FESCO get to vote on > >>> this, or some other committee? > >> I'm all for FESCO making this decision. > > That's fine, > > /me agrees that it's a decision for FESCo > > /me at the same time really wonders why the wiki document where this > needs to be integrated is protected by restricting ACLs of the Packaging > Committee > http://www.fedoraproject.org/wiki/Packaging/ReviewGuidelines > That would indicate that it would be stuff for the Packaging Committee. > But they want to concentrate around Packaging, and not Policies or > Review stuff afaik More appropriate, IMHO, is to break out the part of that document which describes the review process and put it outside the Packaging/ section. Then, that document can simply point to the review process, say, wiki/ReviewProcess . ~spot From a.badger at gmail.com Fri Feb 9 03:54:03 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 08 Feb 2007 19:54:03 -0800 Subject: Problems with core review In-Reply-To: <1170955827.3393.88.camel@junko.usersys.redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080842.09432.jkeating@redhat.com> <20070208153055.bbeba1a4.bugs.michael@gmx.net> <200702081028.24514.jkeating@redhat.com> <20070208171326.ef9b997c.bugs.michael@gmx.net> <1170955827.3393.88.camel@junko.usersys.redhat.com> Message-ID: <1170993243.4306.230.camel@localhost.localdomain> On Thu, 2007-02-08 at 12:30 -0500, John Dennis wrote: > Let me give a further example, I'll call it "source collision". There is > nothing which prevents two independent packages from using a source file > with the same name. The basic default rpm macros do not enforce per > package source dirs, by default all packages share a common source dir. > One source rpm is capable of overwriting another source rpm's files if > they share a common name. There are only three ways to prevent this: > > 1) establish a rule which says every source file must be prepended with > a unique string (i.e. the package name). > This is a de facto standard right now. > 2) always use per package source dirs. > This, along with a per user rpm build tree would be a good rpm bug to reopen once we have a new rpm maintainer. -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 rc040203 at freenet.de Fri Feb 9 04:26:27 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Feb 2007 05:26:27 +0100 Subject: Problems with core review In-Reply-To: <1170993243.4306.230.camel@localhost.localdomain> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080842.09432.jkeating@redhat.com> <20070208153055.bbeba1a4.bugs.michael@gmx.net> <200702081028.24514.jkeating@redhat.com> <20070208171326.ef9b997c.bugs.michael@gmx.net> <1170955827.3393.88.camel@junko.usersys.redhat.com> <1170993243.4306.230.camel@localhost.localdomain> Message-ID: <1170995188.31485.18.camel@mccallum.corsepiu.local> On Thu, 2007-02-08 at 19:54 -0800, Toshio Kuratomi wrote: > On Thu, 2007-02-08 at 12:30 -0500, John Dennis wrote: > > Let me give a further example, I'll call it "source collision". There is > > nothing which prevents two independent packages from using a source file > > with the same name. The basic default rpm macros do not enforce per > > package source dirs, by default all packages share a common source dir. > > One source rpm is capable of overwriting another source rpm's files if > > they share a common name. There are only three ways to prevent this: > > > > 1) establish a rule which says every source file must be prepended with > > a unique string (i.e. the package name). > > > This is a de facto standard right now. Sorry, it is not. What you say largely is a random side-effect of the fact that most tarball's names do not to conflict and to user practice (rpmbuild --rebuild or rpm -U *.src.rpm), but it does not apply to SOURCE in general. We have many scripts, patches and other files, which are likely to conflict - I have been bitten by perl*req/prov filters several times. Ralf From a.badger at gmail.com Fri Feb 9 04:40:24 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 08 Feb 2007 20:40:24 -0800 Subject: Problems with core review In-Reply-To: <1170995188.31485.18.camel@mccallum.corsepiu.local> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080842.09432.jkeating@redhat.com> <20070208153055.bbeba1a4.bugs.michael@gmx.net> <200702081028.24514.jkeating@redhat.com> <20070208171326.ef9b997c.bugs.michael@gmx.net> <1170955827.3393.88.camel@junko.usersys.redhat.com> <1170993243.4306.230.camel@localhost.localdomain> <1170995188.31485.18.camel@mccallum.corsepiu.local> Message-ID: <1170996024.4306.247.camel@localhost.localdomain> On Fri, 2007-02-09 at 05:26 +0100, Ralf Corsepius wrote: > On Thu, 2007-02-08 at 19:54 -0800, Toshio Kuratomi wrote: > > On Thu, 2007-02-08 at 12:30 -0500, John Dennis wrote: > > > Let me give a further example, I'll call it "source collision". There is > > > nothing which prevents two independent packages from using a source file > > > with the same name. The basic default rpm macros do not enforce per > > > package source dirs, by default all packages share a common source dir. > > > One source rpm is capable of overwriting another source rpm's files if > > > they share a common name. There are only three ways to prevent this: > > > > > > 1) establish a rule which says every source file must be prepended with > > > a unique string (i.e. the package name). > > > > > This is a de facto standard right now. > Sorry, it is not. > > What you say largely is a random side-effect of the fact that most > tarball's names do not to conflict and to user practice (rpmbuild > --rebuild or rpm -U *.src.rpm), but it does not apply to SOURCE in > general. > Oops. You're quite right. I was thinking of patches where 80%+ are namespaced and not %{Source}. -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 jdennis at redhat.com Fri Feb 9 05:13:21 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 09 Feb 2007 00:13:21 -0500 Subject: Problems with core review In-Reply-To: <1170993243.4306.230.camel@localhost.localdomain> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080842.09432.jkeating@redhat.com> <20070208153055.bbeba1a4.bugs.michael@gmx.net> <200702081028.24514.jkeating@redhat.com> <20070208171326.ef9b997c.bugs.michael@gmx.net> <1170955827.3393.88.camel@junko.usersys.redhat.com> <1170993243.4306.230.camel@localhost.localdomain> Message-ID: <1170998001.20058.70.camel@junko.usersys.redhat.com> On Thu, 2007-02-08 at 19:54 -0800, Toshio Kuratomi wrote: > On Thu, 2007-02-08 at 12:30 -0500, John Dennis wrote: > > 1) establish a rule which says every source file must be prepended with > > a unique string (i.e. the package name). > > > This is a de facto standard right now. Prefixing is not universal. If the decision is made to enforce use of $SOURCEn then rpmlint should also validate all source files are prefixed with their package name and enforce prefixing just like $SOURCEn would be enforced. Both represent threats of equivalent magnitude. However, I am yet to be convinced either rule needs to be enforced, using build tools obviates the need for either rule. I tend to believe the guidelines should be written with the assumption build tools will be used. But perhaps ensuring robustness with direct use of rpmbuild also needs to be taken into consideration even if it comes at the expense of other positive attributes such as readability and succinctness. My vote is fewer rules and a mandate you use sane tools. -- John Dennis From mtasaka at ioa.s.u-tokyo.ac.jp Fri Feb 9 07:07:56 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 09 Feb 2007 16:07:56 +0900 Subject: Eliminate "Bouncing" in Reviews In-Reply-To: <45CB851A.6020200@redhat.com> References: <45CAA500.5080106@redhat.com> <20070208135705.03ab4688@ludwig-alpha.unil.ch> <200702080825.25601.jkeating@redhat.com> <45CB8360.9090602@ioa.s.u-tokyo.ac.jp> <45CB851A.6020200@redhat.com> Message-ID: <45CC1DCC.1090707@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > Mamoru Tasaka wrote: > >> Actually there are many cases in that the review got troubled >> _after_ the bug was approved and the reviewer should have >> a responsibility for the review request until the review process >> ends (i.e. the bug is closed) completely IMO. >> >> Mamoru >> > > Could you point at specific examples? > > Warren Well, there are many cases. Anyway I suggest again that the reviewer should check the review to the end with responsibility until the reviewer imports the package successfully and closes the bug correctly. And... it is obvious that the person who _mainly_ has to take action after the review passed is the submitter, isn't it? Moreover I think that setting assingee as reviewer, which explicitly shows the person who reviewed the bug, makes it easier to trace the reviewes _afterwards_ by bugzilla query or some other methods. ---------------------------------------------------------- * In not a few cases some other fedora contributors (mainly sponsor members) point out the incompleteness of the reviews, and in a very rare case, the other contributor has to switch back from FE-ACCEPT to FE-REVIEW. * Once the bug was closed successfully (or because the review was rejected with some reason), however another issue is found (or the reason the reviewer rejected the review is resolved) and the bug has to be reopened. * A submitter got troubled when trying to importing a package by various reasons and asked the reviewer for a help (well, this frequently occurs especially for new contributors, i.e. a new contributor askes the reviewer, who is the sponsor of the submitter for a help). * The package the reviewer accepted will not build successfully on buildsys and the package needs more fix. Some reasons are: - Both the submitter and reviewer uses FC6, FC-devel. - Both uses only i386 (this is usually), and it turns out the mockbuild fails on x86_64 or ppc. - Simply, the mockbuild for the package is not checked (note that currently mockbuild is not forced on the review with some reason) * The submitter forgets to import the package or forgets to close the bug (this is not unusual!) and the reviewer has to ask the reviewer "what is going on?" and set NEEDINFO from the reviewer... A rare case (but I experienced) is: * The submitter accidentally(?) imports the different version of package, which leaves some issues the reviewer pointed out unfixed. and .. I may have saw some other issues... From paul at city-fan.org Fri Feb 9 10:21:00 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 09 Feb 2007 10:21:00 +0000 Subject: Problems with core review In-Reply-To: <1170998001.20058.70.camel@junko.usersys.redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080842.09432.jkeating@redhat.com> <20070208153055.bbeba1a4.bugs.michael@gmx.net> <200702081028.24514.jkeating@redhat.com> <20070208171326.ef9b997c.bugs.michael@gmx.net> <1170955827.3393.88.camel@junko.usersys.redhat.com> <1170993243.4306.230.camel@localhost.localdomain> <1170998001.20058.70.camel@junko.usersys.redhat.com> Message-ID: <45CC4B0C.1080202@city-fan.org> John Dennis wrote: > On Thu, 2007-02-08 at 19:54 -0800, Toshio Kuratomi wrote: >> On Thu, 2007-02-08 at 12:30 -0500, John Dennis wrote: >>> 1) establish a rule which says every source file must be prepended with >>> a unique string (i.e. the package name). >>> >> This is a de facto standard right now. > > Prefixing is not universal. > > If the decision is made to enforce use of $SOURCEn then rpmlint should > also validate all source files are prefixed with their package name and > enforce prefixing just like $SOURCEn would be enforced. Both represent > threats of equivalent magnitude. > > However, I am yet to be convinced either rule needs to be enforced, > using build tools obviates the need for either rule. I tend to believe > the guidelines should be written with the assumption build tools will be > used. But perhaps ensuring robustness with direct use of rpmbuild also > needs to be taken into consideration even if it comes at the expense of > other positive attributes such as readability and succinctness. > > My vote is fewer rules and a mandate you use sane tools. Assuming a sane tool such as mock might be going too far the other way though, as it eliminates the class of problems of unwanted build options. For instance, a package foo might build against library bar by default if it is present at build time, which won't be the case in a Fedora mock environment unless foo specifically buildrequires bar-devel. However, if someone was to download the SRPM and build it on their own system, it might pick up the additional library if bar-devel is installed and build a package that was different from the "official" one. So it's usual for Fedora packages to explicitly disable all build options for packages that would be "on" if a particular buildrequire is present but not used in the Fedora package, so as to have reproducible builds. Mandating sane tools would give people an excuse not to harden their packages in this way, which I think would be a bad thing. Paul. From bugs.michael at gmx.net Fri Feb 9 10:26:26 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 9 Feb 2007 11:26:26 +0100 Subject: Core merge and Package Guidelines In-Reply-To: <20070209010519.GF2821@free.fr> References: <1170979354.4306.194.camel@localhost.localdomain> <20070209010519.GF2821@free.fr> Message-ID: <20070209112626.eca5a45b.bugs.michael@gmx.net> On Fri, 9 Feb 2007 02:05:19 +0100, Patrice Dumas wrote: > I don't know if there are real impasses, but the directory owning is > causing trouble -- and in most cases I agree there is a problematic > situation. It has also come again and again before the merge, so maybe > it won't be solved now. Solving this issue isn't necessarily only a > policy issue, since it may be worked around by changes in some packages. > > The issue arise when a package installs something in a directory, but > the package owning the directory isn't a hard requirement for the > package. The typical example is for documentation. Many packages > install things below > /usr/share/omf/ > or > /usr/share/gtk-doc/ > but they don't really require the 'natural' directory owner, which could > be here, for example, scrollkeeper or yelp and gtk-doc or devhelp. > > Similar issues arise with icons, logrotate files, autoconf files. Some > case aren't as clear as documentation, for example it could be arguable > that automake (for aclocal) is required when autoconf macros are > installed. There has been some unfortunate development in that area. If memory serves correctly, we have never wanted absolutely strict ownership in those cases, at least not when we created the initial reviewing guidelines. It's not worth the effort. It would be wrong to create a dependency on an optional help viewer just to get ownership of a documentation root directory. The bad thing, however, is that orphaned directories can be created with insufficient file access permission bits when an administrator uses a restrictive umask -- can anyone confirm that this is still true in 2007? And orphaned directories are not removed during package removal. [ Maybe I'm missing something, but during installation of packages, RPM could maintain a list of orphaned directories and create them with the defattr values, so a restrictive umask does not cause them to be inaccessible by ordinary users. During package removal, it could remove such a directory if empty and if no package in the database contains it. ] Reviewers and packagers argue about /usr/share/aclocal/: $ rpm -qf /usr/share/aclocal file /usr/share/aclocal is not owned by any package $ ls /usr/share/aclocal | wc -l 15 Two cases are to distinguish here: 1) A big -devel package that ships multiple libraries and headers in versioned directories. 2) A tiny -devel package which is trivial to build with. For case 1, not using automake macros (to find the API locations, cflags and linker options) would be very unusual. Just like not running any foo-config script to retrieve the same values. In that case I would recommend a "Requires: automake". Not only to keep /usr/share/aclocal "owned", but because other packages building with the -devel package very likely would use automake anyway. For case 2, requiring automake just to get ownership of a single directory would be overhead. Unlike with pkg-config, /usr/share/aclocal is not covered by the guidelines yet, however. For files in pkg-config's directories, the original reviewing guidelines have been modified to make "Requires: pkgconfig" a MUST in Sep 2006, when .pc files are included: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines?action=diff&rev2=36&rev1=35 More important than requiring pkgconfig is to keep the .pc file dependency chains complete as else you break pkg-config queries for all installed files. And there is no alternative to "Requires: automake", when files are included in /usr/share/aclocal, because: MUST: Packages must not own files or directories already owned by other packages. Though, it's with exceptions: If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. http://fedoraproject.org/wiki/Packaging/ReviewGuidelines?action=diff&rev2=17&rev1=16 So, if a packager wants to include /usr/share/aclocal and be done, other reviewers argue about whether that is correct or good and whether it breaks "Requires: /usr/share/aclocal" or some forms of RPM queries. How to escape from this? From j.w.r.degoede at hhs.nl Fri Feb 9 10:39:36 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 09 Feb 2007 11:39:36 +0100 Subject: Core merge and Package Guidelines In-Reply-To: <20070209112626.eca5a45b.bugs.michael@gmx.net> References: <1170979354.4306.194.camel@localhost.localdomain> <20070209010519.GF2821@free.fr> <20070209112626.eca5a45b.bugs.michael@gmx.net> Message-ID: <45CC4F68.8070009@hhs.nl> Michael Schwendt wrote: > On Fri, 9 Feb 2007 02:05:19 +0100, Patrice Dumas wrote: > >> I don't know if there are real impasses, but the directory owning is >> causing trouble -- and in most cases I agree there is a problematic >> situation. It has also come again and again before the merge, so maybe >> it won't be solved now. Solving this issue isn't necessarily only a >> policy issue, since it may be worked around by changes in some packages. >> >> The issue arise when a package installs something in a directory, but >> the package owning the directory isn't a hard requirement for the >> package. The typical example is for documentation. Many packages >> install things below >> /usr/share/omf/ >> or >> /usr/share/gtk-doc/ >> but they don't really require the 'natural' directory owner, which could >> be here, for example, scrollkeeper or yelp and gtk-doc or devhelp. >> >> Similar issues arise with icons, logrotate files, autoconf files. Some >> case aren't as clear as documentation, for example it could be arguable >> that automake (for aclocal) is required when autoconf macros are >> installed. > > There has been some unfortunate development in that area. > > If memory serves correctly, we have never wanted absolutely strict > ownership in those cases, at least not when we created the initial > reviewing guidelines. > > It's not worth the effort. It would be wrong to create a dependency on an > optional help viewer just to get ownership of a documentation root > directory. > > The bad thing, however, is that orphaned directories can be created with > insufficient file access permission bits when an administrator uses a > restrictive umask -- can anyone confirm that this is still true in 2007? > And orphaned directories are not removed during package removal. > > [ Maybe I'm missing something, but during installation of packages, RPM > could maintain a list of orphaned directories and create them with the > defattr values, so a restrictive umask does not cause them to be > inaccessible by ordinary users. During package removal, it could remove > such a directory if empty and if no package in the database contains it. ] > > Reviewers and packagers argue about /usr/share/aclocal/: > > $ rpm -qf /usr/share/aclocal > file /usr/share/aclocal is not owned by any package > > $ ls /usr/share/aclocal | wc -l > 15 > > Two cases are to distinguish here: > > 1) A big -devel package that ships multiple libraries and headers in > versioned directories. > > 2) A tiny -devel package which is trivial to build with. > > For case 1, not using automake macros (to find the API locations, cflags > and linker options) would be very unusual. Just like not running any > foo-config script to retrieve the same values. In that case I would > recommend a "Requires: automake". Not only to keep /usr/share/aclocal > "owned", but because other packages building with the -devel package very > likely would use automake anyway. For case 2, requiring automake just to > get ownership of a single directory would be overhead. > > Unlike with pkg-config, /usr/share/aclocal is not covered by the > guidelines yet, however. > > For files in pkg-config's directories, the original reviewing guidelines > have been modified to make "Requires: pkgconfig" a MUST in Sep 2006, > when .pc files are included: > > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines?action=diff&rev2=36&rev1=35 > > More important than requiring pkgconfig is to keep the .pc file dependency > chains complete as else you break pkg-config queries for all installed > files. > > And there is no alternative to "Requires: automake", when files are > included in /usr/share/aclocal, because: > > MUST: Packages must not own files or directories already > owned by other packages. > > Though, it's with exceptions: > > If you feel that you have a good reason to own a file or directory > that another package owns, then please present that at package > review time. > > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines?action=diff&rev2=17&rev1=16 > > So, if a packager wants to include /usr/share/aclocal and be done, other > reviewers argue about whether that is correct or good and whether it > breaks "Requires: /usr/share/aclocal" or some forms of RPM queries. > > How to escape from this? > /usr/share/aclocal is only needed on systems with a devel environment installed so putting it in filesystem is not an option. I'm also not a fan of making packageXXX-devel require automake, because: 1) Not everyone likes autoxxx tools. I've seen and created plenty of packages without autoxxx. These packages usually do use foo-config or pkg-config in the makefile's as pkg-config and foo-config are just very handy. Actually when you've got them, there is less need for autoxxx. 2) automake puls in lots of other deps However I'm also not a fan of having multiple packages own /usr/share/aclocal So yes this is a problem indeed. I'm tending towards a automake-filesystem subpackage which owns /usr/share/aclocal and then packages who drop files there can use either: Requires: automake-filesystem (prefered as file based deps make yum slow) or: Requires: /usr/share/aclocal Regards, Hans From pknirsch at redhat.com Fri Feb 9 11:30:01 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 09 Feb 2007 12:30:01 +0100 Subject: Review question about /var/log/* files. Message-ID: <45CC5B39.5020607@redhat.com> Hi folks. During the review of one of my packages (acpid) a question popped up for the logfile that acpid generates in /var/log/acpid Should the package own this file (using %ghost voodoo) or not? I've checked the http://fedoraproject.org/wiki/Packaging/ReviewGuidelines and couldn't find any reference to logfiles there. My personal opinion would be that it depends on whether this logfile is directly connected to 1 package or not. Take for example /var/log/messages. Loads of applications, demons, kernel and whatnots log stuff in there. So no clear association to one package can be done, ergo it shouldn't be owned by one random package that writes in there and be owner less. On the other hand there are some very clear and defined logfiles that get written to by only one application. /var/log/scrollkeeper.log or the /var/log/acpid files come to my mind. For those i'd argue that, due to the nature of those logfiles being directly associated with one specific package and only one package ever writing to them. It would be great if this could be discussed at the next meeting and some conclusion be added to the Review Guidelines. Thanks, Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From twaugh at redhat.com Fri Feb 9 11:34:12 2007 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 09 Feb 2007 11:34:12 +0000 Subject: Move gutenprint from Extras into Core? In-Reply-To: <200611061329.48722.jkeating@redhat.com> References: <1162837098.3474.2.camel@cyberelk.elk> <200611061329.48722.jkeating@redhat.com> Message-ID: <1171020852.5784.1.camel@cyberelk.elk> On Mon, 2006-11-06 at 13:29 -0500, Jesse Keating wrote: > Please wait until after the Fedora Summit (see > fedora-advisory-board at redhat.com list for details) for any core<->extras > shuffling. So, somehow F7test1 ended up with gimp-print included and not gutenprint. What needs to happen to fix this? We should not be shipping gimp-print; instead we should use gutenprint. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at fedoraproject.org Fri Feb 9 12:12:35 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 9 Feb 2007 07:12:35 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-02-09 Message-ID: <20070209121235.D504615212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) libxslt FC6-updates > FC7 (0:1.1.20-1.fc6 > 0:1.1.20-1) logrotate FC6-updates > FC7 (0:3.7.4-12.fc6 > 0:3.7.4-11.fc7) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) samba FC5-updates > FC7 (0:3.0.24-1.fc5 > 0:3.0.23c-2) FC6-updates > FC7 (0:3.0.24-1.fc6 > 0:3.0.23c-2) screen FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) cgoorah AT yahoo.com.au: kdmtheme FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) 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) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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: 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) 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) gemi AT bluewin.ch: genius FE5 > FE7 (0:0.7.7-1.fc5 > 0:0.7.6.1-3.fc6) FE6 > FE7 (0:0.7.7-1.fc6 > 0:0.7.6.1-3.fc6) jfontain AT free.fr: moomps FE5 > FE7 (0:5.8-2.fc5 > 0:5.8-1.fc7) FE6 > FE7 (0:5.8-2.fc6 > 0:5.8-1.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) lists AT forevermore.net: yafc FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.fc6) mdehaan AT redhat.com: cobbler FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.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 linux.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) ynakam AT hitachisoft.jp: seedit FE6 > FE7 (0:2.1.0-3.fc6 > 0:2.1.0-2.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.fc6) 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) 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) genius: gemi AT bluewin.ch FE5 > FE7 (0:0.7.7-1.fc5 > 0:0.7.6.1-3.fc6) FE6 > FE7 (0:0.7.7-1.fc6 > 0:0.7.6.1-3.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) 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) kdmtheme: cgoorah AT yahoo.com.au FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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) logrotate: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.7.4-12.fc6 > 0:3.7.4-11.fc7) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) moomps: jfontain AT free.fr FE5 > FE7 (0:5.8-2.fc5 > 0:5.8-1.fc7) FE6 > FE7 (0:5.8-2.fc6 > 0:5.8-1.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) samba: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.0.24-1.fc5 > 0:3.0.23c-2) FC6-updates > FC7 (0:3.0.24-1.fc6 > 0:3.0.23c-2) screen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) seahorse: skvidal AT linux.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) seedit: ynakam AT hitachisoft.jp FE6 > FE7 (0:2.1.0-3.fc6 > 0:2.1.0-2.fc7) 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) 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) yafc: lists AT forevermore.net FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.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 sgrubb at redhat.com Fri Feb 9 12:50:03 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 9 Feb 2007 07:50:03 -0500 Subject: Review question about /var/log/* files. In-Reply-To: <45CC5B39.5020607@redhat.com> References: <45CC5B39.5020607@redhat.com> Message-ID: <200702090750.03415.sgrubb@redhat.com> On Friday 09 February 2007 06:30, Phil Knirsch wrote: > Should the package own this file (using %ghost voodoo) or not? What about the rotated files? > Take for example /var/log/messages. Loads of applications, demons, > kernel and whatnots log stuff in there. So no clear association to one > package can be done, ergo it shouldn't be owned by one random package > that writes in there and be owner less. syslogd would be the clear owner of that file in addition to maillog, secure, cron, spooler, boot, ... -Steve From bkoz at redhat.com Fri Feb 9 13:06:18 2007 From: bkoz at redhat.com (Benjamin Kosnik) Date: Fri, 09 Feb 2007 14:06:18 +0100 Subject: Move gutenprint from Extras into Core? In-Reply-To: <1171020852.5784.1.camel@cyberelk.elk> References: <1162837098.3474.2.camel@cyberelk.elk> <200611061329.48722.jkeating@redhat.com> <1171020852.5784.1.camel@cyberelk.elk> Message-ID: <45CC71CA.2080100@redhat.com> Tim Waugh wrote: > On Mon, 2006-11-06 at 13:29 -0500, Jesse Keating wrote: >> Please wait until after the Fedora Summit (see >> fedora-advisory-board at redhat.com list for details) for any core<->extras >> shuffling. > > So, somehow F7test1 ended up with gimp-print included and not > gutenprint. > > What needs to happen to fix this? We should not be shipping gimp-print; > instead we should use gutenprint. I noticed that the gutenprint rpms as packaged pull in some gimp-print bits. ie on FC6: %rpm -qa | grep gutenprint gutenprint-5.0.0-0.16.fc6 gutenprint-cups-5.0.0-0.16.fc6 gutenprint-ppds-es-5.0.0-0.16.fc6 %rpm -qa | grep gimp-print gimp-print-4.2.7-23.fc6 gimp-print-plugin-4.2.7-23.fc6 gimp-print-utils-4.2.7-23.fc6 gimp-print-cups-4.2.7-23.fc6 Removing gimp-print: %yum remove gimp-print gimp-print-cups gimp-print-utils gimp-print-plugin gimp-print Gives: Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Removing: gimp-print i386 4.2.7-23.fc6 installed 4.1 M gimp-print-cups i386 4.2.7-23.fc6 installed 28 M gimp-print-plugin i386 4.2.7-23.fc6 installed 95 k gimp-print-utils i386 4.2.7-23.fc6 installed 35 k Removing for dependencies: gimp i386 2:2.2.13-1.fc6 installed 25 M gimp-data-extras noarch 2.0.1-1.1.1 installed 7.6 M gimp-help noarch 2-0.1.0.10.1.1 installed 64 M gutenprint-cups i386 5.0.0-0.16.fc6 installed 6.2 M -benjamin From twaugh at redhat.com Fri Feb 9 13:07:29 2007 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 09 Feb 2007 13:07:29 +0000 Subject: Move gutenprint from Extras into Core? In-Reply-To: <45CC71CA.2080100@redhat.com> References: <1162837098.3474.2.camel@cyberelk.elk> <200611061329.48722.jkeating@redhat.com> <1171020852.5784.1.camel@cyberelk.elk> <45CC71CA.2080100@redhat.com> Message-ID: <1171026449.5784.3.camel@cyberelk.elk> On Fri, 2007-02-09 at 14:06 +0100, Benjamin Kosnik wrote: > I noticed that the gutenprint rpms as packaged pull in some gimp-print > bits. > > ie on FC6: Yes, on FC6, necessarily. Not in F7. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri Feb 9 13:15:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Feb 2007 08:15:27 -0500 Subject: Move gutenprint from Extras into Core? In-Reply-To: <1171020852.5784.1.camel@cyberelk.elk> References: <1162837098.3474.2.camel@cyberelk.elk> <200611061329.48722.jkeating@redhat.com> <1171020852.5784.1.camel@cyberelk.elk> Message-ID: <200702090815.27144.jkeating@redhat.com> On Friday 09 February 2007 06:34, Tim Waugh wrote: > So, somehow F7test1 ended up with gimp-print included and not > gutenprint. > > What needs to happen to fix this? ?We should not be shipping gimp-print; > instead we should use gutenprint. Er, gutenprint was in the manifest, in the spin as well. What we probably forgot to do was mark gutenprint as a default in comps, while making gimp-print optional. Sorry about that. I've just made the change in comps. -- 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 Fri Feb 9 13:21:25 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Feb 2007 14:21:25 +0100 Subject: Core merge and Package Guidelines In-Reply-To: <45CC4F68.8070009@hhs.nl> References: <1170979354.4306.194.camel@localhost.localdomain> <20070209010519.GF2821@free.fr> <20070209112626.eca5a45b.bugs.michael@gmx.net> <45CC4F68.8070009@hhs.nl> Message-ID: <1171027286.31485.110.camel@mccallum.corsepiu.local> On Fri, 2007-02-09 at 11:39 +0100, Hans de Goede wrote: > Michael Schwendt wrote: > > On Fri, 9 Feb 2007 02:05:19 +0100, Patrice Dumas wrote: > > > >> I don't know if there are real impasses, but the directory owning is > >> causing trouble -- and in most cases I agree there is a problematic > >> situation. It has also come again and again before the merge, so maybe > >> it won't be solved now. Solving this issue isn't necessarily only a > >> policy issue, since it may be worked around by changes in some packages. > >> > >> The issue arise when a package installs something in a directory, but > >> the package owning the directory isn't a hard requirement for the > >> package. The typical example is for documentation. Many packages > >> install things below > >> /usr/share/omf/ > >> or > >> /usr/share/gtk-doc/ > >> but they don't really require the 'natural' directory owner, which could > >> be here, for example, scrollkeeper or yelp and gtk-doc or devhelp. > >> > >> Similar issues arise with icons, logrotate files, autoconf files. Some > >> case aren't as clear as documentation, for example it could be arguable > >> that automake (for aclocal) is required when autoconf macros are > >> installed. > > > > There has been some unfortunate development in that area. > > > > If memory serves correctly, we have never wanted absolutely strict > > ownership in those cases, at least not when we created the initial > > reviewing guidelines. But we always have wanted to have clean package removals. > > It's not worth the effort. It would be wrong to create a dependency on an > > optional help viewer just to get ownership of a documentation root > > directory. > > > > The bad thing, however, is that orphaned directories can be created with > > insufficient file access permission bits when an administrator uses a > > restrictive umask -- can anyone confirm that this is still true in 2007? > > And orphaned directories are not removed during package removal. > > > > [ Maybe I'm missing something, but during installation of packages, RPM > > could maintain a list of orphaned directories and create them with the > > defattr values, so a restrictive umask does not cause them to be > > inaccessible by ordinary users. During package removal, it could remove > > such a directory if empty and if no package in the database contains it. ] > > > > Reviewers and packagers argue about /usr/share/aclocal/: Well, this is just a popular and commonly met example for a far more general problem: plugins/drop-in-packages Examples: * *.pc and pkgconfig (Almost identical situation as with automake, default search directory, used by one application one) * "/usr/share/mozilla/plugin", way more complicated. Being used by several applications (mozilla, firefox, seamonkey etc). * dlopen'ed DSOs expected under certain paths (The same situation as mozilla-plugins, but more general) * scripting-language-modules (E.g. perl) - No strict hierarchy between modules. Unique to /usr/share/aclocal is: * /usr/share/aclocal does NOT have to be part of the automake package!! /usr/share/aclocal is the default directory aclocal looks into for *.m4 macros NOT owned by the automake package itself. * /usr/share/aclocal is only used by aclocal by no other applications (except may-be some RAD-GUI tools) * /usr/share/aclocal actually is part of the subsystem used by the application "aclocal". It is NOT part of the application "automake"! > > $ rpm -qf /usr/share/aclocal > > file /usr/share/aclocal is not owned by any package > > > > $ ls /usr/share/aclocal | wc -l > > 15 > > > > Two cases are to distinguish here: > > > > 1) A big -devel package that ships multiple libraries and headers in > > versioned directories. > > > > 2) A tiny -devel package which is trivial to build with. > > > > For case 1, not using automake macros (to find the API locations, cflags > > and linker options) would be very unusual. Just like not running any > > foo-config script to retrieve the same values. In that case I would > > recommend a "Requires: automake". Not only to keep /usr/share/aclocal > > "owned", but because other packages building with the -devel package very > > likely would use automake anyway. For case 2, requiring automake just to > > get ownership of a single directory would be overhead. > > > > Unlike with pkg-config, /usr/share/aclocal is not covered by the > > guidelines yet, however. Yes, but the situation of automake is too similar to pkg-config to justify this deviation. > > And there is no alternative to "Requires: automake", when files are > > included in /usr/share/aclocal, because: > > > > MUST: Packages must not own files or directories already > > owned by other packages. IMNSHO, this rule is simply wrong. It's nothing else but a fallback rule, which fails in many cases. > > Though, it's with exceptions: > > > > If you feel that you have a good reason to own a file or directory > > that another package owns, then please present that at package > > review time. > > > > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines?action=diff&rev2=17&rev1=16 > > > > So, if a packager wants to include /usr/share/aclocal and be done, other > > reviewers argue about whether that is correct or good and whether it > > breaks "Requires: /usr/share/aclocal" or some forms of RPM queries. > > > > How to escape from this? Depends on which problem you want to solve: * Simple installation, pulling in the infrastructure a package optionally supports, rsp. brings a package into "usable shape". => This can be approached by the same approach as it is being applied by pkgconfig: Any package installing a /usr/share/aclocal/*.m4 file must require "automake". * Clean rpm-installation/package removal => One option is the same approach as it is being applied to perl-modules: "Any directory under /usr/lib/perl* which is not part of the basesystem and the base-perl package must be owned by the perl-module" > /usr/share/aclocal is only needed on systems with a devel environment > installed so putting it in filesystem is not an option. I'm also not a > fan of making packageXXX-devel require automake, because: > 1) Not everyone likes autoxxx tools. I've seen and created plenty of > packages without autoxxx. These packages usually do use foo-config or > pkg-config in the makefile's as pkg-config and foo-config are just > very handy. Actually when you've got them, there is less need for > autoxxx. I am not a fan of double standards => I am strongly opposed to implementing an automake specific rule. We need a systematic general approach. > 2) automake puls in lots of other deps This simply is not true. automake doesn't pull in a lot of deps. I only has two major dependencies: autoconf and perl. All the rest is a standard POSIX/GNU devel environment a developer will have installed in any case. > However I'm also not a fan of having multiple packages own > /usr/share/aclocal > So yes this is a problem indeed. I'm tending towards a > automake-filesystem subpackage which owns /usr/share/aclocal and then > packages who drop files there can use either: > Requires: automake-filesystem (prefered as file based deps make yum slow) Well, IMO, the latter is a design flaw in yum, but this would be a different topic. > or: > Requires: /usr/share/aclocal This will break "Joe Random Developer"'s request for "simple installation", and will cause rpm issues (To be verified if they still are present). Ralf From rc040203 at freenet.de Fri Feb 9 13:28:37 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Feb 2007 14:28:37 +0100 Subject: Review question about /var/log/* files. In-Reply-To: <200702090750.03415.sgrubb@redhat.com> References: <45CC5B39.5020607@redhat.com> <200702090750.03415.sgrubb@redhat.com> Message-ID: <1171027717.31485.119.camel@mccallum.corsepiu.local> On Fri, 2007-02-09 at 07:50 -0500, Steve Grubb wrote: > On Friday 09 February 2007 06:30, Phil Knirsch wrote: > > Should the package own this file (using %ghost voodoo) or not? > > What about the rotated files? If you know their exact names ..., why not also %ghost them? But there is the question of whether log-files (and others below /var) shall be deleted upon package removal rsp. upon package installation at all ... I think there is a "grey zone". On one hand, you often don't want to loose your logs just because you had to temporarily remove a package during an update (make them % config .. ?) on the other hand, probably everybody having upgraded a Linux system or having used Linux over longer period is fighting with stray logs having accumulated (and other files below /var) Ralf From pertusus at free.fr Fri Feb 9 13:53:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Feb 2007 14:53:36 +0100 Subject: Review question about /var/log/* files. In-Reply-To: <1171027717.31485.119.camel@mccallum.corsepiu.local> References: <45CC5B39.5020607@redhat.com> <200702090750.03415.sgrubb@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> Message-ID: <20070209135336.GA2979@free.fr> On Fri, Feb 09, 2007 at 02:28:37PM +0100, Ralf Corsepius wrote: > On Fri, 2007-02-09 at 07:50 -0500, Steve Grubb wrote: > > On Friday 09 February 2007 06:30, Phil Knirsch wrote: > > > Should the package own this file (using %ghost voodoo) or not? > > > > What about the rotated files? > If you know their exact names ..., why not also %ghost them? The local admin could have made changes to the logrotate rules. > On one hand, you often don't want to loose your logs just because you > had to temporarily remove a package during an update (make them % > config .. ?) on the other hand, probably everybody having upgraded a > Linux system or having used Linux over longer period is fighting with > stray logs having accumulated (and other files below /var) I think that the log should never be removed automatically, it should be left to the admin. If the package is removed they shouldn't grow anymore anyway. -- Pat From pknirsch at redhat.com Fri Feb 9 14:23:58 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 09 Feb 2007 15:23:58 +0100 Subject: Question about userdel/groupdel usage in uninstall scripts Message-ID: <45CC83FE.7020006@redhat.com> Hi folks. And another question for the next meeting, this time about the use of userdel and groupdel in scripts after removal of a package. I suspect for users/groups in the 1-100 uid/gid range this is not a problem, but removing any users or groups that were added without a specific uid or gid can be a security issue as those ids might get reused for accounts that were added later. Fedora Core doesn't contain any bad cases, but i've already spotted a few ones in Fedora Extras. So for a Package Review and Guideline that might be something we want to take a look at for new packages or (if we ever do that) for a FC-Extras review. Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From sgrubb at redhat.com Fri Feb 9 14:22:46 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 9 Feb 2007 09:22:46 -0500 Subject: Review question about /var/log/* files. In-Reply-To: <20070209135336.GA2979@free.fr> References: <45CC5B39.5020607@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> <20070209135336.GA2979@free.fr> Message-ID: <200702090922.47033.sgrubb@redhat.com> On Friday 09 February 2007 08:53, Patrice Dumas wrote: > > > What about the rotated files? > > > > If you know their exact names ..., why not also %ghost them? > > The local admin could have made changes to the logrotate rules. Right, that was my point in mentioning rotated logs. The admin could have set the number of kept logs to 20. So, the question is why should 1 file be ghosted when you have this open ended rotate question? -Steve From pknirsch at redhat.com Fri Feb 9 14:37:02 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 09 Feb 2007 15:37:02 +0100 Subject: Review question about /var/log/* files. In-Reply-To: <200702090922.47033.sgrubb@redhat.com> References: <45CC5B39.5020607@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> <20070209135336.GA2979@free.fr> <200702090922.47033.sgrubb@redhat.com> Message-ID: <45CC870E.3080702@redhat.com> Steve Grubb wrote: > On Friday 09 February 2007 08:53, Patrice Dumas wrote: >>>> What about the rotated files? >>> If you know their exact names ..., why not also %ghost them? >> The local admin could have made changes to the logrotate rules. > > Right, that was my point in mentioning rotated logs. The admin could have set > the number of kept logs to 20. So, the question is why should 1 file be > ghosted when you have this open ended rotate question? > Thats a real good point. No package pwning^H^H^H^H^H^H owning any logfiles in /var/log/ sounds more and more reasonable. Directories there are a different matter as they clearly are connected to a specific package. Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From rc040203 at freenet.de Fri Feb 9 14:45:04 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Feb 2007 15:45:04 +0100 Subject: Review question about /var/log/* files. In-Reply-To: <45CC870E.3080702@redhat.com> References: <45CC5B39.5020607@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> <20070209135336.GA2979@free.fr> <200702090922.47033.sgrubb@redhat.com> <45CC870E.3080702@redhat.com> Message-ID: <1171032304.31485.136.camel@mccallum.corsepiu.local> On Fri, 2007-02-09 at 15:37 +0100, Phil Knirsch wrote: > Steve Grubb wrote: > > On Friday 09 February 2007 08:53, Patrice Dumas wrote: > >>>> What about the rotated files? > >>> If you know their exact names ..., why not also %ghost them? > >> The local admin could have made changes to the logrotate rules. > > > > Right, that was my point in mentioning rotated logs. The admin could have set > > the number of kept logs to 20. So, the question is why should 1 file be > > ghosted when you have this open ended rotate question? > > > > Thats a real good point. No package pwning^H^H^H^H^H^H owning any > logfiles in /var/log/ sounds more and more reasonable. Directories there > are a different matter as they clearly are connected to a specific package. I would not put it so strictly, I'd prefer handling this on a case-by-case basis. Another question would be: Why does a service need a separate log file system at all? IMO, it should be preferable to have services use syslogd (when applicable). [But more annoying than /var/log/* files, are package leaving trash behind elsewhere in /var/* upon package removal] Ralf From sgrubb at redhat.com Fri Feb 9 15:02:36 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 9 Feb 2007 10:02:36 -0500 Subject: Review question about /var/log/* files. In-Reply-To: <1171032304.31485.136.camel@mccallum.corsepiu.local> References: <45CC5B39.5020607@redhat.com> <45CC870E.3080702@redhat.com> <1171032304.31485.136.camel@mccallum.corsepiu.local> Message-ID: <200702091002.36923.sgrubb@redhat.com> On Friday 09 February 2007 09:45, Ralf Corsepius wrote: > Another question would be: Why does a service need a separate log file > system at all? Because it clutters up the logs. Would you want every apache access in /var/log/messages? Every xinetd connection in the same place? > IMO, it should be preferable to have services use syslogd > (when applicable). I think that's the key - when applicable. Not everything needs to go to syslog as it may not be important in a general sense. And then there are times when syslog doesn't meet the requirements. -Steve From jdennis at redhat.com Fri Feb 9 15:21:18 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 09 Feb 2007 10:21:18 -0500 Subject: Review question about /var/log/* files. In-Reply-To: <1171032304.31485.136.camel@mccallum.corsepiu.local> References: <45CC5B39.5020607@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> <20070209135336.GA2979@free.fr> <200702090922.47033.sgrubb@redhat.com> <45CC870E.3080702@redhat.com> <1171032304.31485.136.camel@mccallum.corsepiu.local> Message-ID: <1171034478.5333.470.camel@finch.boston.redhat.com> On Fri, 2007-02-09 at 15:45 +0100, Ralf Corsepius wrote: > Another question would be: Why does a service need a separate log file > system at all? IMO, it should be preferable to have services use syslogd > (when applicable). You want separate log files because some services log more than an occasional message and because you want all these messages grouped together. Email logging is a good example. Once you establish a need for independent log files then FHS requires independent directories owned by the service. We have a goal to be FHS compliant. -- 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 rdieter at math.unl.edu Fri Feb 9 15:27:26 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 09 Feb 2007 09:27:26 -0600 Subject: Review question about /var/log/* files. In-Reply-To: <20070209135336.GA2979@free.fr> References: <45CC5B39.5020607@redhat.com> <200702090750.03415.sgrubb@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> <20070209135336.GA2979@free.fr> Message-ID: <45CC92DE.7010407@math.unl.edu> Patrice Dumas wrote: > On Fri, Feb 09, 2007 at 02:28:37PM +0100, Ralf Corsepius wrote: >> On Fri, 2007-02-09 at 07:50 -0500, Steve Grubb wrote: >>> On Friday 09 February 2007 06:30, Phil Knirsch wrote: >>>> Should the package own this file (using %ghost voodoo) or not? >>> What about the rotated files? >> If you know their exact names ..., why not also %ghost them? > > The local admin could have made changes to the logrotate rules. > >> On one hand, you often don't want to loose your logs just because you >> had to temporarily remove a package during an update (make them % ... > I think that the log should never be removed automatically, +1. That was the general consensus of the PC discussion around the general issue of "no unowned files", that log files are a reasonable exception and should be unowned (and not removed on pkg erasure). Unfortunately, no policy statement came of out that. -- Rex From rdieter at math.unl.edu Fri Feb 9 15:32:07 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 09 Feb 2007 09:32:07 -0600 Subject: Review question about /var/log/* files. In-Reply-To: <45CC92DE.7010407@math.unl.edu> References: <45CC5B39.5020607@redhat.com> <200702090750.03415.sgrubb@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> <20070209135336.GA2979@free.fr> <45CC92DE.7010407@math.unl.edu> Message-ID: <45CC93F7.90506@math.unl.edu> Rex Dieter wrote: > +1. That was the general consensus of the PC discussion around the > general issue of "no unowned files", that log files are a reasonable > exception and should be unowned (and not removed on pkg erasure). ^^^^^^^^^^^^^^^^^ arg, make that "should *not* be owned". -- Rex From rc040203 at freenet.de Fri Feb 9 15:37:14 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Feb 2007 16:37:14 +0100 Subject: Review question about /var/log/* files. In-Reply-To: <1171034478.5333.470.camel@finch.boston.redhat.com> References: <45CC5B39.5020607@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> <20070209135336.GA2979@free.fr> <200702090922.47033.sgrubb@redhat.com> <45CC870E.3080702@redhat.com> <1171032304.31485.136.camel@mccallum.corsepiu.local> <1171034478.5333.470.camel@finch.boston.redhat.com> Message-ID: <1171035436.31485.149.camel@mccallum.corsepiu.local> On Fri, 2007-02-09 at 10:21 -0500, John Dennis wrote: > On Fri, 2007-02-09 at 15:45 +0100, Ralf Corsepius wrote: > > Another question would be: Why does a service need a separate log file > > system at all? IMO, it should be preferable to have services use syslogd > > (when applicable). > > You want separate log files because some services log more than an > occasional message and because you want all these messages grouped > together. Email logging is a good example. no disagreement. > Once you establish a need for independent log files then FHS requires > independent directories owned by the service. Hmm, that's news to me - Any pointer? All I can find[1] is this: /var/log : Log files and directories Purpose This directory contains miscellaneous log files. Most logs must be written to this directory or an appropriate subdirectory. Ralf [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOGLOGFILESANDDIRECTORIES > We have a goal to be FHS compliant. From kevin at tummy.com Fri Feb 9 16:25:20 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Fri, 9 Feb 2007 09:25:20 -0700 Subject: Review question about /var/log/* files. In-Reply-To: <45CC870E.3080702@redhat.com> References: <45CC5B39.5020607@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> <20070209135336.GA2979@free.fr> <200702090922.47033.sgrubb@redhat.com> <45CC870E.3080702@redhat.com> Message-ID: <20070209092520.14e3f5dd@ningauble.scrye.com> On Fri, 09 Feb 2007 15:37:02 +0100 pknirsch at redhat.com (Phil Knirsch) wrote: > Steve Grubb wrote: > > On Friday 09 February 2007 08:53, Patrice Dumas wrote: > >>>> What about the rotated files? > >>> If you know their exact names ..., why not also %ghost them? > >> The local admin could have made changes to the logrotate rules. > > > > Right, that was my point in mentioning rotated logs. The admin > > could have set the number of kept logs to 20. So, the question is > > why should 1 file be ghosted when you have this open ended rotate > > question? > > > > Thats a real good point. No package pwning^H^H^H^H^H^H owning any > logfiles in /var/log/ sounds more and more reasonable. Directories > there are a different matter as they clearly are connected to a > specific package. Yeah, I agree. I guess in this case you could make acpid use a /var/log/acpid/ but not sure if that would really provide any advantages. The dir will always have log files (some number based on logrotate) and won't get removed on package removal either. One nice advantage of having the log file as you do now is that a rpm query will tell you what package owns it. I think that information is pretty obvious most of the time however. From looking at the input here, I think the thing to do would be drop the /var/log/acpid from files for now. > Read ya, Phil kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Feb 9 16:27:54 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 9 Feb 2007 11:27:54 -0500 Subject: Move gutenprint from Extras into Core? In-Reply-To: <1171026449.5784.3.camel@cyberelk.elk> References: <1162837098.3474.2.camel@cyberelk.elk> <200611061329.48722.jkeating@redhat.com> <1171020852.5784.1.camel@cyberelk.elk> <45CC71CA.2080100@redhat.com> <1171026449.5784.3.camel@cyberelk.elk> Message-ID: <20070209162754.GA22763@nostromo.devel.redhat.com> Tim Waugh (twaugh at redhat.com) said: > On Fri, 2007-02-09 at 14:06 +0100, Benjamin Kosnik wrote: > > I noticed that the gutenprint rpms as packaged pull in some gimp-print > > bits. > > > > ie on FC6: > > Yes, on FC6, necessarily. Not in F7. AFAICT, the gutenprint stuff we have in F7 does *not* obsolete all of gimp-print: [notting at nostromo: ~]$ rpm -q gutenprint gutenprint-5.0.0-4.fc7 [notting at nostromo: ~]$ rpm -qa | grep gimp-print gimp-print-4.2.7-24.fc7 Is this intentional? Bill From roozbeh at farsiweb.info Fri Feb 9 16:31:24 2007 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Fri, 09 Feb 2007 20:01:24 +0330 Subject: Problems with core review In-Reply-To: <20070208140512.GB18668@redhat.com> References: <1170777741.3333.76.camel@shalil.farsiweb.info> <200702080820.30965.jkeating@redhat.com> <20070208133059.GA18668@redhat.com> <200702080842.09432.jkeating@redhat.com> <20070208140512.GB18668@redhat.com> Message-ID: <1171038684.3295.10.camel@shalil.farsiweb.info> On Thu, 2007-02-08 at 14:05 +0000, Joe Orton wrote: > [Truly, we have become debian-devel. Congrats to all.] I definitely agree. debian-devel is baaad... (read in the style of South Park's Mr Mackey) Roozbeh From notting at redhat.com Fri Feb 9 16:35:49 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 9 Feb 2007 11:35:49 -0500 Subject: Core merge and Package Guidelines In-Reply-To: <1171027286.31485.110.camel@mccallum.corsepiu.local> References: <1170979354.4306.194.camel@localhost.localdomain> <20070209010519.GF2821@free.fr> <20070209112626.eca5a45b.bugs.michael@gmx.net> <45CC4F68.8070009@hhs.nl> <1171027286.31485.110.camel@mccallum.corsepiu.local> Message-ID: <20070209163549.GB22763@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > * Clean rpm-installation/package removal > > => One option is the same approach as it is being applied to > perl-modules: "Any directory under /usr/lib/perl* which is not part of > the basesystem and the base-perl package must be owned by the > perl-module" Just patch RPM to unlink-but-no-error-if-failed up the filesystem directory tree on removal. Bill From kwade at redhat.com Fri Feb 9 16:50:35 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 09 Feb 2007 08:50:35 -0800 Subject: easy-as-pie release notes Message-ID: <1171039835.3265.57.camel@erato.phig.org> Friends: You are the developers and package maintainers closest to the work and testing. You are the best people to highlight your project's changes, successes, and testing needs via the release notes. The earlier we get content in, the fewer changes by test3; life is happier for the translators and editors, and for the community, too. Did you know it is brain-dead simple to submit content?[1] These are in order of best to least best: 1. Edit the content directly within the appropriate beat at http://fedoraproject.org/wiki/Docs/Beats. 2. Email relnotes at fedoraproject.org. 3. Add relnotes at fedoraproject.org as a Cc: in an existing bug report. 4. Enter any release note requests, comments, etc. into this pre-filled bugzilla request; http://tinyurl.com/33y7bf. (NOTE: This Bugzilla link is NOT for problems with Fedora software, only for problems with the release notes themselves.) 5. Include the *docs* keyword in your CVS commit log. Each of your projects needs to take responsibility to provide continuous and final content for the release notes. By sharing the load, we exponentially increase the quality and decrease the work. [1] http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process#submitting - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 jdennis at redhat.com Fri Feb 9 17:07:03 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 09 Feb 2007 12:07:03 -0500 Subject: Review question about /var/log/* files. In-Reply-To: <1171035436.31485.149.camel@mccallum.corsepiu.local> References: <45CC5B39.5020607@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> <20070209135336.GA2979@free.fr> <200702090922.47033.sgrubb@redhat.com> <45CC870E.3080702@redhat.com> <1171032304.31485.136.camel@mccallum.corsepiu.local> <1171034478.5333.470.camel@finch.boston.redhat.com> <1171035436.31485.149.camel@mccallum.corsepiu.local> Message-ID: <1171040823.5333.491.camel@finch.boston.redhat.com> On Fri, 2007-02-09 at 16:37 +0100, Ralf Corsepius wrote: > On Fri, 2007-02-09 at 10:21 -0500, John Dennis wrote: > > Once you establish a need for independent log files then FHS requires > > independent directories owned by the service. > Hmm, that's news to me - Any pointer? > > All I can find[1] is this: > > /var/log : Log files and directories > Purpose > This directory contains miscellaneous log files. Most logs must be > written to this directory or an appropriate subdirectory. 'Requires' was too strong, here are the reasons it's recommended, some of it from FHS, some as a consequence of SELinux. FHS requires independent package subdirs for /var/lib, /var/opt. FHS recommends independent package subdirs for /etc, /etc/opt, /opt, /usr/share, /var/run, /usr/lib The spirit of FHS is if a package has more than a few files it should be locating those files in subdirs owned by the package. You are absolutely correct, in the case of /var/log it is not mandated a per package subdir be used but when the entire FHS is taken as a whole you can see it follows as a recommendation. Also, SELinux policy prefers package files be located in directories owned by the package as it makes file labeling easier to specify and maintain. -- 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 twaugh at redhat.com Fri Feb 9 17:16:20 2007 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 09 Feb 2007 17:16:20 +0000 Subject: Move gutenprint from Extras into Core? In-Reply-To: <20070209162754.GA22763@nostromo.devel.redhat.com> References: <1162837098.3474.2.camel@cyberelk.elk> <200611061329.48722.jkeating@redhat.com> <1171020852.5784.1.camel@cyberelk.elk> <45CC71CA.2080100@redhat.com> <1171026449.5784.3.camel@cyberelk.elk> <20070209162754.GA22763@nostromo.devel.redhat.com> Message-ID: <1171041380.5784.7.camel@cyberelk.elk> On Fri, 2007-02-09 at 11:27 -0500, Bill Nottingham wrote: > AFAICT, the gutenprint stuff we have in F7 does *not* obsolete all > of gimp-print: > > [notting at nostromo: ~]$ rpm -q gutenprint > gutenprint-5.0.0-4.fc7 > [notting at nostromo: ~]$ rpm -qa | grep gimp-print > gimp-print-4.2.7-24.fc7 > > Is this intentional? No. Should be fixed in 5.0.0-5.fc7, building now. Thanks for spotting it. Thanks, Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From overholt at redhat.com Fri Feb 9 19:42:19 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 9 Feb 2007 14:42:19 -0500 Subject: Odd licenses Message-ID: <20070209194218.GI1706@redhat.com> Hi, I'm currently trying to do to the merge review for adaptx [1] but the license field is troubling: Exolab Software License A google query gives this page (in the cache): http://209.85.165.104/search?q=cache:kh3l7BHsrJsJ:freshmeat.net/releases/3417/+exolab+osi&hl=en&ct=clnk&cd=7&gl=us&lr=lang_en|lang_fr&client=firefox-a Which seems to imply that the license [2] is BSD. It does indeed look quite BSD-ish to me but what should the license field have? Is this okay from a legal standpoint? Spot? 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 overholt at redhat.com Fri Feb 9 19:43:50 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 9 Feb 2007 14:43:50 -0500 Subject: Odd licenses In-Reply-To: <20070209194218.GI1706@redhat.com> References: <20070209194218.GI1706@redhat.com> Message-ID: <20070209194350.GJ1706@redhat.com> Sorry, I forgot to include the links. Full text below. Merge review for adaptx [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225238 adaptx license.txt [2] http://svn.codehaus.org/castor/adaptx/trunk/src/doc/license.txt * Andrew Overholt [2007-02-09 14:42]: > Hi, > > I'm currently trying to do to the merge review for adaptx [1] but the > license field is troubling: > > Exolab Software License > > A google query gives this page (in the cache): > > http://209.85.165.104/search?q=cache:kh3l7BHsrJsJ:freshmeat.net/releases/3417/+exolab+osi&hl=en&ct=clnk&cd=7&gl=us&lr=lang_en|lang_fr&client=firefox-a > > Which seems to imply that the license [2] is BSD. It does indeed look > quite BSD-ish to me but what should the license field have? Is this > okay from a legal standpoint? Spot? > > 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 dennis at ausil.us Fri Feb 9 19:47:09 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 9 Feb 2007 13:47:09 -0600 Subject: Odd licenses In-Reply-To: <20070209194350.GJ1706@redhat.com> References: <20070209194218.GI1706@redhat.com> <20070209194350.GJ1706@redhat.com> Message-ID: <200702091347.09412.dennis@ausil.us> On Friday 09 February 2007 13:43, Andrew Overholt wrote: > > > > Which seems to imply that the license [2] is BSD. It does indeed look > > quite BSD-ish to me but what should the license field have? Is this > > okay from a legal standpoint? Spot? Best bet is to ask the FSF for clarification. -- Dennis Gilmore, RHCE From pertusus at free.fr Fri Feb 9 19:48:33 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Feb 2007 20:48:33 +0100 Subject: Odd licenses In-Reply-To: <20070209194350.GJ1706@redhat.com> References: <20070209194218.GI1706@redhat.com> <20070209194350.GJ1706@redhat.com> Message-ID: <20070209194833.GF2979@free.fr> On Fri, Feb 09, 2007 at 02:43:50PM -0500, Andrew Overholt wrote: > adaptx license.txt > [2] > http://svn.codehaus.org/castor/adaptx/trunk/src/doc/license.txt This seems to be BSD-like to me. There is condition that I dislike, because it doesn't have an obvious meaning (a clause similar is often seen on scientific packages): 5. Due credit should be given to the ExoLab Group (http://www.exolab.org). It doesn't explain when credit is "due", how credit should be given. Is it for the use, the redistribution, both? I don't think this is a blocker, though. My interpretation is that having this license in the package is enough. -- Pat From overholt at redhat.com Fri Feb 9 19:58:16 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 9 Feb 2007 14:58:16 -0500 Subject: Odd licenses In-Reply-To: <200702091347.09412.dennis@ausil.us> References: <20070209194218.GI1706@redhat.com> <20070209194350.GJ1706@redhat.com> <200702091347.09412.dennis@ausil.us> Message-ID: <20070209195816.GM1706@redhat.com> * Dennis Gilmore [2007-02-09 14:47]: > On Friday 09 February 2007 13:43, Andrew Overholt wrote: > > > > > > > Which seems to imply that the license [2] is BSD. It does indeed look > > > quite BSD-ish to me but what should the license field have? Is this > > > okay from a legal standpoint? Spot? > Best bet is to ask the FSF for clarification. I don't want to wait that long. Didn't Spot and others do a review a few months ago? Was this issue looked at then? 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 overholt at redhat.com Fri Feb 9 19:58:57 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 9 Feb 2007 14:58:57 -0500 Subject: Odd licenses In-Reply-To: <20070209194833.GF2979@free.fr> References: <20070209194218.GI1706@redhat.com> <20070209194350.GJ1706@redhat.com> <20070209194833.GF2979@free.fr> Message-ID: <20070209195855.GN1706@redhat.com> * Patrice Dumas [2007-02-09 14:51]: > On Fri, Feb 09, 2007 at 02:43:50PM -0500, Andrew Overholt wrote: > > adaptx license.txt > > [2] > > http://svn.codehaus.org/castor/adaptx/trunk/src/doc/license.txt > > This seems to be BSD-like to me. There is condition that I dislike, > because it doesn't have an obvious meaning (a clause similar is often > seen on scientific packages): > > 5. Due credit should be given to the ExoLab Group (http://www.exolab.org). > > It doesn't explain when credit is "due", how credit should be given. > Is it for the use, the redistribution, both? I don't think this is a > blocker, though. My interpretation is that having this license in the > package is enough. Okay, so what should License: be? 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 dennis at ausil.us Fri Feb 9 20:08:20 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 9 Feb 2007 14:08:20 -0600 Subject: Odd licenses In-Reply-To: <20070209195816.GM1706@redhat.com> References: <20070209194218.GI1706@redhat.com> <200702091347.09412.dennis@ausil.us> <20070209195816.GM1706@redhat.com> Message-ID: <200702091408.21022.dennis@ausil.us> On Friday 09 February 2007 13:58, Andrew Overholt wrote: > * Dennis Gilmore [2007-02-09 14:47]: > > On Friday 09 February 2007 13:43, Andrew Overholt wrote: > > > > Which seems to imply that the license [2] is BSD. It does indeed > > > > look quite BSD-ish to me but what should the license field have? Is > > > > this okay from a legal standpoint? Spot? > > > > Best bet is to ask the FSF for clarification. > > I don't want to wait that long. Didn't Spot and others do a review a > few months ago? Was this issue looked at then? Yes spot looked at all licenses in core not long ago. So its probably ok. AFAIK FSF has been very responsive to license clarification requests -- Dennis Gilmore, RHCE From ville.skytta at iki.fi Fri Feb 9 20:09:30 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 9 Feb 2007 22:09:30 +0200 Subject: Question about userdel/groupdel usage in uninstall scripts In-Reply-To: <45CC83FE.7020006@redhat.com> References: <45CC83FE.7020006@redhat.com> Message-ID: <200702092209.31097.ville.skytta@iki.fi> On Friday 09 February 2007 16:23, Phil Knirsch wrote: > And another question for the next meeting, this time about the use of > userdel and groupdel in scripts after removal of a package. Yep, that's already on the packaging committee's TODO list; coming up with a discussion draft is currently assigned to me: http://fedoraproject.org/wiki/Packaging/GuidelinesTodo I hope I'll find time for that before the Feb 20th meeting, if not the 13th. Discussion/help before that is of course welcome too. From ville.skytta at iki.fi Fri Feb 9 20:22:14 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 9 Feb 2007 22:22:14 +0200 Subject: Plan for tomorrows (20070208) FESCO meeting In-Reply-To: <1170950841.4996.3.camel@Chuck> References: <1170904156.28453.7.camel@Chuck> <200702080942.56427.ville.skytta@iki.fi> <1170950841.4996.3.camel@Chuck> Message-ID: <200702092222.14521.ville.skytta@iki.fi> On Thursday 08 February 2007 18:07, Brian Pepple wrote: > On Thu, 2007-02-08 at 09:42 +0200, Ville Skytt? wrote: > > > > Incompatible package upgrade policy. A good start that probably wouldn't > > stir up too heated discussions right from the start would be defining how > > these cases must be communicated. Recent example: > > http://www.redhat.com/archives/fedora-extras-list/2007-February/msg00069. > >html > > I've been working on the Maintainer Responsibility policy for a bit, and > there is a section about notifying others about changes that may affect > their packages. Is this sufficient, or do you think we should address > is somewhere else? > > http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy I think that's a good start, but it lacks two key bits: 1) Where to send the announcement. There is a note about that being dependent on mailing list reorganization, but IMNSHO it shouldn't wait for that - just specify a list where to send them for now. This list would be a natural candidate, but AFAIK non-Fedora-maintainers can't post here which is a drawback (think non-critical update and 3rd party repos not being able to update dependent packages in the planned timeframe due to whatever reason and wanting to discuss that in public). I tend to think that this is acceptable for an interim solution before the ML reorganization is finished. 2) When to send the announcement. I think something like one week would be a good default; if later, do it as early as possible. And another last heads up note on the day the update is actually going to be built. From fnasser at redhat.com Fri Feb 9 20:42:10 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 09 Feb 2007 15:42:10 -0500 Subject: Question about userdel/groupdel usage in uninstall scripts In-Reply-To: <45CC83FE.7020006@redhat.com> References: <45CC83FE.7020006@redhat.com> Message-ID: <45CCDCA2.3040306@redhat.com> Phil Knirsch wrote: > Hi folks. > > And another question for the next meeting, this time about the use of > userdel and groupdel in scripts after removal of a package. > > I suspect for users/groups in the 1-100 uid/gid range this is not a > problem, but removing any users or groups that were added without a > specific uid or gid can be a security issue as those ids might get > reused for accounts that were added later. > And for the 1-100 uid/gid range what is the use of removing it? IMO userdel/groupdel should never, ever be used. Regards, Fernando From bpepple at fedoraproject.org Fri Feb 9 20:47:08 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 09 Feb 2007 15:47:08 -0500 Subject: Plan for tomorrows (20070208) FESCO meeting In-Reply-To: <200702092222.14521.ville.skytta@iki.fi> References: <1170904156.28453.7.camel@Chuck> <200702080942.56427.ville.skytta@iki.fi> <1170950841.4996.3.camel@Chuck> <200702092222.14521.ville.skytta@iki.fi> Message-ID: <1171054028.12951.3.camel@Chuck> On Fri, 2007-02-09 at 22:22 +0200, Ville Skytt? wrote: > On Thursday 08 February 2007 18:07, Brian Pepple wrote: > > On Thu, 2007-02-08 at 09:42 +0200, Ville Skytt? wrote: > > > > > > Incompatible package upgrade policy. A good start that probably wouldn't > > > stir up too heated discussions right from the start would be defining how > > > these cases must be communicated. Recent example: > > > http://www.redhat.com/archives/fedora-extras-list/2007-February/msg00069. > > >html > > > > I've been working on the Maintainer Responsibility policy for a bit, and > > there is a section about notifying others about changes that may affect > > their packages. Is this sufficient, or do you think we should address > > is somewhere else? > > > > http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy > > I think that's a good start, but it lacks two key bits: > > 1) Where to send the announcement. There is a note about that being dependent > on mailing list reorganization, but IMNSHO it shouldn't wait for that - just > specify a list where to send them for now. This list would be a natural > candidate, but AFAIK non-Fedora-maintainers can't post here which is a > drawback (think non-critical update and 3rd party repos not being able to > update dependent packages in the planned timeframe due to whatever reason and > wanting to discuss that in public). I tend to think that this is acceptable > for an interim solution before the ML reorganization is finished. I agree for now fedora-maintainers should work, and once the mailing list is reorganized we can always update it. > 2) When to send the announcement. I think something like one week would be a > good default; if later, do it as early as possible. And another last heads > up note on the day the update is actually going to be built. Those are good suggestions, and I'll update the Maintainer responsibility policy accordingly. 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 Fri Feb 9 21:30:01 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 9 Feb 2007 23:30:01 +0200 Subject: Process Change: Package Reviews with Flags In-Reply-To: <20070207162239.00701744@ningauble.scrye.com> References: <45BEC555.8050908@redhat.com> <200702071644.21672.jkeating@redhat.com> <20070207162239.00701744@ningauble.scrye.com> Message-ID: <200702092330.01687.ville.skytta@iki.fi> On Thursday 08 February 2007 01:22, Kevin Fenzi wrote: > commitinfo is run before the files are commited, so if they stopped it, > then they would have no commited files. It might be that there is less > info available at that point, but I would fine also with 2 emails... I'm afraid doubling the number of mails sent to that list would have a considerable negative effect on the number of people actually watching it. From fnasser at redhat.com Fri Feb 9 21:48:38 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Fri, 09 Feb 2007 16:48:38 -0500 Subject: Merge Review build step is redundant? Message-ID: <45CCEC36.3040002@redhat.com> When reviewing a new package one needs to assert if the submitted SRPM really builds, so there is a step for the reviwer that consists in actually trying to build the package. But for the packages of the "Merge Review" type, that are already built in Core, isn't this step unnecessary? Fernando From ville.skytta at iki.fi Fri Feb 9 21:49:08 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 9 Feb 2007 23:49:08 +0200 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <45CAAD34.6020303@redhat.com> References: <45CAAD34.6020303@redhat.com> Message-ID: <200702092349.08257.ville.skytta@iki.fi> On Thursday 08 February 2007 06:55, Warren Togami wrote: > I think this procedure should be good enough for both Mass Review and > general package review for an interim period, prior to a better design > in Package Database. I would like to ratify this process late Thursday > if possible, so please comment soon if you see problems. Just a quick note / implementation detail: > Possible Process Optimizations > ============================== > 1. Changing fedora-review to ? auto-sets Assigned pointer to self. This > is taking the review. > 2. Changing fedora-review to + should auto-set Assigned pointer to > owner. This is a little more difficult because it isn't always obvious > who the owner is (especially in Mass Reviews), but this may be the > reporter in regular reviews later. 3. Bugzilla needs to be fixed not to send two mails every time a flag changes state. Random example: http://www.redhat.com/archives/fedora-package-review/2007-February/msg01538.html http://www.redhat.com/archives/fedora-package-review/2007-February/msg01539.html From dwalsh at redhat.com Fri Feb 9 21:55:03 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 09 Feb 2007 16:55:03 -0500 Subject: Review question about /var/log/* files. In-Reply-To: <1171034478.5333.470.camel@finch.boston.redhat.com> References: <45CC5B39.5020607@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> <20070209135336.GA2979@free.fr> <200702090922.47033.sgrubb@redhat.com> <45CC870E.3080702@redhat.com> <1171032304.31485.136.camel@mccallum.corsepiu.local> <1171034478.5333.470.camel@finch.boston.redhat.com> Message-ID: <45CCEDB7.4080505@redhat.com> John Dennis wrote: > On Fri, 2007-02-09 at 15:45 +0100, Ralf Corsepius wrote: > >> Another question would be: Why does a service need a separate log file >> system at all? IMO, it should be preferable to have services use syslogd >> (when applicable). >> > > You want separate log files because some services log more than an > occasional message and because you want all these messages grouped > together. Email logging is a good example. > > Once you establish a need for independent log files then FHS requires > independent directories owned by the service. We have a goal to be FHS > compliant. > Also independent directories make SELinux a lot happier. From wtogami at redhat.com Fri Feb 9 21:56:58 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 09 Feb 2007 16:56:58 -0500 Subject: Review question about /var/log/* files. In-Reply-To: <45CC870E.3080702@redhat.com> References: <45CC5B39.5020607@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> <20070209135336.GA2979@free.fr> <200702090922.47033.sgrubb@redhat.com> <45CC870E.3080702@redhat.com> Message-ID: <45CCEE2A.2020807@redhat.com> Phil Knirsch wrote: > Steve Grubb wrote: >> On Friday 09 February 2007 08:53, Patrice Dumas wrote: >>>>> What about the rotated files? >>>> If you know their exact names ..., why not also %ghost them? >>> The local admin could have made changes to the logrotate rules. >> >> Right, that was my point in mentioning rotated logs. The admin could >> have set the number of kept logs to 20. So, the question is why should >> 1 file be ghosted when you have this open ended rotate question? >> > > Thats a real good point. No package pwning^H^H^H^H^H^H owning any > logfiles in /var/log/ sounds more and more reasonable. Directories there > are a different matter as they clearly are connected to a specific package. > > Read ya, Phil > I always understood that /var/log was supposed to be write-only by the respective applications, while other tools like logrotate and logwatch allowed processing activities. It seems inappropriate to me to have a RPM package remove logs that from its perspective were supposed to be write-only? Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Feb 9 21:59:02 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 09 Feb 2007 16:59:02 -0500 Subject: Odd licenses In-Reply-To: <20070209194833.GF2979@free.fr> References: <20070209194218.GI1706@redhat.com> <20070209194350.GJ1706@redhat.com> <20070209194833.GF2979@free.fr> Message-ID: <45CCEEA6.4040509@redhat.com> Patrice Dumas wrote: > On Fri, Feb 09, 2007 at 02:43:50PM -0500, Andrew Overholt wrote: >> adaptx license.txt >> [2] >> http://svn.codehaus.org/castor/adaptx/trunk/src/doc/license.txt > > This seems to be BSD-like to me. There is condition that I dislike, > because it doesn't have an obvious meaning (a clause similar is often > seen on scientific packages): > > 5. Due credit should be given to the ExoLab Group (http://www.exolab.org). > > It doesn't explain when credit is "due", how credit should be given. > Is it for the use, the redistribution, both? I don't think this is a > blocker, though. My interpretation is that having this license in the > package is enough. > "should" is also open to interpretation. It makes it sound like a suggestion but not a requirement. The key question of whether this is GPL compatible or not, is if this counts as an "additional requirement" or not. It is unclear if this is even a requirement. Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Feb 9 22:11:25 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 09 Feb 2007 17:11:25 -0500 Subject: RFC: Review with Flags (Version 4) In-Reply-To: <200702092349.08257.ville.skytta@iki.fi> References: <45CAAD34.6020303@redhat.com> <200702092349.08257.ville.skytta@iki.fi> Message-ID: <45CCF18D.8000508@redhat.com> Ville Skytt? wrote: > > 3. Bugzilla needs to be fixed not to send two mails every time a flag changes > state. Random example: > http://www.redhat.com/archives/fedora-package-review/2007-February/msg01538.html > http://www.redhat.com/archives/fedora-package-review/2007-February/msg01539.html > Oops. Fixed. Warren From tibbs at math.uh.edu Fri Feb 9 22:43:06 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Feb 2007 16:43:06 -0600 Subject: Merge Review build step is redundant? In-Reply-To: <45CCEC36.3040002@redhat.com> References: <45CCEC36.3040002@redhat.com> Message-ID: >>>>> "FN" == Fernando Nasser writes: FN> But for the packages of the "Merge Review" type, that are already FN> built in Core, isn't this step unnecessary? Not so much unnecessary as "already done for you". Matt Domsch was kind enough to rebuild all of rawhide in mock and provide pretty much all of the information you need to do an initial review: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/ Of course, keep in mind that you should verify that the package still builds after any changes made during review. Although if the fixes are being checked into fedora CVS then I suppose the nightly rawhide push will check this as well. - J< From davidz at redhat.com Sat Feb 10 01:32:50 2007 From: davidz at redhat.com (David Zeuthen) Date: Fri, 09 Feb 2007 20:32:50 -0500 Subject: Heads up for login managers Message-ID: <1171071170.2935.63.camel@zelda.fubar.dk> Hey, The major chunk of fast-user-switching has landed in Rawhide and as such if a desktop session requires non-trival services from HAL the login manager launching the session needs to be patched to poke ConsoleKit. I've filed a tracking bug for this https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228110 along with explanations and pointers to patches on how to do this. This is in gdm already but work is needed for other login managers https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228111 (kdm) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228079 (wdm) Please file bugs against other login managers (I can't think of others than kdm and, as I just learned, wdm) if you need non-trivial HAL support in desktop sessions launched from these. Thanks. David From bpepple at fedoraproject.org Sat Feb 10 00:56:17 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 09 Feb 2007 19:56:17 -0500 Subject: FESCo Meeting Summary for 2007-02-08 Message-ID: <1171068977.28153.9.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 == THL Leaving * thl is leaving FESCo due to possible conflicts with his day job. FESCo would like to thank Thorsten for all his hard work while he was on FESCo. Thanks! BTW: here's a link to his blog entry about leaving FESCo: http://thorstenl.blogspot.com/2007/02/leaving-fesco.html Core/Extras Merge * FESCo will wait a week before making a decision regarding the Core Review process, to get further feedback from the community. * Currently waiting for the new build system (Koji), which is still going through legal in regard to it's licensing. Co-Maintainership * thl worked on the proposal and adjusted the wording. He'll send it to FESCo members for review, and then to the public mailing lists. cvs-import * The plan is to modify cvs-import to 1) give a warning 2) provide a diff 3) make a cvs comment mandatory. Incompatible package upgrade policy * Maintainers should be aware of the effects that changes to their packages may have, and should alert other maintainers on the mailing list of updates which contain ABI or API changes which may cause dependency problems for other packages. This is covered in the Maintainer Responsibilities policy proposal. http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy * In the future, the new updates system will not let repo breakage occur. Packaging Committee Report * FESCo didn't have any objections to the Packaging Committee's guidelines regarding: 1. non-pear PHP extension paths 2. desktop files - http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles 3. makeinstall clarification - http://fedoraproject.org/wiki/PackagingDrafts/MakeInstall 4. Making the suggested buildroot mandatory 5. All binaries must be built from source - http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement 6. buildrequires clarification - http://fedoraproject.org/wiki/PackagingDrafts/BuildRequires MISC * There was a discussion whether to have acl's enabled by default on new packages. * notting discussed that FAB had recently talked about firmware which would require: 1. make up a license tag for non-modifiable firmware for easy finding for users 2. modify the EULA to add an exception clause for firmware (similar to the one currently for trademarked logos) 3. release note the eula change 4. start poking vendors * jeremy mentioned that the bugzilla update script from owners.list should be running every 4 hours now. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070208 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 mclasen at redhat.com Sat Feb 10 02:49:29 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 09 Feb 2007 21:49:29 -0500 Subject: Heads up for login managers In-Reply-To: <1171071170.2935.63.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> Message-ID: <45CD32B9.9080104@redhat.com> David Zeuthen wrote: > Hey, > > The major chunk of fast-user-switching has landed in Rawhide and as such > if a desktop session requires non-trival services from HAL the login > manager launching the session needs to be patched to poke ConsoleKit. > I've filed a tracking bug for this > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228110 > > along with explanations and pointers to patches on how to do this. This > is in gdm already but work is needed for other login managers > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228111 (kdm) > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228079 (wdm) > > Please file bugs against other login managers (I can't think of others > than kdm and, as I just learned, wdm) if you need non-trivial HAL > support in desktop sessions launched from these. Thanks. > Don't we still ship xdm ? From tcallawa at redhat.com Sat Feb 10 05:24:01 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 09 Feb 2007 23:24:01 -0600 Subject: Core merge and Package Guidelines In-Reply-To: <20070209163549.GB22763@nostromo.devel.redhat.com> References: <1170979354.4306.194.camel@localhost.localdomain> <20070209010519.GF2821@free.fr> <20070209112626.eca5a45b.bugs.michael@gmx.net> <45CC4F68.8070009@hhs.nl> <1171027286.31485.110.camel@mccallum.corsepiu.local> <20070209163549.GB22763@nostromo.devel.redhat.com> Message-ID: <1171085041.1479.27.camel@dhcp-32-109.ord.redhat.com> On Fri, 2007-02-09 at 11:35 -0500, Bill Nottingham wrote: > Ralf Corsepius (rc040203 at freenet.de) said: > > * Clean rpm-installation/package removal > > > > => One option is the same approach as it is being applied to > > perl-modules: "Any directory under /usr/lib/perl* which is not part of > > the basesystem and the base-perl package must be owned by the > > perl-module" > > Just patch RPM to unlink-but-no-error-if-failed up the filesystem > directory tree on removal. "Accepting patches" I think you will find that problem is a lot harder to solve than you think it is. However, I would be very pleased to be proven wrong. :) ~spot From tcallawa at redhat.com Sat Feb 10 05:27:16 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 09 Feb 2007 23:27:16 -0600 Subject: Odd licenses In-Reply-To: <20070209194350.GJ1706@redhat.com> References: <20070209194218.GI1706@redhat.com> <20070209194350.GJ1706@redhat.com> Message-ID: <1171085236.1479.30.camel@dhcp-32-109.ord.redhat.com> On Fri, 2007-02-09 at 14:43 -0500, Andrew Overholt wrote: > Sorry, I forgot to include the links. Full text below. > > Merge review for adaptx > [1] > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225238 > > adaptx license.txt > [2] > http://svn.codehaus.org/castor/adaptx/trunk/src/doc/license.txt > > * Andrew Overholt [2007-02-09 14:42]: > > Hi, > > > > I'm currently trying to do to the merge review for adaptx [1] but the > > license field is troubling: > > > > Exolab Software License > > > > A google query gives this page (in the cache): > > > > http://209.85.165.104/search?q=cache:kh3l7BHsrJsJ:freshmeat.net/releases/3417/+exolab+osi&hl=en&ct=clnk&cd=7&gl=us&lr=lang_en|lang_fr&client=firefox-a > > > > Which seems to imply that the license [2] is BSD. It does indeed look > > quite BSD-ish to me but what should the license field have? Is this > > okay from a legal standpoint? Spot? Mark it as BSD. 99% of the time, when a License has the name of the vendor in it (in the format $VENDOR Software License), its BSD. There are LOTS of things in Core that are just BSD, with mislabeled fields in their spec files (like say, Distributable). ~spot From pertusus at free.fr Sat Feb 10 09:39:55 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 10 Feb 2007 10:39:55 +0100 Subject: Heads up for login managers In-Reply-To: <1171071170.2935.63.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> Message-ID: <20070210093829.GB2797@free.fr> On Fri, Feb 09, 2007 at 08:32:50PM -0500, David Zeuthen wrote: > > Hey, > > The major chunk of fast-user-switching has landed in Rawhide and as such > if a desktop session requires non-trival services from HAL the login > manager launching the session needs to be patched to poke ConsoleKit. > I've filed a tracking bug for this As I said in the bugzilla, the dm is not the right place for ConsoleKit handling. This definitely belongs to pam. At least for the following reasons: * avoid code duplication, especially important becaus security is at stake here * can be extended to other login services than dm * can be removed for dm * configurable * avoid adding dependencies to dm. dbus and glib are bug deps for small dm. -- Pat From bugs.michael at gmx.net Sat Feb 10 10:55:11 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 10 Feb 2007 11:55:11 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <1171068977.28153.9.camel@Chuck> References: <1171068977.28153.9.camel@Chuck> Message-ID: <20070210115511.dc946f84.bugs.michael@gmx.net> On Fri, 09 Feb 2007 19:56:17 -0500, Brian Pepple wrote: > * In the future, the new updates system will not let repo breakage > occur. But the code that makes that possible is not available yet, is it? In the meantime, we can exclude build-job results from being published until a complete set of build-jobs is finished. All that's needed is a mail to the extras signers, which contains the list of src.rpm %{name}s to exclude. I committed rudimentary blacklist support to the pushscript yesterday. From sgrubb at redhat.com Sat Feb 10 14:06:39 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 10 Feb 2007 09:06:39 -0500 Subject: Heads up for login managers In-Reply-To: <1171071170.2935.63.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> Message-ID: <200702100906.40011.sgrubb@redhat.com> On Friday 09 February 2007 20:32, David Zeuthen wrote: > The major chunk of fast-user-switching has landed in Rawhide and as such > if a desktop session requires non-trival services from HAL the login > manager launching the session needs to be patched to poke ConsoleKit. Is there any papers, design docs, or anything to read about how this is intended to work? Has there been a security review? Does the design still allow the distro to meet CAPP? -Steve From buildsys at fedoraproject.org Sat Feb 10 14:05:18 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 10 Feb 2007 09:05:18 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-02-10 Message-ID: <20070210140518.2C91415212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) libxslt FC6-updates > FC7 (0:1.1.20-1.fc6 > 0:1.1.20-1) logrotate FC6-updates > FC7 (0:3.7.4-12.fc6 > 0:3.7.4-11.fc7) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) samba FC5-updates > FC7 (0:3.0.24-1.fc5 > 0:3.0.23c-2) FC6-updates > FC7 (0:3.0.24-1.fc6 > 0:3.0.23c-2) screen FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) cgoorah AT yahoo.com.au: kdmtheme FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) 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) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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: 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) 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) gemi AT bluewin.ch: genius FE5 > FE7 (0:0.7.7-1.fc5 > 0:0.7.6.1-3.fc6) FE6 > FE7 (0:0.7.7-1.fc6 > 0:0.7.6.1-3.fc6) jfontain AT free.fr: moomps FE5 > FE7 (0:5.8-2.fc5 > 0:5.8-1.fc7) FE6 > FE7 (0:5.8-2.fc6 > 0:5.8-1.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) lists AT forevermore.net: yafc FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.fc6) mdehaan AT redhat.com: cobbler FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.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 linux.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) tagoh AT redhat.com: mew FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) 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) ynakam AT hitachisoft.jp: seedit FE6 > FE7 (0:2.1.0-3.fc6 > 0:2.1.0-2.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.fc6) 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) 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) genius: gemi AT bluewin.ch FE5 > FE7 (0:0.7.7-1.fc5 > 0:0.7.6.1-3.fc6) FE6 > FE7 (0:0.7.7-1.fc6 > 0:0.7.6.1-3.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) 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) kdmtheme: cgoorah AT yahoo.com.au FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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) logrotate: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.7.4-12.fc6 > 0:3.7.4-11.fc7) mew: tagoh AT redhat.com FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) moomps: jfontain AT free.fr FE5 > FE7 (0:5.8-2.fc5 > 0:5.8-1.fc7) FE6 > FE7 (0:5.8-2.fc6 > 0:5.8-1.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) samba: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.0.24-1.fc5 > 0:3.0.23c-2) FC6-updates > FC7 (0:3.0.24-1.fc6 > 0:3.0.23c-2) screen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) seahorse: skvidal AT linux.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) seedit: ynakam AT hitachisoft.jp FE6 > FE7 (0:2.1.0-3.fc6 > 0:2.1.0-2.fc7) 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) 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) yafc: lists AT forevermore.net FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.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 belegdol at gmail.com Sun Feb 11 01:43:37 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sun, 11 Feb 2007 01:43:37 +0000 Subject: Stuck behind a proxy :( In-Reply-To: <9b1b20e70701251222v6ac69f04s6d739e8f0cccfea3@mail.gmail.com> References: <9b1b20e70701221234r5779e1albb782471c95cb861@mail.gmail.com> <45B526FC.5040505@poolshark.org> <9b1b20e70701251222v6ac69f04s6d739e8f0cccfea3@mail.gmail.com> Message-ID: <9b1b20e70702101743k47256a92w18a242b55d5a6d0b@mail.gmail.com> I have managed to get it to work. Seems like I'm back in business. 2007/1/25, Julian Sikorski : > 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 mitr at redhat.com Sun Feb 11 01:52:09 2007 From: mitr at redhat.com (Miloslav Trmac) Date: Sun, 11 Feb 2007 02:52:09 +0100 Subject: Process Change: Package Reviews with Flags In-Reply-To: <200702081955.41700.jkeating@redhat.com> References: <45BEC555.8050908@redhat.com> <200702071453.36654.jkeating@redhat.com> <1170980092.13307.77.camel@localhost.localdomain> <200702081955.41700.jkeating@redhat.com> Message-ID: <45CE76C9.2050900@redhat.com> Jesse Keating napsal(a): > Regardless if we fix this or not, just checking emails is reactionary. > Something may happen to one of my packages at 10pm EST, but I don't wake up > and read email until 9am EST. That's a lot of hours for something to happen > to one of my packages and for me to notice. With automated push tools, a > package build could go out into the repos and be installed by who knows how > many people. Relying on me being able to read email in time is not a very > good prospect, as you say 'crackrock'. Would it help to make package builds controlled by ACLs instead of CVS commits? This is still "reactionary", but a package owner has to do a CVS merge before building anyway. Mirek From belegdol at gmail.com Sun Feb 11 13:04:02 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sun, 11 Feb 2007 13:04:02 +0000 Subject: perl-XML-parser vs perl(XML::parser) Message-ID: <9b1b20e70702110504i51148b18i7841d4c8d301969b@mail.gmail.com> Hi. I have noticed that the latter is the preferred format for BuildRequires in FC-6 and devel, but how about FC-5? Cheers. From rc040203 at freenet.de Sun Feb 11 13:09:32 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 11 Feb 2007 14:09:32 +0100 Subject: perl-XML-parser vs perl(XML::parser) In-Reply-To: <9b1b20e70702110504i51148b18i7841d4c8d301969b@mail.gmail.com> References: <9b1b20e70702110504i51148b18i7841d4c8d301969b@mail.gmail.com> Message-ID: <1171199372.22648.1.camel@mccallum.corsepiu.local> On Sun, 2007-02-11 at 13:04 +0000, Julian Sikorski wrote: > Hi. I have noticed that the latter is the preferred format for > BuildRequires in FC-6 and devel, but how about FC-5? Cheers. perl(XML::Parser) For a length discussion, c.f. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227822 Ralf From belegdol at gmail.com Sun Feb 11 13:11:13 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sun, 11 Feb 2007 13:11:13 +0000 Subject: Preferred (smartest?) way of dealing with packages installing docs into %{_docdir} Message-ID: <9b1b20e70702110511u38779c4fl68308c4167f2099d@mail.gmail.com> I am now in the process of updating chemical-mime-data to 0.1.94. The program installs some docs to %{_docdir}/%{name}, while the right place for docs is %{_docdir}/%{name}-%{version}. Is there some encouraged way to deal with such things? I'm thinking about something like: mv %{_docdir}/%{name}/* %{_docdir}/%{name}-%{version}/html at the end of install step. Any other suggestions? From belegdol at gmail.com Sun Feb 11 13:14:07 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sun, 11 Feb 2007 13:14:07 +0000 Subject: perl-XML-parser vs perl(XML::parser) In-Reply-To: <1171199372.22648.1.camel@mccallum.corsepiu.local> References: <9b1b20e70702110504i51148b18i7841d4c8d301969b@mail.gmail.com> <1171199372.22648.1.camel@mccallum.corsepiu.local> Message-ID: <9b1b20e70702110514t1f229ea7y282bdcc818787792@mail.gmail.com> Thanks for the info. I'll start to update all my packages accordingly then. From belegdol at gmail.com Sun Feb 11 14:38:05 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sun, 11 Feb 2007 14:38:05 +0000 Subject: Still some proxy problems (plague) Message-ID: <9b1b20e70702110638t21e2cc6ehd5dad0f6742cf769@mail.gmail.com> Is it possible to make plague client work from behind an authenticating proxy? I tried exporting http_proxy environmental variable, but it did not work so far... Curse the dorms provided by University of Strathclyde! From jkeating at redhat.com Sun Feb 11 15:25:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 11 Feb 2007 10:25:50 -0500 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45CE76C9.2050900@redhat.com> References: <45BEC555.8050908@redhat.com> <200702081955.41700.jkeating@redhat.com> <45CE76C9.2050900@redhat.com> Message-ID: <200702111025.51066.jkeating@redhat.com> On Saturday 10 February 2007 20:52, Miloslav Trmac wrote: > Would it help to make package builds controlled by ACLs instead of CVS > commits? I think it would need to be both, one set of ACLs for commit, another for build. We just don't have that possibility in place right now. > This is still "reactionary", but a package owner has to do a CVS merge > before building anyway. -- 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 mtasaka at ioa.s.u-tokyo.ac.jp Sun Feb 11 17:03:11 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 12 Feb 2007 02:03:11 +0900 Subject: Process Change: Package Reviews with Flags In-Reply-To: <45C5BD28.2060906@ioa.s.u-tokyo.ac.jp> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <45C5B734.60204@ioa.s.u-tokyo.ac.jp> <45C5BD28.2060906@ioa.s.u-tokyo.ac.jp> Message-ID: <45CF4C4F.7040604@ioa.s.u-tokyo.ac.jp> Mamoru Tasaka wrote: > > And more and more slowly it becomes to do something on Fedora.. doing > some immediate fix (like fixing typo as Michael said). Even now, it is > already!! > Actually importing new packaging, fixing owners.list, etc... got slower and slower than before..... Mamoru From jpo at di.uminho.pt Sun Feb 11 17:18:29 2007 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sun, 11 Feb 2007 17:18:29 +0000 Subject: Adding a co-maintainer Message-ID: <45CF4FE5.9000102@di.uminho.pt> What's the new procedure to add a co-maintainer? A couple of weeks ago I only needed to edit the owners.list file but right now I'm not allowed to commit changes to it. ---- cvs commit: Examining . **** Access denied: jpo is not in ACL for owners cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! ---- jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- 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 jamatos at fc.up.pt Sun Feb 11 17:30:45 2007 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Sun, 11 Feb 2007 17:30:45 +0000 Subject: Adding a co-maintainer In-Reply-To: <45CF4FE5.9000102@di.uminho.pt> References: <45CF4FE5.9000102@di.uminho.pt> Message-ID: <200702111730.46615.jamatos@fc.up.pt> On Sunday 11 February 2007 5:18:29 pm Jose Pedro Oliveira wrote: > What's the new procedure to add a co-maintainer? > > A couple of weeks ago I only needed to edit the owners.list file > but right now I'm not allowed to commit changes to it. Ol?, :-) http://fedoraproject.org/wiki/Extras/CVSSyncNeeded > ---- > cvs commit: Examining . > **** Access denied: jpo is not in ACL for owners > cvs commit: Pre-commit check failed > cvs [commit aborted]: correct above errors first! > ---- > > jpo -- Jos? Ab?lio From jima at beer.tclug.org Sun Feb 11 17:49:14 2007 From: jima at beer.tclug.org (Jima) Date: Sun, 11 Feb 2007 11:49:14 -0600 (CST) Subject: Merge Review build step is redundant? In-Reply-To: <45CCEC36.3040002@redhat.com> References: <45CCEC36.3040002@redhat.com> Message-ID: On Fri, 9 Feb 2007, Fernando Nasser wrote: > When reviewing a new package one needs to assert if the submitted SRPM really > builds, so there is a step for the reviwer that consists in actually trying > to build the package. > > But for the packages of the "Merge Review" type, that are already built in > Core, isn't this step unnecessary? Yes and no. While Matt Domsch's builds are very helpful as a baseline, I've found (accidentally) that they're not quite perfect. First, he doesn't do ppc builds. I honestly haven't encountered any ppc-specific bugs (I've only done four Core reviews, though), and most reviewers aren't going to have ppc builders to test them against, so I'm not sure this is a particularly serious lack. Oh well. Second: Unless I'm mistaken, he only built published SRPMs. (Anyone is welcome to correct me if I'm wrong.) While this may seem like nit-picking (it does to me, and I know better), it matters if a maintainer made bad adaptations to a package after the last release was published. I have no idea how likely this is, but it did happen in one of my four reviews; I discovered a poorly implemented patch that made an inadvertant change that caused the build to fail. (Oops!) It was a completely understandable mishap, but I'm not sure anyone had picked up on it yet. I only did because I did a CVS checkout, ran `make srpm`, and threw that against my buildsys. Lucky catch. I don't think anyone is advocating doing rebuilds against the CVS copy; the only reason I did is because I got tired of leaching a bunch of files from Matt's stash. :-) I do strongly suspect that for 90+% of cases, Matt's builds are probably dead-on. As usual, he's doing very helpful work. Thanks, Matt! Jima From peter at thecodergeek.com Sun Feb 11 17:58:02 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 11 Feb 2007 09:58:02 -0800 Subject: Preferred (smartest?) way of dealing with packages installing docs into %{_docdir} In-Reply-To: <9b1b20e70702110511u38779c4fl68308c4167f2099d@mail.gmail.com> References: <9b1b20e70702110511u38779c4fl68308c4167f2099d@mail.gmail.com> Message-ID: <1171216682.3722.2.camel@localhost> On Sun, 2007-02-11 at 13:11 +0000, Julian Sikorski wrote: > I am now in the process of updating chemical-mime-data to 0.1.94. The > program installs some docs to %{_docdir}/%{name}, while the right > place for docs is %{_docdir}/%{name}-%{version}. Is there some > encouraged way to deal with such things? I'm thinking about something > like: > mv %{_docdir}/%{name}/* %{_docdir}/%{name}-%{version}/html > at the end of install step. Any other suggestions? How are these docs installed? Something similar happens in LucidLife, (as the docdir in Makefile.in is hardcoded as "$(datadir)/doc/lucidlife" and I keep a small patch to change that to the proper "$(datadir)/doc/lucidlife-" directory. Hope that helps. -- 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 jpo at di.uminho.pt Sun Feb 11 17:58:54 2007 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sun, 11 Feb 2007 17:58:54 +0000 Subject: Adding a co-maintainer In-Reply-To: <200702111730.46615.jamatos@fc.up.pt> References: <45CF4FE5.9000102@di.uminho.pt> <200702111730.46615.jamatos@fc.up.pt> Message-ID: <45CF595E.30506@di.uminho.pt> Jos? Matos wrote: > On Sunday 11 February 2007 5:18:29 pm Jose Pedro Oliveira wrote: >> What's the new procedure to add a co-maintainer? >> >> A couple of weeks ago I only needed to edit the owners.list file >> but right now I'm not allowed to commit changes to it. > > Ol?, :-) Ni hao! > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded Xie xie, :-) jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- 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 bugs.michael at gmx.net Sun Feb 11 18:13:01 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 11 Feb 2007 19:13:01 +0100 Subject: Adding a co-maintainer In-Reply-To: <45CF4FE5.9000102@di.uminho.pt> References: <45CF4FE5.9000102@di.uminho.pt> Message-ID: <20070211191301.8cebf7c7.bugs.michael@gmx.net> On Sun, 11 Feb 2007 17:18:29 +0000, Jose Pedro Oliveira wrote: > > What's the new procedure to add a co-maintainer? > > A couple of weeks ago I only needed to edit the owners.list file > but right now I'm not allowed to commit changes to it. I assume this procedure is current. https://www.redhat.com/archives/fedora-maintainers/2007-January/msg00378.html In case it has been replaced again, damn. From belegdol at gmail.com Sun Feb 11 18:25:35 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sun, 11 Feb 2007 18:25:35 +0000 Subject: Preferred (smartest?) way of dealing with packages installing docs into %{_docdir} In-Reply-To: <1171216682.3722.2.camel@localhost> References: <9b1b20e70702110511u38779c4fl68308c4167f2099d@mail.gmail.com> <1171216682.3722.2.camel@localhost> Message-ID: <9b1b20e70702111025n66b9fa8wbd05dea6d7c459dc@mail.gmail.com> Well, I don't know how, but the mv solution did not work. I did it the xine-lib way. Thanks to anybody who has invented it. 2007/2/11, Peter Gordon : > On Sun, 2007-02-11 at 13:11 +0000, Julian Sikorski wrote: > > I am now in the process of updating chemical-mime-data to 0.1.94. The > > program installs some docs to %{_docdir}/%{name}, while the right > > place for docs is %{_docdir}/%{name}-%{version}. Is there some > > encouraged way to deal with such things? I'm thinking about something > > like: > > mv %{_docdir}/%{name}/* %{_docdir}/%{name}-%{version}/html > > at the end of install step. Any other suggestions? > > How are these docs installed? Something similar happens in LucidLife, > (as the docdir in Makefile.in is hardcoded as "$(datadir)/doc/lucidlife" > and I keep a small patch to change that to the proper > "$(datadir)/doc/lucidlife-" directory. > > Hope that helps. > -- > 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 > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > > > From jonathan.underwood at gmail.com Sun Feb 11 18:35:48 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 11 Feb 2007 18:35:48 +0000 Subject: (La)TeX add on packages and the future Message-ID: <645d17210702111035j64032573xfb9c834089927ac@mail.gmail.com> Hi, With upstream support for tetex ended and the intention for Fedora to shift to TeXLive, I think there's a need to decide upon some new policies/guidelines for packaging (La)TeX related packages. Currently, such packages are mostly named tetex-foo, falling under the "add-on package" directive in the packaging guidelines, and they Require tetex, tetex-latex etc. While the TeXLive packaging is still a work in progress (as far as I know), it might be prudent to start thinking about it at this point. The large majority of these "add-on" packages actually are agnostic with respect to which TeX distribution is being used. It would be nice to make these add on packages useable with other TeX distributions that users might install - for instance it's not inconceivable that for some legacy reasons, a user might actually need to install the old tetex packages rather than the shiny new TeXLive ones. One thing I could think of is using virtual provides, eg. Provides: TeX, LaTeX, and then extra style file packages could require those, rather than tetex/TeXLive. What about package naming - clearly tetex-foo won't be sensible anylonger - what about simply TeX-foo, or tex-foo in the future? Perhaps reading this you have better suggestions (I hope so) - if so, pile in with them :) Jonathan. From dominik at greysector.net Sun Feb 11 18:49:05 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 11 Feb 2007 19:49:05 +0100 Subject: (La)TeX add on packages and the future In-Reply-To: <645d17210702111035j64032573xfb9c834089927ac@mail.gmail.com> References: <645d17210702111035j64032573xfb9c834089927ac@mail.gmail.com> Message-ID: <20070211184905.GC27735@ryvius.pekin.waw.pl> On Sunday, 11 February 2007 at 19:35, Jonathan Underwood wrote: > Hi, > > With upstream support for tetex ended and the intention for Fedora to > shift to TeXLive, I think there's a need to decide upon some new > policies/guidelines for packaging (La)TeX related packages. > > Currently, such packages are mostly named tetex-foo, falling under the > "add-on package" directive in the packaging guidelines, and they > Require tetex, tetex-latex etc. While the TeXLive packaging is still a > work in progress (as far as I know), it might be prudent to start > thinking about it at this point. The large majority of these "add-on" > packages actually are agnostic with respect to which TeX distribution > is being used. It would be nice to make these add on packages useable > with other TeX distributions that users might install - for instance > it's not inconceivable that for some legacy reasons, a user might > actually need to install the old tetex packages rather than the shiny > new TeXLive ones. > > One thing I could think of is using virtual provides, eg. Provides: > TeX, LaTeX, and then extra style file packages could require those, > rather than tetex/TeXLive. What about package naming - clearly > tetex-foo won't be sensible anylonger - what about simply TeX-foo, or > tex-foo in the future? FWIW, I prefer lowercase names, i.e. tex-foo (or latex-foo, if the package is a LaTeX add-on, I'm not sure if we need the distinction). 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 belegdol at gmail.com Mon Feb 12 13:58:15 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Mon, 12 Feb 2007 13:58:15 +0000 Subject: =?utf-8?b?cGxhZ3VlICYgcHJveHkg4oCcZnVu4oCd?= Message-ID: <9b1b20e70702120558p25e3834bme7179a52e438d2d8@mail.gmail.com> Hi. While I'm struggling to make plague work form behind a proxy, could somebody request a build for chemical-mime-data for devel? It's already tagged, just needs to be built. Thanks in advance. From paul at city-fan.org Mon Feb 12 14:25:10 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Feb 2007 14:25:10 +0000 Subject: plague & proxy =?utf-8?b?4oCcZnVu4oCd?= In-Reply-To: <9b1b20e70702120558p25e3834bme7179a52e438d2d8@mail.gmail.com> References: <9b1b20e70702120558p25e3834bme7179a52e438d2d8@mail.gmail.com> Message-ID: <45D078C6.8000101@city-fan.org> Julian Sikorski wrote: > Hi. While I'm struggling to make plague work form behind a proxy, > could somebody request a build for chemical-mime-data for devel? It's > already tagged, just needs to be built. Thanks in advance. Done. Package chemical-mime-data enqueued. Job ID: 27398. Cheers, Paul. From ajackson at redhat.com Mon Feb 12 15:03:02 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 12 Feb 2007 10:03:02 -0500 Subject: Heads up for login managers In-Reply-To: <45CD32B9.9080104@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <45CD32B9.9080104@redhat.com> Message-ID: <1171292582.7008.8.camel@localhost.localdomain> On Fri, 2007-02-09 at 21:49 -0500, Matthias Clasen wrote: > David Zeuthen wrote: > > Please file bugs against other login managers (I can't think of others > > than kdm and, as I just learned, wdm) if you need non-trivial HAL > > support in desktop sessions launched from these. Thanks. > > > Don't we still ship xdm ? Yes. And can we please not? - ajax From belegdol at gmail.com Mon Feb 12 15:23:04 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Mon, 12 Feb 2007 15:23:04 +0000 Subject: =?utf-8?b?UmU6IHBsYWd1ZSAmIHByb3h5IOKAnGZ1buKAnQ==?= In-Reply-To: <45D078C6.8000101@city-fan.org> References: <9b1b20e70702120558p25e3834bme7179a52e438d2d8@mail.gmail.com> <45D078C6.8000101@city-fan.org> Message-ID: <9b1b20e70702120723m2ba27e52l37e965ddf60884e@mail.gmail.com> Looks like it failed. I'll try to build it in mock and see what happens. In non-isolated environment, it builds fine. Thanks anyway. 2007/2/12, Paul Howarth : > Julian Sikorski wrote: > > Hi. While I'm struggling to make plague work form behind a proxy, > > could somebody request a build for chemical-mime-data for devel? It's > > already tagged, just needs to be built. Thanks in advance. > > Done. > > Package chemical-mime-data enqueued. Job ID: 27398. > > Cheers, Paul. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From paul at city-fan.org Mon Feb 12 15:32:11 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Feb 2007 15:32:11 +0000 Subject: plague & proxy =?utf-8?b?4oCcZnVu4oCd?= In-Reply-To: <9b1b20e70702120723m2ba27e52l37e965ddf60884e@mail.gmail.com> References: <9b1b20e70702120558p25e3834bme7179a52e438d2d8@mail.gmail.com> <45D078C6.8000101@city-fan.org> <9b1b20e70702120723m2ba27e52l37e965ddf60884e@mail.gmail.com> Message-ID: <45D0887B.8010108@city-fan.org> Julian Sikorski wrote: > Looks like it failed. I'll try to build it in mock and see what > happens. In non-isolated environment, it builds fine. Thanks anyway. It's failing because the spec includes a "%find_lang" clause and there are no translations to find. The attached patch works for me. Cheers, Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: chemical-mime-data-lang.patch Type: text/x-patch Size: 499 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Feb 12 15:39:02 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 12 Feb 2007 09:39:02 -0600 Subject: Heads up for login managers In-Reply-To: <1171292582.7008.8.camel@localhost.localdomain> References: <1171071170.2935.63.camel@zelda.fubar.dk> <45CD32B9.9080104@redhat.com> <1171292582.7008.8.camel@localhost.localdomain> Message-ID: <45D08A16.9040509@math.unl.edu> Adam Jackson wrote: > On Fri, 2007-02-09 at 21:49 -0500, Matthias Clasen wrote: >> David Zeuthen wrote: >>> Please file bugs against other login managers (I can't think of others >>> than kdm and, as I just learned, wdm) if you need non-trivial HAL >>> support in desktop sessions launched from these. Thanks. >>> >> Don't we still ship xdm ? > > Yes. And can we please not? Consider that kdm uses (some of) the stuff from /etc/X11/xdm/, namely Xaccess, Xresources, Xservers, Xsetup, etc... -- Rex From mr.ecik at gmail.com Mon Feb 12 15:41:16 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Mon, 12 Feb 2007 16:41:16 +0100 Subject: =?windows-1252?q?Re=3A_plague_=26_proxy_=93fun=94?= In-Reply-To: <45D0887B.8010108@city-fan.org> References: <9b1b20e70702120558p25e3834bme7179a52e438d2d8@mail.gmail.com> <45D078C6.8000101@city-fan.org> <9b1b20e70702120723m2ba27e52l37e965ddf60884e@mail.gmail.com> <45D0887B.8010108@city-fan.org> Message-ID: <668bb39a0702120741p2a3f64a2w74ad463741414ef2@mail.gmail.com> 2007/2/12, Paul Howarth : > It's failing because the spec includes a "%find_lang" clause and there > are no translations to find. The attached patch works for me. Probably, package hasn't got necessary `gettext` BR (haven't tried but should work) -- Micha? Bentkowski mr.ecik at gmail.com From pertusus at free.fr Mon Feb 12 15:42:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 12 Feb 2007 16:42:44 +0100 Subject: Heads up for login managers In-Reply-To: <45D08A16.9040509@math.unl.edu> References: <1171071170.2935.63.camel@zelda.fubar.dk> <45CD32B9.9080104@redhat.com> <1171292582.7008.8.camel@localhost.localdomain> <45D08A16.9040509@math.unl.edu> Message-ID: <20070212154244.GA2761@free.fr> On Mon, Feb 12, 2007 at 09:39:02AM -0600, Rex Dieter wrote: > > Consider that kdm uses (some of) the stuff from /etc/X11/xdm/, namely > Xaccess, Xresources, Xservers, Xsetup, etc... And so does wdm. This allows to avoid duplication of code. And also I can't see why we shouldn't ship xdm, or any other display manager. -- Pat From paul at city-fan.org Mon Feb 12 15:48:01 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Feb 2007 15:48:01 +0000 Subject: plague & proxy =?utf-8?b?4oCcZnVu4oCd?= In-Reply-To: <668bb39a0702120741p2a3f64a2w74ad463741414ef2@mail.gmail.com> References: <9b1b20e70702120558p25e3834bme7179a52e438d2d8@mail.gmail.com> <45D078C6.8000101@city-fan.org> <9b1b20e70702120723m2ba27e52l37e965ddf60884e@mail.gmail.com> <45D0887B.8010108@city-fan.org> <668bb39a0702120741p2a3f64a2w74ad463741414ef2@mail.gmail.com> Message-ID: <45D08C31.8060901@city-fan.org> Micha? Bentkowski wrote: > 2007/2/12, Paul Howarth : >> It's failing because the spec includes a "%find_lang" clause and there >> are no translations to find. The attached patch works for me. > > Probably, package hasn't got necessary `gettext` BR (haven't tried but > should work) That was my first thought too, but adding BR: gettext didn't help. The existing FC6 package appears not to have any translations either. Paul. From belegdol at gmail.com Mon Feb 12 15:49:13 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Mon, 12 Feb 2007 15:49:13 +0000 Subject: =?utf-8?b?UmU6IHBsYWd1ZSAmIHByb3h5IOKAnGZ1buKAnQ==?= In-Reply-To: <668bb39a0702120741p2a3f64a2w74ad463741414ef2@mail.gmail.com> References: <9b1b20e70702120558p25e3834bme7179a52e438d2d8@mail.gmail.com> <45D078C6.8000101@city-fan.org> <9b1b20e70702120723m2ba27e52l37e965ddf60884e@mail.gmail.com> <45D0887B.8010108@city-fan.org> <668bb39a0702120741p2a3f64a2w74ad463741414ef2@mail.gmail.com> Message-ID: <9b1b20e70702120749vfbae577o71f00571415c4343@mail.gmail.com> I added intltool to BR, maybe that will be enough. 2007/2/12, Micha? Bentkowski : > 2007/2/12, Paul Howarth : > > It's failing because the spec includes a "%find_lang" clause and there > > are no translations to find. The attached patch works for me. > > Probably, package hasn't got necessary `gettext` BR (haven't tried but > should work) > > -- > Micha? Bentkowski > mr.ecik at gmail.com > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From ajackson at redhat.com Mon Feb 12 15:40:22 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 12 Feb 2007 10:40:22 -0500 Subject: Heads up for login managers In-Reply-To: <45D08A16.9040509@math.unl.edu> References: <1171071170.2935.63.camel@zelda.fubar.dk> <45CD32B9.9080104@redhat.com> <1171292582.7008.8.camel@localhost.localdomain> <45D08A16.9040509@math.unl.edu> Message-ID: <1171294822.7008.13.camel@localhost.localdomain> On Mon, 2007-02-12 at 09:39 -0600, Rex Dieter wrote: > Adam Jackson wrote: > > On Fri, 2007-02-09 at 21:49 -0500, Matthias Clasen wrote: > >> David Zeuthen wrote: > >>> Please file bugs against other login managers (I can't think of others > >>> than kdm and, as I just learned, wdm) if you need non-trivial HAL > >>> support in desktop sessions launched from these. Thanks. > >>> > >> Don't we still ship xdm ? > > > > Yes. And can we please not? > > Consider that kdm uses (some of) the stuff from /etc/X11/xdm/, namely > Xaccess, Xresources, Xservers, Xsetup, etc... Ick. - ajax From mclasen at redhat.com Mon Feb 12 15:58:29 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 12 Feb 2007 10:58:29 -0500 Subject: Heads up for login managers In-Reply-To: <20070212154244.GA2761@free.fr> References: <1171071170.2935.63.camel@zelda.fubar.dk> <45CD32B9.9080104@redhat.com> <1171292582.7008.8.camel@localhost.localdomain> <45D08A16.9040509@math.unl.edu> <20070212154244.GA2761@free.fr> Message-ID: <45D08EA5.1010608@redhat.com> Patrice Dumas wrote: > On Mon, Feb 12, 2007 at 09:39:02AM -0600, Rex Dieter wrote: > >> Consider that kdm uses (some of) the stuff from /etc/X11/xdm/, namely >> Xaccess, Xresources, Xservers, Xsetup, etc... >> > > And so does wdm. This allows to avoid duplication of code. > > And also I can't see why we shouldn't ship xdm, or any other display > manager. > Because it doesn't make much sense ? If we ship 5 copies of a central piece of infrastructure, it means that any change to that infrastruture becomes 50 times harder... From notting at redhat.com Mon Feb 12 15:58:26 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 10:58:26 -0500 Subject: Heads up for login managers In-Reply-To: <20070212154244.GA2761@free.fr> References: <1171071170.2935.63.camel@zelda.fubar.dk> <45CD32B9.9080104@redhat.com> <1171292582.7008.8.camel@localhost.localdomain> <45D08A16.9040509@math.unl.edu> <20070212154244.GA2761@free.fr> Message-ID: <20070212155826.GE11536@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > And so does wdm. This allows to avoid duplication of code. > > And also I can't see why we shouldn't ship xdm, or any other display > manager. In the grand universe of Fedora? Sure. By default in the OS... no. Bill From paul at city-fan.org Mon Feb 12 16:31:26 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Feb 2007 16:31:26 +0000 Subject: plague & proxy =?utf-8?b?4oCcZnVu4oCd?= In-Reply-To: <9b1b20e70702120749vfbae577o71f00571415c4343@mail.gmail.com> References: <9b1b20e70702120558p25e3834bme7179a52e438d2d8@mail.gmail.com> <45D078C6.8000101@city-fan.org> <9b1b20e70702120723m2ba27e52l37e965ddf60884e@mail.gmail.com> <45D0887B.8010108@city-fan.org> <668bb39a0702120741p2a3f64a2w74ad463741414ef2@mail.gmail.com> <9b1b20e70702120749vfbae577o71f00571415c4343@mail.gmail.com> Message-ID: <45D0965E.3090000@city-fan.org> Julian Sikorski wrote: > I added intltool to BR, maybe that will be enough. Adding buildreqs of intltool *and* gettext works for me. Paul. From davidz at redhat.com Mon Feb 12 16:40:14 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 11:40:14 -0500 Subject: Heads up for login managers In-Reply-To: <200702100906.40011.sgrubb@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> Message-ID: <1171298414.2860.7.camel@zelda.fubar.dk> On Sat, 2007-02-10 at 09:06 -0500, Steve Grubb wrote: > On Friday 09 February 2007 20:32, David Zeuthen wrote: > > The major chunk of fast-user-switching has landed in Rawhide and as such > > if a desktop session requires non-trival services from HAL the login > > manager launching the session needs to be patched to poke ConsoleKit. > > Is there any papers, design docs, or anything to read about how this is > intended to work? Sure, it was announced mid-November 2006 http://www.redhat.com/archives/fedora-devel-list/2006-November/msg00507.html and also mentioned in Bill's plan for Fedora 7. There's not been a ton of feedback from the community just yet. > Has there been a security review? Not per se and, for the record, I'm unsure what is involved in doing that for Fedora; do you know? I guess I'm trying to say there's no process for how to do that. Also, keep in mind f-u-s isn't exactly new, IIRC earlier Fedora releases have allowed you to do this; all we're doing here is turning it on by default as well as fixing up the OS to deal with it (see the Wiki page the mail links to). Suffice to say it's been discussed on a number of lists, it's been designed with security in mind and I also mentioned it doing my two talks at LCA. Also had a lot of private exchanges with people about it. I'd welcome a "security review" by you and others involved in security-related matters in Fedora; it would be nice if you could do that, thanks. > Does the design still > allow the distro to meet CAPP? Haven't looked into it and I'm not sure Fedora is certified in any way at this point anyway. Also it might be useful, as a community service to all readers on the list, if you linked to what CAPP is when using jargon like that, thanks. David From davidz at redhat.com Mon Feb 12 16:46:00 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 11:46:00 -0500 Subject: Heads up for login managers In-Reply-To: <20070210093829.GB2797@free.fr> References: <1171071170.2935.63.camel@zelda.fubar.dk> <20070210093829.GB2797@free.fr> Message-ID: <1171298760.2860.15.camel@zelda.fubar.dk> On Sat, 2007-02-10 at 10:39 +0100, Patrice Dumas wrote: > On Fri, Feb 09, 2007 at 08:32:50PM -0500, David Zeuthen wrote: > > > > Hey, > > > > The major chunk of fast-user-switching has landed in Rawhide and as such > > if a desktop session requires non-trival services from HAL the login > > manager launching the session needs to be patched to poke ConsoleKit. > > I've filed a tracking bug for this > > As I said in the bugzilla, the dm is not the right place for ConsoleKit > handling. This definitely belongs to pam. At least for the following > reasons: > * avoid code duplication, especially important becaus security is at > stake here > * can be extended to other login services than dm > * can be removed for dm > * configurable Probably better to discuss in Bugzilla; I'll add Jon (ConsoleKit author); he had some smashing arguments IIRC for not to do this and I wouldn't be able to do a good job just repeating those. > * avoid adding dependencies to dm. dbus and glib are bug deps for small > dm. No, there's only a dbus dependency. D-Bus does not require glib. David From pertusus at free.fr Mon Feb 12 16:58:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 12 Feb 2007 17:58:36 +0100 Subject: Heads up for login managers In-Reply-To: <45D08EA5.1010608@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <45CD32B9.9080104@redhat.com> <1171292582.7008.8.camel@localhost.localdomain> <45D08A16.9040509@math.unl.edu> <20070212154244.GA2761@free.fr> <45D08EA5.1010608@redhat.com> Message-ID: <20070212165836.GB6224@free.fr> On Mon, Feb 12, 2007 at 10:58:29AM -0500, Matthias Clasen wrote: > > Because it doesn't make much sense ? If we ship 5 copies of a central > piece of infrastructure, > it means that any change to that infrastruture becomes 50 times harder... In that case there is a flaw in the infrastructure design, like not enough modularity or a missing API. Every piece of fedora should be replaceable with something that implements the same interface to a known protocol or something like that. -- Pat From sgrubb at redhat.com Mon Feb 12 17:08:24 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 12 Feb 2007 12:08:24 -0500 Subject: Heads up for login managers In-Reply-To: <1171298414.2860.7.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> Message-ID: <200702121208.25038.sgrubb@redhat.com> On Monday 12 February 2007 11:40, David Zeuthen wrote: > > Has there been a security review? > > Not per se and, for the record, I'm unsure what is involved in doing > that for Fedora; do you know? You gotta do it the hard way...code review. > Suffice to say it's been discussed on a number of lists, it's been > designed with security in mind and I also mentioned it doing my two > talks at LCA. Also had a lot of private exchanges with people about it. > I'd welcome a "security review" by you and others involved in > security-related matters in Fedora; it would be nice if you could do > that, thanks. Yes, I will look it over. > > Does the design still allow the distro to meet CAPP? > > Haven't looked into it and I'm not sure Fedora is certified in any way > at this point anyway. Fedora has all the bits and pieces applied that would let if meet CAPP. This is the Common Criteria Certification based around traditional discretionary access controls (unix perms). > Also it might be useful, as a community service to all readers on the list, > if you linked to what CAPP is when using jargon like that, thanks. CAPP is here: http://www.niap-ccevs.org/cc-scheme/pp/PP_OS_CA_V1.d.cfm The main thing I am concerned with is that auditing doesn't get messed up. There is code in place to make sure that actions get attributed to the right user. A code review should help determine it. I also am concerned about what this means for things like console helper. -Steve From mclasen at redhat.com Mon Feb 12 17:27:58 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 12 Feb 2007 12:27:58 -0500 Subject: Heads up for login managers In-Reply-To: <20070212165836.GB6224@free.fr> References: <1171071170.2935.63.camel@zelda.fubar.dk> <45CD32B9.9080104@redhat.com> <1171292582.7008.8.camel@localhost.localdomain> <45D08A16.9040509@math.unl.edu> <20070212154244.GA2761@free.fr> <45D08EA5.1010608@redhat.com> <20070212165836.GB6224@free.fr> Message-ID: <45D0A39E.8050702@redhat.com> Patrice Dumas wrote: > On Mon, Feb 12, 2007 at 10:58:29AM -0500, Matthias Clasen wrote: > >> Because it doesn't make much sense ? If we ship 5 copies of a central >> piece of infrastructure, >> it means that any change to that infrastruture becomes 50 times harder... >> > > In that case there is a flaw in the infrastructure design, like not > enough modularity or a missing API. Every piece of fedora should be > replaceable with something that implements the same interface to a > known protocol or something like that. > Thats nice in theory, but in practice, standardizing on one piece of infrastructure is often the only way to get anything done. And users care a lot more about the fact that the default display manager works nicely than the fact that they can switch to 20 different display managers... From notting at redhat.com Mon Feb 12 17:24:40 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 12:24:40 -0500 Subject: Heads up for login managers In-Reply-To: <20070212165836.GB6224@free.fr> References: <1171071170.2935.63.camel@zelda.fubar.dk> <45CD32B9.9080104@redhat.com> <1171292582.7008.8.camel@localhost.localdomain> <45D08A16.9040509@math.unl.edu> <20070212154244.GA2761@free.fr> <45D08EA5.1010608@redhat.com> <20070212165836.GB6224@free.fr> Message-ID: <20070212172440.GA13594@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > In that case there is a flaw in the infrastructure design, like not > enough modularity or a missing API. Every piece of fedora should be > replaceable with something that implements the same interface to a > known protocol or something like that. How is talking to dbus not a 'same interface to a known protocol'? Bill From davidz at redhat.com Mon Feb 12 17:27:46 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 12:27:46 -0500 Subject: Heads up for login managers In-Reply-To: <200702121208.25038.sgrubb@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> Message-ID: <1171301266.2860.27.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 12:08 -0500, Steve Grubb wrote: > > Suffice to say it's been discussed on a number of lists, it's been > > designed with security in mind and I also mentioned it doing my two > > talks at LCA. Also had a lot of private exchanges with people about it. > > I'd welcome a "security review" by you and others involved in > > security-related matters in Fedora; it would be nice if you could do > > that, thanks. > > Yes, I will look it over. Thanks, appreciate it. To get you started, keep in mind the major change here is to deny service from e.g. HAL to inactive sessions. Much like we already deny service to HAL for non-console users. To e.g. ensure that an inactive session doesn't do things like suspending the system. This is *hard*; how does a system service like HAL *know*, in a secure way, what desktop session a caller originates from? The solution was to use an environment variable XDG_SESSION_COOKIE; e.g. membership of a desktop session is defined by knowledge of this secret. So we can get the process id of the caller and from there ConsoleKit (running with sufficient privileges) can look up into /proc for that process and peek at what XDG_SESSION_COOKIE is set to. Keep in mind the way of using an environment variable is all implementation details right now and abstracted by ConsoleKit at this point. E.g. if we could securely tag a process with a cookie and ensure that it's inherited by child processes and said child processes cannot change it we're good. And then we can use this mechanism instead of the rather ugly way of using environment variables. Unfortunately, to my knowledge at least, the Linux kernel don't yet support something like this. David From belegdol at gmail.com Mon Feb 12 17:30:33 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Mon, 12 Feb 2007 17:30:33 +0000 Subject: =?utf-8?b?UmU6IHBsYWd1ZSAmIHByb3h5IOKAnGZ1buKAnQ==?= In-Reply-To: <45D0965E.3090000@city-fan.org> References: <9b1b20e70702120558p25e3834bme7179a52e438d2d8@mail.gmail.com> <45D078C6.8000101@city-fan.org> <9b1b20e70702120723m2ba27e52l37e965ddf60884e@mail.gmail.com> <45D0887B.8010108@city-fan.org> <668bb39a0702120741p2a3f64a2w74ad463741414ef2@mail.gmail.com> <9b1b20e70702120749vfbae577o71f00571415c4343@mail.gmail.com> <45D0965E.3090000@city-fan.org> Message-ID: <9b1b20e70702120930u6f5e4c78yc72c5fb12324cab6@mail.gmail.com> I figured it out as well. Ok, new release tagged, could you please request a build? Tag is: chemical-mime-data-0_1_94-2_fc7 2007/2/12, Paul Howarth : > Julian Sikorski wrote: > > I added intltool to BR, maybe that will be enough. > > Adding buildreqs of intltool *and* gettext works for me. > > Paul. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From paul at city-fan.org Mon Feb 12 17:31:45 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Feb 2007 17:31:45 +0000 Subject: plague & proxy =?utf-8?b?4oCcZnVu4oCd?= In-Reply-To: <9b1b20e70702120930u6f5e4c78yc72c5fb12324cab6@mail.gmail.com> References: <9b1b20e70702120558p25e3834bme7179a52e438d2d8@mail.gmail.com> <45D078C6.8000101@city-fan.org> <9b1b20e70702120723m2ba27e52l37e965ddf60884e@mail.gmail.com> <45D0887B.8010108@city-fan.org> <668bb39a0702120741p2a3f64a2w74ad463741414ef2@mail.gmail.com> <9b1b20e70702120749vfbae577o71f00571415c4343@mail.gmail.com> <45D0965E.3090000@city-fan.org> <9b1b20e70702120930u6f5e4c78yc72c5fb12324cab6@mail.gmail.com> Message-ID: <45D0A481.8080504@city-fan.org> Julian Sikorski wrote: > I figured it out as well. Ok, new release tagged, could you please > request a build? Tag is: chemical-mime-data-0_1_94-2_fc7 Package chemical-mime-data enqueued. Job ID: 27405. Paul. From alan at redhat.com Mon Feb 12 17:38:42 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 12:38:42 -0500 Subject: Heads up for login managers In-Reply-To: <1171301266.2860.27.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> Message-ID: <20070212173842.GB17083@devserv.devel.redhat.com> On Mon, Feb 12, 2007 at 12:27:46PM -0500, David Zeuthen wrote: > desktop session is defined by knowledge of this secret. So we can get > the process id of the caller and from there ConsoleKit (running with > sufficient privileges) can look up into /proc for that process and peek > at what XDG_SESSION_COOKIE is set to. Yuk. Thats not very clever. Environment is private to the program and that means that poking around in /proc won't always give you the current environment of the program and that it can set itself up so you get a different answer to the one you expect. > point. E.g. if we could securely tag a process with a cookie and ensure > that it's inherited by child processes and said child processes cannot > change it we're good. And then we can use this mechanism instead of the > rather ugly way of using environment variables. Unfortunately, to my > knowledge at least, the Linux kernel don't yet support something like > this. That would be because such a restriction is meaningless and has no relevance to the security model. Security is enforced by user id and not by session (ok SELinux is a bit more complex). Our unix socket interface even allows you to do credential passing. Perhaps if you can explain your actual security model someone can provide an implementation but I don't currently understand your model even. If I've got a desktop session with some "right" to shut down the system and a remote session I can shut down the box remotely, you can't stop me as I can set up apps in one to listen to the other. If you are trying to do distributed secrets based authentication of services and access rights then its called kerberos and the libraries are installed. Alan From belegdol at gmail.com Mon Feb 12 17:40:17 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Mon, 12 Feb 2007 17:40:17 +0000 Subject: =?utf-8?b?UmU6IHBsYWd1ZSAmIHByb3h5IOKAnGZ1buKAnQ==?= In-Reply-To: <45D0A481.8080504@city-fan.org> References: <9b1b20e70702120558p25e3834bme7179a52e438d2d8@mail.gmail.com> <45D078C6.8000101@city-fan.org> <9b1b20e70702120723m2ba27e52l37e965ddf60884e@mail.gmail.com> <45D0887B.8010108@city-fan.org> <668bb39a0702120741p2a3f64a2w74ad463741414ef2@mail.gmail.com> <9b1b20e70702120749vfbae577o71f00571415c4343@mail.gmail.com> <45D0965E.3090000@city-fan.org> <9b1b20e70702120930u6f5e4c78yc72c5fb12324cab6@mail.gmail.com> <45D0A481.8080504@city-fan.org> Message-ID: <9b1b20e70702120940l45043dc4t6c45e8f22a07275@mail.gmail.com> Build succeeded. If there are no complains, I'll push the changes to FC-6 and FC-5 branches. The other thing, is plague even capable to work prom behind a proxy? Or am I just wasting time trying to make it work? Cheers. 2007/2/12, Paul Howarth : > Julian Sikorski wrote: > > I figured it out as well. Ok, new release tagged, could you please > > request a build? Tag is: chemical-mime-data-0_1_94-2_fc7 > > Package chemical-mime-data enqueued. Job ID: 27405. > > Paul. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From mattdm at mattdm.org Mon Feb 12 17:50:48 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 12 Feb 2007 12:50:48 -0500 Subject: Heads up for login managers In-Reply-To: <1171301266.2860.27.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> Message-ID: <20070212175048.GA10899@jadzia.bu.edu> On Mon, Feb 12, 2007 at 12:27:46PM -0500, David Zeuthen wrote: > Keep in mind the way of using an environment variable is all > implementation details right now and abstracted by ConsoleKit at this > point. E.g. if we could securely tag a process with a cookie and ensure > that it's inherited by child processes and said child processes cannot > change it we're good. And then we can use this mechanism instead of the > rather ugly way of using environment variables. Unfortunately, to my > knowledge at least, the Linux kernel don't yet support something like > this. Wouldn't the kernel keyring mechanism work? (See keys.txt in the kernel docs.) Or perhaps I'm not understanding something. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davidz at redhat.com Mon Feb 12 17:54:14 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 12:54:14 -0500 Subject: Heads up for login managers In-Reply-To: <20070212173842.GB17083@devserv.devel.redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> Message-ID: <1171302855.2860.42.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 12:38 -0500, Alan Cox wrote: > On Mon, Feb 12, 2007 at 12:27:46PM -0500, David Zeuthen wrote: > > desktop session is defined by knowledge of this secret. So we can get > > the process id of the caller and from there ConsoleKit (running with > > sufficient privileges) can look up into /proc for that process and peek > > at what XDG_SESSION_COOKIE is set to. > > Yuk. Thats not very clever. Environment is private to the program and that > means that poking around in /proc won't always give you the current > environment of the program and that it can set itself up so you get a > different answer to the one you expect. Sure, if programs change XDG_SESSION_COOKIE they are denied service. So don't do that if you want to continue having service. It works and it's secure (the cookies are dispensed by ConsoleKit and thus random, e.g. you can't guess the cookie that other users have); just don't change XDG_SESSION_COOKIE. > > point. E.g. if we could securely tag a process with a cookie and ensure > > that it's inherited by child processes and said child processes cannot > > change it we're good. And then we can use this mechanism instead of the > > rather ugly way of using environment variables. Unfortunately, to my > > knowledge at least, the Linux kernel don't yet support something like > > this. > > That would be because such a restriction is meaningless and has no > relevance to the security model. Security is enforced by user id and not > by session (ok SELinux is a bit more complex). Our unix socket interface > even allows you to do credential passing. Which is not good enough; we need a model where we can make a distinction between the actual sessions so we can deny service to sessions depending on whether they are active / local or whatnot. Do you agree this is an important goal? What guarantees we make, and more importantly, what guarantees we don't make are important. See below. > Perhaps if you can explain your actual security model someone can provide an > implementation but I don't currently understand your model even. If I've got > a desktop session with some "right" to shut down the system and a remote > session I can shut down the box remotely, you can't stop me as I can set up > apps in one to listen to the other. If you're already logged in locally, then yes, you're able to mount such an "attack"; e.g. you can extract XDG_SESSION_COOKIE from a process in the locally logged in session, set it in your ssh login session and you will have rights to e.g. shutdown or reboot the system. This is no different from console helper; if you have a record in /var/run/console then, yes, you can happily run 'reboot' etc. even without mocking around with XDG_SESSION_COOKIE. So the security model of this, yes, allows you to gain the same privileges if you're already logged in locally. Again, we're no worse off (somewhat a bit better off) than using console helper. If you have ideas on how to fix Linux so we can have a better security model where this is not possible I'd be happy to hear about it. Thinking about it, I agree it wouldn't make sense; you're already logged in locally so you could just have a VNC server or equivalent running and you could use this to use the privileges exposed by the local session. So I'm not sure what the fuss is about? David From pertusus at free.fr Mon Feb 12 17:53:51 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 12 Feb 2007 18:53:51 +0100 Subject: Heads up for login managers In-Reply-To: <45D0A39E.8050702@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <45CD32B9.9080104@redhat.com> <1171292582.7008.8.camel@localhost.localdomain> <45D08A16.9040509@math.unl.edu> <20070212154244.GA2761@free.fr> <45D08EA5.1010608@redhat.com> <20070212165836.GB6224@free.fr> <45D0A39E.8050702@redhat.com> Message-ID: <20070212175351.GD6224@free.fr> On Mon, Feb 12, 2007 at 12:27:58PM -0500, Matthias Clasen wrote: > > Thats nice in theory, but in practice, standardizing on one piece of > infrastructure is often > the only way to get anything done. But in that case there is a risk for the design to be bad. Modularity should always be the easiest possible. > And users care a lot more about the > fact that the default > display manager works nicely than the fact that they can switch to 20 > different display > managers... Depends on the users. I am a power user and I care about being able to use the display manager, init, window manager, programming language, mailer I like more. Sure, it may be better for many users but I don't think locking stuff it is a good way to attract contributors. Providing alternatives has always been a good way to move along in fedora extras, hoping it'll still be true after the merge. -- Pat From davidz at redhat.com Mon Feb 12 17:59:29 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 12:59:29 -0500 Subject: Heads up for login managers In-Reply-To: <1171302855.2860.42.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> Message-ID: <1171303169.2860.46.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 12:54 -0500, David Zeuthen wrote: > If you have ideas on how to fix Linux so we can have a better security > model where this is not possible I'd be happy to hear about it. Repeating my idea 1. Login manager tags the desktop login process with a random cookie 2. Unprivileged processes cannot read nor write the cookie 3. The cookie is inherited by all child processes 4. Privileged processes, like ConsoleKit daemon, can read the cookie Again, ConsoleKit is designed in a way so it's possible to change this over from XDG_SESSION_COOKIE. Someone, probably kernel people, just needs to implement this. Thanks. David From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 12 18:03:03 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 12 Feb 2007 19:03:03 +0100 Subject: Problem with CVS ACLs Message-ID: <20070212190303.34366980@python3.es.egwn.lan> Hi, Bill just created the "libmp4v2" CVS module for me, where I added all the files I wanted to the various branches, and removed the pkg.acl file. But when I went ahead and did a "cvs commit" for all the changes at once, I got this : [dude at python3 libmp4v2]$ cvs commit cvs commit: Examining . cvs commit: Examining FC-5 cvs commit: Examining FC-6 cvs commit: Examining devel thias is the package owner - allowing ACL changes for libmp4v2. **** Access denied: thias is not in ACL for rpms/libmp4v2 cvs commit: Pre-commit check failed **** Access denied: thias is not in ACL for rpms/libmp4v2/FC-5 cvs commit: Pre-commit check failed **** Access denied: thias is not in ACL for rpms/libmp4v2/FC-6 cvs commit: Pre-commit check failed **** Access denied: thias is not in ACL for rpms/libmp4v2/devel cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! cvs commit: saving log message in /tmp/cvsPZljJI The mail to the list about ACLs mentions that if a maintainer doesn't want any ACL restrictions for a package, he just needs to remove the pkg.acl file... hmmm... so why is this happening? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.69 0.58 0.60 From pertusus at free.fr Mon Feb 12 18:09:06 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 12 Feb 2007 19:09:06 +0100 Subject: Heads up for login managers In-Reply-To: <20070212172440.GA13594@nostromo.devel.redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <45CD32B9.9080104@redhat.com> <1171292582.7008.8.camel@localhost.localdomain> <45D08A16.9040509@math.unl.edu> <20070212154244.GA2761@free.fr> <45D08EA5.1010608@redhat.com> <20070212165836.GB6224@free.fr> <20070212172440.GA13594@nostromo.devel.redhat.com> Message-ID: <20070212180906.GE6224@free.fr> On Mon, Feb 12, 2007 at 12:24:40PM -0500, Bill Nottingham wrote: > Patrice Dumas (pertusus at free.fr) said: > > In that case there is a flaw in the infrastructure design, like not > > enough modularity or a missing API. Every piece of fedora should be > > replaceable with something that implements the same interface to a > > known protocol or something like that. > > How is talking to dbus not a 'same interface to a known protocol'? Indeed it is. I never argued against that. My response was about using a single component instead of having replaceable components around an interface. -- Pat From alan at redhat.com Mon Feb 12 18:22:33 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 13:22:33 -0500 Subject: Heads up for login managers In-Reply-To: <1171302855.2860.42.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> Message-ID: <20070212182233.GA18757@devserv.devel.redhat.com> On Mon, Feb 12, 2007 at 12:54:14PM -0500, David Zeuthen wrote: > secure (the cookies are dispensed by ConsoleKit and thus random, e.g. > you can't guess the cookie that other users have); just don't change > XDG_SESSION_COOKIE. That ought to be ok if they are truely random, sufficiently long and not subject to a usable timing attack yes. > Which is not good enough; we need a model where we can make a > distinction between the actual sessions so we can deny service to > sessions depending on whether they are active / local or whatnot. Do you > agree this is an important goal? What guarantees we make, and more I don't understand why you require security for this. I can see why it is useful in an advisory manner (typing reboot in the wrong window failing because it is remote even though I have a local session on the tagret box may save a few backsides by avoiding errors) > model where this is not possible I'd be happy to hear about it. Thinking > about it, I agree it wouldn't make sense; you're already logged in > locally so you could just have a VNC server or equivalent running and > you could use this to use the privileges exposed by the local session. > So I'm not sure what the fuss is about? I'm not sure what you are trying to do that doesn't just work already. If your model is that there are some set of users who have processes on the system, and that 1 or more of those users are members of a subset who have 'special powers' because at that moment they posess a session which is 'active', 'local', etc then you need to ensure that the privileged agent which manages the creation of sessions/switching of active session and the privileged agents which implement the special powers share a common dynamic list/database indicating which uids are currently entitled to exercise special powers. Sessions don't seem relevant here except that ownership of one in certain states gives you certain power at that time. We seem to be talking (and no I wouldnt do the implementation in sh..) gdm login touch /var/sessions/auth-$uid gdm logout rm /var/sessions/auth-$uid reboot if [ -e /var/sessions/auth-$uid] ; then Our security is by uid, our file and memory level security is by uid so that is the security you get for most things. (Passed file handles are a bit more interesting ways of passing rights) Having a non security based notion of 'the active session' not 'the uid of the active session' makes sense but that can be very relaxed - just pass XDG_SESSION_COOKIE around explicitly. I can extract the key from one app to another of the same uid is easy but a deliberate act by something in the same security domain. In other words security: uid in the dynamic list of folk entitled to super-power X accident avoidance: explicitply passed XDG_SESSION_COOKIE with a request. Once you want to distribute that auth then it seems to be it really does turn into a hard problem, and that maps directly to kerberos. Alan From alan at redhat.com Mon Feb 12 18:36:26 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 13:36:26 -0500 Subject: Heads up for login managers In-Reply-To: <1171303169.2860.46.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <1171303169.2860.46.camel@zelda.fubar.dk> Message-ID: <20070212183626.GC18757@devserv.devel.redhat.com> On Mon, Feb 12, 2007 at 12:59:29PM -0500, David Zeuthen wrote: > Repeating my idea > > 1. Login manager tags the desktop login process with a random cookie We use a cookie called "uid" and one called "gid". > 2. Unprivileged processes cannot read nor write the cookie We let them read it, but not write it. > 3. The cookie is inherited by all child processes Yes. > 4. Privileged processes, like ConsoleKit daemon, can read the cookie Yes. When a message is sent via unix domain sockets the cookie is made available to the recipient solely for checking. Alan From davidz at redhat.com Mon Feb 12 18:41:19 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 13:41:19 -0500 Subject: Heads up for login managers In-Reply-To: <20070212183626.GC18757@devserv.devel.redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <1171303169.2860.46.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> Message-ID: <1171305679.2860.64.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 13:36 -0500, Alan Cox wrote: > We use a cookie called "uid" and one called "gid". The problem is that these are not per-session; am not sure why that is so difficult to understand. > > 4. Privileged processes, like ConsoleKit daemon, can read the cookie > > Yes. When a message is sent via unix domain sockets the cookie is made > available to the recipient solely for checking. No reason to be patronizing and assuming that I'd forget UNIX 101. David From buildsys at fedoraproject.org Mon Feb 12 18:45:00 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 12 Feb 2007 13:45:00 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-02-12 Message-ID: <20070212184500.F021F15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): autofs FC6-updates > FC7 (1:5.0.1-0.rc3.16 > 1:5.0.1-0.rc3.15) boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdewebdev FC6-updates > FC7 (6:3.5.6-0.1.fc6 > 6:3.5.5-0.1.fc6) libwnck FC6-updates > FC7 (0:2.16.3-1.fc6 > 0:2.16.2-1.fc7) libxslt FC6-updates > FC7 (0:1.1.20-1.fc6 > 0:1.1.20-1) logrotate FC6-updates > FC7 (0:3.7.4-12.fc6 > 0:3.7.4-11.fc7) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) samba FC5-updates > FC7 (0:3.0.24-1.fc5 > 0:3.0.23c-2) FC6-updates > FC7 (0:3.0.24-1.fc6 > 0:3.0.23c-2) screen FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) sound-juicer FC6-updates > FC7 (0:2.16.3-1.fc6 > 0:2.16.2-3.fc7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) wordtrans FC6-updates > FC7 (0:1.1pre13-14.1.fc6 > 0:1.1pre13-14) cgoorah AT yahoo.com.au: kdmtheme FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) 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) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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: 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) 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) 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) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lists AT forevermore.net: yafc FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.fc6) mdehaan AT redhat.com: cobbler FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.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 linux.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) tagoh AT redhat.com: mew FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) 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) wtogami AT redhat.com: thunderbird FC6-updates > FC7 (0:1.5.0.9-8.fc6 > 0:1.5.0.9-7.fc7) ynakam AT hitachisoft.jp: seedit FE6 > FE7 (0:2.1.0-3.fc6 > 0:2.1.0-2.fc7) ---------------------------------------------------------------------- autofs: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:5.0.1-0.rc3.16 > 1:5.0.1-0.rc3.15) boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.fc6) 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) 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) 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) 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) kdewebdev: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (6:3.5.6-0.1.fc6 > 6:3.5.5-0.1.fc6) kdmtheme: cgoorah AT yahoo.com.au FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) libwnck: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.16.3-1.fc6 > 0:2.16.2-1.fc7) libxslt: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.1.20-1.fc6 > 0:1.1.20-1) logrotate: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.7.4-12.fc6 > 0:3.7.4-11.fc7) mew: tagoh AT redhat.com FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) 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) samba: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.0.24-1.fc5 > 0:3.0.23c-2) FC6-updates > FC7 (0:3.0.24-1.fc6 > 0:3.0.23c-2) screen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) seahorse: skvidal AT linux.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) seedit: ynakam AT hitachisoft.jp FE6 > FE7 (0:2.1.0-3.fc6 > 0:2.1.0-2.fc7) sound-juicer: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.16.3-1.fc6 > 0:2.16.2-3.fc7) systemtap: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) thunderbird: wtogami AT redhat.com FC6-updates > FC7 (0:1.5.0.9-8.fc6 > 0:1.5.0.9-7.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) 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) wordtrans: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.1pre13-14.1.fc6 > 0:1.1pre13-14) 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) yafc: lists AT forevermore.net FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.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 jwboyer at jdub.homelinux.org Mon Feb 12 18:46:09 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 12 Feb 2007 12:46:09 -0600 Subject: Problem with CVS ACLs In-Reply-To: <20070212190303.34366980@python3.es.egwn.lan> References: <20070212190303.34366980@python3.es.egwn.lan> Message-ID: <1171305969.4003.20.camel@zod.rchland.ibm.com> On Mon, 2007-02-12 at 19:03 +0100, Matthias Saou wrote: > Hi, > > Bill just created the "libmp4v2" CVS module for me, where I added all > the files I wanted to the various branches, and removed the pkg.acl > file. But when I went ahead and did a "cvs commit" for all the changes > at once, I got this : > > [dude at python3 libmp4v2]$ cvs commit > cvs commit: Examining . > cvs commit: Examining FC-5 > cvs commit: Examining FC-6 > cvs commit: Examining devel > thias is the package owner - allowing ACL changes for libmp4v2. > **** Access denied: thias is not in ACL for rpms/libmp4v2 > cvs commit: Pre-commit check failed > **** Access denied: thias is not in ACL for rpms/libmp4v2/FC-5 > cvs commit: Pre-commit check failed > **** Access denied: thias is not in ACL for rpms/libmp4v2/FC-6 > cvs commit: Pre-commit check failed > **** Access denied: thias is not in ACL for rpms/libmp4v2/devel > cvs commit: Pre-commit check failed > cvs [commit aborted]: correct above errors first! > cvs commit: saving log message in /tmp/cvsPZljJI > > The mail to the list about ACLs mentions that if a maintainer > doesn't want any ACL restrictions for a package, he just needs to remove > the pkg.acl file... hmmm... so why is this happening? It takes up to an hour for the server side to sync. Have you wait a bit and tried again? josh From davidz at redhat.com Mon Feb 12 18:48:26 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 13:48:26 -0500 Subject: Heads up for login managers In-Reply-To: <20070212182233.GA18757@devserv.devel.redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <20070212182233.GA18757@devserv.devel.redhat.com> Message-ID: <1171306106.2860.72.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 13:22 -0500, Alan Cox wrote: > > Which is not good enough; we need a model where we can make a > > distinction between the actual sessions so we can deny service to > > sessions depending on whether they are active / local or whatnot. Do you > > agree this is an important goal? What guarantees we make, and more > > I don't understand why you require security for this. I can see why it is > useful in an advisory manner (typing reboot in the wrong window failing > because it is remote even though I have a local session on the tagret box > may save a few backsides by avoiding errors) Two sessions in fast user switching on a single seat. One web cam. You really want to make sure that the inactive session cannot use the web cam. Yes, to do this in a really secure manner you want revoke() and probably something even better than this proposal http://lwn.net/Articles/192632/ E.g. we want to say "revoke all access to /dev/video for processes in this or that session". Without revoke we can at least remove ACL's on the device file. > If your model is that there are some set of users who have processes > on the system, and that 1 or more of those users are members of a subset > who have 'special powers' because at that moment they posess a session which > is 'active', 'local', etc then you need to ensure that the privileged > agent which manages the creation of sessions/switching of active session and > the privileged agents which implement the special powers share a common > dynamic list/database indicating which uids are currently entitled to exercise > special powers. That's called ConsoleKit, please see http://fedoraproject.org/wiki/Desktop/FastUserSwitching for details. Entities that manage e.g. device file permissions can hook into this to add / remove ACL's on devices as well as calling revoke() (if that is available) on session switching. David From tmraz at redhat.com Mon Feb 12 18:58:18 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 12 Feb 2007 19:58:18 +0100 Subject: Heads up for login managers In-Reply-To: <1171305679.2860.64.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <1171303169.2860.46.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> Message-ID: <1171306698.3220.17.camel@perun.kabelta.loc> On Mon, 2007-02-12 at 13:41 -0500, David Zeuthen wrote: > On Mon, 2007-02-12 at 13:36 -0500, Alan Cox wrote: > > We use a cookie called "uid" and one called "gid". > > The problem is that these are not per-session; am not sure why that is > so difficult to understand. The session is just uid + time when the user is logged on/active. As Alan wrote in his other e-mail - you should base the session management authorization checks on the uid+time notion and use the session cookie just as advisory. Otherwise you're creating just another path which can be used to elevate priviledges. But perhaps you already check that in ConsoleKit - I didn't read the source yet. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From sgrubb at redhat.com Mon Feb 12 19:10:58 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 12 Feb 2007 14:10:58 -0500 Subject: Heads up for login managers In-Reply-To: <1171305679.2860.64.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> Message-ID: <200702121410.58951.sgrubb@redhat.com> On Monday 12 February 2007 13:41, David Zeuthen wrote: > > We use a cookie called "uid" and one called "gid". > > The problem is that these are not per-session; am not sure why that is > so difficult to understand. I just checked the wiki (http://en.wikipedia.org/wiki/Fast_User_Switching) and it says this: "It allows users to switch between user accounts on a single PC without quitting applications and logging out." So it seems to indicate that UID is the right granularity. -Steve From davidz at redhat.com Mon Feb 12 19:18:41 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 14:18:41 -0500 Subject: Heads up for login managers In-Reply-To: <1171306698.3220.17.camel@perun.kabelta.loc> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <1171303169.2860.46.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> <1171306698.3220.17.camel@perun.kabelta.loc> Message-ID: <1171307921.2860.87.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 19:58 +0100, Tomas Mraz wrote: > On Mon, 2007-02-12 at 13:41 -0500, David Zeuthen wrote: > > On Mon, 2007-02-12 at 13:36 -0500, Alan Cox wrote: > > > We use a cookie called "uid" and one called "gid". > > > > The problem is that these are not per-session; am not sure why that is > > so difficult to understand. > > The session is just uid + time when the user is logged on/active. As > Alan wrote in his other e-mail - you should base the session management > authorization checks on the uid+time notion and use the session cookie > just as advisory. Otherwise you're creating just another path which can > be used to elevate priviledges. But perhaps you already check that in > ConsoleKit - I didn't read the source yet. The checks against XDG_SESSION_COOKIE is only used to limit access, never to grant access; the algorithm is for e.g. checking whether a called is allowed to call e.g. Mount() or Suspend() on HAL goes like this 1. Someone calls into HAL; we get the uid and pid 2. /var/run/console is checked for the uid; if user is not there we deny (this is actually done in the system message bus daemon) 3. We ask ConsoleKit for the Session object given the caller's pid and then ask ConsoleKit whether that Session is active. If ConsoleKit says no, we deny (this is done in HAL) (As you can see from the Wiki I linked to, ConsoleKit is actively tracking the active session) Today pam_console is responsible for maintaining /var/run/console but for Fedora 8 I envision ConsoleKit completely replacing pam_console as it keeps tracks of users given that display managers (like gdm) is using it. For device file management in Fedora 7, HAL will be modified to grant / remove ACL's on device files when users log in or out. HAL will use ConsoleKit to do be notified of these events. If we want we could also grant / remove ACL's (and call revoke()) when sessions become active / inactive. The webcam example I posted in another mail comes to mind here; you really don't want inactive sessions to use the webcam to spy on the user in the active session. Ditto for sound cards. David From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 12 19:19:32 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 12 Feb 2007 20:19:32 +0100 Subject: Problem with CVS ACLs In-Reply-To: <1171305969.4003.20.camel@zod.rchland.ibm.com> References: <20070212190303.34366980@python3.es.egwn.lan> <1171305969.4003.20.camel@zod.rchland.ibm.com> Message-ID: <20070212201932.6e0a5431@python3.es.egwn.lan> Josh Boyer wrote : > It takes up to an hour for the server side to sync. Have you wait a bit > and tried again? Nope, I hadn't understood that I had to wait, which apparently was the problem. All is well now. Thanks a lot to notting for all the boring work he seems to be doing manually for the CVS modules creation! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.79 1.36 1.60 From davidz at redhat.com Mon Feb 12 19:22:17 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 14:22:17 -0500 Subject: Heads up for login managers In-Reply-To: <200702121410.58951.sgrubb@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> Message-ID: <1171308137.2860.92.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 14:10 -0500, Steve Grubb wrote: > On Monday 12 February 2007 13:41, David Zeuthen wrote: > > > We use a cookie called "uid" and one called "gid". > > > > The problem is that these are not per-session; am not sure why that is > > so difficult to understand. > > I just checked the wiki (http://en.wikipedia.org/wiki/Fast_User_Switching) and > it says this: > > "It allows users to switch between user accounts on a single PC without > quitting applications and logging out." > > So it seems to indicate that UID is the right granularity. No. Again, it's a (mild?) security problem if an inactive session can spy on another session using sound or webcam capture. Just think of bored grad students in a computer lab. Hence why we need to revoke access to devices for inactive sessions. Also why we need to track the sessions. Right now XDG_SESSION_COOKIE provides that mechanism and I'm asking for a kernel extension so we don't need to rely on an environment variable being set. I'm _not_ suggesting to depart from file access being managed only by uid:gid, I'm just saying we need that + revoke(). David From rdieter at math.unl.edu Mon Feb 12 19:23:39 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 12 Feb 2007 13:23:39 -0600 Subject: Heads up for login managers In-Reply-To: <200702121410.58951.sgrubb@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> Message-ID: <45D0BEBB.5060608@math.unl.edu> Steve Grubb wrote: > On Monday 12 February 2007 13:41, David Zeuthen wrote: >>> We use a cookie called "uid" and one called "gid". >> The problem is that these are not per-session; am not sure why that is >> so difficult to understand. > > I just checked the wiki (http://en.wikipedia.org/wiki/Fast_User_Switching) and > it says this: > > "It allows users to switch between user accounts on a single PC without > quitting applications and logging out." > > So it seems to indicate that UID is the right granularity. One could argue that this same technology could be used to switch the *same* user between gnome and kde sessions, for example. (: -- Rex From alan at redhat.com Mon Feb 12 19:36:46 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 14:36:46 -0500 Subject: Heads up for login managers In-Reply-To: <1171305679.2860.64.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <1171303169.2860.46.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> Message-ID: <20070212193646.GA25434@devserv.devel.redhat.com> On Mon, Feb 12, 2007 at 01:41:19PM -0500, David Zeuthen wrote: > On Mon, 2007-02-12 at 13:36 -0500, Alan Cox wrote: > > We use a cookie called "uid" and one called "gid". > > The problem is that these are not per-session; am not sure why that is > so difficult to understand. > > > > 4. Privileged processes, like ConsoleKit daemon, can read the cookie > > > > Yes. When a message is sent via unix domain sockets the cookie is made > > available to the recipient solely for checking. > > No reason to be patronizing and assuming that I'd forget UNIX 101. That was not the goal. The point was that what you appear to be trying to do maps directly onto the existing uid/gid security. Alan From ajackson at redhat.com Mon Feb 12 19:30:31 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 12 Feb 2007 14:30:31 -0500 Subject: Heads up for login managers In-Reply-To: <20070212165836.GB6224@free.fr> References: <1171071170.2935.63.camel@zelda.fubar.dk> <45CD32B9.9080104@redhat.com> <1171292582.7008.8.camel@localhost.localdomain> <45D08A16.9040509@math.unl.edu> <20070212154244.GA2761@free.fr> <45D08EA5.1010608@redhat.com> <20070212165836.GB6224@free.fr> Message-ID: <1171308631.7008.16.camel@localhost.localdomain> On Mon, 2007-02-12 at 17:58 +0100, Patrice Dumas wrote: > On Mon, Feb 12, 2007 at 10:58:29AM -0500, Matthias Clasen wrote: > > > > Because it doesn't make much sense ? If we ship 5 copies of a central > > piece of infrastructure, > > it means that any change to that infrastruture becomes 50 times harder... > > In that case there is a flaw in the infrastructure design, like not > enough modularity or a missing API. Every piece of fedora should be > replaceable with something that implements the same interface to a > known protocol or something like that. xdm, however, is not an interface worthy of support or emulation. - ajax From sgrubb at redhat.com Mon Feb 12 19:42:01 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 12 Feb 2007 14:42:01 -0500 Subject: Heads up for login managers In-Reply-To: <1171308137.2860.92.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> Message-ID: <200702121442.01944.sgrubb@redhat.com> On Monday 12 February 2007 14:22, David Zeuthen wrote: > On Mon, 2007-02-12 at 14:10 -0500, Steve Grubb wrote: > > "It allows users to switch between user accounts on a single PC without > > quitting applications and logging out." > > > > So it seems to indicate that UID is the right granularity. > > No. Again, it's a (mild?) security problem if an inactive session can > spy on another session using sound or webcam capture. Just think of > bored grad students in a computer lab. Inactive sessions should have no access to hardware. Any kind of simultaneous sharing has potentially created a covert channel. Besides, why does considering UID to be the session identifier lead to people being able to spy on each other? > Hence why we need to revoke access to devices for inactive sessions. Agreed. > Also why we need to track the sessions. Right now XDG_SESSION_COOKIE > provides that mechanism and I'm asking for a kernel extension so we > don't need to rely on an environment variable being set. So could UID. All you need is a unique identifier for each session. UID can do that. Whatever you use, it has to be auditable. > I'm _not_ suggesting to depart from file access being managed only by > uid:gid, I'm just saying we need that + revoke(). I still don't see why a cookie provides protection and UID does not. -Steve From davidz at redhat.com Mon Feb 12 19:43:13 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 14:43:13 -0500 Subject: Heads up for login managers In-Reply-To: <20070212193646.GA25434@devserv.devel.redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <1171303169.2860.46.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> <20070212193646.GA25434@devserv.devel.redhat.com> Message-ID: <1171309393.2860.99.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 14:36 -0500, Alan Cox wrote: > The point was that what you appear to be trying > to do maps directly onto the existing uid/gid security. Yea, that's correct. In other words I'm not suggest to modify any file systems to record uid_t:gid_t:session_t instead of just uid_t:gid_t. So f-u-s will come with the caveat that any login session (even remote) can use any device / service available to any other login session of the same user. And I think that's fine; we just have to release note it somewhere. (and the other things I'm saying are 1) we really want revoke() to ensure privacy of sessions on the same seat; and 2) it would be nice to use a kernel mechanism rather than the rather ugly XDG_SESSION_COOKIE mechanism.) David From alan at redhat.com Mon Feb 12 19:43:33 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 14:43:33 -0500 Subject: Heads up for login managers In-Reply-To: <1171306106.2860.72.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <20070212182233.GA18757@devserv.devel.redhat.com> <1171306106.2860.72.camel@zelda.fubar.dk> Message-ID: <20070212194333.GC25434@devserv.devel.redhat.com> On Mon, Feb 12, 2007 at 01:48:26PM -0500, David Zeuthen wrote: > Two sessions in fast user switching on a single seat. One web cam. You > really want to make sure that the inactive session cannot use the web > cam. Yes, to do this in a really secure manner you want revoke() and No you don't. You want to make sure that only the user uid of the currently active session can access the webcam. It doesn't matter if the webcam access then comes from my X session or some other unrelated process, providing it's me it is watching. Trivial example is a user running cron to take 5 minute shots of their activity via cron. The cron fired video grab is definitely not part of some gnome created session but its perfectly fine. What must fail is if I try and take a picture while I've let someone else borrow the seat (and this again is uid not session) > probably something even better than this proposal SELinux can do much of the revoke type duties, but I agree you want revoke really, and its a big Linux failing. Please beat up Al Viro until he understands how urgent it is... Alan From notting at redhat.com Mon Feb 12 19:42:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 14:42:46 -0500 Subject: Heads up for login managers In-Reply-To: <200702121442.01944.sgrubb@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> Message-ID: <20070212194246.GA16334@nostromo.devel.redhat.com> Steve Grubb (sgrubb at redhat.com) said: > > Also why we need to track the sessions. Right now XDG_SESSION_COOKIE > > provides that mechanism and I'm asking for a kernel extension so we > > don't need to rely on an environment variable being set. > > So could UID. All you need is a unique identifier for each session. UID can do > that. Whatever you use, it has to be auditable. UID isn't unique among sessions. Bill From alan at redhat.com Mon Feb 12 19:46:41 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 14:46:41 -0500 Subject: Heads up for login managers In-Reply-To: <1171307921.2860.87.camel@zelda.fubar.dk> References: <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <1171303169.2860.46.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> <1171306698.3220.17.camel@perun.kabelta.loc> <1171307921.2860.87.camel@zelda.fubar.dk> Message-ID: <20070212194641.GD25434@devserv.devel.redhat.com> On Mon, Feb 12, 2007 at 02:18:41PM -0500, David Zeuthen wrote: > The checks against XDG_SESSION_COOKIE is only used to limit access, They are not limiting access. The "session cookie" is free for anything with the same uid to access and use. Its nerf security. Alan From alan at redhat.com Mon Feb 12 19:52:26 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 14:52:26 -0500 Subject: Heads up for login managers In-Reply-To: <20070212194246.GA16334@nostromo.devel.redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <20070212194246.GA16334@nostromo.devel.redhat.com> Message-ID: <20070212195226.GE25434@devserv.devel.redhat.com> On Mon, Feb 12, 2007 at 02:42:46PM -0500, Bill Nottingham wrote: > > So could UID. All you need is a unique identifier for each session. UID can do > > that. Whatever you use, it has to be auditable. > > UID isn't unique among sessions. Our security boundary is the user not the session. Its a fundamental design upon which the OS is based. The cookie is not unique amongst sessions either because I can pass it around freely within tasks with my uid just as I should be able to, and even if I couldn't I could ptrace patch a program with the cookie and my uid to do what I wanted. You could build a security model around this, but then I start the following app in my desktop while(1) read command from named pipe execute command write status to named pipe and we are back to the fact that security in Linux systems is tied to the user (or with SELinux arguably user/role, and then the user/role matters not a cookie) Tell me why your security model gains from poking around unreliably in the environment of a task (which is also btw really slow and a path we optimise against not for) as opposed to operating on the uid. Alan From alan at redhat.com Mon Feb 12 19:53:21 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 14:53:21 -0500 Subject: Heads up for login managers In-Reply-To: <1171309393.2860.99.camel@zelda.fubar.dk> References: <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <1171303169.2860.46.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> <20070212193646.GA25434@devserv.devel.redhat.com> <1171309393.2860.99.camel@zelda.fubar.dk> Message-ID: <20070212195321.GF25434@devserv.devel.redhat.com> On Mon, Feb 12, 2007 at 02:43:13PM -0500, David Zeuthen wrote: > (and the other things I'm saying are 1) we really want revoke() to > ensure privacy of sessions on the same seat; and 2) it would be nice to > use a kernel mechanism rather than the rather ugly XDG_SESSION_COOKIE > mechanism.) 1. Agreed (and SELinux) 2. Your XDG_SESSION_COOKIE doesn't do anything anyway. From davidz at redhat.com Mon Feb 12 19:57:00 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 14:57:00 -0500 Subject: Heads up for login managers In-Reply-To: <20070212194333.GC25434@devserv.devel.redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <20070212182233.GA18757@devserv.devel.redhat.com> <1171306106.2860.72.camel@zelda.fubar.dk> <20070212194333.GC25434@devserv.devel.redhat.com> Message-ID: <1171310220.2860.110.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 14:43 -0500, Alan Cox wrote: > On Mon, Feb 12, 2007 at 01:48:26PM -0500, David Zeuthen wrote: > > Two sessions in fast user switching on a single seat. One web cam. You > > really want to make sure that the inactive session cannot use the web > > cam. Yes, to do this in a really secure manner you want revoke() and > > No you don't. You want to make sure that only the user uid of the currently > active session can access the webcam. It doesn't matter if the webcam > access then comes from my X session or some other unrelated process, providing > it's me it is watching. Correct me if I'm wrong, but today, access to hardware solely relies on whether you can get a file descriptor. This most of the time means that you need to be able to open a device file (ignoring crazy things like SUSE's now defunct resmgr that passes fd's over a socket). Hence, the proposal here is to just manage the permissions, via ACL's, on said device files. And of course revoke() after having removed the ACL. Are you suggesting something else than relying on ACL + revoke()? That would seem to make the system more complex perhaps... Just saying that today's model on hardware access from user space is well understood... > Trivial example is a user running cron to take 5 minute shots of their activity > via cron. The cron fired video grab is definitely not part of some gnome > created session but its perfectly fine. What must fail is if I try and > take a picture while I've let someone else borrow the seat (and this again > is uid not session) That's an interesting example. So perhaps the ACL management system should have a notion of letting people say "apply these ACL's if, and only if, no seat is claiming the device". There's a bug open on this you might want to look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140853 As I'm putting ACL management into HAL (see the proposal in the link in comment 18) putting stuff like "apply these ACL's if, and only if, no seat is claiming the device" is a real possibility. Then again, I'm not really sure whether it's worth the complexity. It might be. > > probably something even better than this proposal > > SELinux can do much of the revoke type duties, but I agree you want revoke > really, and its a big Linux failing. Please beat up Al Viro until he > understands how urgent it is... Sure! I'm not sure he listens to me though. Another point is that all this effort happens upstream (for better and worse) so I'm not sure how much we can rely on SELinux. David From sgrubb at redhat.com Mon Feb 12 20:01:42 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 12 Feb 2007 15:01:42 -0500 Subject: Heads up for login managers In-Reply-To: <20070212194246.GA16334@nostromo.devel.redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <20070212194246.GA16334@nostromo.devel.redhat.com> Message-ID: <200702121501.43019.sgrubb@redhat.com> On Monday 12 February 2007 14:42, Bill Nottingham wrote: > > So could UID. All you need is a unique identifier for each session. UID > > can do that. Whatever you use, it has to be auditable. > > UID isn't unique among sessions. Is it a requirement for a user to log in multiple times? Where are the actual requirements for this subsystem? The wiki page talks about problems, but not what its supposed to allow. The wiki page it references talks about switching between users. -Steve From davidz at redhat.com Mon Feb 12 20:06:29 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 15:06:29 -0500 Subject: Heads up for login managers In-Reply-To: <20070212195321.GF25434@devserv.devel.redhat.com> References: <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <1171303169.2860.46.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> <20070212193646.GA25434@devserv.devel.redhat.com> <1171309393.2860.99.camel@zelda.fubar.dk> <20070212195321.GF25434@devserv.devel.redhat.com> Message-ID: <1171310789.2860.120.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 14:53 -0500, Alan Cox wrote: > On Mon, Feb 12, 2007 at 02:43:13PM -0500, David Zeuthen wrote: > > (and the other things I'm saying are 1) we really want revoke() to > > ensure privacy of sessions on the same seat; and 2) it would be nice to > > use a kernel mechanism rather than the rather ugly XDG_SESSION_COOKIE > > mechanism.) > > 1. Agreed (and SELinux) > > 2. Your XDG_SESSION_COOKIE doesn't do anything anyway. Of course it does. User alan is logged in on two seats A and B. Seat A gives access to Hardware X (say, a usb optical drive). Seat B gives access to Hardware Y (say, another usb optical drive). Login session for alan on seat A is active. Login session for alan on seat B is inactive. Hence, user alan should only have access to hardware Y. Further, programs running for alan on seat B needs to be denied access to certain D-Bus methods on system daemons like Bluez, HAL, NetworkManager and other services. Programs running for alan on seat A need not to be denied this access. The system daemons are smart enough to know what seats the hardware belong to. Bottom line: system-level daemons needs to know more than the uid of the caller. They actually need to know what session they originate from. Hence XDG_SESSION_COOKIE. I'm just asking for a nicer way to do this. Thanks. David From davidz at redhat.com Mon Feb 12 20:10:54 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 15:10:54 -0500 Subject: Heads up for login managers In-Reply-To: <200702121501.43019.sgrubb@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <20070212194246.GA16334@nostromo.devel.redhat.com> <200702121501.43019.sgrubb@redhat.com> Message-ID: <1171311054.2860.125.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 15:01 -0500, Steve Grubb wrote: > On Monday 12 February 2007 14:42, Bill Nottingham wrote: > > > So could UID. All you need is a unique identifier for each session. UID > > > can do that. Whatever you use, it has to be auditable. > > > > UID isn't unique among sessions. > > Is it a requirement for a user to log in multiple times? Where are the actual > requirements for this subsystem? The wiki page talks about problems, but not > what its supposed to allow. The wiki page it references talks about switching > between users. Yes it is. If we ever want to be serious about multi-seat, or a lot more interesting, thin client computing a'la Sun Ray (including session migration) it's a requirement to be able to support this. I'm also a huge proponent of designing systems with artificial limits. Only allowing one login per system is a fundamentally bad idea. Still, I don't see what the fuss is about - XDG_SESSION_COOKIE works well, I just wish the damn kernel would allow me to tag processes like I outlined earlier. David From davidz at redhat.com Mon Feb 12 20:17:02 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 15:17:02 -0500 Subject: Heads up for login managers In-Reply-To: <20070212194641.GD25434@devserv.devel.redhat.com> References: <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <1171303169.2860.46.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> <1171306698.3220.17.camel@perun.kabelta.loc> <1171307921.2860.87.camel@zelda.fubar.dk> <20070212194641.GD25434@devserv.devel.redhat.com> Message-ID: <1171311422.2860.129.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 14:46 -0500, Alan Cox wrote: > On Mon, Feb 12, 2007 at 02:18:41PM -0500, David Zeuthen wrote: > > The checks against XDG_SESSION_COOKIE is only used to limit access, > > They are not limiting access. The "session cookie" is free for anything > with the same uid to access and use. Its nerf security. I never claimed it provided security. You will be able to copy XDG_SESSION_COOKIE from your other processes and that's fine. Just keep in mind it's easier to just run VNC than copying it around. However if we used something else than XDG_SESSION_COOKIE, like tagging a process with a secret cookie that only privileged processes can read/write it would provide real security. David From davidz at redhat.com Mon Feb 12 20:25:03 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 15:25:03 -0500 Subject: Heads up for login managers In-Reply-To: <20070212195226.GE25434@devserv.devel.redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <20070212194246.GA16334@nostromo.devel.redhat.com> <20070212195226.GE25434@devserv.devel.redhat.com> Message-ID: <1171311903.2860.136.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 14:52 -0500, Alan Cox wrote: > Tell me why your security model gains from poking around unreliably in the > environment of a task (which is also btw really slow and a path we optimise > against not for) as opposed to operating on the uid. There's no changes in the security model; any login session from user FOO can access resources over D-Bus from all of FOO's login sessions by tweaking XDG_SESSION_COOKIE. They also be able to access device files without any problems. This is like pam_console. No changes. You might even consider it a feature. We need XDG_SESSION_COOKIE to make sure what desktop session a D-Bus call originates from. We can't use uid for this because you might be logged in multiple times and at different seats. For example; if you're inactive at seat A you should not be able to invoke Mount() on HAL on a storage device that is exclusive to seat A just because you're active on seat B. We can do this securely only with XDG_SESSION_COOKIE. If we used uid it wouldn't be secure. I refuse to be part of designing a system that cannot allow multiple logins from the same user. I hope I'm not the only one. David From mclasen at redhat.com Mon Feb 12 20:32:31 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 12 Feb 2007 15:32:31 -0500 Subject: Heads up for login managers In-Reply-To: <1171311903.2860.136.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <20070212194246.GA16334@nostromo.devel.redhat.com> <20070212195226.GE25434@devserv.devel.redhat.com> <1171311903.2860.136.camel@zelda.fubar.dk> Message-ID: <45D0CEDF.10803@redhat.com> David Zeuthen wrote: > > I refuse to be part of designing a system that cannot allow multiple > logins from the same user. I hope I'm not the only one. > > Of course, it is only honest to admit that the desktop currently does have some problems when running multiple sessions as the same user on the same system, and we don't want to encourage doing that. From davidz at redhat.com Mon Feb 12 20:30:54 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 15:30:54 -0500 Subject: Heads up for login managers In-Reply-To: <45D0CEDF.10803@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <20070212194246.GA16334@nostromo.devel.redhat.com> <20070212195226.GE25434@devserv.devel.redhat.com> <1171311903.2860.136.camel@zelda.fubar.dk> <45D0CEDF.10803@redhat.com> Message-ID: <1171312254.2860.139.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 15:32 -0500, Matthias Clasen wrote: > David Zeuthen wrote: > > > > I refuse to be part of designing a system that cannot allow multiple > > logins from the same user. I hope I'm not the only one. > > > > > > Of course, it is only honest to admit that the desktop currently does > have some problems when > running multiple sessions as the same user on the same system, and we > don't want to encourage > doing that. That's a bug in GNOME yes and IIRC mostly because people have difficulties designing multi user systems (e.g. what is per-user and what is per-session). It shouldn't have to be this way. David From mitr at redhat.com Mon Feb 12 20:31:02 2007 From: mitr at redhat.com (Miloslav Trmac) Date: Mon, 12 Feb 2007 21:31:02 +0100 Subject: Heads up for login managers In-Reply-To: <1171311903.2860.136.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <20070212194246.GA16334@nostromo.devel.redhat.com> <20070212195226.GE25434@devserv.devel.redhat.com> <1171311903.2860.136.camel@zelda.fubar.dk> Message-ID: <45D0CE86.6010706@redhat.com> David Zeuthen napsal(a): > We can't use uid for this because you might be > logged in multiple times and at different seats. For example; if you're > inactive at seat A you should not be able to invoke Mount() on HAL on a > storage device that is exclusive to seat A just because you're active on > seat B. That can be prevented by allowing the access to Mount(seat_A, *) only to the UID active at seat A. There is no need to prevent a process with UID $foo running in the inactive session at seat A from accessing Mount(seat_B, *) while a session with UID $foo is active at seat B, is there? Mirek From roland at redhat.com Mon Feb 12 20:31:40 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 12 Feb 2007 12:31:40 -0800 (PST) Subject: Heads up for login managers In-Reply-To: Matthias Clasen's message of Monday, 12 February 2007 15:32:31 -0500 <45D0CEDF.10803@redhat.com> Message-ID: <20070212203141.0E9E31800E4@magilla.sf.frob.com> > Of course, it is only honest to admit that the desktop currently does > have some problems when running multiple sessions as the same user on the > same system, and we don't want to encourage doing that. Sure we do, and the sooner the better so all those bugs get filed and can be fixed before we claim to support any useful multi-session feature. From davidz at redhat.com Mon Feb 12 20:42:35 2007 From: davidz at redhat.com (David Zeuthen) Date: Mon, 12 Feb 2007 15:42:35 -0500 Subject: Heads up for login managers In-Reply-To: <45D0CE86.6010706@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <20070212194246.GA16334@nostromo.devel.redhat.com> <20070212195226.GE25434@devserv.devel.redhat.com> <1171311903.2860.136.camel@zelda.fubar.dk> <45D0CE86.6010706@redhat.com> Message-ID: <1171312955.2860.144.camel@zelda.fubar.dk> On Mon, 2007-02-12 at 21:31 +0100, Miloslav Trmac wrote: > David Zeuthen napsal(a): > > We can't use uid for this because you might be > > logged in multiple times and at different seats. For example; if you're > > inactive at seat A you should not be able to invoke Mount() on HAL on a > > storage device that is exclusive to seat A just because you're active on > > seat B. > That can be prevented by allowing the access to Mount(seat_A, *) only to > the UID active at seat A. But with D-Bus we only get the uid and pid of the caller; how do we figure out if the caller is from a session on Seat A or Seat B? That's perfectly possible since the same user is logged in at A and B. (answer: we use the pid to look up XDG_SESSION_COOKIE) David From mitr at redhat.com Mon Feb 12 20:47:02 2007 From: mitr at redhat.com (Miloslav Trmac) Date: Mon, 12 Feb 2007 21:47:02 +0100 Subject: Heads up for login managers In-Reply-To: <1171312955.2860.144.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <20070212194246.GA16334@nostromo.devel.redhat.com> <20070212195226.GE25434@devserv.devel.redhat.com> <1171311903.2860.136.camel@zelda.fubar.dk> <45D0CE86.6010706@redhat.com> <1171312955.2860.144.camel@zelda.fubar.dk> Message-ID: <45D0D246.3050109@redhat.com> David Zeuthen napsal(a): > On Mon, 2007-02-12 at 21:31 +0100, Miloslav Trmac wrote: >> David Zeuthen napsal(a): >>> We can't use uid for this because you might be >>> logged in multiple times and at different seats. For example; if you're >>> inactive at seat A you should not be able to invoke Mount() on HAL on a >>> storage device that is exclusive to seat A just because you're active on >>> seat B. >> That can be prevented by allowing the access to Mount(seat_A, *) only to >> the UID active at seat A. > > But with D-Bus we only get the uid and pid of the caller; how do we > figure out if the caller is from a session on Seat A or Seat B? That's > perfectly possible since the same user is logged in at A and B. WE DON'T NEED TO. WHY DOES IT MATTER what seat is the calling process on if they can communicate and pass privileges to each other? |> There is no need to prevent a process with UID $foo running in the |> inactive session at seat A from accessing Mount(seat_B, *) while a |> session with UID $foo is active at seat B, is there? Mirek From mattdm at mattdm.org Mon Feb 12 21:32:20 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 12 Feb 2007 16:32:20 -0500 Subject: Heads up for login managers In-Reply-To: <20070212194246.GA16334@nostromo.devel.redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <20070212194246.GA16334@nostromo.devel.redhat.com> Message-ID: <20070212213220.GA30861@jadzia.bu.edu> On Mon, Feb 12, 2007 at 02:42:46PM -0500, Bill Nottingham wrote: > > > provides that mechanism and I'm asking for a kernel extension so we > > > don't need to rely on an environment variable being set. > > So could UID. All you need is a unique identifier for each session. UID can do > > that. Whatever you use, it has to be auditable. > UID isn't unique among sessions. The kernel's session-specific keyring is, though, right? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From wtogami at redhat.com Mon Feb 12 21:38:38 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Feb 2007 16:38:38 -0500 Subject: RFC: CVS Admin with Flags (Version 1) In-Reply-To: <20070205192839.38fe8004@ningauble.scrye.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45C7C3EC.1010300@redhat.com> <20070205192839.38fe8004@ningauble.scrye.com> Message-ID: <45D0DE5E.50504@redhat.com> Kevin Fenzi wrote: >> 4) CVS Admins get e-mail about fedora-cvs flag. All context of the >> review is within the bug itself, so they can easily read all details >> about the package and verify approval validity. The Admin then >> creates CVS directories and sets owner. Sets fedora-cvs flag to >> BLANK. 5) Owner checks in and builds. > > Sounds great. > How about also having the admin close the bug when they set the flag > back to BLANK in step 4? One less thing for the submitter to forget to > do. > I don't think this is a good idea. CVS admins should not get too deep into the package process itself. Closing a bug should be an explicit decision of the owner/reviewer pair when the job is truly done and verified. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Feb 12 21:43:40 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Feb 2007 16:43:40 -0500 Subject: VOTE: CVS Admin with Flags (Version 2) In-Reply-To: <20070205213236.GI4858@nostromo.devel.redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> Message-ID: <45D0DF8C.1030002@redhat.com> FESCO Members, I would like this process to be ratified in order to get rid of CVSSyncNeeded. If you think the process below should be adjusted before ratification, please reply with comments. This has NOTHING to do with the review process which must be fixed independently. (NOTE, anybody may comment, but only FESCO members may vote.) After ratification, we will edit the necessary Wiki pages to reflect this new process. Thanks, Warren Togami wtogami at redhat.com Current Crappy CVSSyncNeeded Wiki Procedure =========================================== http://fedoraproject.org/wiki/Extras/CVSSyncNeeded 1. Request new package and branch. 2. Wait until somebody creates empty directories and edits owners.list. 3. Owner checks stuff in and builds. Using the Wiki for this process has always sucked. We could embed this process within the Bugzilla review tickets themselves. Proposal: CVS Admin with Flags ============================== 1) Review is complete, fedora-review+ 2) Owner writes in the Bugzilla comment something like: FC-5 FC-6 foopackage bobjoebugzilla at gmail.com 3) Set fedora-cvs flag to ? 4) CVS Admins get e-mail about fedora-cvs flag. All context of the review is within the bug itself, so they can easily read all details about the package and verify approval validity. The Admin then creates CVS directories and sets owner in owners.list. Clear the fedora-cvs flag to BLANK. 5) Owner checks in and builds. Benefits ======== - This fedora-cvs flag eliminates the need for CVSSyncNeeded entirely. An actual work queue with tickets! - fedora-cvs can be a simple canned query for CVS admins to see. Awesome possibilities offered via RSS too... =) - You could also use the fedora-cvs flag with explicit instructions within any bug to do special requests, like: "Please remove audacious-itouch. We made some mistake. Blah blah." Notes ===== - Unlike other flags, fedora-cvs is only BLANK or ?. fedorabugs members may request fedora-cvs by setting it to ?. This sends an e-mail to CVS Admins, signifying that attention is required. - Syncing from owners.list to CVS ACL's happen every 30 minutes. From notting at redhat.com Mon Feb 12 21:46:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 16:46:03 -0500 Subject: VOTE: CVS Admin with Flags (Version 2) In-Reply-To: <45D0DF8C.1030002@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0DF8C.1030002@redhat.com> Message-ID: <20070212214603.GA8261@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > 4) CVS Admins get e-mail about fedora-cvs flag. All context of the > review is within the bug itself, so they can easily read all details > about the package and verify approval validity. The Admin then creates > CVS directories and sets owner in owners.list. Clear the fedora-cvs > flag to BLANK. Why not set the flag to '+' when done? Bill From wtogami at redhat.com Mon Feb 12 21:51:32 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Feb 2007 16:51:32 -0500 Subject: VOTE: CVS Admin with Flags (Version 2) In-Reply-To: <20070212214603.GA8261@nostromo.devel.redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0DF8C.1030002@redhat.com> <20070212214603.GA8261@nostromo.devel.redhat.com> Message-ID: <45D0E164.7040805@redhat.com> Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: >> 4) CVS Admins get e-mail about fedora-cvs flag. All context of the >> review is within the bug itself, so they can easily read all details >> about the package and verify approval validity. The Admin then creates >> CVS directories and sets owner in owners.list. Clear the fedora-cvs >> flag to BLANK. > > Why not set the flag to '+' when done? > One possibility is that fedora-cvs might be requested once, something done, and fedora-cvs might be requested again. ? meaning "I need CVS admin attention". It could be cleared after CVS admin is no longer needed. I suppose it could be +, but what is the actual benefit? Warren Togami wtogami at redhat.com From pertusus at free.fr Mon Feb 12 21:49:06 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 12 Feb 2007 22:49:06 +0100 Subject: VOTE: CVS Admin with Flags (Version 2) In-Reply-To: <45D0DF8C.1030002@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0DF8C.1030002@redhat.com> Message-ID: <20070212214905.GA3261@free.fr> On Mon, Feb 12, 2007 at 04:43:40PM -0500, Warren Togami wrote: > 2) Owner writes in the Bugzilla comment something like: > > FC-5 FC-6 foopackage bobjoebugzilla at gmail.com There shouldn't be any mail adress in bugzilla comments, they may be viewed by anybody (at least it was like that before). -- Pat From wtogami at redhat.com Mon Feb 12 21:54:26 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Feb 2007 16:54:26 -0500 Subject: VOTE: CVS Admin with Flags (Version 2) In-Reply-To: <20070212214905.GA3261@free.fr> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0DF8C.1030002@redhat.com> <20070212214905.GA3261@free.fr> Message-ID: <45D0E212.4060402@redhat.com> Patrice Dumas wrote: > On Mon, Feb 12, 2007 at 04:43:40PM -0500, Warren Togami wrote: >> 2) Owner writes in the Bugzilla comment something like: >> >> FC-5 FC-6 foopackage bobjoebugzilla at gmail.com > > There shouldn't be any mail adress in bugzilla comments, they may > be viewed by anybody (at least it was like that before). > bugzilla addresses are already public in many places, there isn't anything we can currently do about this. Later I would like to use FAS names everywhere instead of Bugzilla addresses, but we aren't there quite yet. Warren Togami wtogami at redhat.com From notting at redhat.com Mon Feb 12 21:54:25 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 16:54:25 -0500 Subject: VOTE: CVS Admin with Flags (Version 2) In-Reply-To: <45D0E164.7040805@redhat.com> References: <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0DF8C.1030002@redhat.com> <20070212214603.GA8261@nostromo.devel.redhat.com> <45D0E164.7040805@redhat.com> Message-ID: <20070212215425.GA8926@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > One possibility is that fedora-cvs might be requested once, something > done, and fedora-cvs might be requested again. ? meaning "I need CVS > admin attention". It could be cleared after CVS admin is no longer needed. > > I suppose it could be +, but what is the actual benefit? Someone could see that the request is handled. If someone needs further changes, it's set back to '?'. Bill From notting at redhat.com Mon Feb 12 21:55:02 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 16:55:02 -0500 Subject: VOTE: CVS Admin with Flags (Version 2) In-Reply-To: <45D0E212.4060402@redhat.com> References: <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0DF8C.1030002@redhat.com> <20070212214905.GA3261@free.fr> <45D0E212.4060402@redhat.com> Message-ID: <20070212215502.GB8926@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > bugzilla addresses are already public in many places, there isn't > anything we can currently do about this. > > Later I would like to use FAS names everywhere instead of Bugzilla > addresses, but we aren't there quite yet. The bz address of the owner should be easy enough to pick out from the associated other talk in the bug. Bill From pertusus at free.fr Mon Feb 12 21:54:51 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 12 Feb 2007 22:54:51 +0100 Subject: VOTE: CVS Admin with Flags (Version 2) In-Reply-To: <45D0E212.4060402@redhat.com> References: <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0DF8C.1030002@redhat.com> <20070212214905.GA3261@free.fr> <45D0E212.4060402@redhat.com> Message-ID: <20070212215451.GB3261@free.fr> On Mon, Feb 12, 2007 at 04:54:26PM -0500, Warren Togami wrote: > > bugzilla addresses are already public in many places, there isn't > anything we can currently do about this. Where? -- Pat From wtogami at redhat.com Mon Feb 12 22:00:25 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Feb 2007 17:00:25 -0500 Subject: VOTE: CVS Admin with Flags (Version 2) In-Reply-To: <20070212215425.GA8926@nostromo.devel.redhat.com> References: <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0DF8C.1030002@redhat.com> <20070212214603.GA8261@nostromo.devel.redhat.com> <45D0E164.7040805@redhat.com> <20070212215425.GA8926@nostromo.devel.redhat.com> Message-ID: <45D0E379.9010503@redhat.com> Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: >> One possibility is that fedora-cvs might be requested once, something >> done, and fedora-cvs might be requested again. ? meaning "I need CVS >> admin attention". It could be cleared after CVS admin is no longer needed. >> >> I suppose it could be +, but what is the actual benefit? > > Someone could see that the request is handled. If someone needs further > changes, it's set back to '?'. > Is there any case where we actually need to keep the fedora-cvs+ data? If so, that's the only reason to use it. Otherwise, I figured that ? or blank is simpler. (NOTE: This is intended to be an improvement over the horribly bad CVSSyncNeeded Wiki process. But this itself is not the desired long-term solution. We may want to replace this with something in the PackageDB later.) Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Feb 12 22:00:57 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Feb 2007 17:00:57 -0500 Subject: VOTE: CVS Admin with Flags (Version 2) In-Reply-To: <20070212215502.GB8926@nostromo.devel.redhat.com> References: <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0DF8C.1030002@redhat.com> <20070212214905.GA3261@free.fr> <45D0E212.4060402@redhat.com> <20070212215502.GB8926@nostromo.devel.redhat.com> Message-ID: <45D0E399.3060609@redhat.com> Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: >> bugzilla addresses are already public in many places, there isn't >> anything we can currently do about this. >> >> Later I would like to use FAS names everywhere instead of Bugzilla >> addresses, but we aren't there quite yet. > > The bz address of the owner should be easy enough to pick out > from the associated other talk in the bug. > That's true, but it is better to explicitly ask for owner, because they could specify one or more owners. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Feb 12 22:09:59 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Feb 2007 17:09:59 -0500 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: <20070205213236.GI4858@nostromo.devel.redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> Message-ID: <45D0E5B7.2040206@redhat.com> FESCO Members, I would like this process to be ratified in order to get rid of CVSSyncNeeded. If you think the process below should be adjusted before ratification, please reply with comments. This has NOTHING to do with the review process which must be fixed independently. Changes since Version 2: - notting pointed out, how do people request branches for a package already imported? Just comment in the bug and set fedora-cvs? again. This works fine even on CLOSED bugs. - Multiple owners are possible. Please comma separate the owners in a list. - Other ways to use fedora-cvs are spelled out explicitly. Thanks, Warren Togami wtogami at redhat.com Current Crappy CVSSyncNeeded Wiki Procedure =========================================== http://fedoraproject.org/wiki/Extras/CVSSyncNeeded 1. Request new package and branch. 2. Wait until somebody creates empty directories and edits owners.list. 3. Owner checks stuff in and builds. Using the Wiki for this process has always sucked. We could embed this process within the Bugzilla review tickets themselves. ================================== = Proposal: CVS Admin with Flags = ================================== New Packages ============ 1) Review is complete, fedora-review+ 2) Owner writes in the Bugzilla comment something like: Please comma separate the co-maintainers if you have more than one. Examples: FC-5 FC-6 foopackage bobjoe at gmail.com FC-6 barpackage bobjoe at gmail.com,mary at example.com 3) Set fedora-cvs flag to ? 4) CVS Admins get e-mail about fedora-cvs flag. All context of the review is within the bug itself, so they can easily read all details about the package and verify approval validity. The Admin then creates CVS directories and sets owner in owners.list. Clear the fedora-cvs flag to BLANK. 5) Owner checks in and builds. More Branches on Existing Packages ================================== 1) Use existing review ticket, even if it is CLOSED, this is fine. 2) Write in a comment the additional branch names you desire. 3) Set fedora-cvs? Change Owner or Add Co-Maintainers ================================== 1) Use existing review ticket, even if it is CLOSED, this is fine. 2) Write in a comment the change request and justification if appropriate. 3) Set fedora-cvs? (If bulk changes are required (i.e. more than six at once), please talk directly to a Fedora CVS administrator.) Special CVS Admin Requests ========================== In some cases you will want special CVS requests, like fixing import accidents or removing packages that were added in error. 1) Use existing review ticket, even if it is CLOSED, this is fine. 2) Write in a comment your request and why it should be done. 3) Set fedora-cvs? Benefits ======== - This fedora-cvs flag eliminates the need for CVSSyncNeeded entirely. An actual work queue with tickets! - fedora-cvs can be a simple canned query for CVS admins to see. Awesome possibilities offered via RSS too... =) Notes ===== - Unlike other flags, fedora-cvs is only BLANK or ?. fedorabugs members may request fedora-cvs by setting it to ?. This sends an e-mail to CVS Admins, signifying that attention is required. - Syncing from owners.list to CVS ACL's happen every 30 minutes. From jkeating at redhat.com Mon Feb 12 22:16:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 17:16:58 -0500 Subject: VOTE: CVS Admin with Flags (Version 2) In-Reply-To: <20070212214905.GA3261@free.fr> References: <45BE7342.1070005@redhat.com> <45D0DF8C.1030002@redhat.com> <20070212214905.GA3261@free.fr> Message-ID: <200702121716.59204.jkeating@redhat.com> On Monday 12 February 2007 16:49, Patrice Dumas wrote: > There shouldn't be any mail adress in bugzilla comments, they may > be viewed by anybody (at least it was like that before). Surely you could obfuscate it right? -- 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 Feb 12 22:18:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 17:18:43 -0500 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: <45D0E5B7.2040206@redhat.com> References: <45BE7342.1070005@redhat.com> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0E5B7.2040206@redhat.com> Message-ID: <200702121718.44146.jkeating@redhat.com> On Monday 12 February 2007 17:09, Warren Togami wrote: > FESCO Members, I would like this process to be ratified in order to get > rid of CVSSyncNeeded. ?If you think the process below should be adjusted > before ratification, please reply with comments. ?This has NOTHING to do > with the review process which must be fixed independently. I'll give this a +1, and hopefully we'll revisit when packageDB and such become realities and we can give people more access to things like creating their own co-maintainers and such. -- 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 Feb 12 22:23:59 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 17:23:59 -0500 Subject: VOTE: CVS Admin with Flags (Version 2) In-Reply-To: <45D0E379.9010503@redhat.com> References: <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0DF8C.1030002@redhat.com> <20070212214603.GA8261@nostromo.devel.redhat.com> <45D0E164.7040805@redhat.com> <20070212215425.GA8926@nostromo.devel.redhat.com> <45D0E379.9010503@redhat.com> Message-ID: <20070212222359.GA10324@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > Is there any case where we actually need to keep the fedora-cvs+ data? It's a record of action easily visible in the bug. If you set it back to blank, someone might think 'wait, did I forget to set this?' > (NOTE: This is intended to be an improvement over the horribly bad > CVSSyncNeeded Wiki process. But this itself is not the desired > long-term solution. We may want to replace this with something in the > PackageDB later.) ... which means another flag living on the bugzilla db forever. Ick. Bill From sgrubb at redhat.com Mon Feb 12 22:47:34 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 12 Feb 2007 17:47:34 -0500 Subject: Heads up for login managers In-Reply-To: <20070212213220.GA30861@jadzia.bu.edu> References: <1171071170.2935.63.camel@zelda.fubar.dk> <20070212194246.GA16334@nostromo.devel.redhat.com> <20070212213220.GA30861@jadzia.bu.edu> Message-ID: <200702121747.34429.sgrubb@redhat.com> On Monday 12 February 2007 16:32, Matthew Miller wrote: > > UID isn't unique among sessions. > > The kernel's session-specific keyring is, though, right? We don't include the contents of any keyring in any audit message. We include everything that has to do with a user's identity and where a command came from. -Steve From alan at redhat.com Mon Feb 12 23:39:54 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 18:39:54 -0500 Subject: Heads up for login managers In-Reply-To: <1171310220.2860.110.camel@zelda.fubar.dk> References: <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <20070212182233.GA18757@devserv.devel.redhat.com> <1171306106.2860.72.camel@zelda.fubar.dk> <20070212194333.GC25434@devserv.devel.redhat.com> <1171310220.2860.110.camel@zelda.fubar.dk> Message-ID: <20070212233954.GA8530@devserv.devel.redhat.com> On Mon, Feb 12, 2007 at 02:57:00PM -0500, David Zeuthen wrote: > Sure! I'm not sure he listens to me though. Another point is that all > this effort happens upstream (for better and worse) so I'm not sure how > much we can rely on SELinux. For Solaris and BSD you have revoke in various forms, for Linux right now you have SELinux and no other real choice but prayer (which isn't the recommended solution to security problems). The revoke side is going to be easier to sort out in the kernel and win those arguments when we have a real clear user of it too Alan From notting at redhat.com Mon Feb 12 23:46:00 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 18:46:00 -0500 Subject: Heads up for login managers In-Reply-To: <200702121747.34429.sgrubb@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <20070212194246.GA16334@nostromo.devel.redhat.com> <20070212213220.GA30861@jadzia.bu.edu> <200702121747.34429.sgrubb@redhat.com> Message-ID: <20070212234600.GC11073@nostromo.devel.redhat.com> Steve Grubb (sgrubb at redhat.com) said: > On Monday 12 February 2007 16:32, Matthew Miller wrote: > > > UID isn't unique among sessions. > > > > The kernel's session-specific keyring is, though, right? > > We don't include the contents of any keyring in any audit message. We include > everything that has to do with a user's identity and where a command came > from. ... but that could be fixed, certainly? Bill From alan at redhat.com Mon Feb 12 23:56:05 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 18:56:05 -0500 Subject: Heads up for login managers In-Reply-To: <1171311422.2860.129.camel@zelda.fubar.dk> References: <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <1171303169.2860.46.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> <1171306698.3220.17.camel@perun.kabelta.loc> <1171307921.2860.87.camel@zelda.fubar.dk> <20070212194641.GD25434@devserv.devel.redhat.com> <1171311422.2860.129.camel@zelda.fubar.dk> Message-ID: <20070212235605.GB8530@devserv.devel.redhat.com> On Mon, Feb 12, 2007 at 03:17:02PM -0500, David Zeuthen wrote: > > with the same uid to access and use. Its nerf security. > > I never claimed it provided security. You will be able to copy > XDG_SESSION_COOKIE from your other processes and that's fine. Just keep > in mind it's easier to just run VNC than copying it around. That bit is really important. If your session cookie is just a non security helper object then you don't need to do sick hacks grovelling around in other processes environment (which isnt safe). You can pass the session id explicitly. The other end knows the uid so can validate the session id with respect to the user. Keep it in the environment but pass it and don't do sick /proc hacks. Use kerberos keys (See below) and it gets kind of hard to pass fake keys too. > However if we used something else than XDG_SESSION_COOKIE, like tagging > a process with a secret cookie that only privileged processes can > read/write it would provide real security. Only in some very narrow cases. If power is acquired through posession of a key then your security boundary is uid. Even if only a privileged process can read or write the key, the mere possession case applies as I can modify any executable I own, or any running image I own. More seriously the moment you want to deal in passing secure secret cookies around and using them as authentication tokens you are doing Kerberos, the difference being MIT has spent years making it secure and doing the crypto right. You can (and IMHO should) look seriously at this point at having the objects you pass explicitly being kerberos keys. At that point all the existing kerberos single sign on, web authentication of services by keys and desktop will be using the very same authority objects, and those objects are directly bindable to NFSv4 for file serving, cryptographically sound and already supported by things like ssh and our tools and libraries. Kerberos is a cross system, cross architecture, cross platform and a standard so its ideal with a "Gnome is not Linux" hat on too. There are some other things kerberos gives you that are powerful too, such as constructs like key granting tickets so you can build heirarchies. Alan From alan at redhat.com Tue Feb 13 00:10:30 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 19:10:30 -0500 Subject: Heads up for login managers In-Reply-To: <1171311903.2860.136.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <20070212194246.GA16334@nostromo.devel.redhat.com> <20070212195226.GE25434@devserv.devel.redhat.com> <1171311903.2860.136.camel@zelda.fubar.dk> Message-ID: <20070213001030.GC8530@devserv.devel.redhat.com> On Mon, Feb 12, 2007 at 03:25:03PM -0500, David Zeuthen wrote: > We need XDG_SESSION_COOKIE to make sure what desktop session a D-Bus > call originates from. We can't use uid for this because you might be > logged in multiple times and at different seats. For example; if you're > inactive at seat A you should not be able to invoke Mount() on HAL on a > storage device that is exclusive to seat A just because you're active on > seat B. We can do this securely only with XDG_SESSION_COOKIE. If we used > uid it wouldn't be secure. No, you are consistently missing the point here. Let us take you example step by step Assertion: XDG_SESSION_COOKIE allows us to tell session A from session B On seat A I write my XDG_SESSION_COOKIE to a file and wait for it to go inactive On seat B I set my XDG_SESSION_COOKIE from the file Seat A and B processes of mine now have the same cookie so can't be told apart On seat B I call Mount() for a storage device on seat A Assertion false. A second problem is a single application running on both seat A and seat B at once under my uid. Let me suggest an alternative assertion: Assertion: uid is sufficient to enforce the desired policy I propose the following logic Aceess a a resource tied to seat A is granted only if the caller has the uid that is the same as the *active* session on seat A That is: Uid = Uid of inactive session on seat A -> REFUSE Uid = Uid unrelated to a session on seat A -> REFUSE Flip it to use kerberos keys (whose posession is controlled by uid and external to the system by shared security policy) and it flies sweetly. From alan at redhat.com Tue Feb 13 00:11:47 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 19:11:47 -0500 Subject: Heads up for login managers In-Reply-To: <1171312955.2860.144.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <20070212194246.GA16334@nostromo.devel.redhat.com> <20070212195226.GE25434@devserv.devel.redhat.com> <1171311903.2860.136.camel@zelda.fubar.dk> <45D0CE86.6010706@redhat.com> <1171312955.2860.144.camel@zelda.fubar.dk> Message-ID: <20070213001147.GD8530@devserv.devel.redhat.com> On Mon, Feb 12, 2007 at 03:42:35PM -0500, David Zeuthen wrote: > But with D-Bus we only get the uid and pid of the caller; how do we > figure out if the caller is from a session on Seat A or Seat B? That's > perfectly possible since the same user is logged in at A and B. We don't care. The caller can be on the moon. What matters is that we know the seat the resource belongs too. From kevin at tummy.com Tue Feb 13 01:08:52 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 12 Feb 2007 18:08:52 -0700 Subject: RFC: CVS Admin with Flags (Version 1) In-Reply-To: <45D0DE5E.50504@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45C7C3EC.1010300@redhat.com> <20070205192839.38fe8004@ningauble.scrye.com> <45D0DE5E.50504@redhat.com> Message-ID: <20070212180852.31064bc9@ningauble.scrye.com> On Mon, 12 Feb 2007 16:38:38 -0500 wtogami at redhat.com (Warren Togami) wrote: > Kevin Fenzi wrote: > >> 4) CVS Admins get e-mail about fedora-cvs flag. All context of the > >> review is within the bug itself, so they can easily read all > >> details about the package and verify approval validity. The Admin > >> then creates CVS directories and sets owner. Sets fedora-cvs flag > >> to BLANK. 5) Owner checks in and builds. > > > > Sounds great. > > How about also having the admin close the bug when they set the flag > > back to BLANK in step 4? One less thing for the submitter to forget > > to do. > > > > I don't think this is a good idea. CVS admins should not get too > deep into the package process itself. Closing a bug should be an > explicit decision of the owner/reviewer pair when the job is truly > done and verified. I suppose, but my thought was that once the package is added to CVS and owners.list (or the package database) there would be a bugzilla component for it. If it failed to build or had other issues, a new non review bug could then be filed against it to track it... Doesn't matter too much, just thought it could streamline the process some more. > > Warren Togami > wtogami at redhat.com kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at tummy.com Tue Feb 13 01:11:02 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 12 Feb 2007 18:11:02 -0700 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: <200702121718.44146.jkeating@redhat.com> References: <45BE7342.1070005@redhat.com> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0E5B7.2040206@redhat.com> <200702121718.44146.jkeating@redhat.com> Message-ID: <20070212181102.3423fbb7@ningauble.scrye.com> On Mon, 12 Feb 2007 17:18:43 -0500 jkeating at redhat.com (Jesse Keating) wrote: > On Monday 12 February 2007 17:09, Warren Togami wrote: > > FESCO Members, I would like this process to be ratified in order to > > get rid of CVSSyncNeeded. ?If you think the process below should be > > adjusted before ratification, please reply with comments. ?This has > > NOTHING to do with the review process which must be fixed > > independently. > > I'll give this a +1, and hopefully we'll revisit when packageDB and > such become realities and we can give people more access to things > like creating their own co-maintainers and such. Ditto... +1 to this process for now, and hopefully we can look again once we have the package database and such in place. 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 Tue Feb 13 01:23:22 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Feb 2007 19:23:22 -0600 Subject: Heads up for login managers In-Reply-To: <20070212233954.GA8530@devserv.devel.redhat.com> References: <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <20070212182233.GA18757@devserv.devel.redhat.com> <1171306106.2860.72.camel@zelda.fubar.dk> <20070212194333.GC25434@devserv.devel.redhat.com> <1171310220.2860.110.camel@zelda.fubar.dk> <20070212233954.GA8530@devserv.devel.redhat.com> Message-ID: >>>>> "AC" == Alan Cox writes: AC> The revoke side is going to be easier to sort out in the kernel AC> and win those arguments when we have a real clear user of it too Is there really any question about the use cases for revoke(), though? My understanding is that everyone knows we need it, but nobody knows just how to implement it properly. - J< From tibbs at math.uh.edu Tue Feb 13 01:32:53 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Feb 2007 19:32:53 -0600 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: <45D0E5B7.2040206@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0E5B7.2040206@redhat.com> Message-ID: +1 from me. The only question I'd have is whether it would be feasible to use Fedora account system IDs instead of email addresses for those who don't want to expose their addresses. (Those who insist on using a different address in bugzilla and the account system would just have to deal, of course.) - J< From wtogami at redhat.com Tue Feb 13 01:44:38 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Feb 2007 20:44:38 -0500 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0E5B7.2040206@redhat.com> Message-ID: <45D11806.90407@redhat.com> Jason L Tibbitts III wrote: > +1 from me. The only question I'd have is whether it would be > feasible to use Fedora account system IDs instead of email addresses > for those who don't want to expose their addresses. (Those who insist > on using a different address in bugzilla and the account system would > just have to deal, of course.) > I agree it would be superior to use the FAS account names everywhere, and have services that need something different to need to deal with it somehow. (Currently we have a tiny hard-coded e-mail to e-mail mapping in the ACL handling code.) This however would be another change to existing code that is live. With other big changes happening, I don't know if it is wise to change this many things at once? A counter-argument however would be... does only owners.list -> CVS ACL use the Bugzilla address and nothing else? If so, why not change it now before this new policy goes live. Warren Togami wtogami at redhat.com From wtogami at redhat.com Tue Feb 13 01:49:12 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Feb 2007 20:49:12 -0500 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: <45D11806.90407@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0E5B7.2040206@redhat.com> <45D11806.90407@redhat.com> Message-ID: <45D11918.4020705@redhat.com> Warren Togami wrote: > Jason L Tibbitts III wrote: >> +1 from me. The only question I'd have is whether it would be >> feasible to use Fedora account system IDs instead of email addresses >> for those who don't want to expose their addresses. (Those who insist >> on using a different address in bugzilla and the account system would >> just have to deal, of course.) >> > > I agree it would be superior to use the FAS account names everywhere, > and have services that need something different to need to deal with it > somehow. (Currently we have a tiny hard-coded e-mail to e-mail mapping > in the ACL handling code.) > > This however would be another change to existing code that is live. With > other big changes happening, I don't know if it is wise to change this > many things at once? > > A counter-argument however would be... does only owners.list -> CVS ACL > use the Bugzilla address and nothing else? If so, why not change it now > before this new policy goes live. http://cvs.fedora.redhat.com/viewcvs/owners/?root=extras I suppose also that it is too easy for e-mail addresses to be harvested from places like this too. I'll look into how difficult it would be to reverse the mapping and use FAS names in owners.list instead of Bugzilla. This might help to simply some things... although it would still need a hard-coded mapping hack in order to allow for the few people who have e-mail addresses that don't match. Warren Togami wtogami at redhat.com From notting at redhat.com Tue Feb 13 01:53:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 20:53:38 -0500 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: <45D11806.90407@redhat.com> References: <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0E5B7.2040206@redhat.com> <45D11806.90407@redhat.com> Message-ID: <20070213015338.GB12724@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > A counter-argument however would be... does only owners.list -> CVS ACL > use the Bugzilla address and nothing else? If so, why not change it now > before this new policy goes live. No, owners.list -> BZ ownership uses it. Bill From mtasaka at ioa.s.u-tokyo.ac.jp Tue Feb 13 01:58:17 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 13 Feb 2007 10:58:17 +0900 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: <45D0E5B7.2040206@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0E5B7.2040206@redhat.com> Message-ID: <45D11B39.20103@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > Changes since Version 2: > - notting pointed out, how do people request branches for a package > already imported? Just comment in the bug and set fedora-cvs? again. > This works fine even on CLOSED bugs. > - Multiple owners are possible. Please comma separate the owners in a > list. > - Other ways to use fedora-cvs are spelled out explicitly. Some questions. How does this work with the renamed packages or packages of which the maintainer changed several times from initial? * Well, there may be the case that the name of the package changed several times (this especially happens for new packages) * Maintainers also change. * After some long time, the "current" maintainer askes, "well, where is the initial review request?" This becomes a trouble especially when the previous maintainer is missing, some people (like sponsors) puts the package into "orphaned" category, and then some other fedorabugs member takes over the maintainership (and at the time the name of the package changed from initial). From wtogami at redhat.com Tue Feb 13 02:20:58 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Feb 2007 21:20:58 -0500 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: <45D11918.4020705@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0E5B7.2040206@redhat.com> <45D11806.90407@redhat.com> <45D11918.4020705@redhat.com> Message-ID: <45D1208A.9050706@redhat.com> Warren Togami wrote: > > http://cvs.fedora.redhat.com/viewcvs/owners/?root=extras > I suppose also that it is too easy for e-mail addresses to be harvested > from places like this too. > > I'll look into how difficult it would be to reverse the mapping and use > FAS names in owners.list instead of Bugzilla. This might help to simply > some things... although it would still need a hard-coded mapping hack in > order to allow for the few people who have e-mail addresses that don't > match. > notting pointed out further complication... like initialcclist can (and does in some cases) contain addresses that are not FAS accounts, or are not even people. (Zombies!) There is also the possibility that there are other scripts that we don't know about using the current owners.list format. Given too many complications and unknowns, I think we should wait until the PackageDB before moving to this. We have too many other things to work on in the short-term to make such an invasive change now. Warren Togami wtogami at redhat.com From a.badger at gmail.com Tue Feb 13 06:50:58 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 12 Feb 2007 22:50:58 -0800 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: <45D0E5B7.2040206@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0E5B7.2040206@redhat.com> Message-ID: <1171349458.4306.338.camel@localhost.localdomain> On Mon, 2007-02-12 at 17:09 -0500, Warren Togami wrote: > FESCO Members, I would like this process to be ratified in order to get > rid of CVSSyncNeeded. If you think the process below should be adjusted > before ratification, please reply with comments. This has NOTHING to do > with the review process which must be fixed independently. > > Changes since Version 2: > - notting pointed out, how do people request branches for a package > already imported? Just comment in the bug and set fedora-cvs? again. > This works fine even on CLOSED bugs. > - Multiple owners are possible. Please comma separate the owners in a list. > - Other ways to use fedora-cvs are spelled out explicitly. > > Thanks, > Warren Togami > wtogami at redhat.com > > Current Crappy CVSSyncNeeded Wiki Procedure > =========================================== > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded > 1. Request new package and branch. > 2. Wait until somebody creates empty directories and edits owners.list. > 3. Owner checks stuff in and builds. > > Using the Wiki for this process has always sucked. We could embed this > process within the Bugzilla review tickets themselves. > > ================================== > = Proposal: CVS Admin with Flags = > ================================== > New Packages > ============ > 1) Review is complete, fedora-review+ > 2) Owner writes in the Bugzilla comment something like: > > Please comma separate the co-maintainers if you have more than one. > Examples: > FC-5 FC-6 foopackage bobjoe at gmail.com > FC-6 barpackage bobjoe at gmail.com,mary at example.com > > 3) Set fedora-cvs flag to ? > 4) CVS Admins get e-mail about fedora-cvs flag. All context of the > review is within the bug itself, so they can easily read all details > about the package and verify approval validity. The Admin then creates > CVS directories and sets owner in owners.list. Clear the fedora-cvs > flag to BLANK. > 5) Owner checks in and builds. > > More Branches on Existing Packages > ================================== > 1) Use existing review ticket, even if it is CLOSED, this is fine. > 2) Write in a comment the additional branch names you desire. > 3) Set fedora-cvs? > > Change Owner or Add Co-Maintainers > ================================== > 1) Use existing review ticket, even if it is CLOSED, this is fine. > 2) Write in a comment the change request and justification if appropriate. > 3) Set fedora-cvs? > > (If bulk changes are required (i.e. more than six at once), please talk > directly to a Fedora CVS administrator.) > > Special CVS Admin Requests > ========================== > In some cases you will want special CVS requests, like fixing import > accidents or removing packages that were added in error. > 1) Use existing review ticket, even if it is CLOSED, this is fine. > 2) Write in a comment your request and why it should be done. > 3) Set fedora-cvs? > > Benefits > ======== > - This fedora-cvs flag eliminates the need for CVSSyncNeeded > entirely. An actual work queue with tickets! > - fedora-cvs can be a simple canned query for CVS admins to see. > Awesome possibilities offered via RSS too... =) > > Notes > ===== > - Unlike other flags, fedora-cvs is only BLANK or ?. fedorabugs members > may request fedora-cvs by setting it to ?. This sends an e-mail to CVS > Admins, signifying that attention is required. > - Syncing from owners.list to CVS ACL's happen every 30 minutes. I think we're going to run into potential confusion with the use of flags here and for determining status during the review. However, I think that using a flag here is better than using CVSSyncNeeded. So I'm +1 here but am noting that it makes me slightly more biased against using flags for reviews. -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 bnocera at redhat.com Tue Feb 13 09:23:00 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 13 Feb 2007 09:23:00 +0000 Subject: Impending FLAC update warning: rebuilds required In-Reply-To: <20070207001731.GB29173@ryvius.pekin.waw.pl> References: <883cfe6d0702031735m5f043a59ja1e3b5c8089d98ff@mail.gmail.com> <20070205190352.GA18421@ryvius.pekin.waw.pl> <883cfe6d0702051758i60833642oaecd4207e5ca3525@mail.gmail.com> <20070207001731.GB29173@ryvius.pekin.waw.pl> Message-ID: <1171358580.30807.20.camel@cookie.hadess.net> On Wed, 2007-02-07 at 01:17 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 06 February 2007 at 02:58, Michel Salim wrote: > > 2007/2/5, Dominik 'Rathann' Mierzejewski : > > >> mkvtoolnix > > > > > >That one is mine. > > > > > >> muine > > >> scummvm > > >> stratagus > > >> xine-lib > > >> xmms-flac > > >> > > >> If your package is on this list, and the new FLAC does not work with > > >> you without further workaround, please follow-up at the Bugzilla > > >> entry. I'll ask Matthias if he can provide a test SRPM. > > > > > >Do you have an updated flac spec somewhere? > > > > > Matthias has put them up (URL is also at the Bugzilla entry): > > http://people.redhat.com/mclasen/flac/ Everything's built in rawhide. I also updated gstreamer-plugins-good for the new lib, but the new flac is still missing from the build tree. > rpmlint complains loudly about them: > W: flac-devel summary-ended-with-dot Static libraries and header files from FLAC. > W: flac summary-ended-with-dot An encoder/decoder for the Free Lossless Audio Codec. > W: flac unversioned-explicit-obsoletes flac-libs > W: flac summary-ended-with-dot An encoder/decoder for the Free Lossless Audio Codec. > W: flac incoherent-version-in-changelog 1.1.2-27 1.1.3-1.fc7 > E: flac obsolete-not-provided flac-libs > E: flac obsolete-not-provided xmms-flac I removed the obsoletes for xmms-flac, as the flac package doesn't provide the FLAC plugin anymore. The rest don't look serious, but feel free to push them to Dan's review, so they can get fixed in time. > mkvtoolnix builds fine against it though. Cool, get ready to rebuild then :) From bnocera at redhat.com Tue Feb 13 09:23:58 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 13 Feb 2007 09:23:58 +0000 Subject: Impending FLAC update warning: rebuilds required In-Reply-To: <1170845858.3660.9.camel@eagle.danny.cz> References: <883cfe6d0702031735m5f043a59ja1e3b5c8089d98ff@mail.gmail.com> <20070205190352.GA18421@ryvius.pekin.waw.pl> <883cfe6d0702051758i60833642oaecd4207e5ca3525@mail.gmail.com> <1170845858.3660.9.camel@eagle.danny.cz> Message-ID: <1171358638.30807.21.camel@cookie.hadess.net> On Wed, 2007-02-07 at 11:57 +0100, Dan Hor?k wrote: > > > Do you have an updated flac spec somewhere? > > > > > Matthias has put them up (URL is also at the Bugzilla entry): > > http://people.redhat.com/mclasen/flac/ > > > > Regards, > > > > I was going to do Merge Review for FLAC, should I set the owner to > Matthias? Current owner in the Bugzilla is "davidz at redhat.com". Also > having the new version in the CVS would be nice. That'd be mine actually. I CC:'ed myself to the bug, feel free to send your comments there. Cheers From arjan at fenrus.demon.nl Tue Feb 13 09:56:11 2007 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 13 Feb 2007 10:56:11 +0100 Subject: Heads up for login managers In-Reply-To: <1171311422.2860.129.camel@zelda.fubar.dk> References: <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <1171303169.2860.46.camel@zelda.fubar.dk> <20070212183626.GC18757@devserv.devel.redhat.com> <1171305679.2860.64.camel@zelda.fubar.dk> <1171306698.3220.17.camel@perun.kabelta.loc> <1171307921.2860.87.camel@zelda.fubar.dk> <20070212194641.GD25434@devserv.devel.redhat.com> <1171311422.2860.129.camel@zelda.fubar.dk> Message-ID: <1171360572.12771.68.camel@laptopd505.fenrus.org> > However if we used something else than XDG_SESSION_COOKIE, like tagging > a process with a secret cookie that only privileged processes can > read/write it would provide real security. just use the kernel keyring infrastructure.. afaik that has per session cookies like this. From arjan at fenrus.demon.nl Tue Feb 13 09:57:24 2007 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 13 Feb 2007 10:57:24 +0100 Subject: Heads up for login managers In-Reply-To: <1171310220.2860.110.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702100906.40011.sgrubb@redhat.com> <1171298414.2860.7.camel@zelda.fubar.dk> <200702121208.25038.sgrubb@redhat.com> <1171301266.2860.27.camel@zelda.fubar.dk> <20070212173842.GB17083@devserv.devel.redhat.com> <1171302855.2860.42.camel@zelda.fubar.dk> <20070212182233.GA18757@devserv.devel.redhat.com> <1171306106.2860.72.camel@zelda.fubar.dk> <20070212194333.GC25434@devserv.devel.redhat.com> <1171310220.2860.110.camel@zelda.fubar.dk> Message-ID: <1171360644.12771.70.camel@laptopd505.fenrus.org> > proposal here is to just manage the permissions, via ACL's, on said > device files. And of course revoke() after having removed the ACL. ACL's suck though.... they make your system rather... slow often, and they have many other downsides. And they don't work on all filesystems either ;) From gilboad at gmail.com Tue Feb 13 11:30:27 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 13 Feb 2007 13:30:27 +0200 Subject: Owners list? Message-ID: <1171366227.29289.5.camel@gilboa-work-dev.localdomain> Hello all, (I may have missed the discussion - my apologies in advanced if this question has been answered 999 times) I'm trying to import two new packages - and in-order to do so, I need to update the owners.list (or at least, it was a prerequisite [1]) However, when I try to commit the updated owners.list, I'm getting rejected due to invalid/missing ACL. Help? - Gilboa [1] http://fedoraproject.org/wiki/Extras/NewPackageProcess From giallu at gmail.com Tue Feb 13 11:36:57 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 13 Feb 2007 12:36:57 +0100 Subject: Owners list? In-Reply-To: <1171366227.29289.5.camel@gilboa-work-dev.localdomain> References: <1171366227.29289.5.camel@gilboa-work-dev.localdomain> Message-ID: On 2/13/07, Gilboa Davara wrote: > Hello all, > > (I may have missed the discussion - my apologies in advanced if this > question has been answered 999 times) > I'm trying to import two new packages - and in-order to do so, I need to > update the owners.list (or at least, it was a prerequisite [1]) > However, when I try to commit the updated owners.list, I'm getting > rejected due to invalid/missing ACL. > > Help? > > - Gilboa > [1] http://fedoraproject.org/wiki/Extras/NewPackageProcess > > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded From gilboad at gmail.com Tue Feb 13 13:05:01 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 13 Feb 2007 15:05:01 +0200 Subject: Owners list? In-Reply-To: References: <1171366227.29289.5.camel@gilboa-work-dev.localdomain> Message-ID: <1171371901.29289.17.camel@gilboa-work-dev.localdomain> On Tue, 2007-02-13 at 12:36 +0100, Gianluca Sforna wrote: > On 2/13/07, Gilboa Davara wrote: > > Hello all, > > > > (I may have missed the discussion - my apologies in advanced if this > > question has been answered 999 times) > > I'm trying to import two new packages - and in-order to do so, I need to > > update the owners.list (or at least, it was a prerequisite [1]) > > However, when I try to commit the updated owners.list, I'm getting > > rejected due to invalid/missing ACL. > > > > Help? > > > > - Gilboa > > [1] http://fedoraproject.org/wiki/Extras/NewPackageProcess > > > > > > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded Done. Thanks, - Gilboa From jwboyer at jdub.homelinux.org Wed Feb 14 02:12:23 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 13 Feb 2007 20:12:23 -0600 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: <45D0E5B7.2040206@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0E5B7.2040206@redhat.com> Message-ID: <1171419143.15310.1.camel@vader.jdub.homelinux.org> On Mon, 2007-02-12 at 17:09 -0500, Warren Togami wrote: > FESCO Members, I would like this process to be ratified in order to get > rid of CVSSyncNeeded. If you think the process below should be adjusted > before ratification, please reply with comments. This has NOTHING to do > with the review process which must be fixed independently. I'll +1 this. Seems to be more streamlined than CVSSyncNeeded. My only question is, who are the CVS admins and do we need a couple more to help with the workload? josh From bugs.michael at gmx.net Wed Feb 14 10:36:17 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 14 Feb 2007 11:36:17 +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: <20070214113617.18bebcb7.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. > > Paul. imlib is still marked as orphaned. From paul at city-fan.org Wed Feb 14 10:39:36 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 14 Feb 2007 10:39:36 +0000 Subject: imlib is orphaned In-Reply-To: <20070214113617.18bebcb7.bugs.michael@gmx.net> References: <20070111214418.e9e6511f.bugs.michael@gmx.net> <45A74B31.7080907@city-fan.org> <20070214113617.18bebcb7.bugs.michael@gmx.net> Message-ID: <45D2E6E8.3050307@city-fan.org> 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. >> >> Paul. > > imlib is still marked as orphaned. I know. It's on my to-do list to update it to the latest upstream version (a nontrivial task as I need to go through all of the patches again), check out/reassign any existing bugs etc. but I've been very busy with $DAYJOB the last few weeks. Still, nobody else seems to have stepped up so I may as well get the ownership changed at least. Paul. From buildsys at fedoraproject.org Wed Feb 14 12:17:07 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 14 Feb 2007 07:17:07 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-02-14 Message-ID: <20070214121707.B057615212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) libxslt FC6-updates > FC7 (0:1.1.20-1.fc6 > 0:1.1.20-1) 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) sound-juicer FC6-updates > FC7 (0:2.16.3-1.fc6 > 0:2.16.2-3.fc7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) cgoorah AT yahoo.com.au: kdmtheme FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) 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) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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: 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) 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) 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) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lists AT forevermore.net: yafc FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.fc6) mdehaan AT redhat.com: cobbler FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.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 linux.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) tagoh AT redhat.com: mew FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) 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) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.fc6) 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) 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) 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) 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) kdmtheme: cgoorah AT yahoo.com.au FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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) mew: tagoh AT redhat.com FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) 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 linux.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) sound-juicer: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.16.3-1.fc6 > 0:2.16.2-3.fc7) 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) 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) yafc: lists AT forevermore.net FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.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 wtogami at redhat.com Wed Feb 14 21:17:12 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 14 Feb 2007 16:17:12 -0500 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: <1171419143.15310.1.camel@vader.jdub.homelinux.org> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0E5B7.2040206@redhat.com> <1171419143.15310.1.camel@vader.jdub.homelinux.org> Message-ID: <45D37C58.70309@redhat.com> Josh Boyer wrote: > On Mon, 2007-02-12 at 17:09 -0500, Warren Togami wrote: >> FESCO Members, I would like this process to be ratified in order to get >> rid of CVSSyncNeeded. If you think the process below should be adjusted >> before ratification, please reply with comments. This has NOTHING to do >> with the review process which must be fixed independently. > > I'll +1 this. Seems to be more streamlined than CVSSyncNeeded. > > My only question is, who are the CVS admins and do we need a couple more > to help with the workload? Right now the CVS admins are a few of the infrastructure leads and RH engineers. Unfortunately, they are all currently within two adjacent timezones. Jesse and I had been talking about spreading the CVS admin responsibility with someone in Europe, and I know a Fedora participant in Asia that might be good too. Full timezone coverage would be a good thing. Warren From bpepple at fedoraproject.org Wed Feb 14 22:06:48 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 14 Feb 2007 17:06:48 -0500 Subject: Plan for tomorrows (20070215) FESCO meeting Message-ID: <1171490808.21788.10.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-meeting on irc.freenode.org: /topic FESCO-Meeting -- Core Package Review Process -- warren? /topic FESCO-Meeting -- Opening Core -- status update -- jeremy, warren /topic FESCO-Meeting -- Encourage co-maintainership -- all, thl /topic FESCO-Meeting -- MISC -- cvs-import changes /topic FESCO-Meeting -- MISC -- Extras 7 preparation -- all /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs /topic FESCO-Meeting -- sponsor nominations -- Parag Ashok Nemade nominated by Jens Petersen Here's a link to the reviews handled by Parag: https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=Review+Request%3A&product=Fedora+Extras&component_text=&query_format=advanced&bug_status=CLOSED&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&fixed_in_type=allwordssubstr&fixed_in=&qa_whiteboard_type=allwordssubstr&qa_whiteboard=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=panemade%40gmail.com&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= 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 Feb 15 05:59:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 15 Feb 2007 06:59:24 +0100 Subject: Updates co-maintainership proposal (was: Re: Plan for tomorrows (20070215) FESCO meeting) In-Reply-To: <1171490808.21788.10.camel@Chuck> References: <1171490808.21788.10.camel@Chuck> Message-ID: <45D3F6BC.3040202@leemhuis.info> On 14.02.2007 23:06, Brian Pepple wrote: > /topic FESCO-Meeting -- Encourage co-maintainership -- all, thl FYI, I reworked the last proposal and some FESCo members looked over it and seemed to agree with it so far, too. See http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership for details. Please comment. CU thl From gauret at free.fr Thu Feb 15 06:45:14 2007 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 15 Feb 2007 07:45:14 +0100 Subject: Impending FLAC update warning: rebuilds required In-Reply-To: <1171358638.30807.21.camel@cookie.hadess.net> References: <883cfe6d0702031735m5f043a59ja1e3b5c8089d98ff@mail.gmail.com> <1170845858.3660.9.camel@eagle.danny.cz> <1171358638.30807.21.camel@cookie.hadess.net> Message-ID: <200702150745.14754.gauret@free.fr> Hey there, It looks FLAC has been rebuilt: http://buildsys.fedoraproject.org/logs/fedora-development-extras/27623-amarok-1.4.5-3.fc7/i386/root.log "Error: Missing Dependency: libFLAC.so.7 is needed by package kdemultimedia" Please rebuild kdemultimedia as soon as possible, this is holding off a security patch to amarok. Thanks, Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr One OS to hook them all One browser to find them One word processor to bring them all And in monopoly, bind them... From pertusus at free.fr Thu Feb 15 09:22:48 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 Feb 2007 10:22:48 +0100 Subject: Updates co-maintainership proposal (was: Re: Plan for tomorrows (20070215) FESCO meeting) In-Reply-To: <45D3F6BC.3040202@leemhuis.info> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> Message-ID: <20070215092248.GA2797@free.fr> On Thu, Feb 15, 2007 at 06:59:24AM +0100, Thorsten Leemhuis wrote: > On 14.02.2007 23:06, Brian Pepple wrote: > >/topic FESCO-Meeting -- Encourage co-maintainership -- all, thl > > FYI, I reworked the last proposal and some FESCo members looked over it > and seemed to agree with it so far, too. See > http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership > for details. Please comment. This seems good to me, although this is a bit long. I have one criticism, I think that for some packages co-maintainership is not needed and a loss of time. On maintainer for all the branches, including EPEL is not an issue for those packages. For examples in the packages I maintain there is asa which hasn't changed since 1994, or libsx - I don't even know if there are actual users for thoses packages. -- Pat From Christian.Iseli at licr.org Thu Feb 15 10:53:31 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 15 Feb 2007 11:53:31 +0100 Subject: VOTE: CVS Admin with Flags (Version 3) In-Reply-To: <45D0E5B7.2040206@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45D0E5B7.2040206@redhat.com> Message-ID: <20070215115331.6a33c97a@ludwig-alpha.unil.ch> On Mon, 12 Feb 2007 17:09:59 -0500, Warren Togami wrote: > FESCO Members, I would like this process to be ratified in order to get > rid of CVSSyncNeeded. If you think the process below should be adjusted > before ratification, please reply with comments. This has NOTHING to do > with the review process which must be fixed independently. That process seems fine to me, so +1 C From Christian.Iseli at licr.org Thu Feb 15 11:00:23 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 15 Feb 2007 12:00:23 +0100 Subject: Updates co-maintainership proposal (was: Re: Plan for tomorrows (20070215) FESCO meeting) In-Reply-To: <45D3F6BC.3040202@leemhuis.info> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> Message-ID: <20070215120023.5bef2079@ludwig-alpha.unil.ch> On Thu, 15 Feb 2007 06:59:24 +0100, Thorsten Leemhuis wrote: > FYI, I reworked the last proposal and some FESCo members looked over it > and seemed to agree with it so far, too. See > http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership > for details. Please comment. "at least three maintainers" looks like an awful lot in case of simple packages. I know it's hard to define "simple", but still... "Maintainers should work towards getting at least one co-maintainer." I don't like this too much. I think the burden should be placed on would-be maintainers to strive to be accepted as co-maintainers, not on overloaded maintainers to be forced to go hunting for co-maintainers. CHF 0.02 C From fedora at leemhuis.info Thu Feb 15 11:19:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 15 Feb 2007 12:19:30 +0100 Subject: Updates co-maintainership proposal In-Reply-To: <20070215120023.5bef2079@ludwig-alpha.unil.ch> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> <20070215120023.5bef2079@ludwig-alpha.unil.ch> Message-ID: <45D441C2.4000109@leemhuis.info> On 15.02.2007 12:00, Christian Iseli wrote: > On Thu, 15 Feb 2007 06:59:24 +0100, Thorsten Leemhuis wrote: >> FYI, I reworked the last proposal and some FESCo members looked over it >> and seemed to agree with it so far, too. See >> http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership >> for details. Please comment. > "at least three maintainers" looks like an awful lot in case of simple > packages. I know it's hard to define "simple", but still... Remember, that sentence starts with "should" -- there is no must there, so its okay if there are simple packages that have only two maintainers. But if there is someone else that is interested in becoming a co-maintainer then he should be accepted normally. > "Maintainers should work towards getting at least one co-maintainer." > I don't like this too much. [...] The reasons why I put that there -- co-maintainership is there for a long time already, but not much used yet, and FESCo wanted to encourage it more. And, btw, you missed to quote the second part of that para: [...]The goal is to have that process mostly automated -- e.g. let a script parse the owner informations and send out mail list now and then that contains a list of the packages that do not have enough co-maintainers yet.[...] CU thl From j.w.r.degoede at hhs.nl Thu Feb 15 11:21:16 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 15 Feb 2007 12:21:16 +0100 Subject: Updates co-maintainership proposal In-Reply-To: <20070215092248.GA2797@free.fr> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> <20070215092248.GA2797@free.fr> Message-ID: <45D4422C.7050905@hhs.nl> On Thu, Feb 15, 2007 at 06:59:24AM +0100, Thorsten Leemhuis wrote: > FYI, I reworked the last proposal and some FESCo members looked over it > and seemed to agree with it so far, too. See > http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership > for details. Please comment. > I stil see little of any value in this piece of prosa. Isn't FESCo's job to make procedures and guidelines to govern the project? Not write opinion articles for fwn? Don't get me wrong co-maintainership can be a good thing, and we might need some infrastructure to facilitate this. What we do not need is a bunch of useless rules dictating people to search for co-maintainers. I maintain a 100+ packages and would love to have one or more CAPABLE co-maintainers, but in my experience a lot of FE contributers have pretty sub standard (my standard that is) packaging skills and allowing them to modify my packages will only create more work not less. Regards, Hans From gilboad at gmail.com Thu Feb 15 11:56:01 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 15 Feb 2007 13:56:01 +0200 Subject: Make tags fails? Help? Message-ID: <1171540561.9384.7.camel@gilboa-work-dev.localdomain> Hello all, I'm trying to import two new packages into -extras and make tag fails. $ rm -rf gmrun icewm common $ cvs co gmrun icewm cvs checkout: Updating gmrun U gmrun/Makefile U gmrun/import.log U gmrun/pkg.acl cvs checkout: Updating gmrun/FC-5 U gmrun/FC-5/.cvsignore U gmrun/FC-5/Makefile U gmrun/FC-5/branch U gmrun/FC-5/sources cvs checkout: Updating gmrun/FC-6 U gmrun/FC-6/.cvsignore U gmrun/FC-6/Makefile U gmrun/FC-6/branch U gmrun/FC-6/sources cvs checkout: Updating gmrun/devel U gmrun/devel/.cvsignore U gmrun/devel/Makefile U gmrun/devel/gmrun-gmrunrc.patch U gmrun/devel/gmrun.spec U gmrun/devel/sources cvs checkout: Updating common U common/Makefile U common/Makefile.common U common/branches U common/cvs-import.sh cvs checkout: Updating icewm U icewm/Makefile U icewm/import.log U icewm/pkg.acl cvs checkout: Updating icewm/FC-5 U icewm/FC-5/.cvsignore U icewm/FC-5/Makefile U icewm/FC-5/branch U icewm/FC-5/sources cvs checkout: Updating icewm/FC-6 U icewm/FC-6/.cvsignore U icewm/FC-6/Makefile U icewm/FC-6/branch U icewm/FC-6/sources cvs checkout: Updating icewm/devel U icewm/devel/.cvsignore U icewm/devel/Makefile U icewm/devel/icewm-configure.patch U icewm/devel/icewm-keys.patch U icewm/devel/icewm-menu.patch U icewm/devel/icewm-startup U icewm/devel/icewm-toolbar.patch U icewm/devel/icewm-xdg-menu U icewm/devel/icewm.desktop U icewm/devel/icewm.spec U icewm/devel/sources cvs checkout: Updating common U common/Makefile U common/Makefile.common U common/branches U common/cvs-import.sh $ cd icewm/devel/ $ make tag cvs tag -c icewm-1_2_30-12_fc7 cvs [server aborted]: "tag" requires write access to the repository make: *** [tag] Error 1 ACL problems? - Gilboa From buildsys at fedoraproject.org Thu Feb 15 12:35:28 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 15 Feb 2007 07:35:28 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-02-15 Message-ID: <20070215123528.52B7D15212E@buildsys.fedoraproject.org> Jochen AT herr-schmitt.de: gnu-smalltalk FE5 > FE6 (0:2.3.3-2.fc5 > 0:2.3.2-4.fc6) UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) libxslt FC6-updates > FC7 (0:1.1.20-1.fc6 > 0:1.1.20-1) 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) sound-juicer FC6-updates > FC7 (0:2.16.3-1.fc6 > 0:2.16.2-3.fc7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) cgoorah AT yahoo.com.au: kdmtheme FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) 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) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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: 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) 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 FE5 > FE7 (0:1.4.5-3.fc5 > 0:1.4.5-1.fc7) FE6 > FE7 (0:1.4.5-3.fc6 > 0:1.4.5-1.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) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) lists AT forevermore.net: yafc FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.fc6) mdehaan AT redhat.com: cobbler FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.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 linux.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) tagoh AT redhat.com: mew FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) 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) ---------------------------------------------------------------------- amarok: gauret AT free.fr FE5 > FE7 (0:1.4.5-3.fc5 > 0:1.4.5-1.fc7) FE6 > FE7 (0:1.4.5-3.fc6 > 0:1.4.5-1.fc7) boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE6 (0:0.3.9-2.fc5 > 0:0.3.9-1.fc6) 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) 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) 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) gnu-smalltalk: Jochen AT herr-schmitt.de FE5 > FE6 (0:2.3.3-2.fc5 > 0:2.3.2-4.fc6) gnubg: limb AT jcomserv.net FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.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) kdmtheme: cgoorah AT yahoo.com.au FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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) mew: tagoh AT redhat.com FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) 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 linux.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) sound-juicer: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.16.3-1.fc6 > 0:2.16.2-3.fc7) 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) 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) yafc: lists AT forevermore.net FE6 > FE7 (0:1.1.1-6.fc6 > 0:1.1.1-5.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 gilboad at gmail.com Thu Feb 15 13:38:25 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 15 Feb 2007 15:38:25 +0200 Subject: Make tags fails? Help? In-Reply-To: <1171540561.9384.7.camel@gilboa-work-dev.localdomain> References: <1171540561.9384.7.camel@gilboa-work-dev.localdomain> Message-ID: <1171546705.9384.23.camel@gilboa-work-dev.localdomain> On Thu, 2007-02-15 at 13:56 +0200, Gilboa Davara wrote: > Hello all, > > I'm trying to import two new packages into -extras and make tag fails. Oops. Please ignore. Resending to -extras. - Gilboa From jkeating at redhat.com Thu Feb 15 13:47:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Feb 2007 08:47:37 -0500 Subject: Make tags fails? Help? In-Reply-To: <1171546705.9384.23.camel@gilboa-work-dev.localdomain> References: <1171540561.9384.7.camel@gilboa-work-dev.localdomain> <1171546705.9384.23.camel@gilboa-work-dev.localdomain> Message-ID: <200702150847.37913.jkeating@redhat.com> On Thursday 15 February 2007 08:38, Gilboa Davara wrote: > Oops. > Please ignore. > Resending to -extras. Why? This list is for all Fedora maintainers, both Core and Extras (and soon just Fedora). -- 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 laroche at redhat.com Thu Feb 15 14:27:46 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 15 Feb 2007 15:27:46 +0100 Subject: non-working Fedora mirrors Message-ID: <20070215142746.GA26186@dudweiler.stuttgart.redhat.com> Hello Matt, here a list of mirrors which fail to work today. Some might be temporarily, but many others could be removed from the lists on http://fedora.redhat.com/Download/mirrors/. http://fedora.server4you.net/ is probably an internal host only and not public. regards, Florian La Roche --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/fedora-core-5. Reading yum repository ftp://redhat.taygeta.com/pub/RedHat/fedora/core/5/i386/os/. cacheLocal: looking at url: ftp://redhat.taygeta.com/pub/RedHat/fedora/core/5/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 os: No such file or directory failed Reading yum repository ftp://ftp.net.usf.edu/pub/fedora/linux/core/5/i386/os/. cacheLocal: looking at url: ftp://ftp.net.usf.edu/pub/fedora/linux/core/5/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 5: No such file or directory failed Reading yum repository http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/5/i386/os/. cacheLocal: looking at url: http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/5/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository http://fedora.server4you.net/fedora/core/5/i386/os/. cacheLocal: looking at url: http://fedora.server4you.net/fedora/core/5/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 12] Timeout: failed Reading yum repository ftp://ftp.ciril.fr/pub/linux/fedora/linux/core/5/i386/os/. cacheLocal: looking at url: ftp://ftp.ciril.fr/pub/linux/fedora/linux/core/5/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 5: No such file or directory failed Reading yum repository ftp://mirror.cs.princeton.edu/pub/mirrors/fedora/linux/core/5/i386/os/. cacheLocal: looking at url: ftp://mirror.cs.princeton.edu/pub/mirrors/fedora/linux/core/5/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 421 Sorry, mirror already has 12 users logged on. Try again in 10 minutes. failed Reading yum repository http://less.cogeco.net/pub/fedora/linux/core/5/i386/os/. cacheLocal: looking at url: http://less.cogeco.net/pub/fedora/linux/core/5/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/core/i386/os/. cacheLocal: looking at url: ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/core/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 i386: No such file or directory. failed Reading yum repository ftp://ftp.oss.eznetsols.org/linux/fedora/linux/core/i386/os/. cacheLocal: looking at url: ftp://ftp.oss.eznetsols.org/linux/fedora/linux/core/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 linux: No such file or directory failed Reading yum repository http://distribuciones.telecable.es/fedora/i386/os/. cacheLocal: looking at url: http://distribuciones.telecable.es/fedora/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository ftp://mirror.nyi.net/fedora/5/i386/os/. cacheLocal: looking at url: ftp://mirror.nyi.net/fedora/5/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 Can't change directory to 5: No such file or directory failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/fedora-core-6. Reading yum repository http://fedora.server4you.net/fedora/core/6/i386/os/. cacheLocal: looking at url: http://fedora.server4you.net/fedora/core/6/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 12] Timeout: failed Reading yum repository ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/core/i386/os/. cacheLocal: looking at url: ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/core/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 i386: No such file or directory. failed Reading yum repository ftp://ftp.oss.eznetsols.org/linux/fedora/linux/core/i386/os/. cacheLocal: looking at url: ftp://ftp.oss.eznetsols.org/linux/fedora/linux/core/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 linux: No such file or directory failed Reading yum repository http://distribuciones.telecable.es/fedora/i386/os/. cacheLocal: looking at url: http://distribuciones.telecable.es/fedora/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository http://download.stmc.edu.hk/fedora/linux/core/6/i386/os/. cacheLocal: looking at url: http://download.stmc.edu.hk/fedora/linux/core/6/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 403: Forbidden failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/fedora-core-rawhide. Reading yum repository http://mirror.aarnet.edu.au/pub/fedora/linux/core/development/i386/os/. cacheLocal: looking at url: http://mirror.aarnet.edu.au/pub/fedora/linux/core/development/i386/os/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/fedora-core-rawhide-debug. Reading yum repository http://mirror.aarnet.edu.au/pub/fedora/linux/core/development/i386/debug/. cacheLocal: looking at url: http://mirror.aarnet.edu.au/pub/fedora/linux/core/development/i386/debug/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/fedora-core-rawhide-source. Reading yum repository http://mirror.aarnet.edu.au/pub/fedora/linux/core/development/source/SRPMS/. cacheLocal: looking at url: http://mirror.aarnet.edu.au/pub/fedora/linux/core/development/source/SRPMS/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/updates-released-fc5. Reading yum repository ftp://ftp.rdsor.ro/pub/Linux/Distributions/Fedora/updates/5/i386/. cacheLocal: looking at url: ftp://ftp.rdsor.ro/pub/Linux/Distributions/Fedora/updates/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 5: No such file or directory failed Reading yum repository ftp://ftp.tecnoera.com/pub/fedora/linux/updates/5/i386/. cacheLocal: looking at url: ftp://ftp.tecnoera.com/pub/fedora/linux/updates/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] timed out failed Reading yum repository http://fedora.server4you.net/fedora/core/updates/5/i386/. cacheLocal: looking at url: http://fedora.server4you.net/fedora/core/updates/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 12] Timeout: failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/updates-released-fc6. Reading yum repository http://fedora.server4you.net/fedora/core/updates/6/i386/. cacheLocal: looking at url: http://fedora.server4you.net/fedora/core/updates/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 12] Timeout: failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/updates-testing-fc5. Reading yum repository http://less.cogeco.net/pub/fedora/linux/core/updates/testing/5/i386/. cacheLocal: looking at url: http://less.cogeco.net/pub/fedora/linux/core/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository http://ftp1.skynet.cz/pub/linux/fedora/updates/testing/5/i386/. cacheLocal: looking at url: http://ftp1.skynet.cz/pub/linux/fedora/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository ftp://falkor.skane.se/pub/mirrors/fedora/updates/testing/5/i386/. cacheLocal: looking at url: ftp://falkor.skane.se/pub/mirrors/fedora/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 testing: No such file or directory failed Reading yum repository ftp://ftp.quicknet.nl/pub/Linux/download.fedora.redhat.com/updates/testing/5/i386/. cacheLocal: looking at url: ftp://ftp.quicknet.nl/pub/Linux/download.fedora.redhat.com/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 No such directory. failed Reading yum repository ftp://ftp.wsisiz.edu.pl/pub/linux/fedora/linux/core/updates/testing/5. cacheLocal: looking at url: ftp://ftp.wsisiz.edu.pl/pub/linux/fedora/linux/core/updates/testing/5/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. failed Reading yum repository ftp://ftp.wicks.co.nz/pub/linux/dist/fedora/updates/testing/5/i386/. cacheLocal: looking at url: ftp://ftp.wicks.co.nz/pub/linux/dist/fedora/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. failed Reading yum repository ftp://ftp.rdsor.ro/pub/Linux/Distributions/Fedora/updates/testing/5/i386/. cacheLocal: looking at url: ftp://ftp.rdsor.ro/pub/Linux/Distributions/Fedora/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 testing: No such file or directory failed Reading yum repository http://ftp.stw-bonn.de/pub/fedora/linux/core/updates/testing/5/i386/. cacheLocal: looking at url: http://ftp.stw-bonn.de/pub/fedora/linux/core/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository ftp://ftp.dc.aleron.net/pub/linux/fedora/linux/core/updates/testing/5/i386/. cacheLocal: looking at url: ftp://ftp.dc.aleron.net/pub/linux/fedora/linux/core/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. failed Reading yum repository http://ftp.ale.org/mirrors/fedora/linux/core/updates/testing/5/i386/. cacheLocal: looking at url: http://ftp.ale.org/mirrors/fedora/linux/core/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository ftp://ftp.tecnoera.com/pub/fedora/linux/updates/testing/5/i386/. cacheLocal: looking at url: ftp://ftp.tecnoera.com/pub/fedora/linux/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] timed out failed Reading yum repository ftp://mirror.newnanutilities.org/pub/fedora/linux/core/updates/testing/5/i386/. cacheLocal: looking at url: ftp://mirror.newnanutilities.org/pub/fedora/linux/core/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. failed Reading yum repository http://fedora.server4you.net/fedora/core/updates/testing/5/i386/. cacheLocal: looking at url: http://fedora.server4you.net/fedora/core/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 12] Timeout: failed Reading yum repository http://ftp.gui.uva.es/sites/fedora.redhat.com/updates/testing/5/i386/. cacheLocal: looking at url: http://ftp.gui.uva.es/sites/fedora.redhat.com/updates/testing/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/updates-testing-source-fc5. Reading yum repository http://ftp.gui.uva.es/sites/fedora.redhat.com/updates/testing/5/SRPMS/. cacheLocal: looking at url: http://ftp.gui.uva.es/sites/fedora.redhat.com/updates/testing/5/SRPMS/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/updates-testing-fc6. Reading yum repository http://less.cogeco.net/pub/fedora/linux/core/updates/testing/6/i386/. cacheLocal: looking at url: http://less.cogeco.net/pub/fedora/linux/core/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository http://ftp1.skynet.cz/pub/linux/fedora/updates/testing/6/i386/. cacheLocal: looking at url: http://ftp1.skynet.cz/pub/linux/fedora/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository ftp://falkor.skane.se/pub/mirrors/fedora/updates/testing/6/i386/. cacheLocal: looking at url: ftp://falkor.skane.se/pub/mirrors/fedora/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 testing: No such file or directory failed Reading yum repository ftp://ftp.quicknet.nl/pub/Linux/download.fedora.redhat.com/updates/testing/6/i386/. cacheLocal: looking at url: ftp://ftp.quicknet.nl/pub/Linux/download.fedora.redhat.com/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 No such directory. failed Reading yum repository ftp://ftp.wsisiz.edu.pl/pub/linux/fedora/linux/core/updates/testing/5. cacheLocal: looking at url: ftp://ftp.wsisiz.edu.pl/pub/linux/fedora/linux/core/updates/testing/5/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. failed Reading yum repository ftp://ftp.wicks.co.nz/pub/linux/dist/fedora/updates/testing/6/i386/. cacheLocal: looking at url: ftp://ftp.wicks.co.nz/pub/linux/dist/fedora/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. failed Reading yum repository ftp://ftp.rdsor.ro/pub/Linux/Distributions/Fedora/updates/testing/6/i386/. cacheLocal: looking at url: ftp://ftp.rdsor.ro/pub/Linux/Distributions/Fedora/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 testing: No such file or directory failed Reading yum repository http://ftp.stw-bonn.de/pub/fedora/linux/core/updates/testing/6/i386/. cacheLocal: looking at url: http://ftp.stw-bonn.de/pub/fedora/linux/core/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository ftp://ftp.dc.aleron.net/pub/linux/fedora/linux/core/updates/testing/6/i386/. cacheLocal: looking at url: ftp://ftp.dc.aleron.net/pub/linux/fedora/linux/core/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. failed Reading yum repository http://ftp.ale.org/mirrors/fedora/linux/core/updates/testing/6/i386/. cacheLocal: looking at url: http://ftp.ale.org/mirrors/fedora/linux/core/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository ftp://ftp.tecnoera.com/pub/fedora/linux/updates/testing/6/i386/. cacheLocal: looking at url: ftp://ftp.tecnoera.com/pub/fedora/linux/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] timed out failed Reading yum repository ftp://mirror.newnanutilities.org/pub/fedora/linux/core/updates/testing/6/i386/. cacheLocal: looking at url: ftp://mirror.newnanutilities.org/pub/fedora/linux/core/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 Failed to change directory. failed Reading yum repository http://fedora.server4you.net/fedora/core/updates/testing/6/i386/. cacheLocal: looking at url: http://fedora.server4you.net/fedora/core/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 12] Timeout: failed Reading yum repository http://ftp.gui.uva.es/sites/fedora.redhat.com/updates/testing/6/i386/. cacheLocal: looking at url: http://ftp.gui.uva.es/sites/fedora.redhat.com/updates/testing/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/updates-testing-source-fc6. Reading yum repository http://ftp.gui.uva.es/sites/fedora.redhat.com/updates/testing/6/SRPMS/. cacheLocal: looking at url: http://ftp.gui.uva.es/sites/fedora.redhat.com/updates/testing/6/SRPMS/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/fedora-extras-5. Reading yum repository http://mirror.clarkson.edu/pub/distributions/fedora/linux/extras/5/i386/. cacheLocal: looking at url: http://mirror.clarkson.edu/pub/distributions/fedora/linux/extras/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository http://fedora.server4you.net/fedora/extras/5/i386/. cacheLocal: looking at url: http://fedora.server4you.net/fedora/extras/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 12] Timeout: failed Reading yum repository ftp://ftp.tecnoera.com/pub/fedora/linux/extras/5/i386/. cacheLocal: looking at url: ftp://ftp.tecnoera.com/pub/fedora/linux/extras/5/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] timed out failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/fedora-extras-6. Reading yum repository http://mirror.clarkson.edu/pub/distributions/fedora/linux/extras/6/i386/. cacheLocal: looking at url: http://mirror.clarkson.edu/pub/distributions/fedora/linux/extras/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 14] HTTP Error 404: Not Found failed Reading yum repository http://fedora.server4you.net/fedora/extras/6/i386/. cacheLocal: looking at url: http://fedora.server4you.net/fedora/extras/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 12] Timeout: failed Reading yum repository ftp://ftp.tecnoera.com/pub/fedora/linux/extras/6/i386/. cacheLocal: looking at url: ftp://ftp.tecnoera.com/pub/fedora/linux/extras/6/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 extras: No such file or directory failed --------------------------------------- Getting mirrorlist from http://fedora.redhat.com/Download/mirrors/fedora-extras-devel. Reading yum repository http://gd.tuwien.ac.at/opsys/linux/fedora/extras/development/i386/. cacheLocal: looking at url: http://gd.tuwien.ac.at/opsys/linux/fedora/extras/development/i386/repodata/repomd.xml failed Reading yum repository http://fedora.server4you.net/fedora/extras/development/i386/. cacheLocal: looking at url: http://fedora.server4you.net/fedora/extras/development/i386/repodata/repomd.xml cacheLocal: error: e: [Errno 12] Timeout: failed From Matt_Domsch at dell.com Thu Feb 15 15:10:05 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 15 Feb 2007 09:10:05 -0600 Subject: non-working Fedora mirrors In-Reply-To: <20070215142746.GA26186@dudweiler.stuttgart.redhat.com> References: <20070215142746.GA26186@dudweiler.stuttgart.redhat.com> Message-ID: <20070215151005.GA2644@lists.us.dell.com> On Thu, Feb 15, 2007 at 03:27:46PM +0100, Florian La Roche wrote: > Hello Matt, > > here a list of mirrors which fail to work today. Some might be temporarily, > but many others could be removed from the lists on > http://fedora.redhat.com/Download/mirrors/. Yes. Honestly, it's part of the big mirror management redo I've been working on, code at https://hosted.fedoraproject.org/projects/mirrormanager and an overview of the process at http://fedoraproject.org/wiki/Infrastructure/Mirroring. Manually fixing all the existing text lists is terribly time-consuming, so instead, I spent way too much time writing code to do it automagically. :-) With a few more tweaks, it'll be ready for testing use in parallel with the Test2 release I hope, we'll put it to torture test with Test3, and then the F7 release should go smoothly. When we're confident it's working, we'll switch the methods for the existing releases to use this new database too. Thanks, Matt From Christian.Iseli at licr.org Thu Feb 15 16:03:37 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 15 Feb 2007 17:03:37 +0100 Subject: Make tags fails? Help? In-Reply-To: <1171540561.9384.7.camel@gilboa-work-dev.localdomain> References: <1171540561.9384.7.camel@gilboa-work-dev.localdomain> Message-ID: <20070215170337.7da57503@ludwig-alpha.unil.ch> On Thu, 15 Feb 2007 13:56:01 +0200, Gilboa Davara wrote: > ACL problems? You sure you didn't check them out anonymously ? From dakingun at gmail.com Thu Feb 15 16:54:21 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Thu, 15 Feb 2007 11:54:21 -0500 Subject: non-working Fedora mirrors In-Reply-To: <20070215142746.GA26186@dudweiler.stuttgart.redhat.com> References: <20070215142746.GA26186@dudweiler.stuttgart.redhat.com> Message-ID: On 2/15/07, Florian La Roche wrote: > Hello Matt, > > here a list of mirrors which fail to work today. Some might be temporarily, > but many others could be removed from the lists on > http://fedora.redhat.com/Download/mirrors/. > ... > Reading yum repository ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/core/i386/os/. > cacheLocal: looking at url: ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/core/i386/os/repodata/repomd.xml > cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 i386: No such file or directory. > failed This mirror exists and does work. I don't know how you perform your query, but there's a typo in the url you queried. Deji From notting at redhat.com Thu Feb 15 16:52:40 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Feb 2007 11:52:40 -0500 Subject: Updates co-maintainership proposal (was: Re: Plan for tomorrows (20070215) FESCO meeting) In-Reply-To: <45D3F6BC.3040202@leemhuis.info> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> Message-ID: <20070215165240.GB11994@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > On 14.02.2007 23:06, Brian Pepple wrote: > >/topic FESCO-Meeting -- Encourage co-maintainership -- all, thl > > FYI, I reworked the last proposal and some FESCo members looked over it > and seemed to agree with it so far, too. See > http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership > for details. Please comment. Too long. I'd argue that any proposal that needs a *digest* is too long by definition. It's longer than the packaging guidelines! Moreover, we *already* have co-maintainership - we have co-maintainers, we have upstream CC'd on bugs, we have commits going to all with access; I'm not sure we need 4 pages describing what we already have. Bill From notting at redhat.com Thu Feb 15 19:28:24 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Feb 2007 14:28:24 -0500 Subject: changing the format of owners.list Message-ID: <20070215192824.GA14557@nostromo.devel.redhat.com> To better enable co-maintainership, the format of owners.list is going to change slightly on Monday, February 18th, at 3PM EST (2000 UTC), give or take a few minutes. The change is that the 'initialowner' field will now be a comma-separated list of maintainers. The first e-mail address listed will be the 'primary' maintainer listed as the owner in bugzilla; all other address will be co-maintainers. Hence, if you currently have co-maintainers listed in initialcclist, you'll want them moved to the owner field. Feel free to notify cvsadmin-members at fedoraproject.org, or set the review bug to fedora-cvs? in bugzilla, and we'll get this taken care of. Bill From wtogami at redhat.com Thu Feb 15 20:56:48 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 15 Feb 2007 15:56:48 -0500 Subject: CVS Flags: Clarifying flag statuses Message-ID: <45D4C910.1030103@redhat.com> FESCO voted to ratify the fedora-cvs procedure which gets rid of the CVSSyncNeeded and Wiki from the package process, which is good. Before we do this however, I hope to brainstorm about what the flag statuses mean. fedora-cvs BLANK Default status, means nothing. fedora-cvs ? I want CVS admin attention to deal with the request that I wrote in a Bugzilla comment, preferably at the same time fedora-cvs was set to ?. The states that are unclear are... fedora-cvs - fedora-cvs + notting brought up the good point that setting + at least sends an informative e-mail indicating that a request was done, so the reviewer/owner knows to go ahead with importing and building. Aside from this however, is there any value to +? Should - be used at all? Perhaps in addition to writing a comment like, "You did not provide enough information to do this CVS request." Or "Your request was bad for some reason, like changing owner for a package that you clearly do not own and I don't see permission from the owner or a FESCO decision." Any opinions? Is this too confusing? If not I will just go ahead with the above ideas and update documentation where needed. Warren Togami wtogami at redhat.com From limb at jcomserv.net Thu Feb 15 21:01:36 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 15 Feb 2007 15:01:36 -0600 (CST) Subject: CVS Flags: Clarifying flag statuses In-Reply-To: <45D4C910.1030103@redhat.com> References: <45D4C910.1030103@redhat.com> Message-ID: <19540.65.192.24.190.1171573296.squirrel@mail.jcomserv.net> > fedora-cvs BLANK > Default status, means nothing. +1 > fedora-cvs ? > I want CVS admin attention to deal with the request that I wrote in a > Bugzilla comment, preferably at the same time fedora-cvs was set to ?. +1 > The states that are unclear are... > > fedora-cvs - > fedora-cvs + > notting brought up the good point that setting + at least sends an > informative e-mail indicating that a request was done, so the > reviewer/owner knows to go ahead with importing and building. Aside > from this however, is there any value to +? > > Should - be used at all? > > Perhaps in addition to writing a comment like, "You did not provide > enough information to do this CVS request." Or "Your request was bad > for some reason, like changing owner for a package that you clearly do > not own and I don't see permission from the owner or a FESCO decision." > Deprecate - and have + be set by the CVS admin. I think that'd be my preference. +$0.02. Jon -- novus ordo absurdum From jwboyer at jdub.homelinux.org Thu Feb 15 22:18:44 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 15 Feb 2007 16:18:44 -0600 Subject: changing the format of owners.list In-Reply-To: <20070215192824.GA14557@nostromo.devel.redhat.com> References: <20070215192824.GA14557@nostromo.devel.redhat.com> Message-ID: <1171577924.4003.160.camel@zod.rchland.ibm.com> On Thu, 2007-02-15 at 14:28 -0500, Bill Nottingham wrote: > To better enable co-maintainership, the format of owners.list is going > to change slightly on Monday, February 18th, at 3PM EST (2000 UTC), give > or take a few minutes. > > The change is that the 'initialowner' field will now be a comma-separated > list of maintainers. The first e-mail address listed will be the 'primary' > maintainer listed as the owner in bugzilla; all other address will be > co-maintainers. > > Hence, if you currently have co-maintainers listed in initialcclist, > you'll want them moved to the owner field. Feel free to notify > cvsadmin-members at fedoraproject.org, or set the review bug to fedora-cvs? > in bugzilla, and we'll get this taken care of. And all of this is going to magically work with the ACL system recently put in place? As in, for new packages both maintainers will have commit access, etc? I'm assuming it's not going to break ACLs for current packages, but I'm curious about new ones. josh From wtogami at redhat.com Thu Feb 15 22:49:41 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 15 Feb 2007 17:49:41 -0500 Subject: changing the format of owners.list In-Reply-To: <1171577924.4003.160.camel@zod.rchland.ibm.com> References: <20070215192824.GA14557@nostromo.devel.redhat.com> <1171577924.4003.160.camel@zod.rchland.ibm.com> Message-ID: <45D4E385.1010902@redhat.com> Josh Boyer wrote: >> Hence, if you currently have co-maintainers listed in initialcclist, >> you'll want them moved to the owner field. Feel free to notify >> cvsadmin-members at fedoraproject.org, or set the review bug to fedora-cvs? >> in bugzilla, and we'll get this taken care of. > > And all of this is going to magically work with the ACL system recently > put in place? As in, for new packages both maintainers will have commit > access, etc? > > I'm assuming it's not going to break ACLs for current packages, but I'm > curious about new ones. > I don't know if this decision was changed since it was made, but as I understand it... - Old packages have no pkg.acl file by default. - New packages have a blank pkg.acl file by default, meaning only owners may make changes in that package. - owners.list listing multiple owners has a dual purpose: Who to allow to checkin when a pkg.acl exists, but also who is allowed to modify pkg.acl. Warren Togami wtogami at redhat.com From gilboad at gmail.com Fri Feb 16 00:03:41 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 16 Feb 2007 02:03:41 +0200 Subject: Make tags fails? Help? In-Reply-To: <200702150847.37913.jkeating@redhat.com> References: <1171540561.9384.7.camel@gilboa-work-dev.localdomain> <1171546705.9384.23.camel@gilboa-work-dev.localdomain> <200702150847.37913.jkeating@redhat.com> Message-ID: <1171584221.3377.36.camel@gilboa-home-dev.localdomain> On Thu, 2007-02-15 at 08:47 -0500, Jesse Keating wrote: > On Thursday 15 February 2007 08:38, Gilboa Davara wrote: > > Oops. > > Please ignore. > > Resending to -extras. > > Why? This list is for all Fedora maintainers, both Core and Extras (and soon > just Fedora). > Oh... OK, my mistake. Please ignore my last statement. Thanks, - Gilboa From gilboad at gmail.com Fri Feb 16 00:14:24 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 16 Feb 2007 02:14:24 +0200 Subject: Make tags fails? Help? In-Reply-To: <20070215170337.7da57503@ludwig-alpha.unil.ch> References: <1171540561.9384.7.camel@gilboa-work-dev.localdomain> <20070215170337.7da57503@ludwig-alpha.unil.ch> Message-ID: <1171584864.3377.39.camel@gilboa-home-dev.localdomain> On Thu, 2007-02-15 at 17:03 +0100, Christian Iseli wrote: > On Thu, 15 Feb 2007 13:56:01 +0200, Gilboa Davara wrote: > > ACL problems? > > You sure you didn't check them out anonymously ? Ouch! My mistake. (Broken .bashrc CVSROOT string) - Thanks! - Gilboa From Christian.Iseli at licr.org Fri Feb 16 10:38:44 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 16 Feb 2007 11:38:44 +0100 Subject: Flags column in bugzilla bug list Message-ID: <20070216113844.5b58f134@ludwig-alpha.unil.ch> Dear all, Now that flags play an increasing role in our processes, would it be possible to have them listed in the column view of bug lists ? In other words: could someone add one more column choice in the "Change Columns" part of bugzilla ? I think it would greatly improve the usefulness of package review bug lists, to be able to see which ones are in which state. A comma separated list of all the set flags would be fine. Cheers, Christian From notting at redhat.com Fri Feb 16 18:52:41 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 16 Feb 2007 13:52:41 -0500 Subject: changing the format of owners.list In-Reply-To: <1171577924.4003.160.camel@zod.rchland.ibm.com> References: <20070215192824.GA14557@nostromo.devel.redhat.com> <1171577924.4003.160.camel@zod.rchland.ibm.com> Message-ID: <20070216185241.GH30687@nostromo.devel.redhat.com> Josh Boyer (jwboyer at jdub.homelinux.org) said: > And all of this is going to magically work with the ACL system recently > put in place? As in, for new packages both maintainers will have commit > access, etc? Yeah, this was coded into the ACL system to allow for this. Bill From jwboyer at jdub.homelinux.org Fri Feb 16 19:26:14 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 16 Feb 2007 13:26:14 -0600 Subject: changing the format of owners.list In-Reply-To: <20070216185241.GH30687@nostromo.devel.redhat.com> References: <20070215192824.GA14557@nostromo.devel.redhat.com> <1171577924.4003.160.camel@zod.rchland.ibm.com> <20070216185241.GH30687@nostromo.devel.redhat.com> Message-ID: <1171653974.4003.211.camel@zod.rchland.ibm.com> On Fri, 2007-02-16 at 13:52 -0500, Bill Nottingham wrote: > Josh Boyer (jwboyer at jdub.homelinux.org) said: > > And all of this is going to magically work with the ACL system recently > > put in place? As in, for new packages both maintainers will have commit > > access, etc? > > Yeah, this was coded into the ACL system to allow for this. Great to hear. josh From jkeating at redhat.com Fri Feb 16 21:08:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Feb 2007 16:08:05 -0500 Subject: Announcing a change in the Fedora 7 schedule Message-ID: <200702161608.14572.jkeating@redhat.com> One of the big Features of Fedora 7 is a merged core and extras. In order to accomplish this, we need some improvements to the buildsystem currently used by Fedora Extras. We need these improvements done or mostly done by the Feature Freeze of Fedora 7, which was originally set to be the 20th of February, 4 days from now. It is very clear that these changes will not be ready by then. To accomplish these changes (and others) in time for the Feature Freeze, we have added another month to the schedule, introducing a Test 4, and moving the Feature Freeze as well as String Freeze up to Test 3 freeze, March 19. This moves the general availability date from April 26 to May 24. For further discussion on this topic, please use the fedora-maintainers list, which I am attempting to set reply-to. For reference: http://fedoraproject.org/wiki/Releases/7/Schedule -- 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 Gateway at redhat.com Fri Feb 16 21:08:35 2007 From: Gateway at redhat.com (Gateway at redhat.com) Date: Fri, 16 Feb 2007 22:08:35 +0100 Subject: NDN: Announcing a change in the Fedora 7 schedule Message-ID: Sorry. Your message could not be delivered to: christian paratschek,reflex.at (The name was not found at the remote site. Check that the name has been entered correctly.) From eric.tanguy at univ-nantes.fr Fri Feb 16 22:11:36 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Fri, 16 Feb 2007 23:11:36 +0100 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <200702161608.14572.jkeating@redhat.com> References: <200702161608.14572.jkeating@redhat.com> Message-ID: <1171663896.5985.0.camel@bureau.maison> Le vendredi 16 f?vrier 2007 ? 16:08 -0500, Jesse Keating a ?crit : > One of the big Features of Fedora 7 is a merged core and extras. In order to > accomplish this, we need some improvements to the buildsystem currently used > by Fedora Extras. We need these improvements done or mostly done by the > Feature Freeze of Fedora 7, which was originally set to be the 20th of > February, 4 days from now. It is very clear that these changes will not be > ready by then. > > To accomplish these changes (and others) in time for the Feature Freeze, we > have added another month to the schedule, introducing a Test 4, and moving > the Feature Freeze as well as String Freeze up to Test 3 freeze, March 19. > > This moves the general availability date from April 26 to May 24. > > For further discussion on this topic, please use the fedora-maintainers list, > which I am attempting to set reply-to. > > For reference: http://fedoraproject.org/wiki/Releases/7/Schedule > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers With this schedule modification, will this release include firefox3 and Xorg 7.3 ? Thanks Eric From jkeating at redhat.com Fri Feb 16 22:19:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Feb 2007 17:19:33 -0500 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <1171663896.5985.0.camel@bureau.maison> References: <200702161608.14572.jkeating@redhat.com> <1171663896.5985.0.camel@bureau.maison> Message-ID: <200702161719.33085.jkeating@redhat.com> On Friday 16 February 2007 17:11, Tanguy Eric wrote: > With this schedule modification, will this release include firefox3 and > Xorg 7.3 ? To be honest? I don't know. Various teams will most likely need to re-evaluate what is possible with the extra month of development time. Since they are learning about it at the same time you are, they will probably need some time to digest and react. -- 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 Fri Feb 16 22:28:49 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 16 Feb 2007 16:28:49 -0600 Subject: Updates co-maintainership proposal In-Reply-To: <45D4422C.7050905@hhs.nl> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> <20070215092248.GA2797@free.fr> <45D4422C.7050905@hhs.nl> Message-ID: <1171664929.30902.0.camel@localhost.localdomain> On Thu, 2007-02-15 at 12:21 +0100, Hans de Goede wrote: > I maintain a 100+ packages and would love to have one or more CAPABLE > co-maintainers, but in my experience a lot of FE contributers have > pretty sub standard (my standard that is) packaging skills and allowing > them to modify my packages will only create more work not less. We are truly fortunate to have you in the community. -------------- 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 Fri Feb 16 23:09:22 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 16 Feb 2007 18:09:22 -0500 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <200702161719.33085.jkeating@redhat.com> References: <200702161608.14572.jkeating@redhat.com> <1171663896.5985.0.camel@bureau.maison> <200702161719.33085.jkeating@redhat.com> Message-ID: <1171667362.22219.71.camel@localhost.localdomain> On Fri, 2007-02-16 at 17:19 -0500, Jesse Keating wrote: > On Friday 16 February 2007 17:11, Tanguy Eric wrote: > > With this schedule modification, will this release include firefox3 and > > Xorg 7.3 ? > > To be honest? I don't know. Various teams will most likely need to > re-evaluate what is possible with the extra month of development time. Since > they are learning about it at the same time you are, they will probably need > some time to digest and react. Firefox3 is too far out to consider. --Chris From laroche at redhat.com Fri Feb 16 23:25:00 2007 From: laroche at redhat.com (Florian La Roche) Date: Sat, 17 Feb 2007 00:25:00 +0100 Subject: non-working Fedora mirrors In-Reply-To: References: <20070215142746.GA26186@dudweiler.stuttgart.redhat.com> Message-ID: <20070216232500.GA9630@dudweiler.stuttgart.redhat.com> On Thu, Feb 15, 2007 at 11:54:21AM -0500, Deji Akingunola wrote: > On 2/15/07, Florian La Roche wrote: > >Hello Matt, > > > >here a list of mirrors which fail to work today. Some might be temporarily, > >but many others could be removed from the lists on > >http://fedora.redhat.com/Download/mirrors/. > > > ... > >Reading yum repository > >ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/core/i386/os/. > >cacheLocal: looking at url: > >ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/core/i386/os/repodata/repomd.xml > >cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 i386: No > >such file or directory. > >failed > > This mirror exists and does work. I don't know how you perform your > query, but there's a typo in the url you queried. This is then a typo within the mirrorlist on fedoraproject. regards, Florian La Roche From stickster at gmail.com Sat Feb 17 01:01:49 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 16 Feb 2007 20:01:49 -0500 Subject: Docs schedule updated Message-ID: <1171674109.15333.26.camel@localhost.localdomain> I've updated the Docs release schedule in a way I hope is appropriate, given Jesse's recent announcement for the F7 release schedule: http://fedoraproject.org/wiki/DocsProject/Schedule Note that a full set of Release Notes will not be released until test3 now, as opposed to test2. (Both test2 and test3 will continue the "one-sheet" summary used in test1, but with somewhat expanded content each iteration.) However, it is *VERY* important that developers and other contributors remain proactive in populating Release Notes content. That practice allows us to work effectively with the L10N team to provide translations. Please direct replies and discussion to fedora-docs-list (reply-to set FWIW). -- 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 Matt_Domsch at dell.com Sat Feb 17 05:58:00 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 16 Feb 2007 23:58:00 -0600 Subject: non-working Fedora mirrors In-Reply-To: <20070216232500.GA9630@dudweiler.stuttgart.redhat.com> References: <20070215142746.GA26186@dudweiler.stuttgart.redhat.com> <20070216232500.GA9630@dudweiler.stuttgart.redhat.com> Message-ID: <20070217055759.GA6888@lists.us.dell.com> On Sat, Feb 17, 2007 at 12:25:00AM +0100, Florian La Roche wrote: > On Thu, Feb 15, 2007 at 11:54:21AM -0500, Deji Akingunola wrote: > > On 2/15/07, Florian La Roche wrote: > > >Hello Matt, > > > > > >here a list of mirrors which fail to work today. Some might be temporarily, > > >but many others could be removed from the lists on > > >http://fedora.redhat.com/Download/mirrors/. > > > > > ... > > >Reading yum repository > > >ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/core/i386/os/. > > >cacheLocal: looking at url: > > >ftp://ftp.nrc.ca/pub/systems/linux/redhat/fedora/linux/core/i386/os/repodata/repomd.xml > > >cacheLocal: error: e: [Errno 4] IOError: [Errno ftp error] 550 i386: No > > >such file or directory. > > >failed > > > > This mirror exists and does work. I don't know how you perform your > > query, but there's a typo in the url you queried. > > > This is then a typo within the mirrorlist on fedoraproject. Indeed, thanks for catching this. I've fixed the mirrorlist in CVS, it should propogate and be checked in the morning. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From laroche at redhat.com Sat Feb 17 07:56:15 2007 From: laroche at redhat.com (Florian La Roche) Date: Sat, 17 Feb 2007 08:56:15 +0100 Subject: non-working Fedora mirrors In-Reply-To: <20070217055759.GA6888@lists.us.dell.com> References: <20070215142746.GA26186@dudweiler.stuttgart.redhat.com> <20070216232500.GA9630@dudweiler.stuttgart.redhat.com> <20070217055759.GA6888@lists.us.dell.com> Message-ID: <20070217075615.GA4194@dudweiler.stuttgart.redhat.com> > Indeed, thanks for catching this. I've fixed the mirrorlist in CVS, > it should propogate and be checked in the morning. Thanks for doing this. A good mirrorlist is very important to keep Fedora running. regards, Florian La Roche From fedora at leemhuis.info Sat Feb 17 13:58:59 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 17 Feb 2007 14:58:59 +0100 Subject: RFC: Updated co-maintainership proposal -- policy part In-Reply-To: <45D3F6BC.3040202@leemhuis.info> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> Message-ID: <45D70A23.9070602@leemhuis.info> Thorsten Leemhuis schrieb: > On 14.02.2007 23:06, Brian Pepple wrote: >> /topic FESCO-Meeting -- Encourage co-maintainership -- all, thl > FYI, I reworked the last proposal and some FESCo members looked over it > and seemed to agree with it so far, too. See > http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership > for details. Please comment. FESCo discussed this in its last meeting and agreed that this is roughly the way forward. So I'd like to put the current proposal up for discussion here so we can shake out the last details now, as that's easier then doing it later (side note: of course everything can later be adjusted if we want or if there is a need to; stuff like this always needs to be adjusted over time in my experience). So here is the policy part of the proposal. I'll send the guidelines in a separate mail. ---- == Policy == All packages in Fedora Extras shall normally be maintained by a group of maintainers. The most important reasons for it: One maintainer can commit fixes like patches or new upstream releases that fix important bugs (for example security data-corruption issues or packaging bugs that confuse the users systems) even when the other maintainer(s) are away from keyboard due to traveling, sleeping or whatever. Maintainers further can help, guide and watch each other, which should lead to a better overall package quality. The goal is to have at least three maintainers per package in total and at least two per supported distribution release. Big and important packages should have more maintainers -- there is no upper limit. There is a primary maintainer who takes care of the package in general; it's his job to approve and find new maintainers and to make sure their efforts get coordinated -- especially between different branches like EPEL and Fedora. Then there is a primary maintainer per distribution release -- that's often the same as the primary maintainer; bugs get assigned to the per distribution maintainer, who is in charge of the package. It does not mean that he has to do all the work, but he has to make sure the work gets done! The maintainers should actively work towards getting at least one co-maintainer and also try to get the seconds one -- for now that means ask around one the mailing list now and then for people that might be interested in the job. The goal is to have that process mostly automated -- e.g. let a script parse the owner informations and send out mail to a mailing list now and then that contains a list of the packages that do not have enough co-maintainers yet. The primary maintainer can not block co-maintainers for distributions he doesn't want to support -- e.g. if he does not want to care about his package in EPEL he has to accept that someone else takes care of it in EPEL. ---- Comments? Cu thl From fedora at leemhuis.info Sat Feb 17 14:01:41 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 17 Feb 2007 15:01:41 +0100 Subject: Updated co-maintainership proposal -- guidelines In-Reply-To: <45D3F6BC.3040202@leemhuis.info> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> Message-ID: <45D70AC5.8090502@leemhuis.info> Thorsten Leemhuis schrieb: > On 14.02.2007 23:06, Brian Pepple wrote: >> /topic FESCO-Meeting -- Encourage co-maintainership -- all, thl > FYI, I reworked the last proposal and some FESCo members looked over it > and seemed to agree with it so far, too. See > http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership > for details. Please comment. As announced in the other mail here are the guidelines up for discussion. ---- == Guidelines == The following sections up until the end of this document describe some guidelines how co-maintainership should be used in practice. Note that this section is entitled "guidelines", and not "rules". In other words: you don't have to follow the guidelines if there is a good reasons to. But please keep in mind that they were carefully written and that some parts of it take the interest of the project as a whole into account, to make sure Fedora stays healthy and grows up -- that might not be obvious on the first sight. Thanks for helping us with it. === How does is it supposed to work in detail === Something like the following points describe the concept roughly: * in most cases the primary maintainer is the primary per-release maintainer for all supported distributions at the same time. There are two co-maintainers, and the three make sure everybody knows the important stuff and they share the load a bit, to make sure everybody knows about the details of a package. * the primary maintainer should normally be the primary per-release maintainer for the Fedora devel branch, as that's the most important one * all the maintainers of a particular package should be co-maintainers or observers (somebody that gets CCed to bugs, get noticed of commits and builds, but normally doesn't do any work) for the Fedora devel branch, as that's where all the fun stuff happens. * the per-release primary maintainer takes care of the a package for that release. He should have at least one co-maintainers for maintaining that package in that relase * bugs get assigned to the primary per-release maintainer; the primary maintainer and the co-maintainer for that release get into the CC list. The per-release maintainer has to make sure the bugs get fixed, but of course some of the other maintainers of that package can do that, too. * all the maintainers should check each others commits for correct- and saneness. * the primary maintainer should make sure important bugfixes get applied to all the supported distributions where it makes sense * for the devel branch: Small changes (for example: package enhancements, bugfixes) and medium sized changes (for example: update from 1.0.1 to 1.0.2) go directly to cvs and get build. If someone feels unsure about a commit he should wait one or two days before actually building or pushing the package out to the repos, as that should give the other maintainers a chance to yell if they see problems. 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; a temporary separate branch in the cvs can be used for this purpose as well as of course e-mail or bugzilla. * for released distributions: Small changes (for example: package enhancements, bugfixes) get go directly to cvs. The other maintainers of that package should have the chance (e.g. a short time period, like two days) where they can commit other enhancements (to save users lots of upgrades) or to discuss the committed change before its actually pushed to the users. With the current (FC7T1) scheme it means: don't build the package immediately, in the future with the new repo push stuff from lmacken it hopefully should be easily possible to define a waiting period in updates-testing before a package gets pushed out to the proper repo. Only the per-distribution maintainer should commit and build medium sized changes, that of course should have seen testing in devel first; co-maintainer of course should have a chance to comment on the commits before the package gets to the repo. Big changes get coordinated. * 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. There is the strong wish to have a group of long-term contributors (say FESCo members, Release-Managers, Sponsors and some other hand-selected people) that get access everywhere to commit package updates easily without asking the maintainers, in case the maintainers are not fixing stuff or if the changes are small and obvious (it's often a lot easier to commit a simple spec files touch than to create a patch, send it to the maintainer or open bugzilla). * the primary maintainer has to approve new co-maintainers. He now and then should search for co-maintainers if there aren't enough. === 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 a file """rules""" in the packages top level directory of the version control system (e.g. packagename/rules). Those rules are optional and should only be set in place if there is a strong need to (we don#t want different rules for each package, as that will result in a major pita). When you do so please keep the goals of the project as a whole in mind -- the Fedora Distribution in a big *community* project and keeping something like that running is not much helped with a "This is my package, I don't want other people touching it" attitude. === Disputes === We had some conflicts in the past between the package maintainers and users or other contributors how to best maintain a package. Similar conflicts will arise if two or more people work together on a package (a: "1+1=2"; b: "no, you're stupid; 1+1=0x0000010"; c: "you are both stupid, 1+1=11"). Most of them will probably be solved without much noise, but some need a bit help. There are no hard rules how those disagreements shall be solved, but here are some suggestions how it could be solved: * if two maintainers are in disagreement over a detail ask the third maintainer * if no consensus can be found ask on the appropriate mailing list * if still no consensus can be found ask a FESCo member 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 AWOL then again a mediator has to be found. FESCo can hand over a package to somebody else if there is a strong need to (packager does not respond/AWOL/is unwilling to find compromisses on issues) if the committee believes that the co-maintainers will do the job better (should not happen often). === Don't (co-)maintain too many packages === There is a lot of work to do in Fedora and we should try to get many contributors into the project as that should help getting the work done, the load shared and Fedora improved. Packaging is currently the most important (maybe even nearly the only) enter path to get involved in the Fedora Distribution as people by doing packaging can show their knowledge and their abilities before they get access to the more serious stuff and respected by the key people. If you showed that ability and gained respect by properly maintaining a lot of packages it might be time to slowly move on to more serious stuff. One needs time for that, and to get that it might be a good idea to hand over some packages to other interested contributors that are still on their way up -- that often can easily be achieved by educating co-maintainers over time and handing over packager to them when they have shown to be doing a good job. That should help new contributors finding their way into the project and growing up. And it should share the load between the different contributors with even could lead to a better overall package quality. All that serves the Project as a whole and improves it. This enter path might to a wide area obsolete the old sponsor process. Even in the linux and open source world the number of software packages that's worth shipping in a repo is finite. We come closer to a point where nearly all of the interesting stuff is packaged, and thus the situations comes up (or properly came up already, but we didn't notice it) that new contributors do not find something they actually use (we don't want new contributors to package stuff they are not interested in, just to get involved) that is not yet packaged. By giving those users a chance to get involved by starting as from a non-official co-maintainer (e.g. a observers that provides patches), over to official co-maintainership to a real primary (per-release) maintainer we give people a chance to become involved without stating with a package that gets reviewed. === 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. Rather they should observe the packages or make sure that the SIG members are co-maintainers everywhere where needed. That -- if properly used -- is nearly the same as having a SIG that co-maintains and avoids that new SIG members suddenly get access to a lot of packages just by joining a SIG. The jobs of the primary maintainer an the primary per-release maintainer are there to make sure that there is someone that actually is responsible -- that quite important, because letting a group of people handle a package could lead to situations where nobody is actually doing the work, because everyone thinks that one of the other maintainers will do the work. 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 or interested users to become co-maintainers. We probably should automatically send out a list of packages with only one or two maintainers now and then, so new contributors that want to get involved more can easily find places where help is needed. Especially packages with large numbers of open bugs will want to find more co-maintainers to try and help solve them. Ask upstream developers to become co-maintainer or a observer of the package -- that could be of benefit for both sides. Having upstream developers as a primary maintainers is often better avoided (but is allowed) -- the goals of upstream and Fedora might be to different sometimes (freezes or Fedora-specific stuff are some reasons, that contributors that maybe don't really use Fedora on their machines are not aware off) which can lead to interest conflicts. === 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. Note: currently owners.list is locked-down so changes need to be requested through the wiki, but once the package database is live this limitation should be removed. * Ideally, all packages should have at least two co-maintainers * make sure the packaging database has everything we need * make sure it is possible that people get access to version control system, but not access to the buildsystem -- new co-maintainers that are not properly sponsert thus can try in cvs, without doing harm ---- Comments? CU thl From stickster at gmail.com Sat Feb 17 15:04:12 2007 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 17 Feb 2007 10:04:12 -0500 Subject: Docs schedule updated In-Reply-To: <1171674109.15333.26.camel@localhost.localdomain> References: <1171674109.15333.26.camel@localhost.localdomain> Message-ID: <1171724652.31794.0.camel@localhost.localdomain> On Fri, 2007-02-16 at 20:01 -0500, Paul W. Frields wrote: > Note that a full set of Release Notes will not be released until test3 > now, as opposed to test2. Excuse the reply to myself; this should read: "Note that a full set of Release Notes will not be released until test4 now, as opposed to test3." -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 eric.tanguy at univ-nantes.fr Sat Feb 17 16:02:41 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sat, 17 Feb 2007 17:02:41 +0100 Subject: Require Message-ID: <1171728161.7756.2.camel@bureau.maison> I would like to know how to know which packages foo require package bar or just a file from it. I explain : i just update a lib and i would like to know which packages will be affected by this and contact the maintainers. Thanks Eric From jkeating at redhat.com Sat Feb 17 16:33:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 17 Feb 2007 11:33:33 -0500 Subject: Require In-Reply-To: <1171728161.7756.2.camel@bureau.maison> References: <1171728161.7756.2.camel@bureau.maison> Message-ID: <200702171133.33807.jkeating@redhat.com> On Saturday 17 February 2007 11:02, Tanguy Eric wrote: > I would like to know how to know which packages foo require package bar > or just a file from it. > I explain : i just update a lib and i would like to know which packages > will be affected by this and contact the maintainers. repoquery is your friend (: -- 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 eric.tanguy at univ-nantes.fr Sat Feb 17 16:55:01 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sat, 17 Feb 2007 17:55:01 +0100 Subject: Require In-Reply-To: <200702171133.33807.jkeating@redhat.com> References: <1171728161.7756.2.camel@bureau.maison> <200702171133.33807.jkeating@redhat.com> Message-ID: <1171731302.7756.5.camel@bureau.maison> Le samedi 17 f?vrier 2007 ? 11:33 -0500, Jesse Keating a ?crit : > On Saturday 17 February 2007 11:02, Tanguy Eric wrote: > > I would like to know how to know which packages foo require package bar > > or just a file from it. > > I explain : i just update a lib and i would like to know which packages > > will be affected by this and contact the maintainers. > > repoquery is your friend (: > Thanks but it's not my friend ... repoquery --alldeps --whatrequires libupnp Traceback (most recent call last): File "/usr/bin/repoquery", line 690, in ? main(sys.argv) File "/usr/bin/repoquery", line 687, in main repoq.runQuery(regexs) File "/usr/bin/repoquery", line 416, in runQuery for p in self.doQuery(oper, prco): print p File "/usr/bin/repoquery", line 421, in doQuery return getattr(self, "fmt_%s" % method)(*args, **kw) File "/usr/bin/repoquery", line 439, in fmt_whatrequires provs.extend(pkg.prco("provides")) File "/usr/bin/repoquery", line 187, in prco rpdict[misc.prco_typle_to_string(rptup)] = None AttributeError: 'module' object has no attribute 'prco_typle_to_string' Eric From michel.salim at gmail.com Sat Feb 17 17:08:17 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 17 Feb 2007 12:08:17 -0500 Subject: FLAC update broke vorbis-tools Message-ID: <883cfe6d0702170908k47634e46w6a964e607d7b098b@mail.gmail.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229124 The V-Day edition of vorbis-tools does not have FLAC playback support. Perhaps when getting it to build against libogg instead of libOggFLAC the linking against libFLAC got clobbered as well? Regards, -- Michel Salim http://hircus.wordpress.com/ From tla at rasmil.dk Sat Feb 17 17:30:39 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Sat, 17 Feb 2007 18:30:39 +0100 Subject: Require In-Reply-To: <1171731302.7756.5.camel@bureau.maison> References: <1171728161.7756.2.camel@bureau.maison> <200702171133.33807.jkeating@redhat.com> <1171731302.7756.5.camel@bureau.maison> Message-ID: <45D73BBF.3010907@rasmil.dk> Tanguy Eric wrote: > Le samedi 17 f?vrier 2007 ? 11:33 -0500, Jesse Keating a ?crit : > >> On Saturday 17 February 2007 11:02, Tanguy Eric wrote: >> >>> I would like to know how to know which packages foo require package bar >>> or just a file from it. >>> I explain : i just update a lib and i would like to know which packages >>> will be affected by this and contact the maintainers. >>> >> repoquery is your friend (: >> >> > Thanks but it's not my friend ... > > repoquery --alldeps --whatrequires libupnp > > Traceback (most recent call last): > File "/usr/bin/repoquery", line 690, in ? > main(sys.argv) > File "/usr/bin/repoquery", line 687, in main > repoq.runQuery(regexs) > File "/usr/bin/repoquery", line 416, in runQuery > for p in self.doQuery(oper, prco): print p > File "/usr/bin/repoquery", line 421, in doQuery > return getattr(self, "fmt_%s" % method)(*args, **kw) > File "/usr/bin/repoquery", line 439, in fmt_whatrequires > provs.extend(pkg.prco("provides")) > File "/usr/bin/repoquery", line 187, in prco > rpdict[misc.prco_typle_to_string(rptup)] = None > AttributeError: 'module' object has no attribute 'prco_typle_to_string' > > Eric > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > The is a typo bug in repoquery, just change 'prco_typle_to_string' to 'prco_tuple_to_string' in line 186. It is fixed upstream, it will be available in next yum-util release. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.tanguy at univ-nantes.fr Sat Feb 17 17:35:01 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sat, 17 Feb 2007 18:35:01 +0100 Subject: Require In-Reply-To: <45D73BBF.3010907@rasmil.dk> References: <1171728161.7756.2.camel@bureau.maison> <200702171133.33807.jkeating@redhat.com> <1171731302.7756.5.camel@bureau.maison> <45D73BBF.3010907@rasmil.dk> Message-ID: <1171733701.7756.7.camel@bureau.maison> Le samedi 17 f?vrier 2007 ? 18:30 +0100, Tim Lauridsen a ?crit : > Tanguy Eric wrote: > > Le samedi 17 f?vrier 2007 ? 11:33 -0500, Jesse Keating a ?crit : > > > > > On Saturday 17 February 2007 11:02, Tanguy Eric wrote: > > > > > > > I would like to know how to know which packages foo require package bar > > > > or just a file from it. > > > > I explain : i just update a lib and i would like to know which packages > > > > will be affected by this and contact the maintainers. > > > > > > > repoquery is your friend (: > > > > > > > > Thanks but it's not my friend ... > > > > repoquery --alldeps --whatrequires libupnp > > > > Traceback (most recent call last): > > File "/usr/bin/repoquery", line 690, in ? > > main(sys.argv) > > File "/usr/bin/repoquery", line 687, in main > > repoq.runQuery(regexs) > > File "/usr/bin/repoquery", line 416, in runQuery > > for p in self.doQuery(oper, prco): print p > > File "/usr/bin/repoquery", line 421, in doQuery > > return getattr(self, "fmt_%s" % method)(*args, **kw) > > File "/usr/bin/repoquery", line 439, in fmt_whatrequires > > provs.extend(pkg.prco("provides")) > > File "/usr/bin/repoquery", line 187, in prco > > rpdict[misc.prco_typle_to_string(rptup)] = None > > AttributeError: 'module' object has no attribute 'prco_typle_to_string' > > > > Eric > > > > -- > > Fedora-maintainers mailing list > > Fedora-maintainers at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-maintainers > > > The is a typo bug in repoquery, just change 'prco_typle_to_string' to > 'prco_tuple_to_string' in line 186. > It is fixed upstream, it will be available in next yum-util release. > > Tim > > Thanks it works fine now. Eric From seg at haxxed.com Sun Feb 18 03:09:10 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 17 Feb 2007 21:09:10 -0600 Subject: Review question about /var/log/* files. In-Reply-To: <45CC870E.3080702@redhat.com> References: <45CC5B39.5020607@redhat.com> <1171027717.31485.119.camel@mccallum.corsepiu.local> <20070209135336.GA2979@free.fr> <200702090922.47033.sgrubb@redhat.com> <45CC870E.3080702@redhat.com> Message-ID: <1171768150.5761.7.camel@localhost.localdomain> On Fri, 2007-02-09 at 15:37 +0100, Phil Knirsch wrote: > Steve Grubb wrote: > > On Friday 09 February 2007 08:53, Patrice Dumas wrote: > >>>> What about the rotated files? > >>> If you know their exact names ..., why not also %ghost them? > >> The local admin could have made changes to the logrotate rules. > > > > Right, that was my point in mentioning rotated logs. The admin could have set > > the number of kept logs to 20. So, the question is why should 1 file be > > ghosted when you have this open ended rotate question? > > > > Thats a real good point. No package pwning^H^H^H^H^H^H owning any > logfiles in /var/log/ sounds more and more reasonable. Directories there > are a different matter as they clearly are connected to a specific package. I got bit on my server, which runs debian. (changing to CentOS Real Soon Now...) When I moved it over to Apache 2 from 1.3, I left 1.3 installed until it worked. Once I got everything going under Apache 2, I dpkg --purged Apache 1.3, and to my surprise, it nuked several years worth of access log files. I wanted to keep them around for running statistics and such. Oh well, live and learn. Thanks, debian... -------------- 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 ajackson at redhat.com Mon Feb 19 03:00:46 2007 From: ajackson at redhat.com (Adam Jackson) Date: Sun, 18 Feb 2007 22:00:46 -0500 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <1171663896.5985.0.camel@bureau.maison> References: <200702161608.14572.jkeating@redhat.com> <1171663896.5985.0.camel@bureau.maison> Message-ID: <1171854046.19779.1.camel@localhost.localdomain> On Fri, 2007-02-16 at 23:11 +0100, Tanguy Eric wrote: > With this schedule modification, will this release include firefox3 and > Xorg 7.3 ? X server 1.3, maybe. Xorg 7.3 (which will include some server >= 1.4), absolutely not. - ajax From j.w.r.degoede at hhs.nl Mon Feb 19 09:47:19 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 19 Feb 2007 10:47:19 +0100 Subject: Updated co-maintainership proposal -- guidelines In-Reply-To: <45D70AC5.8090502@leemhuis.info> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> <45D70AC5.8090502@leemhuis.info> Message-ID: <45D97227.2040002@hhs.nl> Thorsten Leemhuis wrote: > Comments? > First of all let me say that I'm very happy that this has become a "guidelines" document and not a set of hard rules. I think the name guidelines is wrong though, as currently we already have : * Packaging Guidelines * Package Naming Guidelines * Dist Tag Guidelines * Package Review Guidelines Which are must follow rules, not "guidelines" as used in your proposal. The new parts look good, I still see little value in the: "=== Don't (co-)maintain too many packages ===" and "=== Other aspects of co-maintainership ===" pieces, they make the whole document way too long to read with little added value IMHO. One last note: " * co-maintainers all get listed in the last field in owners.list. Note: currently owners.list is locked-down so changes need to be requested through the wiki, but once the package database is live this limitation should be removed." Aren't we changing the owners.list format, so that co-maintainers can be listed in the owners field, clearly seperating maintainers and observers? Regards, Hans From bugs.michael at gmx.net Mon Feb 19 10:16:46 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 19 Feb 2007 11:16:46 +0100 Subject: wxGTK2 status and testing Message-ID: <20070219111646.abfa4780.bugs.michael@gmx.net> $ rpm -q wxGTK wxGTK-2.8.0-2.8.0.1.3.fc7 What is the perceived stability of this wxGTK2 release so far? To build Audacity >= 2.3.1-beta with it, a CVS snapshot of Audacity is needed. The one from 2007-02-18 enters a deadlock, however, when exiting the program. Is this wxGTK2 release free of problems with other apps in Extras, which use it? From paul at city-fan.org Mon Feb 19 10:25:07 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 19 Feb 2007 10:25:07 +0000 Subject: wxGTK2 status and testing In-Reply-To: <20070219111646.abfa4780.bugs.michael@gmx.net> References: <20070219111646.abfa4780.bugs.michael@gmx.net> Message-ID: <45D97B03.6090606@city-fan.org> Michael Schwendt wrote: > $ rpm -q wxGTK > wxGTK-2.8.0-2.8.0.1.3.fc7 > > What is the perceived stability of this wxGTK2 release so far? > > To build Audacity >= 2.3.1-beta with it, a CVS snapshot of Audacity is > needed. The one from 2007-02-18 enters a deadlock, however, when exiting > the program. > > Is this wxGTK2 release free of problems with other apps in Extras, which > use it? No. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225043 (it's conceivable that this is a wxPython or bittorrent problem, but the same bittorrent package works fine with wx 2.6.x) I intend to revert bittorrent in Rawhide to 4.4.x, which uses a pygtk2 GUI. Paul. From bnocera at redhat.com Mon Feb 19 11:49:40 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 19 Feb 2007 11:49:40 +0000 Subject: FLAC update broke vorbis-tools In-Reply-To: <883cfe6d0702170908k47634e46w6a964e607d7b098b@mail.gmail.com> References: <883cfe6d0702170908k47634e46w6a964e607d7b098b@mail.gmail.com> Message-ID: <1171885780.28561.3.camel@bnocera.surrey.redhat.com> On Sat, 2007-02-17 at 12:08 -0500, Michel Salim wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229124 > > The V-Day edition of vorbis-tools does not have FLAC playback support. > Perhaps when getting it to build against libogg instead of libOggFLAC > the linking against libFLAC got clobbered as well? Probably just needs a rebuild. I'll do that now. From fedora at leemhuis.info Mon Feb 19 11:58:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Feb 2007 12:58:14 +0100 Subject: Updated co-maintainership proposal -- guidelines In-Reply-To: <45D97227.2040002@hhs.nl> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> <45D70AC5.8090502@leemhuis.info> <45D97227.2040002@hhs.nl> Message-ID: <45D990D6.2020705@leemhuis.info> On 19.02.2007 10:47, Hans de Goede wrote: > Thorsten Leemhuis wrote: >> Comments? > First of all let me say that I'm very happy that this has become a > "guidelines" document and not a set of hard rules. That was always meant as such, but wasn't that clear earlier. > I think the name > guidelines is wrong though, as currently we already have : > * Packaging Guidelines > * Package Naming Guidelines > * Dist Tag Guidelines > * Package Review Guidelines > Which are must follow rules, not "guidelines" as used in your proposal. Well, - maybe some native English speaker can come up with a better name, but "guidelines" seem to match the meaning of this stuff very well according to my English-German dictionary and my understanding of the English language. - it's not my fault if the stuff from the Packaging Committee uses the wrong word ;-) But I think they used it on purpose, too, as a in some very *rare* situations parts of what is written there is wrong for a particular package and can be ignored. > The new parts look good, I still see little value in the: > "=== Don't (co-)maintain too many packages ===" and > "=== Other aspects of co-maintainership ===" pieces, they make the whole > document way too long to read with little added value IMHO. I think they are worth it. I want to get new contributors into the project and that is the first step into this direction for a alternative way. Sponsorship doesn't scale endlessly. It doesn't work already anymore. Just imagine *me* wanting to start getting involved today (if I wouldn't have started years ago) -- I would not know what to package as everything I use or I'm interested in is packaged already. But I could start as a co-maintainer for another package, without access to the buildsystem and observed by the primary maintainer. But if you have a better idea to get new people involved and grown up in Fedora Packaging lang: tell us, as I really think that's hardly needed, as otherwise we have a "open" Fedora (Core) sonn, that's only open to a small group (~300 people) of formally Extras packagers, but still closed to the rest of the world, as it doesn't find a way in. That would be nearly no improvement. > One last note: > " * co-maintainers all get listed in the last field in owners.list. > Note: currently owners.list is locked-down so changes need to be > requested through the wiki, but once the package database is live this > limitation should be removed." > > Aren't we changing the owners.list format, so that co-maintainers can be > listed in the owners field, clearly seperating maintainers and observers? Yes, that need to be adjusted. CU thl From j.w.r.degoede at hhs.nl Mon Feb 19 12:09:10 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 19 Feb 2007 13:09:10 +0100 Subject: Updated co-maintainership proposal -- guidelines In-Reply-To: <45D990D6.2020705@leemhuis.info> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> <45D70AC5.8090502@leemhuis.info> <45D97227.2040002@hhs.nl> <45D990D6.2020705@leemhuis.info> Message-ID: <45D99366.1030501@hhs.nl> Thorsten Leemhuis wrote: > On 19.02.2007 10:47, Hans de Goede wrote: >> The new parts look good, I still see little value in the: >> "=== Don't (co-)maintain too many packages ===" and >> "=== Other aspects of co-maintainership ===" pieces, they make the >> whole document way too long to read with little added value IMHO. > > I think they are worth it. I want to get new contributors into the > project and that is the first step into this direction for a alternative > way. Sponsorship doesn't scale endlessly. > > It doesn't work already anymore. Just imagine *me* wanting to start > getting involved today (if I wouldn't have started years ago) -- I would > not know what to package as everything I use or I'm interested in is > packaged already. But I could start as a co-maintainer for another > package, without access to the buildsystem and observed by the primary > maintainer. > > But if you have a better idea to get new people involved and grown up in > Fedora Packaging lang: tell us, as I really think that's hardly needed, > as otherwise we have a "open" Fedora (Core) sonn, that's only open to a > small group (~300 people) of formally Extras packagers, but still closed > to the rest of the world, as it doesn't find a way in. That would be > nearly no improvement. > I don't object to the message, but I feel an vision piece like this, about how things should be, doesn't belong in a guidelines document, no matter how soft/hard the guidelines in the document, the vision piece of it doesn't give much guidance and thus belongs in a seperate document. About there not being much interesting stuff left to package, I disagree. I can still give a long list of somewhat pupolar games missign (glchess for example) and currently I'm working on packaging cross-compilers for the avr microcontroller and the gp2x handheld. But I agree that it would be usefull to have a different entry path. The problem here is, that most of us are currently maximally loaded with FE "work", thus if we get co-maintainers we (I) don't want that to cause any additional work, the concept of co-maintainers should lower the actual workload of the primary maintainer. I myself would like to see a couple of people who will be able to take a bunch of the more simple packages of my hand, and that I then become the co-maintainer, watching over their shoulder for a while to catch any grave mistakes. Regards, Hans From alan at redhat.com Mon Feb 19 12:28:52 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 19 Feb 2007 07:28:52 -0500 Subject: Updated co-maintainership proposal -- guidelines In-Reply-To: <45D990D6.2020705@leemhuis.info> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> <45D70AC5.8090502@leemhuis.info> <45D97227.2040002@hhs.nl> <45D990D6.2020705@leemhuis.info> Message-ID: <20070219122852.GA16578@devserv.devel.redhat.com> On Mon, Feb 19, 2007 at 12:58:14PM +0100, Thorsten Leemhuis wrote: > wrong word ;-) But I think they used it on purpose, too, as a in some > very *rare* situations parts of what is written there is wrong for a > particular package and can be ignored. "Policy" might have been better. That is stronger than guideline but less prescriptive than "rule". From fedora at leemhuis.info Mon Feb 19 12:46:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Feb 2007 13:46:28 +0100 Subject: Updated co-maintainership proposal -- guidelines In-Reply-To: <45D99366.1030501@hhs.nl> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> <45D70AC5.8090502@leemhuis.info> <45D97227.2040002@hhs.nl> <45D990D6.2020705@leemhuis.info> <45D99366.1030501@hhs.nl> Message-ID: <45D99C24.9080304@leemhuis.info> On 19.02.2007 13:09, Hans de Goede wrote: > [...] > About there not being much interesting stuff left to package, I > disagree. I did not say there isn't interesting stuff left to package. I'd say there isn't any stuff left to package that *I* would be interested in. And IMHO people should normally only package stuff that they are interested in and use. Otherwise the package quality might not be the best in the end. And most of the "mainstream" stuff is packaged these days afaics. > [...] But I > agree that it would be usefull to have a different entry path. The > problem here is, that most of us are currently maximally loaded with FE > "work", thus if we get co-maintainers we (I) don't want that to cause > any additional work, the concept of co-maintainers should lower the > actual workload of the primary maintainer. Exactly. But we have a lot of contributors already that are probably willing to take over some packagers from you. You just have to ask. Just remember when I became FESCO chair -- I had a lot more packages then and simply asked on the list "Hey, does anyone want to take over packages foo, bar and baz"? Some people showed up and took them over. They grew up in the Project. At least one of them is sponsor now (two iirc). Sure, some of the new packagers made errors -- that happens. But they learned from it, grew up in the project and now are better maintainers, and that is good for the project as a whole. So in this case and with co-maintainership it should work like this IMHO: you ask existing maintainers if they want to take over some of your packages. Some will find new owners. Those of the new owners could share the load with co-maintainers. Those new owners eventually become sponsors or get involved in other areas of the project in one or two years from now, and some of the new co-maintainers become real package owners. Then the cycle starts anew. > I myself would like to see a > couple of people who will be able to take a bunch of the more simple > packages of my hand, and that I then become the co-maintainer, watching > over their shoulder for a while to catch any grave mistakes. +1 (ans that exactly is written in one of the sections of the co-maintainership guidelines) CU thl From bugs.michael at gmx.net Mon Feb 19 13:18:22 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 19 Feb 2007 14:18:22 +0100 Subject: Updated co-maintainership proposal -- guidelines In-Reply-To: <45D990D6.2020705@leemhuis.info> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> <45D70AC5.8090502@leemhuis.info> <45D97227.2040002@hhs.nl> <45D990D6.2020705@leemhuis.info> Message-ID: <20070219141822.79b2e97c.bugs.michael@gmx.net> On Mon, 19 Feb 2007 12:58:14 +0100, Thorsten Leemhuis wrote: [...] > I want to get new contributors into the > project and that is the first step into this direction for a alternative > way. Sponsorship doesn't scale endlessly. > > It doesn't work already anymore. Just imagine *me* wanting to start > getting involved today (if I wouldn't have started years ago) -- I would > not know what to package as everything I use or I'm interested in is > packaged already. But I could start as a co-maintainer for another > package, without access to the buildsystem and observed by the primary > maintainer. Laughable. Most likely you just look in the wrong places. There are lots of open bug reports, lots of upstream bugs, lots of packages, which need more than throw-in-a-tarball-and-build updates, tools that are missing, insufficient man-power. And: We do have co-maintainership possibilities. We do have the sponsorship system. Any external contributor may join Fedora based on the same principles we've used in conjunction with Fedora Core for a very long time. Contributions in bugzilla and/or via closer contact with package maintainers. With Fedora Extras it is even easier, as its open to the community already. "Open" as in you can sign up for access. All that is needed are the actual contributions and the sponsors who are willing to let active contributors join even if they don't do reviews and if they own only a single package. The next logical step is to let them join if they are competent with regard to an existant package and when they team up with its primary owner. I welcome everyone, who contributes patches, testing, careful upgrades and similar stuff that needs to be done and where Fedora packagers as well as upstream developers can need help. It may be that some packages are almost free of maintenance requirements, and a single person can package dozens of them. But many aren't, because they are full of pitfalls and bugs. They would benefit from team-work. Team-work that starts *prior* to publishing [ABI/API-incompatible] version upgrades, which break other packages. Where is the updated/adjusted "How to become a Contributor" page? With ACLs at package-level, package owners could become sponsors for co-maintainers. From mattdm at mattdm.org Mon Feb 19 14:01:17 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 19 Feb 2007 09:01:17 -0500 Subject: wxGTK2 status and testing In-Reply-To: <20070219111646.abfa4780.bugs.michael@gmx.net> References: <20070219111646.abfa4780.bugs.michael@gmx.net> Message-ID: <20070219140117.GA13340@jadzia.bu.edu> On Mon, Feb 19, 2007 at 11:16:46AM +0100, Michael Schwendt wrote: > $ rpm -q wxGTK > wxGTK-2.8.0-2.8.0.1.3.fc7 > What is the perceived stability of this wxGTK2 release so far? Not so great -- causes problems with bittorrent, for example. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jwboyer at jdub.homelinux.org Mon Feb 19 14:09:31 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Feb 2007 08:09:31 -0600 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <200702161608.14572.jkeating@redhat.com> References: <200702161608.14572.jkeating@redhat.com> Message-ID: <1171894171.24204.21.camel@zod.rchland.ibm.com> On Fri, 2007-02-16 at 16:08 -0500, Jesse Keating wrote: > One of the big Features of Fedora 7 is a merged core and extras. In order to > accomplish this, we need some improvements to the buildsystem currently used > by Fedora Extras. We need these improvements done or mostly done by the > Feature Freeze of Fedora 7, which was originally set to be the 20th of > February, 4 days from now. It is very clear that these changes will not be > ready by then. > > To accomplish these changes (and others) in time for the Feature Freeze, we > have added another month to the schedule, introducing a Test 4, and moving > the Feature Freeze as well as String Freeze up to Test 3 freeze, March 19. > > This moves the general availability date from April 26 to May 24. > > For further discussion on this topic, please use the fedora-maintainers list, > which I am attempting to set reply-to. > > For reference: http://fedoraproject.org/wiki/Releases/7/Schedule Just a reminder for everyone, this means that FC-5 will be maintained for a slightly longer period of time. The lifetime of releases is N+2 plus one month. So FC-5 will be maintained until one month after F7 is release. Happy Hacking. josh From bugs.michael at gmx.net Mon Feb 19 14:22:48 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 19 Feb 2007 15:22:48 +0100 Subject: wxGTK2 status and testing In-Reply-To: <20070219140117.GA13340@jadzia.bu.edu> References: <20070219111646.abfa4780.bugs.michael@gmx.net> <20070219140117.GA13340@jadzia.bu.edu> Message-ID: <20070219152248.81038ee4.bugs.michael@gmx.net> On Mon, 19 Feb 2007 09:01:17 -0500, Matthew Miller wrote: > > $ rpm -q wxGTK > > wxGTK-2.8.0-2.8.0.1.3.fc7 > > What is the perceived stability of this wxGTK2 release so far? > > Not so great -- causes problems with bittorrent, for example. $ rpm -qa '*wxG*'|sort compat-wxGTK26-2.6.3-1 compat-wxGTK26-devel-2.6.3-1 wxGTK-2.8.0-2.8.0.1.3.fc7 wxGTK-devel-2.8.0-2.8.0.1.3.fc7 wxGTK-gl-2.8.0-2.8.0.1.3.fc7 I'm going to give this a try with Audacity, first. From gemi at bluewin.ch Mon Feb 19 14:27:20 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 19 Feb 2007 15:27:20 +0100 Subject: wxGTK2 status and testing In-Reply-To: <20070219152248.81038ee4.bugs.michael@gmx.net> References: <20070219111646.abfa4780.bugs.michael@gmx.net> <20070219140117.GA13340@jadzia.bu.edu> <20070219152248.81038ee4.bugs.michael@gmx.net> Message-ID: <1171895240.5333.1.camel@scriabin.tannenrauch.ch> On Mon, 2007-02-19 at 15:22 +0100, Michael Schwendt wrote: > I'm going to give this a try with Audacity, first. Michael, Since you maintain the livna package of audacity, you could also comaintain audacity in Fedora with me, couldn't you? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From jkeating at redhat.com Mon Feb 19 15:04:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Feb 2007 10:04:15 -0500 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <1171894171.24204.21.camel@zod.rchland.ibm.com> References: <200702161608.14572.jkeating@redhat.com> <1171894171.24204.21.camel@zod.rchland.ibm.com> Message-ID: <200702191004.19461.jkeating@redhat.com> On Monday 19 February 2007 09:09, Josh Boyer wrote: > Just a reminder for everyone, this means that FC-5 will be maintained > for a slightly longer period of time. ?The lifetime of releases is N+2 > plus one month. ?So FC-5 will be maintained until one month after F7 is > release. > > Happy Hacking. Hrm, I don't remember any official decisions wrt FC-5. I thought we had agreed to do this for FC6, but was unclear about FC-5. -- 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 Christian.Iseli at licr.org Mon Feb 19 15:05:41 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 19 Feb 2007 16:05:41 +0100 Subject: FE Package Status of Feb 19, 2007 Message-ID: <20070219160541.539bce2d@ludwig-alpha.unil.ch> Hi folks, I cross-post this to fel and fml. I suppose this should later only go to fml. What do you think ? The name should also become Fedora Package Status... I made a long overdue update to the PackageStatus page. I changed the script to deal with the new reviewing process and hope I didn't make too many mistakes. Have a good look, and report funnies... The mass review makes it a bit complicated to determine who is the submitter and who is the reviewer in some cases. We'll see how things look when the dust settles a bit on the big "merge review" thing. Looks like the owners.list file is still missing a couple entries, and is not fully sorted... Someone who has access: please fix it (or give me access to fix it). Sorting problem in owners.list: hunspell-bg lt hunspell-ca Sorting problem in owners.list: ices lt icewm Sorting problem in owners.list: kakasi lt kalgebra Cheers, C ---- FE Package Status of Feb 19, 2007 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 2868 packages - 4175 binary rpms in devel - 102 orphans - 21 packages not available in extras devel or release andreas at bawue dot net ddrescue bdpepple at ameritech dot net galago-filesystem caolanm at redhat dot com hunspell-hu caolanm at redhat dot com hunspell-ms caolanm at redhat dot com hunspell-it cweyl at alumni dot drew dot edu perl-GStreamer dbhole at redhat dot com objectweb-anttask fitzsim at redhat dot com classpathx-jaxp gauret at free dot fr pdftohtml gauret at free dot fr libvisual-plugins guillaume dot thouvenin at bull dot net elsa jhrozek at redhat dot com dwdiff matt at rudeserver dot com rudeconfig mcepl at redhat dot com gstreamer-plugins-pulseaudio overholt at redhat dot com jython paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net paul at all-the-johnsons dot co dot uk gconvert paul at xelerance dot com l2tpd pertusus at free dot fr ivman rmeggins at redhat dot com fedora-ds - 7 packages not available in extras devel but present in release andreas dot bierfert at lowlatency dot de sylpheed-claws-plugins andreas dot bierfert at lowlatency dot de sylpheed-claws bjohnson at symetrix dot com gdome2 cweyl at alumni dot drew dot edu 915resolution cweyl at alumni dot drew dot edu perl-File-ExtAttr jmp at safe dot ca clement lmacken at redhat dot com python-TurboMail - 26 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=226002 libevent nobody at fedoraproject.org https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=196837,221084,225755,225808,225896,225995,226036,226240,226264,226265,226266,226272,226279,226280,226291,226340,226345,226390,226395,226396,226399,226403,226429,226490,226497 php-pear-PHPUnit chris.stone at gmail.com dkms Matt_Domsch at dell.com firefox nobody at fedoraproject.org gmime nobody at fedoraproject.org icu nobody at fedoraproject.org libdaemon nobody at fedoraproject.org liboil nobody at fedoraproject.org perl-Archive-Zip nobody at fedoraproject.org perl-IO-Socket-SSL nobody at fedoraproject.org perl-IO-String nobody at fedoraproject.org perl-IO-Zlib nobody at fedoraproject.org perl-Net-SSLeay nobody at fedoraproject.org perl-Socket6 nobody at fedoraproject.org perl-String-CRC32 nobody at fedoraproject.org perl-XML-Simple nobody at fedoraproject.org pyspi nobody at fedoraproject.org python-numeric nobody at fedoraproject.org scim-anthy nobody at fedoraproject.org scim nobody at fedoraproject.org scim-pinyin nobody at fedoraproject.org scim-tables nobody at fedoraproject.org seamonkey nobody at fedoraproject.org sqlite nobody at fedoraproject.org thunderbird nobody at fedoraproject.org tog-pegasus nobody at fedoraproject.org - 2 packages present in the development repo which have no owners entry cycle gstreamer-plugins-pulse - 2 orphaned packages, yet available in extras devel luks-tools udftools - 43 packages that moved to core FE-ACCEPT packages stats: - 1945 accepted, closed package reviews - 25 accepted, closed package reviews not in repo - 2 accepted, closed package reviews not in owners - 13 accepted, open package reviews older than 4 weeks; - 80 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 213 open tickets - 23 tickets with no activity in eight weeks - 13 tickets with no activity in four weeks - 3 closed tickets FE-NEW packages stats: - 1175 open tickets - 38 tickets with no activity in eight weeks - 33 tickets with no activity in four weeks - 1 closed tickets FE-NEEDSPONSOR packages stats: - 49 open tickets - 7 tickets with no activity in eight weeks - 6 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets FE-GUIDELINES packages stats: - 2 open tickets - 2 tickets with no activity in eight weeks OPEN-BUGS packages stats: - 257 open tickets - 102 tickets with no activity in eight weeks - 36 tickets with no activity in four weeks CVS stats: - 2864 packages with a devel directory - 7 packages with no owners entry EL4 EL5 cycle gstreamer-plugins-pulse php-pear-PHP-CodeSniffer postgis postgresql-dbi-link - 1 packages in CVS devel *and* Core libnl - 193 packages were dropped from extras Maintainers stats: - 258 maintainers - 11 inactive maintainers with open bugs - 33 inactive maintainers Dropped FC packages: - 290 packages were dropped from core since FC 1 Comps.xml files stats: - 938 packages in comps-fe7 file - 546 packages missing from comps-fe7 file - 12 packages in comps-fe7 but not in repo - 935 packages in comps-fe6 file - 553 packages missing from comps-fe6 file - 5 packages in comps-fe6 but not in repo From ville.skytta at iki.fi Mon Feb 19 16:36:32 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 19 Feb 2007 18:36:32 +0200 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <200702191004.19461.jkeating@redhat.com> References: <200702161608.14572.jkeating@redhat.com> <1171894171.24204.21.camel@zod.rchland.ibm.com> <200702191004.19461.jkeating@redhat.com> Message-ID: <200702191836.32876.ville.skytta@iki.fi> On Monday 19 February 2007, Jesse Keating wrote: > On Monday 19 February 2007 09:09, Josh Boyer wrote: > > Just a reminder for everyone, this means that FC-5 will be maintained > > for a slightly longer period of time. ?The lifetime of releases is N+2 > > plus one month. ?So FC-5 will be maintained until one month after F7 is > > release. > > > > Happy Hacking. > > Hrm, I don't remember any official decisions wrt FC-5. I thought we had > agreed to do this for FC6, but was unclear about FC-5. In previous releases, placing FCX in maintenance mode happened IIRC at FC(X+2)test2 time. But I suppose maintenance mode as the concept it used to be has disappeared along with Legacy. Which way shall it be for FC5, and what are the plans for FC6+ in the future? Incidentally, I was looking for this information a few days back, but couldn't find it. It'd be good to have this documented somewhere prominently. Something to add to this week's FESCo agenda? From jkeating at redhat.com Mon Feb 19 16:46:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Feb 2007 11:46:56 -0500 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <200702191836.32876.ville.skytta@iki.fi> References: <200702161608.14572.jkeating@redhat.com> <200702191004.19461.jkeating@redhat.com> <200702191836.32876.ville.skytta@iki.fi> Message-ID: <200702191146.56378.jkeating@redhat.com> On Monday 19 February 2007 11:36, Ville Skytt? wrote: > In previous releases, placing FCX in maintenance mode happened IIRC at > FC(X+2)test2 time. ?But I suppose maintenance mode as the concept it used > to be has disappeared along with Legacy. > > Which way shall it be for FC5, and what are the plans for FC6+ in the > future? ? Incidentally, I was looking for this information a few days back, > but couldn't find it. ?It'd be good to have this documented somewhere > prominently. ?Something to add to this week's FESCo agenda? It does need to be decided. It was left somewhat in the air from the Fedora Summit where we introduced the idea of a 13~ month livespan, going from Test2 to 1 month past GOLD for a lifespan. We punted on any decision wrt FC-5 (and even 6) at that point. Given that we still don't have an ability for community folks to contribute updates to existing Fedora releases, I think this really needs to be answered by RH engineering management for how much work they are willing to sign up their engineers for, and that really isn't a decision that FESCO can make. We can certainly decide what should happen to Extras packages in accordance with the Core lifespan. -- 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 chris.stone at gmail.com Mon Feb 19 17:47:11 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 19 Feb 2007 09:47:11 -0800 Subject: FE Package Status of Feb 19, 2007 In-Reply-To: <20070219160541.539bce2d@ludwig-alpha.unil.ch> References: <20070219160541.539bce2d@ludwig-alpha.unil.ch> Message-ID: The new script did not pick up my review for duel3: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226729 What am I doing wrong? On 2/19/07, Christian Iseli wrote: > Hi folks, > > I cross-post this to fel and fml. I suppose this should later only go > to fml. What do you think ? The name should also become Fedora > Package Status... > > I made a long overdue update to the PackageStatus page. I > changed the script to deal with the new reviewing process and hope I > didn't make too many mistakes. Have a good look, and report funnies... > > The mass review makes it a bit complicated to determine who is the > submitter and who is the reviewer in some cases. We'll see how things > look when the dust settles a bit on the big "merge review" thing. > > Looks like the owners.list file is still missing a couple entries, and > is not fully sorted... Someone who has access: please fix it (or give > me access to fix it). > > Sorting problem in owners.list: hunspell-bg lt hunspell-ca > Sorting problem in owners.list: ices lt icewm > Sorting problem in owners.list: kakasi lt kalgebra > > Cheers, > C > > ---- > > FE Package Status of Feb 19, 2007 > > The full report can be found here: > http://fedoraproject.org/wiki/Extras/PackageStatus > > > Owners file stats: > - 2868 packages > - 4175 binary rpms in devel > - 102 orphans > - 21 packages not available in extras devel or release > andreas at bawue dot net ddrescue > bdpepple at ameritech dot net galago-filesystem > caolanm at redhat dot com hunspell-hu > caolanm at redhat dot com hunspell-ms > caolanm at redhat dot com hunspell-it > cweyl at alumni dot drew dot edu perl-GStreamer > dbhole at redhat dot com objectweb-anttask > fitzsim at redhat dot com classpathx-jaxp > gauret at free dot fr pdftohtml > gauret at free dot fr libvisual-plugins > guillaume dot thouvenin at bull dot net elsa > jhrozek at redhat dot com dwdiff > matt at rudeserver dot com rudeconfig > mcepl at redhat dot com gstreamer-plugins-pulseaudio > overholt at redhat dot com jython > paul at all-the-johnsons dot co dot uk XaraLX > paul at all-the-johnsons dot co dot uk mysql-connector-net > paul at all-the-johnsons dot co dot uk gconvert > paul at xelerance dot com l2tpd > pertusus at free dot fr ivman > rmeggins at redhat dot com fedora-ds > - 7 packages not available in extras devel but present in release > andreas dot bierfert at lowlatency dot de sylpheed-claws-plugins > andreas dot bierfert at lowlatency dot de sylpheed-claws > bjohnson at symetrix dot com gdome2 > cweyl at alumni dot drew dot edu 915resolution > cweyl at alumni dot drew dot edu perl-File-ExtAttr > jmp at safe dot ca clement > lmacken at redhat dot com python-TurboMail > - 26 packages which have not yet been FE-ACCEPT'd... > https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=226002 > libevent nobody at fedoraproject.org > https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=196837,221084,225755,225808,225896,225995,226036,226240,226264,226265,226266,226272,226279,226280,226291,226340,226345,226390,226395,226396,226399,226403,226429,226490,226497 > php-pear-PHPUnit chris.stone at gmail.com > dkms Matt_Domsch at dell.com > firefox nobody at fedoraproject.org > gmime nobody at fedoraproject.org > icu nobody at fedoraproject.org > libdaemon nobody at fedoraproject.org > liboil nobody at fedoraproject.org > perl-Archive-Zip nobody at fedoraproject.org > perl-IO-Socket-SSL nobody at fedoraproject.org > perl-IO-String nobody at fedoraproject.org > perl-IO-Zlib nobody at fedoraproject.org > perl-Net-SSLeay nobody at fedoraproject.org > perl-Socket6 nobody at fedoraproject.org > perl-String-CRC32 nobody at fedoraproject.org > perl-XML-Simple nobody at fedoraproject.org > pyspi nobody at fedoraproject.org > python-numeric nobody at fedoraproject.org > scim-anthy nobody at fedoraproject.org > scim nobody at fedoraproject.org > scim-pinyin nobody at fedoraproject.org > scim-tables nobody at fedoraproject.org > seamonkey nobody at fedoraproject.org > sqlite nobody at fedoraproject.org > thunderbird nobody at fedoraproject.org > tog-pegasus nobody at fedoraproject.org > - 2 packages present in the development repo which have no owners entry > cycle gstreamer-plugins-pulse > - 2 orphaned packages, yet available in extras devel > luks-tools udftools > - 43 packages that moved to core > > FE-ACCEPT packages stats: > - 1945 accepted, closed package reviews > - 25 accepted, closed package reviews not in repo > - 2 accepted, closed package reviews not in owners > - 13 accepted, open package reviews older than 4 weeks; > - 80 accepted, open package reviews with a package already in the repo > > FE-REVIEW packages stats: > - 213 open tickets > - 23 tickets with no activity in eight weeks > - 13 tickets with no activity in four weeks > - 3 closed tickets > > FE-NEW packages stats: > - 1175 open tickets > - 38 tickets with no activity in eight weeks > - 33 tickets with no activity in four weeks > - 1 closed tickets > > FE-NEEDSPONSOR packages stats: > - 49 open tickets > - 7 tickets with no activity in eight weeks > - 6 tickets with no activity in four weeks > > FE-LEGAL packages stats: > - 1 open tickets > > FE-GUIDELINES packages stats: > - 2 open tickets > - 2 tickets with no activity in eight weeks > > OPEN-BUGS packages stats: > - 257 open tickets > - 102 tickets with no activity in eight weeks > - 36 tickets with no activity in four weeks > > CVS stats: > - 2864 packages with a devel directory > - 7 packages with no owners entry > EL4 EL5 cycle gstreamer-plugins-pulse php-pear-PHP-CodeSniffer postgis > postgresql-dbi-link > - 1 packages in CVS devel *and* Core > libnl > - 193 packages were dropped from extras > > Maintainers stats: > - 258 maintainers > - 11 inactive maintainers with open bugs > - 33 inactive maintainers > > Dropped FC packages: > - 290 packages were dropped from core since FC 1 > > Comps.xml files stats: > - 938 packages in comps-fe7 file > - 546 packages missing from comps-fe7 file > - 12 packages in comps-fe7 but not in repo > - 935 packages in comps-fe6 file > - 553 packages missing from comps-fe6 file > - 5 packages in comps-fe6 but not in repo > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From chris.stone at gmail.com Mon Feb 19 18:01:39 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 19 Feb 2007 10:01:39 -0800 Subject: Updated co-maintainership proposal -- guidelines In-Reply-To: <45D990D6.2020705@leemhuis.info> References: <1171490808.21788.10.camel@Chuck> <45D3F6BC.3040202@leemhuis.info> <45D70AC5.8090502@leemhuis.info> <45D97227.2040002@hhs.nl> <45D990D6.2020705@leemhuis.info> Message-ID: On 2/19/07, Thorsten Leemhuis wrote: > It doesn't work already anymore. Just imagine *me* wanting to start > getting involved today (if I wouldn't have started years ago) -- I would > not know what to package as everything I use or I'm interested in is > packaged already. But I could start as a co-maintainer for another > package, without access to the buildsystem and observed by the primary > maintainer. Dude, there must be thousands of packages that still need packaging. What are you kidding me?? There must be hundreds of games at pygame.org _alone_ that still need packaging. And not to mention the fifty or so packages on the wish list[1]. You do realize that suse linux has about 22,000 packages and we only have 8000 at best[2]? Do you ever wonder why suse is doing so much better than fedora on sites like distrowatch? So the excuse of "we are running out of things to package" is totally bogus as a reason to want to encourage co-maintainers, IMO. If you want something to package, I can mention atleast 250 or so games that still need to be done. See [3] and [4]. -Chris [1] http://fedoraproject.org/wiki/Extras/WishList [2] http://en.wikipedia.org/wiki/Comparison_of_Linux_Distributions [3] http://pygame.org [4] http://fedoraproject.org/wiki/Extras/SIGs/Games From Christian.Iseli at licr.org Mon Feb 19 18:32:53 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 19 Feb 2007 19:32:53 +0100 Subject: FE Package Status of Feb 19, 2007 In-Reply-To: References: <20070219160541.539bce2d@ludwig-alpha.unil.ch> Message-ID: <20070219193253.01acf920@ludwig-alpha.unil.ch> On Mon, 19 Feb 2007 09:47:11 -0800, Christopher Stone wrote: > The new script did not pick up my review for duel3: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226729 > > What am I doing wrong? Probably nothing (not completely sure, because mtasaka just did some changes on the ticket). The way the script currently counts who made a review is by looking at the "Assigned To" field, *not* by looking at who flipped the fedora?review flag to '+'. I have not found a way to do batch queries to determine who flipped that switch (but I'm very willing to be educated... :-) ) So, for the time being, if the reviewer could make sure he's the "Assigned To" target when a review is done, the counts will be correct (and I think that's the way it is supposed to be according to the latest version of the review guidelines...) Getting an easy mean to know who flipped the flag, and when, would of course be very good too... (I suppose I could grab the change history of each ticket, but that somehow looks pretty unappealing...) Cheers, Christian From wtogami at redhat.com Mon Feb 19 20:51:00 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 19 Feb 2007 15:51:00 -0500 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <20070205213236.GI4858@nostromo.devel.redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> Message-ID: <45DA0DB4.4020307@redhat.com> FESCO voted to ratify this process during last Thursday's meeting. I am posting this on record to reflect the minor changes to the flag treatment. Next I will update documentation. Changes since Version 3: - notting had a good point that unsetting a flag did not necessarily notify folks that a request is done. Thus, + is used when a request is done. ================================== = Proposal: CVS Admin with Flags = ================================== New Packages ============ 1) Review is complete, fedora-review+ 2) Owner writes in the Bugzilla comment something like: Please comma separate the co-maintainers if you have more than one. Examples: FC-5 FC-6 foopackage bobjoe at gmail.com FC-6 barpackage bobjoe at gmail.com,mary at example.com 3) Set fedora-cvs flag to ? 4) CVS Admins get e-mail about fedora-cvs flag. All context of the review is within the bug itself, so they can easily read all details about the package and verify approval validity. The Admin then creates CVS directories and sets owner in owners.list. fedora-cvs is set to + when the request is done. 5) Owner checks in and builds. More Branches on Existing Packages ================================== 1) Use existing review ticket, even if it is CLOSED, this is fine. 2) Write in a comment the additional branch names you desire. 3) Set fedora-cvs? Change Owner or Add Co-Maintainers ================================== 1) Use existing review ticket, even if it is CLOSED, this is fine. 2) Write in a comment the change request and justification if appropriate. 3) Set fedora-cvs? (If bulk changes are required (i.e. more than six at once), please talk directly to a Fedora CVS administrator.) Special CVS Admin Requests ========================== In some cases you will want special CVS requests, like fixing import accidents or removing packages that were added in error. 1) Use existing review ticket, even if it is CLOSED, this is fine. 2) Write in a comment your request and why it should be done. 3) Set fedora-cvs? Benefits ======== - This fedora-cvs flag eliminates the need for CVSSyncNeeded entirely. An actual work queue with tickets! - fedora-cvs can be a simple canned query for CVS admins to see. Awesome possibilities offered via RSS too... =) Notes ===== - Syncing from owners.list to CVS ACL's happen every 30 minutes. You may need to wait for the next 30 minute sync before checking in files of a new package. From notting at redhat.com Mon Feb 19 21:03:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Feb 2007 16:03:10 -0500 Subject: changing the format of owners.list In-Reply-To: <20070215192824.GA14557@nostromo.devel.redhat.com> References: <20070215192824.GA14557@nostromo.devel.redhat.com> Message-ID: <20070219210310.GA3736@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > To better enable co-maintainership, the format of owners.list is going > to change slightly on Monday, February 18th, at 3PM EST (2000 UTC), give > or take a few minutes. This switch has now happened. Bill From mr.ecik at gmail.com Mon Feb 19 21:06:20 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Mon, 19 Feb 2007 22:06:20 +0100 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DA0DB4.4020307@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> Message-ID: <668bb39a0702191306i1939c0a6ga5eb0701ce813ab1@mail.gmail.com> 2007/2/19, Warren Togami : > 2) Owner writes in the Bugzilla comment something like: > > Please comma separate the co-maintainers if you have more than one. > Examples: > FC-5 FC-6 foopackage bobjoe at gmail.com > FC-6 barpackage bobjoe at gmail.com,mary at example.com Why don't we suppose that review request reporter is the main package maintainer? In this case there would be only a need to write additional co-maintainers. -- Micha? Bentkowski mr.ecik at gmail.com From wtogami at redhat.com Mon Feb 19 21:41:37 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 19 Feb 2007 16:41:37 -0500 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <668bb39a0702191306i1939c0a6ga5eb0701ce813ab1@mail.gmail.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> <668bb39a0702191306i1939c0a6ga5eb0701ce813ab1@mail.gmail.com> Message-ID: <45DA1991.2010906@redhat.com> Micha? Bentkowski wrote: > 2007/2/19, Warren Togami : >> 2) Owner writes in the Bugzilla comment something like: >> >> Please comma separate the co-maintainers if you have more than one. >> Examples: >> FC-5 FC-6 foopackage bobjoe at gmail.com >> FC-6 barpackage bobjoe at gmail.com,mary at example.com > Why don't we suppose that review request reporter is the main package > maintainer? In this case there would be only a need to write > additional co-maintainers. > That isn't always a safe assumption. http://fedoraproject.org/wiki/Infrastructure/PackageDatabase Yes, this process sucks, but don't worry too much. We will eventually get rid of this entirely as part of the PackageDatabase project. Please help the Infrastructure team with that project. Warren Togami wtogami at redhat.com From wart at kobold.org Mon Feb 19 21:51:47 2007 From: wart at kobold.org (Wart) Date: Mon, 19 Feb 2007 13:51:47 -0800 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DA0DB4.4020307@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> Message-ID: <45DA1BF3.8040301@kobold.org> Warren Togami wrote: > FESCO voted to ratify this process during last Thursday's meeting. I am > posting this on record to reflect the minor changes to the flag > treatment. Next I will update documentation. > > Changes since Version 3: > - notting had a good point that unsetting a flag did not necessarily > notify folks that a request is done. Thus, + is used when a request is > done. > > ================================== > = Proposal: CVS Admin with Flags = > ================================== [...] Does the current set of requests on http://fedoraproject.org/wiki/Extras/CVSSyncNeeded need to be re-requested using the flag system? --Wart From wtogami at redhat.com Mon Feb 19 22:20:53 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 19 Feb 2007 17:20:53 -0500 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DA1BF3.8040301@kobold.org> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> <45DA1BF3.8040301@kobold.org> Message-ID: <45DA22C5.7020102@redhat.com> Wart wrote: > Warren Togami wrote: >> FESCO voted to ratify this process during last Thursday's meeting. I >> am posting this on record to reflect the minor changes to the flag >> treatment. Next I will update documentation. >> >> Changes since Version 3: >> - notting had a good point that unsetting a flag did not necessarily >> notify folks that a request is done. Thus, + is used when a request >> is done. >> >> ================================== >> = Proposal: CVS Admin with Flags = >> ================================== > [...] > > Does the current set of requests on > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded need to be > re-requested using the flag system? > No, I'm taking care of those myself before I clear out that page and redirect people to the new procedure forming on: http://fedoraproject.org/wiki/CVSAdminProcedure You may use the new procedure on this page now. Warren Togami wtogami at redhat.com From buildsys at fedoraproject.org Mon Feb 19 23:02:03 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 19 Feb 2007 18:02:03 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-02-19 Message-ID: <20070219230203.D996815212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) rsync FC5-updates > FC7 (0:2.6.9-2.fc5 > 0:2.6.9-1) FC6-updates > FC7 (0:2.6.9-2.fc6 > 0:2.6.9-1) screen FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) sound-juicer FC6-updates > FC7 (0:2.16.3-1.fc6 > 0:2.16.2-3.fc7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) cgoorah AT yahoo.com.au: kdmtheme FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) 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) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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: 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) 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) 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) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) FE5 > FE7 (0:2.10.17-2.fc5 > 0:2.10.17-1.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 linux.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) tagoh AT redhat.com: mew FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) 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) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) 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) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) 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) 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) gnubg: limb AT jcomserv.net FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.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) kdmtheme: cgoorah AT yahoo.com.au FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) FE5 > FE7 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc7) mew: tagoh AT redhat.com FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) 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) rsync: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:2.6.9-2.fc5 > 0:2.6.9-1) FC6-updates > FC7 (0:2.6.9-2.fc6 > 0:2.6.9-1) screen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) seahorse: skvidal AT linux.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) sound-juicer: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.16.3-1.fc6 > 0:2.16.2-3.fc7) 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) 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) 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 mtasaka at ioa.s.u-tokyo.ac.jp Tue Feb 20 02:32:16 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 20 Feb 2007 11:32:16 +0900 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DA0DB4.4020307@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> Message-ID: <45DA5DB0.9050108@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > FESCO voted to ratify this process during last Thursday's meeting. I am > posting this on record to reflect the minor changes to the flag > treatment. Next I will update documentation. > > Changes since Version 3: Well, again I ask the same question: Some questions. How does this work with the renamed packages or packages of which the maintainer changed several times from initial? * Well, there may be the case that the name of the package changed several times (this especially happens for new packages) * Maintainers also change. * After some long time, the "current" maintainer askes, "well, where is the initial review request?" This becomes a trouble especially when the previous maintainer is missing, some people (like sponsors) puts the package into "orphaned" category, and then some other fedorabugs member takes over the maintainership (and at the time the name of the package changed from initial). Mamoru Tasaka From paul at xelerance.com Tue Feb 20 05:14:54 2007 From: paul at xelerance.com (Paul Wouters) Date: Tue, 20 Feb 2007 06:14:54 +0100 (CET) Subject: FE Package Status of Feb 19, 2007 In-Reply-To: <20070219160541.539bce2d@ludwig-alpha.unil.ch> References: <20070219160541.539bce2d@ludwig-alpha.unil.ch> Message-ID: On Mon, 19 Feb 2007, Christian Iseli wrote: > FE Package Status of Feb 19, 2007 > - 21 packages not available in extras devel or release [...] > paul at xelerance dot com l2tpd Package was obsoleted for xl2tpd. was I supposed to remove it from the owners file? I no longer have access to modify that file. Paul From Christian.Iseli at licr.org Tue Feb 20 08:48:35 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 20 Feb 2007 09:48:35 +0100 Subject: FE Package Status of Feb 19, 2007 In-Reply-To: References: <20070219160541.539bce2d@ludwig-alpha.unil.ch> Message-ID: <20070220094835.42703b5d@ludwig-alpha.unil.ch> On Tue, 20 Feb 2007 06:14:54 +0100 (CET), Paul Wouters wrote: > Package was obsoleted for xl2tpd. was I supposed to remove it from the > owners file? No. Please have a look at http://fedoraproject.org/wiki/Extras/PackageEndOfLife (you should "cvs rm" the files in l2tpd/devel and "cvs add" a dead.package file in there) Cheers, C From bugs.michael at gmx.net Tue Feb 20 09:39:18 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 20 Feb 2007 10:39:18 +0100 Subject: wxGTK2 status and testing In-Reply-To: <1171895240.5333.1.camel@scriabin.tannenrauch.ch> References: <20070219111646.abfa4780.bugs.michael@gmx.net> <20070219140117.GA13340@jadzia.bu.edu> <20070219152248.81038ee4.bugs.michael@gmx.net> <1171895240.5333.1.camel@scriabin.tannenrauch.ch> Message-ID: <20070220103918.12549d0f.bugs.michael@gmx.net> On Mon, 19 Feb 2007 15:27:20 +0100, G?rard Milmeister wrote: > On Mon, 2007-02-19 at 15:22 +0100, Michael Schwendt wrote: > > > I'm going to give this a try with Audacity, first. > Michael, > Since you maintain the livna package of audacity, you could also > comaintain audacity in Fedora with me, couldn't you? We can try that if you like. Though, for Audacity (and the big wxWidgets) an even larger team would be beneficial. Anyway, I've submitted compat-wxGTK26 for review, because Audacity builds with it and doesn't lock up and because a recent snapshot of Audacity introduces new problems wrt audio I/O and project freq. From bugs.michael at gmx.net Tue Feb 20 09:39:34 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 20 Feb 2007 10:39:34 +0100 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DA5DB0.9050108@ioa.s.u-tokyo.ac.jp> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> <45DA5DB0.9050108@ioa.s.u-tokyo.ac.jp> Message-ID: <20070220103934.756f181f.bugs.michael@gmx.net> On Tue, 20 Feb 2007 11:32:16 +0900, Mamoru Tasaka wrote: > Warren Togami wrote: > > FESCO voted to ratify this process during last Thursday's meeting. I am > > posting this on record to reflect the minor changes to the flag > > treatment. Next I will update documentation. > > > > Changes since Version 3: > > Well, again I ask the same question: > > Some questions. > How does this work with the renamed packages or packages of which > the maintainer changed several times from initial? > > * Well, there may be the case that the name of the package changed > several times (this especially happens for new packages) > * Maintainers also change. > * After some long time, the "current" maintainer askes, "well, > where is the initial review request?" This becomes a trouble > especially when the previous maintainer is missing, some people > (like sponsors) puts the package into "orphaned" category, > and then some other fedorabugs member takes over the maintainership > (and at the time the name of the package changed from initial). Plus: the original package submitter and reviewer(s) receive bugzilla spam when old closed tickets are reused for requesting ownership changes. From mtasaka at ioa.s.u-tokyo.ac.jp Tue Feb 20 10:38:08 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 20 Feb 2007 19:38:08 +0900 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <20070220103934.756f181f.bugs.michael@gmx.net> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> <45DA5DB0.9050108@ioa.s.u-tokyo.ac.jp> <20070220103934.756f181f.bugs.michael@gmx.net> Message-ID: <45DACF90.8000207@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote: > On Tue, 20 Feb 2007 11:32:16 +0900, Mamoru Tasaka wrote: > >> Warren Togami wrote: >>> FESCO voted to ratify this process during last Thursday's meeting. I am >>> posting this on record to reflect the minor changes to the flag >>> treatment. Next I will update documentation. >>> >>> Changes since Version 3: >> Well, again I ask the same question: >> >> Some questions. >> How does this work with the renamed packages or packages of which >> the maintainer changed several times from initial? > > Plus: the original package submitter and reviewer(s) receive bugzilla spam > when old closed tickets are reused for requesting ownership changes. > And.. Thorsten asked the case in that the package was imported from fedora.us or freshrpms.net, in which the original bugzilla ticket does not exist. Moreover, writing a request on the old bugzilla ticket changes the status of "Last Changed" meaninglessly, which may cause some problems when someone wants to use this information. Mamoru From jkeating at redhat.com Tue Feb 20 14:32:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Feb 2007 09:32:58 -0500 Subject: Fedora 7 Test 2 Freeze... TODAY! Message-ID: <200702200932.58143.jkeating@redhat.com> In all the hustle and bustle last week of trying to get the schedule extended, I completely forgot to warn about the Test 2 freeze, which is scheduled for today. Due to the late notice, I'll be setting up the freeze tag and tagging stuff late tonight (Eastern US time zone). This is not the feature freeze, instead it is another trial of what we compose for Fedora 7. -- 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 Tue Feb 20 16:57:28 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 11:57:28 -0500 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DA5DB0.9050108@ioa.s.u-tokyo.ac.jp> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> <45DA5DB0.9050108@ioa.s.u-tokyo.ac.jp> Message-ID: <45DB2878.4000405@redhat.com> Mamoru Tasaka wrote: > Warren Togami wrote: >> FESCO voted to ratify this process during last Thursday's meeting. I >> am posting this on record to reflect the minor changes to the flag >> treatment. Next I will update documentation. >> >> Changes since Version 3: > > Well, again I ask the same question: > > Some questions. > How does this work with the renamed packages or packages of which > the maintainer changed several times from initial? > > * Well, there may be the case that the name of the package changed > several times (this especially happens for new packages) > * Maintainers also change. > * After some long time, the "current" maintainer askes, "well, > where is the initial review request?" This becomes a trouble > especially when the previous maintainer is missing, some people > (like sponsors) puts the package into "orphaned" category, > and then some other fedorabugs member takes over the maintainership > (and at the time the name of the package changed from initial). > Well, how do we currently handle those cases? Not in any organized and easy to track way. Perhaps if existing review tickets are used, with comments about what is being done in conjunction with fedora-cvs set to ?, then we at least have a semi-organized paper trail as maintainers change, or package name changes, etc. Warren Togami wtogami at redhat.com From wtogami at redhat.com Tue Feb 20 17:02:53 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 12:02:53 -0500 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DACF90.8000207@ioa.s.u-tokyo.ac.jp> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> <45DA5DB0.9050108@ioa.s.u-tokyo.ac.jp> <20070220103934.756f181f.bugs.michael@gmx.net> <45DACF90.8000207@ioa.s.u-tokyo.ac.jp> Message-ID: <45DB29BD.3040604@redhat.com> Mamoru Tasaka wrote: > Michael Schwendt wrote: >> On Tue, 20 Feb 2007 11:32:16 +0900, Mamoru Tasaka wrote: >> >>> Warren Togami wrote: >>>> FESCO voted to ratify this process during last Thursday's meeting. >>>> I am posting this on record to reflect the minor changes to the flag >>>> treatment. Next I will update documentation. >>>> >>>> Changes since Version 3: >>> Well, again I ask the same question: >>> >>> Some questions. >>> How does this work with the renamed packages or packages of which >>> the maintainer changed several times from initial? >> >> Plus: the original package submitter and reviewer(s) receive bugzilla >> spam >> when old closed tickets are reused for requesting ownership changes. >> > And.. Thorsten asked the case in that the package was imported from > fedora.us or freshrpms.net, in which the original bugzilla ticket > does not exist. I suppose nothing stops you from filing a new bug in order to request a CVS change. > > Moreover, writing a request on the old bugzilla ticket changes the > status of "Last Changed" meaninglessly, which may cause some problems > when someone wants to use this information. > The history however keeps track of those previous states. Can we just accept that we are limited by the current tools? http://fedoraproject.org/wiki/Infrastructure/PackageDatabase Please use your ideas of what the process needs and contribute to the design and implementation of the Package Database project. Warren Togami wtogami at redhat.com From mtasaka at ioa.s.u-tokyo.ac.jp Tue Feb 20 17:12:59 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 21 Feb 2007 02:12:59 +0900 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DB29BD.3040604@redhat.com> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> <45DA5DB0.9050108@ioa.s.u-tokyo.ac.jp> <20070220103934.756f181f.bugs.michael@gmx.net> <45DACF90.8000207@ioa.s.u-tokyo.ac.jp> <45DB29BD.3040604@redhat.com> Message-ID: <45DB2C1B.5010505@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > > Can we just accept that we are limited by the current tools? > > http://fedoraproject.org/wiki/Infrastructure/PackageDatabase So simply: "use cvs flags if it is possible. If it seems difficult (in the case that the original review request cannot be found, e.g.) write the request to SyncNeeded, however perhaps using cvs flags will be faster" seems okay. Mamoru From ville.skytta at iki.fi Tue Feb 20 18:04:15 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 20 Feb 2007 20:04:15 +0200 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DA0DB4.4020307@redhat.com> References: <45BE7342.1070005@redhat.com> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> Message-ID: <200702202004.15848.ville.skytta@iki.fi> On Monday 19 February 2007, Warren Togami wrote: > More Branches on Existing Packages > ================================== > 1) Use existing review ticket, even if it is CLOSED, this is fine. Reusing an old review ticket results in additional traffic on the reviews mailing list that most recipients probably don't care about and would rather not receive... From wtogami at redhat.com Tue Feb 20 18:22:28 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 13:22:28 -0500 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <200702202004.15848.ville.skytta@iki.fi> References: <45BE7342.1070005@redhat.com> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> <200702202004.15848.ville.skytta@iki.fi> Message-ID: <45DB3C64.7070602@redhat.com> Ville Skytt? wrote: > On Monday 19 February 2007, Warren Togami wrote: > >> More Branches on Existing Packages >> ================================== >> 1) Use existing review ticket, even if it is CLOSED, this is fine. > > Reusing an old review ticket results in additional traffic on the reviews > mailing list that most recipients probably don't care about and would rather > not receive... > Somebody asking to change the owner of a package shouldn't be visible to everyone else? I believe it should. Even if this not ideal, this sucks a LOT less than the previous process. Using the Wiki for workflow management was just horrible. Separate authentication system, poor tracking of who did what, completely decoupled from the Bugzilla tickets they were referring to, requiring more work in reading context before approving a request. We will NOT move back to using the Wiki for a purpose like that. Please help us to figure out exactly what we need in the PackageDatabase to further streamline this process. Warren Togami wtogami at redhat.com From wtogami at redhat.com Tue Feb 20 18:29:50 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 13:29:50 -0500 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DB2C1B.5010505@ioa.s.u-tokyo.ac.jp> References: <45BE7342.1070005@redhat.com> <45BEC555.8050908@redhat.com> <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> <45DA5DB0.9050108@ioa.s.u-tokyo.ac.jp> <20070220103934.756f181f.bugs.michael@gmx.net> <45DACF90.8000207@ioa.s.u-tokyo.ac.jp> <45DB29BD.3040604@redhat.com> <45DB2C1B.5010505@ioa.s.u-tokyo.ac.jp> Message-ID: <45DB3E1E.5030607@redhat.com> Mamoru Tasaka wrote: > Warren Togami wrote: >> >> Can we just accept that we are limited by the current tools? >> >> http://fedoraproject.org/wiki/Infrastructure/PackageDatabase > > So simply: > "use cvs flags if it is possible. If it seems difficult > (in the case that the original review request cannot be found, > e.g.) > write the request to SyncNeeded, however perhaps using cvs flags > will be faster" > seems okay. > You are advocating that we reintroduce a huge and ugly complication in order to "better" handle a corner case. The regular case is handled now in a far smoother way, and these corner cases are not so unreasonable either. Warren From wtogami at redhat.com Tue Feb 20 18:33:09 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 13:33:09 -0500 Subject: Reviewer as Enforcer (ASSIGNED) In-Reply-To: <45CC1DCC.1090707@ioa.s.u-tokyo.ac.jp> References: <45CAA500.5080106@redhat.com> <20070208135705.03ab4688@ludwig-alpha.unil.ch> <200702080825.25601.jkeating@redhat.com> <45CB8360.9090602@ioa.s.u-tokyo.ac.jp> <45CB851A.6020200@redhat.com> <45CC1DCC.1090707@ioa.s.u-tokyo.ac.jp> Message-ID: <45DB3EE5.2080400@redhat.com> Mamoru Tasaka wrote: > And... it is obvious that the person who _mainly_ has > to take action after the review passed is the submitter, > isn't it? Moreover I think that setting assingee as > reviewer, which explicitly shows the person who reviewed > the bug, makes it easier to trace the reviewes > _afterwards_ by bugzilla query or some other methods. I see. You see the role of the reviewer as an "enforcer", who is responsible to being sure that a review goes through to the end. Even after fedora-review+, the reviewer remains ASSIGNED and accountable, able to follow-up if necessary. OK, I am convinced. ASSIGNED to reviewer (and stays that way) is the best we can do within limitations of our current tools. I guess another draft ensues... Warren From wtogami at redhat.com Tue Feb 20 18:45:15 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 13:45:15 -0500 Subject: RFC: Review with Flags (Version 5) Message-ID: <45DB41BB.7010807@redhat.com> This procedure is meant to be for *BOTH* Merge and regular package reviews. Please comment. I hope we can finally ratify something during this Thursday's FESCO meeting. Changes since Version 4: ======================== - ASSIGNED to nobody if there is no reviewer yet. - ASSIGNED remains on reviewer thereafter. - Use NEEDINFO if someone other than the reviewer needs to take action. Fedora Review Flag States ========================= fedora-review BLANK I want a review, or a past reviewer gave up. fedora-review? Under Review, ASSIGNED to reviewer fedora-review- Denied and needs work, NEEDINFO to owner fedora-review+ APPROVED, ASSIGNED to reviewer Assigned Pointer ================ - Assigned pointer to nobody at fedoraproject.org if no reviewer yet. - Assigned pointer to reviewer, during and after the review. Bugzilla States =============== In practice a bug sitting in these states matter less than the state of the fedora-review flag. Participants are to follow these states as suggested guidelines, but the fedora-review flag has the hard requirements of behavior. NEW ASSIGNED REOPENED - There is no real distinction between these states, they all generally mean "open". NEEDINFO - To owner or other person who needs to fix something or provide needed information in order for the review to proceed. MODIFIED - Owner seems to have fixed it, but it requires testing. - OPTIONAL: you don't need to use this state. It could sit in ASSIGNED where you do the same thing. This might seem confusing, but we can't stop people from using this state. Yet another thing to simplify away in the future ideal process. - *Special Case: During the Mass Review, the fix may go into rawhide and the reviewer can verify both the CVS contents and package before giving fedora-review+. CLOSED RAWHIDE - fedora-review+ is APPROVED, CVS procedure is done, and package is built and confirmed to be done. - *Special Case*: During the Mass Review, it is fine to set to CLOSED RAWHIDE if it is confirmed to be fixed there. Please use MODIFIED prior to CLOSED RAWHIDE to allow for a verification step. Review Process ============== 1. Review Request is filed fedora-review is BLANK Assigned to nobody 2. Reviewer Takes a Request fedora-review is ? Assigned to reviewer 3a. If review denied and needs work Comment fedora-review- NEEDINFO to whoever needs to fix it. 3b. fedora-review- and owner provides fix fedora-review back to ?, to request re-review 4. If APPROVED fedora-review+ 5. After fedora-review+ initiate the fedora-cvs request procedure 6. After fedora-cvs procedure (empty directories are in CVS) checkin build verify buids set to CLOSED RAWHIDE Other Possibilities =================== fedora-review? could also be used on any other Fedora bug when a horrible mess is found in an existing package, and attention for a re-review would be desired to fix it. Possible Process Optimizations ============================== Changing fedora-review to ? auto-sets Assigned pointer to self. This would require code changes to Bugzilla itself. Unclear whether this is worth doing or not. Warren Togami wtogami at redhat.com From ville.skytta at iki.fi Tue Feb 20 18:50:44 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 20 Feb 2007 20:50:44 +0200 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DB3C64.7070602@redhat.com> References: <45BE7342.1070005@redhat.com> <200702202004.15848.ville.skytta@iki.fi> <45DB3C64.7070602@redhat.com> Message-ID: <200702202050.45143.ville.skytta@iki.fi> On Tuesday 20 February 2007, Warren Togami wrote: > Ville Skytt? wrote: > > On Monday 19 February 2007, Warren Togami wrote: > >> More Branches on Existing Packages > >> ================================== > >> 1) Use existing review ticket, even if it is CLOSED, this is fine. > > > > Reusing an old review ticket results in additional traffic on the reviews > > mailing list that most recipients probably don't care about and would > > rather not receive... > > Somebody asking to change the owner of a package shouldn't be visible to > everyone else? I believe it should. I believe so too [0], but that's not what I replied to. See above, the reply was to the chapter titled "More Branches on Existing Packages". IMO there's little reason to notify everyone on fedora-package-review about additional branch requests done later (probably 2 mails per request as the flag gets toggled between states). [0] OTOH, I'm not sure about the fedora-package-review list being an appropriate way to tell everyone about package owner change requests either (a post to fedora-maintainers by a human involved would be much better), but that's not the point here, and I'm not expecting the CVS admin flags stuff to be a silver bullet to everything. From opensource at till.name Tue Feb 20 19:15:50 2007 From: opensource at till.name (Till Maas) Date: Tue, 20 Feb 2007 20:15:50 +0100 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DB3C64.7070602@redhat.com> References: <45BE7342.1070005@redhat.com> <200702202004.15848.ville.skytta@iki.fi> <45DB3C64.7070602@redhat.com> Message-ID: <200702202015.58368.opensource@till.name> On Dienstag 20 Februar 2007, Warren Togami wrote: > Ville Skytt? wrote: > > On Monday 19 February 2007, Warren Togami wrote: > >> More Branches on Existing Packages > >> ================================== > >> 1) Use existing review ticket, even if it is CLOSED, this is fine. > > > > Reusing an old review ticket results in additional traffic on the reviews > > mailing list that most recipients probably don't care about and would > > rather not receive... > > Somebody asking to change the owner of a package shouldn't be visible to > everyone else? I believe it should. Why not keep sending it to fedora-extras-commits at redhat.com like it was done before and also notify the previous owner/comaintainers and e-mail address in case of changes? Why are changes to owners.list not sent to fedora-extras-commits at redhat.com anymore? > Even if this not ideal, this sucks a LOT less than the previous process. > Using the Wiki for workflow management was just horrible. Separate > authentication system, poor tracking of who did what, completely > decoupled from the Bugzilla tickets they were referring to, requiring > more work in reading context before approving a request. We will NOT > move back to using the Wiki for a purpose like that. When you want to use Bugzilla, why not create a Product "CVS Staff" with the same Components (Packages) as Extras/Core and manage CVS requests there? Then you have everything you need but do not need to add unrelated information to the review tickets. Afaics you do not even need flags anymore because the CVS staff can query for new tickets, to see what needs to be done. 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 opensource at till.name Tue Feb 20 19:19:35 2007 From: opensource at till.name (Till Maas) Date: Tue, 20 Feb 2007 20:19:35 +0100 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB41BB.7010807@redhat.com> References: <45DB41BB.7010807@redhat.com> Message-ID: <200702202019.36147.opensource@till.name> On Dienstag 20 Februar 2007, Warren Togami wrote: > This procedure is meant to be for *BOTH* Merge and regular package > reviews. Please comment. I hope we can finally ratify something during > this Thursday's FESCO meeting. What is the advantage of using flags? -------------- 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 Tue Feb 20 19:31:17 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 14:31:17 -0500 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <200702202019.36147.opensource@till.name> References: <45DB41BB.7010807@redhat.com> <200702202019.36147.opensource@till.name> Message-ID: <45DB4C85.5020601@redhat.com> Till Maas wrote: > On Dienstag 20 Februar 2007, Warren Togami wrote: >> This procedure is meant to be for *BOTH* Merge and regular package >> reviews. Please comment. I hope we can finally ratify something during >> this Thursday's FESCO meeting. > > What is the advantage of using flags? > Using tracker bugs was unscalable when it got into the hundreds, and completely unusable with a thousand. Warren Togami wtogami at redhat.com From mtasaka at ioa.s.u-tokyo.ac.jp Tue Feb 20 19:37:42 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 21 Feb 2007 04:37:42 +0900 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB4C85.5020601@redhat.com> References: <45DB41BB.7010807@redhat.com> <200702202019.36147.opensource@till.name> <45DB4C85.5020601@redhat.com> Message-ID: <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > > Using tracker bugs was unscalable when it got into the hundreds, and > completely unusable with a thousand. > Well, this is intended to remove completely remove FE-NEW FE-NEEDSPONSOR FE-REVIEW RE-ACCEPT? Or this is intended to use both fedora-review flag and bug blocker? Mamoru From rdieter at math.unl.edu Tue Feb 20 19:41:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Feb 2007 13:41:55 -0600 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> References: <45DB41BB.7010807@redhat.com> <200702202019.36147.opensource@till.name> <45DB4C85.5020601@redhat.com> <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> Message-ID: <45DB4F03.7090607@math.unl.edu> Mamoru Tasaka wrote: > Warren Togami wrote: >> >> Using tracker bugs was unscalable when it got into the hundreds, and >> completely unusable with a thousand. >> > Well, this is intended to remove completely remove FE-NEW > FE-NEEDSPONSOR FE-REVIEW RE-ACCEPT? I'd say all except NEEDSPONSOR. -- Rex From wtogami at redhat.com Tue Feb 20 19:43:50 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 14:43:50 -0500 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> References: <45DB41BB.7010807@redhat.com> <200702202019.36147.opensource@till.name> <45DB4C85.5020601@redhat.com> <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> Message-ID: <45DB4F76.7030504@redhat.com> Mamoru Tasaka wrote: > Warren Togami wrote: >> >> Using tracker bugs was unscalable when it got into the hundreds, and >> completely unusable with a thousand. >> > Well, this is intended to remove completely remove FE-NEW > FE-NEEDSPONSOR FE-REVIEW RE-ACCEPT? Or this is intended > to use both fedora-review flag and bug blocker? > Remove the use of FE-NEW, FE-REVIEW, and FE-ACCEPT. I suppose FE-NEEDSPONSOR can stay, as we don't have a good way to replace it, and it is relatively small (thus scales reasonably well). Warren Togami wtogami at redhat.com From mtasaka at ioa.s.u-tokyo.ac.jp Tue Feb 20 19:55:53 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 21 Feb 2007 04:55:53 +0900 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB4F76.7030504@redhat.com> References: <45DB41BB.7010807@redhat.com> <200702202019.36147.opensource@till.name> <45DB4C85.5020601@redhat.com> <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> <45DB4F76.7030504@redhat.com> Message-ID: <45DB5249.2070807@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > Mamoru Tasaka wrote: >> Warren Togami wrote: >>> >>> Using tracker bugs was unscalable when it got into the hundreds, and >>> completely unusable with a thousand. >>> >> Well, this is intended to remove completely remove FE-NEW >> FE-NEEDSPONSOR FE-REVIEW RE-ACCEPT? Or this is intended >> to use both fedora-review flag and bug blocker? >> > > Remove the use of FE-NEW, FE-REVIEW, and FE-ACCEPT. Then I want the following feature. There are some cases in that one review request depends on the other review requests, or the bugs to be resolved which may be not review requests. In that case, to review the request we have to review other requests which the bug depends on beforehand. And.. even for the review requests blocked by FE-REVIEW some review requests may depend on other bugs which may not be resolved at the time. Currently, the dependency tree for FE-NEW or FE-REVIEW easily shows this. Can we check the dependency for review requests easily as before with flags? Mamoru From opensource at till.name Tue Feb 20 20:01:39 2007 From: opensource at till.name (Till Maas) Date: Tue, 20 Feb 2007 21:01:39 +0100 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB4F76.7030504@redhat.com> References: <45DB41BB.7010807@redhat.com> <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> <45DB4F76.7030504@redhat.com> Message-ID: <200702202101.54904.opensource@till.name> On Dienstag 20 Februar 2007, Warren Togami wrote: > Remove the use of FE-NEW, FE-REVIEW, and FE-ACCEPT. For this fedora-review{BLANK,?,+} would be enough and when it is not needed to change the blocking bugs anymore, it does not make it more complicated, than it is now. Is there als an advantage of using "fedora-review-" instead of only using "NEEDINFO" when someone has to do something? And does assigning to "nobody at fedoraproject.org" or the reviewer instead of using "fedora-review{BLANK,?}" and changing to "CLOSED RAWHIDE" instead of fedora-review+ not scale, too? I think it is odd to mark the state of a ticket with two ways which both need to be done manually, when only one may be sufficient. 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 Tue Feb 20 20:06:17 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 15:06:17 -0500 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <200702202101.54904.opensource@till.name> References: <45DB41BB.7010807@redhat.com> <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> <45DB4F76.7030504@redhat.com> <200702202101.54904.opensource@till.name> Message-ID: <45DB54B9.7000701@redhat.com> Till Maas wrote: > On Dienstag 20 Februar 2007, Warren Togami wrote: > >> Remove the use of FE-NEW, FE-REVIEW, and FE-ACCEPT. > > For this fedora-review{BLANK,?,+} would be enough and when it is not needed to > change the blocking bugs anymore, it does not make it more complicated, than > it is now. Is there als an advantage of using "fedora-review-" instead of > only using "NEEDINFO" when someone has to do something? And does assigning > to "nobody at fedoraproject.org" or the reviewer instead of > using "fedora-review{BLANK,?}" and changing to "CLOSED RAWHIDE" instead of Eh? > fedora-review+ not scale, too? I think it is odd to mark the state of a > ticket with two ways which both need to be done manually, when only one may > be sufficient. > fedora-review state indicates the state of the review. BLANK (not yet reviewed) ? (currently under review) - (needs work!) + (approved) Package Review APPROVED does not mean the package is done. Bugzilla CLOSED should be clear. CLOSED means the package itself is done, imported, build and tested. Yes, this still is confusing and not streamlined, but it is better than the earlier process. We are limited by the tools, and we need something NOW. *PLEASE* help us in the design and implementation of the Package Database so that we may make this even simpler in the future. Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Tue Feb 20 20:23:22 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 20 Feb 2007 21:23:22 +0100 Subject: Orphanizing the OrphanedPackages Wiki page Message-ID: <20070220212322.add7edba.bugs.michael@gmx.net> After sending this message, I won't keep an eye on the OrphanedPackages Wiki page and on orphaned packages anymore. I will also discontinue with monitoring the orphan owner in bugzilla. With the locks on owners.list and CVS it makes no sense to continue with such activities. From bugs.michael at gmx.net Tue Feb 20 20:26:12 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 20 Feb 2007 21:26:12 +0100 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB4F03.7090607@math.unl.edu> References: <45DB41BB.7010807@redhat.com> <200702202019.36147.opensource@till.name> <45DB4C85.5020601@redhat.com> <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> <45DB4F03.7090607@math.unl.edu> Message-ID: <20070220212612.2a4c7360.bugs.michael@gmx.net> On Tue, 20 Feb 2007 13:41:55 -0600, Rex Dieter wrote: > Mamoru Tasaka wrote: > > Warren Togami wrote: > >> > >> Using tracker bugs was unscalable when it got into the hundreds, and > >> completely unusable with a thousand. > >> > > Well, this is intended to remove completely remove FE-NEW > > FE-NEEDSPONSOR FE-REVIEW RE-ACCEPT? > > I'd say all except NEEDSPONSOR. Yes. FE-NEEDSPONSOR is added to tickets only temporarily. Unlike FE-ACCEPT. From bugs.michael at gmx.net Tue Feb 20 20:55:06 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 20 Feb 2007 21:55:06 +0100 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB5249.2070807@ioa.s.u-tokyo.ac.jp> References: <45DB41BB.7010807@redhat.com> <200702202019.36147.opensource@till.name> <45DB4C85.5020601@redhat.com> <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> <45DB4F76.7030504@redhat.com> <45DB5249.2070807@ioa.s.u-tokyo.ac.jp> Message-ID: <20070220215506.a6a6e84a.bugs.michael@gmx.net> On Wed, 21 Feb 2007 04:55:53 +0900, Mamoru Tasaka wrote: > > Remove the use of FE-NEW, FE-REVIEW, and FE-ACCEPT. > > Then I want the following feature. > > There are some cases in that one review request depends on > the other review requests, or the bugs to be resolved > which may be not review requests. In that case, to review > the request we have to review other requests which > the bug depends on beforehand. > And.. even for the review requests blocked by FE-REVIEW > some review requests may depend on other bugs which may > not be resolved at the time. > > Currently, the dependency tree for FE-NEW or FE-REVIEW > easily shows this. Can we check the dependency for > review requests easily as before with flags? You can still display the dependency tree for *every* ticket. But if we stop using a tracker bug, we lose the ability to show the dependency tree of the tracker bug. ;) From wtogami at redhat.com Tue Feb 20 21:08:17 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 16:08:17 -0500 Subject: Fixed: owners.list changes go to commits list Message-ID: <45DB6341.3070106@redhat.com> notting just fixed owners.list changes go to commits list. Warren From wtogami at redhat.com Tue Feb 20 21:10:01 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 16:10:01 -0500 Subject: Orphanizing the OrphanedPackages Wiki page In-Reply-To: <20070220212322.add7edba.bugs.michael@gmx.net> References: <20070220212322.add7edba.bugs.michael@gmx.net> Message-ID: <45DB63A9.1020109@redhat.com> Michael Schwendt wrote: > After sending this message, I won't keep an eye on the OrphanedPackages > Wiki page and on orphaned packages anymore. I will also discontinue with > monitoring the orphan owner in bugzilla. With the locks on owners.list > and CVS it makes no sense to continue with such activities. I believe maintaining this in two places is too much manual work in the long-term. Perhaps we should have a script that reads owners.list and to auto-generates a static page that displays the orphans? This could be written independently of anything else. http://rubenkerkhof.com/review Something like this... except generated with links to the CVS of each orphaned package. Any volunteers to write this? Pretty easy project. Warren Togami wtogami at redhat.com From mattdm at mattdm.org Tue Feb 20 21:41:06 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Feb 2007 16:41:06 -0500 Subject: wxGTK2 status and testing In-Reply-To: <20070220103918.12549d0f.bugs.michael@gmx.net> References: <20070219111646.abfa4780.bugs.michael@gmx.net> <20070219140117.GA13340@jadzia.bu.edu> <20070219152248.81038ee4.bugs.michael@gmx.net> <1171895240.5333.1.camel@scriabin.tannenrauch.ch> <20070220103918.12549d0f.bugs.michael@gmx.net> Message-ID: <20070220214106.GA9459@jadzia.bu.edu> On Tue, Feb 20, 2007 at 10:39:18AM +0100, Michael Schwendt wrote: > Anyway, I've submitted compat-wxGTK26 for review, because Audacity builds > with it and doesn't lock up and because a recent snapshot of Audacity > introduces new problems wrt audio I/O and project freq. Thanks, by the way. I was considering what to do about this in general; I'd prefer not to back out the version, but clearly 2.8 has some, er, growing pains. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From chitlesh at fedoraproject.org Tue Feb 20 21:47:24 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 20 Feb 2007 22:47:24 +0100 Subject: wxGTK2 status and testing In-Reply-To: <20070220103918.12549d0f.bugs.michael@gmx.net> References: <20070219111646.abfa4780.bugs.michael@gmx.net> <20070219140117.GA13340@jadzia.bu.edu> <20070219152248.81038ee4.bugs.michael@gmx.net> <1171895240.5333.1.camel@scriabin.tannenrauch.ch> <20070220103918.12549d0f.bugs.michael@gmx.net> Message-ID: <13dbfe4f0702201347i52ec648cx49bd031a134601bc@mail.gmail.com> On 2/20/07, Michael Schwendt wrote: > Anyway, I've submitted compat-wxGTK26 for review, because Audacity builds > with it and doesn't lock up and because a recent snapshot of Audacity > introduces new problems wrt audio I/O and project freq. Great :) Toped has been broken for some time and upstream isn't responding. I'll test those rpms and report back. Chitlesh -- http://clunixchit.blogspot.com From buildsys at fedoraproject.org Tue Feb 20 22:40:35 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 20 Feb 2007 17:40:35 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-02-20 Message-ID: <20070220224035.0486315212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) 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) sound-juicer FC6-updates > FC7 (0:2.16.3-1.fc6 > 0:2.16.2-3.fc7) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) cgoorah AT yahoo.com.au: kdmtheme FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) 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) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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: 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) 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) 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) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) limb AT jcomserv.net: gnubg FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.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 linux.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) tagoh AT redhat.com: mew FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) 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) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) 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) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) 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) 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) gnubg: limb AT jcomserv.net FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.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) kdmtheme: cgoorah AT yahoo.com.au FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) mew: tagoh AT redhat.com FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) 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 linux.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) sound-juicer: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.16.3-1.fc6 > 0:2.16.2-3.fc7) 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) 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) 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 icon at fedoraproject.org Tue Feb 20 22:41:22 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 20 Feb 2007 17:41:22 -0500 Subject: Update ReviewGuidelines Message-ID: Would someone (who has a good idea about the new procedure) update http://fedoraproject.org/wiki/Packaging/ReviewGuidelines? I'd do it, but at this point I'm very much confused, which is why I wanted to look at it in the first place. Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From Christian.Iseli at licr.org Tue Feb 20 22:44:12 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 20 Feb 2007 23:44:12 +0100 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB41BB.7010807@redhat.com> References: <45DB41BB.7010807@redhat.com> Message-ID: <20070220234412.3ff532b8@ludwig-alpha.unil.ch> On Tue, 20 Feb 2007 13:45:15 -0500, Warren Togami wrote: > This procedure is meant to be for *BOTH* Merge and regular package > reviews. Please comment. I mostly like it. My only gripe is about the toggling between fedora-review? and fedora-review- I do not think it brings much. I'd prefer the flag to stay at ? (corresponding to the FE-REVIEW state) and simply use NEEDINFO/MODIFIED BZ status if deemed necessary by the parties involved. I'd prefer the fedora-review- flag to be used in place of FE-DEADREVIEW (#201449), or some similar purpose. C From jkeating at redhat.com Tue Feb 20 22:47:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Feb 2007 17:47:44 -0500 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <20070220234412.3ff532b8@ludwig-alpha.unil.ch> References: <45DB41BB.7010807@redhat.com> <20070220234412.3ff532b8@ludwig-alpha.unil.ch> Message-ID: <200702201747.44381.jkeating@redhat.com> On Tuesday 20 February 2007 17:44, Christian Iseli wrote: > I do not think it brings much. ?I'd prefer the flag to stay at ? > (corresponding to the FE-REVIEW state) and simply use NEEDINFO/MODIFIED > BZ status if deemed necessary by the parties involved. > > I'd prefer the fedora-review- flag to be used in place of FE-DEADREVIEW > (#201449), or some similar purpose. +1 -- 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 Feb 21 00:02:10 2007 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Wed, 21 Feb 2007 00:02:10 +0000 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <200702201747.44381.jkeating@redhat.com> References: <45DB41BB.7010807@redhat.com> <20070220234412.3ff532b8@ludwig-alpha.unil.ch> <200702201747.44381.jkeating@redhat.com> Message-ID: <200702210002.10883.jamatos@fc.up.pt> On Tuesday 20 February 2007 10:47:44 pm Jesse Keating wrote: > > > > I'd prefer the fedora-review- flag to be used in place of FE-DEADREVIEW > > (#201449), or some similar purpose. > > +1 +1 -- Jos? Ab?lio From blizzard at redhat.com Wed Feb 21 01:32:09 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 20 Feb 2007 20:32:09 -0500 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB41BB.7010807@redhat.com> References: <45DB41BB.7010807@redhat.com> Message-ID: <1172021529.16219.10.camel@localhost.localdomain> Hi, Warren. I think that my only suggestion here is based on our history with the Red Hat bugzilla, which is a mess of flags and states. It turns out that flags and states, and the interactions thereof make for a terrible workflow tool. And that's what you really want, a real workflow tool. I don't know if we have the bandwith to find out and build it out and hook it up to bugzilla properly, but that has to be better than trying to teach people about the various interactions between all the states. --Chris From a.badger at gmail.com Wed Feb 21 01:59:19 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 20 Feb 2007 17:59:19 -0800 Subject: New Guideline; spec file naming Message-ID: <1172023159.4472.243.camel@localhost.localdomain> Hi all, The new spec file naming guideline was passed last week and became official today. It's basically a clarification of why the current guideline exists and includes a clause for allowing Core packages to be accepted with an alternate name under certain conditions. If you maintain a Core package that you want included in the exception, please send a note to me or the packaging committee so we can add your package to the clause. -Toshio Text of new guideline below:: == Spec file name == The spec file should be named using the %{name}.spec scheme. This is to make it easier for people to find the appropriate spec when they install a src.rpm. Example: {{{ If your package is named foo-1.0.0-1.src.rpm, then the spec file should be named foo.spec. }}} There is normally no need to include the `%{version}` in the spec file name. If you are packaging multiple versions of a package for simultaneous use, they should already reflect the version in the ` %{name}.spec` scheme (refer to [#MultiplePackages Multiple Packages with the same base name] for details). In normal cases adding the version can cause the spec file's history to be lost when a package's version is upgraded. As a special exception, there are a few packages which are allowed to have a version in their spec filename. This is because they had the version in their name when they were merged from Fedora Core's cvs and removing the version at that time would have *lost* history: * gcc * [Please ask the packaging committee to add your package if you think it should also fall under this exception.] This exception will go away when any of the following criteria are met: 1. We move the packages to a revision control system which is able to preserve history across a file rename. 2. The package spec file is going to be renamed anyway (for example, gcc41.spec is currently in cvs. When gcc is upgraded to gcc-4.2, the new spec will be created as gcc.spec '''not''' gcc42.spec) -------------- 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 Wed Feb 21 02:18:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Feb 2007 21:18:01 -0500 Subject: Fedora 7 frozen for Test 2 Message-ID: <200702202118.01175.jkeating@redhat.com> I've frozen the "Core" side of Fedora 7 for Test 2. Rawhide composes will happen from the 'f7-test2' collection. Builds from the devel/ branch continue to go to dist-fc7 and will be picked up after the freeze. If you have compelling reason to have your build included in Test2, please email rel-eng at fedoraproject.org State your package build and reasons why it should be included in Test2. That is all. -- 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 petersen at redhat.com Wed Feb 21 02:28:15 2007 From: petersen at redhat.com (Jens Petersen) Date: Wed, 21 Feb 2007 12:28:15 +1000 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <20070220234412.3ff532b8@ludwig-alpha.unil.ch> References: <45DB41BB.7010807@redhat.com> <20070220234412.3ff532b8@ludwig-alpha.unil.ch> Message-ID: <45DBAE3F.7080200@redhat.com> Christian Iseli wrote: > I'd prefer the fedora-review- flag to be used in place of FE-DEADREVIEW > (#201449), or some similar purpose. And for forbidden items too? Jens From cweyl at alumni.drew.edu Wed Feb 21 02:31:32 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 20 Feb 2007 18:31:32 -0800 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <20070220234412.3ff532b8@ludwig-alpha.unil.ch> References: <45DB41BB.7010807@redhat.com> <20070220234412.3ff532b8@ludwig-alpha.unil.ch> Message-ID: <7dd7ab490702201831l165ee5baqb864157290d3153a@mail.gmail.com> On 2/20/07, Christian Iseli wrote: > I mostly like it. My only gripe is about the toggling between > fedora-review? and fedora-review- > > I do not think it brings much. I'd prefer the flag to stay at ? > (corresponding to the FE-REVIEW state) and simply use NEEDINFO/MODIFIED > BZ status if deemed necessary by the parties involved. > > I'd prefer the fedora-review- flag to be used in place of FE-DEADREVIEW > (#201449), or some similar purpose. Strong +1. There doesn't seem to be much constantly flipping flag states can do that a judicious use of needinfo can't. -Chris -- Chris Weyl Ex astris, scientia From kevin at tummy.com Wed Feb 21 03:18:55 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Tue, 20 Feb 2007 20:18:55 -0700 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <200702210002.10883.jamatos@fc.up.pt> References: <45DB41BB.7010807@redhat.com> <20070220234412.3ff532b8@ludwig-alpha.unil.ch> <200702201747.44381.jkeating@redhat.com> <200702210002.10883.jamatos@fc.up.pt> Message-ID: <20070220201855.26986a63@ningauble.scrye.com> On Wed, 21 Feb 2007 00:02:10 +0000 jamatos at fc.up.pt (Jos? Matos) wrote: > On Tuesday 20 February 2007 10:47:44 pm Jesse Keating wrote: > > > > > > I'd prefer the fedora-review- flag to be used in place of > > > FE-DEADREVIEW (#201449), or some similar purpose. > > > > +1 > > +1 > I'll throw in another +1... this was my suggestion from one of the previous versions as well. I don't think changing the flag on most every comment has any advantage, and is likely to be forgotten by the submitter, since they are less likely to know the procedure. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wart at kobold.org Wed Feb 21 03:48:36 2007 From: wart at kobold.org (Wart) Date: Tue, 20 Feb 2007 19:48:36 -0800 Subject: packages with logwatch scripts Message-ID: <45DBC114.8060902@kobold.org> I'm starting to work on adding logwatch support to a few game daemons that I maintain, to help admins keep track of player activity. Where would be the correct place to add the logwatch scripts, and how should the Requires: be handled? choices: 1) Put the scripts and configs in the /etc/logwatch hierarchy or 2) Put the scripts and configs in the /usr/share/logwatch hierarchy and a) Require: logwatch for directory ownership or b) Don't explicitly Require: logwatch; daemons will only have logwatch support if logwatch is already present. I would prefer not to add the explicit 'Requires: logwatch', and only provide that functionality if the server admin has already installed logwatch. But this would leave the directories in 1/2 unowned. Suggestions? --Wart From wtogami at redhat.com Wed Feb 21 05:57:06 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 21 Feb 2007 00:57:06 -0500 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <1172021529.16219.10.camel@localhost.localdomain> References: <45DB41BB.7010807@redhat.com> <1172021529.16219.10.camel@localhost.localdomain> Message-ID: <45DBDF32.3080204@redhat.com> Christopher Blizzard wrote: > Hi, Warren. I think that my only suggestion here is based on our > history with the Red Hat bugzilla, which is a mess of flags and states. > It turns out that flags and states, and the interactions thereof make > for a terrible workflow tool. And that's what you really want, a real > workflow tool. I don't know if we have the bandwith to find out and > build it out and hook it up to bugzilla properly, but that has to be > better than trying to teach people about the various interactions > between all the states. > Hi Chris, We tried to create a process that was usable *now* because it would be unacceptable to block the entire project on implementing the ideal tool. I am fully aware that this only putting lipstick on a pig. But while this pig isn't gorgeous, it is at least moderately less ugly than before. The non-obviousness and complications of these flags are moderately less broken than the previous blocker bug + wiki workflow. While this interim process wont make everyone happy because it is ambiguous and non-obvious in places, it sucks less, and we can use it immediately. Meanwhile we can think hard about what exactly we want in the ideal workflow tool, and implement that fresh. It will help at that point that requisite pieces like Fedora Account System, Build System, Source Control, and Package Database will be evolving together. Armed with knowledge of our these past pigs, we have a clearer understanding of what exactly we need at that point. Warren Togami wtogami at redhat.com From wtogami at redhat.com Wed Feb 21 06:09:53 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 21 Feb 2007 01:09:53 -0500 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <20070220201855.26986a63@ningauble.scrye.com> References: <45DB41BB.7010807@redhat.com> <20070220234412.3ff532b8@ludwig-alpha.unil.ch> <200702201747.44381.jkeating@redhat.com> <200702210002.10883.jamatos@fc.up.pt> <20070220201855.26986a63@ningauble.scrye.com> Message-ID: <45DBE231.3090701@redhat.com> Kevin Fenzi wrote: > On Wed, 21 Feb 2007 00:02:10 +0000 > jamatos at fc.up.pt (Jos? Matos) wrote: > >> On Tuesday 20 February 2007 10:47:44 pm Jesse Keating wrote: >>>> I'd prefer the fedora-review- flag to be used in place of >>>> FE-DEADREVIEW (#201449), or some similar purpose. >>> +1 >> +1 >> > > I'll throw in another +1... this was my suggestion from one of the > previous versions as well. I don't think changing the flag on most > every comment has any advantage, and is likely to be forgotten by the > submitter, since they are less likely to know the procedure. > So you want: 1) FE-REVIEW to completely be equivalent to the meaning of fedora-review? 2) fedora-review- to mean, "Absolutely no, and you can't fix this to make it a yes." ? Possible reasons for denied fedora-review flag: - The package is unacceptable and the submitter is unwilling to fix it. - The package contains something that is forbidden. I suppose this might work. I might be a little concerned that folks interpret fedora-review- to be the Version 5 meaning though, only because the interface makes it non-obvious if you haven't read that in documentation. I'm tired of working on the pig. If people are happy with this, let's just use it until we can get rid of this process. I hope FESCO can ratify *something* this week Thursday. Warren Togami wtogami at redhat.com From wtogami at redhat.com Wed Feb 21 06:11:24 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 21 Feb 2007 01:11:24 -0500 Subject: Update ReviewGuidelines In-Reply-To: References: Message-ID: <45DBE28C.5010405@redhat.com> Konstantin Ryabitsev wrote: > Would someone (who has a good idea about the new procedure) update > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines? > > I'd do it, but at this point I'm very much confused, which is why I > wanted to look at it in the first place. > > Cheers, The documentation has not been updated yet because we've been arguing for too long about what exactly the review process should be changed to. Then FESCO decided that FESCO should ratify any process change. That might happen on Thursday, I hope... Warren From j.w.r.degoede at hhs.nl Wed Feb 21 07:29:14 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 21 Feb 2007 08:29:14 +0100 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB41BB.7010807@redhat.com> References: <45DB41BB.7010807@redhat.com> Message-ID: <45DBF4CA.30105@hhs.nl> Warren Togami wrote: > This procedure is meant to be for *BOTH* Merge and regular package > reviews. Please comment. I hope we can finally ratify something during > this Thursday's FESCO meeting. > > Changes since Version 4: > ======================== > - ASSIGNED to nobody if there is no reviewer yet. > - ASSIGNED remains on reviewer thereafter. > - Use NEEDINFO if someone other than the reviewer needs to take action. > > Fedora Review Flag States > ========================= > fedora-review BLANK > I want a review, or a past reviewer gave up. > fedora-review? > Under Review, ASSIGNED to reviewer > fedora-review- > Denied and needs work, NEEDINFO to owner > fedora-review+ > APPROVED, ASSIGNED to reviewer > > Assigned Pointer > ================ > - Assigned pointer to nobody at fedoraproject.org if no reviewer yet. > - Assigned pointer to reviewer, during and after the review. > > Bugzilla States > =============== > In practice a bug sitting in these states matter less than the state of > the fedora-review flag. Participants are to follow these states as > suggested guidelines, but the fedora-review flag has the hard > requirements of behavior. > > NEW ASSIGNED REOPENED > - There is no real distinction between these states, they all generally > mean "open". > > NEEDINFO > - To owner or other person who needs to fix something or provide needed > information in order for the review to proceed. > > MODIFIED > - Owner seems to have fixed it, but it requires testing. > - OPTIONAL: you don't need to use this state. It could sit in ASSIGNED > where you do the same thing. This might seem confusing, but we can't > stop people from using this state. Yet another thing to simplify away > in the future ideal process. > - *Special Case: During the Mass Review, the fix may go into rawhide and > the reviewer can verify both the CVS contents and package before giving > fedora-review+. > why is this one optional but need info not? To me fedora-review- and NEEDINFO should only be used if there is a dispute / things are moving slow, normally a review can have quite a few quickly following eachother comments where the reviewer and submitter work things out I still see no use in this PING PONG-ing of the status and fedora-review flag, this has been mentioned by me and several others several times, why is no one listening or atleast a response is geiven explaining what the perceived advantage of using NEEDINFO is, even if the review is going smoothly. Even better make the NEEDINFO fedora-review- step optional. To me fedora-review- should be used with CLOSED WONTFIX if the package is denied forever (for example if the license is no good) and NEEDINFO should be used as it always is in bugzilla. > Review Process > ============== > 1. Review Request is filed > fedora-review is BLANK > Assigned to nobody > 2. Reviewer Takes a Request > fedora-review is ? > Assigned to reviewer > 3a. If review denied and needs work > Comment > fedora-review- > NEEDINFO to whoever needs to fix it. > 3b. fedora-review- and owner provides fix > fedora-review back to ?, to request re-review Can we PLEASE make step 3a and 3b optional, I only see extra mouse clicks with little added value here. > 4. If APPROVED > fedora-review+ > 5. After fedora-review+ > initiate the fedora-cvs request procedure > 6. After fedora-cvs procedure (empty directories are in CVS) > checkin > build > verify buids > set to CLOSED RAWHIDE > Regards, Hans From j.w.r.degoede at hhs.nl Wed Feb 21 07:31:34 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 21 Feb 2007 08:31:34 +0100 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <20070220234412.3ff532b8@ludwig-alpha.unil.ch> References: <45DB41BB.7010807@redhat.com> <20070220234412.3ff532b8@ludwig-alpha.unil.ch> Message-ID: <45DBF556.10300@hhs.nl> Christian Iseli wrote: > On Tue, 20 Feb 2007 13:45:15 -0500, Warren Togami wrote: >> This procedure is meant to be for *BOTH* Merge and regular package >> reviews. Please comment. > > I mostly like it. My only gripe is about the toggling between > fedora-review? and fedora-review- > > I do not think it brings much. I'd prefer the flag to stay at ? > (corresponding to the FE-REVIEW state) and simply use NEEDINFO/MODIFIED > BZ status if deemed necessary by the parties involved. > > I'd prefer the fedora-review- flag to be used in place of FE-DEADREVIEW > (#201449), or some similar purpose. > +1, if not +100, this toggling between fedora-review? and fedora-review- is totally unnecesarry as heen be said by me and several others several times already, why o why is noone listening, or atleast explaining why this is actually necessary? Regards, Hans From j.w.r.degoede at hhs.nl Wed Feb 21 07:35:35 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 21 Feb 2007 08:35:35 +0100 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DBE231.3090701@redhat.com> References: <45DB41BB.7010807@redhat.com> <20070220234412.3ff532b8@ludwig-alpha.unil.ch> <200702201747.44381.jkeating@redhat.com> <200702210002.10883.jamatos@fc.up.pt> <20070220201855.26986a63@ningauble.scrye.com> <45DBE231.3090701@redhat.com> Message-ID: <45DBF647.9040500@hhs.nl> Warren Togami wrote: > Kevin Fenzi wrote: >> On Wed, 21 Feb 2007 00:02:10 +0000 >> jamatos at fc.up.pt (Jos? Matos) wrote: >> >>> On Tuesday 20 February 2007 10:47:44 pm Jesse Keating wrote: >>>>> I'd prefer the fedora-review- flag to be used in place of >>>>> FE-DEADREVIEW (#201449), or some similar purpose. >>>> +1 >>> +1 >>> >> >> I'll throw in another +1... this was my suggestion from one of the >> previous versions as well. I don't think changing the flag on most >> every comment has any advantage, and is likely to be forgotten by the >> submitter, since they are less likely to know the procedure. > > So you want: > 1) FE-REVIEW to completely be equivalent to the meaning of fedora-review? > 2) fedora-review- to mean, "Absolutely no, and you can't fix this to > make it a yes." ? > > Possible reasons for denied fedora-review flag: > - The package is unacceptable and the submitter is unwilling to fix it. > - The package contains something that is forbidden. > Yes exactly, except that there will ofcourse an exception or 2 to the absolutely no, like upstream changing the license into something suitable, but that can easily be handled by replacing the fedora-review- with fedora-review? again. Think of fedora-review- as FE_DEADREVIEW > I'm tired of working on the pig. If people are happy with this, let's > just use it until we can get rid of this process. I hope FESCO can > ratify *something* this week Thursday. > (Speaking for myself) I think we are all tired and you did a great job! Except for the mandatory toggling between fedora-review- and fedora-review? Actually the last few weeks I've actually submitted a couple of new packages and these were reviewed using the new process without the toggling and it works like a charm. Regards, Hans From Christian.Iseli at licr.org Wed Feb 21 07:54:49 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 21 Feb 2007 08:54:49 +0100 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DBAE3F.7080200@redhat.com> References: <45DB41BB.7010807@redhat.com> <20070220234412.3ff532b8@ludwig-alpha.unil.ch> <45DBAE3F.7080200@redhat.com> Message-ID: <20070221085449.72ee5b88@ludwig-alpha.unil.ch> On Wed, 21 Feb 2007 12:28:15 +1000, Jens Petersen wrote: > And for forbidden items too? yes C From Christian.Iseli at licr.org Wed Feb 21 08:02:58 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 21 Feb 2007 09:02:58 +0100 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DBE231.3090701@redhat.com> References: <45DB41BB.7010807@redhat.com> <20070220234412.3ff532b8@ludwig-alpha.unil.ch> <200702201747.44381.jkeating@redhat.com> <200702210002.10883.jamatos@fc.up.pt> <20070220201855.26986a63@ningauble.scrye.com> <45DBE231.3090701@redhat.com> Message-ID: <20070221090258.1426d337@ludwig-alpha.unil.ch> On Wed, 21 Feb 2007 01:09:53 -0500, Warren Togami wrote: > So you want: > 1) FE-REVIEW to completely be equivalent to the meaning of fedora-review? yes > 2) fedora-review- to mean, "Absolutely no, and you can't fix this to > make it a yes." ? yes > Possible reasons for denied fedora-review flag: > - The package is unacceptable and the submitter is unwilling to fix it. > - The package contains something that is forbidden. yes Many examples block FE-DEADREVIEW C From paul at city-fan.org Wed Feb 21 09:16:14 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 21 Feb 2007 09:16:14 +0000 Subject: wxGTK2 status and testing In-Reply-To: <13dbfe4f0702201347i52ec648cx49bd031a134601bc@mail.gmail.com> References: <20070219111646.abfa4780.bugs.michael@gmx.net> <20070219140117.GA13340@jadzia.bu.edu> <20070219152248.81038ee4.bugs.michael@gmx.net> <1171895240.5333.1.camel@scriabin.tannenrauch.ch> <20070220103918.12549d0f.bugs.michael@gmx.net> <13dbfe4f0702201347i52ec648cx49bd031a134601bc@mail.gmail.com> Message-ID: <1172049374.4239.12.camel@metropolis.intra.city-fan.org> On Tue, 2007-02-20 at 22:47 +0100, Chitlesh GOORAH wrote: > On 2/20/07, Michael Schwendt wrote: > > Anyway, I've submitted compat-wxGTK26 for review, because Audacity builds > > with it and doesn't lock up and because a recent snapshot of Audacity > > introduces new problems wrt audio I/O and project freq. > > Great :) Toped has been broken for some time and upstream isn't > responding. I'll test those rpms and report back. Is anybody considering doing a compat-wxPython26 package? Paul. From belegdol at gmail.com Wed Feb 21 11:50:00 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Wed, 21 Feb 2007 11:50:00 +0000 Subject: Fedora 7 frozen for Test 2 In-Reply-To: <200702202118.01175.jkeating@redhat.com> References: <200702202118.01175.jkeating@redhat.com> Message-ID: <9b1b20e70702210350r39e2db84r2c39956b69f44287@mail.gmail.com> And how about Extras? Can the builds be requested as usual, or shall I wait until the defrost? 2007/2/21, Jesse Keating : > I've frozen the "Core" side of Fedora 7 for Test 2. Rawhide composes will > happen from the 'f7-test2' collection. Builds from the devel/ branch > continue to go to and will be picked up after the freeze. If you > have compelling reason to have your build included in Test2, please email > rel-eng at fedoraproject.org State your package build and reasons why it should > be included in Test2. > > That is all. > > -- > Jesse Keating > Release Engineer: Fedora > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > > > From jkeating at redhat.com Wed Feb 21 12:55:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 07:55:36 -0500 Subject: Fedora 7 frozen for Test 2 In-Reply-To: <9b1b20e70702210350r39e2db84r2c39956b69f44287@mail.gmail.com> References: <200702202118.01175.jkeating@redhat.com> <9b1b20e70702210350r39e2db84r2c39956b69f44287@mail.gmail.com> Message-ID: <200702210755.39843.jkeating@redhat.com> On Wednesday 21 February 2007 06:50, Julian Sikorski wrote: > And how about Extras? Can the builds be requested as usual, or shall I > wait until the defrost? Since we aren't merged I'll leave it up to the extras pushers as to whether or not they do any pushes, or targetted pushes of specific packages. I'd prefer it stays frozen so that we can get a consistant tree for composing, I haven't done any dep checking with what would be on the Classic spin to know if there are currently problems. That will be today. Extras build requests should be able to continue, it's all about what is made available to the public. -- 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 SteveD at redhat.com Wed Feb 21 13:15:26 2007 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 21 Feb 2007 08:15:26 -0500 Subject: Where is Conga? Message-ID: <45DC45EE.3000602@RedHat.com> Is Conga not part of Fedora Core? I have a number people looking for a open UI that will manage NFSv4 namespaces, something that Conga would be perfect for... So can I tell people Conga will be part of FC7? steved. From jbowes at redhat.com Wed Feb 21 13:24:04 2007 From: jbowes at redhat.com (James Bowes) Date: Wed, 21 Feb 2007 08:24:04 -0500 Subject: Where is Conga? In-Reply-To: <45DC45EE.3000602@RedHat.com> References: <45DC45EE.3000602@RedHat.com> Message-ID: <45DC47F4.70809@redhat.com> Steve Dickson wrote: > Is Conga not part of Fedora Core? The review[1] seems to have stalled, waiting on the submitter. -James [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197137 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From Axel.Thimm at ATrpms.net Wed Feb 21 13:29:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 21 Feb 2007 14:29:06 +0100 Subject: Where is Conga? In-Reply-To: <45DC45EE.3000602@RedHat.com> References: <45DC45EE.3000602@RedHat.com> Message-ID: <20070221132906.GI7699@neu.nirvana> On Wed, Feb 21, 2007 at 08:15:26AM -0500, Steve Dickson wrote: > Is Conga not part of Fedora Core? > > I have a number people looking for a open UI that will manage NFSv4 > namespaces, something that Conga would be perfect for... So can I > tell people Conga will be part of FC7? > > steved. Stanko Kupcevic (Cc'd) maintains it for RHEL5, so maybe he wants to submit it to Fedora? -- 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 Wed Feb 21 14:08:21 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 21 Feb 2007 15:08:21 +0100 Subject: Fedora 7 frozen for Test 2 In-Reply-To: <200702210755.39843.jkeating@redhat.com> References: <200702202118.01175.jkeating@redhat.com> <9b1b20e70702210350r39e2db84r2c39956b69f44287@mail.gmail.com> <200702210755.39843.jkeating@redhat.com> Message-ID: <20070221150821.e5d42899.bugs.michael@gmx.net> On Wed, 21 Feb 2007 07:55:36 -0500, Jesse Keating wrote: > On Wednesday 21 February 2007 06:50, Julian Sikorski wrote: > > And how about Extras? Can the builds be requested as usual, or shall I > > wait until the defrost? > > Since we aren't merged I'll leave it up to the extras pushers as to whether or > not they do any pushes, or targetted pushes of specific packages. I'd prefer > it stays frozen so that we can get a consistant tree for composing, I haven't > done any dep checking with what would be on the Classic spin to know if there > are currently problems. That will be today. Extras build requests should be > able to continue, it's all about what is made available to the public. We have the code to push individual packages, but no user interface to make use of it. It would need some work, e.g. a separate script takes pkg names as input instead of just dist names. So, if there is anything new we want to do this time, we'd better talk about it. From jkeating at redhat.com Wed Feb 21 14:10:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 09:10:59 -0500 Subject: Where is Conga? In-Reply-To: <45DC45EE.3000602@RedHat.com> References: <45DC45EE.3000602@RedHat.com> Message-ID: <200702210911.02729.jkeating@redhat.com> On Wednesday 21 February 2007 08:15, Steve Dickson wrote: > Is Conga not part of Fedora Core? > > I have a number people looking for a open UI that will > manage NFSv4 namespaces, something that Conga would > be perfect for... So can I tell people Conga will be > part of FC7? Well, there is no "Core" anymore. It's just Fedora 7, and whatever makes it through the review process and into the repository will be a part of Fedora. Whether or not it makes it onto one of the spins we do is a different matter, and one that isn't very clear right now. Of course, it will wind up on the monster EVERYTHING spin, but that isn't very significant. -- 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 mattdm at mattdm.org Wed Feb 21 14:49:31 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 21 Feb 2007 09:49:31 -0500 Subject: wxGTK2 status and testing In-Reply-To: <1172049374.4239.12.camel@metropolis.intra.city-fan.org> References: <20070219111646.abfa4780.bugs.michael@gmx.net> <20070219140117.GA13340@jadzia.bu.edu> <20070219152248.81038ee4.bugs.michael@gmx.net> <1171895240.5333.1.camel@scriabin.tannenrauch.ch> <20070220103918.12549d0f.bugs.michael@gmx.net> <13dbfe4f0702201347i52ec648cx49bd031a134601bc@mail.gmail.com> <1172049374.4239.12.camel@metropolis.intra.city-fan.org> Message-ID: <20070221144931.GA18171@jadzia.bu.edu> On Wed, Feb 21, 2007 at 09:16:14AM +0000, Paul Howarth wrote: > > Great :) Toped has been broken for some time and upstream isn't > > responding. I'll test those rpms and report back. > Is anybody considering doing a compat-wxPython26 package? One thing I'd be concerned about is that upstream wxPython only tracks the very latest wxWidgets (and in fact, often gets ahead of the officially released branch, although the wxPython developer is also a wxWidgets developer). This means wxPython 2.6.x is effectively unmaintained upstream. That may or may not be an issue, but it may end up easier overall to work to get problems fixed in 2.8.x. (Following the "upstream! upstream!" mantra.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kupcevic at redhat.com Wed Feb 21 14:55:29 2007 From: kupcevic at redhat.com (Stan Kupcevic) Date: Wed, 21 Feb 2007 09:55:29 -0500 Subject: Where is Conga? In-Reply-To: <20070221132906.GI7699@neu.nirvana> References: <45DC45EE.3000602@RedHat.com> <20070221132906.GI7699@neu.nirvana> Message-ID: <45DC5D61.70902@redhat.com> Axel Thimm wrote: >On Wed, Feb 21, 2007 at 08:15:26AM -0500, Steve Dickson wrote: > > >>Is Conga not part of Fedora Core? >> >>I have a number people looking for a open UI that will manage NFSv4 >>namespaces, something that Conga would be perfect for... So can I >>tell people Conga will be part of FC7? >> >> Conga will be in FC7; inclusion process is about to be initiated. >>steved. >> >> > >Stanko Kupcevic (Cc'd) maintains it for RHEL5, > Conga is a part of RHEL4.5 as well. >so maybe he wants to >submit it to Fedora? > > CC'ing the rest of devel team... - stan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jparsons at redhat.com Wed Feb 21 16:12:12 2007 From: jparsons at redhat.com (James Parsons) Date: Wed, 21 Feb 2007 11:12:12 -0500 Subject: Where is Conga? In-Reply-To: <45DC47F4.70809@redhat.com> References: <45DC45EE.3000602@RedHat.com> <45DC47F4.70809@redhat.com> Message-ID: <45DC6F5C.8010602@redhat.com> James Bowes wrote: >Steve Dickson wrote: > > >>Is Conga not part of Fedora Core? >> >> > >The review[1] seems to have stalled, waiting on the submitter. > >-James > >[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197137 > > > >------------------------------------------------------------------------ > >-- >Fedora-maintainers mailing list >Fedora-maintainers at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-maintainers > > This last issue was addressed by the Conga team. Nothing ever went forward from there. I own the Conga package. Please, what exactly do I need to do to get it reviewed and in? Where do I begin, please? I know the process has seen quite a bit of churn lately, and I have had my head down working on Conga. Where do I start? File a BZ ticket? -Jim From SteveD at redhat.com Wed Feb 21 16:16:40 2007 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 21 Feb 2007 11:16:40 -0500 Subject: Where is Conga? In-Reply-To: <45DC6F5C.8010602@redhat.com> References: <45DC45EE.3000602@RedHat.com> <45DC47F4.70809@redhat.com> <45DC6F5C.8010602@redhat.com> Message-ID: <45DC7068.40408@RedHat.com> James Parsons wrote: > James Bowes wrote: > >> Steve Dickson wrote: >> >> >>> Is Conga not part of Fedora Core? >>> >> >> The review[1] seems to have stalled, waiting on the submitter. >> >> -James >> >> [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197137 >> >> >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-maintainers mailing list >> Fedora-maintainers at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-maintainers >> >> > This last issue was addressed by the Conga team. Nothing ever went > forward from there. > > I own the Conga package. Please, what exactly do I need to do to get it > reviewed and in? Where do I begin, please? I know the process has seen > quite a bit of churn lately, and I have had my head down working on Conga. > > Where do I start? File a BZ ticket? https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Core&format=core-review steved. From tibbs at math.uh.edu Wed Feb 21 16:18:19 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Feb 2007 10:18:19 -0600 Subject: Where is Conga? In-Reply-To: <45DC6F5C.8010602@redhat.com> References: <45DC45EE.3000602@RedHat.com> <45DC47F4.70809@redhat.com> <45DC6F5C.8010602@redhat.com> Message-ID: >>>>> "JP" == James Parsons writes: JP> I own the Conga package. Please, what exactly do I need to do to JP> get it reviewed and in? Where do I begin, please? I know the JP> process has seen quite a bit of churn lately, and I have had my JP> head down working on Conga. Don't worry about the process. There's already a ticket open, with a reviewer attached: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197137 The process died because the package failed to build and the package submitter (which seems to be you) never replied to that or submitted any new packages. So start by making some fresh packages and posting links to them in that ticket. At worst the reviewer will decide he doesn't want to continue reviewing and someone else will take over. - J< From fedora at leemhuis.info Wed Feb 21 18:47:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Feb 2007 19:47:15 +0100 Subject: Small heads up: Discussion around EPEL now on fedora-devel Message-ID: <45DC93B3.9080004@leemhuis.info> Hi, just a heads up on this lists (?) -- I posted some thoughts about EPEL and the way forward to fedora-devel list; see https://www.redhat.com/archives/fedora-devel-list/2007-February/msg01085.html for details. Please participate in that discussion there if you are interested. tia! CU thl (?) -- ohh boy, this mailing list mess really needs to be sorted out soon -- it gets more and more annoying. I'm still waiting for feedback from some redhat guys how we actually want to move on regarding the serer side for mailman (own server? seperate domain for fedora? leave everything as it is and just kleen up the lists) before we can move on... From jwilson at redhat.com Wed Feb 21 18:55:42 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 21 Feb 2007 13:55:42 -0500 Subject: FLAC update broke vorbis-tools In-Reply-To: <1171885780.28561.3.camel@bnocera.surrey.redhat.com> References: <883cfe6d0702170908k47634e46w6a964e607d7b098b@mail.gmail.com> <1171885780.28561.3.camel@bnocera.surrey.redhat.com> Message-ID: <45DC95AE.3040604@redhat.com> Bastien Nocera wrote: > On Sat, 2007-02-17 at 12:08 -0500, Michel Salim wrote: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229124 >> >> The V-Day edition of vorbis-tools does not have FLAC playback support. >> Perhaps when getting it to build against libogg instead of libOggFLAC >> the linking against libFLAC got clobbered as well? > > Probably just needs a rebuild. I'll do that now. There was a fairly massive api change between flac 1.1.2 (the version in fc6) and flac 1.1.3 (flac 1.1.4 is now in rawhide). I doubt if just rebuilding will fix it. http://flac.sourceforge.net/api/group__porting.html http://flac.sourceforge.net/api/group__porting__1__1__2__to__1__1__3.html Its really not too bad though, mostly just FLAC__seekable_stream_decoder* -> FLAC__stream_decoder* type things. Far more fun if you're trying to support both APIs with the same code base though. For reference, see: http://svn.mythtv.org/trac/ticket/2957 -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From overholt at redhat.com Wed Feb 21 20:31:13 2007 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 21 Feb 2007 15:31:13 -0500 Subject: http://fedoraproject.org/wiki/Rawhide Message-ID: <20070221203112.GK29321@redhat.com> Hi, I created $subj today but it needs fleshing out. I know things will be changing with the new merged world, but I didn't want to let that stop me. I created the page after a discussion I had with some people internally about participating in Fedora and how it was hard to find information about rawhide. They wanted to know how one can install rawhide, whether there were nightly composes, how they could help with testing, etc. Feel free to add stuff to the page, tear it apart, delete it, or whatever :). 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 notting at redhat.com Wed Feb 21 20:34:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Feb 2007 15:34:06 -0500 Subject: http://fedoraproject.org/wiki/Rawhide In-Reply-To: <20070221203112.GK29321@redhat.com> References: <20070221203112.GK29321@redhat.com> Message-ID: <20070221203406.GB6837@nostromo.devel.redhat.com> Andrew Overholt (overholt at redhat.com) said: > Feel free to add stuff to the page, tear it apart, delete it, or > whatever :). Heh. Moved under the Releases/ section, doing some editing. Bill From overholt at redhat.com Wed Feb 21 21:08:46 2007 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 21 Feb 2007 16:08:46 -0500 Subject: Rawhide stability Message-ID: <20070221210846.GM29321@redhat.com> Hi, For a while I've been thinking about rawhide stability. I know we all love to say how it eats babies and it's really easy to tell someone "I told you so" when they try rawhide and complain that it's broken. But I'd like to start a discussion about whether or not it's possible --or even worth it -- to maintain a relatively stable rawhide (and yes, I realize the term and/or the situation may be changing with the merge). I work on Eclipse stuff and one of the key features of the development of Eclipse is that things should be continuously consumable. Nightly builds are done and large test suites are run daily. The results are always available and I've heard some people who weren't previously involved with any open source projects say that "Open source is public humiliation" :) . People try hard to ensure that things are always buildable and while things aren't always perfect, weekly builds are almost always at least testable. You can read more about this process at the links at the bottom. I can hear you now: "This is an unfair comparison; we don't have giant test suites and it's not even possible to test everything in the distro working together!" And you're right: it _is_ a completely unfair comparison. And please don't think I'm picking on the kernel - 'cause I'm not. But I want to see what good parts of the Eclipse development process we can bring over to Fedora. For example, how do we expect users to help out with testing if rawhide is regularly in a completely unusable state? Is there something we can do to drive towards more continuous stability? Is this even possible? Should we instead focus on making more frequent (weekly?) releases in between actual test releases? Are better tools (such as a better bug tracking system, a better delivery mechanism, more effective communication media, a better means of working with different upstream projects, etc.) the answer to more stability? Can we achieve stability while still pushing the latest technology? Am I completely nuts for attempting to draw any comparisons between Eclipse and Fedora? I look forward to people's thoughts on these issues. Andrew Just a few samples describing some of the Eclipse processes: http://eclipsecon.org/2005/presentations/econ2005-eclipse-way.pdf http://blogs.zdnet.com/Burnette/?p=43 http://blogs.zdnet.com/Burnette/?p=113 http://www.eclipsezone.com/eclipse/forums/t20805.html -------------- 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 Feb 21 21:24:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 16:24:31 -0500 Subject: Rawhide stability In-Reply-To: <20070221210846.GM29321@redhat.com> References: <20070221210846.GM29321@redhat.com> Message-ID: <200702211624.34769.jkeating@redhat.com> On Wednesday 21 February 2007 16:08, Andrew Overholt wrote: > For example, how do we expect users to help out with testing if rawhide > is regularly in a completely unusable state? ?Is there something we can > do to drive towards more continuous stability? ?Is this even possible? > Should we instead focus on making more frequent (weekly?) releases in > between actual test releases? ?Are better tools (such as a better bug > tracking system, a better delivery mechanism, more effective > communication media, a better means of working with different upstream > projects, etc.) the answer to more stability? ?Can we achieve stability > while still pushing the latest technology? ?Am I completely nuts for > attempting to draw any comparisons between Eclipse and Fedora? > > I look forward to people's thoughts on these issues. The biggest problems are almost always broken deps. That's just the nature of things, different parts get built at different times, and a cron job just pushes whatever mess is currently there out. There was talk of doing recursive depsolving and removing parts of the push that would break deps, but then what lands in rawhide isn't the same as what is in the buildroots, plus somethings may never go out and see the light of day if we do this. Not to mention compose time would skyrocket :/ -- 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 sgrubb at redhat.com Wed Feb 21 21:23:42 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 21 Feb 2007 16:23:42 -0500 Subject: Rawhide stability In-Reply-To: <20070221210846.GM29321@redhat.com> References: <20070221210846.GM29321@redhat.com> Message-ID: <200702211623.42699.sgrubb@redhat.com> On Wednesday 21 February 2007 16:08:46 Andrew Overholt wrote: > I look forward to people's thoughts on these issues. People should do some testing with their packages. It should install with no %post errors at a minimum. It should not cause avcs when installing, it should have files in state that selinux agrees with, and not create files/directories on install that are not listed in the manifest. These can easily all be checked. Maybe we should have some tests run after a build against the new package? The above problems are not specific to any one package and easily scripted. Other than that, I hate to see any restrictions on rawhide. -Steve From dakingun at gmail.com Wed Feb 21 21:26:09 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Wed, 21 Feb 2007 16:26:09 -0500 Subject: Rawhide stability In-Reply-To: <20070221210846.GM29321@redhat.com> References: <20070221210846.GM29321@redhat.com> Message-ID: > > For example, how do we expect users to help out with testing if rawhide > is regularly in a completely unusable state? Is there something we can In my experience, rawhide is most (>95%) of the time usable, although it is more often non-installable due to package dependencies issues. I've been using rawhide on one of my systems since FC5 era. Deji From mattdm at mattdm.org Wed Feb 21 21:29:46 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 21 Feb 2007 16:29:46 -0500 Subject: Rawhide stability In-Reply-To: References: <20070221210846.GM29321@redhat.com> Message-ID: <20070221212946.GA5497@jadzia.bu.edu> On Wed, Feb 21, 2007 at 04:26:09PM -0500, Deji Akingunola wrote: > >For example, how do we expect users to help out with testing if rawhide > >is regularly in a completely unusable state? Is there something we can > In my experience, rawhide is most (>95%) of the time usable, although > it is more often non-installable due to package dependencies issues. > I've been using rawhide on one of my systems since FC5 era. I've been using it as my main desktop system since FC6-test-something, and while there's occasionally a glitch, nothing that's kept me from working. Primarily, I have to update manually and often have to exclude some broken deps. Other than that, works for me. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Wed Feb 21 21:32:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 16:32:07 -0500 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB41BB.7010807@redhat.com> References: <45DB41BB.7010807@redhat.com> Message-ID: <200702211632.07284.jkeating@redhat.com> On Tuesday 20 February 2007 13:45, Warren Togami wrote: > ????????initiate the fedora-cvs request procedure What initiates this step? Where is this step defined? I see a flag for fedora_cvs, what should it be set to? -- 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 Feb 21 21:32:03 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 21 Feb 2007 16:32:03 -0500 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <200702211632.07284.jkeating@redhat.com> References: <45DB41BB.7010807@redhat.com> <200702211632.07284.jkeating@redhat.com> Message-ID: <45DCBA53.6060108@redhat.com> Jesse Keating wrote: > On Tuesday 20 February 2007 13:45, Warren Togami wrote: >> initiate the fedora-cvs request procedure > > What initiates this step? Where is this step defined? I see a flag for > fedora_cvs, what should it be set to? > The "CVS Admin with Flags" procedure was ratified by FESCO earlier because it was less controversial. http://fedoraproject.org/wiki/Extras/CVSSyncNeeded The old CVS procedure used to point people here, but now they are pointed at http://fedoraproject.org/wiki/CVSAdminProcedure Warren Togami wtogami at redhat.com From jkeating at redhat.com Wed Feb 21 21:45:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 16:45:42 -0500 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DCBA53.6060108@redhat.com> References: <45DB41BB.7010807@redhat.com> <200702211632.07284.jkeating@redhat.com> <45DCBA53.6060108@redhat.com> Message-ID: <200702211645.42960.jkeating@redhat.com> On Wednesday 21 February 2007 16:32, Warren Togami wrote: > The "CVS Admin with Flags" procedure was ratified by FESCO earlier > because it was less controversial. > > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded > The old CVS procedure used to point people here, but now they are pointed > at > > http://fedoraproject.org/wiki/CVSAdminProcedure Can you link to it from your proposed steps so that all the information is somewhat viewable in one place? (: -- 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 roland at redhat.com Wed Feb 21 21:44:48 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 21 Feb 2007 13:44:48 -0800 (PST) Subject: Rawhide stability In-Reply-To: Matthew Miller's message of Wednesday, 21 February 2007 16:29:46 -0500 <20070221212946.GA5497@jadzia.bu.edu> Message-ID: <20070221214448.C682B1800E4@magilla.sf.frob.com> > Primarily, I have to update manually and often have to exclude some broken > deps. This would be greatly aided if yum had a "smallest usable transaction" mode. That is, instead of always doing one giant upgrade that barfs if there are dependency problems, it would take each update available and suck in only its necessary deps as if you'd done "yum upgrade foobar" on the individual package, finish that, and then do the next transaction. When some packages have dependency problems, they get punted but not everything else unrelated. So instead of either "wait for a day when yum upgrade works" or "mess around manually a lot", every day has an "easily upgrade what upgrades easily" option. From sundaram at fedoraproject.org Wed Feb 21 21:52:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Feb 2007 03:22:20 +0530 Subject: Rawhide stability In-Reply-To: <20070221214448.C682B1800E4@magilla.sf.frob.com> References: <20070221214448.C682B1800E4@magilla.sf.frob.com> Message-ID: <45DCBF14.80704@fedoraproject.org> Roland McGrath wrote: >> Primarily, I have to update manually and often have to exclude some broken >> deps. > > This would be greatly aided if yum had a "smallest usable transaction" > mode. That is, instead of always doing one giant upgrade that barfs if > there are dependency problems, it would take each update available and suck > in only its necessary deps as if you'd done "yum upgrade foobar" on the > individual package, finish that, and then do the next transaction. When > some packages have dependency problems, they get punted but not everything > else unrelated. So instead of either "wait for a day when yum upgrade works" > or "mess around manually a lot", every day has an "easily upgrade what > upgrades easily" option. # yum install yum-skip-broken and use the --skip-broken parameter. Rahul From giallu at gmail.com Wed Feb 21 22:04:35 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 21 Feb 2007 23:04:35 +0100 Subject: Rawhide stability In-Reply-To: <45DCBF14.80704@fedoraproject.org> References: <20070221214448.C682B1800E4@magilla.sf.frob.com> <45DCBF14.80704@fedoraproject.org> Message-ID: On 2/21/07, Rahul Sundaram wrote: > # yum install yum-skip-broken and use the --skip-broken parameter. > So the question turns to be: if we already have it, why don't we ship and enable it by default? From chris.stone at gmail.com Wed Feb 21 22:10:26 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 21 Feb 2007 14:10:26 -0800 Subject: Rawhide stability In-Reply-To: References: <20070221214448.C682B1800E4@magilla.sf.frob.com> <45DCBF14.80704@fedoraproject.org> Message-ID: On 2/21/07, Gianluca Sforna wrote: > On 2/21/07, Rahul Sundaram wrote: > > # yum install yum-skip-broken and use the --skip-broken parameter. > > > > So the question turns to be: if we already have it, why don't we ship > and enable it by default? I also have another question: Why is it required to add --skip-broken? I would think that if you went through all the trouble to install this plugin, then you probably want this feature to run by default. From roland at redhat.com Wed Feb 21 22:11:26 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 21 Feb 2007 14:11:26 -0800 (PST) Subject: Rawhide stability In-Reply-To: Rahul Sundaram's message of Thursday, 22 February 2007 03:22:20 +0530 <45DCBF14.80704@fedoraproject.org> Message-ID: <20070221221126.B9C741800E4@magilla.sf.frob.com> > # yum install yum-skip-broken and use the --skip-broken parameter. My hero! A "smallest possible transaction" mode would still make me happier for rawhide upgrades. I have too many times had the giant yum upgrade not have any dep problems, but have some %post error or kernel crash in the middle, that left me with an unholy mess of half-upgraded crap to sort out (usually both versions of a billion rpms in the db, with the files maybe from the new one or maybe still some files from the old one, etc). If each transaction were only as big as it needed to be to be coherent, with the rpm database written in a clear state, then the incremental damage done at any instance of crashing in the middle would be much more manageable. Thanks, Roland From giallu at gmail.com Wed Feb 21 22:19:34 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 21 Feb 2007 23:19:34 +0100 Subject: Rawhide stability In-Reply-To: <20070221221126.B9C741800E4@magilla.sf.frob.com> References: <45DCBF14.80704@fedoraproject.org> <20070221221126.B9C741800E4@magilla.sf.frob.com> Message-ID: On 2/21/07, Roland McGrath wrote: > > # yum install yum-skip-broken and use the --skip-broken parameter. > > My hero! A "smallest possible transaction" mode would still make me > happier for rawhide upgrades. I have too many times had the giant yum > upgrade not have any dep problems, but have some %post error or kernel > crash in the middle, that left me with an unholy mess of half-upgraded crap > to sort out (usually both versions of a billion rpms in the db, with the > files maybe from the new one or maybe still some files from the old one, > etc). That's why I always upgrade kernel in its own transaction. Maybe there is another plugin for this... From bnocera at redhat.com Wed Feb 21 23:03:45 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 21 Feb 2007 23:03:45 +0000 Subject: FLAC update broke vorbis-tools In-Reply-To: <45DC95AE.3040604@redhat.com> References: <883cfe6d0702170908k47634e46w6a964e607d7b098b@mail.gmail.com> <1171885780.28561.3.camel@bnocera.surrey.redhat.com> <45DC95AE.3040604@redhat.com> Message-ID: <1172099025.3760.14.camel@cookie.hadess.net> On Wed, 2007-02-21 at 13:55 -0500, Jarod Wilson wrote: > Bastien Nocera wrote: > > On Sat, 2007-02-17 at 12:08 -0500, Michel Salim wrote: > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229124 > >> > >> The V-Day edition of vorbis-tools does not have FLAC playback support. > >> Perhaps when getting it to build against libogg instead of libOggFLAC > >> the linking against libFLAC got clobbered as well? > > > > Probably just needs a rebuild. I'll do that now. > > There was a fairly massive api change between flac 1.1.2 (the version in > fc6) and flac 1.1.3 (flac 1.1.4 is now in rawhide). I doubt if just > rebuilding will fix it. I already talked to Conrad Parker and Mike Smith about it, and we should have a vorbis-tools release with support for the new API soonish. In the meanwhile, no FLAC support, which is better than no vorbis-tools... Cheers From bugs.michael at gmx.net Wed Feb 21 23:27:47 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 22 Feb 2007 00:27:47 +0100 Subject: Fedora 7 frozen for Test 2 In-Reply-To: <20070221150821.e5d42899.bugs.michael@gmx.net> References: <200702202118.01175.jkeating@redhat.com> <9b1b20e70702210350r39e2db84r2c39956b69f44287@mail.gmail.com> <200702210755.39843.jkeating@redhat.com> <20070221150821.e5d42899.bugs.michael@gmx.net> Message-ID: <20070222002747.09891981.bugs.michael@gmx.net> On Wed, 21 Feb 2007 15:08:21 +0100, Michael Schwendt wrote: > On Wed, 21 Feb 2007 07:55:36 -0500, Jesse Keating wrote: > > > On Wednesday 21 February 2007 06:50, Julian Sikorski wrote: > > > And how about Extras? Can the builds be requested as usual, or shall I > > > wait until the defrost? > > > > Since we aren't merged I'll leave it up to the extras pushers as to whether or > > not they do any pushes, or targetted pushes of specific packages. I'd prefer > > it stays frozen so that we can get a consistant tree for composing, I haven't > > done any dep checking with what would be on the Classic spin to know if there > > are currently problems. That will be today. Extras build requests should be > > able to continue, it's all about what is made available to the public. > > We have the code to push individual packages, but no user interface to > make use of it. It would need some work, e.g. a separate script takes pkg > names as input instead of just dist names. So, if there is anything new we > want to do this time, we'd better talk about it. As a follow-up here, freezing Extras development and pushing individual packages is possible now. Small changes to the pushscript which can easily be disabled again. From bpepple at fedoraproject.org Wed Feb 21 23:33:19 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 21 Feb 2007 18:33:19 -0500 Subject: Plan for tomorrows (20070222) FESCO meeting Message-ID: <1172100799.25639.5.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-meeting on irc.freenode.org: /topic FESCO-Meeting -- EPEL -- thl -- okay for everybody if the EPEL-SIGs works more on its own and reports to FESCo /topic FESCO-Meeting -- Core Package Review Process -- warren /topic FESCO-Meeting -- Encourage co-maintainership -- thl /topic FESCO-Meeting -- sponsor nominations -- Parag Ashok Nemade, Andrew Overholt, Thomas Fitzsimmons, Chitlesh Goorah, Fernando Nasser /topic FESCO-Meeting -- MISC -- cvs-import changes /topic FESCO-Meeting -- MISC -- Extras 7 preparation /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCo meeting -- Free discussion around Fedora Extras 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... BTW: Sorry, I haven't written up a summary of last weeks meeting, but real-life intruded on my fedora time this week. I'll try to finish it up tomorrow. 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 wtogami at redhat.com Thu Feb 22 00:14:23 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 21 Feb 2007 19:14:23 -0500 Subject: Plan for tomorrows (20070222) FESCO meeting In-Reply-To: <1172100799.25639.5.camel@Chuck> References: <1172100799.25639.5.camel@Chuck> Message-ID: <45DCE05F.5040103@redhat.com> Brian Pepple wrote: > > /topic FESCO-Meeting -- MISC -- cvs-import changes > cvs-import.sh Safety Issues =========================== - Discourage cvs-import if this is not the initial import into empty directories? - Force the user to type a custom import message? Always? Or only if they are replacing stuff? - Force the user to see a cvs diff? cvs-import.sh and the new CVS Admin Process =========================================== Is it obvious enough what to do when you start out with empty directories in a new package? Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Thu Feb 22 00:22:02 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 22 Feb 2007 01:22:02 +0100 Subject: Plan for tomorrows (20070222) FESCO meeting In-Reply-To: <1172100799.25639.5.camel@Chuck> References: <1172100799.25639.5.camel@Chuck> Message-ID: <20070222012202.6cab4334.bugs.michael@gmx.net> On Wed, 21 Feb 2007 18:33:19 -0500, Brian Pepple wrote: > /topic FESCO-Meeting -- MISC -- Extras 7 preparation - freeze up to test2 release or not? - problems related to automatic comps.xml updates during freeze? - roadmap after test2? - bug reports about long-time broken deps in Extras development? From mattdm at mattdm.org Thu Feb 22 00:52:25 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 21 Feb 2007 19:52:25 -0500 Subject: Rawhide stability In-Reply-To: <45DCBF14.80704@fedoraproject.org> References: <20070221214448.C682B1800E4@magilla.sf.frob.com> <45DCBF14.80704@fedoraproject.org> Message-ID: <20070222005225.GA20418@jadzia.bu.edu> On Thu, Feb 22, 2007 at 03:22:20AM +0530, Rahul Sundaram wrote: > >or "mess around manually a lot", every day has an "easily upgrade what > >upgrades easily" option. > # yum install yum-skip-broken and use the --skip-broken parameter. For reasons I've yet to bother to figure out, this plugin only solves part of the problem -- I usually have to *also* exclude things manually. (Or more often, it's like this: "what, ekiga is causing some sort of conflict preventing an upgrade? I don't even ever *use* ekiga on this machine. `yum remove ekiga`".) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu Feb 22 01:40:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 20:40:15 -0500 Subject: Fedora 7 frozen for Test 2 In-Reply-To: <20070222002747.09891981.bugs.michael@gmx.net> References: <200702202118.01175.jkeating@redhat.com> <20070221150821.e5d42899.bugs.michael@gmx.net> <20070222002747.09891981.bugs.michael@gmx.net> Message-ID: <200702212040.19251.jkeating@redhat.com> On Wednesday 21 February 2007 18:27, Michael Schwendt wrote: > As a follow-up here, freezing Extras development and pushing individual > packages is possible now. Small changes to the pushscript which can easily > be disabled again. Thanks Michael. Would you like to be added to the rel-eng at fp.o alias to catch push requests for Extras 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 fedora at leemhuis.info Thu Feb 22 06:16:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Feb 2007 07:16:37 +0100 Subject: http://fedoraproject.org/wiki/Rawhide In-Reply-To: <20070221203112.GK29321@redhat.com> References: <20070221203112.GK29321@redhat.com> Message-ID: <45DD3545.5060403@leemhuis.info> On 21.02.2007 21:31, Andrew Overholt wrote: > I created $subj today but it needs fleshing out. I know things will be > changing with the new merged world, but I didn't want to let that stop > me. Isn't $subj in parts already covered by http://www.fedoraproject.org/wiki/Testing Maybe the new and the old page should should be merged? And I thought we don't call our development tree "rawhide" anymore in public (not sure on that)? CU thl From fedora at leemhuis.info Thu Feb 22 07:25:59 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Feb 2007 08:25:59 +0100 Subject: Discourage cvs-import (was: Re: Plan for tomorrows (20070222) FESCO meeting) In-Reply-To: <45DCE05F.5040103@redhat.com> References: <1172100799.25639.5.camel@Chuck> <45DCE05F.5040103@redhat.com> Message-ID: <45DD4587.2050700@leemhuis.info> On 22.02.2007 01:14, Warren Togami wrote: > Brian Pepple wrote: >> /topic FESCO-Meeting -- MISC -- cvs-import changes > cvs-import.sh Safety Issues > =========================== > - Discourage cvs-import if this is not the initial import into empty > directories? FESCo IIRC (there was no public summary of the meeting afaik) agreed on the FUDCon 2007 meeting to discourage the use of cvs-import and thus remove the section that describes its use from the wiki (e.g. http://www.fedoraproject.org/wiki/Extras/UsingCvsFaq ). The discussion further settled on "it would be nice if someone improves the cvs-import script to force users to look at a diff before the import. But if nobody works on this lets ignore the problem for a little bit longer, as we probably get a new VCS in less then one year anyway -- when doing that switch make sure users get a diff presented". Is that roughly correct? If yes: is there anything else that needs to be discussed? Or did I miss anything? CU thl From fedora at camperquake.de Thu Feb 22 10:04:16 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 22 Feb 2007 11:04:16 +0100 Subject: Rawhide stability In-Reply-To: References: <20070221210846.GM29321@redhat.com> Message-ID: <20070222110416.4b0a9d0a@banea.int.addix.net> Hi. On Wed, 21 Feb 2007 16:26:09 -0500, Deji Akingunola wrote: > In my experience, rawhide is most (>95%) of the time usable, although > it is more often non-installable due to package dependencies issues. > I've been using rawhide on one of my systems since FC5 era. I have to second that. I am running rawhide on my desktop and my notebook since the RH9->FC1 transistion, and I would not do that if the systems were not usable most of the time. Stuff breaks, of course, I had to recover from bad kernels and/or bad glibcs, but that's life in rawhide. I can not speak about the installability of rawhide, as I quite seldom do that. From denis at poolshark.org Thu Feb 22 10:38:10 2007 From: denis at poolshark.org (Denis Leroy) Date: Thu, 22 Feb 2007 11:38:10 +0100 Subject: Rawhide stability In-Reply-To: References: <20070221214448.C682B1800E4@magilla.sf.frob.com> <45DCBF14.80704@fedoraproject.org> Message-ID: <45DD7292.2010807@poolshark.org> Christopher Stone wrote: > On 2/21/07, Gianluca Sforna wrote: >> On 2/21/07, Rahul Sundaram wrote: >> > # yum install yum-skip-broken and use the --skip-broken parameter. >> > >> >> So the question turns to be: if we already have it, why don't we ship >> and enable it by default? > > I also have another question: > Why is it required to add --skip-broken? I would think that if you > went through all the trouble to install this plugin, then you probably > want this feature to run by default. +1 From tmraz at redhat.com Thu Feb 22 10:48:42 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 22 Feb 2007 11:48:42 +0100 Subject: Heads up for login managers In-Reply-To: <1171071170.2935.63.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> Message-ID: <1172141322.3134.27.camel@perun.kabelta.loc> On Fri, 2007-02-09 at 20:32 -0500, David Zeuthen wrote: > Hey, > > The major chunk of fast-user-switching has landed in Rawhide and as such > if a desktop session requires non-trival services from HAL the login > manager launching the session needs to be patched to poke ConsoleKit. > I've filed a tracking bug for this > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228110 > Also are we really sure that all login-like programs should call ConsoleKit directly and not through a PAM module? (See my and Karel Zak's concerns in the bug report.) -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From aph at redhat.com Thu Feb 22 11:01:00 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 22 Feb 2007 11:01:00 +0000 Subject: Rawhide stability In-Reply-To: <20070221210846.GM29321@redhat.com> References: <20070221210846.GM29321@redhat.com> Message-ID: <17885.30700.246665.365413@zebedee.pink> Andrew Overholt writes: > For a while I've been thinking about rawhide stability. I know we > all love to say how it eats babies and it's really easy to tell > someone "I told you so" when they try rawhide and complain that > it's broken. But I'd like to start a discussion about whether or > not it's possible --or even worth it -- to maintain a relatively > stable rawhide (and yes, I realize the term and/or the situation > may be changing with the merge). I think this is probably a mistake. Let's imagine that we improve the stability of Rawhide. The only way to do that is to raise the bar so that unstable packages are excluded. So, with Rawhide now stable there will be no place to put unstable packages for testing. What will happen then? People need to get unstable packages tested, so they have somehow to be distributed. Either people will put RPMs up on web sites, or someone will have to invent Rawerhide. And then we'd be back in the same position, but with Rawerhide substituted for Rawhide. > Can we achieve stability while still pushing the latest technology? By definition, no. If you wait for it to be stable it's no longer the latest technology. It's not called the "bleeding edge" for nothing. Note that I'm not saying that our processes can't be improved! And I certainly am not advocating a cavalier attitude to testing packages. But I am saying that we have to accept that developers and packagers aren't perfect, and mistakes will be made as part of our drive to improve the software that we ship. Rawhide is an important part of the way that we ensure that those mistakes aren't still present when we make a release. Andrew. From bugs.michael at gmx.net Thu Feb 22 12:07:13 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 22 Feb 2007 13:07:13 +0100 Subject: Fedora 7 frozen for Test 2 In-Reply-To: <200702212040.19251.jkeating@redhat.com> References: <200702202118.01175.jkeating@redhat.com> <20070221150821.e5d42899.bugs.michael@gmx.net> <20070222002747.09891981.bugs.michael@gmx.net> <200702212040.19251.jkeating@redhat.com> Message-ID: <20070222130713.5b7a87d1.bugs.michael@gmx.net> On Wed, 21 Feb 2007 20:40:15 -0500, Jesse Keating wrote: > On Wednesday 21 February 2007 18:27, Michael Schwendt wrote: > > As a follow-up here, freezing Extras development and pushing individual > > packages is possible now. Small changes to the pushscript which can easily > > be disabled again. > > Thanks Michael. Would you like to be added to the rel-eng at fp.o alias to catch > push requests for Extras packages? It's an entirely unknown and undocumented procedure for Extras packagers to send a mail to that address. Further, we haven't freezed Extras before. In case we want to try it for test2, what are the guidelines for including packages during the freeze? Is it a hard/strict freeze? Is this documented for Core anywhere? From jkeating at redhat.com Thu Feb 22 12:12:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 22 Feb 2007 07:12:26 -0500 Subject: Fedora 7 frozen for Test 2 In-Reply-To: <20070222130713.5b7a87d1.bugs.michael@gmx.net> References: <200702202118.01175.jkeating@redhat.com> <200702212040.19251.jkeating@redhat.com> <20070222130713.5b7a87d1.bugs.michael@gmx.net> Message-ID: <200702220712.30578.jkeating@redhat.com> On Thursday 22 February 2007 07:07, Michael Schwendt wrote: > It's an entirely unknown and undocumented procedure for Extras packagers > to send a mail to that address. Ditto for Core, but I'm trying to open the rel-eng process up a bit and I added some folks outside of rel-eng to that alias to help with making decisions. > Further, we haven't freezed Extras before. Correct. > In case we want to try it for > test2, what are the guidelines for including packages during the freeze? > Is it a hard/strict freeze? Is this documented for Core anywhere? It isn't well documented, something I need to add to my RelEng page on the wiki. Basically we take things that fix broken deps (so long as they don't further break other deps, or the new build doesn't work somehow), we take things that fix crashbugs like wont start at all, or crash if a user clicks this common thing. Mostly it's maintainers stating their case as to why their build needs to be included in the Test release, and those of us on the rel-eng alias would make a decision as to if we want it in or not. -- 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 Thu Feb 22 15:37:34 2007 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 22 Feb 2007 10:37:34 -0500 Subject: Rawhide stability In-Reply-To: <20070221210846.GM29321@redhat.com> References: <20070221210846.GM29321@redhat.com> Message-ID: <20070222153734.GA388@redhat.com> Thanks for your thoughts, everyone. I'm glad rawhide stability isn't an issue. I'm also in agreement that we shouldn't impose limits or anything which will slow down progress bleeding-edge-ness. Andrew -------------- 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 Thu Feb 22 16:18:14 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 22 Feb 2007 17:18:14 +0100 Subject: Heads up for login managers In-Reply-To: <1172141322.3134.27.camel@perun.kabelta.loc> References: <1171071170.2935.63.camel@zelda.fubar.dk> <1172141322.3134.27.camel@perun.kabelta.loc> Message-ID: <20070222161814.GB5617@free.fr> On Thu, Feb 22, 2007 at 11:48:42AM +0100, Tomas Mraz wrote: > > > Also are we really sure that all login-like programs should call > ConsoleKit directly and not through a PAM module? (See my and Karel > Zak's concerns in the bug report.) I am personally convinced that the ConsoleKit session opening should be done in a APM module. I said some reasons above in the thread. -- Pat From bpepple at fedoraproject.org Thu Feb 22 16:04:46 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 22 Feb 2007 11:04:46 -0500 Subject: FESCo Meeting Summary for 2007-02-15 Message-ID: <1172160286.12386.5.camel@Chuck> Sorry for the delay in getting this out, I've been buried with work the last week. :( Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (ch4chris) * Tom Callaway (spot) * Warren Togami (warren) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Jesse Keating (f13) * Jeremy Katz (jeremy) Absent * Andreas Bierfert (awjb) * Josh Boyer (jwb) == Summary == Core/Extras Merge * FESCo ratified the CVS administration with flags proposal. * warren is going to continue working on the core package review procedures, and the plan is for FESCo to vote on it at the 2007-02-22 meeting. * notting brought up a proposed change to owners.list, which would list multiple owners in the owners section. FESCo approved this change. Sponsor Nominations * rvolkal was nominated and accepted. Packaging Committee Report * FESCo didn't have any objections to the Packaging Committee's guidelines regarding: * Jpackage naming policy * spec file naming clarification For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070215 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 mtasaka at ioa.s.u-tokyo.ac.jp Thu Feb 22 17:14:56 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 23 Feb 2007 02:14:56 +0900 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DB4F76.7030504@redhat.com> References: <45DB41BB.7010807@redhat.com> <200702202019.36147.opensource@till.name> <45DB4C85.5020601@redhat.com> <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> <45DB4F76.7030504@redhat.com> Message-ID: <45DDCF90.3020905@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > Mamoru Tasaka wrote: >> Warren Togami wrote: >>> >>> Using tracker bugs was unscalable when it got into the hundreds, and >>> completely unusable with a thousand. >>> >> Well, this is intended to remove completely FE-NEW >> FE-NEEDSPONSOR FE-REVIEW RE-ACCEPT? Or this is intended >> to use both fedora-review flag and bug blocker? >> > > Remove the use of FE-NEW, FE-REVIEW, and FE-ACCEPT. Well, I submitted a new review request (hyperestraire: bz 229647) just a few hours ago and I noticed now that the bug didn't block FE-NEW. So for now I manually made the bug block FE-NEW. I see some newest review requests now not blocking FE-NEW. Did this change silently (without some notification)? Mamoru From ajackson at redhat.com Thu Feb 22 17:17:02 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 22 Feb 2007 12:17:02 -0500 Subject: Discourage cvs-import (was: Re: Plan for tomorrows (20070222) FESCO meeting) In-Reply-To: <45DD4587.2050700@leemhuis.info> References: <1172100799.25639.5.camel@Chuck> <45DCE05F.5040103@redhat.com> <45DD4587.2050700@leemhuis.info> Message-ID: <1172164622.5602.1.camel@localhost.localdomain> On Thu, 2007-02-22 at 08:25 +0100, Thorsten Leemhuis wrote: > On 22.02.2007 01:14, Warren Togami wrote: > > Brian Pepple wrote: > >> /topic FESCO-Meeting -- MISC -- cvs-import changes > > cvs-import.sh Safety Issues > > =========================== > > - Discourage cvs-import if this is not the initial import into empty > > directories? > > FESCo IIRC (there was no public summary of the meeting afaik) agreed on > the FUDCon 2007 meeting to discourage the use of cvs-import and thus > remove the section that describes its use from the wiki (e.g. > http://www.fedoraproject.org/wiki/Extras/UsingCvsFaq ). The discussion > further settled on "it would be nice if someone improves the cvs-import > script to force users to look at a diff before the import. But if nobody > works on this lets ignore the problem for a little bit longer, as we > probably get a new VCS in less then one year anyway -- when doing that > switch make sure users get a diff presented". Please at least don't break cvs-import.sh for non-initial commits. It's _way_ more pleasant to use when updating tarballs than make upload or make new-source. - ajax From jdennis at redhat.com Thu Feb 22 17:48:41 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 22 Feb 2007 12:48:41 -0500 Subject: Discourage cvs-import (was: Re: Plan for tomorrows (20070222) FESCO meeting) In-Reply-To: <1172164622.5602.1.camel@localhost.localdomain> References: <1172100799.25639.5.camel@Chuck> <45DCE05F.5040103@redhat.com> <45DD4587.2050700@leemhuis.info> <1172164622.5602.1.camel@localhost.localdomain> Message-ID: <1172166521.1641.65.camel@finch.boston.redhat.com> > Please at least don't break cvs-import.sh for non-initial commits. It's > _way_ more pleasant to use when updating tarballs than make upload or > make new-source. +1 cvs-import is the most sane way to update an rpm when we are upstream. There are quite a few rpm's for which we are the upstream and importing into 'dist cvs' is just the final step after preparing a new release. I really don't want some tool forcing me to review the changes I just made to make sure I approve of my own work. -- 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 fedora at leemhuis.info Thu Feb 22 18:01:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 22 Feb 2007 19:01:52 +0100 Subject: Discourage cvs-import In-Reply-To: <1172166521.1641.65.camel@finch.boston.redhat.com> References: <1172100799.25639.5.camel@Chuck> <45DCE05F.5040103@redhat.com> <45DD4587.2050700@leemhuis.info> <1172164622.5602.1.camel@localhost.localdomain> <1172166521.1641.65.camel@finch.boston.redhat.com> Message-ID: <45DDDA90.3050900@leemhuis.info> John Dennis schrieb: >> Please at least don't break cvs-import.sh for non-initial commits. It's >> _way_ more pleasant to use when updating tarballs than make upload or >> make new-source. > +1 > cvs-import is the most sane way to update an rpm when we are upstream. > There are quite a few rpm's for which we are the upstream and importing > into 'dist cvs' is just the final step after preparing a new release. I > really don't want some tool forcing me to review the changes I just made > to make sure I approve of my own work. It seems it wasn't clear in my mail: cvs-import.sh would still be there, just not documented in the wiki. So those that know about it can just continue to use it. CU thl From buildsys at fedoraproject.org Thu Feb 22 19:22:46 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 22 Feb 2007 14:22:46 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-02-22 Message-ID: <20070222192246.B3BBF15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) screen FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) bruno AT postle.net: vigra FE5 > FE7 (0:1.5.0-2.fc5 > 0:1.4.0-4.fc6) FE6 > FE7 (0:1.5.0-2.fc6 > 0:1.4.0-4.fc6) cgoorah AT yahoo.com.au: kdmtheme FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) 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) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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: 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) 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) gemi AT bluewin.ch: gauche-gl FE6 > FE7 (0:0.4.3-2.fc6 > 0:0.4.3-1.fc7) gauche-gtk FE6 > FE7 (0:0.4.1-11.fc6 > 0:0.4.1-10.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) kevin AT tummy.com: leafnode FE6 > FE7 (0:1.11.5-4.fc6 > 0:1.11.5-3.fc7) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lemenkov AT gmail.com: fuse FE5 > FE7 (0:2.6.3-2.fc5 > 0:2.6.3-1.fc7) FE6 > FE7 (0:2.6.3-2.fc6 > 0:2.6.3-1.fc7) limb AT jcomserv.net: gnubg FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.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 linux.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) tagoh AT redhat.com: mew FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) 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) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) 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) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) 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) fuse: lemenkov AT gmail.com FE5 > FE7 (0:2.6.3-2.fc5 > 0:2.6.3-1.fc7) FE6 > FE7 (0:2.6.3-2.fc6 > 0:2.6.3-1.fc7) gauche-gl: gemi AT bluewin.ch FE6 > FE7 (0:0.4.3-2.fc6 > 0:0.4.3-1.fc7) gauche-gtk: gemi AT bluewin.ch FE6 > FE7 (0:0.4.1-11.fc6 > 0:0.4.1-10.fc7) 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) gnubg: limb AT jcomserv.net FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.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) kdmtheme: cgoorah AT yahoo.com.au FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) leafnode: kevin AT tummy.com FE6 > FE7 (0:1.11.5-4.fc6 > 0:1.11.5-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) mew: tagoh AT redhat.com FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) 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 linux.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.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) 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) vigra: bruno AT postle.net FE5 > FE7 (0:1.5.0-2.fc5 > 0:1.4.0-4.fc6) FE6 > FE7 (0:1.5.0-2.fc6 > 0:1.4.0-4.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) 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 wtogami at redhat.com Thu Feb 22 21:02:25 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 22 Feb 2007 16:02:25 -0500 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DDCF90.3020905@ioa.s.u-tokyo.ac.jp> References: <45DB41BB.7010807@redhat.com> <200702202019.36147.opensource@till.name> <45DB4C85.5020601@redhat.com> <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> <45DB4F76.7030504@redhat.com> <45DDCF90.3020905@ioa.s.u-tokyo.ac.jp> Message-ID: <45DE04E1.5040403@redhat.com> Mamoru Tasaka wrote: >> Remove the use of FE-NEW, FE-REVIEW, and FE-ACCEPT. > > Well, I submitted a new review request (hyperestraire: bz 229647) > just a few hours ago and I noticed now that the bug didn't block > FE-NEW. So for now I manually made the bug block FE-NEW. > > I see some newest review requests now not blocking FE-NEW. Did this > change silently (without some notification)? > Irrelevant now, FESCO in today's meeting ratified the new process. For now leave FE trackers as-is, they will be auto-migrated to equivalent fedora-review flag states later. Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Feb 22 21:05:23 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 22 Feb 2007 16:05:23 -0500 Subject: Discourage cvs-import In-Reply-To: <1172166521.1641.65.camel@finch.boston.redhat.com> References: <1172100799.25639.5.camel@Chuck> <45DCE05F.5040103@redhat.com> <45DD4587.2050700@leemhuis.info> <1172164622.5602.1.camel@localhost.localdomain> <1172166521.1641.65.camel@finch.boston.redhat.com> Message-ID: <45DE0593.7030203@redhat.com> John Dennis wrote: >> Please at least don't break cvs-import.sh for non-initial commits. It's >> _way_ more pleasant to use when updating tarballs than make upload or >> make new-source. > > +1 > > cvs-import is the most sane way to update an rpm when we are upstream. > There are quite a few rpm's for which we are the upstream and importing > into 'dist cvs' is just the final step after preparing a new release. I > really don't want some tool forcing me to review the changes I just made > to make sure I approve of my own work. You aren't the type of people that we want to guard against. We want to guard against: - people checking stuff in, blindly blowing away whatever might be there. (in cases where other people might have added fixes) - checking stuff in that did not even have a cursory sanity check of "cvs diff" that often catches stupid mistakes. I don't think we should break cvs-import.sh for non-initial commits, but instead discourage its use unless the user really knows what they are doing. Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Feb 22 21:05:52 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 22 Feb 2007 16:05:52 -0500 Subject: Discourage cvs-import In-Reply-To: <45DDDA90.3050900@leemhuis.info> References: <1172100799.25639.5.camel@Chuck> <45DCE05F.5040103@redhat.com> <45DD4587.2050700@leemhuis.info> <1172164622.5602.1.camel@localhost.localdomain> <1172166521.1641.65.camel@finch.boston.redhat.com> <45DDDA90.3050900@leemhuis.info> Message-ID: <45DE05B0.6020600@redhat.com> Thorsten Leemhuis wrote: > John Dennis schrieb: >>> Please at least don't break cvs-import.sh for non-initial commits. It's >>> _way_ more pleasant to use when updating tarballs than make upload or >>> make new-source. >> +1 >> cvs-import is the most sane way to update an rpm when we are upstream. >> There are quite a few rpm's for which we are the upstream and importing >> into 'dist cvs' is just the final step after preparing a new release. I >> really don't want some tool forcing me to review the changes I just made >> to make sure I approve of my own work. > > It seems it wasn't clear in my mail: cvs-import.sh would still be there, > just not documented in the wiki. So those that know about it can just > continue to use it. > Not documented in the Wiki even for initial imports? Warren From wtogami at redhat.com Thu Feb 22 22:47:13 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 22 Feb 2007 17:47:13 -0500 Subject: RATIFIED: Review with Flags (Version 6) Message-ID: <45DE1D71.7020300@redhat.com> Thursday, February 22nd, 2007 FESCO ratified this as the new package review process for *ALL* reviews. This includes both Merge Reviews and New Package Reviews. Next I need to find all places in the Wiki that need updating... STOP USING THE TRACKER BUGS. Just leave them as-is. FESCO is thinking about what to do about them during next week's meeting. Changes since Version 5: ======================== - fedora-review- is equivalent to FE-DEADPACKAGE. Only set to - if the package cannot be fixed and thus is no longer in consideration for reviews. Possible reasons may include: - license or other legal problems - other reasons that cannot be solved soon - fedora-review? is equivalent to FE-REVIEW. Use this for any review in process. If you ask the owner to make changes, keep it set to ?, and use NEEDINFO on the owner. - fedora-review+ is equivalent to FE-ACCEPT Fedora Review Flag States ========================= fedora-review BLANK I want a review, or a past reviewer gave up. fedora-review? Under Review, ASSIGNED to reviewer fedora-review- This review cannot proceed, dropped for legal or other issues. fedora-review+ APPROVED, ASSIGNED to reviewer Assigned Pointer ================ - Assigned pointer to nobody at fedoraproject.org if no reviewer yet. - Assigned pointer to reviewer, during and after the review. Bugzilla States =============== In practice a bug sitting in these states matter less than the state of the fedora-review flag. Participants are to follow these states as suggested guidelines, but the fedora-review flag has the hard requirements of behavior. NEW ASSIGNED REOPENED - There is no real distinction between these states, they all generally mean "open". NEEDINFO - To owner or other person who needs to fix something or provide needed information in order for the review to proceed. MODIFIED - Owner seems to have fixed it, but it requires testing. - OPTIONAL: you don't need to use this state. It could sit in ASSIGNED where you do the same thing. This might seem confusing, but we can't stop people from using this state. Yet another thing to simplify away in the future ideal process. I'm sorry if you're upset about this. - *Special Case: During the Mass Review, the fix may go into rawhide and the reviewer can verify both the CVS contents and package before giving fedora-review+. CLOSED RAWHIDE - fedora-review+ is APPROVED, CVS procedure is done, and package is built and confirmed to be done. - *Special Case*: During the Mass Review, it is fine to set to CLOSED RAWHIDE if it is confirmed to be fixed there. Please consider using MODIFIED prior to CLOSED RAWHIDE to allow for a verification step. Review Process ============== 1. Review Request is filed fedora-review is BLANK Assigned to nobody 2. Reviewer Takes a Request fedora-review is ? Assigned to reviewer 3a. If review denied and needs work Comment NEEDINFO to whoever needs to fix it. 3b. NEEDINFO, owner provides fix Undo NEEDINFO status 4. If APPROVED fedora-review+ 5. After fedora-review+ initiate the fedora-cvs request procedure http://fedoraproject.org/wiki/CVSAdminProcedure 6. After fedora-cvs procedure (empty directories are in CVS) checkin build verify buids set to CLOSED RAWHIDE Other Possibilities =================== fedora-review? could also be used on any other Fedora bug when a horrible mess is found in an existing package, and attention for a re-review would be desired to fix it. Warren Togami wtogami at redhat.com From buildsys at fedoraproject.org Thu Feb 22 22:48:20 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 22 Feb 2007 17:48:20 -0500 (EST) Subject: Package EVR problems in FC+FE 2007-02-22 Message-ID: <20070222224820.27A6D15212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): boost FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) dbus FC6-updates > FC7 (0:1.0.1-9.fc6 > 0:1.0.1-3.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) screen FC5-updates > FC6-updates (0:4.0.3-2 > 0:4.0.3-1.fc6) systemtap FC6-updates > FC7 (0:0.5.12-1.fc6 > 0:0.5.10-1.fc7) bruno AT postle.net: vigra FE5 > FE7 (0:1.5.0-2.fc5 > 0:1.4.0-4.fc6) FE6 > FE7 (0:1.5.0-2.fc6 > 0:1.4.0-4.fc6) cgoorah AT yahoo.com.au: kdmtheme FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) 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) dennis AT ausil.us: knetworkmanager FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.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: 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) 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) gemi AT bluewin.ch: gauche-gl FE6 > FE7 (0:0.4.3-2.fc6 > 0:0.4.3-1.fc7) gauche-gtk FE6 > FE7 (0:0.4.1-11.fc6 > 0:0.4.1-10.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) kevin AT tummy.com: leafnode FE6 > FE7 (0:1.11.5-4.fc6 > 0:1.11.5-3.fc7) kushaldas AT gmail.com: kphotobymail FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) lemenkov AT gmail.com: fuse FE5 > FE7 (0:2.6.3-2.fc5 > 0:2.6.3-1.fc7) FE6 > FE7 (0:2.6.3-2.fc6 > 0:2.6.3-1.fc7) limb AT jcomserv.net: gnubg FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.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 linux.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) tagoh AT redhat.com: mew FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) 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) wart AT kobold.org: sear FE6 > FE7 (0:0.6.3-3.fc6 > 0:0.6.3-2.fc7) ---------------------------------------------------------------------- boost: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.33.1-11.fc6 > 0:1.33.1-10.fc7) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) 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) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) 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) fuse: lemenkov AT gmail.com FE5 > FE7 (0:2.6.3-2.fc5 > 0:2.6.3-1.fc7) FE6 > FE7 (0:2.6.3-2.fc6 > 0:2.6.3-1.fc7) gauche-gl: gemi AT bluewin.ch FE6 > FE7 (0:0.4.3-2.fc6 > 0:0.4.3-1.fc7) gauche-gtk: gemi AT bluewin.ch FE6 > FE7 (0:0.4.1-11.fc6 > 0:0.4.1-10.fc7) 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) gnubg: limb AT jcomserv.net FE5 > FE6 (0:20061119-8.fc5.2 > 0:20061119-7.fc6) FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.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) kdmtheme: cgoorah AT yahoo.com.au FE5 > FE7 (0:1.1.2-5.fc5 > 0:1.1.2-4.fc7) FE6 > FE7 (0:1.1.2-5.fc6 > 0:1.1.2-4.fc7) knetworkmanager: dennis AT ausil.us FE6 > FE7 (0:0.1-0.6.svn20061113.fc6 > 0:0.1-0.5.svn20061113.fc7) kphotobymail: kushaldas AT gmail.com FE6 > FE7 (0:0.4.1-1.fc6 > 0:0.4-3.fc7) leafnode: kevin AT tummy.com FE6 > FE7 (0:1.11.5-4.fc6 > 0:1.11.5-3.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) mew: tagoh AT redhat.com FE5 > FE6 (0:5.2-3.fc5 > 0:5.2-2.fc6) FE5 > FE7 (0:5.2-3.fc5 > 0:5.2-2.fc7) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) 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 linux.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) sear: wart AT kobold.org FE6 > FE7 (0:0.6.3-3.fc6 > 0:0.6.3-2.fc7) 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) 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) vigra: bruno AT postle.net FE5 > FE7 (0:1.5.0-2.fc5 > 0:1.4.0-4.fc6) FE6 > FE7 (0:1.5.0-2.fc6 > 0:1.4.0-4.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) 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 wart at kobold.org Fri Feb 23 04:10:38 2007 From: wart at kobold.org (Wart) Date: Thu, 22 Feb 2007 20:10:38 -0800 Subject: packages with logwatch scripts In-Reply-To: <45DBC114.8060902@kobold.org> References: <45DBC114.8060902@kobold.org> Message-ID: <45DE693E.1070903@kobold.org> Wart wrote: > I'm starting to work on adding logwatch support to a few game daemons > that I maintain, to help admins keep track of player activity. Where > would be the correct place to add the logwatch scripts, and how should > the Requires: be handled? > > choices: > > 1) Put the scripts and configs in the /etc/logwatch hierarchy > or > 2) Put the scripts and configs in the /usr/share/logwatch hierarchy > > and > > a) Require: logwatch for directory ownership > or > b) Don't explicitly Require: logwatch; daemons will only have logwatch > support if logwatch is already present. > > I would prefer not to add the explicit 'Requires: logwatch', and only > provide that functionality if the server admin has already installed > logwatch. But this would leave the directories in 1/2 unowned. > > Suggestions? In the absence of any feedback, I've decided to put the logwatch files in a -logwatch subpackage, install them into /usr/share/logwatch, and Require: logwatch for the -logwatch subpackage only. --Wart From rc040203 at freenet.de Fri Feb 23 05:03:27 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 23 Feb 2007 06:03:27 +0100 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <45DE04E1.5040403@redhat.com> References: <45DB41BB.7010807@redhat.com> <200702202019.36147.opensource@till.name> <45DB4C85.5020601@redhat.com> <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> <45DB4F76.7030504@redhat.com> <45DDCF90.3020905@ioa.s.u-tokyo.ac.jp> <45DE04E1.5040403@redhat.com> Message-ID: <1172207008.23237.338.camel@mccallum.corsepiu.local> On Thu, 2007-02-22 at 16:02 -0500, Warren Togami wrote: > Mamoru Tasaka wrote: > >> Remove the use of FE-NEW, FE-REVIEW, and FE-ACCEPT. > > > > Well, I submitted a new review request (hyperestraire: bz 229647) > > just a few hours ago and I noticed now that the bug didn't block > > FE-NEW. So for now I manually made the bug block FE-NEW. > > > > I see some newest review requests now not blocking FE-NEW. Did this > > change silently (without some notification)? > > > > Irrelevant now, With the tracker bugs, we could "Goto: FE-NEW|FE-ACCEPT|FE-*" to get an overlook over all packages in process. What's the "Flagged" counter-part? Ralf From fedora at leemhuis.info Fri Feb 23 05:49:59 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 23 Feb 2007 06:49:59 +0100 Subject: Discourage cvs-import In-Reply-To: <45DE05B0.6020600@redhat.com> References: <1172100799.25639.5.camel@Chuck> <45DCE05F.5040103@redhat.com> <45DD4587.2050700@leemhuis.info> <1172164622.5602.1.camel@localhost.localdomain> <1172166521.1641.65.camel@finch.boston.redhat.com> <45DDDA90.3050900@leemhuis.info> <45DE05B0.6020600@redhat.com> Message-ID: <45DE8087.6090807@leemhuis.info> On 22.02.2007 22:05, Warren Togami wrote: > Thorsten Leemhuis wrote: >> John Dennis schrieb: >>>> Please at least don't break cvs-import.sh for non-initial commits. It's >>>> _way_ more pleasant to use when updating tarballs than make upload or >>>> make new-source. >>> +1 >>> cvs-import is the most sane way to update an rpm when we are upstream. >>> There are quite a few rpm's for which we are the upstream and importing >>> into 'dist cvs' is just the final step after preparing a new release. I >>> really don't want some tool forcing me to review the changes I just made >>> to make sure I approve of my own work. >> It seems it wasn't clear in my mail: cvs-import.sh would still be there, >> just not documented in the wiki. So those that know about it can just >> continue to use it. > Not documented in the Wiki even for initial imports? Well, that would be counter-productive. ;-) So no, it should be documented; probably something like this "use cvs-import.sh for the initial import like this [...]; Updating the package later work like this [...] cvs update[...] cvs diff [...]cvs commit [...]" CU thl From kevin at tummy.com Fri Feb 23 06:07:56 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Thu, 22 Feb 2007 23:07:56 -0700 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <1172207008.23237.338.camel@mccallum.corsepiu.local> References: <45DB41BB.7010807@redhat.com> <200702202019.36147.opensource@till.name> <45DB4C85.5020601@redhat.com> <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> <45DB4F76.7030504@redhat.com> <45DDCF90.3020905@ioa.s.u-tokyo.ac.jp> <45DE04E1.5040403@redhat.com> <1172207008.23237.338.camel@mccallum.corsepiu.local> Message-ID: <20070222230756.03adda9a@ningauble.scrye.com> On Fri, 23 Feb 2007 06:03:27 +0100 rc040203 at freenet.de (Ralf Corsepius) wrote: > With the tracker bugs, we could "Goto: FE-NEW|FE-ACCEPT|FE-*" to get > an overlook over all packages in process. > > What's the "Flagged" counter-part? None of these are polished up yet, but here's the searches I have: formerly FE-NEW, now component "Package Review" with no flag set yet: https://bugzilla.redhat.com/bugzilla/buglist.cgi?cmdtype=runnamed&namedcmd=awaiting-review&namedowner=kevin%40tummy.com (Note that this search takes a long time since many merge reviews are here... current count is 1217 as of this email) formerly FE-ACCEPT, now component "Package Review" with flag set to +: https://bugzilla.redhat.com/bugzilla/buglist.cgi?cmdtype=runnamed&namedcmd=approved&namedowner=kevin%40tummy.com formerly FE-REVIEW, now component "Package Review" with flag set to ?: https://bugzilla.redhat.com/bugzilla/buglist.cgi?cmdtype=runnamed&namedcmd=under%20review&namedowner=kevin%40tummy.com Feel free to use those and let me know if you spot any improvements in them. Note that some of the ones in the awaiting-review search are extras reviews with no flag set, but with the old blocker bugs, so they are really under review or the like. That will hopefully get cleaned up at some point here. > Ralf kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mtasaka at ioa.s.u-tokyo.ac.jp Fri Feb 23 06:35:44 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 23 Feb 2007 15:35:44 +0900 Subject: RFC: Review with Flags (Version 5) In-Reply-To: <20070222230756.03adda9a@ningauble.scrye.com> References: <45DB41BB.7010807@redhat.com> <200702202019.36147.opensource@till.name> <45DB4C85.5020601@redhat.com> <45DB4E06.9050409@ioa.s.u-tokyo.ac.jp> <45DB4F76.7030504@redhat.com> <45DDCF90.3020905@ioa.s.u-tokyo.ac.jp> <45DE04E1.5040403@redhat.com> <1172207008.23237.338.camel@mccallum.corsepiu.local> <20070222230756.03adda9a@ningauble.scrye.com> Message-ID: <45DE8B40.40602@ioa.s.u-tokyo.ac.jp> Kevin Fenzi wrote: > On Fri, 23 Feb 2007 06:03:27 +0100 > rc040203 at freenet.de (Ralf Corsepius) wrote: > >> With the tracker bugs, we could "Goto: FE-NEW|FE-ACCEPT|FE-*" to get >> an overlook over all packages in process. >> >> What's the "Flagged" counter-part? I am also trying to find out how I can find out these status with flags, however currently I don't know what to do _correctly_ . Well, for me, currently I use the links on my wiki page: http://fedoraproject.org/wiki/MamoruTasaka I would also appreciate it if someone would help me polishing up the search link. Thanks. Mamoru Tasaka From bugs.michael at gmx.net Fri Feb 23 15:59:28 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 23 Feb 2007 16:59:28 +0100 Subject: wxGTK2 status and testing In-Reply-To: <13dbfe4f0702201347i52ec648cx49bd031a134601bc@mail.gmail.com> References: <20070219111646.abfa4780.bugs.michael@gmx.net> <20070219140117.GA13340@jadzia.bu.edu> <20070219152248.81038ee4.bugs.michael@gmx.net> <1171895240.5333.1.camel@scriabin.tannenrauch.ch> <20070220103918.12549d0f.bugs.michael@gmx.net> <13dbfe4f0702201347i52ec648cx49bd031a134601bc@mail.gmail.com> Message-ID: <20070223165928.1214f9be.bugs.michael@gmx.net> On Tue, 20 Feb 2007 22:47:24 +0100, Chitlesh GOORAH wrote: > > Anyway, I've submitted compat-wxGTK26 for review, because Audacity builds > > with it and doesn't lock up and because a recent snapshot of Audacity > > introduces new problems wrt audio I/O and project freq. > > Great :) Toped has been broken for some time and upstream isn't > responding. I'll test those rpms and report back. freeglut in devel seems broken. Package has not been touched or rebuilt since Tue 29 Aug 2006. That's a first blocker for toped. /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libglut.so: undefined reference to `glXGetCurrentContext' From tmz at pobox.com Fri Feb 23 16:27:17 2007 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 23 Feb 2007 11:27:17 -0500 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <45DA22C5.7020102@redhat.com> References: <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> <45DA1BF3.8040301@kobold.org> <45DA22C5.7020102@redhat.com> Message-ID: <20070223162717.GA28224@psilocybe.teonanacatl.org> Warren Togami wrote: > http://fedoraproject.org/wiki/CVSAdminProcedure > > You may use the new procedure on this page now. I have a few questions on that. The example on that page is: New Package CVS Request ======================= Package Name: foobar Short Description: 3D Game of Foo Owners: foo at example.com,bar at example.com Branches: FC-5 FC-6 devel InitialCC: baz at example.com Below this it says: Valid branch names currently used for Fedora: FC-5 FC-6 devel branch is implicit and always created. Is there a formatting error that "devel branch is implicit and always created" is not on its own line? I don't imagine that all three targets (FC-5 FC-6 devel) are implicit). Also, if devel is implicit, is it really needed to list it in Branches: ? -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== There, I've gone and soiled myself, are you happy now?! -- Stewie Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From bugs.michael at gmx.net Fri Feb 23 16:36:30 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 23 Feb 2007 17:36:30 +0100 Subject: RATIFIED: CVS Admin with Flags (Version 4) In-Reply-To: <20070223162717.GA28224@psilocybe.teonanacatl.org> References: <45C015AA.6070008@redhat.com> <20070204012016.50a5f8b9@ludwig-alpha.unil.ch> <20070203201810.6bdd8141@ningauble.scrye.com> <20070204112051.612bcbeb.bugs.michael@gmx.net> <20070205213236.GI4858@nostromo.devel.redhat.com> <45DA0DB4.4020307@redhat.com> <45DA1BF3.8040301@kobold.org> <45DA22C5.7020102@redhat.com> <20070223162717.GA28224@psilocybe.teonanacatl.org> Message-ID: <20070223173630.0d0620d2.bugs.michael@gmx.net> On Fri, 23 Feb 2007 11:27:17 -0500, Todd Zullinger wrote: > Warren Togami wrote: > > http://fedoraproject.org/wiki/CVSAdminProcedure > > > > You may use the new procedure on this page now. > > I have a few questions on that. The example on that page is: > > New Package CVS Request > ======================= > Package Name: foobar > Short Description: 3D Game of Foo > Owners: foo at example.com,bar at example.com > Branches: FC-5 FC-6 devel > InitialCC: baz at example.com > > Below this it says: > > Valid branch names currently used for Fedora: FC-5 FC-6 devel branch > is implicit and always created. > > Is there a formatting error that "devel branch is implicit and always > created" is not on its own line? I don't imagine that all three > targets (FC-5 FC-6 devel) are implicit). > > Also, if devel is implicit, is it really needed to list it in > Branches: ? No. It is a formatting error in the Wiki. From dominik at greysector.net Fri Feb 23 16:12:04 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 23 Feb 2007 17:12:04 +0100 Subject: RATIFIED: Review with Flags (Version 6) In-Reply-To: <45DE1D71.7020300@redhat.com> References: <45DE1D71.7020300@redhat.com> Message-ID: <20070223161204.GA12571@ryvius.pekin.waw.pl> On Thursday, 22 February 2007 at 23:47, Warren Togami wrote: > Thursday, February 22nd, 2007 FESCO ratified this as the new package > review process for *ALL* reviews. This includes both Merge Reviews and > New Package Reviews. Next I need to find all places in the Wiki that > need updating... Thank you! Looks similar to the old process, which is good. 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 pmatilai at laiskiainen.org Fri Feb 23 18:36:53 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 23 Feb 2007 20:36:53 +0200 (EET) Subject: Rawhide stability In-Reply-To: <20070221214448.C682B1800E4@magilla.sf.frob.com> References: <20070221214448.C682B1800E4@magilla.sf.frob.com> Message-ID: On Wed, 21 Feb 2007, Roland McGrath wrote: >> Primarily, I have to update manually and often have to exclude some broken >> deps. > > This would be greatly aided if yum had a "smallest usable transaction" > mode. That is, instead of always doing one giant upgrade that barfs if > there are dependency problems, it would take each update available and suck > in only its necessary deps as if you'd done "yum upgrade foobar" on the > individual package, finish that, and then do the next transaction. When > some packages have dependency problems, they get punted but not everything > else unrelated. So instead of either "wait for a day when yum upgrade works" > or "mess around manually a lot", every day has an "easily upgrade what > upgrades easily" option. For all the bizarre decisions apt-rpm can occasionally do in depsolving, this kind of thing it does rather well. Depending on various details and the used method, it'll either hold back from updating a package or remove if there's no other way to solve the issue. Additionally with --fix-missing it's much more forgiving about partially out-of-sync mirrors than yum is. I have a feeling I've said this before but I find it somewhat funny that yum refuses to work with broken repository but doesn't care about broken dependencies on the installed system whereas apt refuses to work with broken dependencies on the installed system, yet is fairly forgiving about badness in repository. Usually using one or the other will get you around the problem, depending on the situation :) - Panu - From mattdm at mattdm.org Fri Feb 23 18:42:40 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 23 Feb 2007 13:42:40 -0500 Subject: Rawhide stability In-Reply-To: References: <20070221214448.C682B1800E4@magilla.sf.frob.com> Message-ID: <20070223184240.GA12938@jadzia.bu.edu> On Fri, Feb 23, 2007 at 08:36:53PM +0200, Panu Matilainen wrote: > For all the bizarre decisions apt-rpm can occasionally do in depsolving, > this kind of thing it does rather well. Depending on various details and > the used method, it'll either hold back from updating a package or remove > if there's no other way to solve the issue. Additionally with > --fix-missing it's much more forgiving about partially out-of-sync mirrors > than yum is. Yeah, it's nice how APT is happy to totally eat all of your system so it can reduce it to a consistent set. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nicolas.mailhot at laposte.net Sat Feb 24 10:58:19 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 24 Feb 2007 11:58:19 +0100 Subject: Rawhide stability In-Reply-To: <20070222153734.GA388@redhat.com> References: <20070221210846.GM29321@redhat.com> <20070222153734.GA388@redhat.com> Message-ID: <1172314699.3573.27.camel@rousalka.dyndns.org> Le jeudi 22 f?vrier 2007 ? 10:37 -0500, Andrew Overholt a ?crit : > Thanks for your thoughts, everyone. I'm glad rawhide stability isn't an > issue. I'm also in agreement that we shouldn't impose limits or > anything which will slow down progress bleeding-edge-ness. Actually, even though rawhide stability is not a huge issue (speaking as someone who's been running rawhide systems continuously since ~ RHL 6-7), there are lots of room for improvement. Most of rawhide pains are not difficult-to-diagnose stuff that requires days of analysis and would slow progress if we tried to avoid it, but trivial mistakes, incomplete rebuilds, bad interdependency tracking, etc that could be avoided with better tooling/processes. Taking care of those would make rawhide hugely more attractive for testers, and leave the difficult/subtle problems for test releases. Focus is good. Stuff that would make testers life easier: - better rebuild staging (do not expose half-rebuilt repos, wait till they're complete) - trivial stuff hot-fixes (allow maintainers to push trivial fixes before the nightly push when the fix is known and every tester complains about the same problem) - rollback of problem packages (put back the previous package when a problem has been identified with the new one and we know it will take days to fix) I hate to write this, but even though rawhide should be allowed to eat babies occasionally, this argument is often used to justify slacking on small fixes. Letting small problems accumulate only means there is little time left for difficult stuff during test phases. -- 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 jkeating at redhat.com Sat Feb 24 13:31:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 24 Feb 2007 08:31:38 -0500 Subject: Rawhide stability In-Reply-To: <1172314699.3573.27.camel@rousalka.dyndns.org> References: <20070221210846.GM29321@redhat.com> <20070222153734.GA388@redhat.com> <1172314699.3573.27.camel@rousalka.dyndns.org> Message-ID: <200702240831.38955.jkeating@redhat.com> On Saturday 24 February 2007 05:58, Nicolas Mailhot wrote: > Stuff that would make testers life easier: > - better rebuild staging (do not expose half-rebuilt repos, wait till > they're complete) This has been brought up before, how do we know what is "half rebuilt" ? There is almost always going to be some form of broken deps, especially after the merger. Timezone variance makes it very difficult, but thats what freezes are for, to get things consistent again, without things changing underneath you. > - trivial stuff hot-fixes (allow maintainers to push trivial fixes > before the nightly push when the fix is known and every tester complains > about the same problem) somewhat difficult on the mirrors. Also, pushing rawhide takes a while, since we make it installable, multilib, etc... maybe some sort of 'updates' to rawhide in another repo, but then we need somebody to respond to the push requests and, well, that's a lot of work. > - rollback of problem packages (put back the previous package when a > problem has been identified with the new one and we know it will take > days to fix) This can be done, all it takes is a maintainer telling me and I can untag the broken build. Of course this breaks upgrade paths for anybody who picked up the broken build... -- 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 laroche at redhat.com Sat Feb 24 13:47:09 2007 From: laroche at redhat.com (Florian La Roche) Date: Sat, 24 Feb 2007 14:47:09 +0100 Subject: Rawhide stability In-Reply-To: <200702240831.38955.jkeating@redhat.com> References: <20070221210846.GM29321@redhat.com> <20070222153734.GA388@redhat.com> <1172314699.3573.27.camel@rousalka.dyndns.org> <200702240831.38955.jkeating@redhat.com> Message-ID: <20070224134709.GA12077@dudweiler.stuttgart.redhat.com> > > - rollback of problem packages (put back the previous package when a > > problem has been identified with the new one and we know it will take > > days to fix) > > This can be done, all it takes is a maintainer telling me and I can untag the > broken build. Of course this breaks upgrade paths for anybody who picked up > the broken build... Maybe this one should go onto the TODO list for the buildsystem, so that developers could revert to an older known stable rpm via the buildsystem, so that they can take their time to develop a real fix to show up in a new package. This still leaves the normal turnaround time to the next rawhide push, but then gives more time for the real fix to go out. regards, Florian La Roche From laroche at redhat.com Sat Feb 24 13:50:43 2007 From: laroche at redhat.com (Florian La Roche) Date: Sat, 24 Feb 2007 14:50:43 +0100 Subject: Rawhide stability In-Reply-To: <20070223184240.GA12938@jadzia.bu.edu> References: <20070221214448.C682B1800E4@magilla.sf.frob.com> <20070223184240.GA12938@jadzia.bu.edu> Message-ID: <20070224135043.GB12077@dudweiler.stuttgart.redhat.com> On Fri, Feb 23, 2007 at 01:42:40PM -0500, Matthew Miller wrote: > On Fri, Feb 23, 2007 at 08:36:53PM +0200, Panu Matilainen wrote: > > For all the bizarre decisions apt-rpm can occasionally do in depsolving, > > this kind of thing it does rather well. Depending on various details and > > the used method, it'll either hold back from updating a package or remove > > if there's no other way to solve the issue. Additionally with > > --fix-missing it's much more forgiving about partially out-of-sync mirrors > > than yum is. > > Yeah, it's nice how APT is happy to totally eat all of your system so it can > reduce it to a consistent set. :) You can add a mode where only updates are limited to a subset without dependency problems, so that broken rawhide pushes can still be consumed. regards, Florian La Roche From jkeating at redhat.com Sat Feb 24 13:53:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 24 Feb 2007 08:53:37 -0500 Subject: Rawhide stability In-Reply-To: <20070224134709.GA12077@dudweiler.stuttgart.redhat.com> References: <20070221210846.GM29321@redhat.com> <200702240831.38955.jkeating@redhat.com> <20070224134709.GA12077@dudweiler.stuttgart.redhat.com> Message-ID: <200702240853.38062.jkeating@redhat.com> On Saturday 24 February 2007 08:47, Florian La Roche wrote: > Maybe this one should go onto the TODO list for the buildsystem, so that > developers could revert to an older known stable rpm via the buildsystem, > so that they can take their time to develop a real fix to show up in a new > package. > This still leaves the normal turnaround time to the next rawhide push, but > then gives more time for the real fix to go out. I misspoke. They should be able to do that now. untag-pkg allows you to untag a package for a collection. -- 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 quintela at redhat.com Sat Feb 24 15:04:37 2007 From: quintela at redhat.com (Juan Quintela) Date: Sat, 24 Feb 2007 16:04:37 +0100 Subject: Rawhide stability In-Reply-To: <20070221221126.B9C741800E4@magilla.sf.frob.com> References: <20070221221126.B9C741800E4@magilla.sf.frob.com> Message-ID: <1172329478.5673.46.camel@anano.mitica> On Wed, 2007-02-21 at 14:11 -0800, Roland McGrath wrote: > > # yum install yum-skip-broken and use the --skip-broken parameter. > > My hero! A "smallest possible transaction" mode would still make me > happier for rawhide upgrades. I have too many times had the giant yum > upgrade not have any dep problems, but have some %post error or kernel > crash in the middle, that left me with an unholy mess of half-upgraded crap > to sort out (usually both versions of a billion rpms in the db, with the > files maybe from the new one or maybe still some files from the old one, > etc). If each transaction were only as big as it needed to be to be > coherent, with the rpm database written in a clear state, then the > incremental damage done at any instance of crashing in the middle would be > much more manageable. And that will also help when you don't have enough free space in /var for the update. i.e. today upgrade from a fresh FC6 to FC6+updates in one go in x86_64 needs ~700MB on /var. When I don't have enough space, I have to do the updates by hand and it works. Later, Juan. /me expects that somebody shows me some other yum plugin that does that From a.badger at gmail.com Sat Feb 24 17:03:50 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 24 Feb 2007 09:03:50 -0800 Subject: Future owners/ACL choices Message-ID: <1172336630.4472.411.camel@localhost.localdomain> Hey all, The packagedb[1]_ is progressing quite nicely. To the point where we should be able to replace owners.list and acls with it in the not too distant future. But in talking about what remains to be done, Bill Nottingham and I came to a disagreement about what the policy surrounding ownership needs to be. In the pre-ACL cvs tree, anyone could edit owners.list and the cvs files. When ACLs were enabled on the cvs tree[2]_, existence of a special pkg.acl file was used to lock down individual packages. At the same time, owners.list was locked down to prevent package maintainers from adding themselves as owners on other packages and circumventing the ACLs. Any changes to the file, orphaning or taking packages, adding new packages, adding comaintainers, etc, now has to go through a cvs administrator in order to be approved. With the packagedb we have more flexibility in what we allow owners to do, what we need admins to do, and what anyone can do. But there's a disagreement as to how much access is prudent. Here's the functions that can change with the packagedb: * Take ownership * Release ownership * Ability to control commit access (CVS ACLs) * Ability to control who can modify packagedb ACLs * Watch bugzilla (notified about bugs opened on this package) * Watch commits (notified about commits to the package) These two are available in the db but probably won't be implemented in the interface for F7: * Checkout -- Necessary for embargoed packages/package branches but we don't have any. * Build -- Requires interaction with the build system so it probably will wait for F8 notting and I are in agreement that Commit, packagedb ACLs, and notifications will be requested by user and approved by package owner (I'm thinking of auto-approving watchbugzilla and watchcommits but I hadn't mentioned that before.) We disagree about ownership. I think we should allow members of cvsextras to take and release ownership at will. notting would rather see requests get queued (at least, requests to take ownership) and a cvs admin will approve it. Here's a summary of arguments: = At Will = = Queued = Closer to the pre-acl state Closer to what we have presently More convenient for packagers Less ability for a rogue packager to build a bunch of orphaned packages with malicious intent. Easier for packagers to make Do we actually want this? small fixes to orphaned packages. There's no need to force admins A package is reviewed and imported for to look at every request as we a specific owner. A new owner should already trust the packager to be reviewed to make sure they're do the right thing. trusted for this package. FESCo will have to make a decision on this matter but we need more input on what the right course of action is. Your thoughts are appreciated so I can continue hacking, -Toshio [1]_: https://admin.fedoraproject.org/pkgdb [2]_: FESCo minutes for the meeting that the lock down of owners.list was announced. This discussion is in the last section of the logs. http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070125 -------------- 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 tibbs at math.uh.edu Sat Feb 24 17:41:43 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 24 Feb 2007 11:41:43 -0600 Subject: Future owners/ACL choices In-Reply-To: <1172336630.4472.411.camel@localhost.localdomain> References: <1172336630.4472.411.camel@localhost.localdomain> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> I think we should allow members of cvsextras to take and release TK> ownership at will. notting would rather see requests get queued TK> (at least, requests to take ownership) and a cvs admin will TK> approve it. After some thought I believe that people should be able to relinquish ownership at will (since they can do that anyway just by not maintaining their packages any longer) and that anyone should be able to take ownership of orphaned packages at will. Maintainers should be able to give ownership of their packages to others (either adding other maintainers or completely transferring ownership to others). But I see no problem with restricting the ability to arbitrarily take ownership of another already owned package. - J< From michel.salim at gmail.com Sat Feb 24 17:49:04 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 24 Feb 2007 12:49:04 -0500 Subject: Future owners/ACL choices In-Reply-To: <1172336630.4472.411.camel@localhost.localdomain> References: <1172336630.4472.411.camel@localhost.localdomain> Message-ID: <883cfe6d0702240949qf28b39el16c0ece28979e556@mail.gmail.com> 2007/2/24, Toshio Kuratomi : > = At Will = = Queued = > > Closer to the pre-acl state Closer to what we have presently > > More convenient for packagers Less ability for a rogue packager > to build a bunch of orphaned packages > with malicious intent. > > Easier for packagers to make Do we actually want this? > small fixes to orphaned > packages. > > There's no need to force admins A package is reviewed and imported for > to look at every request as we a specific owner. A new owner should > already trust the packager to be reviewed to make sure they're > do the right thing. trusted for this package. > How about a throttling system: only allow a certain rate of ownership takeover before then queuing up the request. The allowed rate can be set higher for more trusted maintainers, and reduced (even to zero) for maintainers who botched the job. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From fedora at leemhuis.info Sat Feb 24 17:51:25 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 24 Feb 2007 18:51:25 +0100 Subject: Future owners/ACL choices In-Reply-To: <1172336630.4472.411.camel@localhost.localdomain> References: <1172336630.4472.411.camel@localhost.localdomain> Message-ID: <45E07B1D.8030208@leemhuis.info> Toshio Kuratomi schrieb: > notting and I are in agreement that Commit, packagedb ACLs, and > notifications will be requested by user and approved by package owner > (I'm thinking of auto-approving watchbugzilla and watchcommits but I > hadn't mentioned that before.) We disagree about ownership. My 2 cent: "Queue and ACK" the owner for new and freshly imported packages as well as orphaned packages, but "at will" for existing packages. The latter *maybe* "at will" only for the primary maintainer, so only he can add co-maintainers or hand over maintainership to somebody else. Cu thl From jkeating at redhat.com Sat Feb 24 18:05:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 24 Feb 2007 13:05:49 -0500 Subject: Future owners/ACL choices In-Reply-To: References: <1172336630.4472.411.camel@localhost.localdomain> Message-ID: <200702241305.53007.jkeating@redhat.com> On Saturday 24 February 2007 12:41, Jason L Tibbitts III wrote: > After some thought I believe that people should be able to relinquish > ownership at will (since they can do that anyway just by not > maintaining their packages any longer) and that anyone should be able > to take ownership of orphaned packages at will. ?Maintainers should be > able to give ownership of their packages to others (either adding > other maintainers or completely transferring ownership to others). > But I see no problem with restricting the ability to arbitrarily take > ownership of another already owned package. I like this. Orphaned packages could default back to open for any Extras contributor. Then if it ever gets taken over, the maintainer taking it over can make a decision about the ACLs at that point. -- 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 Sat Feb 24 18:55:27 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 24 Feb 2007 10:55:27 -0800 Subject: Future owners/ACL choices In-Reply-To: <200702241305.53007.jkeating@redhat.com> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> Message-ID: <1172343327.4472.443.camel@localhost.localdomain> On Sat, 2007-02-24 at 13:05 -0500, Jesse Keating wrote: > On Saturday 24 February 2007 12:41, Jason L Tibbitts III wrote: > > After some thought I believe that people should be able to relinquish > > ownership at will (since they can do that anyway just by not > > maintaining their packages any longer) and that anyone should be able > > to take ownership of orphaned packages at will. Maintainers should be > > able to give ownership of their packages to others (either adding > > other maintainers or completely transferring ownership to others). > > But I see no problem with restricting the ability to arbitrarily take > > ownership of another already owned package. > > I like this. Orphaned packages could default back to open for any Extras > contributor. Then if it ever gets taken over, the maintainer taking it over > can make a decision about the ACLs at that point. This makes sense to me as well. Summary: Maintainer requesting ownership of an owned package => request is queued Dropping ownership => at will Taking orphans => at will Maintainer transfer => Present owner should be able to reassign to a new owner within cvsextras. Orphaned packages have ACLs dropped back to "open for cvsextras." -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 cweyl at alumni.drew.edu Sat Feb 24 19:04:37 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sat, 24 Feb 2007 11:04:37 -0800 Subject: Future owners/ACL choices In-Reply-To: <200702241305.53007.jkeating@redhat.com> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> Message-ID: <7dd7ab490702241104v37e1bebeu1b90510d9435ab59@mail.gmail.com> On 2/24/07, Jesse Keating wrote: > On Saturday 24 February 2007 12:41, Jason L Tibbitts III wrote: > > After some thought I believe that people should be able to relinquish > > ownership at will (since they can do that anyway just by not > > maintaining their packages any longer) and that anyone should be able > > to take ownership of orphaned packages at will. Maintainers should be > > able to give ownership of their packages to others (either adding > > other maintainers or completely transferring ownership to others). > > But I see no problem with restricting the ability to arbitrarily take > > ownership of another already owned package. > > I like this. Orphaned packages could default back to open for any Extras > contributor. Then if it ever gets taken over, the maintainer taking it over > can make a decision about the ACLs at that point. +1. This seems to enable the best of both worlds; if someone's packages (say, AWOL) need to be forcibly orphaned it doesn't seem to be a huge burden to have another set of eyes on the request. -Chris -- Chris Weyl Ex astris, scientia From jkeating at redhat.com Sat Feb 24 19:14:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 24 Feb 2007 14:14:16 -0500 Subject: Future owners/ACL choices In-Reply-To: <1172343327.4472.443.camel@localhost.localdomain> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> <1172343327.4472.443.camel@localhost.localdomain> Message-ID: <200702241414.16831.jkeating@redhat.com> On Saturday 24 February 2007 13:55, Toshio Kuratomi wrote: > Summary: > > Maintainer requesting ownership of an owned package => request is queued > Dropping ownership => at will > Taking orphans => at will > Maintainer transfer => Present owner should be able to reassign to a new > owner within cvsextras. > Orphaned packages have ACLs dropped back to "open for cvsextras." And rel-eng type people can do reassignments at will right? Like say if an employee leaves Red Hat and another maintainer picks up the packages, or if somebody changes groups within Red Hat leaving various packages behind, or other such things. -- 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 opensource at till.name Sat Feb 24 19:35:45 2007 From: opensource at till.name (Till Maas) Date: Sat, 24 Feb 2007 20:35:45 +0100 Subject: Future owners/ACL choices In-Reply-To: <1172343327.4472.443.camel@localhost.localdomain> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> <1172343327.4472.443.camel@localhost.localdomain> Message-ID: <200702242036.06553.opensource@till.name> On Samstag 24 Februar 2007, Toshio Kuratomi wrote: > Maintainer requesting ownership of an owned package => request is queued When is there a need for a maintainer to get ownership of another package without wanting the original owner to transfer it? The only case I can think of is when the actual owner of a package is AWOL. But in this case it should be made sure that all of his packages are taken care of, so that the correct workflow should be a request to orphan all packages of a maintainer and then pick the package one wants to adopt. What may be useful, would be to queue the request for the owner of the regarding package, so that a maintainer can ask another maintainer via the packageDB for a package and then it is transfered. > Maintainer transfer => Present owner should be able to reassign to a new > owner within cvsextras. I think that this transfer should be acknowleged by the new owner before it takes place, to make sure it is wanted by both sides. 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 tgl at redhat.com Sun Feb 25 02:39:48 2007 From: tgl at redhat.com (Tom Lane) Date: Sat, 24 Feb 2007 21:39:48 -0500 Subject: Future owners/ACL choices In-Reply-To: <1172336630.4472.411.camel@localhost.localdomain> References: <1172336630.4472.411.camel@localhost.localdomain> Message-ID: <1435.1172371188@sss.pgh.pa.us> Toshio Kuratomi writes: > notting and I are in agreement that Commit, packagedb ACLs, and > notifications will be requested by user and approved by package owner > (I'm thinking of auto-approving watchbugzilla and watchcommits but I > hadn't mentioned that before.) We disagree about ownership. I think we > should allow members of cvsextras to take and release ownership at will. I must be misunderstanding your proposal. You want actions X, Y, and Z to be approved by the package owner ... but anyone can become the package owner at will? This does not compute. You might as well just say that every member of cvsextras has all the keys to the kingdom. Reading between the lines I think you might have meant that anyone could take ownership of a currently-unowned package; but that's not what you actually said. regards, tom lane From nicolas.mailhot at laposte.net Sun Feb 25 08:56:36 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 25 Feb 2007 09:56:36 +0100 Subject: Heads up for login managers In-Reply-To: <200702121442.01944.sgrubb@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> Message-ID: <1172393796.25309.7.camel@rousalka.dyndns.org> Le lundi 12 f?vrier 2007 ? 14:42 -0500, Steve Grubb a ?crit : > On Monday 12 February 2007 14:22, David Zeuthen wrote: > > On Mon, 2007-02-12 at 14:10 -0500, Steve Grubb wrote: > > > "It allows users to switch between user accounts on a single PC without > > > quitting applications and logging out." > > > > > > So it seems to indicate that UID is the right granularity. > > > > No. Again, it's a (mild?) security problem if an inactive session can > > spy on another session using sound or webcam capture. Just think of > > bored grad students in a computer lab. > > Inactive sessions should have no access to hardware Nope. Think system with PVR card & video output on TV/videoprojector/whatever You will want a continuously running background session managing the video bits (recording stuff, outputing video, reacting to lirc remote commands) with normal computer user sessions running in parallel on the computer screen head -- 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 Sun Feb 25 09:59:10 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 25 Feb 2007 10:59:10 +0100 Subject: Core merge and Package Guidelines In-Reply-To: <20070209112626.eca5a45b.bugs.michael@gmx.net> References: <1170979354.4306.194.camel@localhost.localdomain> <20070209010519.GF2821@free.fr> <20070209112626.eca5a45b.bugs.michael@gmx.net> Message-ID: <1172397550.25309.20.camel@rousalka.dyndns.org> Le vendredi 09 f?vrier 2007 ? 11:26 +0100, Michael Schwendt a ?crit : > There has been some unfortunate development in that area. > > If memory serves correctly, we have never wanted absolutely strict > ownership in those cases, at least not when we created the initial > reviewing guidelines. > > It's not worth the effort. It would be wrong to create a dependency on an > optional help viewer just to get ownership of a documentation root > directory. IMHO: 1. The default rule should be package owning all the directories it uses and created itself 2. For directories owned by another package, there should be a dep on this other package 3. For common shared directories where we don't want to force a dep on another component, a fedora-filesystem package should be created that owns those dirs and manages their permissions (in that case both primary and secondary users of the dir should depend on fedora-filesystem) 3. solves the unowned dir/permission conflict problem, documents what directories Fedora considers shared, and does not force dependency explosion. If there are not enough users for a dir to be put in the fedora-filesystem package then we can live with deps on the primary owner, little harm done, and being strict is better than being lax (which always bite you someday) -- 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 davidz at redhat.com Sun Feb 25 18:02:34 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 25 Feb 2007 13:02:34 -0500 Subject: Heads up for login managers In-Reply-To: <1172393796.25309.7.camel@rousalka.dyndns.org> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <1172393796.25309.7.camel@rousalka.dyndns.org> Message-ID: <1172426554.2633.8.camel@zelda.fubar.dk> On Sun, 2007-02-25 at 09:56 +0100, Nicolas Mailhot wrote: > Think system with PVR card & video output on TV/videoprojector/whatever > You will want a continuously running background session managing the > video bits (recording stuff, outputing video, reacting to lirc remote > commands) with normal computer user sessions running in parallel on the > computer screen head For such things, you can simply drop a file (requires root access) somewhere such that the users/groups of your choice can get access. See both https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140853 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229912 for examples where this is discussed (Flumotion resp. accessible gdm). I hope you agree that, as a long term goal, we shouldn't allow users in inactive sessions to capture A/V such as to spy on active sessions :-). But, sure, that is policy and when you do policy you better provide a way to override it. So there you go. (Btw, ideally, PVR functionality would be provided in such a way that these things just runs in the background and you wouldn't need a dedicated login session. But if you want, it's not difficult to change although as mentioned in 140853 I need to write some good docs about.) (Of course, right now in Rawhide we don't remove the ACL's on session inactivity (it's a one-line change though) but that's mostly because we don't have revoke()....) David From alan at redhat.com Sun Feb 25 18:19:40 2007 From: alan at redhat.com (Alan Cox) Date: Sun, 25 Feb 2007 13:19:40 -0500 Subject: Heads up for login managers In-Reply-To: <1172426554.2633.8.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <1172393796.25309.7.camel@rousalka.dyndns.org> <1172426554.2633.8.camel@zelda.fubar.dk> Message-ID: <20070225181940.GA19580@devserv.devel.redhat.com> On Sun, Feb 25, 2007 at 01:02:34PM -0500, David Zeuthen wrote: > (Of course, right now in Rawhide we don't remove the ACL's on session > inactivity (it's a one-line change though) but that's mostly because we > don't have revoke()....) Keep poking Mr Viro to review and help with the revoke patches From sgrubb at redhat.com Sun Feb 25 18:39:13 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sun, 25 Feb 2007 13:39:13 -0500 Subject: Heads up for login managers In-Reply-To: <1172426554.2633.8.camel@zelda.fubar.dk> References: <1171071170.2935.63.camel@zelda.fubar.dk> <1172393796.25309.7.camel@rousalka.dyndns.org> <1172426554.2633.8.camel@zelda.fubar.dk> Message-ID: <200702251339.13534.sgrubb@redhat.com> On Sunday 25 February 2007 13:02:34 David Zeuthen wrote: > Of course, right now in Rawhide we don't remove the ACL's on session > inactivity (it's a one-line change though) but that's mostly because we > don't have revoke()....) Is there a bz for this feature request? This is something that is discussed in CAPP/LSPP security targets. I think there are some minimum features/functionality that it would have to meet that I'd like to add to the bz. -Steve From davidz at redhat.com Sun Feb 25 19:15:54 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 25 Feb 2007 14:15:54 -0500 Subject: Heads up for login managers In-Reply-To: <200702251339.13534.sgrubb@redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <1172393796.25309.7.camel@rousalka.dyndns.org> <1172426554.2633.8.camel@zelda.fubar.dk> <200702251339.13534.sgrubb@redhat.com> Message-ID: <1172430954.2633.13.camel@zelda.fubar.dk> On Sun, 2007-02-25 at 13:39 -0500, Steve Grubb wrote: > On Sunday 25 February 2007 13:02:34 David Zeuthen wrote: > > Of course, right now in Rawhide we don't remove the ACL's on session > > inactivity (it's a one-line change though) but that's mostly because we > > don't have revoke()....) > > Is there a bz for this feature request? This is something that is discussed in > CAPP/LSPP security targets. I think there are some minimum > features/functionality that it would have to meet that I'd like to add to the > bz. Good idea; I've just filed this one https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230005 David From davidz at redhat.com Sun Feb 25 19:25:40 2007 From: davidz at redhat.com (David Zeuthen) Date: Sun, 25 Feb 2007 14:25:40 -0500 Subject: Heads up for login managers In-Reply-To: <20070225181940.GA19580@devserv.devel.redhat.com> References: <1171071170.2935.63.camel@zelda.fubar.dk> <200702121410.58951.sgrubb@redhat.com> <1171308137.2860.92.camel@zelda.fubar.dk> <200702121442.01944.sgrubb@redhat.com> <1172393796.25309.7.camel@rousalka.dyndns.org> <1172426554.2633.8.camel@zelda.fubar.dk> <20070225181940.GA19580@devserv.devel.redhat.com> Message-ID: <1172431540.2633.17.camel@zelda.fubar.dk> On Sun, 2007-02-25 at 13:19 -0500, Alan Cox wrote: > On Sun, Feb 25, 2007 at 01:02:34PM -0500, David Zeuthen wrote: > > (Of course, right now in Rawhide we don't remove the ACL's on session > > inactivity (it's a one-line change though) but that's mostly because we > > don't have revoke()....) > > Keep poking Mr Viro to review and help with the revoke patches Yup, thanks, I've opened https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230006 for this request. David From a.badger at gmail.com Sun Feb 25 22:50:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 25 Feb 2007 14:50:34 -0800 Subject: Future owners/ACL choices In-Reply-To: <1435.1172371188@sss.pgh.pa.us> References: <1172336630.4472.411.camel@localhost.localdomain> <1435.1172371188@sss.pgh.pa.us> Message-ID: On 2/24/07, Tom Lane wrote: > Toshio Kuratomi writes: > > notting and I are in agreement that Commit, packagedb ACLs, and > > notifications will be requested by user and approved by package owner > > (I'm thinking of auto-approving watchbugzilla and watchcommits but I > > hadn't mentioned that before.) We disagree about ownership. I think we > > should allow members of cvsextras to take and release ownership at will. > > I must be misunderstanding your proposal. You want actions X, Y, and Z > to be approved by the package owner ... but anyone can become the > package owner at will? This does not compute. You might as well just > say that every member of cvsextras has all the keys to the kingdom. > > Reading between the lines I think you might have meant that anyone could > take ownership of a currently-unowned package; but that's not what you > actually said. > You are correct: Releasing packages: Owned package: owner may release at will Taking Packages: Orphaned package: Anyone with cvsextras may take Owned package: Not usually allowed. Requests for this would be queued and approved by an admin. Sorry about that; Jason's reply should also have clued me in that I was being less than clear. -Toshio From a.badger at gmail.com Mon Feb 26 04:16:10 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 25 Feb 2007 20:16:10 -0800 Subject: Future owners/ACL choices In-Reply-To: <200702241414.16831.jkeating@redhat.com> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> <1172343327.4472.443.camel@localhost.localdomain> <200702241414.16831.jkeating@redhat.com> Message-ID: <1172463370.4097.23.camel@localhost.localdomain> On Sat, 2007-02-24 at 14:14 -0500, Jesse Keating wrote: > On Saturday 24 February 2007 13:55, Toshio Kuratomi wrote: > > Summary: > > > > Maintainer requesting ownership of an owned package => request is queued > > Dropping ownership => at will > > Taking orphans => at will > > Maintainer transfer => Present owner should be able to reassign to a new > > owner within cvsextras. > > Orphaned packages have ACLs dropped back to "open for cvsextras." > > And rel-eng type people can do reassignments at will right? Like say if an > employee leaves Red Hat and another maintainer picks up the packages, or if > somebody changes groups within Red Hat leaving various packages behind, or > other such things. Essentially yes. I haven't coded it yet but the initial plan is that people who are in the cvsadmin group will have the same rights as an owner of any package. Which group is given this power is almost certain to be changed over time, however. Your example brings up an important but tangential point, however: In the merged Core + Extras world (aka allowing community outside of Red Hat to maintain "Core" packages) someone within Red Hat could leave Red Hat and still want to maintain their packages for Fedora. In many cases, this would be a good thing. So changing owners should still go through some sort of process even when the maintainer involved is from within Red Hat (not just have a rel-engineer make the change when the Red Hatter takes another job.) -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 a.badger at gmail.com Mon Feb 26 04:33:13 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 25 Feb 2007 20:33:13 -0800 Subject: Future owners/ACL choices In-Reply-To: <200702242036.06553.opensource@till.name> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> <1172343327.4472.443.camel@localhost.localdomain> <200702242036.06553.opensource@till.name> Message-ID: <1172464393.4097.40.camel@localhost.localdomain> On Sat, 2007-02-24 at 20:35 +0100, Till Maas wrote: > On Samstag 24 Februar 2007, Toshio Kuratomi wrote: > > > Maintainer requesting ownership of an owned package => request is queued > > When is there a need for a maintainer to get ownership of another package > without wanting the original owner to transfer it? The only case I can think > of is when the actual owner of a package is AWOL. But in this case it should > be made sure that all of his packages are taken care of, so that the correct > workflow should be a request to orphan all packages of a maintainer and then > pick the package one wants to adopt. There could be other instances as well. If Dave Jones were to go AWOL, for instance, and he had no comaintainers, we'd certainly want to fast track someone onto the kernel package no matter what the state of his other packages. If a package maintainer was not dealing with one of their packages but was quite active on their others, we'd want to enable someone to take over that one package. > What may be useful, would be to queue the request for the owner of the > regarding package, so that a maintainer can ask another maintainer via the > packageDB for a package and then it is transfered. > Sure. That would work for me. Something like: "Request Ownership" => Request queued with the Package Owner and Admins able to approve it. Note that I don't consider requesting ownership of an owned package an essential feature for the initial incarnation. Queuing or requests could be implemented later. > > Maintainer transfer => Present owner should be able to reassign to a new > > owner within cvsextras. > > I think that this transfer should be acknowleged by the new owner before it > takes place, to make sure it is wanted by both sides. I could go either way. If the new owner doesn't want it, all they have to do is drop ownership (Or send it back) so I don't think acknowledging the package is uber-important. -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 oliver at linux-kernel.at Mon Feb 26 08:37:24 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 26 Feb 2007 09:37:24 +0100 Subject: owners.list Message-ID: <45E29C44.5090701@linux-kernel.at> Can someone with write permissions please change the following: RCS file: /cvs/extras/owners/owners.list,v retrieving revision 1.2380 diff -r1.2380 owners.list 2551c2551 < Fedora Extras|syck|YAML for C, Python, and PHP|oliver at linux-kernel.at|extras-qa at fedoraproject.org| --- > Fedora Extras|syck|YAML for C, Python, and PHP|tibbs at math.uh.edu|extras-qa at fedoraproject.org|oliver at linux-kernel.at Thanks, Oliver From jkeating at redhat.com Mon Feb 26 13:51:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 08:51:19 -0500 Subject: Future owners/ACL choices In-Reply-To: <1172463370.4097.23.camel@localhost.localdomain> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241414.16831.jkeating@redhat.com> <1172463370.4097.23.camel@localhost.localdomain> Message-ID: <200702260851.19590.jkeating@redhat.com> On Sunday 25 February 2007 23:16, Toshio Kuratomi wrote: > Your example brings up an important but tangential point, however: In > the merged Core + Extras world (aka allowing community outside of Red > Hat to maintain "Core" packages) someone within Red Hat could leave Red > Hat and still want to maintain their packages for Fedora. ?In many > cases, this would be a good thing. ?So changing owners should still go > through some sort of process even when the maintainer involved is from > within Red Hat (not just have a rel-engineer make the change when the > Red Hatter takes another job.) While in theory this sounds good, but in practice I can really see those that leave RH or move to a different job within RH not wanting to keep up their Fedora packages, and in some cases not be able to communicate that or interact with that correctly (@redhat.com email address no longer valid, etc..) While it would be best if the process is followed, there needs to be some room for rel-eng interaction. There may be many packages maintained within Fedora purely by assignment. A RH manager assigns maintainership of given packages to given people, from Fedora to RHEL to any other product. When reassignment happens, it would be for the whole tree, not just the RHEL side. These aren't so much 'volunteers' so many of the rules/ideals don't apply. -- 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 tibbs at math.uh.edu Mon Feb 26 14:55:36 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Feb 2007 08:55:36 -0600 Subject: owners.list In-Reply-To: <45E29C44.5090701@linux-kernel.at> References: <45E29C44.5090701@linux-kernel.at> Message-ID: >>>>> "OF" == Oliver Falk writes: >> Fedora Extras|syck|YAML for C, Python, and PHP> tibbs at math.uh.edu|extras-qa at fedoraproject.org|oliver at linux-kernel.at Umm, no. I am not in any way the maintainer of syck, nor have I ever wished to be. The only reason my name appears in the changelog is because I did mass rebuilds of many packages due to core python and PHP updates. Since this package needs rebuilding when either changes, I show up a lot. - J< From oliver at linux-kernel.at Mon Feb 26 15:22:53 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 26 Feb 2007 16:22:53 +0100 Subject: owners.list In-Reply-To: References: <45E29C44.5090701@linux-kernel.at> Message-ID: <45E2FB4D.30605@linux-kernel.at> Am 2007-02-26 15:55, Jason L Tibbitts III schrieb: >>>>>> "OF" == Oliver Falk writes: > >>> Fedora Extras|syck|YAML for C, Python, and > PHP> tibbs at math.uh.edu|extras-qa at fedoraproject.org|oliver at linux-kernel.at > > Umm, no. I am not in any way the maintainer of syck, nor have I ever > wished to be. The only reason my name appears in the changelog is > because I did mass rebuilds of many packages due to core python and > PHP updates. Since this package needs rebuilding when either changes, > I show up a lot. k! Havn't thought about this :-) Maybe jima is the one who should be informed then... Jima? You take syck also? Or Steven? As you maintain the perl part also!? Thanks, Oliver From steve at silug.org Mon Feb 26 16:17:09 2007 From: steve at silug.org (Steven Pritchard) Date: Mon, 26 Feb 2007 10:17:09 -0600 Subject: owners.list In-Reply-To: <45E2FB4D.30605@linux-kernel.at> References: <45E29C44.5090701@linux-kernel.at> <45E2FB4D.30605@linux-kernel.at> Message-ID: <20070226161709.GA4401@osiris.silug.org> On Mon, Feb 26, 2007 at 04:22:53PM +0100, Oliver Falk wrote: > Maybe jima is the one who should be informed then... Jima? You take syck > also? > > Or Steven? As you maintain the perl part also!? I'd rather not touch it, but thanks for asking. :-) (If it ends up orphaned, I'd be willing to help with it though.) 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 cweyl at alumni.drew.edu Mon Feb 26 16:54:28 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 26 Feb 2007 08:54:28 -0800 Subject: Future owners/ACL choices In-Reply-To: <200702260851.19590.jkeating@redhat.com> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241414.16831.jkeating@redhat.com> <1172463370.4097.23.camel@localhost.localdomain> <200702260851.19590.jkeating@redhat.com> Message-ID: <7dd7ab490702260854x72cf62f0gf0b2cc014448f698@mail.gmail.com> On 2/26/07, Jesse Keating wrote: > On Sunday 25 February 2007 23:16, Toshio Kuratomi wrote: > > Your example brings up an important but tangential point, however: In > > the merged Core + Extras world (aka allowing community outside of Red > > Hat to maintain "Core" packages) someone within Red Hat could leave Red > > Hat and still want to maintain their packages for Fedora. In many > > cases, this would be a good thing. So changing owners should still go > > through some sort of process even when the maintainer involved is from > > within Red Hat (not just have a rel-engineer make the change when the > > Red Hatter takes another job.) > > While in theory this sounds good, but in practice I can really see those that > leave RH or move to a different job within RH not wanting to keep up their > Fedora packages, and in some cases not be able to communicate that or > interact with that correctly (@redhat.com email address no longer valid, > etc..) > > While it would be best if the process is followed, there needs to be some room > for rel-eng interaction. There may be many packages maintained within Fedora > purely by assignment. A RH manager assigns maintainership of given packages > to given people, from Fedora to RHEL to any other product. When reassignment > happens, it would be for the whole tree, not just the RHEL side. These > aren't so much 'volunteers' so many of the rules/ideals don't apply. Why couldn't this just be handled by the existing AWOL process? In theory, it should be even easier to confirm the AWOL in this case -- another redhatter could ACK the person's departure (assuming they haven't) and the process should go quickly. I'm not seeing the need for two sets of rules, one for @redhat and one for everyone else; isn't that what we're trying to move away from? Of course, this discussion is also assuming that the theoretical person in question won't be responsible and take the minimum step of "see ya, have fun with my packages" :) -Chris -- Chris Weyl Ex astris, scientia From jkeating at redhat.com Mon Feb 26 17:08:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 12:08:08 -0500 Subject: Future owners/ACL choices In-Reply-To: <7dd7ab490702260854x72cf62f0gf0b2cc014448f698@mail.gmail.com> References: <1172336630.4472.411.camel@localhost.localdomain> <200702260851.19590.jkeating@redhat.com> <7dd7ab490702260854x72cf62f0gf0b2cc014448f698@mail.gmail.com> Message-ID: <200702261208.08799.jkeating@redhat.com> On Monday 26 February 2007 11:54, Chris Weyl wrote: > Why couldn't this just be handled by the existing AWOL process? ?In > theory, it should be even easier to confirm the AWOL in this case -- > another redhatter could ACK the person's departure (assuming they > haven't) and the process should go quickly. ?I'm not seeing the need > for two sets of rules, one for @redhat and one for everyone else; > isn't that what we're trying to move away from? Depends on how quickly this can be done and how many hoops one would have to jump through. Please bear in mind that I'm trying to find middle ground between a ton of volunteers and rules that apply to such and employees that are assigned to work on things. > Of course, this discussion is also assuming that the theoretical > person in question won't be responsible and take the minimum step of > "see ya, have fun with my packages" :) In the rare case the person was terminated, they may not be able to send such things. A manager could, but then again a manager probably already knows who is going to take on the orphaned 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 notting at redhat.com Mon Feb 26 17:05:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 26 Feb 2007 12:05:46 -0500 Subject: Future owners/ACL choices In-Reply-To: <200702241305.53007.jkeating@redhat.com> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> Message-ID: <20070226170546.GF24833@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > I like this. Orphaned packages could default back to open for any Extras > contributor. What I'm concerned about here is what to do with orphaned packages from a repository standpoint - should they be removed? Should builds go to some sort of limbo? I'm mostly of the opinion that they shouldn't be kept limping indefinitely without an *actual* owner. Bill From rc040203 at freenet.de Mon Feb 26 17:15:24 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 26 Feb 2007 18:15:24 +0100 Subject: Future owners/ACL choices In-Reply-To: <20070226170546.GF24833@nostromo.devel.redhat.com> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> <20070226170546.GF24833@nostromo.devel.redhat.com> Message-ID: <1172510124.23237.630.camel@mccallum.corsepiu.local> On Mon, 2007-02-26 at 12:05 -0500, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > I like this. Orphaned packages could default back to open for any Extras > > contributor. > > What I'm concerned about here is what to do with orphaned packages > from a repository standpoint - should they be removed? Should > builds go to some sort of limbo? > > I'm mostly of the opinion that they shouldn't be kept limping indefinitely > without an *actual* owner. Check how FE has handled this: http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers I don't see why this should not be applicable in future. One problem however: The ACLs prevent volunteers from stepping in and to take over rsp. to remove a package. Ralf From notting at redhat.com Mon Feb 26 17:25:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 26 Feb 2007 12:25:33 -0500 Subject: Future owners/ACL choices In-Reply-To: <1172510124.23237.630.camel@mccallum.corsepiu.local> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> <20070226170546.GF24833@nostromo.devel.redhat.com> <1172510124.23237.630.camel@mccallum.corsepiu.local> Message-ID: <20070226172533.GA26214@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > > I'm mostly of the opinion that they shouldn't be kept limping indefinitely > > without an *actual* owner. > > Check how FE has handled this: > http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers > > I don't see why this should not be applicable in future. > > One problem however: The ACLs prevent volunteers from stepping in and to > take over rsp. to remove a package. Sure, that's how to *obtain* ownership if you desire it, and Toshio has mentioned in this thread how he'd like to make that step easy. What I'm concerned about is packages remaining orphaned long-term, because either no one wants to maintain them, or not maintain them more than a rebuild for depedencies, etc. That's not really covered here. Another point is that we probably need to set up an official place where people can watch and track owner changes, package changes, etc to orphaned packages, much in the same way that owners get all the commits to their own packages now. Bill From ville.skytta at iki.fi Mon Feb 26 17:55:58 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 26 Feb 2007 19:55:58 +0200 Subject: Future owners/ACL choices In-Reply-To: <20070226172533.GA26214@nostromo.devel.redhat.com> References: <1172336630.4472.411.camel@localhost.localdomain> <1172510124.23237.630.camel@mccallum.corsepiu.local> <20070226172533.GA26214@nostromo.devel.redhat.com> Message-ID: <200702261955.58530.ville.skytta@iki.fi> On Monday 26 February 2007, Bill Nottingham wrote: > Ralf Corsepius (rc040203 at freenet.de) said: > > > > Check how FE has handled this: > > http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers > > > > I don't see why this should not be applicable in future. > > > > One problem however: The ACLs prevent volunteers from stepping in and to > > take over rsp. to remove a package. > > Sure, that's how to *obtain* ownership if you desire it, and Toshio > has mentioned in this thread how he'd like to make that step easy. > > What I'm concerned about is packages remaining orphaned long-term, > because either no one wants to maintain them, or not maintain > them more than a rebuild for depedencies, etc. That's not really > covered here. During the FE preparations for FC6 [1], we pruned packages which were known to be orphaned from the repositories unless they got unorphaned in timely manner. I think this would be a good strategy to apply by default before every release, but perhaps earlier than was done in the above case, eg. somewhere between test2 and test3. [1] http://fedoraproject.org/wiki/Extras/Schedule/FC6MassRebuild From kevin at tummy.com Mon Feb 26 18:00:43 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 26 Feb 2007 11:00:43 -0700 Subject: Future owners/ACL choices In-Reply-To: <20070226172533.GA26214@nostromo.devel.redhat.com> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> <20070226170546.GF24833@nostromo.devel.redhat.com> <1172510124.23237.630.camel@mccallum.corsepiu.local> <20070226172533.GA26214@nostromo.devel.redhat.com> Message-ID: <20070226110043.37210f26@ningauble.scrye.com> On Mon, 26 Feb 2007 12:25:33 -0500 notting at redhat.com (Bill Nottingham) wrote: > Ralf Corsepius (rc040203 at freenet.de) said: > > > I'm mostly of the opinion that they shouldn't be kept limping > > > indefinitely without an *actual* owner. > > > > Check how FE has handled this: > > http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers > > > > I don't see why this should not be applicable in future. > > > > One problem however: The ACLs prevent volunteers from stepping in > > and to take over rsp. to remove a package. > > Sure, that's how to *obtain* ownership if you desire it, and Toshio > has mentioned in this thread how he'd like to make that step easy. > > What I'm concerned about is packages remaining orphaned long-term, > because either no one wants to maintain them, or not maintain > them more than a rebuild for depedencies, etc. That's not really > covered here. Yeah, there needs to be periodic 'culling' of the orphans. If they haven't been picked up in a while (how long?) they should get: - removed from the repository (all branches?) - all open bugs closed with 'this package isn't maintained anymore, sorry' - bugzilla component removed? - cvs rm'ed and dead.package put in place. Perhaps that could be automated somehow? Of course it's possible that removing an orphan will break a non orphan package, so what do we do there? Let it be broken and the maintainer can bring the orphan back if they want? We could do it something like a week before test3 every cycle? or Just try and run it once a week or something? Right now there are over 100 orphans that should get cleaned out... > Another point is that we probably need to set up an official place > where people can watch and track owner changes, package changes, etc > to orphaned packages, much in the same way that owners get all the > commits to their own packages now. Yeah, if this was done via script it could mail a report to maintainers? and/or have a fedora people feed to post what orphans were nuked? > Bill kevin -------------- 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 Mon Feb 26 18:33:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 13:33:37 -0500 Subject: Slight slip of Fedora 7 Test 2 Message-ID: <200702261333.37545.jkeating@redhat.com> We've ran into some kernel difficulties on PPC, some VNC issues, and more fun with figuring out what to spin and how. As such we were not able to have a tree ready on Friday for the mirrors to sync. We cannot release Tomorrow. We expect to have a final tree done (late?) today to give to the mirrors for a Thursday (March 1st) release. -- 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 Feb 26 19:23:14 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 26 Feb 2007 13:23:14 -0600 Subject: Future owners/ACL choices In-Reply-To: <1172464393.4097.40.camel@localhost.localdomain> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> <1172343327.4472.443.camel@localhost.localdomain> <200702242036.06553.opensource@till.name> <1172464393.4097.40.camel@localhost.localdomain> Message-ID: <1172517794.21659.1.camel@vader.jdub.homelinux.org> On Sun, 2007-02-25 at 20:33 -0800, Toshio Kuratomi wrote: > On Sat, 2007-02-24 at 20:35 +0100, Till Maas wrote: > > On Samstag 24 Februar 2007, Toshio Kuratomi wrote: > > > > > Maintainer requesting ownership of an owned package => request is queued > > > > When is there a need for a maintainer to get ownership of another package > > without wanting the original owner to transfer it? The only case I can think > > of is when the actual owner of a package is AWOL. But in this case it should > > be made sure that all of his packages are taken care of, so that the correct > > workflow should be a request to orphan all packages of a maintainer and then > > pick the package one wants to adopt. > > There could be other instances as well. If Dave Jones were to go AWOL, > for instance, and he had no comaintainers, we'd certainly want to fast > track someone onto the kernel package no matter what the state of his > other packages. Bad example. Dave has a GPS unit embedded into him that the Fedora Orbital Laser is constantly tracking. He can't go AWOL, or he and everyone within 5 km of him will be incinerated. Oh wait... I wasn't supposed to say that. MUAHAHAHAHHA josh From bugs.michael at gmx.net Mon Feb 26 19:46:37 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 26 Feb 2007 20:46:37 +0100 Subject: Future owners/ACL choices In-Reply-To: <20070226110043.37210f26@ningauble.scrye.com> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> <20070226170546.GF24833@nostromo.devel.redhat.com> <1172510124.23237.630.camel@mccallum.corsepiu.local> <20070226172533.GA26214@nostromo.devel.redhat.com> <20070226110043.37210f26@ningauble.scrye.com> Message-ID: <20070226204637.c8bc4f96.bugs.michael@gmx.net> On Mon, 26 Feb 2007 11:00:43 -0700, Kevin Fenzi wrote: > Yeah, there needs to be periodic 'culling' of the orphans. > If they haven't been picked up in a while (how long?) they should get: > > - removed from the repository (all branches?) Of course! All branches! Else it creates broken upgrades and bug reports that go to "orphan owner". We've had a few cases where somebody run into such a case. The "orphan owner" in bugzilla is like /dev/null when nobody monitors that address and answers in bugzilla. It is easy to re-add a package to an active branch when a new maintainer is found. > - all open bugs closed with 'this package isn't maintained anymore, > sorry' Plus the obligatory pointer to the documentation on how to sign up as a contributor in case there is interest in becoming the new package maintainer. > - bugzilla component removed? Would that be limited to components which don't contain any tickets yet? > - cvs rm'ed and dead.package put in place. > > Perhaps that could be automated somehow? > Of course it's possible that removing an orphan will break a non orphan > package, so what do we do there? Let it be broken and the maintainer > can bring the orphan back if they want? Is that a problem? Removing the orphans would create a broken deps report in that case and mail all package owners that depend on the orphan. If it happens early enough, there should be plenty of time to find a new owner and rebuild the package. From mattdm at mattdm.org Mon Feb 26 20:20:54 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 26 Feb 2007 15:20:54 -0500 Subject: firefox 1.5.0.10 update timeframe? Message-ID: <20070226202054.GA11121@jadzia.bu.edu> As I'm sure everyone knows, the Red Hat Enterprise Linux errata for this is already out, and marked as critical. No sign of a corresponding update for any of the supported Fedora versions. Please let's not have this be another one of those cases where Fedora's Firefox is vulnerable for weeks. It is, frankly, embarrassing. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Mon Feb 26 20:36:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 15:36:04 -0500 Subject: firefox 1.5.0.10 update timeframe? In-Reply-To: <20070226202054.GA11121@jadzia.bu.edu> References: <20070226202054.GA11121@jadzia.bu.edu> Message-ID: <200702261536.04915.jkeating@redhat.com> On Monday 26 February 2007 15:20, Matthew Miller wrote: > As I'm sure everyone knows, the Red Hat Enterprise Linux errata for this is > already out, and marked as critical. No sign of a corresponding update for > any of the supported Fedora versions. Please let's not have this be another > one of those cases where Fedora's Firefox is vulnerable for weeks. It is, > frankly, embarrassing. I'm working on a push right now. However I think some build issues on ppc64 is preventing the fc6 to go out. Stransky is still working on 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 mattdm at mattdm.org Mon Feb 26 20:34:57 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 26 Feb 2007 15:34:57 -0500 Subject: firefox 1.5.0.10 update timeframe? In-Reply-To: <200702261536.04915.jkeating@redhat.com> References: <20070226202054.GA11121@jadzia.bu.edu> <200702261536.04915.jkeating@redhat.com> Message-ID: <20070226203457.GA12866@jadzia.bu.edu> On Mon, Feb 26, 2007 at 03:36:04PM -0500, Jesse Keating wrote: > I'm working on a push right now. However I think some build issues on ppc64 > is preventing the fc6 to go out. Stransky is still working on it. Glad to hear it. Thanks for the update. And mark this down under yet another reason to move ppc to secondary arch status. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Mon Feb 26 20:36:17 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 26 Feb 2007 15:36:17 -0500 Subject: firefox 1.5.0.10 update timeframe? In-Reply-To: <20070226203457.GA12866@jadzia.bu.edu> References: <20070226202054.GA11121@jadzia.bu.edu> <200702261536.04915.jkeating@redhat.com> <20070226203457.GA12866@jadzia.bu.edu> Message-ID: <20070226203617.GA13136@jadzia.bu.edu> On Mon, Feb 26, 2007 at 03:34:57PM -0500, Matthew Miller wrote: > > I'm working on a push right now. However I think some build issues on > > ppc64 is preventing the fc6 to go out. Stransky is still working on it. > Glad to hear it. Thanks for the update. > And mark this down under yet another reason to move ppc to secondary arch > status. :) Actually -- is it possible to put updates into updates/testing even if there's build problems on any specific arch? That might be a way to approach this in the future. (Or this time, even, if the ppc64 build issue can't be resolved quickly.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ville.skytta at iki.fi Mon Feb 26 20:39:29 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 26 Feb 2007 22:39:29 +0200 Subject: Future owners/ACL choices In-Reply-To: <20070226204637.c8bc4f96.bugs.michael@gmx.net> References: <1172336630.4472.411.camel@localhost.localdomain> <20070226110043.37210f26@ningauble.scrye.com> <20070226204637.c8bc4f96.bugs.michael@gmx.net> Message-ID: <200702262239.29528.ville.skytta@iki.fi> On Monday 26 February 2007, Michael Schwendt wrote: > On Mon, 26 Feb 2007 11:00:43 -0700, Kevin Fenzi wrote: > > Yeah, there needs to be periodic 'culling' of the orphans. > > If they haven't been picked up in a while (how long?) they should get: > > > > - removed from the repository (all branches?) > > Of course! All branches! Else it creates broken upgrades and bug reports > that go to "orphan owner". That's only a partial solution, it won't help people who installed it while it was available which is very confusing. IMO that'd make it a no go; instead either 1) Never remove orphaned packages from non-devel distros only because they're orphaned, and do document whatever there is to document about them in the next release notes (at least a list with a caveat that it is possible that some of them will reappear later and thus the accuracy of the information is likely to decrease as time passes from the release date), or 2) Arrange a way to have the orphaned packages removed or at least suggested to be removed from end user systems at the time they disappear from repositories. Far from nice in the first place, and possibly a PITA if one has local/3rd party packages that have dependencies to removed stuff. > > Of course it's possible that removing an orphan will break a non orphan > > package, so what do we do there? Let it be broken and the maintainer > > can bring the orphan back if they want? > > Is that a problem? Removing the orphans would create a broken deps report > in that case and mail all package owners that depend on the orphan. If it > happens early enough, there should be plenty of time to find a new owner > and rebuild the package. This is certainly not something I'd like to see in non-devel distros, especially if the mindset for fixing the resulting broken dep chains is that there's "plenty of time" to do it. But perhaps that's not what you meant for non-devel distros? From jkeating at redhat.com Mon Feb 26 20:44:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 15:44:35 -0500 Subject: firefox 1.5.0.10 update timeframe? In-Reply-To: <20070226203617.GA13136@jadzia.bu.edu> References: <20070226202054.GA11121@jadzia.bu.edu> <20070226203457.GA12866@jadzia.bu.edu> <20070226203617.GA13136@jadzia.bu.edu> Message-ID: <200702261544.36153.jkeating@redhat.com> On Monday 26 February 2007 15:36, Matthew Miller wrote: > Actually -- is it possible to put updates into updates/testing even if > there's build problems on any specific arch? That might be a way to > approach this in the future. (Or this time, even, if the ppc64 build issue > can't be resolved quickly.) Eeew. While technically there is, I'd rather not go down this road. -- 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 tibbs at math.uh.edu Mon Feb 26 20:46:38 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Feb 2007 14:46:38 -0600 Subject: Future owners/ACL choices In-Reply-To: <20070226204637.c8bc4f96.bugs.michael@gmx.net> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> <20070226170546.GF24833@nostromo.devel.redhat.com> <1172510124.23237.630.camel@mccallum.corsepiu.local> <20070226172533.GA26214@nostromo.devel.redhat.com> <20070226110043.37210f26@ningauble.scrye.com> <20070226204637.c8bc4f96.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Of course! All branches! Sorry, this would be a terrible idea. The security team may still need to push a fix to the package, which isn't possible to do unless the sources are still there. - J< From mattdm at mattdm.org Mon Feb 26 20:48:02 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 26 Feb 2007 15:48:02 -0500 Subject: firefox 1.5.0.10 update timeframe? In-Reply-To: <200702261544.36153.jkeating@redhat.com> References: <20070226202054.GA11121@jadzia.bu.edu> <20070226203457.GA12866@jadzia.bu.edu> <20070226203617.GA13136@jadzia.bu.edu> <200702261544.36153.jkeating@redhat.com> Message-ID: <20070226204802.GA13949@jadzia.bu.edu> On Mon, Feb 26, 2007 at 03:44:35PM -0500, Jesse Keating wrote: > > Actually -- is it possible to put updates into updates/testing even if > > there's build problems on any specific arch? That might be a way to > > approach this in the future. (Or this time, even, if the ppc64 build issue > > can't be resolved quickly.) > Eeew. While technically there is, I'd rather not go down this road. I understand your Release Ninja disgust. :) However, from the user-supporting point of view it sucks to completely hold up security updates for platform specific build problems. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Mon Feb 26 20:54:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 15:54:25 -0500 Subject: firefox 1.5.0.10 update timeframe? In-Reply-To: <20070226204802.GA13949@jadzia.bu.edu> References: <20070226202054.GA11121@jadzia.bu.edu> <200702261544.36153.jkeating@redhat.com> <20070226204802.GA13949@jadzia.bu.edu> Message-ID: <200702261554.25698.jkeating@redhat.com> On Monday 26 February 2007 15:48, Matthew Miller wrote: > I understand your Release Ninja disgust. :) However, from the > user-supporting point of view it sucks to completely hold up security > updates for platform specific build problems. Yes it does. It also sucks for the ppc users to tell them right now that they don't matter as much to us. If we can't get this resolved today/tomorrow, we'll probably have to look at something like doing the other arches first. -- 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 mattdm at mattdm.org Mon Feb 26 21:04:32 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 26 Feb 2007 16:04:32 -0500 Subject: firefox 1.5.0.10 update timeframe? In-Reply-To: <200702261554.25698.jkeating@redhat.com> References: <20070226202054.GA11121@jadzia.bu.edu> <200702261544.36153.jkeating@redhat.com> <20070226204802.GA13949@jadzia.bu.edu> <200702261554.25698.jkeating@redhat.com> Message-ID: <20070226210432.GA15418@jadzia.bu.edu> On Mon, Feb 26, 2007 at 03:54:25PM -0500, Jesse Keating wrote: > Yes it does. It also sucks for the ppc users to tell them right now that > they don't matter as much to us. Well, it's not like you're not working on it. I'd say the same thing if it were x86_64. Or, uh, if it built on x86_64 but not i386. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tibbs at math.uh.edu Mon Feb 26 21:05:50 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Feb 2007 15:05:50 -0600 Subject: firefox 1.5.0.10 update timeframe? In-Reply-To: <200702261554.25698.jkeating@redhat.com> References: <20070226202054.GA11121@jadzia.bu.edu> <200702261544.36153.jkeating@redhat.com> <20070226204802.GA13949@jadzia.bu.edu> <200702261554.25698.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> It also sucks for the ppc users to tell them right now that they JK> don't matter as much to us. I'm having trouble getting from: A) We're sorry, but currently we're currently not able to build the updated firefox on PPC64. We've released it to other architectures now and are still working on getting it to build on all of them. to: B) You don't matter as much to us. This isn't about secondary arches. If the roles were reversed and it build fine on PPC64 but not i386, I'd advocate shipping it for PPC64. - J< From bugs.michael at gmx.net Mon Feb 26 21:13:39 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 26 Feb 2007 22:13:39 +0100 Subject: Future owners/ACL choices In-Reply-To: <200702262239.29528.ville.skytta@iki.fi> References: <1172336630.4472.411.camel@localhost.localdomain> <20070226110043.37210f26@ningauble.scrye.com> <20070226204637.c8bc4f96.bugs.michael@gmx.net> <200702262239.29528.ville.skytta@iki.fi> Message-ID: <20070226221339.ac68380b.bugs.michael@gmx.net> On Mon, 26 Feb 2007 22:39:29 +0200, Ville Skytt? wrote: > > > Of course it's possible that removing an orphan will break a non orphan > > > package, so what do we do there? Let it be broken and the maintainer > > > can bring the orphan back if they want? > > > > Is that a problem? Removing the orphans would create a broken deps report > > in that case and mail all package owners that depend on the orphan. If it > > happens early enough, there should be plenty of time to find a new owner > > and rebuild the package. > > This is certainly not something I'd like to see in non-devel distros, > especially if the mindset for fixing the resulting broken dep chains is that > there's "plenty of time" to do it. But perhaps that's not what you meant for > non-devel distros? Restoring the packages (after running into unexpected broken deps) could be as easy as copying them into the repository or resubmitting a build job for the last known tag. In my view, "broken deps" imply that there are package owners, who depend on the orphans and who need to decide on what to do with the orphans. The least thing that should happen for non-devel branches is to put these package owners into the Cc field of the orphans. From bugs.michael at gmx.net Mon Feb 26 21:18:44 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 26 Feb 2007 22:18:44 +0100 Subject: Future owners/ACL choices In-Reply-To: References: <1172336630.4472.411.camel@localhost.localdomain> <200702241305.53007.jkeating@redhat.com> <20070226170546.GF24833@nostromo.devel.redhat.com> <1172510124.23237.630.camel@mccallum.corsepiu.local> <20070226172533.GA26214@nostromo.devel.redhat.com> <20070226110043.37210f26@ningauble.scrye.com> <20070226204637.c8bc4f96.bugs.michael@gmx.net> Message-ID: <20070226221844.93fefa7d.bugs.michael@gmx.net> On 26 Feb 2007 14:46:38 -0600, Jason L Tibbitts III wrote: > MS> Of course! All branches! > > Sorry, this would be a terrible idea. The security team may still > need to push a fix to the package, which isn't possible to do unless > the sources are still there. They are still in CVS. And do you say that the security team takes over orphaned packages? From braden at endoframe.com Mon Feb 26 21:20:21 2007 From: braden at endoframe.com (Braden McDaniel) Date: Mon, 26 Feb 2007 16:20:21 -0500 Subject: firefox 1.5.0.10 update timeframe? In-Reply-To: <200702261536.04915.jkeating@redhat.com> References: <20070226202054.GA11121@jadzia.bu.edu> <200702261536.04915.jkeating@redhat.com> Message-ID: <45E34F15.3@endoframe.com> Jesse Keating wrote: > On Monday 26 February 2007 15:20, Matthew Miller wrote: >> As I'm sure everyone knows, the Red Hat Enterprise Linux errata for this is >> already out, and marked as critical. No sign of a corresponding update for >> any of the supported Fedora versions. Please let's not have this be another >> one of those cases where Fedora's Firefox is vulnerable for weeks. It is, >> frankly, embarrassing. > > I'm working on a push right now. However I think some build issues on ppc64 > is preventing the fc6 to go out. Stransky is still working on it. Can the fix for bug 227262 get rolled into this? If not, what else needs to be done for this to be fixed? It's a regression (introduced in 1.5.0.9-2) that stands to break things that have firefox-devel as a dependency. A patch has been provided. Braden From bpepple at fedoraproject.org Mon Feb 26 21:53:45 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 26 Feb 2007 16:53:45 -0500 Subject: FESCo Meeting Summary for 2007-02-22 Message-ID: <1172526825.16039.5.camel@Chuck> Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (ch4chris) * Tom Callaway (spot) * Warren Togami (warren) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Jesse Keating (f13) * Jeremy Katz (jeremy) Members Absent * Andreas Bierfert (awjb) * Josh Boyer (jwb) == Summary == awjb * Andreas has decided to step down from FESCo due to time constraints with his university work. Core/Extras Merge * FESCo ratified the new Package Review process. For more details refer to https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00380.html Co-Maintainers * FESCo ratified the co-maintainers guidelines. http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership Sponsor Nominations * Parag Ashok Nemade, Andrew Overholt, Thomas Fitzsimmons, and Chitlesh Goorahwas were nominated and accepted as new sponsors. Packaging Committee Report * FESCo didn't have any objections to the Packaging Committee's guidelines regarding: SourceURL: http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070222 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 chitlesh at fedoraproject.org Mon Feb 26 23:04:19 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 27 Feb 2007 00:04:19 +0100 Subject: wxGTK2 status and testing In-Reply-To: <20070223165928.1214f9be.bugs.michael@gmx.net> References: <20070219111646.abfa4780.bugs.michael@gmx.net> <20070219140117.GA13340@jadzia.bu.edu> <20070219152248.81038ee4.bugs.michael@gmx.net> <1171895240.5333.1.camel@scriabin.tannenrauch.ch> <20070220103918.12549d0f.bugs.michael@gmx.net> <13dbfe4f0702201347i52ec648cx49bd031a134601bc@mail.gmail.com> <20070223165928.1214f9be.bugs.michael@gmx.net> Message-ID: <13dbfe4f0702261504i7acec75bs785cb292fd887ec1@mail.gmail.com> On 2/23/07, Michael Schwendt wrote: > freeglut in devel seems broken. Package has not been touched or rebuilt > since Tue 29 Aug 2006. That's a first blocker for toped. > > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libglut.so: undefined reference to `glXGetCurrentContext' True, http://buildsys.fedoraproject.org/logs/fedora-development-extras/28337-toped-0.8.2-8.fc7/ppc/build.log my src.rpm built against compat-wxGTK26 on fc6 is working fine. Hans, can you update freeglut in development repositories ? Chitlesh -- http://clunixchit.blogspot.com From bugs.michael at gmx.net Mon Feb 26 23:48:30 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 27 Feb 2007 00:48:30 +0100 Subject: wxGTK2 status and testing In-Reply-To: <13dbfe4f0702261504i7acec75bs785cb292fd887ec1@mail.gmail.com> References: <20070219111646.abfa4780.bugs.michael@gmx.net> <20070219140117.GA13340@jadzia.bu.edu> <20070219152248.81038ee4.bugs.michael@gmx.net> <1171895240.5333.1.camel@scriabin.tannenrauch.ch> <20070220103918.12549d0f.bugs.michael@gmx.net> <13dbfe4f0702201347i52ec648cx49bd031a134601bc@mail.gmail.com> <20070223165928.1214f9be.bugs.michael@gmx.net> <13dbfe4f0702261504i7acec75bs785cb292fd887ec1@mail.gmail.com> Message-ID: <20070227004830.a3805971.bugs.michael@gmx.net> On Tue, 27 Feb 2007 00:04:19 +0100, Chitlesh GOORAH wrote: > On 2/23/07, Michael Schwendt wrote: > > > freeglut in devel seems broken. Package has not been touched or rebuilt > > since Tue 29 Aug 2006. That's a first blocker for toped. > > > > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libglut.so: undefined reference to `glXGetCurrentContext' > > True, > http://buildsys.fedoraproject.org/logs/fedora-development-extras/28337-toped-0.8.2-8.fc7/ppc/build.log > > my src.rpm built against compat-wxGTK26 on fc6 is working fine. > > Hans, can you update freeglut in development repositories ? This is multiple issues at once. See #229808 and my reply to the "Extras x86_64 rawhide rebuild in mock status 2007-02-26" on fedora-devel-list: | This needs the fixed Mesa (6.5.2-6) to appear in Rawhide first. | Else freeglut fails. From a.badger at gmail.com Mon Feb 26 23:24:27 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 26 Feb 2007 15:24:27 -0800 Subject: Future owners/ACL choices In-Reply-To: <7dd7ab490702260854x72cf62f0gf0b2cc014448f698@mail.gmail.com> References: <1172336630.4472.411.camel@localhost.localdomain> <200702241414.16831.jkeating@redhat.com> <1172463370.4097.23.camel@localhost.localdomain> <200702260851.19590.jkeating@redhat.com> <7dd7ab490702260854x72cf62f0gf0b2cc014448f698@mail.gmail.com> Message-ID: <1172532267.13034.40.camel@localhost.localdomain> On Mon, 2007-02-26 at 08:54 -0800, Chris Weyl wrote: > On 2/26/07, Jesse Keating wrote: > > On Sunday 25 February 2007 23:16, Toshio Kuratomi wrote: > > > Your example brings up an important but tangential point, however: In > > > the merged Core + Extras world (aka allowing community outside of Red > > > Hat to maintain "Core" packages) someone within Red Hat could leave Red > > > Hat and still want to maintain their packages for Fedora. In many > > > cases, this would be a good thing. So changing owners should still go > > > through some sort of process even when the maintainer involved is from > > > within Red Hat (not just have a rel-engineer make the change when the > > > Red Hatter takes another job.) > > > > While in theory this sounds good, but in practice I can really see those that > > leave RH or move to a different job within RH not wanting to keep up their > > Fedora packages, and in some cases not be able to communicate that or > > interact with that correctly (@redhat.com email address no longer valid, > > etc..) > > > > While it would be best if the process is followed, there needs to be some room > > for rel-eng interaction. There may be many packages maintained within Fedora > > purely by assignment. A RH manager assigns maintainership of given packages > > to given people, from Fedora to RHEL to any other product. When reassignment > > happens, it would be for the whole tree, not just the RHEL side. These > > aren't so much 'volunteers' so many of the rules/ideals don't apply. > > Why couldn't this just be handled by the existing AWOL process? In > theory, it should be even easier to confirm the AWOL in this case -- > another redhatter could ACK the person's departure (assuming they > haven't) and the process should go quickly. I'm not seeing the need > for two sets of rules, one for @redhat and one for everyone else; > isn't that what we're trying to move away from? > I agree with keeping a single set of rules that apply to everyone. However, we may be in more of a hurry with some packages than for others. We wouldn't want rpm to hang around for years with no maintainer, would we? ;-) So we should have some way to expedite the AWOL process. Or a way to expedite putting a new person in as a co-maintainer while the AWOL process is proceeding as normal. Some way that will allow us to switch Red Hat maintainers around efficiently but at the same time is general enough that it can apply to anyone in the community and can deal with the fact that just because you work for Red Hat doesn't always mean you only care about your packages because it's your job. So -- existing AWOL needs to be enhanced to make this case work in a timely fashion but there still needs to be more of a process than "Red Hat Manager says to change so we made it so." -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 Feb 27 00:40:10 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 26 Feb 2007 19:40:10 -0500 Subject: Build problem Message-ID: <1172536810.28372.8.camel@localhost.localdomain> I'm having wacko problems with xmldiff: http://buildsys.fedoraproject.org/logs/fedora-development-extras/28338-xmldiff-0.6.8-2.fc7/ The build error is caused by the unit tests that run as part of the package's %test phase. These errors do not occur in an i386 build when I run "make mockbuild" on my dual-core i686 box. Kevin Fenzi kindly tried the build on his x86_64, and he can build both the x86_64 and the i386 version without problems. Although the logs in question show a PPC failure, this package actually built fine for Kevin on his ppc32 as well. Advice? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 Feb 27 00:40:49 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 26 Feb 2007 19:40:49 -0500 Subject: Fedora Developer Ranking System v1 Message-ID: <45E37E11.7080805@redhat.com> ================================================== = Strawman of Fedora Developer Ranking System v1 = ================================================== This concept document contains only *IDEAS* of why we would want a ranking system, and how a ranking system might be useful. Below are only examples. Please add your ideas to this thread. Any ranking system would be automated as part of augmentations to FAS2 and PackageDB. FAQ === 1) Why ranks? - Merit Ranks provide a visible and better defined way for contributors to "earn" their way up the ladder and gain more responsibilities. - Lower Overhead of Scaling A ranking system enables opportunities for the project to scale without requiring the top ranked developers to be involved in or pay attention to all activities. Lower ranks could have the ability to recognize merit and promote ranks below them. - Who Are You? As the project grows, you can't possibly know all contributors on the other side of the project. Viewing that member's stat page gives you a convenient snapshot of what they are working on, who they work with, who sponsored, who promoted, etc. 2) Isn't this just silly and unnecessary? It depends. Much of the ranking system is just meaningless earning of "gold stars". Many members may happily choose to just ignore the ranking system because the default ranks give them enough permissions to do their jobs. It is important that the interface and policies driving the ranking system do not get in the way of getting things done. I believe the below theoretical system achieves this level of inobtrusiveness. Fedora Developer Ranks ====================== These are only EXAMPLES of ranks and associated permissions. This could be reorganized with additional permissions, fewer permissions, re-arranged permissions, fewer or more ranks, etc. Some of the permissions may be a bad idea. Some of this may be implementable sooner, and others later. FD6: Elder Sponsor (rank of more experienced sponsors) (any better name for this? Chief?) FD5: Sponsor Write access to own packages, open ACL, orphan, and sponsoree ACL control over sponsoree [1] May grant unowned package to anybody (i.e. FD0) [2] FD4: FD3: May invite anybody to fedora-maintainers [3] Write access to own packages, open ACL, orphan [4] Take ownership of orphaned packages FD2: Write access to own packages, open ACL [5] FD1: Package Maintainer (currently cvsextras) May subscribe to fedora-maintainers May orphan your own package FD0: Probationary/Training Write access to own packages only ---: Read-Only Access to Package SCM Please add your ideas of what other responsibilities could be given at the different ranks of trust. Rank Notes ========== - FD0 is new, allowing a safe and convenient way to ease new contributors into the project. They are allowed to touch only what they own. This makes it easy for a sponsor to allow unproven/uncertain new members in, while containing potential damage they might cause by accident or otherwise. NOTE: *ALL* members with any write access at all still require a sponsor. - Sponsors may decide for new members to begin at FD1 because they don't need hand-holding at FD0. - FD1 or FD2 is all you really need if you are interested in maintaining only your own packages, and not other aspects of the project (governance, teamwork, etc). For example, many RH engineers or upstream authors may fall into this category. - FD2 is the equivalent of the current cvsextras. The varying grades FD1 through FD4 are to allow finger grained permissions and a merit earning path within what is currently known as cvsextras. - FESCO is not a rank on the scale, because FESCO has permissions granted by election, and those permissions may be taken away when they step down from FESCO later. Additionally, a FESCO seat does not automatically mean they have more merit than other members (although in many cases they do.) - Additional ranks and definitions may be added later if needed. Promotion ========= Each rank will have formal written description of rough requirements and responsibilities. (Example: FD3 requires 17 quality reviews or 9 owned packages and shows clear competence in package guidelines. FD4 requires a history of giving opinions or helping others when needed in addition to other technical requirements...) These descriptions however are only to serve as examples, not hard requirements. Promotions in general are the decision of higher ranked members, who may or may not choose to follow those suggested requirements. Higher ranks however, have higher bars of entry, and all members should hold promoters accountable to their decisions. Promotion Examples (specifics of which should be discussed): - Elder Sponsor is FD6. - Sponsor rank is FD5. - FD5 (using some process) may be promoted to FD6. [6] - FESCO group vote required to promote anybody to FD5. - FESCO members may promote anybody to FD4, unilaterally. - FD6 may promote anybody to FD4, unilaterally. - FD5 may promote anybody to FD4, if three FD5 members agree (in database). - FD5 may promote anybody to FD3, unilaterally. - FD4 may promote anybody to FD3, if three FD4 members agree (in database). - FD4 may promote anybody to FD2, unilaterally. - FD3 may promote anybody to FD2, if two FD3 members agree (in database). - FD2 can't promote anybody. - FD1 can't promote anybody. - FD0 can't promote anybody. What do you think should be requirements and responsibilities of each rank? Demotion Examples ================= - FESCO group decides to demote, with cause. - Sponsor decides to demote (or expel) their sponsored FD0 or FD1 member, with cause. (Although after they have been promoted to FD2+, only FESCO may demote or expel a member.) - Inactivity and AWOL status, per the written guidelines, can lead to losing all ranks as well as package ownership by the decision of FESCO. Things Made Possible by Ranks ============================= - FD ranks can be used in elections. Theoretical Example: Eligible FESCO candidates must be FD3+, but next year FD4+ will be the minimum because our membership pool would have grown. FD1+ may vote in FESCO elections. - Optional Rank-Based ACL As a package owner, I may choose most of my packages to be "open" to FD1 write, because I think it is unnecessary to be so protective. But I may want squirrelmail to be FD3+, or spamassassin to be only me and specific people or other groups that I specify. Package owners should be able to make these kinds of choices. - Paper Trail All sponsorships and promotions are logged in the database. When FESCO wants to look into the merits of a nominated new sponsor, they have convenient and timely access to information by simply viewing the member's status page. At a glance, they can see how many packages they have owned, how many reviews they have done, links to those reviews, who sponsored their membership, who promoted them up the ladder, what other project groups they belong to, etc. - Any other arbitrary policy may be easily created by requiring membership in a FAS2 group. A member of FD4 would also be a member of FD3, FD2, FD1, and FD0. This allows a great deal of flexibility in future automation. Theoretical Groups Outside of FD Ranks ====================================== Other groups will (eventually) exist in FAS2, where permissions can be granted when appropriate. Such groups could also used in optional package ACL's if the owner chooses to make it so. In some cases other parts of Fedora may want to create their own ranking ladder, but that is outside the scope of this concept document. (For example, Infrastructure might choose to have simple ranks, and FI1 may subscribe to fedora-maintainers, while FI3 may invite anybody to fedora-maintainers.) Special Groups -------------- FESCO - voted in by Fedora Developer membership. Security - TBD CVSAdmin - decided by FI Signers - decided by FPB Fedora Sub-Projects ------------------- Infrastructure Docs Translators Package Ownership Groups ------------------------ gecko-maint kernel-maint xorg-maint desktop-maint kde-sig games-sig perl-sig Footnotes ========= [1] - We probably need to define where a sponsor may no longer exert control over a sponsoree. For example, if they have reached FD3, they probably no longer need guardianship, and a group with more authority (like FESCO) should exert decisions if necessary. - RH engineers probably don't want sponsors to be able to modify their packages, like kernel or glibc... although in practice a sponsor wouldn't be so stupid to actually do that. Worthwhile to encode a special enforcement case for such an unlikely event? [2] FD5 being able to grant an unowned package to anybody, especially to a new member that they sponsor, is a powerful way to lower overhead in the project in a safe and controlled manner. [3] We need a low overhead way to let qualified people into fedora-maintainers list. Anybody who has passed the "training" and a sponsor has judged that they understand the guidelines (FD1) may subscribe. Additionally, sufficiently empowered users (FD3?) should at their own discretion be able to invite anybody else to fedora-maintainers. An invitee could include someone who is not a member in the project (no CLA required), but is useful to us in some capacity. [4] IMHO, protecting orphans with ACL is really unnecessary. How is this different than all of the other "open ACL" packages? [5] "open ACL" means any package where the owner chooses not to protect with an ACL. I suspect write access to this belongs in either FD1 or FD2, but I am leaning toward FD2. Why? Because new members in FD1 really have no business touching someone else's package. Most existing cvsextras members would probably land at FD2+ levels, and it is easy enough to become FD2, so is this really an issue? [6] It might be cool if "Sponsors" may be promoted to "Elder Sponsors" not from above, but from below. For example, if fifteen FD3+ members like the work a sponsor is doing, they can become an Elder Sponsor. The difference between FD5 and FD6 (like most other ranks) would be mostly meaningless other than a vote of confidence from peers. From jgarzik at redhat.com Tue Feb 27 00:46:22 2007 From: jgarzik at redhat.com (Jeff Garzik) Date: Mon, 26 Feb 2007 19:46:22 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E37E11.7080805@redhat.com> References: <45E37E11.7080805@redhat.com> Message-ID: <20070227004622.GF4018@devserv.devel.redhat.com> On Mon, Feb 26, 2007 at 07:40:49PM -0500, Warren Togami wrote: > ================================================== > = Strawman of Fedora Developer Ranking System v1 = > ================================================== > This concept document contains only *IDEAS* of why we would want a > ranking system, and how a ranking system might be useful. Below are > only examples. Please add your ideas to this thread. Unfortunately, I think a lot of the larger kernel projects work on distributed trust metrics, something that often makes people sqeamish to post in public. Stuff like "we avoid this guy because he sues everybody he meets" or "we avoid this guy because he is a huge pain to deal with" can be big factors, but not something people will endorse publicly. There are a lot of non-linear, human, biological-esque processes that go into medium and large open source projects. Tough to quantify that. Jeff From wtogami at redhat.com Tue Feb 27 00:57:07 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 26 Feb 2007 19:57:07 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <20070227004622.GF4018@devserv.devel.redhat.com> References: <45E37E11.7080805@redhat.com> <20070227004622.GF4018@devserv.devel.redhat.com> Message-ID: <45E381E3.5070200@redhat.com> Jeff Garzik wrote: > On Mon, Feb 26, 2007 at 07:40:49PM -0500, Warren Togami wrote: >> ================================================== >> = Strawman of Fedora Developer Ranking System v1 = >> ================================================== >> This concept document contains only *IDEAS* of why we would want a >> ranking system, and how a ranking system might be useful. Below are >> only examples. Please add your ideas to this thread. > > Unfortunately, I think a lot of the larger kernel projects work on > distributed trust metrics, something that often makes people sqeamish to > post in public. > > Stuff like "we avoid this guy because he sues everybody he meets" or "we Haven't met anybody like this yet, but if this does happen, this is a much bigger issue than just the scope of a volunteer project.) > avoid this guy because he is a huge pain to deal with" can be big We have a few people like that both inside Red Hat and in Fedora today. =) Differing opinions will always exist, and sometimes these differing opinions are even healthy. (Even if I personally have mild levels of loathing toward them...) If you're talking about somebody following written promotion requirements to the letter, but is otherwise just an malicious asshole, that is why the requirements are not in themselves allowing automatic promotion. Somebody must explicitly choose to upgrade them. If that fails, ultimately some decisions must be made by empowered groups (FESCO or FPB), and others by dictators. We of course would codify the ability for decisions to be overridden when common sense screams it. (FPB can command almost anything, but very rarely has it needed to.) > factors, but not something people will endorse publicly. > > There are a lot of non-linear, human, biological-esque processes that go > into medium and large open source projects. Tough to quantify that. > > Jeff These are valid concerns... and maybe this entire system is just infeasible. I think we should discuss this to find out. Warren Togami wtogami at redhat.com From jspaleta at gmail.com Tue Feb 27 01:11:31 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 26 Feb 2007 16:11:31 -0900 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E37E11.7080805@redhat.com> References: <45E37E11.7080805@redhat.com> Message-ID: <604aa7910702261711u3e6a9b94xea3efcffcb19b3cb@mail.gmail.com> > FD0: Probationary/Training > Write access to own packages only > ---: Read-Only Access to Package SCM Okay, here is what I am specifically interested in. As a package maintainer, I'd like to find a way to get upstream developers for some packages involved as co-maintainers, if they are interested. What I'd like is that initially I'm the primary maintainer, but I'd like to have upstream people who are new to the fedora packaging process be secondary maintainers, so I can work with them inside the SCM until its clear to a sponsor that they can take over primary maintainership, and I can dial back my involvement in that package to a secondary maintainer role. This way I can hopefully train up active maintainers, who are less likely to orphan a package, without burning myself out with packaging duties. I hate watching package submissions from upstream developers languish in review. I've jumped in and taken maintainership over in a couple of cases, to keep the issue of sponsorship from keeping the package out. But obviously that's not ideal, because it doesn't help the upstream developer show necessary competence for sponser review. I'd like to think that some of us more veteran packagers can act as mentors for these people in a way that lets them build a track record of correct action for sponsors to review without holding up the packaging itself. Is the FD0 concept meant to help with this sort of scenario? -jef"so far my curling team has a 5 and 1 winning record. At this rate we are totally going to earn free T-shirts for the spring league, If I had known about the T-shirts in the Fall league I would have actually not goofed-off...well not as much anyways. Because its always about the free T-shirt."spaleta From wtogami at redhat.com Tue Feb 27 05:14:45 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 27 Feb 2007 00:14:45 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <604aa7910702261711u3e6a9b94xea3efcffcb19b3cb@mail.gmail.com> References: <45E37E11.7080805@redhat.com> <604aa7910702261711u3e6a9b94xea3efcffcb19b3cb@mail.gmail.com> Message-ID: <45E3BE45.4010107@redhat.com> Jeff Spaleta wrote: >> FD0: Probationary/Training >> Write access to own packages only >> ---: Read-Only Access to Package SCM > > Okay, here is what I am specifically interested in. As a package > maintainer, I'd like to find a way to get upstream developers for some > packages involved as co-maintainers, if they are interested. What I'd > like is that initially I'm the primary maintainer, but I'd like to > have upstream people who are new to the fedora packaging process be > secondary maintainers, so I can work with them inside the SCM until > its clear to a sponsor that they can take over primary maintainership, > and I can dial back my involvement in that package to a secondary > maintainer role. This way I can hopefully train up active > maintainers, who are less likely to orphan a package, without burning > myself out with packaging duties. This is exactly the desired scenario: using FD0 to scale the project and multiply your efforts many times fold. 1) Existing Fedora contributor owns 50 packages. 2) Find upstream developers who are interested in more directly maintaining their own software in Fedora. 3) Ease them into the process with FD0, connect them to Fedora bug tickets and train them slowly so they aren't overwhelmed. 4) Over time they might feel comfortable in their limited role, and you can reduce your involvement in that package. Some might even choose to expand their involvement in other packages now that they understand the Fedora package process. > > I hate watching package submissions from upstream developers languish > in review. I've jumped in and taken maintainership over in a couple of > cases, to keep the issue of sponsorship from keeping the package out. > But obviously that's not ideal, because it doesn't help the upstream > developer show necessary competence for sponser review. I'd like to > think that some of us more veteran packagers can act as mentors for > these people in a way that lets them build a track record of correct > action for sponsors to review without holding up the packaging itself. > Is the FD0 concept meant to help with this sort of scenario? > Yes! You got it. Warren Togami wtogami at redhat.com From j.w.r.degoede at hhs.nl Tue Feb 27 06:29:58 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Feb 2007 07:29:58 +0100 Subject: wxGTK2 status and testing In-Reply-To: <13dbfe4f0702261504i7acec75bs785cb292fd887ec1@mail.gmail.com> References: <20070219111646.abfa4780.bugs.michael@gmx.net> <20070219140117.GA13340@jadzia.bu.edu> <20070219152248.81038ee4.bugs.michael@gmx.net> <1171895240.5333.1.camel@scriabin.tannenrauch.ch> <20070220103918.12549d0f.bugs.michael@gmx.net> <13dbfe4f0702201347i52ec648cx49bd031a134601bc@mail.gmail.com> <20070223165928.1214f9be.bugs.michael@gmx.net> <13dbfe4f0702261504i7acec75bs785cb292fd887ec1@mail.gmail.com> Message-ID: <45E3CFE6.2050209@hhs.nl> Chitlesh GOORAH wrote: > On 2/23/07, Michael Schwendt wrote: > >> freeglut in devel seems broken. Package has not been touched or rebuilt >> since Tue 29 Aug 2006. That's a first blocker for toped. >> >> /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libglut.so: undefined >> reference to `glXGetCurrentContext' > > True, > http://buildsys.fedoraproject.org/logs/fedora-development-extras/28337-toped-0.8.2-8.fc7/ppc/build.log > > > my src.rpm built against compat-wxGTK26 on fc6 is working fine. > > Hans, can you update freeglut in development repositories ? > Its not a freeglut problem, but a mesa problem. Ajax has acknowledge this and fixed it, once a new mesa hits rawhide it should be fixed. Regards, Hans From j.w.r.degoede at hhs.nl Tue Feb 27 06:54:56 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Feb 2007 07:54:56 +0100 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <1172526825.16039.5.camel@Chuck> References: <1172526825.16039.5.camel@Chuck> Message-ID: <45E3D5C0.5090002@hhs.nl> Brian Pepple wrote: > Packaging Committee Report > * FESCo didn't have any objections to the Packaging Committee's > guidelines regarding: > SourceURL: http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl > Hmm, I added a comment a couple of days ago to the page about the sourceforge section not being correct and that is still there. How can this be approved without that comment being addressed? Regsrds, Hans From mtasaka at ioa.s.u-tokyo.ac.jp Tue Feb 27 06:58:21 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 27 Feb 2007 15:58:21 +0900 Subject: RATIFIED: Review with Flags (Version 6) In-Reply-To: <45DE1D71.7020300@redhat.com> References: <45DE1D71.7020300@redhat.com> Message-ID: <45E3D68D.1040009@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > STOP USING THE TRACKER BUGS. Just leave them as-is. FESCO is thinking > about what to do about them during next week's meeting. Please update: http://fedoraproject.org/wiki/Extras/HowToGetSponsored Current policy is that a new contributor who want to get sponsored have to either * submit a new review request with enough quality * or do a "pre-review" of other person's review requests to show that he surely understands how to package. And this wiki page still uses FE-NEW to find a review request which is waiting to be reviewed. So: please someone update FE-NEW etc to the alternatives. Mamoru From wtogami at redhat.com Tue Feb 27 07:37:21 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 27 Feb 2007 02:37:21 -0500 Subject: RATIFIED: Review with Flags (Version 6) In-Reply-To: <45E3D68D.1040009@ioa.s.u-tokyo.ac.jp> References: <45DE1D71.7020300@redhat.com> <45E3D68D.1040009@ioa.s.u-tokyo.ac.jp> Message-ID: <45E3DFB1.2020303@redhat.com> Mamoru Tasaka wrote: > Warren Togami wrote: >> STOP USING THE TRACKER BUGS. Just leave them as-is. FESCO is >> thinking about what to do about them during next week's meeting. > > Please update: > http://fedoraproject.org/wiki/Extras/HowToGetSponsored > > Current policy is that a new contributor who want to get > sponsored have to either > * submit a new review request with enough quality > * or do a "pre-review" of other person's review requests > to show that he surely understands how to package. > > And this wiki page still uses FE-NEW to find a review > request which is waiting to be reviewed. > > So: please someone update FE-NEW etc to the alternatives. > During the previous FESCO meeting, it was decided to implement the process. This upcoming Thursday's FESCO meeting will discuss how we can automatically migrate all the old tracker bugs to be consistent with the new flags, so single queries can pick up both. c4chris said he would work on "cached" query pages to make this quick and easy, while http://www.fedoraproject.org/wiki/KevinFenzi/ Kenvin Fenzi made a few tempory canned queries to work in this purpose. I suspect soon we will be able to auto-migrate all tracker bugs to their equivalent flag states. But FESCO must discuss this in the next meeting, feasibility must be figured out with dkl, then the optimal querying methods need to be figured out. I'm sorry it isn't exactly obvious how to update the documentation in that regard just yet, because the prerequisites to make it happen are not done yet. Warren Togami wtogami at redhat.com From fedora at leemhuis.info Tue Feb 27 09:37:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 27 Feb 2007 10:37:35 +0100 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E3BE45.4010107@redhat.com> References: <45E37E11.7080805@redhat.com> <604aa7910702261711u3e6a9b94xea3efcffcb19b3cb@mail.gmail.com> <45E3BE45.4010107@redhat.com> Message-ID: <45E3FBDF.105@leemhuis.info> On 27.02.2007 06:14, Warren Togami wrote: > Jeff Spaleta wrote: >>> FD0: Probationary/Training >>> Write access to own packages only >>> ---: Read-Only Access to Package SCM >> Okay, here is what I am specifically interested in. As a package >> maintainer, I'd like to find a way to get upstream developers for some >> packages involved as co-maintainers, if they are interested. What I'd >> like is that initially I'm the primary maintainer, but I'd like to >> have upstream people who are new to the fedora packaging process be >> secondary maintainers, so I can work with them inside the SCM until >> its clear to a sponsor that they can take over primary maintainership, >> and I can dial back my involvement in that package to a secondary >> maintainer role. This way I can hopefully train up active >> maintainers, who are less likely to orphan a package, without burning >> myself out with packaging duties. > > This is exactly the desired scenario: using FD0 to scale the project and > multiply your efforts many times fold. > [...] >> I hate watching package submissions from upstream developers languish >> in review. I've jumped in and taken maintainership over in a couple of >> cases, to keep the issue of sponsorship from keeping the package out. >> But obviously that's not ideal, because it doesn't help the upstream >> developer show necessary competence for sponser review. I'd like to >> think that some of us more veteran packagers can act as mentors for >> these people in a way that lets them build a track record of correct >> action for sponsors to review without holding up the packaging itself. >> Is the FD0 concept meant to help with this sort of scenario? > Yes! You got it. I disagree. The problem afaics (correct me if I'm wrong) is only solved if the packager is a sponsor. But we should solve the problem also for non-sponsors, so a normal and experienced packager (I'd roughly say this means all of the packagers we currently have that are around for more then 3 months and have at least two packages) that are not yet sponsors should be able to get upstream involved easily, too. In other words: FD0 should gets access to some packages only, no access to the buildsystem to prevent that stuff get build and pushed out. Members of FD2 (e.g. packagers that are around for some time and got a bit experience) could approve members for FD0 (for example upstream or new packagers) and give them access to their packages. But FD2 members should still not be able to upgrade people to FD1 (that should still require a proper sponsor). CU thl From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 13:27:47 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 14:27:47 +0100 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <45E3D5C0.5090002@hhs.nl> References: <1172526825.16039.5.camel@Chuck> <45E3D5C0.5090002@hhs.nl> Message-ID: <20070227142747.2f929eb5@python3.es.egwn.lan> Hans de Goede wrote : > > Packaging Committee Report > > * FESCo didn't have any objections to the Packaging Committee's > > guidelines regarding: > > SourceURL: http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl > > Hmm, I added a comment a couple of days ago to the page about the > sourceforge section not being correct and that is still there. How can > this be approved without that comment being addressed? Regarding your comment : dl.sf.net seems to return many different IP addresses, and wget fails to contact some of them fairly often in my case. OTOH, I've just tried downloads.sf.net and it redirects me to Heanet or Switch (which are mirrors quite close to me) with a 302 response, and seem like a clean redirect script on sourceforge's side. Cool. So using downloads seems the best to me, but I'd like to use sf.net instead of sourceforge.net since it'll make URLs shorter, thus more of them will manage to fit in 80 columns. Do others have experience with sourceforge downloads? Doesn't anyone actually know someone from sourceforge who could clear this up, or simply try and contact them to get a final and official answer about this, instead of us "poking around"? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.09 0.22 0.42 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 13:42:14 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 14:42:14 +0100 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <1172526825.16039.5.camel@Chuck> References: <1172526825.16039.5.camel@Chuck> Message-ID: <20070227144214.12a7ab41@python3.es.egwn.lan> Brian Pepple wrote : > Core/Extras Merge > * FESCo ratified the new Package Review process. For more details refer > to > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00380.html Might I point out that the "requires_kbase_article" flag still appears in bugzilla, and might confuse a lot of people? (me, for one) No news about the possible reverting of the MANDATORY build root tag? It's still blocking a few of my submissions... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.08 0.14 0.24 From Axel.Thimm at ATrpms.net Tue Feb 27 14:39:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 27 Feb 2007 15:39:47 +0100 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <20070227144214.12a7ab41@python3.es.egwn.lan> References: <1172526825.16039.5.camel@Chuck> <20070227144214.12a7ab41@python3.es.egwn.lan> Message-ID: <20070227143947.GU9953@neu.nirvana> On Tue, Feb 27, 2007 at 02:42:14PM +0100, Matthias Saou wrote: > Brian Pepple wrote : > > > Core/Extras Merge > > * FESCo ratified the new Package Review process. For more details refer > > to > > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00380.html > > Might I point out that the "requires_kbase_article" flag still appears > in bugzilla, and might confuse a lot of people? (me, for one) > > No news about the possible reverting of the MANDATORY build root tag? > It's still blocking a few of my submissions... spot asked me to write something up and it will hopefully be voted on today: http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot Feel free to stop by on #fedora-packaging at 17:00 UTC to manipulate your favourite representative. :) If it passes it will have to be ratified on Thursday by fesco, so if all go well, you'll be able to finish up those packages (me also). -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 15:44:51 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 16:44:51 +0100 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <20070227143947.GU9953@neu.nirvana> References: <1172526825.16039.5.camel@Chuck> <20070227144214.12a7ab41@python3.es.egwn.lan> <20070227143947.GU9953@neu.nirvana> Message-ID: <20070227164451.4fe85864@python3.es.egwn.lan> Axel Thimm wrote : > > No news about the possible reverting of the MANDATORY build root tag? > > It's still blocking a few of my submissions... > > spot asked me to write something up and it will hopefully be voted on > today: > > http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot > > Feel free to stop by on #fedora-packaging at 17:00 UTC to manipulate > your favourite representative. :) > > If it passes it will have to be ratified on Thursday by fesco, so if > all go well, you'll be able to finish up those packages (me also). Neat. Thanks. I've make a few corrections, slightly changed a few biased sentences and added some minor details. Please check my changes, and feel free to revert anything you wouldn't agree with. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.14 0.17 0.17 From wtogami at redhat.com Tue Feb 27 16:02:13 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 27 Feb 2007 11:02:13 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E3FBDF.105@leemhuis.info> References: <45E37E11.7080805@redhat.com> <604aa7910702261711u3e6a9b94xea3efcffcb19b3cb@mail.gmail.com> <45E3BE45.4010107@redhat.com> <45E3FBDF.105@leemhuis.info> Message-ID: <45E45605.3010306@redhat.com> Thorsten Leemhuis wrote: > I disagree. The problem afaics (correct me if I'm wrong) is only solved > if the packager is a sponsor. But we should solve the problem also for > non-sponsors, so a normal and experienced packager (I'd roughly say this > means all of the packagers we currently have that are around for more > then 3 months and have at least two packages) that are not yet sponsors > should be able to get upstream involved easily, too. > > In other words: FD0 should gets access to some packages only, no access > to the buildsystem to prevent that stuff get build and pushed out. > Members of FD2 (e.g. packagers that are around for some time and got a > bit experience) could approve members for FD0 (for example upstream or > new packagers) and give them access to their packages. But FD2 members > should still not be able to upgrade people to FD1 (that should still > require a proper sponsor). > > CU > thl > Interesting, I had not considered the possibility that members lower than sponsor (FD5) could bring FD0 onboard. This might work. Warren From Axel.Thimm at ATrpms.net Tue Feb 27 16:06:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 27 Feb 2007 17:06:52 +0100 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <20070227164451.4fe85864@python3.es.egwn.lan> References: <1172526825.16039.5.camel@Chuck> <20070227144214.12a7ab41@python3.es.egwn.lan> <20070227143947.GU9953@neu.nirvana> <20070227164451.4fe85864@python3.es.egwn.lan> Message-ID: <20070227160652.GC3516@neu.nirvana> On Tue, Feb 27, 2007 at 04:44:51PM +0100, Matthias Saou wrote: > Axel Thimm wrote : > > > > No news about the possible reverting of the MANDATORY build root tag? > > > It's still blocking a few of my submissions... > > > > spot asked me to write something up and it will hopefully be voted on > > today: > > > > http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot > > > > Feel free to stop by on #fedora-packaging at 17:00 UTC to manipulate > > your favourite representative. :) > > > > If it passes it will have to be ratified on Thursday by fesco, so if > > all go well, you'll be able to finish up those packages (me also). > > Neat. Thanks. I've make a few corrections, slightly changed a few > biased sentences and added some minor details. Please check my changes, > and feel free to revert anything you wouldn't agree with. Thanks, it all looks good, and I stand embarrassed of making so many typos in such little space ;) I don't see any biased stuff changed, but maybe I didn't even notice the orginal wording was biased. For what it's worth the whole thing *is* biased otherwise it wouldn't start with "has been too much talk about this topic. This topic is not a rebel topic. This topic is BuildRoot, Bloody BuildRoot" ;) -- 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 notting at redhat.com Tue Feb 27 17:21:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 Feb 2007 12:21:09 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E37E11.7080805@redhat.com> References: <45E37E11.7080805@redhat.com> Message-ID: <20070227172109.GC24137@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > ================================================== > = Strawman of Fedora Developer Ranking System v1 = > ================================================== > This concept document contains only *IDEAS* of why we would want a > ranking system, and how a ranking system might be useful. Below are > only examples. Please add your ideas to this thread. Overly complex. Why do you need 7 levels, somewhat obtuse names, etc, when we realistically have just four groups: - new/training/probationary members - members - sponsors - admins If we want a mechanism to reward people for contributions to the project, I'd suggest something like the bugzilla points system: http://bugzilla.gnome.org/page.cgi?id=points.html This allows an easy view of users, while rewarding: - packaging (through reviews and new packages) - bug reporting - bug fixing - bug triaging That allows it to be valid for even larger groups of users. Moreover... > Promotion Examples (specifics of which should be discussed): > > - Elder Sponsor is FD6. > - Sponsor rank is FD5. > - FD5 (using some process) may be promoted to FD6. [6] > - FESCO group vote required to promote anybody to FD5. > - FESCO members may promote anybody to FD4, unilaterally. > - FD6 may promote anybody to FD4, unilaterally. > - FD5 may promote anybody to FD4, if three FD5 members agree (in database). > - FD5 may promote anybody to FD3, unilaterally. > - FD4 may promote anybody to FD3, if three FD4 members agree (in database). > - FD4 may promote anybody to FD2, unilaterally. > - FD3 may promote anybody to FD2, if two FD3 members agree (in database). > - FD2 can't promote anybody. > - FD1 can't promote anybody. > - FD0 can't promote anybody. > > What do you think should be requirements and responsibilities of each rank? Something like this seems to be to be excessive policy for the sake of having policy. This isn't debian. Bill From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 17:32:37 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 18:32:37 +0100 Subject: Fedora Developer Ranking System v1 In-Reply-To: <20070227172109.GC24137@nostromo.devel.redhat.com> References: <45E37E11.7080805@redhat.com> <20070227172109.GC24137@nostromo.devel.redhat.com> Message-ID: <20070227183237.07cdc329@python3.es.egwn.lan> Bill Nottingham wrote : > Overly complex. Why do you need 7 levels, somewhat obtuse names, etc, when > we realistically have just four groups: > > - new/training/probationary members > - members > - sponsors > - admins > > If we want a mechanism to reward people for contributions to the > project, I'd suggest something like the bugzilla points system: > > http://bugzilla.gnome.org/page.cgi?id=points.html > > This allows an easy view of users, while rewarding: > > - packaging (through reviews and new packages) > - bug reporting > - bug fixing > - bug triaging > > That allows it to be valid for even larger groups of users. After seeing so many situations in which individuals chase "points", often for no good reason [1], like forum posts, ftp/torrent upload amounts... I'm pretty sure that groups could stay the ones that Bill lists, and that we would all feel a little boost in motivation by having these bugzilla points (or something similar) set up. This would allow some effort recognition, and would allow us to quickly identify who we are dealing with in a package review. I'm all for it. > Moreover... > [...] > Something like this seems to be to be excessive policy for the sake > of having policy. This isn't debian. Exactly. Matthias [1] : The "Pokemon" syndrome, "catch'em all"... which reminds me a phrase from a Garfield stip : "It's not the having, it's the getting". -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.83 0.93 0.51 From kzak at redhat.com Tue Feb 27 18:42:24 2007 From: kzak at redhat.com (Karel Zak) Date: Tue, 27 Feb 2007 19:42:24 +0100 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E37E11.7080805@redhat.com> References: <45E37E11.7080805@redhat.com> Message-ID: <20070227184224.GG3954@petra.dvoda.cz> On Mon, Feb 26, 2007 at 07:40:49PM -0500, Warren Togami wrote: > ================================================== > = Strawman of Fedora Developer Ranking System v1 = > ================================================== > This concept document contains only *IDEAS* of why we would want a > ranking system, and how a ranking system might be useful. Below are > only examples. Please add your ideas to this thread. Overkill :-). Sorry, this word comes to mind when I read your concept. > - Who Are You? As the project grows, you can't possibly know all > contributors on the other side of the project. Viewing that > member's stat page gives you a convenient snapshot of what they are > working on, who they work with, who sponsored, who promoted, etc. Frankly, you can send me a patch from Mars and I will always independently or your name check technical quality of the patch only. If you send me good patches often I will decide to give you write access to SCM. This is the way. (BUT.. in distributed development model (and SCM) you needn't any access. You need to send me "please, pull from scm://..." only.) > Each rank will have formal written description of rough requirements > and You cannot describe these things (see Jeff's mail). It's more colored and more difficult than someone of us is able to describe. > responsibilities. (Example: FD3 requires 17 quality reviews or 9 > owned packages and shows clear competence in package guidelines. > FD4 requires 9 packages? Define the "package"? Kernel or gnome-sudoku? 17 quality reviews? Review of what? Patch to kernel or to any man page? Please, keep things simple. Nobody wants to study your wiki, nobody wants to fight with our processes. I believe we want to work with minimal overhead. Smart people needn't strong rules. Intelligent and responsible people need freedom. Karel -- Karel Zak From wtogami at redhat.com Tue Feb 27 19:03:58 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 27 Feb 2007 14:03:58 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <20070227184224.GG3954@petra.dvoda.cz> References: <45E37E11.7080805@redhat.com> <20070227184224.GG3954@petra.dvoda.cz> Message-ID: <45E4809E.6000508@redhat.com> Karel Zak wrote: > Please, keep things simple. Nobody wants to study your wiki, nobody > wants to fight with our processes. I believe we want to work with > minimal overhead. > > Smart people needn't strong rules. Intelligent and responsible people > need freedom. > > Karel > An important design consideration for this system would be that if you choose to do so, you DON'T NEED TO PARTICIPATE. It doesn't get in your way. These concerns are valid. I still think this idea should be explored for stages after FAS2 and PackageDB are in place. I did think Bugzilla scores may potentially have value too. Warren Togami wtogami at redhat.com From mattdm at mattdm.org Tue Feb 27 19:51:18 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 27 Feb 2007 14:51:18 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <20070227172109.GC24137@nostromo.devel.redhat.com> References: <45E37E11.7080805@redhat.com> <20070227172109.GC24137@nostromo.devel.redhat.com> Message-ID: <20070227195118.GA19861@jadzia.bu.edu> On Tue, Feb 27, 2007 at 12:21:09PM -0500, Bill Nottingham wrote: > If we want a mechanism to reward people for contributions to the > project, I'd suggest something like the bugzilla points system: > http://bugzilla.gnome.org/page.cgi?id=points.html > This allows an easy view of users, while rewarding: > - packaging (through reviews and new packages) > - bug reporting > - bug fixing > - bug triaging > That allows it to be valid for even larger groups of users. Hmmm. Would this score be computed retroactively? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Tue Feb 27 19:57:28 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 Feb 2007 14:57:28 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <20070227195118.GA19861@jadzia.bu.edu> References: <45E37E11.7080805@redhat.com> <20070227172109.GC24137@nostromo.devel.redhat.com> <20070227195118.GA19861@jadzia.bu.edu> Message-ID: <20070227195728.GD3330@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > Hmmm. Would this score be computed retroactively? :) Quick! Race to close all the FC-old bugs! Bill From jkeating at redhat.com Tue Feb 27 20:37:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Feb 2007 15:37:36 -0500 Subject: Proposed guideline for init script files Message-ID: <200702271537.36532.jkeating@redhat.com> The Packaging Committee has been discussing guidelines for init scripts for a while. Currently there is a split between init scripts being marked as %config and many that aren't. We (the PC) with input from various folks feel it is best to not mark init scripts as %config, and instead promote configuration to happen in an /etc/sysconfig/ file. Mostly the reason being that init scripts are just that, scripts to run and not config files to edit. As such I've drafted a proposal for the guidelines and the PC approved it. There is time now for a wider audience to review the proposed change and comment. Please take a moment to read through http://fedoraproject.org/wiki/PackagingDrafts/InitScripts and provide some feedback. If nobody has major objections or reasonable adjustments, this will become policy in a week's 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 jspaleta at gmail.com Tue Feb 27 20:52:31 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 27 Feb 2007 11:52:31 -0900 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E3FBDF.105@leemhuis.info> References: <45E37E11.7080805@redhat.com> <604aa7910702261711u3e6a9b94xea3efcffcb19b3cb@mail.gmail.com> <45E3BE45.4010107@redhat.com> <45E3FBDF.105@leemhuis.info> Message-ID: <604aa7910702271252l338c2430gae94521aa8dc8103@mail.gmail.com> On 2/27/07, Thorsten Leemhuis wrote: > In other words: FD0 should gets access to some packages only, no access > to the buildsystem to prevent that stuff get build and pushed out. I'd actually like that. I'd like to bring in upstream people to work with me inside the scm, but I would be on the hook for pushing out the builds after I reviewed spec and patches from the people I was mentoring. Give them just enough access to work inside the scm in good faith, but with a responsible package maintainer acting as a proactive gatekeeper for any changes the FD0 individuals made. -jef"Trust...but verify"spaleta From jspaleta at gmail.com Tue Feb 27 21:11:38 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 27 Feb 2007 12:11:38 -0900 Subject: Fedora Developer Ranking System v1 In-Reply-To: <20070227183237.07cdc329@python3.es.egwn.lan> References: <45E37E11.7080805@redhat.com> <20070227172109.GC24137@nostromo.devel.redhat.com> <20070227183237.07cdc329@python3.es.egwn.lan> Message-ID: <604aa7910702271311j5595632aua88456263394d922@mail.gmail.com> On 2/27/07, Matthias Saou > After seeing so many situations in which individuals chase "points", > often for no good reason [1], like forum posts, ftp/torrent upload > amounts... I'm pretty sure that groups could stay the ones that Bill > lists, and that we would all feel a little boost in motivation by > having these bugzilla points (or something similar) set up. This would > allow some effort recognition, and would allow us to quickly identify > who we are dealing with in a package review. I'm all for it. A coherent recognition system would probably be a good idea for retention and recruitment. Some people respond to that sort of thing.. I'm not one of them. Something like an outstanding contributors list with a threshold 'point' value that was engineered to highlight people who have maintained a threshold involvement consistently over some time. And perhaps a second list engineering to include people who are ramping up their involvement. If we were really on the ball, we'd squander some money taking out a full page ad in a paper like the world renownd Fairbanks Daily Miner ( or maybe the less well known NYT for people with more provincial interests) just to get all the names listed in a high profile thank you note. That'd puff up contributor morale in some quarters and make for an interesting round of secondary laypress articles to counterbalance the poor coverage over this past week. -jef"doesn't need recognition, jef needs free swag. I want enough fedora stickers to wallpaper my spare bedroom... one sticker for every time i've instructed someone use 'su -l' on irc."spaleta From jspaleta at gmail.com Tue Feb 27 21:17:12 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 27 Feb 2007 12:17:12 -0900 Subject: Proposed guideline for init script files In-Reply-To: <200702271537.36532.jkeating@redhat.com> References: <200702271537.36532.jkeating@redhat.com> Message-ID: <604aa7910702271317v5df56642l8217065f4a955f39@mail.gmail.com> On 2/27/07, Jesse Keating wrote: > Please take a moment to read through > http://fedoraproject.org/wiki/PackagingDrafts/InitScripts and provide some > feedback. If nobody has major objections or reasonable adjustments, this > will become policy in a week's time. +1 I think this makes a lot of sense for consistent treatment of local administration configs. Any chance we could have some optional boiler plate text in the init files... encouraging admins who are editting the init files directly to send in bugtickets so that future versions of the scripts and associated config files can be extended to reduce the need for any admin to make direct edits of these scripts? -jef From jkeating at redhat.com Tue Feb 27 22:25:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Feb 2007 17:25:12 -0500 Subject: F7 Test2 syncing to mirrors Message-ID: <200702271725.15536.jkeating@redhat.com> And thus freeze is over. Rawhide tonight will include all the things that have been built over the past week, expect much breakage. Extras can push as well. If you have anything to say about Test 2, by all means drop it in http://fedoraproject.org/wiki/F7Test2/ReleaseNotes -- 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 Tue Feb 27 23:50:31 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 28 Feb 2007 00:50:31 +0100 Subject: plaque vs koji Message-ID: <20070227235031.GA20852@neu.nirvana> Hi, before someone mentions that we have fedora-buildsys to discuss this, I'm not after the technical details (although in fact I'd love an executive-like summary of the difference between the two), but more on the politics: koji is after replacing plaque. Is that that plan decided on already, or are there opponents to koji? If the replacement is already decided on, when should that happen? In the wiki there is a delivery target of F7test3 (in 4 weeks), do we really want to swap buildsystems shortly before a release? If we commit to koji and it slips the whole release slips even further, and we get back PR on this already. And will the change affect packagers in their common workflow? E.g. I can imagine a rather transparent change, with make build someday silently (but pre-announced) update itself into calling koji components instead of plaque. -- 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 Wed Feb 28 01:42:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Feb 2007 20:42:40 -0500 Subject: plaque vs koji In-Reply-To: <20070227235031.GA20852@neu.nirvana> References: <20070227235031.GA20852@neu.nirvana> Message-ID: <200702272042.40972.jkeating@redhat.com> On Tuesday 27 February 2007 18:50, Axel Thimm wrote: > koji is after replacing plaque. Is that that plan decided on already, > or are there opponents to koji? That was the plan as decided at the Fedora Summit. > If the replacement is already decided > on, when should that happen? As soon as we can do it cleanly. > In the wiki there is a delivery target of > F7test3 (in 4 weeks), do we really want to swap buildsystems shortly > before a release? Given that Test3 is the Feature Freeze, and we've created a Test4 after that, and that both koji and plague use mock as the building tool, yes I feel confident switching them at this point. Getting koji in place is a precursor to merging all the packages. > If we commit to koji and it slips the whole release > slips even further, and we get back PR on this already. I'm of the opinion that if we can't meet the Test3 deadline for koji, we may do a release without the merger, still composing out of the two package collections and target F8 for the merger. This is just me thinking outload, no official statement or anything. > And will the change affect packagers in their common workflow? E.g. I > can imagine a rather transparent change, with make build someday > silently (but pre-announced) update itself into calling koji > components instead of plaque. That's the plan. Adding new packages may be an extra step or two for the cvsadmin for a bit, but 'make tag, make build' should all do the same things. You'll gain a lot more functionality out of the build system but you can completely ignore it if you want. -- 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 kevin at tummy.com Wed Feb 28 00:44:57 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Tue, 27 Feb 2007 17:44:57 -0700 Subject: Future owners/ACL choices In-Reply-To: <200702262239.29528.ville.skytta@iki.fi> References: <1172336630.4472.411.camel@localhost.localdomain> <20070226110043.37210f26@ningauble.scrye.com> <20070226204637.c8bc4f96.bugs.michael@gmx.net> <200702262239.29528.ville.skytta@iki.fi> Message-ID: <20070227174457.07d9ba19@ningauble.scrye.com> On Mon, 26 Feb 2007 22:39:29 +0200 ville.skytta at iki.fi (Ville Skytt?) wrote: > On Monday 26 February 2007, Michael Schwendt wrote: > > On Mon, 26 Feb 2007 11:00:43 -0700, Kevin Fenzi wrote: > > > Yeah, there needs to be periodic 'culling' of the orphans. > > > If they haven't been picked up in a while (how long?) they should > > > get: > > > > > > - removed from the repository (all branches?) > > > > Of course! All branches! Else it creates broken upgrades and bug > > reports that go to "orphan owner". > > That's only a partial solution, it won't help people who installed it > while it was available which is very confusing. IMO that'd make it a > no go; instead either > > 1) Never remove orphaned packages from non-devel distros only because > they're orphaned, and do document whatever there is to document about > them in the next release notes (at least a list with a caveat that it > is possible that some of them will reappear later and thus the > accuracy of the information is likely to decrease as time passes from > the release date), or The downside here, as Michael mentioned is that users will then file bugs and it will go to the orphan alias and be ignored, or if we remove the bugzilla component entirely, they won't even be able to file a bug at all. No one will be watching the package for security issues most likely either. ;( > 2) Arrange a way to have the orphaned packages removed or at least > suggested to be removed from end user systems at the time they > disappear from repositories. Far from nice in the first place, and > possibly a PITA if one has local/3rd party packages that have > dependencies to removed stuff. Yeah, could be that would cause problems, but I wonder if it's worth trying... create a 'fedora-orphans' package. When things are orphaned, that package gets added to it: Provides: oldpackagename = $provEVR Obsoletes: oldpackagename < $obsEVR If the package is unorphaned, just bump release and it's back in business. I do suspect this will make some mad users if they use other repos or locally built packages however. Just a thought... kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cr33dog at gmail.com Wed Feb 28 03:21:56 2007 From: cr33dog at gmail.com (Chris Mohler) Date: Tue, 27 Feb 2007 21:21:56 -0600 Subject: ltsp-utils vs LTSP-5 Message-ID: Hi, I recently adopted ltsp-utils. It looks like that package will be made obsolete by LTSP-5 - is this correct? I infer from reading about the 'MueKow' stuff that there will be an enitirely new package present in F7? Thanks, Chris From notting at redhat.com Wed Feb 28 03:39:56 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 Feb 2007 22:39:56 -0500 Subject: Future owners/ACL choices In-Reply-To: <20070227174457.07d9ba19@ningauble.scrye.com> References: <1172336630.4472.411.camel@localhost.localdomain> <20070226110043.37210f26@ningauble.scrye.com> <20070226204637.c8bc4f96.bugs.michael@gmx.net> <200702262239.29528.ville.skytta@iki.fi> <20070227174457.07d9ba19@ningauble.scrye.com> Message-ID: <20070228033956.GA18767@nostromo.devel.redhat.com> Kevin Fenzi (kevin at tummy.com) said: > The downside here, as Michael mentioned is that users will then file > bugs and it will go to the orphan alias and be ignored, or if we remove > the bugzilla component entirely, they won't even be able to file a bug > at all. No one will be watching the package for security issues most > likely either. ;( I don't think we ever want to remove the bugzilla component. (Aside from the fact that bugzilla's design makes that near impossible.) > create a 'fedora-orphans' package. When things are orphaned, that > package gets added to it: > Provides: oldpackagename = $provEVR > Obsoletes: oldpackagename < $obsEVR > > If the package is unorphaned, just bump release and it's back in > business. I do suspect this will make some mad users if they use other > repos or locally built packages however. Hm. I think the effect on locally-built packages is too much for this. Bill From wtogami at redhat.com Wed Feb 28 04:49:09 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 27 Feb 2007 23:49:09 -0500 Subject: ltsp-utils vs LTSP-5 In-Reply-To: References: Message-ID: <45E509C5.8070002@redhat.com> Chris Mohler wrote: > Hi, > > I recently adopted ltsp-utils. It looks like that package will be > made obsolete by LTSP-5 - is this correct? I infer from reading about > the 'MueKow' stuff that there will be an enitirely new package present > in F7? > > Thanks, > Chris > The way LTSP-5 is organized is entirely different from the old LTSP. Previous LTSP built an entire OS for the thin clients within the chroot. LTSP-5 instead uses the base OS' packages to form that chroot. Eric Harrison did some work Fedora-izing LTSP-5. We should see what progress he made on this and figure out what other pieces need doing. Eric, could you fill us in on the status? We need to get all the supporting pieces of LTSP into Fedora, and figure out exactly how the thin clients should be configured (initrd, X and other stuff) that is either Fedora compatible, or using LTSP-scripts bypassing it entirely. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207341 Here is one key problem needing solving for Fedora to natively handle one aspect of LTSP-5. There are many other pieces that need to be isolated, filed and worked on. Warren Togami wtogami at redhat.com From panemade at gmail.com Wed Feb 28 05:46:23 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Wed, 28 Feb 2007 11:16:23 +0530 Subject: Core packages are using %config for files being installed under /usr Message-ID: Hi, While reviewing some fonts-* packages , I saw files being installed under /usr are marked as %config in their SPECS as shown below %config(noreplace) %verify(not md5 size mtime) %{ttfontdir}/fonts.alias %config(noreplace) %verify(not md5 size mtime) %{bmpfontdir}/fonts.alias some are even have %config(noreplace) %verify(not md5 size mtime) /usr/share/fonts/%{ISONAME}/100dpi/fonts.alias That made rpmlint to report following types of rpmlint messages on those packages E: fonts-ISO8859-2-100dpi file-in-usr-marked-as-conffile /usr/share/fonts/ISO8859-2/100dpi/fonts.alias A file in /usr is marked as being a configuration file. Store your conf files in /etc/ instead. Also i am reviewing hwdata(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225893 ) Core package and i even saw there %config /usr/share/hwdata/* and rpmlint is giving error. How to handle this issue? Regards, Parag. From majain at redhat.com Wed Feb 28 06:20:20 2007 From: majain at redhat.com (=?UTF-8?Q?=E0=A4=AE=E0=A4=AF=E0=A4=82=E0=A4=95_=E0=A4=9C=E0=A5=88?= =?UTF-8?Q?=E0=A4=A8?=) Date: Wed, 28 Feb 2007 11:50:20 +0530 Subject: F7 Test2 syncing to mirrors In-Reply-To: <200702271725.15536.jkeating@redhat.com> References: <200702271725.15536.jkeating@redhat.com> Message-ID: <1172643620.24460.3.camel@majain.pnq.redhat.com> On Tue, 2007-02-27 at 17:25 -0500, Jesse Keating wrote: > And thus freeze is over. Rawhide tonight will include all the things that > have been built over the past week, expect much breakage. Extras can push as > well. > > If you have anything to say about Test 2, by all means drop it in > http://fedoraproject.org/wiki/F7Test2/ReleaseNotes Just added a few lines about m17n-db (indic keymaps) Regards, Makuchaku http://www.makuchaku.info/blog From fedora at leemhuis.info Wed Feb 28 06:51:16 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 28 Feb 2007 07:51:16 +0100 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E37E11.7080805@redhat.com> References: <45E37E11.7080805@redhat.com> Message-ID: <45E52664.7020302@leemhuis.info> On 27.02.2007 01:40, Warren Togami wrote: > ================================================== > = Strawman of Fedora Developer Ranking System v1 = > ================================================== > This concept document contains only *IDEAS* of why we would want a > ranking system, and how a ranking system might be useful. Below are > only examples. Please add your ideas to this thread. > [...] As two other (red hat) people said "overkill" and "Overly complex" I'd like to say the opposite: I like the direction, but would like to see https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00764.html integrated. Sure, maybe some other details need to be adjusted, but this scheme might meld a lot to get new people involved and growing up in the project. And that's hardly needed and the best for the project. Even if the system is a bit more complex than what we have now -- it lowers the bar (that's quite high ATM) to get involved into Fedora, and that's important to get new people in. It's thus a step into the right direction. Cu thl From ville.skytta at iki.fi Wed Feb 28 06:56:34 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 28 Feb 2007 08:56:34 +0200 Subject: Future owners/ACL choices In-Reply-To: <20070228033956.GA18767@nostromo.devel.redhat.com> References: <1172336630.4472.411.camel@localhost.localdomain> <20070227174457.07d9ba19@ningauble.scrye.com> <20070228033956.GA18767@nostromo.devel.redhat.com> Message-ID: <200702280856.35435.ville.skytta@iki.fi> On Wednesday 28 February 2007, Bill Nottingham wrote: > Kevin Fenzi (kevin at tummy.com) said: > > > create a 'fedora-orphans' package. When things are orphaned, that > > package gets added to it: > > Provides: oldpackagename = $provEVR > > Obsoletes: oldpackagename < $obsEVR > > > > If the package is unorphaned, just bump release and it's back in > > business. I do suspect this will make some mad users if they use other > > repos or locally built packages however. > > Hm. I think the effect on locally-built packages is too much for this. Agreed, as already said in a previous post. Just a note, if someone is still interested in pursuing this, at least the Provides needs to be dropped from the above - it's just wrong. From giallu at gmail.com Wed Feb 28 08:33:41 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 28 Feb 2007 09:33:41 +0100 Subject: Proposed guideline for init script files In-Reply-To: <200702271537.36532.jkeating@redhat.com> References: <200702271537.36532.jkeating@redhat.com> Message-ID: On 2/27/07, Jesse Keating wrote: > The Packaging Committee has been discussing guidelines for init scripts for a > while. Currently there is a split between init scripts being marked > as %config and many that aren't. We (the PC) with input from various folks > feel it is best to not mark init scripts as %config, and instead promote > configuration to happen in an /etc/sysconfig/ file. Mostly the reason > being that init scripts are just that, scripts to run and not config files to > edit. Will rpmlint be amended to report a warning (error?) for this? From petersen at redhat.com Wed Feb 28 09:24:09 2007 From: petersen at redhat.com (Jens Petersen) Date: Wed, 28 Feb 2007 19:24:09 +1000 Subject: naming scheme for fonts packages? Message-ID: <45E54A39.7030104@redhat.com> I am currently reviewing a Tibetan font for inclusion in Fedora. It is called Tibetan Machine Uni, and we have had a lengthy polite discussion on the naming of the package both in and out of bugzilla, also with the upstream maintainer. (The project is hosted on SourceForge and GPL fwiw). The package was submitted as tibetan-machine-uni-fonts, so I suggested fonts-tibetan. However since the font is also good for Bhutanese, the submitter and the maintainer think fonts-tibetan-dzongkha (bhutanese) would be more appropriate. It occurred to me that we really need some guideline about naming of fonts packages. Most of our international fonts follow the naming scheme "fonts-*" where "*" is the generally the English name of the language, which makes the package pretty easy to find. And the remainder are mostly suffixed with "-fonts". Currently in F7T2 there are: fonts-ISO8859-2 fonts-KOI8-R fonts-arabic fonts-bengali fonts-chinese fonts-gujarati fonts-hebrew fonts-hindi fonts-japanese fonts-kannada fonts-korean fonts-malayalam fonts-oriya fonts-punjabi fonts-sinhala fonts-tamil fonts-telugu and: bitmap-fonts bitstream-vera-fonts dejavu-lgc-fonts ghostscript-fonts tetex-fonts urw-fonts xorg-x11-fonts In Extras the fonts tend to be more alternative/miscellaneous I guess: VLGothic-fonts artwiz-aleczapka-fonts charis-fonts dejavu-fonts doulos-fonts gentium-fonts hunky-fonts linux-libertine-fonts mathml-fonts mgopen-fonts terminus-font, and fonts-hebrew-fancy So perhaps we need to set two naming conventions: using "fonts-" for standard international fonts and "-fonts" for alternative general fonts? Of course "fonts-" doesn't quite solve the problem for the Tibetan font... ;) The name fonts-tibetan-script was also brought up, and even fonts-bodic. It would probably be good to add some text about in on http://fedoraproject.org/wiki/Packaging/NamingGuidelines anyway. Comments? Opinions? Jens From nicolas.mailhot at laposte.net Wed Feb 28 10:03:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Feb 2007 11:03:32 +0100 (CET) Subject: naming scheme for fonts packages? In-Reply-To: <45E54A39.7030104@redhat.com> References: <45E54A39.7030104@redhat.com> Message-ID: <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> Le Mer 28 f?vrier 2007 10:24, Jens Petersen a ?crit : > So perhaps we need to set two naming conventions: using > "fonts-" for standard international fonts and "-fonts" > for alternative general fonts? fonts-foo are usually a mashup of fonts for a specific encoding, and foo-fonts fonts with distinct style that may span several languages areas. To be honest I'm not too fond of foo-font packages. They're a necessary 8-bit legacy stopgap, but I'd rather have vibrant font projects competing on quality and international coverage. You don't get that if you bundle different upstreams in neutraly named packages. (the fact that FC was more fonts-foo and FE foo-fonts reflects a rather utilitarian view of fonts RH-side, and the huge weight of the fossilized fonts sourced from xfree86/xorg) IMHO (which if worth what it's worth) you're not packaging generic fonts for tibetan but a specific font project, and it deserves name recognition just like any other upstream. So upstreamname-fonts seems more respectful for me. Also have you though of what will happen should someone want to package another tibetan font in a few months ? -- Nicolas Mailhot From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 28 10:17:26 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 28 Feb 2007 11:17:26 +0100 Subject: Proposed guideline for init script files In-Reply-To: <200702271537.36532.jkeating@redhat.com> References: <200702271537.36532.jkeating@redhat.com> Message-ID: <20070228111726.3207602a@python3.es.egwn.lan> Jesse Keating wrote : > Please take a moment to read through > http://fedoraproject.org/wiki/PackagingDrafts/InitScripts and provide some > feedback. If nobody has major objections or reasonable adjustments, this > will become policy in a week's time. This is definitely a step in the right direction, but if it's meant to become the "init script packaging guidelines", then it's missing all of the most important parts : The init script's content. A few things from the top of my mind : - What output is okay and what output isn't (to look good and play nice with the graphical boot). - Which commands should be mandatory and which optional (start, stop, restart, condrestart and status are the most expected ones, reload doesn't always make sense). - Which syntax should be followed in the initial comments for compatibility with chkconfig and other tools. I will try to spare some time to write some proposals for these if it is something we want to try and cover too. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.23 1.05 0.64 From pertusus at free.fr Wed Feb 28 10:40:30 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 28 Feb 2007 11:40:30 +0100 Subject: Proposed guideline for init script files In-Reply-To: <20070228111726.3207602a@python3.es.egwn.lan> References: <200702271537.36532.jkeating@redhat.com> <20070228111726.3207602a@python3.es.egwn.lan> Message-ID: <20070228104030.GB2903@free.fr> On Wed, Feb 28, 2007 at 11:17:26AM +0100, Matthias Saou wrote: > Jesse Keating wrote : > > > Please take a moment to read through > > http://fedoraproject.org/wiki/PackagingDrafts/InitScripts and provide some > > feedback. If nobody has major objections or reasonable adjustments, this > > will become policy in a week's time. > > This is definitely a step in the right direction, but if it's meant to > become the "init script packaging guidelines", then it's missing all of > the most important parts : The init script's content. > > - Which commands should be mandatory and which optional (start, stop, > restart, condrestart and status are the most expected ones, reload > doesn't always make sense). There is already something about the commands in the post scripts page: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-a6d7a1ed9d77dbb8d4af067378a79b838aebb20a I can't remember of anything about the remaining, except that rpmlint does some checks on the comments. Also there could be lsb-init comments and chkconfig comments. -- Pat From panemade at gmail.com Wed Feb 28 11:12:15 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Wed, 28 Feb 2007 16:42:15 +0530 Subject: naming scheme for fonts packages? In-Reply-To: <45E54A39.7030104@redhat.com> References: <45E54A39.7030104@redhat.com> Message-ID: Hi, On 2/28/07, Jens Petersen wrote: > I am currently reviewing a Tibetan font for inclusion in Fedora. > It is called Tibetan Machine Uni, and we have had a lengthy > polite discussion on the naming of the package both in and out > of bugzilla, also with the upstream maintainer. (The project is hosted > on SourceForge and GPL fwiw). The package was submitted as > tibetan-machine-uni-fonts, so I suggested fonts-tibetan. However since > the font is also good for Bhutanese, the submitter and the maintainer > think fonts-tibetan-dzongkha (bhutanese) would be more appropriate. +1. I agree with fonts-tibetan-dzongkha-bhutanese package name. > > It occurred to me that we really need some guideline about naming of > fonts packages. Most of our international fonts follow the naming > scheme "fonts-*" where "*" is the generally the English name of the > language, which makes the package pretty easy to find. And the > remainder are mostly suffixed with "-fonts". Currently in F7T2 there are: > > fonts-ISO8859-2 fonts-KOI8-R fonts-arabic fonts-bengali fonts-chinese > fonts-gujarati fonts-hebrew fonts-hindi fonts-japanese fonts-kannada > fonts-korean fonts-malayalam fonts-oriya fonts-punjabi fonts-sinhala > fonts-tamil fonts-telugu > > and: > > bitmap-fonts bitstream-vera-fonts dejavu-lgc-fonts ghostscript-fonts > tetex-fonts urw-fonts xorg-x11-fonts > > In Extras the fonts tend to be more alternative/miscellaneous I guess: > > VLGothic-fonts artwiz-aleczapka-fonts charis-fonts dejavu-fonts > doulos-fonts gentium-fonts hunky-fonts linux-libertine-fonts > mathml-fonts mgopen-fonts terminus-font, and fonts-hebrew-fancy > > So perhaps we need to set two naming conventions: using > "fonts-" for standard international fonts and "-fonts" > for alternative general fonts? +1. Good point. > > Of course "fonts-" doesn't quite solve the problem for the > Tibetan font... ;) The name fonts-tibetan-script was also brought up, > and even fonts-bodic. > > It would probably be good to add some text about in on > http://fedoraproject.org/wiki/Packaging/NamingGuidelines anyway. > This is now really needed and FESCO should discuss this in tomorrow's meeting. > Comments? Opinions? > > Jens > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From kwade at redhat.com Wed Feb 28 11:29:26 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 28 Feb 2007 03:29:26 -0800 Subject: F7 t2 release notes "one sheet" Message-ID: <1172662166.4651.256.camel@erato.phig.org> For reasons outlined on the page itself, we are using the "one sheet on the Wiki" approach for release notes for test2. Spread the word. http://fedoraproject.org/wiki/F7Test2/ReleaseNotes You can edit that page yourself, or you can use one of the five other ways to file a release note: http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process#submitting *Now* is the time to start using these methods to add content to the release notes: http://fedoraproject.org/wiki/Docs/Beats The content must be mainly complete by the final test (test4) so that i) the content can be vetted by the community, and ii) translators can translate and know that >80% of their work is complete in translating the test4 notes. Don't hesitate to send content bits our way; others have experienced the joy already[1]. Thanks - Karsten [1] New content on this page was received (and used nearly verbatim) by a packager who used the *docs* tag in his CVS commit. http://fedoraproject.org/wiki/Docs/Beats/Entertainment Tibbs, thanks for the nicely formatted content! -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 rdieter at math.unl.edu Wed Feb 28 12:41:23 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Feb 2007 06:41:23 -0600 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: References: Message-ID: <45E57873.5020109@math.unl.edu> Parag N(????) wrote: > Hi, > While reviewing some fonts-* packages , I saw files being installed > under /usr are marked as %config in their SPECS as shown below > %config(noreplace) %verify(not md5 size mtime) %{ttfontdir}/fonts.alias ... > How to handle this issue? IMO, the fonts.alias example is a fair use of %config that's ok in my book. -- Rex From blizzard at redhat.com Wed Feb 28 12:59:29 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 28 Feb 2007 07:59:29 -0500 Subject: Proposed guideline for init script files In-Reply-To: <200702271537.36532.jkeating@redhat.com> References: <200702271537.36532.jkeating@redhat.com> Message-ID: <1172667569.7686.2.camel@localhost.localdomain> On Tue, 2007-02-27 at 15:37 -0500, Jesse Keating wrote: > The Packaging Committee has been discussing guidelines for init scripts for a > while. Currently there is a split between init scripts being marked > as %config and many that aren't. We (the PC) with input from various folks > feel it is best to not mark init scripts as %config, and instead promote > configuration to happen in an /etc/sysconfig/ file. Mostly the reason > being that init scripts are just that, scripts to run and not config files to > edit. As such I've drafted a proposal for the guidelines and the PC approved > it. There is time now for a wider audience to review the proposed change and > comment. +1. In general if you have to edit an init startup file, it's a bug. Configuration should be in /etc/sysconfig/foo. --Chris From jkeating at redhat.com Wed Feb 28 13:18:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Feb 2007 08:18:33 -0500 Subject: Proposed guideline for init script files In-Reply-To: <20070228111726.3207602a@python3.es.egwn.lan> References: <200702271537.36532.jkeating@redhat.com> <20070228111726.3207602a@python3.es.egwn.lan> Message-ID: <200702280818.33182.jkeating@redhat.com> On Wednesday 28 February 2007 05:17, Matthias Saou wrote: > This is definitely a step in the right direction, but if it's meant to > become the "init script packaging guidelines", then it's missing all of > the most important parts : The init script's content. > > A few things from the top of my mind : > - What output is okay and what output isn't (to look good and play nice > with the graphical boot). > - Which commands should be mandatory and which optional (start, stop, > restart, condrestart and status are the most expected ones, reload > doesn't always make sense). > - Which syntax should be followed in the initial comments for > compatibility with chkconfig and other tools. > > I will try to spare some time to write some proposals for these if it > is something we want to try and cover too. Yes, the init script section can grow and cross link to things in scriptletsnippits as necessary. I find it difficult to get a big chunks of guidelines approved all at once, so I'd rather take the approach of one subject at a time. This time it's the %config or not. -- 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 Feb 28 13:38:39 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 28 Feb 2007 14:38:39 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1172667569.7686.2.camel@localhost.localdomain> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> Message-ID: <1172669919.15418.163.camel@mccallum.corsepiu.local> On Wed, 2007-02-28 at 07:59 -0500, Christopher Blizzard wrote: > On Tue, 2007-02-27 at 15:37 -0500, Jesse Keating wrote: > > The Packaging Committee has been discussing guidelines for init scripts for a > > while. Currently there is a split between init scripts being marked > > as %config and many that aren't. We (the PC) with input from various folks > > feel it is best to not mark init scripts as %config, and instead promote > > configuration to happen in an /etc/sysconfig/ file. Mostly the reason > > being that init scripts are just that, scripts to run and not config files to > > edit. As such I've drafted a proposal for the guidelines and the PC approved > > it. There is time now for a wider audience to review the proposed change and > > comment. > > +1. In general if you have to edit an init startup file, it's a bug. Exactly ... and what can users do about it? Edit them. With them not being marked %config users can only hope that RH/upstream fixes it before the next update blows away their edits :( > Configuration should be in /etc/sysconfig/foo. But real bugs and missing features init scripts suffer from can't. As I've said many times before, I consider not marking init scripts %config a regression, Fedora will regret. Ralf From laurent.rineau__fedora_extras at normalesup.org Wed Feb 28 13:46:09 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Wed, 28 Feb 2007 14:46:09 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1172667569.7686.2.camel@localhost.localdomain> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> Message-ID: <200702281446.10030@rineau.tsetse> On Wednesday 28 February 2007 13:59:29 Christopher Blizzard wrote: > On Tue, 2007-02-27 at 15:37 -0500, Jesse Keating wrote: > > The Packaging Committee has been discussing guidelines for init scripts > > for a while. Currently there is a split between init scripts being > > marked as %config and many that aren't. We (the PC) with input from > > various folks feel it is best to not mark init scripts as %config, and > > instead promote configuration to happen in an /etc/sysconfig/ file. > > Mostly the reason being that init scripts are just that, scripts to run > > and not config files to edit. As such I've drafted a proposal for the > > guidelines and the PC approved it. There is time now for a wider > > audience to review the proposed change and comment. > > +1. In general if you have to edit an init startup file, it's a bug. > Configuration should be in /etc/sysconfig/foo. Right. But are we sure our scripts are configurable enough for usages of all administrators? As an administrator, I would like to be able to use Fedora without filling a bug when my local settings are incompatible with Fedora's init scripts. What is more, even though an administrator report all bugs, during the period when the bug is not fixed, Fedora would suck if it overrides local modifications of those scripts. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From rdieter at math.unl.edu Wed Feb 28 14:10:16 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Feb 2007 08:10:16 -0600 Subject: Proposed guideline for init script files In-Reply-To: <200702281446.10030@rineau.tsetse> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <200702281446.10030@rineau.tsetse> Message-ID: <45E58D48.70204@math.unl.edu> Laurent Rineau wrote: > On Wednesday 28 February 2007 13:59:29 Christopher Blizzard wrote: >> +1. In general if you have to edit an init startup file, it's a bug. >> Configuration should be in /etc/sysconfig/foo. > > Right. But are we sure our scripts are configurable enough for usages of all > administrators? > > As an administrator, I would like to be able to use Fedora without filling a > bug when my local settings are incompatible with Fedora's init scripts. A better workaround, in cases like these, is to rename the customized init script so that the incompatible changes will not be lost. -- Rex From nicolas.mailhot at laposte.net Wed Feb 28 14:26:51 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Feb 2007 15:26:51 +0100 (CET) Subject: Proposed guideline for init script files In-Reply-To: <45E58D48.70204@math.unl.edu> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <200702281446.10030@rineau.tsetse> <45E58D48.70204@math.unl.edu> Message-ID: <47858.192.54.193.51.1172672811.squirrel@rousalka.dyndns.org> Le Mer 28 f?vrier 2007 15:10, Rex Dieter a ?crit : > Laurent Rineau wrote: >> On Wednesday 28 February 2007 13:59:29 Christopher Blizzard wrote: > >>> +1. In general if you have to edit an init startup file, it's a bug. >>> Configuration should be in /etc/sysconfig/foo. >> >> Right. But are we sure our scripts are configurable enough for usages of >> all >> administrators? >> >> As an administrator, I would like to be able to use Fedora without >> filling a >> bug when my local settings are incompatible with Fedora's init scripts. > > A better workaround, in cases like these, is to rename the customized > init script so that the incompatible changes will not be lost. Also the scripts won't ever get flexible enough if people finding limitations in them don't report them -- Nicolas Mailhot From jkeating at redhat.com Wed Feb 28 14:41:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Feb 2007 09:41:53 -0500 Subject: Proposed guideline for init script files In-Reply-To: <45E58D48.70204@math.unl.edu> References: <200702271537.36532.jkeating@redhat.com> <200702281446.10030@rineau.tsetse> <45E58D48.70204@math.unl.edu> Message-ID: <200702280941.53336.jkeating@redhat.com> On Wednesday 28 February 2007 09:10:16 Rex Dieter wrote: > A better workaround, in cases like these, is to rename the customized > init script so that the incompatible changes will not be lost. Exactly, just like you would with any other script on the system that you want to preserve across upgrades. -- 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 Wed Feb 28 15:07:05 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 28 Feb 2007 16:07:05 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1172669919.15418.163.camel@mccallum.corsepiu.local> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> Message-ID: <20070228160705.85502291.bugs.michael@gmx.net> On Wed, 28 Feb 2007 14:38:39 +0100, Ralf Corsepius wrote: > > +1. In general if you have to edit an init startup file, it's a bug. > > Exactly ... and what can users do about it? Edit them. > > With them not being marked %config users can only hope that RH/upstream > fixes it before the next update blows away their edits :( A moot point. The same applies to all the programs, which are implemented in an interpreted language like Python. Do you want to mark all *.py files %config just because they may contain bugs? From tibbs at math.uh.edu Wed Feb 28 15:26:32 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Feb 2007 09:26:32 -0600 Subject: Proposed guideline for init script files In-Reply-To: References: <200702271537.36532.jkeating@redhat.com> Message-ID: >>>>> "GS" == Gianluca Sforna writes: GS> Will rpmlint be amended to report a warning (error?) for this? It already does; try running rpmlint -I executable-marked-as-config-file - J< From rc040203 at freenet.de Wed Feb 28 15:29:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 28 Feb 2007 16:29:15 +0100 Subject: Proposed guideline for init script files In-Reply-To: <20070228160705.85502291.bugs.michael@gmx.net> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> Message-ID: <1172676555.15418.170.camel@mccallum.corsepiu.local> On Wed, 2007-02-28 at 16:07 +0100, Michael Schwendt wrote: > On Wed, 28 Feb 2007 14:38:39 +0100, Ralf Corsepius wrote: > > > > +1. In general if you have to edit an init startup file, it's a bug. > > > > Exactly ... and what can users do about it? Edit them. > > > > With them not being marked %config users can only hope that RH/upstream > > fixes it before the next update blows away their edits :( > > A moot point. You mean, a point Fedora wishes to ignore. I'll personally remind you when it happens the next time. > The same applies to all the programs, which are implemented in an > interpreted language like Python. Do you want to mark all *.py files > %config just because they may contain bugs? Well, the more I think about it, the more I am inclined to like the idea to consider rpm's default behavior to override any modified file as a bug. Ralf From bugs.michael at gmx.net Wed Feb 28 15:48:49 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 28 Feb 2007 16:48:49 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1172676555.15418.170.camel@mccallum.corsepiu.local> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> Message-ID: <20070228164849.f5864c62.bugs.michael@gmx.net> On Wed, 28 Feb 2007 16:29:15 +0100, Ralf Corsepius wrote: > > The same applies to all the programs, which are implemented in an > > interpreted language like Python. Do you want to mark all *.py files > > %config just because they may contain bugs? > > Well, the more I think about it, the more I am inclined to like the idea > to consider rpm's default behavior to override any modified file as a > bug. The bug is that somebody modifies installed non-config files without using the packaging system. It's called "to mess around in a system". Admins, who do that, often forget what files they've changed, and "rpm -Va" only reports the changed checksum, not a diff. And what behaviour would you prefer during a dist-upgrade? That RPM refuses to install new binaries, because the user has replaced them with modified files? From Axel.Thimm at ATrpms.net Wed Feb 28 15:50:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 28 Feb 2007 16:50:15 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <45E57873.5020109@math.unl.edu> References: <45E57873.5020109@math.unl.edu> Message-ID: <20070228155015.GW20852@neu.nirvana> On Wed, Feb 28, 2007 at 06:41:23AM -0600, Rex Dieter wrote: > Parag N(????) wrote: > >Hi, > > While reviewing some fonts-* packages , I saw files being installed > >under /usr are marked as %config in their SPECS as shown below > >%config(noreplace) %verify(not md5 size mtime) %{ttfontdir}/fonts.alias > ... > >How to handle this issue? > > IMO, the fonts.alias example is a fair use of %config that's ok in my book. But we do want /usr to be "stateless". Although I can see that fixing the fonts.alias issues may be non-trivial. -- 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 Wed Feb 28 15:53:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 28 Feb 2007 16:53:24 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1172676555.15418.170.camel@mccallum.corsepiu.local> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> Message-ID: <20070228155324.GX20852@neu.nirvana> On Wed, Feb 28, 2007 at 04:29:15PM +0100, Ralf Corsepius wrote: > Well, the more I think about it, the more I am inclined to like the idea > to consider rpm's default behavior to override any modified file as a > bug. Long live the r00tk1ts -- 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 Wed Feb 28 16:17:16 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 28 Feb 2007 17:17:16 +0100 Subject: Proposed guideline for init script files In-Reply-To: <20070228164849.f5864c62.bugs.michael@gmx.net> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> <20070228164849.f5864c62.bugs.michael@gmx.net> Message-ID: <1172679436.15418.203.camel@mccallum.corsepiu.local> On Wed, 2007-02-28 at 16:48 +0100, Michael Schwendt wrote: > On Wed, 28 Feb 2007 16:29:15 +0100, Ralf Corsepius wrote: > > > > The same applies to all the programs, which are implemented in an > > > interpreted language like Python. Do you want to mark all *.py files > > > %config just because they may contain bugs? > > > > Well, the more I think about it, the more I am inclined to like the idea > > to consider rpm's default behavior to override any modified file as a > > bug. > > The bug is that somebody modifies installed non-config files without using > the packaging system. == You want users to package their customizations. Given the limitations of rpm this means to rebuild the packages. > It's called "to mess around in a system". A matter of POV. The point you seem to be missing is: I am talking about very few files, admins might have customized, e.g. * to work around bugs (I have stopped counting know how many times RH has messed up my xorg.conf, my named.conf over all these years, and how many times I have modified init-prios to work around this still unfixed portmapper port allocation bugs) * to add missing/experimental features. * because they are developing on something. * because they have 3rd party packages installed which might apply a different sub-package splits. * because traditional packaging of packages were designed to be modified (e.g. site-wide app-defaults) > Admins, who do that, often > forget what files they've changed, and "rpm -Va" only reports the changed > checksum, not a diff. Please, try that. With Fedora, the results of an rpm -Va is hardly usable (alternatives, files outside of rpm control, missing dir ownerships etc.). > And what behaviour would you prefer during a dist-upgrade? That RPM > refuses to install new binaries, because the user has replaced them with > modified files? Nope, I'd prefer an rpm that refuses to replace modified _files_ (Note: files, not packages) and backs them up (similar to *.rpmsave or *.rpmnew). Of cause such an rpm also would have to have a "--force" mode to forcibly replace such files. Ralf From bugs.michael at gmx.net Wed Feb 28 17:12:06 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 28 Feb 2007 18:12:06 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1172679436.15418.203.camel@mccallum.corsepiu.local> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> <20070228164849.f5864c62.bugs.michael@gmx.net> <1172679436.15418.203.camel@mccallum.corsepiu.local> Message-ID: <20070228181206.19dab9b8.bugs.michael@gmx.net> On Wed, 28 Feb 2007 17:17:16 +0100, Ralf Corsepius wrote: > > > Well, the more I think about it, the more I am inclined to like the idea > > > to consider rpm's default behavior to override any modified file as a > > > bug. > > > > The bug is that somebody modifies installed non-config files without using > > the packaging system. > == You want users to package their customizations. Given the limitations > of rpm this means to rebuild the packages. Yes, the source rpms are available. Using local repositories is possible, too, and highly recommended if you want to install the same fix on multiple machines. > The point you seem to be missing is: I am talking about very few files, > admins might have customized, e.g. Customisation => %config files => done You refer to modifications which go beyond the scope of the software's configuration files. Else you would not need to touch non-config files. > * to work around bugs (I have stopped counting know how many times RH > has messed up my xorg.conf, my named.conf over all these years, Neither one is marked a %config file. Perhaps you refer to config tools which have written to the files [at install/update-time]? > and how > many times I have modified init-prios to work around this still unfixed > portmapper port allocation bugs) That doesn't require you to modify init files, though. > * to add missing/experimental features. > > * because they are developing on something. > > * because they have 3rd party packages installed which might apply a > different sub-package splits. This is an entirely different beast. We've come a long way to get confirmation, repeatedly, that 3rd party packages either are compatible or aren't. > * because traditional packaging of packages were designed to be modified > (e.g. site-wide app-defaults) In non-%config files? > > Admins, who do that, often > > forget what files they've changed, and "rpm -Va" only reports the changed > > checksum, not a diff. > > Please, try that. With Fedora, the results of an rpm -Va is hardly > usable (alternatives, files outside of rpm control, missing dir > ownerships etc.). Even more reason to install modifications via RPM packages. > > And what behaviour would you prefer during a dist-upgrade? That RPM > > refuses to install new binaries, because the user has replaced them with > > modified files? > Nope, I'd prefer an rpm that refuses to replace modified _files_ (Note: > files, not packages) and backs them up (similar to *.rpmsave or > *.rpmnew). Of cause such an rpm also would have to have a "--force" mode > to forcibly replace such files. *.rpmnew for such files would be a show-stopper. Just imagine how RPM could not guarantee integrity of an installed set of packages, if it installed any updated files as *.rpmnew. I can think of RPM creating backups of any files, which don't belong into any package, before overwriting them. But the problem is selfmade: modifying files which belong into packages, and mixing unpackaged files and packages in an installation. This bears the risk of breaking in many places. It's also one reason why the filesys has places like /usr/local and site-specific install locations. From rc040203 at freenet.de Wed Feb 28 17:50:44 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 28 Feb 2007 18:50:44 +0100 Subject: Proposed guideline for init script files In-Reply-To: <20070228181206.19dab9b8.bugs.michael@gmx.net> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> <20070228164849.f5864c62.bugs.michael@gmx.net> <1172679436.15418.203.camel@mccallum.corsepiu.local> <20070228181206.19dab9b8.bugs.michael@gmx.net> Message-ID: <1172685044.15418.237.camel@mccallum.corsepiu.local> On Wed, 2007-02-28 at 18:12 +0100, Michael Schwendt wrote: > On Wed, 28 Feb 2007 17:17:16 +0100, Ralf Corsepius wrote: > > > > > Well, the more I think about it, the more I am inclined to like the idea > > > > to consider rpm's default behavior to override any modified file as a > > > > bug. > > > > > > The bug is that somebody modifies installed non-config files without using > > > the packaging system. > > == You want users to package their customizations. Given the limitations > > of rpm this means to rebuild the packages. > > Yes, the source rpms are available. Inapplicable to "joe average" > Using local repositories is possible, > too, and highly recommended if you want to install the same fix on > multiple machines. How do you think did I get into packaging? Because it's fun? No. Because the limitations of rpm, how it had been used by vendors (% config) and vendors not having been able to provide bug-fixes in reasonable time had forced me into it. > > The point you seem to be missing is: I am talking about very few files, > > admins might have customized, e.g. > > Customisation => %config files => done Yes! But this thread started with the FPC having decided to drop %config on init scripts, because the majority of FPC members doesn't consider them to be config scripts. i.e. this decision has rendered this way of bug-fixing impossible. > You refer to modifications which go beyond the scope of the software's > configuration files. As I said many times before: init scripts traditionally have been config files, ever since *nix'ish OSes exist (the origin is the early *nixes having used monolytic rc.local init scripts). > > * to work around bugs (I have stopped counting know how many times RH > > has messed up my xorg.conf, my named.conf over all these years, > > Neither one is marked a %config file. Perhaps you refer to config > tools which have written to the files [at install/update-time]? True, xorg.conf isn't owned by any rpm, and named.conf seems to be ghosted, but ... if not them which files else are config files? > > * to add missing/experimental features. > > > > * because they are developing on something. > > > > * because they have 3rd party packages installed which might apply a > > different sub-package splits. > > This is an entirely different beast. We've come a long way to get > confirmation, repeatedly, that 3rd party packages either are compatible > or aren't. At the very moment a package is being introduced into Fedora, any existing 3rd party package has no chance to be compatible > > * because traditional packaging of packages were designed to be modified > > (e.g. site-wide app-defaults) > > In non-%config files? Init scripts was the point this thread has started with. Now people have started a crusade against %config files outside of /etc. > > > And what behaviour would you prefer during a dist-upgrade? That RPM > > > refuses to install new binaries, because the user has replaced them with > > > modified files? > > Nope, I'd prefer an rpm that refuses to replace modified _files_ (Note: > > files, not packages) and backs them up (similar to *.rpmsave or > > *.rpmnew). Of cause such an rpm also would have to have a "--force" mode > > to forcibly replace such files. > > *.rpmnew for such files would be a show-stopper. Just imagine how RPM > could not guarantee integrity of an installed set of packages, if it > installed any updated files as *.rpmnew. > > I can think of RPM creating backups of any files, which don't belong into > any package, before overwriting them. But the problem is selfmade: > modifying files which belong into packages, and mixing unpackaged files > and packages in an installation. Again matter of POV: It's often the easiest way to fix (often trivial) bugs, and it's often the easiest way to add features. > This bears the risk of breaking in many > places. It's also one reason why the filesys has places like /usr/local > and site-specific install locations. This doesn't help when it comes to packaging bugs below /etc, esp. to bugs in init scripts. Just imagine an initscript having a typo in a rarely used "case/switch". The quick fix would be "fix that typo". Without %config, the next update will blow this change away. If Fedora hasn't fixed it, ... your changes will be lost. Ralf From coldwell at redhat.com Wed Feb 28 17:54:27 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Wed, 28 Feb 2007 12:54:27 -0500 (Eastern Standard Time) Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070228155015.GW20852@neu.nirvana> References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> Message-ID: On Wed, 28 Feb 2007, Axel Thimm wrote: > On Wed, Feb 28, 2007 at 06:41:23AM -0600, Rex Dieter wrote: > > Parag N(????????????) wrote: > > >Hi, > > > While reviewing some fonts-* packages , I saw files being installed > > >under /usr are marked as %config in their SPECS as shown below > > >%config(noreplace) %verify(not md5 size mtime) %{ttfontdir}/fonts.alias > > ... > > >How to handle this issue? > > > > IMO, the fonts.alias example is a fair use of %config that's ok in my book. > > But we do want /usr to be "stateless". Although I can see that fixing > the fonts.alias issues may be non-trivial. I agree. Ideally, /usr could be a filesystem mounted read-only. Somebody shoulda told those X11 guys that. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From rdieter at math.unl.edu Wed Feb 28 17:57:12 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Feb 2007 11:57:12 -0600 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> Message-ID: <45E5C278.6020605@math.unl.edu> Chip Coldwell wrote: > On Wed, 28 Feb 2007, Axel Thimm wrote: > >> On Wed, Feb 28, 2007 at 06:41:23AM -0600, Rex Dieter wrote: >>> Parag N(????) wrote: >>>> Hi, >>>> While reviewing some fonts-* packages , I saw files being installed >>>> under /usr are marked as %config in their SPECS as shown below >>>> %config(noreplace) %verify(not md5 size mtime) %{ttfontdir}/fonts.alias >>> ... >>>> How to handle this issue? >>> IMO, the fonts.alias example is a fair use of %config that's ok in my book. >> But we do want /usr to be "stateless". Although I can see that fixing >> the fonts.alias issues may be non-trivial. > > I agree. Ideally, /usr could be a filesystem mounted read-only. Somebody > shoulda told those X11 guys that. OTOH, fonts.alias is way-old legacy pre-fontconfig stuff anyway. Is xfs gone yet? (: -- Rex From coldwell at redhat.com Wed Feb 28 18:02:58 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Wed, 28 Feb 2007 13:02:58 -0500 (Eastern Standard Time) Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <45E5C278.6020605@math.unl.edu> References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> <45E5C278.6020605@math.unl.edu> Message-ID: On Wed, 28 Feb 2007, Rex Dieter wrote: > > OTOH, fonts.alias is way-old legacy pre-fontconfig stuff anyway. Is xfs gone > yet? (: I, for one, would miss it. I know that probably 99% of xfs installations are using a font server on localhost, but I've actually had situations where it was very useful to have a network based font server: 1. X Terminals (a.k.a. thin clients) can get their fonts from the server's xfs process. Makes updating the collection of fonts the X Terminals are using *much* easier. 2. Obscure fonts, such as those used by Mathematica, can be installed in one place and distrubted network wide. But now this thread is wandering off the topic a bit .... Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From notting at redhat.com Wed Feb 28 18:12:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 28 Feb 2007 13:12:43 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E52664.7020302@leemhuis.info> References: <45E37E11.7080805@redhat.com> <45E52664.7020302@leemhuis.info> Message-ID: <20070228181243.GA31458@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > As two other (red hat) people said "overkill" and "Overly complex" I'd > like to say the opposite: I like the direction, but would like to see > https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00764.html > integrated. Sure, maybe some other details need to be adjusted, but this > scheme might meld a lot to get new people involved and growing up in the > project. And that's hardly needed and the best for the project. I agree that we should have a way for new contributors to have access to just their packages. I don't see how this is the right answer to solve that. Bill From a.badger at gmail.com Wed Feb 28 19:03:56 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 28 Feb 2007 11:03:56 -0800 Subject: Proposed guideline for init script files In-Reply-To: <200702281446.10030@rineau.tsetse> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <200702281446.10030@rineau.tsetse> Message-ID: <1172689436.20343.40.camel@localhost.localdomain> On Wed, 2007-02-28 at 14:46 +0100, Laurent Rineau wrote: > On Wednesday 28 February 2007 13:59:29 Christopher Blizzard wrote: > > On Tue, 2007-02-27 at 15:37 -0500, Jesse Keating wrote: > > > The Packaging Committee has been discussing guidelines for init scripts > > > for a while. Currently there is a split between init scripts being > > > marked as %config and many that aren't. We (the PC) with input from > > > various folks feel it is best to not mark init scripts as %config, and > > > instead promote configuration to happen in an /etc/sysconfig/ file. > > > Mostly the reason being that init scripts are just that, scripts to run > > > and not config files to edit. As such I've drafted a proposal for the > > > guidelines and the PC approved it. There is time now for a wider > > > audience to review the proposed change and comment. > > > > +1. In general if you have to edit an init startup file, it's a bug. > > Configuration should be in /etc/sysconfig/foo. > > Right. But are we sure our scripts are configurable enough for usages of all > administrators? > > As an administrator, I would like to be able to use Fedora without filling a > bug when my local settings are incompatible with Fedora's init scripts. > This was my only complaint with the policy. I think it needs to emphasize the importance of packagers exposing configuration options to the enduser. Otherwise we put users in the unenviable position of having their necessary changes silently lost with every update. Matthias's suggestion to have a Best Practices section that outlines what a proper init script will help as well. There should be a section that talks about exposing customization. Here's a snippet for exposing the command line: ''' If your daemon can be customized via environment variables or commandline switches, then you need to expose that to the end user. Do this by 1. Creating an /etc/sysconfig/DAEMONNAME file to store the configuration in. Be sure to add comments to this file that indicate what variables it will know about. 2. Your init script must source that config file. 3. If the daemon you're starting takes commandline options, one of the variables must be DAEMONOPTS which your init script will use when it invokes the daemon. Be sure that this variable allows the user to override any commandline options you've placed in the file. If the daemon does not override arguments but rather spits out errors (like "-v and -q are incompatible. Please specify one or the other.") you may have to place the default commandline options in the sysconfig config file. ''' We should also have some rough guidelines of what customization would be so invasive that a separate package should be built instead of trying to support it in the initscript/config file. For instance, managing the package in a chroot might be something that is configured by dropping a second package on the system that has a different init script and a chroot environment setup. The one thing that I see as the worst of all worlds is encouraging a situation where initscripts are not config and we simultaneously have packages where bugs about customization are considered low priority. -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 bugs.michael at gmx.net Wed Feb 28 19:08:55 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 28 Feb 2007 20:08:55 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1172685044.15418.237.camel@mccallum.corsepiu.local> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> <20070228164849.f5864c62.bugs.michael@gmx.net> <1172679436.15418.203.camel@mccallum.corsepiu.local> <20070228181206.19dab9b8.bugs.michael@gmx.net> <1172685044.15418.237.camel@mccallum.corsepiu.local> Message-ID: <20070228200855.e2a2ff72.bugs.michael@gmx.net> On Wed, 28 Feb 2007 18:50:44 +0100, Ralf Corsepius wrote: > > Yes, the source rpms are available. > Inapplicable to "joe average" Does "joe average" fix bugs the way you've described? > > > The point you seem to be missing is: I am talking about very few files, > > > admins might have customized, e.g. > > > > Customisation => %config files => done > Yes! But this thread started with the FPC having decided to drop %config > on init scripts, because the majority of FPC members doesn't consider > them to be config scripts. > > i.e. this decision has rendered this way of bug-fixing impossible. Bug in an init-script => submit a bug report in bugzilla => expect an update/errata package => why is an update of the package released which doesn't fix the bug? If the problem or fix is contradictory, disable the service, create your own renamed initscript. Perhaps exclude the package from being updated, since you don't trust the vendor anyway. > > You refer to modifications which go beyond the scope of the software's > > configuration files. > As I said many times before: init scripts traditionally have been config > files, ever since *nix'ish OSes exist (the origin is the early *nixes > having used monolytic rc.local init scripts). %config vs. %config(noreplace) vs. no %config Isn't it too much of a risk to make init scripts a %config file that is not kept in sync with package updates? > > > * to work around bugs (I have stopped counting know how many times RH > > > has messed up my xorg.conf, my named.conf over all these years, > > > > Neither one is marked a %config file. Perhaps you refer to config > > tools which have written to the files [at install/update-time]? > True, xorg.conf isn't owned by any rpm, and named.conf seems to be > ghosted, but ... if not them which files else are config files? There are services, for which a default configuration is possible. For other services, the configuration system is not flexible enough (e.g. no include mechanism, no /etc/sysconfig usage, etc.), hence it makes no sense to ship a default. > > > * to add missing/experimental features. > > > > > > * because they are developing on something. > > > > > > * because they have 3rd party packages installed which might apply a > > > different sub-package splits. > > > > This is an entirely different beast. We've come a long way to get > > confirmation, repeatedly, that 3rd party packages either are compatible > > or aren't. > At the very moment a package is being introduced into Fedora, any > existing 3rd party package has no chance to be compatible Are the 3rd party packages unmaintained? Personally, I'm tired of that "3rd party" topic unless there is a > Init scripts was the point this thread has started with. Now people have > started a crusade against %config files outside of /etc. If there's one thing you can annoy "joe average" with, it's config files that are spread over the entire filesys. Add on top of that files in /var, which are erased during package removal, because the packager has included them in the package. > bugs in init scripts. Just imagine an initscript having a typo in a > rarely used "case/switch". The quick fix would be "fix that typo". > > Without %config, the next update will blow this change away. If Fedora > hasn't fixed it, ... your changes will be lost. I am a proponent of fixing the vendor's broken package instead of trying to work around the crap for too long. Even more since it's supposed to be an open community project, which releases hundreds of updates. A "rarely used case/switch"? So what? It's broken, isn't it? The vendor's stuff should _just work_, let's not forget that! Whether it's an init script or Python code or Perl code, doesn't matter. You cannot mark everything %config(noreplace) just to be able to give your temporary fixes precedence over official package updates. I have no idea where that would start and where it would end (libs? binaries?). From bugs.michael at gmx.net Wed Feb 28 19:17:44 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 28 Feb 2007 20:17:44 +0100 Subject: Proposed guideline for init script files In-Reply-To: <20070228200855.e2a2ff72.bugs.michael@gmx.net> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> <1172676555.15418.170.camel@mccallum.corsepiu.local> <20070228164849.f5864c62.bugs.michael@gmx.net> <1172679436.15418.203.camel@mccallum.corsepiu.local> <20070228181206.19dab9b8.bugs.michael@gmx.net> <1172685044.15418.237.camel@mccallum.corsepiu.local> <20070228200855.e2a2ff72.bugs.michael@gmx.net> Message-ID: <20070228201744.a1150e06.bugs.michael@gmx.net> On Wed, 28 Feb 2007 20:08:55 +0100, Michael Schwendt wrote: > > At the very moment a package is being introduced into Fedora, any > > existing 3rd party package has no chance to be compatible > > Are the 3rd party packages unmaintained? > > Personally, I'm tired of that "3rd party" topic unless there is a [got distracted at this point] - should have read: Personally, I'm tired of that "3rd party" topic unless there is a program, where 3rd party vendors can register (and share details about their requirements) and a set of strict guidelines on how to keep a distribution release ABI- and API-compatible. I'm not comfortable with the scenario, in which an unknown 3rd party vendor replaces or modifies arbitrary packages of the distribution without any guidelines. From blizzard at redhat.com Wed Feb 28 14:44:50 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 28 Feb 2007 09:44:50 -0500 Subject: Proposed guideline for init script files In-Reply-To: <1172669919.15418.163.camel@mccallum.corsepiu.local> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> Message-ID: <1172673890.2871.5.camel@localhost.localdomain> On Wed, 2007-02-28 at 14:38 +0100, Ralf Corsepius wrote: > > +1. In general if you have to edit an init startup file, it's a bug. > > Exactly ... and what can users do about it? Edit them. > > With them not being marked %config users can only hope that RH/upstream > fixes it before the next update blows away their edits :( How is that different than any other part of the OS that uses a shell script? Are the init scripts so buggy that we need to be able to mark them with %config where we don't do that with other parts of the OS? There's another problem with using %config for init scripts. The way that programs start up changes over time. They are closely tied to the program they have to start. If the init script isn't updated with the binary then after an upgrade a program might not start in the intended fashion. It breaks the upgrade path. I would rather see the init scripts fixed than marking them as %config. > > > Configuration should be in /etc/sysconfig/foo. > But real bugs and missing features init scripts suffer from can't. > > As I've said many times before, I consider not marking init scripts > %config a regression, Fedora will regret. I'm don't believe that. It's certainly not a regression by any stretch. It sounds like you're run into bugs with the init scripts, or their configuration wasn't rich enough and editing them directly has been the only way you've been able to manage. I would love to see you work with the various owners and get fixes in place so we don't have to break upgrade paths. A nice side effect of that work would be that everyone has more options for their init scripts too - everyone benefits. --Chris From blizzard at redhat.com Wed Feb 28 16:08:07 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 28 Feb 2007 11:08:07 -0500 Subject: Proposed guideline for init script files In-Reply-To: <200702281446.10030@rineau.tsetse> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <200702281446.10030@rineau.tsetse> Message-ID: <1172678887.2871.11.camel@localhost.localdomain> On Wed, 2007-02-28 at 14:46 +0100, Laurent Rineau wrote: > > +1. In general if you have to edit an init startup file, it's a bug. > > Configuration should be in /etc/sysconfig/foo. > > Right. But are we sure our scripts are configurable enough for usages of all > administrators? That feels like hyperbole to me. Of course we're not perfect for every person in every circumstance. But we should be close, and if you're reaction to that problem is to use the hammer of %config - and it's a big hammer - then it's clear there's a long way to go in the init scripts to at least capture some large part of the functionality that people need. It's an incremental process, not one that will be solved overnight. But that's not enough reason to make upgrades not work properly. > As an administrator, I would like to be able to use Fedora without filling a > bug when my local settings are incompatible with Fedora's init scripts. What do you do when a program doesn't do what you need? These are little programs, they aren't config files. --Chris From blizzard at redhat.com Wed Feb 28 16:50:11 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 28 Feb 2007 11:50:11 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E52664.7020302@leemhuis.info> References: <45E37E11.7080805@redhat.com> <45E52664.7020302@leemhuis.info> Message-ID: <1172681411.2871.55.camel@localhost.localdomain> On Wed, 2007-02-28 at 07:51 +0100, Thorsten Leemhuis wrote: > On 27.02.2007 01:40, Warren Togami wrote: > > ================================================== > > = Strawman of Fedora Developer Ranking System v1 = > > ================================================== > > This concept document contains only *IDEAS* of why we would want a > > ranking system, and how a ranking system might be useful. Below are > > only examples. Please add your ideas to this thread. > > [...] > > As two other (red hat) people said "overkill" and "Overly complex" I'd > like to say the opposite: I like the direction, but would like to see > https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00764.html > integrated. Sure, maybe some other details need to be adjusted, but this > scheme might meld a lot to get new people involved and growing up in the > project. And that's hardly needed and the best for the project. > > Even if the system is a bit more complex than what we have now -- it > lowers the bar (that's quite high ATM) to get involved into Fedora, and > that's important to get new people in. It's thus a step into the right > direction. I think the specific proposal is too complex. (It _is_ a strawman, after all!) But I like the idea of doing something like this. The incentives are nice, but I'm more interested in allowing people to choose their level of participation in a particular part of the project. For example, there are a large number of packages that I care about, but I don't need to own. I just want to be informed when there are changes. Or if someone is doing translations for a particular package, they should be able to watch that package for changes and jump in when that happens. As near as I can tell that's not easy right now. Some examples of the kinds of things that I'm talking about: o Watcher - "I care about this package." o Developer - "I should be consulted when there are major changes to this package." o Owner - "I am accountable for changes in this package. The buck stops here." o Hacker - "I can make changes to this package." (Extra bonus points to Red Hat people who know where these four things come from.) People will naturally work their way up the stack, and this is more self-descriptive than just numbers. And I would think in terms of responsibilities, not merit badges. We want delegation to scale here. --Chris From hp at redhat.com Wed Feb 28 19:51:10 2007 From: hp at redhat.com (Havoc Pennington) Date: Wed, 28 Feb 2007 14:51:10 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <1172681411.2871.55.camel@localhost.localdomain> References: <45E37E11.7080805@redhat.com> <45E52664.7020302@leemhuis.info> <1172681411.2871.55.camel@localhost.localdomain> Message-ID: <45E5DD2E.3090305@redhat.com> Christopher Blizzard wrote: > I think the specific proposal is too complex. (It _is_ a strawman, > after all!) But I like the idea of doing something like this. The > incentives are nice, but I'm more interested in allowing people to > choose their level of participation in a particular part of the project. > For example, there are a large number of packages that I care about, but > I don't need to own. I just want to be informed when there are changes. > Or if someone is doing translations for a particular package, they > should be able to watch that package for changes and jump in when that > happens. As near as I can tell that's not easy right now. When we did the Red-Hat-internal study/design-recommendations on bugzilla and related systems, one of the big guidelines was visibility rather than enforcement. That is, the important thing is that the right people see the right things, while most "fix the system" discussion seem to focus on either making people do the right things or keeping people from doing the wrong things. (Or imagining that people will fill out dozens of little bugzilla fields then keep them up to date, but that's another issue - maybe just someone's OCD or love of policy-writing.) If you try to encode a bunch of policies in software tools you just get a nightmare. It's much better to design the tools so they are simple for intelligent people to use to do what they want, and people can easily and accurately see what's going on, and then allow social mechanisms (including the "flame", "cluebat", and other time-tested tools) to take care of the rest. Think wiki, not Enterprise Workflow. ACLs are fine as a broad thing to keep total strangers from putting a virus in a package - but getting too fine-grained with security clearances and policies within a community of people who are supposed to be working together is just overhead that sucks energy - implementation, administration, and endless policy debates. Look at the current kernel system with git - I've never used it, but my impression is that it's centered on accountability (being able to see where stuff came from). Similarly, for years GNOME CVS/SVN was pretty much one big unified commit access, and the security policy was mailing all the changes to cvs-commits-list where people could see them. bugzilla "points" works relatively well because it's simple and transparent, requires no extra work, but most importantly because the points are interpreted by humans and not computers. If I have a lot of bugzilla points it just means people know I spent a lot of time in bugzilla, and then they use that knowledge wisely. For example, if you want someone to patch a package but not build it, why not just ask them; and if they build it anyway, kick them out of your package. There's no reason to have a complicated policy about it. Or if you want long-term developers to have more weight, just show how long someone has been a developer or how many packages they own somewhere prominent. Those developers will automatically pull more weight when appropriate because people will know they are experienced developers. Havoc From enrico.scholz at informatik.tu-chemnitz.de Wed Feb 28 19:52:00 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 28 Feb 2007 20:52:00 +0100 Subject: Proposed guideline for init script files In-Reply-To: <20070228160705.85502291.bugs.michael@gmx.net> (Michael Schwendt's message of "Wed, 28 Feb 2007 16:07:05 +0100") References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <20070228160705.85502291.bugs.michael@gmx.net> Message-ID: <877iu22h7j.fsf@kosh.bigo.ensc.de> bugs.michael at gmx.net (Michael Schwendt) writes: >> With them not being marked %config users can only hope that RH/upstream >> fixes it before the next update blows away their edits :( > > A moot point. > > The same applies to all the programs, which are implemented in an > interpreted language like Python. Do you want to mark all *.py files > %config just because they may contain bugs? When they are under /etc: yes. Enrico From enrico.scholz at informatik.tu-chemnitz.de Wed Feb 28 19:56:18 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 28 Feb 2007 20:56:18 +0100 Subject: Proposed guideline for init script files In-Reply-To: <1172673890.2871.5.camel@localhost.localdomain> (Christopher Blizzard's message of "Wed, 28 Feb 2007 09:44:50 -0500") References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1172673890.2871.5.camel@localhost.localdomain> Message-ID: <873b4q2h0d.fsf@kosh.bigo.ensc.de> blizzard at redhat.com (Christopher Blizzard) writes: > How is that different than any other part of the OS that uses a shell > script? Are the init scripts so buggy that we need to be able to mark > them with %config where we don't do that with other parts of the OS? /etc is the classical location for configuration files and I *expect* that I can edit things there resp. that my changes are not lost silently. Enrico From enrico.scholz at informatik.tu-chemnitz.de Wed Feb 28 20:00:09 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 28 Feb 2007 21:00:09 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <20070228155015.GW20852@neu.nirvana> (Axel Thimm's message of "Wed, 28 Feb 2007 16:50:15 +0100") References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> Message-ID: <87y7mi129i.fsf@kosh.bigo.ensc.de> Axel.Thimm at ATrpms.net (Axel Thimm) writes: >> > While reviewing some fonts-* packages , I saw files being installed >> >under /usr are marked as %config in their SPECS as shown below >> >%config(noreplace) %verify(not md5 size mtime) %{ttfontdir}/fonts.alias >> ... >> IMO, the fonts.alias example is a fair use of %config that's ok in my book. > > But we do want /usr to be "stateless". afaik, 'fonts.alias' has nothing todo with stateless or non-stateless. This file won't be touched by any system program (in opposite to fonts.dir and fonts.scale) but might be used to configure preferences for certain fonts (e.g. 'fixed' or 'cursor'). Enrico From wtogami at redhat.com Wed Feb 28 20:17:12 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 28 Feb 2007 15:17:12 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <1172681411.2871.55.camel@localhost.localdomain> References: <45E37E11.7080805@redhat.com> <45E52664.7020302@leemhuis.info> <1172681411.2871.55.camel@localhost.localdomain> Message-ID: <45E5E348.1090802@redhat.com> Christopher Blizzard wrote: > > I think the specific proposal is too complex. (It _is_ a strawman, > after all!) But I like the idea of doing something like this. The > incentives are nice, but I'm more interested in allowing people to > choose their level of participation in a particular part of the project. The strawman ranking system doesn't get in the way of choosing levels of participation if all you are interested in is watching some things, owning others, and hacking others. The strawman rankings system is primarily a merit tracker. Responsibilities or watches can be assigned or subscribed as needed outside of the ranks. Thus you only participate in ranks if you want to. I suspect this is reasonable if you are interested in community policy and technical governance (which most developers are not.) > For example, there are a large number of packages that I care about, but > I don't need to own. I just want to be informed when there are changes. > Or if someone is doing translations for a particular package, they > should be able to watch that package for changes and jump in when that > happens. As near as I can tell that's not easy right now. Some > examples of the kinds of things that I'm talking about: > > o Watcher - "I care about this package." > o Developer - "I should be consulted when there are major changes to > this package." I believe what you want are different types of "subscriptions" in order to watch specific things that you care about? > o Owner - "I am accountable for changes in this package. The buck stops > here." > o Hacker - "I can make changes to this package." (but not own it) > > (Extra bonus points to Red Hat people who know where these four things > come from.) > > People will naturally work their way up the stack, and this is more > self-descriptive than just numbers. And I would think in terms of > responsibilities, not merit badges. We want delegation to scale here. > I believe *some* merit system (be it Bugzilla and/or ranks) will be useful. I am just brain storming possibilities. After the basics of PackageDB and koji are driving the distro workflow, we may more seriously think about how a merit system can augment or enhance this. Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Wed Feb 28 20:25:37 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 28 Feb 2007 21:25:37 +0100 Subject: Proposed guideline for init script files In-Reply-To: <873b4q2h0d.fsf@kosh.bigo.ensc.de> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1172673890.2871.5.camel@localhost.localdomain> <873b4q2h0d.fsf@kosh.bigo.ensc.de> Message-ID: <20070228212537.d2ada58f.bugs.michael@gmx.net> On Wed, 28 Feb 2007 20:56:18 +0100, Enrico Scholz wrote: > > How is that different than any other part of the OS that uses a shell > > script? Are the init scripts so buggy that we need to be able to mark > > them with %config where we don't do that with other parts of the OS? > > /etc is the classical location for configuration files and I *expect* > that I can edit things there resp. that my changes are not lost silently. /etc contains things, such as GConf2 schema files, which you are not supposed to edit. From wtogami at redhat.com Wed Feb 28 20:30:35 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 28 Feb 2007 15:30:35 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E5DD2E.3090305@redhat.com> References: <45E37E11.7080805@redhat.com> <45E52664.7020302@leemhuis.info> <1172681411.2871.55.camel@localhost.localdomain> <45E5DD2E.3090305@redhat.com> Message-ID: <45E5E66B.8030508@redhat.com> Havoc Pennington wrote: > > bugzilla "points" works relatively well because it's simple and > transparent, requires no extra work, but most importantly because the > points are interpreted by humans and not computers. If I have a lot of > bugzilla points it just means people know I spent a lot of time in > bugzilla, and then they use that knowledge wisely. > I suspect a points system would be good, but we could perhaps improve on this... - Points in itself is not a hard indicator of merit or promotion eligibility, just a strong hint of the contributor's value to the project. - Earning points is logarithmic. You shouldn't earn a super high score by doing an inordinate amount of one thing. Points should perhaps reward doing different things more than plenty of the same thing. - Points shouldn't be just for Bugzilla activity, there other potential sources. - Points might accrue for consistent activity, and gradually fall if you stop participating. (Note, points have no relation with access levels, so people who participate without care for points to maintain only specific packages don't need to care about maintaining consistent activity.) (just some brainstorming) Warren From triad at df.lth.se Wed Feb 28 21:23:04 2007 From: triad at df.lth.se (Linus Walleij) Date: Wed, 28 Feb 2007 22:23:04 +0100 (CET) Subject: /etc/sysconfig detour In-Reply-To: <200702271537.36532.jkeating@redhat.com> References: <200702271537.36532.jkeating@redhat.com> Message-ID: On Tue, 27 Feb 2007, Jesse Keating wrote: > (...) promote > configuration to happen in an /etc/sysconfig/ file. I think this is a moment to think about the fact that in some parts of the world, /etc/sysconfig is understood as a hopeless redhat:ism. The reason why it is there and why you sometimes, only having experience with other distributions (yeah I know SuSE use it too nowadays), or even with other POSIX systems, are surprised with finding important config stuff in /etc/sysconfig after looking around elsewhere for some time. Example: Fedora /etc/sysconfig/network-scripts/ifcfg-eth0 define config for eth0 to be used at boot and run level changes. In Debian this is at /etc/network/interface I think. In Gentoo supposedly in a third place. In BSD, Solaris, Mac OS I dare not even guess anymore, didn't administer them in years. We need to note down, in the guidelines or so: * Why we put things in /etc/sysconfig in a very clear, concise and understandable manner, that noone can misunderstand (though they might disagree) * That we think it would be a natural thing to have in the FHS! (And let those who have energy for it lobby to get it into there.) I have no doubt that Jesse can put this in very clear words, problem is that I think noone has ever done that, and it is percieved idiosyncratic. Linus From enrico.scholz at informatik.tu-chemnitz.de Wed Feb 28 21:32:47 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 28 Feb 2007 22:32:47 +0100 Subject: Proposed guideline for init script files In-Reply-To: <20070228212537.d2ada58f.bugs.michael@gmx.net> (Michael Schwendt's message of "Wed, 28 Feb 2007 21:25:37 +0100") References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1172673890.2871.5.camel@localhost.localdomain> <873b4q2h0d.fsf@kosh.bigo.ensc.de> <20070228212537.d2ada58f.bugs.michael@gmx.net> Message-ID: <87tzx60xz4.fsf@kosh.bigo.ensc.de> bugs.michael at gmx.net (Michael Schwendt) writes: >> /etc is the classical location for configuration files and I >> *expect* that I can edit things there resp. that my changes are >> not lost silently. > > /etc contains things, such as GConf2 schema files, which you are not > supposed to edit. Then, they do not belong into /etc and should be moved out it. Enrico From Axel.Thimm at ATrpms.net Wed Feb 28 21:49:26 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 28 Feb 2007 22:49:26 +0100 Subject: Core packages are using %config for files being installed under /usr In-Reply-To: <87y7mi129i.fsf@kosh.bigo.ensc.de> References: <45E57873.5020109@math.unl.edu> <20070228155015.GW20852@neu.nirvana> <87y7mi129i.fsf@kosh.bigo.ensc.de> Message-ID: <20070228214926.GN1417@neu.nirvana> On Wed, Feb 28, 2007 at 09:00:09PM +0100, Enrico Scholz wrote: > Axel.Thimm at ATrpms.net (Axel Thimm) writes: > > >> > While reviewing some fonts-* packages , I saw files being installed > >> >under /usr are marked as %config in their SPECS as shown below > >> >%config(noreplace) %verify(not md5 size mtime) %{ttfontdir}/fonts.alias > >> ... > >> IMO, the fonts.alias example is a fair use of %config that's ok in my book. > > > > But we do want /usr to be "stateless". > > afaik, 'fonts.alias' has nothing todo with stateless or non-stateless. This > file won't be touched by any system program (in opposite to fonts.dir and > fonts.scale) but might be used to configure preferences for certain fonts > (e.g. 'fixed' or 'cursor'). Which is really hard to do on a real-only filesystem. -- 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 hp at redhat.com Wed Feb 28 22:19:16 2007 From: hp at redhat.com (Havoc Pennington) Date: Wed, 28 Feb 2007 17:19:16 -0500 Subject: Fedora Developer Ranking System v1 In-Reply-To: <45E5E66B.8030508@redhat.com> References: <45E37E11.7080805@redhat.com> <45E52664.7020302@leemhuis.info> <1172681411.2871.55.camel@localhost.localdomain> <45E5DD2E.3090305@redhat.com> <45E5E66B.8030508@redhat.com> Message-ID: <45E5FFE4.3020903@redhat.com> Warren Togami wrote: > > I suspect a points system would be good, but we could perhaps improve on > this... > > - Points in itself is not a hard indicator of merit or promotion > eligibility, just a strong hint of the contributor's value to the project. > - Earning points is logarithmic. You shouldn't earn a super high score > by doing an inordinate amount of one thing. Points should perhaps > reward doing different things more than plenty of the same thing. > - Points shouldn't be just for Bugzilla activity, there other potential > sources. > - Points might accrue for consistent activity, and gradually fall if you > stop participating. (Note, points have no relation with access levels, > so people who participate without care for points to maintain only > specific packages don't need to care about maintaining consistent > activity.) > Remember this stuff is for human interpretation. So basing just on bugzilla is fine; high points means "does a lot of bugzilla stuff." Having also "years as fedora contributor" or "number of packages owned" would also be easy to understand, but to me probably easier if they are separate metrics. Any kind of complex formula and nobody knows what the number means. But really, define the problem... for me bugzilla points are so people jumping into the community can tell who is just a drive-by commentator and who is a contributor. They seem to work fine for that. I don't see why you'd want some single rank metric to measure someone's global Fedora coolness. Havoc From bugs.michael at gmx.net Wed Feb 28 22:47:27 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 28 Feb 2007 23:47:27 +0100 Subject: Proposed guideline for init script files In-Reply-To: <87tzx60xz4.fsf@kosh.bigo.ensc.de> References: <200702271537.36532.jkeating@redhat.com> <1172667569.7686.2.camel@localhost.localdomain> <1172669919.15418.163.camel@mccallum.corsepiu.local> <1172673890.2871.5.camel@localhost.localdomain> <873b4q2h0d.fsf@kosh.bigo.ensc.de> <20070228212537.d2ada58f.bugs.michael@gmx.net> <87tzx60xz4.fsf@kosh.bigo.ensc.de> Message-ID: <20070228234727.7d3893e2.bugs.michael@gmx.net> On Wed, 28 Feb 2007 22:32:47 +0100, Enrico Scholz wrote: > >> /etc is the classical location for configuration files and I > >> *expect* that I can edit things there resp. that my changes are > >> not lost silently. > > > > /etc contains things, such as GConf2 schema files, which you are not > > supposed to edit. > > Then, they do not belong into /etc and should be moved out it. Even if they contain configuration related defaults? They can be used to reinstall the configuration database with package defaults. Think of them like constants. You *could* edit them, but it would not by typical usage in gconftool-2 world, since even site-wide defaults are created in different files and in a different way. There are also normal configuration files in /etc, which are recreated ("overwritten"), if a configuration utility is used instead of editing them manually. With such an operation your changes would be lost silently, too. I can follow the requirement that /etc must not contain binaries, but configuration related static files. I can see the historical importance of keeping service initscripts in the configuration area to allow for configuration changes directly in the shell scripts. But only *if* there is no other place where to customise the service config, e.g. /etc/sysconfig. From bpepple at fedoraproject.org Wed Feb 28 23:22:55 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 28 Feb 2007 18:22:55 -0500 Subject: Plan for tomorrows (20070301) FESCO meeting Message-ID: <1172704975.26805.3.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-meeting on irc.freenode.org: /topic FESCO-Meeting -- Core/Merge Process - Tracker bugs -- warren /topic FESCO-Meeting -- sponsor nominations -- Fernando Nasser /topic FESCO-Meeting -- MISC -- extras repo-creation using new createrepo - skvidal /topic FESCO-Meeting -- MISC -- cvs-import changes /topic FESCO-Meeting -- MISC -- Extras 7 preparation /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCO-Meeting -- EPEL -- dgilmore /topic FESCo meeting -- Free discussion around Fedora Extras 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 sundaram at fedoraproject.org Wed Feb 28 23:29:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 01 Mar 2007 04:59:29 +0530 Subject: Plan for tomorrows (20070301) FESCO meeting In-Reply-To: <1172704975.26805.3.camel@Chuck> References: <1172704975.26805.3.camel@Chuck> Message-ID: <45E61059.2080608@fedoraproject.org> Brian Pepple wrote: > 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-meeting on irc.freenode.org: > > /topic FESCO-Meeting -- Core/Merge Process - Tracker bugs -- warren > > /topic FESCO-Meeting -- sponsor nominations -- Fernando Nasser > > /topic FESCO-Meeting -- MISC -- extras repo-creation using new > createrepo - skvidal > > /topic FESCO-Meeting -- MISC -- cvs-import changes > > /topic FESCO-Meeting -- MISC -- Extras 7 preparation > > /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, > rdieter, tibbs, scop > > /topic FESCO-Meeting -- EPEL -- dgilmore > > /topic FESCo meeting -- Free discussion around Fedora Extras It might be more appropriate now to change this in "Free discussions around Fedora" instead. Rahul From petersen at redhat.com Wed Feb 28 23:29:28 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 01 Mar 2007 09:29:28 +1000 Subject: [Fedora-i18n-list] Re: naming scheme for fonts packages? In-Reply-To: <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> References: <45E54A39.7030104@redhat.com> <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> Message-ID: <45E61058.1020801@redhat.com> Hi, Thanks for the followup. Nicolas Mailhot wrote: > fonts-foo are usually a mashup of fonts for a specific encoding, and > foo-fonts fonts with distinct style that may span several languages areas. Well the prospect of good free fonts with really wide unicode glyph coverage is not something that is going to happen anytime soon I'm afraid. Having lived 12 years in Japan my perspective is probably a bit different from many Fedora developers. We really really need those fonts-* packages for Asian languages and scripts. :) And as a data-point the big desktop OSs also ship lots of separate fonts for them AFAIK. > To be honest I'm not too fond of foo-font packages. Sorry, did you mean "fonts-*"? > They're a necessary 8-bit legacy stopgap, but I'd rather have vibrant font projects competing > on quality and international coverage. You don't get that if you bundle > different upstreams in neutraly named packages. (the fact that FC was more > fonts-foo and FE foo-fonts reflects a rather utilitarian view of fonts > RH-side, and the huge weight of the fossilized fonts sourced from > xfree86/xorg) I agree with you for fonts for Western languages for which it is possible to have reasonable coverage with limited resources. > IMHO (which if worth what it's worth) you're not packaging generic fonts > for tibetan but a specific font project, and it deserves name recognition > just like any other upstream. So upstreamname-fonts seems more respectful > for me. Also have you though of what will happen should someone want to > package another tibetan font in a few months ? Well in the review we are actually now discussing putting two GPL Tibetan fonts in the same package if it is going by the generic language name. Jens From bpepple at fedoraproject.org Wed Feb 28 23:41:06 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 28 Feb 2007 18:41:06 -0500 Subject: Plan for tomorrows (20070301) FESCO meeting In-Reply-To: <45E61059.2080608@fedoraproject.org> References: <1172704975.26805.3.camel@Chuck> <45E61059.2080608@fedoraproject.org> Message-ID: <1172706066.27645.2.camel@Chuck> On Thu, 2007-03-01 at 04:59 +0530, Rahul Sundaram wrote: > Brian Pepple wrote: > > > > /topic FESCo meeting -- Free discussion around Fedora Extras > > It might be more appropriate now to change this in "Free discussions > around Fedora" instead. Yeah, your right. I've been slowly fixing references to Extras, but missed that one. /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: