From fedora at leemhuis.info Fri Jun 1 05:11:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 01 Jun 2007 07:11:46 +0200 Subject: Upcoming FESCo Election In-Reply-To: <1180627394.5867.2.camel@lincoln> References: <1180627394.5867.2.camel@lincoln> Message-ID: <465FAA92.6050708@leemhuis.info> On 31.05.2007 18:03, Brian Pepple wrote: > > It's that time of year again. Everyone that wants to be in the next > FESCo needs to nominate him/herself for it by June 12, 2007 0:00 UTC; > that self-nomination should contain some information's like "Mission > Statement, Past work summary and Future plans". I think it's to early to have that election; the Board (together with FESCo) still didn't clarify what FESCo will be responsible for and where other groups (release engineering for example) are in the hierarchy of the whole game. That should be solved *before* a proper election is held IMHO, as that is highly relevant. To give a short example from a voters point of view: If FESCo is responsible for the distribution itself (features, schedule) and its packages I might vote for foo and bar, but not baz. But if FESCo just handles packaging in practice I might go for bar and baz, but not for foo. What FESCo will do in the future is also highly relevant for those people that might want to consider self-nominating for FESCo. Just my 2 cent. CU thl From j.w.r.degoede at hhs.nl Fri Jun 1 07:07:36 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 09:07:36 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180655288.25009.12.camel@cookie.hadess.net> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> Message-ID: <465FC5B8.7060602@hhs.nl> Bastien Nocera wrote: > On Thu, 2007-05-31 at 11:11 -0400, Jesse Keating wrote: >> On Thursday 31 May 2007 10:58:31 Bastien Nocera wrote: >>> Is it an enhancement, or a bugfix, or neither? >> Enhancement (to the distribution) > > It would be easier if the update was a bit clever about new packages, > and made them bypass updates-testing automatically. > +1 Regards, Hans From denis at poolshark.org Fri Jun 1 09:10:34 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 01 Jun 2007 11:10:34 +0200 Subject: [SECURITY] Fedora 7 Update: firefox-2.0.0.4-1.fc7 In-Reply-To: <465F5821.4060107@redhat.com> References: <200705311808.l4VI8Lpo003174@bastion.fedora.phx.redhat.com> <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> <465F22EC.8060400@redhat.com> <465F5107.4020504@poolshark.org> <20070601010511.d065ebaa.bugs.michael@gmx.net> <465F5821.4060107@redhat.com> Message-ID: <465FE28A.9090608@poolshark.org> Christopher Aillon wrote: > Michael Schwendt wrote: >> Here's one problem! >> Resolver was asked for gecko-devel, returned firefox-devel, but installed >> was firefox-debuginfo instead. > > That should be fixed in the -1 package which just got released, but > broken in the rc3 package. > > Just re-submit, and it'll likely iron itself out. that did it, thanks! From lmacken at redhat.com Fri Jun 1 10:38:45 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 1 Jun 2007 06:38:45 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <465FC5B8.7060602@hhs.nl> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> Message-ID: <20070601103845.GB4751@tomservo.rochester.rr.com> On Fri, Jun 01, 2007 at 09:07:36AM +0200, Hans de Goede wrote: > Bastien Nocera wrote: > > On Thu, 2007-05-31 at 11:11 -0400, Jesse Keating wrote: > >> On Thursday 31 May 2007 10:58:31 Bastien Nocera wrote: > >>> Is it an enhancement, or a bugfix, or neither? > >> Enhancement (to the distribution) > > It would be easier if the update was a bit clever about new packages, > > and made them bypass updates-testing automatically. > > +1 Just because it's a new package means it doesn't need to be tested? :) luke From buildsys at fedoraproject.org Fri Jun 1 11:16:32 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 1 Jun 2007 07:16:32 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-06-01 Message-ID: <20070601111632.3242E152131@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: nx FE5 > F7 (0:2.1.0-22.fc5 > 0:2.1.0-1.fc6) FE6 > F7 (0:2.1.0-22.fc6 > 0:2.1.0-1.fc6) allisson AT gmail.com: ruby-gnome2 FE6 > F7 (0:0.16.0-6.fc6 > 0:0.16.0-5.fc7) cgoorah AT yahoo.com.au: kmenu-gnome FE5 > FE6 (0:0.6.4-1 > 0:0.6.3-1.fc6) FE5 > F7 (0:0.6.4-1 > 0:0.6.3-1.fc7) cweyl AT alumni.drew.edu: perl-Algorithm-C3 FE5 > F7 (0:0.07-1.fc5 > 0:0.06-1.fc7) FE6 > F7 (0:0.07-1.fc6 > 0:0.06-1.fc7) perl-CGI-Ex FE5 > F7 (0:2.13-1.fc5 > 0:2.12-1.fc7) FE6 > F7 (0:2.13-1.fc6 > 0:2.12-1.fc7) perl-Class-C3-XS FE5 > F7 (0:0.06-1.fc5 > 0:0.04-1.fc7) FE6 > F7 (0:0.06-1.fc6 > 0:0.04-1.fc7) perl-Class-Data-Accessor FE5 > F7 (0:0.04001-1.fc5 > 0:0.04000-3.fc7) FE6 > F7 (0:0.04001-1.fc6 > 0:0.04000-3.fc7) perl-Class-MOP FE5 > F7 (0:0.38-1.fc5 > 0:0.37-1.fc7) FE6 > F7 (0:0.38-1.fc6 > 0:0.37-1.fc7) perl-Gtk2-Notify FE6 > F7 (0:0.03-1.fc6 > 0:0.02-4.fc7) perl-Moose FE5 > F7 (0:0.22-1.fc5 > 0:0.21-1.fc7) FE6 > F7 (0:0.22-1.fc6 > 0:0.21-1.fc7) dm AT mensa.se: initng FE6 > F7 (0:0.6.10.1-1.fc6 > 0:0.6.10-2.fc7) initng-ifiles FE6 > F7 (0:0.1.3-1.fc6 > 0:0.1.2-1.fc7) dmaley AT redhat.com: wavbreaker FE5 > F7 (0:0.8-1.fc5 > 0:0.7-6.fc6) FE6 > F7 (0:0.8-1.fc6 > 0:0.7-6.fc6) drzeus-bugzilla AT drzeus.cx: libatomic_ops FE5 > F7 (0:1.2-2.fc5 > 0:1.2-1.fc7) FE6 > F7 (0:1.2-2.fc6 > 0:1.2-1.fc7) pulseaudio FE5 > F7 (0:0.9.6-2.fc5 > 0:0.9.5-5.fc7) FE6 > F7 (0:0.9.6-2.fc6 > 0:0.9.5-5.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE6 > F7 (0:0.30.213-1.fc6 > 0:0.30.212-3.fc7) fedora AT leemhuis.info: enigma FE6 > F7 (0:1.01-1.fc6 > 0:1.0-1.fc7) foolish AT guezz.net: DMitry FE6 > F7 (0:1.3a-2.fc6 > 0:1.3a-1.fc7) perl-libwhisker2 FE5 > F7 (0:2.4-3.fc5 > 0:2.4-2.fc7) FE6 > F7 (0:2.4-3.fc6 > 0:2.4-2.fc7) gemi AT bluewin.ch: ocaml FE6 > F7 (0:3.09.3-2.fc6 > 0:3.09.3-1.fc7) hellwolf.misty AT gmail.com: fuse-convmvfs FE6 > F7 (0:0.2.4-2.fc6 > 0:0.2.3-2.fc7) ianburrell AT gmail.com: perl-Module-Depends FE5 > F7 (0:0.12-1.fc5 > 0:0.10-2.fc7) FE6 > F7 (0:0.12-1.fc6 > 0:0.10-2.fc7) jeff AT ocjtech.us: radiusclient-ng FE5 > F7 (0:0.5.5.1-1.fc5 > 0:0.5.2-4.fc6) FE6 > F7 (0:0.5.5.1-1.fc6 > 0:0.5.2-4.fc6) jpo AT di.uminho.pt: perl-Image-Info FE5 > F7 (0:1.25-1.fc5 > 0:1.24-1.fc7) FE6 > F7 (0:1.25-1.fc6 > 0:1.24-1.fc7) perl-Module-CoreList FE5 > F7 (0:2.11-1.fc5 > 0:2.09-1.fc6) FE6 > F7 (0:2.11-1.fc6 > 0:2.09-1.fc6) lists AT forevermore.net: dar FE6 > F7 (0:2.3.3-1.fc6 > 0:2.3.1-4.fc7) rsnapshot FE6 > F7 (0:1.3.0-1.fc6 > 0:1.2.9-5.fc6) sec FE6 > F7 (0:2.4.1-1.fc6 > 0:2.4.0-1.fc7) mbacovsk AT redhat.com: squid FC6-updates > F7 (7:2.6.STABLE13-1.fc6 > 7:2.6.STABLE12-1.fc7) meme AT daughtersoftiresias.org: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-2.fc6 > 0:2.1.1-2.fc6) mtasaka AT ioa.s.u-tokyo.ac.jp: jd FE5 > F7 (0:1.9.5-0.3.beta070528.fc5 > 0:1.9.5-0.1.beta070516.fc7) FE6 > F7 (0:1.9.5-0.3.beta070528.fc6 > 0:1.9.5-0.1.beta070516.fc7) nhorman AT redhat.com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) nphilipp AT redhat.com: ufraw FE6 > F7 (0:0.11-8.fc6 > 0:0.11-6.fc7) packages AT amiga-hardware.com: zvbi FE5 > F7 (0:0.2.25-1.fc5 > 0:0.2.24-1.fc7) FE6 > F7 (0:0.2.25-1.fc6 > 0:0.2.24-1.fc7) rc040203 AT freenet.de: perl-Params-Util FE5 > F7 (0:0.25-1.fc5 > 0:0.24-1.fc7) FE6 > F7 (0:0.25-1.fc6 > 0:0.24-1.fc7) redhat-bugzilla AT camperquake.de: audacious-plugins FE6 > F7 (0:1.3.4-2.fc6 > 0:1.3.3-1.fc7) s.adam AT diffingo.com: fwbackups FE5 > F7 (0:1.43.0-0.1.rc2.fc5 > 0:1.43.0-0.1.beta3.fc7) FE6 > F7 (0:1.43.0-0.1.rc2.fc6 > 0:1.43.0-0.1.beta3.fc7) seg AT haxxed.com: rosegarden4 FE5 > F7 (0:1.5.1-1.fc5 > 0:1.4.0-1.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.4.0-1.fc7) spr AT astrax.fis.ucm.es: funtools FE5 > FE6 (0:1.3.0-0.5.b33.fc5 > 0:1.3.0-0.4.b29.fc6) FE5 > F7 (0:1.3.0-0.5.b33.fc5 > 0:1.3.0-0.4.b29.fc7) ssorce AT redhat.com: samba FC5-updates > FC6-updates (0:3.0.24-6.fc5 > 0:3.0.24-5.fc6) ---------------------------------------------------------------------- audacious-plugins: redhat-bugzilla AT camperquake.de FE6 > F7 (0:1.3.4-2.fc6 > 0:1.3.3-1.fc7) dar: lists AT forevermore.net FE6 > F7 (0:2.3.3-1.fc6 > 0:2.3.1-4.fc7) DMitry: foolish AT guezz.net FE6 > F7 (0:1.3a-2.fc6 > 0:1.3a-1.fc7) enigma: fedora AT leemhuis.info FE6 > F7 (0:1.01-1.fc6 > 0:1.0-1.fc7) fortune-firefly: meme AT daughtersoftiresias.org FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-2.fc6 > 0:2.1.1-2.fc6) funtools: spr AT astrax.fis.ucm.es FE5 > FE6 (0:1.3.0-0.5.b33.fc5 > 0:1.3.0-0.4.b29.fc6) FE5 > F7 (0:1.3.0-0.5.b33.fc5 > 0:1.3.0-0.4.b29.fc7) fuse-convmvfs: hellwolf.misty AT gmail.com FE6 > F7 (0:0.2.4-2.fc6 > 0:0.2.3-2.fc7) fwbackups: s.adam AT diffingo.com FE5 > F7 (0:1.43.0-0.1.rc2.fc5 > 0:1.43.0-0.1.beta3.fc7) FE6 > F7 (0:1.43.0-0.1.rc2.fc6 > 0:1.43.0-0.1.beta3.fc7) initng: dm AT mensa.se FE6 > F7 (0:0.6.10.1-1.fc6 > 0:0.6.10-2.fc7) initng-ifiles: dm AT mensa.se FE6 > F7 (0:0.1.3-1.fc6 > 0:0.1.2-1.fc7) irqbalance: nhorman AT redhat.com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) jd: mtasaka AT ioa.s.u-tokyo.ac.jp FE5 > F7 (0:1.9.5-0.3.beta070528.fc5 > 0:1.9.5-0.1.beta070516.fc7) FE6 > F7 (0:1.9.5-0.3.beta070528.fc6 > 0:1.9.5-0.1.beta070516.fc7) kmenu-gnome: cgoorah AT yahoo.com.au FE5 > FE6 (0:0.6.4-1 > 0:0.6.3-1.fc6) FE5 > F7 (0:0.6.4-1 > 0:0.6.3-1.fc7) libatomic_ops: drzeus-bugzilla AT drzeus.cx FE5 > F7 (0:1.2-2.fc5 > 0:1.2-1.fc7) FE6 > F7 (0:1.2-2.fc6 > 0:1.2-1.fc7) nx: Axel.Thimm AT ATrpms.net FE5 > F7 (0:2.1.0-22.fc5 > 0:2.1.0-1.fc6) FE6 > F7 (0:2.1.0-22.fc6 > 0:2.1.0-1.fc6) ocaml: gemi AT bluewin.ch FE6 > F7 (0:3.09.3-2.fc6 > 0:3.09.3-1.fc7) perl-Algorithm-C3: cweyl AT alumni.drew.edu FE5 > F7 (0:0.07-1.fc5 > 0:0.06-1.fc7) FE6 > F7 (0:0.07-1.fc6 > 0:0.06-1.fc7) perl-CGI-Ex: cweyl AT alumni.drew.edu FE5 > F7 (0:2.13-1.fc5 > 0:2.12-1.fc7) FE6 > F7 (0:2.13-1.fc6 > 0:2.12-1.fc7) perl-Class-C3-XS: cweyl AT alumni.drew.edu FE5 > F7 (0:0.06-1.fc5 > 0:0.04-1.fc7) FE6 > F7 (0:0.06-1.fc6 > 0:0.04-1.fc7) perl-Class-Data-Accessor: cweyl AT alumni.drew.edu FE5 > F7 (0:0.04001-1.fc5 > 0:0.04000-3.fc7) FE6 > F7 (0:0.04001-1.fc6 > 0:0.04000-3.fc7) perl-Class-MOP: cweyl AT alumni.drew.edu FE5 > F7 (0:0.38-1.fc5 > 0:0.37-1.fc7) FE6 > F7 (0:0.38-1.fc6 > 0:0.37-1.fc7) perl-Gtk2-Notify: cweyl AT alumni.drew.edu FE6 > F7 (0:0.03-1.fc6 > 0:0.02-4.fc7) perl-Image-Info: jpo AT di.uminho.pt FE5 > F7 (0:1.25-1.fc5 > 0:1.24-1.fc7) FE6 > F7 (0:1.25-1.fc6 > 0:1.24-1.fc7) perl-libwhisker2: foolish AT guezz.net FE5 > F7 (0:2.4-3.fc5 > 0:2.4-2.fc7) FE6 > F7 (0:2.4-3.fc6 > 0:2.4-2.fc7) perl-Module-CoreList: jpo AT di.uminho.pt FE5 > F7 (0:2.11-1.fc5 > 0:2.09-1.fc6) FE6 > F7 (0:2.11-1.fc6 > 0:2.09-1.fc6) perl-Module-Depends: ianburrell AT gmail.com FE5 > F7 (0:0.12-1.fc5 > 0:0.10-2.fc7) FE6 > F7 (0:0.12-1.fc6 > 0:0.10-2.fc7) perl-Moose: cweyl AT alumni.drew.edu FE5 > F7 (0:0.22-1.fc5 > 0:0.21-1.fc7) FE6 > F7 (0:0.22-1.fc6 > 0:0.21-1.fc7) perl-Params-Util: rc040203 AT freenet.de FE5 > F7 (0:0.25-1.fc5 > 0:0.24-1.fc7) FE6 > F7 (0:0.25-1.fc6 > 0:0.24-1.fc7) pulseaudio: drzeus-bugzilla AT drzeus.cx FE5 > F7 (0:0.9.6-2.fc5 > 0:0.9.5-5.fc7) FE6 > F7 (0:0.9.6-2.fc6 > 0:0.9.5-5.fc7) radiusclient-ng: jeff AT ocjtech.us FE5 > F7 (0:0.5.5.1-1.fc5 > 0:0.5.2-4.fc6) FE6 > F7 (0:0.5.5.1-1.fc6 > 0:0.5.2-4.fc6) rosegarden4: seg AT haxxed.com FE5 > F7 (0:1.5.1-1.fc5 > 0:1.4.0-1.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.4.0-1.fc7) rsnapshot: lists AT forevermore.net FE6 > F7 (0:1.3.0-1.fc6 > 0:1.2.9-5.fc6) ruby-gnome2: allisson AT gmail.com FE6 > F7 (0:0.16.0-6.fc6 > 0:0.16.0-5.fc7) samba: ssorce AT redhat.com FC5-updates > FC6-updates (0:3.0.24-6.fc5 > 0:3.0.24-5.fc6) sec: lists AT forevermore.net FE6 > F7 (0:2.4.1-1.fc6 > 0:2.4.0-1.fc7) squid: mbacovsk AT redhat.com FC6-updates > F7 (7:2.6.STABLE13-1.fc6 > 7:2.6.STABLE12-1.fc7) ufraw: nphilipp AT redhat.com FE6 > F7 (0:0.11-8.fc6 > 0:0.11-6.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE6 > F7 (0:0.30.213-1.fc6 > 0:0.30.212-3.fc7) wavbreaker: dmaley AT redhat.com FE5 > F7 (0:0.8-1.fc5 > 0:0.7-6.fc6) FE6 > F7 (0:0.8-1.fc6 > 0:0.7-6.fc6) zvbi: packages AT amiga-hardware.com FE5 > F7 (0:0.2.25-1.fc5 > 0:0.2.24-1.fc7) FE6 > F7 (0:0.2.25-1.fc6 > 0:0.2.24-1.fc7) From rc040203 at freenet.de Fri Jun 1 11:20:30 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jun 2007 13:20:30 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070601103845.GB4751@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> Message-ID: <1180696831.12595.192.camel@mccallum.corsepiu.local> On Fri, 2007-06-01 at 06:38 -0400, Luke Macken wrote: > On Fri, Jun 01, 2007 at 09:07:36AM +0200, Hans de Goede wrote: > > Bastien Nocera wrote: > > > On Thu, 2007-05-31 at 11:11 -0400, Jesse Keating wrote: > > >> On Thursday 31 May 2007 10:58:31 Bastien Nocera wrote: > > >>> Is it an enhancement, or a bugfix, or neither? > > >> Enhancement (to the distribution) > > > It would be easier if the update was a bit clever about new packages, > > > and made them bypass updates-testing automatically. > > > > +1 > > Just because it's a new package means it doesn't need to be tested? :) No, because pushing packages into "testing" makes sense when chasing specific bugs ("does this version fix kernel bug XYZ") or in case of very complex packages (such as the kernel). In most other cases, "testing" just means delaying packages and pushing additional bureaucratic hurdles onto maintainers (yet more forms to fill out). Cases like SONAME changes or packages breaking deps such as the firefox package did yesterday, should be caught automatically and would not require "testing". Ralf From j.w.r.degoede at hhs.nl Fri Jun 1 11:23:53 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 13:23:53 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070601103845.GB4751@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> Message-ID: <466001C9.1080704@hhs.nl> Luke Macken wrote: > On Fri, Jun 01, 2007 at 09:07:36AM +0200, Hans de Goede wrote: >> Bastien Nocera wrote: >>> On Thu, 2007-05-31 at 11:11 -0400, Jesse Keating wrote: >>>> On Thursday 31 May 2007 10:58:31 Bastien Nocera wrote: >>>>> Is it an enhancement, or a bugfix, or neither? >>>> Enhancement (to the distribution) >>> It would be easier if the update was a bit clever about new packages, >>> and made them bypass updates-testing automatically. >> +1 > > Just because it's a new package means it doesn't need to be tested? :) > Can it cause regressions for existing users? -> No Will it get installed automatically by the relative few people who have updates -testing enabled, and thus see any kind of testing (atleast if its installable)? -> No Is there any added value in a new package first sitting for a few days in testing -> No Is it rewarding to packagers if there packages become available to all immediately -> Yes Are the chances of end-users seeing the package and thus installing it, leading to it actually getting tested better in updates-testing, or in updates? -> Beter in updates, so if you want testing the package should go to updates, let me reiterate that this package cannot cause any regressions as if people don't install it explicitly, it will be as if it isn't there. Remember release early, release often Regards, Hans From sundaram at fedoraproject.org Fri Jun 1 11:31:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 17:01:07 +0530 Subject: Pushing updates for Fedora 7 In-Reply-To: <466001C9.1080704@hhs.nl> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> Message-ID: <4660037B.9090009@fedoraproject.org> Hans de Goede wrote: > Is there any added value in a new package first sitting for a few days > in testing -> No It gives a chance for people to test and provide feedback. > Remember release early, release often With the number of regressions have, it's more like break early, break often. Rahul From j.w.r.degoede at hhs.nl Fri Jun 1 11:31:41 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 13:31:41 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <4660037B.9090009@fedoraproject.org> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> Message-ID: <4660039D.1070500@hhs.nl> Rahul Sundaram wrote: > Hans de Goede wrote: > >> Is there any added value in a new package first sitting for a few days >> in testing -> No > > It gives a chance for people to test and provide feedback. > >> Remember release early, release often > > With the number of regressions have, it's more like break early, break > often. > As I already said, new packages don't cause regressions, unless the new package does something really stupid like: Provides: /bin/bash or: Obsoletes: glibc < 5 But if that happens then we have a much bigger problem (review process failing, sponsering failing, etc). Regards. Hans From fedora at leemhuis.info Fri Jun 1 11:42:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 01 Jun 2007 13:42:15 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180696831.12595.192.camel@mccallum.corsepiu.local> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <1180696831.12595.192.camel@mccallum.corsepiu.local> Message-ID: <46600617.5000204@leemhuis.info> On 01.06.2007 13:20, Ralf Corsepius wrote: > On Fri, 2007-06-01 at 06:38 -0400, Luke Macken wrote: >> On Fri, Jun 01, 2007 at 09:07:36AM +0200, Hans de Goede wrote: >>> Bastien Nocera wrote: >>>> On Thu, 2007-05-31 at 11:11 -0400, Jesse Keating wrote: >>>>> On Thursday 31 May 2007 10:58:31 Bastien Nocera wrote: >>>>>> Is it an enhancement, or a bugfix, or neither? >>>>> Enhancement (to the distribution) >>>> It would be easier if the update was a bit clever about new packages, >>>> and made them bypass updates-testing automatically. >>> +1 >> Just because it's a new package means it doesn't need to be tested? :) > No, because pushing packages into "testing" makes sense when chasing > specific bugs ("does this version fix kernel bug XYZ") or in case of > very complex packages (such as the kernel). I'd say even in easy package there is always a chance something goes wrong, so in my opinion it IMHO would be best if all packages hit testing at least for a short timeframe. > In most other cases, "testing" just means delaying packages and pushing > additional bureaucratic hurdles onto maintainers (yet more forms to fill > out). Then let's try to get the hurdles down again that currently come each and everywhere . E.g. the workflow IMHO should be something like this: - $ cvs commit -m "foo" - $ make tag - $ make build -- bodhi here afaics somehow needs to get some informations; e.g. --- from a file --- from the changelog --- via a parameter to make build --- simply by asking (similar how cvs will ask when you don't use "-m" - package goes to testing automatically - if nobody pushes a stop button in the next 4 (?) days something automatically should move the package to updates-proper > [...] CU thl From sundaram at fedoraproject.org Fri Jun 1 11:51:05 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 17:21:05 +0530 Subject: Pushing updates for Fedora 7 In-Reply-To: <4660039D.1070500@hhs.nl> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> Message-ID: <46600829.1080301@fedoraproject.org> Hans de Goede wrote: > Rahul Sundaram wrote: >> Hans de Goede wrote: >> >>> Is there any added value in a new package first sitting for a few >>> days in testing -> No >> >> It gives a chance for people to test and provide feedback. >> >>> Remember release early, release often >> >> With the number of regressions have, it's more like break early, break >> often. >> > > As I already said, new packages don't cause regressions, unless the new > package does something really stupid Ok. Not regressions. New problems. When we push out packages we need room to allow some amount of testing. If you are a pushing out a new package the update system can push it out to updates-testing and automatically move it to updates a week or so later if no bugs are reported. No additional burden for you. Rahul From j.w.r.degoede at hhs.nl Fri Jun 1 12:24:33 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 14:24:33 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <46600829.1080301@fedoraproject.org> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> Message-ID: <46601001.1000201@hhs.nl> Rahul Sundaram wrote: > Hans de Goede wrote: >> Rahul Sundaram wrote: >>> Hans de Goede wrote: >>> >>>> Is there any added value in a new package first sitting for a few >>>> days in testing -> No >>> >>> It gives a chance for people to test and provide feedback. >>> >>>> Remember release early, release often >>> >>> With the number of regressions have, it's more like break early, >>> break often. >>> >> >> As I already said, new packages don't cause regressions, unless the >> new package does something really stupid > > Ok. Not regressions. New problems. When we push out packages we need > room to allow some amount of testing. If you are a pushing out a new > package the update system can push it out to updates-testing and > automatically move it to updates a week or so later if no bugs are > reported. > > No additional burden for you. > You are currently debating things one argument at a time, please reply to my original mail as a whole, I've numbered the arguments this case, you're above reasoning is flawed because of arguments 2,3,4 and 5. With esp arguments 2, 4 and 5 being important. Also in order for "normal" users to be able to see the new package it must be added to comps, does updates-testing have a comps, if it does -> more manual work, if it doesn't no-one will install it while its in updates-testing, so we might as well skip updates testing. 1) Can it cause regressions for existing users? -> No 2) Will it get installed automatically by the relative few people who have updates -testing enabled, and thus see any kind of testing (atleast if its installable)? -> No 3) Is there any added value in a new package first sitting for a few days in testing -> No (because of 2) 4) Is it rewarding to packagers if there packages become available to all immediately -> Yes 5) Are the chances of end-users seeing the package and thus installing it, leading to it actually getting tested better in updates-testing, or in updates? -> Beter in updates, so if you want testing the package should go to updates, let me reiterate that this package cannot cause any regressions as if people don't install it explicitly, it will be as if it isn't there. Remember release early, release often Regards, Hans p.s. Wasn't this all already discussed and decided that new packages could short circuit updates-testing???? From sundaram at fedoraproject.org Fri Jun 1 12:40:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 18:10:39 +0530 Subject: Pushing updates for Fedora 7 In-Reply-To: <46601001.1000201@hhs.nl> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> Message-ID: <466013C7.7030700@fedoraproject.org> Hans de Goede wrote: > 1) Can it cause regressions for existing users? -> No It wouldn't be classified as a regression but new packages can definitely cause issues when user's see the announcement and install it if they are not tested appropriately. > 2) Will it get installed automatically by the relative few people who > have updates -testing enabled, and thus see any kind of testing (atleast > if its installable)? -> No It won't get automatically installed but we can solve that by having a QA group that gets all the packages pushed into updates-testing or finding other good solutions to solve this. > 3) Is there any added value in a new package first sitting for a few > days in testing -> No (because of 2) 2 is a justification for better QA solutions to the problem and not for ignoring any chances to test new packages. > 4) Is it rewarding to packagers if there packages become available to > all immediately -> Yes We need to care about end users not getting affected more compared to packagers gratification of getting a new package a week earlier. > 5) Are the chances of end-users seeing the package and thus installing > it, leading to it actually getting tested better in updates-testing, or > in updates? -> If every package that is pushed to the development tree gets pushed into the updates tree for existing releases they would get more testing too. I don't think you would argue for that. Rahul From jwboyer at jdub.homelinux.org Fri Jun 1 12:43:44 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 01 Jun 2007 07:43:44 -0500 Subject: Pushing updates for Fedora 7 In-Reply-To: <46601001.1000201@hhs.nl> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> Message-ID: <1180701824.5761.70.camel@vader.jdub.homelinux.org> On Fri, 2007-06-01 at 14:24 +0200, Hans de Goede wrote: > 1) Can it cause regressions for existing users? -> No It can cause new problems. > 2) Will it get installed automatically by the relative few people who have > updates -testing enabled, and thus see any kind of testing (atleast if its > installable)? -> No You're making an assumption that there are few people that enable updates-testing. > > 3) Is there any added value in a new package first sitting for a few days in > testing -> No (because of 2) Yes. The QA team can at least install from there and see if it starts. > 4) Is it rewarding to packagers if there packages become available to all > immediately -> Yes Instant gratification of packagers, while a good thing, is trumped by testing and verification of packages. > > 5) Are the chances of end-users seeing the package and thus installing it, > leading to it actually getting tested better in updates-testing, or in updates? -> > Beter in updates, so if you want testing the package should go to updates, let > me reiterate that this package cannot cause any regressions as if people don't > install it explicitly, it will be as if it isn't there. Yes, there are greater chances for it being installed from updates. Which is why it gets pushed there after a small amount of time. This time delay can be mitigated even further by providing comments to the update saying you've tested it and it work on multiple machines, etc. At the least, the QA team (SIG if you will) can grab it and one of them can comment on it. And the fact that you flat out said "if you want testing the package should go to updates" really concerns me. End users are NOT for testing. The package should be tested as much as possible before it even gets into their hands. josh From rc040203 at freenet.de Fri Jun 1 12:59:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jun 2007 14:59:15 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <46600617.5000204@leemhuis.info> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <1180696831.12595.192.camel@mccallum.corsepiu.local> <46600617.5000204@leemhuis.info> Message-ID: <1180702755.12595.225.camel@mccallum.corsepiu.local> On Fri, 2007-06-01 at 13:42 +0200, Thorsten Leemhuis wrote: > On 01.06.2007 13:20, Ralf Corsepius wrote: > > On Fri, 2007-06-01 at 06:38 -0400, Luke Macken wrote: > >> On Fri, Jun 01, 2007 at 09:07:36AM +0200, Hans de Goede wrote: > >>> Bastien Nocera wrote: > >>>> On Thu, 2007-05-31 at 11:11 -0400, Jesse Keating wrote: > >>>>> On Thursday 31 May 2007 10:58:31 Bastien Nocera wrote: > >>>>>> Is it an enhancement, or a bugfix, or neither? > >>>>> Enhancement (to the distribution) > >>>> It would be easier if the update was a bit clever about new packages, > >>>> and made them bypass updates-testing automatically. > >>> +1 > >> Just because it's a new package means it doesn't need to be tested? :) > > No, because pushing packages into "testing" makes sense when chasing > > specific bugs ("does this version fix kernel bug XYZ") or in case of > > very complex packages (such as the kernel). > > I'd say even in easy package there is always a chance something goes > wrong, so in my opinion it IMHO would be best if all packages hit > testing at least for a short timeframe. This only makes sense if * there is somebody to test it * there is something to test for In many cases, their is neither. All "anonymous testers" without direct relation to a particular package can test for "packaging" and "obvious" bugs (doesn't immediate seg-fault). Taking care about individual bugs, should be the job of the maintainer, and be taken care during "hunting down a bug" (The bugzilla process). Things get even more interesting if the Fedora maintainer is the upstream. In such cases he is shipping the best available package, no matter how broken and defective it actually might be. Something like a "delay release" queue until maintainer OK's or withdraws package or (short) timeout occurs make sense. > > In most other cases, "testing" just means delaying packages and pushing > > additional bureaucratic hurdles onto maintainers (yet more forms to fill > > out). > > Then let's try to get the hurdles down again that currently come each > and everywhere . E.g. the workflow IMHO should be something like this: > > - $ cvs commit -m "foo" > - $ make tag > - $ make build > -- bodhi here afaics somehow needs to get some informations; e.g. > --- from a file > --- from the changelog > --- via a parameter to make build > --- simply by asking (similar how cvs will ask when you don't use "-m" > - package goes to testing automatically > - if nobody pushes a stop button in the next 4 (?) days something > automatically should move the package to updates-proper Well, something I've always missed in FE, is a "delay release" queue to delay packages until a maintainer explicitly OK's ("make release") or withdraws package or a (short) timeout occurs ("make withdraw"). Whether 4 days is a reasonable timeout, is arguable. Ralf From j.w.r.degoede at hhs.nl Fri Jun 1 12:58:06 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 14:58:06 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180701824.5761.70.camel@vader.jdub.homelinux.org> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> <1180701824.5761.70.camel@vader.jdub.homelinux.org> Message-ID: <466017DE.5050006@hhs.nl> Josh Boyer wrote: > Instant gratification of packagers, while a good thing, is trumped by > testing and verification of packages. > I would agree if there would be any worthwhile testing, which there simply won't be for may types of more niche packages. >> 5) Are the chances of end-users seeing the package and thus installing it, >> leading to it actually getting tested better in updates-testing, or in updates? -> >> Beter in updates, so if you want testing the package should go to updates, let >> me reiterate that this package cannot cause any regressions as if people don't >> install it explicitly, it will be as if it isn't there. > > Yes, there are greater chances for it being installed from updates. > Which is why it gets pushed there after a small amount of time. This > time delay can be mitigated even further by providing comments to the > update saying you've tested it and it work on multiple machines, etc. > At the least, the QA team (SIG if you will) can grab it and one of them > can comment on it. > > And the fact that you flat out said "if you want testing the package > should go to updates" really concerns me. End users are NOT for > testing. The package should be tested as much as possible before it > even gets into their hands. > It has been tested, since its a new package it has just been completely reviewed, and as part of that hopefully started / tested by the reviewer, add to that that reviews are often done by SIG members, with experience with the type of application, what more could you want? I _really_ see no use for new packages being in updates-testing, this only makes the process to get new packages into Fedora one step longer, which makes it less attractive to add new packages, without giving anything substantial in return. Remember new packages have just been thoroughly vetted during review and are already installed and run by the reviewer. Regards, Hans From fedora at leemhuis.info Fri Jun 1 13:10:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 01 Jun 2007 15:10:14 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180701824.5761.70.camel@vader.jdub.homelinux.org> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> <1180701824.5761.70.camel@vader.jdub.homelinux.org> Message-ID: <46601AB6.10602@leemhuis.info> On 01.06.2007 14:43, Josh Boyer wrote: > On Fri, 2007-06-01 at 14:24 +0200, Hans de Goede wrote: >> 1) Can it cause regressions for existing users? -> No > It can cause new problems. +1 >> 2) Will it get installed automatically by the relative few people who have >> updates -testing enabled, and thus see any kind of testing (atleast if its >> installable)? -> No > You're making an assumption that there are few people that enable > updates-testing. /me has it enabled on nearly all of his machines and that way prevented at least once or twice in the past that bad updates hit updates-proper >> 3) Is there any added value in a new package first sitting for a few days in >> testing -> No (because of 2) > Yes. The QA team can at least install from there and see if it starts. +1 -- and from what I've heard it looks to me that the new QA stuff might make it quite easy to just push some kind of button to say "there is a problem, please don't push" > [...] Cu thl From jkeating at redhat.com Fri Jun 1 13:29:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 09:29:50 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <466017DE.5050006@hhs.nl> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180701824.5761.70.camel@vader.jdub.homelinux.org> <466017DE.5050006@hhs.nl> Message-ID: <200706010929.50800.jkeating@redhat.com> On Friday 01 June 2007 08:58:06 Hans de Goede wrote: > I _really_ see no use for new packages being in updates-testing, this only > makes the process to get new packages into Fedora one step longer, which > makes it less attractive to add new packages, without giving anything > substantial in return. Remember new packages have just been thoroughly > vetted during review and are already installed and run by the reviewer. Look, you're adding a new package to a stable platform. The review most likely focused on devel, where you can get your instant gratification. For a released platform, your new package should hopefully have a level of stability that should be expected of a released platform. Try as we might, we're not perfect, and we can't simulate the wide variety of software/hardware sets that would use our package. Therefor getting a wider audience to try out new things in an updates-testing manner before lobbing it over the wall as a released update to a stable platform is the responsible thing to do. And you know what, adding software to a stable platform _should_ be a bit harder. We don't want to just chuck every new package that tickles our fancy at the released products, especially as many of the maintainers are working on rawhide and not on the past release, or the past release -1. These packages to stable platforms deserve extra scrutiny and extra care as to not destabilize a release and feed to the negative impressions of Fedora as nothing but a perpetual beta. -- 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 Jun 1 14:01:51 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jun 2007 16:01:51 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <46601AB6.10602@leemhuis.info> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> <1180701824.5761.70.camel@vader.jdub.homelinux.org> <46601AB6.10602@leemhuis.info> Message-ID: <1180706511.12595.281.camel@mccallum.corsepiu.local> On Fri, 2007-06-01 at 15:10 +0200, Thorsten Leemhuis wrote: > On 01.06.2007 14:43, Josh Boyer wrote: > > On Fri, 2007-06-01 at 14:24 +0200, Hans de Goede wrote: > >> 3) Is there any added value in a new package first sitting for a few days in > >> testing -> No (because of 2) > > Yes. The QA team can at least install from there and see if it starts. And what gives? Any package above a certain size or certain complexity is filled with known and unknown bugs. It's only a matter of how one defines a testsuite to expose such bugs. > +1 -- and from what I've heard it looks to me that the new QA stuff > might make it quite easy to just push some kind of button to say "there > is a problem, please don't push" That's the negation of testing - As in mathematics, one counter proof suffices to bring a proof down. Anybody being intimate with a SW probably is able to provide a case to expose a bug - So, what kind of additional quality would "testing" provide? I don't see any. Ralf From jdieter at gmail.com Fri Jun 1 14:38:54 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Fri, 01 Jun 2007 17:38:54 +0300 Subject: Yum-presto not "submitted" in Bodhi Message-ID: <1180708734.4058.14.camel@jndwidescreen.lesbg.loc> I'm a bit confused. Yesterday, I built yum-presto-0.3.10 through koji for F-7 and devel, and then asked Bodhi to add yum-presto-0.3.10-1.fc7. It put yum-presto in pending updates, and now there's a big minus sign next to it in the "submitted" column. Is there something I've forgotten to do? Jonathan -------------- 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 Jun 1 14:39:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 10:39:29 -0400 Subject: Yum-presto not "submitted" in Bodhi In-Reply-To: <1180708734.4058.14.camel@jndwidescreen.lesbg.loc> References: <1180708734.4058.14.camel@jndwidescreen.lesbg.loc> Message-ID: <200706011039.29496.jkeating@redhat.com> On Friday 01 June 2007 10:38:54 Jonathan Dieter wrote: > I'm a bit confused. ?Yesterday, I built yum-presto-0.3.10 through koji > for F-7 and devel, and then asked Bodhi to add yum-presto-0.3.10-1.fc7. > It put yum-presto in pending updates, and now there's a big minus sign > next to it in the "submitted" column. ?Is there something I've forgotten > to do? Click the 'push' link in the upper right corner if your update request. -- 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 sheltren at cs.ucsb.edu Fri Jun 1 14:56:38 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 1 Jun 2007 10:56:38 -0400 Subject: Pushing from updates-testing to updates Message-ID: <456D6EFB-85E7-4366-BF8C-48771DE4073F@cs.ucsb.edu> Is there a policy (or guideline) in place for pushing packages from updates-testing to the updates repo? Thanks, Jeff From jdieter at gmail.com Fri Jun 1 15:03:57 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Fri, 01 Jun 2007 18:03:57 +0300 Subject: Yum-presto not "submitted" in Bodhi In-Reply-To: <200706011039.29496.jkeating@redhat.com> References: <1180708734.4058.14.camel@jndwidescreen.lesbg.loc> <200706011039.29496.jkeating@redhat.com> Message-ID: <1180710237.4058.16.camel@jndwidescreen.lesbg.loc> On Fri, 2007-06-01 at 10:39 -0400, Jesse Keating wrote: > Click the 'push' link in the upper right corner if your update request. Thanks. That did it. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Fri Jun 1 15:16:38 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 01 Jun 2007 17:16:38 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180706511.12595.281.camel@mccallum.corsepiu.local> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> <1180701824.5761.70.camel@vader.jdub.homelinux.org> <46601AB6.10602@leemhuis.info> <1180706511.12595.281.camel@mccallum.corsepiu.local> Message-ID: <46603856.8020304@leemhuis.info> On 01.06.2007 16:01, Ralf Corsepius wrote: > [...] > Anybody being intimate with a SW probably is able to provide a case to > expose a bug - So, what kind of additional quality would "testing" > provide? I don't see any. * different users use software differently and thus hit different bugs * some bugs might be arch specific -- I assume only a few of our packagers have access to all the archs we support to test their packages (especially when soon more arch come into the mix, which looks likely) * some (?) packagers test (?) a update only on one distribution and build the software for different distributions -- there is a chance that a bug happens only on one, but not on the others CU knurd (?) -- I know from some, but assume it are more than just a few (?) -- I know of some occurrences where packagers only testbuild a software and just shipped it as a update if the build went fine From mr.ecik at gmail.com Fri Jun 1 15:52:45 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Fri, 1 Jun 2007 17:52:45 +0200 Subject: Fedora Bugzilla Merge Plan In-Reply-To: <4651C88E.5090106@redhat.com> References: <464E0C1C.2030700@redhat.com> <4651C88E.5090106@redhat.com> Message-ID: <668bb39a0706010852l34ebf271o35c6b7524ca35456@mail.gmail.com> 2007/5/21, Warren Togami : > dkl said that he would prefer to do this next week. So this will be > postponed for now. When is it going to happen? I'm interested in it since I need it for my version tracker - Fever. -- Micha? Bentkowski mr.ecik at gmail.com From bnocera at redhat.com Fri Jun 1 16:00:09 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 01 Jun 2007 17:00:09 +0100 Subject: Pushing updates for Fedora 7 In-Reply-To: <46601AB6.10602@leemhuis.info> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> <1180701824.5761.70.camel@vader.jdub.homelinux.org> <46601AB6.10602@leemhuis.info> Message-ID: <1180713609.25009.69.camel@cookie.hadess.net> On Fri, 2007-06-01 at 15:10 +0200, Thorsten Leemhuis wrote: > On 01.06.2007 14:43, Josh Boyer wrote: > > On Fri, 2007-06-01 at 14:24 +0200, Hans de Goede wrote: > >> 1) Can it cause regressions for existing users? -> No > > It can cause new problems. > > +1 > > >> 2) Will it get installed automatically by the relative few people who have > >> updates -testing enabled, and thus see any kind of testing (atleast if its > >> installable)? -> No > > You're making an assumption that there are few people that enable > > updates-testing. > > /me has it enabled on nearly all of his machines and that way prevented > at least once or twice in the past that bad updates hit updates-proper How often do you install new packages from updates-testing? I use updates-testing just like a lot of other people, but I've never installed new packages from it, I don't even know how to see which new packages are available there without listing the directory. If you insist on having it go through updates-testing, then it should be automated, ie. the first build of the new package in a particular distro should get submitted through the errata tool automatically. From dkl at redhat.com Fri Jun 1 16:06:02 2007 From: dkl at redhat.com (Dave Lawrence) Date: Fri, 01 Jun 2007 12:06:02 -0400 Subject: Fedora Bugzilla Merge Plan In-Reply-To: <668bb39a0706010852l34ebf271o35c6b7524ca35456@mail.gmail.com> References: <464E0C1C.2030700@redhat.com> <4651C88E.5090106@redhat.com> <668bb39a0706010852l34ebf271o35c6b7524ca35456@mail.gmail.com> Message-ID: <466043EA.5050105@redhat.com> We are working through some infrastructure issues so that we move everything in Bugzilla properly. This is going to require moving quite a lot of bugs and we would rather not spam everyone in the process :) Hopefully the move will happen next week. Dave Lawrence Micha? Bentkowski ha scritto: > 2007/5/21, Warren Togami : >> dkl said that he would prefer to do this next week. So this will be >> postponed for now. > > When is it going to happen? I'm interested in it since I need it for > my version tracker - Fever. > > -- David Lawrence, RHCE dkl at redhat.com ------------------------------------ Red Hat, Inc. Web: www.redhat.com 1801 Varsity Drive Raleigh, NC 27606 Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 From wwoods at redhat.com Fri Jun 1 16:14:01 2007 From: wwoods at redhat.com (Will Woods) Date: Fri, 01 Jun 2007 12:14:01 -0400 Subject: Pushing from updates-testing to updates In-Reply-To: <456D6EFB-85E7-4366-BF8C-48771DE4073F@cs.ucsb.edu> References: <456D6EFB-85E7-4366-BF8C-48771DE4073F@cs.ucsb.edu> Message-ID: <1180714441.3946.29.camel@zebes.localdomain> On Fri, 2007-06-01 at 10:56 -0400, Jeff Sheltren wrote: > Is there a policy (or guideline) in place for pushing packages from > updates-testing to the updates repo? We talked about this a bit in yesterday's QA meeting. Here's a first draft of our proposal. Pushing from updates-testing to updates currently requires intervention from a rel-eng person (i.e. someone who has the official signing key). But how do they know when a package is ready to go? Each update in Bodhi's Testing Updates list (i.e. the stuff in updates-testing) should have a "QA Verified" flag. If the flag is set, the package should be considered ready to go live. How does the flag get set? One of two ways: 1) The QA team (i.e. pretty much anyone who can use bodhi and knows how to do basic package sanity checking) will go through that list and verify the packages in the updates. 2) After a week in updates-testing, the flag is automatically set - this matches the traditional updates-testing behavior for Core. "Verifying" a package means doing basic sanity testing - install the packages, make sure there's no broken dependencies, make sure binaries run without segfaulting, etc. We'll post package verification guidelines on the wiki for discussion and refinement. Does that sound reasonable? -w -------------- 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 Jun 1 16:28:51 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 01 Jun 2007 18:28:51 +0200 Subject: Pushing from updates-testing to updates In-Reply-To: <1180714441.3946.29.camel@zebes.localdomain> References: <456D6EFB-85E7-4366-BF8C-48771DE4073F@cs.ucsb.edu> <1180714441.3946.29.camel@zebes.localdomain> Message-ID: <1180715331.12595.366.camel@mccallum.corsepiu.local> On Fri, 2007-06-01 at 12:14 -0400, Will Woods wrote: > On Fri, 2007-06-01 at 10:56 -0400, Jeff Sheltren wrote: > > Is there a policy (or guideline) in place for pushing packages from > > updates-testing to the updates repo? > > We talked about this a bit in yesterday's QA meeting. Here's a first > draft of our proposal. > > Pushing from updates-testing to updates currently requires intervention > from a rel-eng person (i.e. someone who has the official signing key). > But how do they know when a package is ready to go? > > Each update in Bodhi's Testing Updates list (i.e. the stuff in > updates-testing) should have a "QA Verified" flag. If the flag is set, > the package should be considered ready to go live. > > How does the flag get set? One of two ways: > > 1) The QA team (i.e. pretty much anyone who can use bodhi and knows how > to do basic package sanity checking) will go through that list and > verify the packages in the updates. > > 2) After a week in updates-testing, the flag is automatically set - this > matches the traditional updates-testing behavior for Core. > > "Verifying" a package means doing basic sanity testing - install the > packages, make sure there's no broken dependencies, make sure binaries > run without segfaulting, etc. We'll post package verification guidelines > on the wiki for discussion and refinement. > > Does that sound reasonable? No ... this sounds like quarantining and caging packages, until some state authority officer puts his stamp onto it ... Definitively a massive workflow regression to community contributors. Ralf From fedora at leemhuis.info Fri Jun 1 16:34:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 01 Jun 2007 18:34:52 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180713609.25009.69.camel@cookie.hadess.net> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> <1180701824.5761.70.camel@vader.jdub.homelinux.org> <46601AB6.10602@leemhuis.info> <1180713609.25009.69.camel@cookie.hadess.net> Message-ID: <46604AAC.30906@leemhuis.info> /me really thinks the subject is bad and confusing; some people seem to talk about "Pushing updates for existing packages through update-testing" (as the subject could indicate) other about "Pushing new packages through updates-testing first"; hopefully most differentiate... On 01.06.2007 18:00, Bastien Nocera wrote: > On Fri, 2007-06-01 at 15:10 +0200, Thorsten Leemhuis wrote: >> On 01.06.2007 14:43, Josh Boyer wrote: >>> On Fri, 2007-06-01 at 14:24 +0200, Hans de Goede wrote: >>>> 1) Can it cause regressions for existing users? -> No >>> It can cause new problems. >> +1 >>>> 2) Will it get installed automatically by the relative few people who have >>>> updates -testing enabled, and thus see any kind of testing (atleast if its >>>> installable)? -> No >>> You're making an assumption that there are few people that enable >>> updates-testing. >> /me has it enabled on nearly all of his machines and that way prevented >> at least once or twice in the past that bad updates hit updates-proper > How often do you install new packages from updates-testing? Until now there were nearly never new packages in update-testing as only Core had updates-testing -- but Core rarely had new packages so the repo was only used for updates normally. So the answer until now is: Never, or only, if the new package was tracked in by a dep. > I use updates-testing just like a lot of other people, but I've never > installed new packages from it, I don't even know how to see which new > packages are available there without listing the directory. See above. But I assume soon you'll see update-testing announcements on fedora-test-list just as we did in the past for update. If it's something I might be interested in I'd in the future say "hey, that apps sounds cool; I give it a quick try just to know if it really is". There are small chances I find a bug while at it. If it's not a bad bug: yeah, push the package over to updates-proper and deal with it later. > [...] Cu thl From Axel.Thimm at ATrpms.net Fri Jun 1 16:37:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 1 Jun 2007 18:37:01 +0200 Subject: HOWTO for bodhi and friends? Message-ID: <20070601163701.GA23557@neu.nirvana> Hi, I'v ebeen trying to follow the threads about how to push updates/updates-testing etc, but they deal with lots of details w/o really showing the main work flow. So for someone who just wants to start processing his built package, either in testing/updates etc. is there a "push your package through F7 for dummies" guide? BTW I tried to seach a bit in the wiki, but these days it's looks quite hopeless to do so ("28 results out of about 7930 pages. (85.80 seconds)") while https://hosted.fedoraproject.org/projects/bodhi/wiki is still trying to load after 30 min. After 15 minutes I found some docu that starts with "Now you can login to the bodhi web interface.", but w/o mentioning the URL to bodhi. So if someone has these steps, please post them here, at least the URL :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Fri Jun 1 16:39:03 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Jun 2007 08:39:03 -0800 Subject: Pushing from updates-testing to updates In-Reply-To: <1180714441.3946.29.camel@zebes.localdomain> References: <456D6EFB-85E7-4366-BF8C-48771DE4073F@cs.ucsb.edu> <1180714441.3946.29.camel@zebes.localdomain> Message-ID: <604aa7910706010939r528dc81dlc70ad7c86ee0632c@mail.gmail.com> On 6/1/07, Will Woods wrote: > 1) The QA team (i.e. pretty much anyone who can use bodhi and knows how > to do basic package sanity checking) will go through that list and > verify the packages in the updates. Sign me up. And you sure as hell better come up with a snarky t-shirt design and send me one or two. I imagine we need coverage of all current releases and primary arches. > "Verifying" a package means doing basic sanity testing - install the > packages, make sure there's no broken dependencies, make sure binaries > run without segfaulting, etc. We'll post package verification guidelines > on the wiki for discussion and refinement. Aren't these basically the "should" items from the submission review list? Can you codify the starting list on a wiki page. And perhaps maybe, some instructions to help people create local emulated test install of multiple releases/arches on their own system. Perhaps even offer up pre-defined qemu images that act as the basis for all the manual QA work. So all the QA community team members can have the same base install image to work from when checking for correct deps and what not. It would be super if I could sit on my x86_64 rawhide box at home and pull an f7 or f6 QA base image under qemu for 32bit or 64bit and test packages in updates-testing for correct behavior. -jef From sundaram at fedoraproject.org Fri Jun 1 16:47:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Jun 2007 22:17:16 +0530 Subject: Pushing from updates-testing to updates In-Reply-To: <1180715331.12595.366.camel@mccallum.corsepiu.local> References: <456D6EFB-85E7-4366-BF8C-48771DE4073F@cs.ucsb.edu> <1180714441.3946.29.camel@zebes.localdomain> <1180715331.12595.366.camel@mccallum.corsepiu.local> Message-ID: <46604D94.5050605@fedoraproject.org> Ralf Corsepius wrote: > No ... this sounds like quarantining and caging packages, until some > state authority officer puts his stamp onto it ... > > Definitively a massive workflow regression to community contributors. How about more specific constructive feedback? Rahul From jkeating at redhat.com Fri Jun 1 17:00:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 13:00:06 -0400 Subject: HOWTO for bodhi and friends? In-Reply-To: <20070601163701.GA23557@neu.nirvana> References: <20070601163701.GA23557@neu.nirvana> Message-ID: <200706011300.09953.jkeating@redhat.com> On Friday 01 June 2007 12:37:01 Axel Thimm wrote: > I'v ebeen trying to follow the threads about how to push > updates/updates-testing etc, but they deal with lots of details w/o > really showing the main work flow. > > So for someone who just wants to start processing his built package, > either in testing/updates etc. is there a "push your package through > F7 for dummies" guide? It was referenced in the first message from Bill Nottingham labeled "Pushing Updates for Fedora 7" http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Fri Jun 1 17:05:46 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 01 Jun 2007 13:05:46 -0400 Subject: HOWTO for bodhi and friends? In-Reply-To: <20070601163701.GA23557@neu.nirvana> References: <20070601163701.GA23557@neu.nirvana> Message-ID: <1180717546.3207.7.camel@kennedy> On Fri, 2007-06-01 at 18:37 +0200, Axel Thimm wrote: > Hi, > > I'v ebeen trying to follow the threads about how to push > updates/updates-testing etc, but they deal with lots of details w/o > really showing the main work flow. > > So for someone who just wants to start processing his built package, > either in testing/updates etc. is there a "push your package through > F7 for dummies" guide? > > BTW I tried to seach a bit in the wiki, but these days it's looks > quite hopeless to do so ("28 results out of about 7930 pages. (85.80 > seconds)") while https://hosted.fedoraproject.org/projects/bodhi/wiki > is still trying to load after 30 min. After 15 minutes I found some > docu that starts with "Now you can login to the bodhi web interface.", > but w/o mentioning the URL to bodhi. So if someone has these steps, > please post them here, at least the URL :) Here's the url: https://admin.fedoraproject.org/updates /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 j.w.r.degoede at hhs.nl Fri Jun 1 17:26:11 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 19:26:11 +0200 Subject: Pushing from updates-testing to updates In-Reply-To: <1180714441.3946.29.camel@zebes.localdomain> References: <456D6EFB-85E7-4366-BF8C-48771DE4073F@cs.ucsb.edu> <1180714441.3946.29.camel@zebes.localdomain> Message-ID: <466056B3.1020008@hhs.nl> Will Woods wrote: > On Fri, 2007-06-01 at 10:56 -0400, Jeff Sheltren wrote: >> Is there a policy (or guideline) in place for pushing packages from >> updates-testing to the updates repo? > > We talked about this a bit in yesterday's QA meeting. Here's a first > draft of our proposal. > > Pushing from updates-testing to updates currently requires intervention > from a rel-eng person (i.e. someone who has the official signing key). > But how do they know when a package is ready to go? > > Each update in Bodhi's Testing Updates list (i.e. the stuff in > updates-testing) should have a "QA Verified" flag. If the flag is set, > the package should be considered ready to go live. > > How does the flag get set? One of two ways: > > 1) The QA team (i.e. pretty much anyone who can use bodhi and knows how > to do basic package sanity checking) will go through that list and > verify the packages in the updates. > > 2) After a week in updates-testing, the flag is automatically set - this > matches the traditional updates-testing behavior for Core. > > "Verifying" a package means doing basic sanity testing - install the > packages, make sure there's no broken dependencies, make sure binaries > run without segfaulting, etc. We'll post package verification guidelines > on the wiki for discussion and refinement. > > Does that sound reasonable? > It does sound reasonable, however I don't see any QA done flag in Bodhi atm, is this on the todo list? Also I would like to see a way to shortcircuit this, for for example trivial fixes fixing serious bugs. Rationale: -Since Fedora X is a stable release, the build environment for packages should not change significantly, and thus a mere rebuild against the normal stable environment should have a very small cance of introducing regressions -If the patch is trivially correct and thus can be verified at the source level, the patch should have a very small chance of introducing regressions too So if an update fixes a serious bug with a trivial patch, then the importance of getting the bugfix to users outways the very small chance for regressions. (much like security fixes) Notice that this was already discussed and agreed upon some weeks ago (I can dig up the thread if want me too), now all we need is a mechanism to make this happen. Regards, Hans From jspaleta at gmail.com Fri Jun 1 17:28:41 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Jun 2007 09:28:41 -0800 Subject: HOWTO for bodhi and friends? In-Reply-To: <1180717546.3207.7.camel@kennedy> References: <20070601163701.GA23557@neu.nirvana> <1180717546.3207.7.camel@kennedy> Message-ID: <604aa7910706011028w174e7c66xa2c4f8abb19b60db@mail.gmail.com> On 6/1/07, Brian Pepple wrote: > Here's the url: > > https://admin.fedoraproject.org/updates I could use some streamlined, normal process guidance to help remind me where the urls are. Has this been added to the package submission process guidance in the wiki yet? I tend to look over that for new information concerning how to interact with the system if I haven't actively been using it in the past couple of weeks. -jef From denis at poolshark.org Fri Jun 1 17:32:08 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 01 Jun 2007 19:32:08 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <46601AB6.10602@leemhuis.info> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> <1180701824.5761.70.camel@vader.jdub.homelinux.org> <46601AB6.10602@leemhuis.info> Message-ID: <46605818.6050809@poolshark.org> Thorsten Leemhuis wrote: > On 01.06.2007 14:43, Josh Boyer wrote: >> On Fri, 2007-06-01 at 14:24 +0200, Hans de Goede wrote: >>> 1) Can it cause regressions for existing users? -> No >> It can cause new problems. > > +1 > >>> 2) Will it get installed automatically by the relative few people who have >>> updates -testing enabled, and thus see any kind of testing (atleast if its >>> installable)? -> No >> You're making an assumption that there are few people that enable >> updates-testing. > > /me has it enabled on nearly all of his machines and that way prevented > at least once or twice in the past that bad updates hit updates-proper I have updates-testing set up too, but remember it won't install new packages, only update existing ones. Is anyone going to install all *new* packages that hit updates-testing automatically ? >>> 3) Is there any added value in a new package first sitting for a few days in >>> testing -> No (because of 2) >> Yes. The QA team can at least install from there and see if it starts. > > +1 -- and from what I've heard it looks to me that the new QA stuff > might make it quite easy to just push some kind of button to say "there > is a problem, please don't push" My biggest question about the whole QA stuff is: while some packages are nice desktop applications with menu entries, many (most?) new packages are going to be somewhat obscure libraries, plugins, perl/py modules, i.e. things that are difficult to test. For example, if i push a new version of libgnomeuimm26 to updates-testing, will the QA folks know that the only way to test that is to actually test gcdmaster, workrave, referencer and wp_tray ? From mclasen at redhat.com Fri Jun 1 17:30:10 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 01 Jun 2007 13:30:10 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <46605818.6050809@poolshark.org> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> <1180701824.5761.70.camel@vader.jdub.homelinux.org> <46601AB6.10602@leemhuis.info> <46605818.6050809@poolshark.org> Message-ID: <1180719010.26073.2.camel@dhcp83-186.boston.redhat.com> On Fri, 2007-06-01 at 19:32 +0200, Denis Leroy wrote: > > My biggest question about the whole QA stuff is: while some packages are > nice desktop applications with menu entries, many (most?) new packages > are going to be somewhat obscure libraries, plugins, perl/py modules, > i.e. things that are difficult to test. For example, if i push a new > version of libgnomeuimm26 to updates-testing, will the QA folks know > that the only way to test that is to actually test gcdmaster, workrave, > referencer and wp_tray ? > Obviously not. Which is why the corresponding internal tools used for RHEL errata have a field where the engineer is supposed to fill in QA test instructions. Bodhi doesn't have that (yet ?) From jwboyer at jdub.homelinux.org Fri Jun 1 17:31:51 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 01 Jun 2007 12:31:51 -0500 Subject: Pushing from updates-testing to updates In-Reply-To: <604aa7910706010939r528dc81dlc70ad7c86ee0632c@mail.gmail.com> References: <456D6EFB-85E7-4366-BF8C-48771DE4073F@cs.ucsb.edu> <1180714441.3946.29.camel@zebes.localdomain> <604aa7910706010939r528dc81dlc70ad7c86ee0632c@mail.gmail.com> Message-ID: <1180719111.5761.76.camel@vader.jdub.homelinux.org> On Fri, 2007-06-01 at 08:39 -0800, Jeff Spaleta wrote: > On 6/1/07, Will Woods wrote: > > 1) The QA team (i.e. pretty much anyone who can use bodhi and knows how > > to do basic package sanity checking) will go through that list and > > verify the packages in the updates. > > Sign me up. And you sure as hell better come up with a snarky t-shirt > design and send me one or two. I imagine we need coverage of all > current releases and primary arches. We have no secondary arches at the moment. Everything that gets built is a primary arch until we do. josh From bpepple at fedoraproject.org Fri Jun 1 17:45:45 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 01 Jun 2007 13:45:45 -0400 Subject: HOWTO for bodhi and friends? In-Reply-To: <604aa7910706011028w174e7c66xa2c4f8abb19b60db@mail.gmail.com> References: <20070601163701.GA23557@neu.nirvana> <1180717546.3207.7.camel@kennedy> <604aa7910706011028w174e7c66xa2c4f8abb19b60db@mail.gmail.com> Message-ID: <1180719945.3207.13.camel@kennedy> On Fri, 2007-06-01 at 09:28 -0800, Jeff Spaleta wrote: > On 6/1/07, Brian Pepple wrote: > > Here's the url: > > > > https://admin.fedoraproject.org/updates > > > I could use some streamlined, normal process guidance to help remind > me where the urls are. Has this been added to the package submission > process guidance in the wiki yet? I tend to look over that for new > information concerning how to interact with the system if I haven't > actively been using it in the past couple of weeks. > As far as I'm aware it's not been added yet to the normal process guide on the wiki. Here's a link to the initial draft on using Bohdi: http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT which would come into play after step 13 of the package process: http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess Later, /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 Fri Jun 1 18:32:06 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 02 Jun 2007 03:32:06 +0900 Subject: Updates notification information on Fedora 7? Message-ID: <46606626.7090200@ioa.s.u-tokyo.ac.jp> Hello. By the way, when will the information for updates notification of packages on Fedora 7 be pushed? Actually, I have 6 updates other than jd-1.9.5-0.3.beta070528.fc7 (of which the notication came as https://www.redhat.com/archives/fedora-package-announce/2007-June/msg00002.html ) FEDORA-2007-0032 alexandria-0.6.1-3.fc7 (new package) FEDORA-2007-0031 kazehakase-0.4.7-1.fc7 FEDORA-2007-0030 xtide-2.9.3-2.fc7 FEDORA-2007-0028 comix-3.6.4-1.fc7 FEDORA-2007-0027 cmigemo-1.3-0.5.c_MIT.fc7 (new package) FEDORA-2007-0026 wallpapoz-0.4-1.fc7 Actually I received the mails about 16 hours ago like: ----------------------------------------------- alexandria-0.6.1-3.fc7 successfully moved from dist-fc7-updates-testing into dist-fc7-updates by lmacken ----------------------------------------------- and actually these packages are already published as formal (not testing) Fedora 7 updates. However, no information of these packages appears on https://www.redhat.com/archives/fedora-package-announce/ Also, updates information for FEDORA-2007-0029 pidgin-2.0.1-1.fc7 FEDORA-2007-0033 freetype-2.3.4-3.fc7 (not my packages) don't appear? Mamoru From jkeating at redhat.com Fri Jun 1 18:37:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Jun 2007 14:37:51 -0400 Subject: Updates notification information on Fedora 7? In-Reply-To: <46606626.7090200@ioa.s.u-tokyo.ac.jp> References: <46606626.7090200@ioa.s.u-tokyo.ac.jp> Message-ID: <200706011437.51444.jkeating@redhat.com> On Friday 01 June 2007 14:32:06 Mamoru Tasaka wrote: > Hello. > > By the way, when will the information for updates > notification of packages on Fedora 7 be pushed? > > Actually, I have 6 updates other than jd-1.9.5-0.3.beta070528.fc7 > (of which the notication came as > https://www.redhat.com/archives/fedora-package-announce/2007-June/msg00002. >html ) > > FEDORA-2007-0032 alexandria-0.6.1-3.fc7 (new package) > FEDORA-2007-0031 kazehakase-0.4.7-1.fc7 > FEDORA-2007-0030 xtide-2.9.3-2.fc7 > FEDORA-2007-0028 comix-3.6.4-1.fc7 > FEDORA-2007-0027 cmigemo-1.3-0.5.c_MIT.fc7 (new package) > FEDORA-2007-0026 wallpapoz-0.4-1.fc7 > > Actually I received the mails about 16 hours ago like: > ----------------------------------------------- > alexandria-0.6.1-3.fc7 successfully moved from dist-fc7-updates-testing > into dist-fc7-updates by lmacken > ----------------------------------------------- > and actually these packages are already published as formal (not testing) > Fedora 7 updates. However, no information of these packages > appears on > https://www.redhat.com/archives/fedora-package-announce/ > > Also, updates information for > FEDORA-2007-0029 ?pidgin-2.0.1-1.fc7 > FEDORA-2007-0033 ?freetype-2.3.4-3.fc7 > (not my packages) don't appear? We're still working out the kinks with Bodhi and notifications (as well as other things). I do believe a full resend of all notifications will be sent. Also the extra updateinfo metdata will be added in soon. -- 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 Fri Jun 1 19:33:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Jun 2007 15:33:46 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <466001C9.1080704@hhs.nl> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> Message-ID: <20070601193346.GG7580@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > Can it cause regressions for existing users? -> No > > Will it get installed automatically by the relative few people who have > updates -testing enabled, and thus see any kind of testing (atleast if its > installable)? -> No Well, if the packager really futzes up the packaging, it *can*. (Conflicts, provides/requires that it shouldn't have, etc.) Ideally, all this stuff is caught in review. That being said, step one is being able to reliably and automatically tell what's a *new* package, versus an update, or even a rename/obsolete (e.g., pidgin). We can't really change the bodhi workflow until that's done. Bill From j.w.r.degoede at hhs.nl Fri Jun 1 20:00:32 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 01 Jun 2007 22:00:32 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070601193346.GG7580@nostromo.devel.redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <20070601193346.GG7580@nostromo.devel.redhat.com> Message-ID: <46607AE0.4070700@hhs.nl> Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: >> Can it cause regressions for existing users? -> No >> >> Will it get installed automatically by the relative few people who have >> updates -testing enabled, and thus see any kind of testing (atleast if its >> installable)? -> No > > Well, if the packager really futzes up the packaging, it *can*. (Conflicts, > provides/requires that it shouldn't have, etc.) Ideally, all this > stuff is caught in review. > > That being said, step one is being able to reliably and automatically tell > what's a *new* package, versus an update, or even a rename/obsolete (e.g., > pidgin). We can't really change the bodhi workflow until that's done. > Erm, we already have a drop down allowing one to choice from: security fix, bug fix, enhancement. Whats wrong with adding "new package" to the list? Regards, Hans From notting at redhat.com Fri Jun 1 19:49:25 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Jun 2007 15:49:25 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <46607AE0.4070700@hhs.nl> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <20070601193346.GG7580@nostromo.devel.redhat.com> <46607AE0.4070700@hhs.nl> Message-ID: <20070601194925.GA8854@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > Erm, we already have a drop down allowing one to choice from: security fix, > bug fix, enhancement. Whats wrong with adding "new package" to the list? It should (and could) be automatically determined, so I don't see any reason why it it needs to be a choice. Bill From jspaleta at gmail.com Fri Jun 1 20:00:57 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Jun 2007 12:00:57 -0800 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070601194925.GA8854@nostromo.devel.redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <20070601193346.GG7580@nostromo.devel.redhat.com> <46607AE0.4070700@hhs.nl> <20070601194925.GA8854@nostromo.devel.redhat.com> Message-ID: <604aa7910706011300v72ac0ce6ha579d27f8b430cf4@mail.gmail.com> On 6/1/07, Bill Nottingham wrote: > It should (and could) be automatically determined, so I don't see any reason why it > it needs to be a choice. I think you really want to be able to know this...however you do it. We very well may want to treat new packages differently later for QA process reasons so we can do things like pile on and write some testing harness scripts for new packages. And I know I'm interested in see new things announcements separated from updated things announcements. -jef"or at least i think i know i'm interested, i could be wrong...more than enough room to be persuaded that i really don't want what I think i know I want"spaleta From caillon at redhat.com Fri Jun 1 21:02:52 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 01 Jun 2007 17:02:52 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <46607AE0.4070700@hhs.nl> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <20070601193346.GG7580@nostromo.devel.redhat.com> <46607AE0.4070700@hhs.nl> Message-ID: <4660897C.9090107@redhat.com> Hans de Goede wrote: > Erm, we already have a drop down allowing one to choice from: security > fix, bug fix, enhancement. Whats wrong with adding "new package" to the > list? New package doesn't tell you what type of problem you're addressing, though. In FC5, we went from mozilla -> seamonkey which was a security fix. In FC6, we went from gaim -> pidgin which while a new package, was more of a bug fix update as it was just a name change. From notting at redhat.com Fri Jun 1 21:07:02 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Jun 2007 17:07:02 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <4660897C.9090107@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <20070601193346.GG7580@nostromo.devel.redhat.com> <46607AE0.4070700@hhs.nl> <4660897C.9090107@redhat.com> Message-ID: <20070601210702.GA9785@nostromo.devel.redhat.com> Christopher Aillon (caillon at redhat.com) said: > Hans de Goede wrote: > >Erm, we already have a drop down allowing one to choice from: security > >fix, bug fix, enhancement. Whats wrong with adding "new package" to the > >list? > > New package doesn't tell you what type of problem you're addressing, though. > > In FC5, we went from mozilla -> seamonkey which was a security fix. > In FC6, we went from gaim -> pidgin which while a new package, was more > of a bug fix update as it was just a name change. And neither of those would truly qualify as 'new' in this case. Bill From alexl at users.sourceforge.net Fri Jun 1 22:41:47 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 01 Jun 2007 15:41:47 -0700 Subject: Yum-presto not "submitted" in Bodhi In-Reply-To: <1180710237.4058.16.camel@jndwidescreen.lesbg.loc> (Jonathan Dieter's message of "Fri\, 01 Jun 2007 18\:03\:57 +0300") References: <1180708734.4058.14.camel@jndwidescreen.lesbg.loc> <200706011039.29496.jkeating@redhat.com> <1180710237.4058.16.camel@jndwidescreen.lesbg.loc> Message-ID: >>>>> "JD" == Jonathan Dieter writes: JD> On Fri, 2007-06-01 at 10:39 -0400, Jesse Keating wrote: >> Click the 'push' link in the upper right corner if your update >> request. JD> Thanks. That did it. Judging from the number of updates in: https://admin.fedoraproject.org/updates/pending that have a "-" next to them (i.e. haven't been pushed), many others are not aware of this extra necessary step. I think that the guidelines at: http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT aren't sufficiently clear and explicit on this point. (I also wondered why the check mark didn't appear and just stumbled upon the "push" button by chance). The instructions "bury the lead" (the fact that clicking the "Push" button is necessary) at the end of the paragraph and I suggest expanding the single bullet-point to something like the following: * From here your update is in a 'Pending' state, which is where we will eventually kick it off to Beaker to perform automated tests. Beaker is still in the works, so if your update passess the preliminary checks and has made it this far, just look over your update to make sure all of the details are correct. * If you satified with the details click 'Push' in the top-right hand corner of each update to submit a push request to the Release Engineering Team. This is necessary for the update to proceed. From orion at cora.nwra.com Fri Jun 1 22:57:40 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 01 Jun 2007 16:57:40 -0600 Subject: Pushing updates for Fedora 7 In-Reply-To: <46600829.1080301@fedoraproject.org> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> Message-ID: <4660A464.4040209@cora.nwra.com> > Hans de Goede wrote: >> Rahul Sundaram wrote: >>> Hans de Goede wrote: >>> >>>> Is there any added value in a new package first sitting for a few >>>> days in testing -> No >>> >>> It gives a chance for people to test and provide feedback. >>> >>>> Remember release early, release often >>> >>> With the number of regressions have, it's more like break early, >>> break often. >>> >> >> As I already said, new packages don't cause regressions, unless the >> new package does something really stupid Like Provides that conflict with other existing packages... It can happen. (Of course, we need buildsystem checks for these...) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From lmacken at redhat.com Fri Jun 1 23:55:27 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 1 Jun 2007 19:55:27 -0400 Subject: Yum-presto not "submitted" in Bodhi In-Reply-To: References: <1180708734.4058.14.camel@jndwidescreen.lesbg.loc> <200706011039.29496.jkeating@redhat.com> <1180710237.4058.16.camel@jndwidescreen.lesbg.loc> Message-ID: <20070601235527.GE4751@tomservo.rochester.rr.com> On Fri, Jun 01, 2007 at 03:41:47PM -0700, Alex Lancaster wrote: > Judging from the number of updates in: > > https://admin.fedoraproject.org/updates/pending > > that have a "-" next to them (i.e. haven't been pushed), many others > are not aware of this extra necessary step. I think that the > guidelines at: > > http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT > > aren't sufficiently clear and explicit on this point. (I also > wondered why the check mark didn't appear and just stumbled upon the > "push" button by chance). I agree, and there are also updates in the pending queue that have obsoleted by another updates. We definitely need a way of handling that as well. I really don't want to resort to nagmail if we don't have to. > The instructions "bury the lead" (the fact that clicking the "Push" > button is necessary) at the end of the paragraph and I suggest > expanding the single bullet-point to something like the following: > > * From here your update is in a 'Pending' state, which is where we > will eventually kick it off to Beaker to perform automated > tests. Beaker is still in the works, so if your update passess the > preliminary checks and has made it this far, just look over your > update to make sure all of the details are correct. > > * If you satified with the details click 'Push' in the top-right hand > corner of each update to submit a push request to the Release > Engineering Team. This is necessary for the update to proceed. Sounds good to me, I updated the wiki. Thanks! luke From lmacken at redhat.com Fri Jun 1 23:59:59 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 1 Jun 2007 19:59:59 -0400 Subject: Updates notification information on Fedora 7? In-Reply-To: <46606626.7090200@ioa.s.u-tokyo.ac.jp> References: <46606626.7090200@ioa.s.u-tokyo.ac.jp> Message-ID: <20070601235959.GF4751@tomservo.rochester.rr.com> On Sat, Jun 02, 2007 at 03:32:06AM +0900, Mamoru Tasaka wrote: > Hello. > > By the way, when will the information for updates > notification of packages on Fedora 7 be pushed? > > Actually, I have 6 updates other than jd-1.9.5-0.3.beta070528.fc7 > (of which the notication came as > https://www.redhat.com/archives/fedora-package-announce/2007-June/msg00002.html ) > > FEDORA-2007-0032 alexandria-0.6.1-3.fc7 (new package) > FEDORA-2007-0031 kazehakase-0.4.7-1.fc7 > FEDORA-2007-0030 xtide-2.9.3-2.fc7 > FEDORA-2007-0028 comix-3.6.4-1.fc7 > FEDORA-2007-0027 cmigemo-1.3-0.5.c_MIT.fc7 (new package) > FEDORA-2007-0026 wallpapoz-0.4-1.fc7 > > Actually I received the mails about 16 hours ago like: > ----------------------------------------------- > alexandria-0.6.1-3.fc7 successfully moved from dist-fc7-updates-testing into dist-fc7-updates by lmacken > ----------------------------------------------- > and actually these packages are already published as formal (not testing) > Fedora 7 updates. However, no information of these packages > appears on > https://www.redhat.com/archives/fedora-package-announce/ > > Also, updates information for > FEDORA-2007-0029 pidgin-2.0.1-1.fc7 > FEDORA-2007-0033 freetype-2.3.4-3.fc7 > (not my packages) don't appear? There was an explosion during our second push during update notice generation, thanks to smiley faces and checkmarks inside of an RPM ChangeLog. I updated bodhi to fix the encoding of all of the details with koji.fixEncoding(), and re-pushed all of those updates. The update mails should have gone out, but I'm not sure if fedora-test-list is whitelisting mails from bodhi yet. luke From lmacken at redhat.com Sat Jun 2 00:07:04 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 1 Jun 2007 20:07:04 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> Message-ID: <20070602000704.GG4751@tomservo.rochester.rr.com> On Thu, May 31, 2007 at 07:40:26AM -0400, Jeff Sheltren wrote: > Luke, thanks for all your work on Bodhi! > > Does anyone have an answer to the question at the bottom of the Bodhi wiki > page: > - Are we going to have any rule for how long things should be in > updates-testing? How much QA? How many good/bad? > > Was this already discussed somewhere? :) Not that I know of. Once we agree on a policy, I can implement it. I've heard some people suggest letting updates sit in testing for 7 days, and if there are no complaints, then they can be pushed to the stable repo. This sounds fine to me, what does everyone else think? We'll have a better feedback interface in place in the near future, where testers can +1/-1 updates. From here, we can say that n positive approvals will mark an update as stable. What should n be? > Also, it looks like I can revoke/edit push requests. Is that intended > behavior? Jesse, I clicked on the revoke link for your pungi package and it > seemed to successfully revoke the push request. I clicked the link to push > it again, so it should be back to normal (awaiting push), but please verify! Bodhi is very trusting at the moment. I hacked in some basic access control last night, and plan on improving it soon. Until we can acquire the maintainers of a package, bodhi will only allow modifications from the initial submitter. luke From lmacken at redhat.com Sat Jun 2 00:10:49 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 1 Jun 2007 20:10:49 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180696831.12595.192.camel@mccallum.corsepiu.local> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <1180696831.12595.192.camel@mccallum.corsepiu.local> Message-ID: <20070602001049.GH4751@tomservo.rochester.rr.com> On Fri, Jun 01, 2007 at 01:20:30PM +0200, Ralf Corsepius wrote: > On Fri, 2007-06-01 at 06:38 -0400, Luke Macken wrote: > > On Fri, Jun 01, 2007 at 09:07:36AM +0200, Hans de Goede wrote: > > > Bastien Nocera wrote: > > > > On Thu, 2007-05-31 at 11:11 -0400, Jesse Keating wrote: > > > >> On Thursday 31 May 2007 10:58:31 Bastien Nocera wrote: > > > >>> Is it an enhancement, or a bugfix, or neither? > > > >> Enhancement (to the distribution) > > > > It would be easier if the update was a bit clever about new packages, > > > > and made them bypass updates-testing automatically. > > > > > > +1 > > > > Just because it's a new package means it doesn't need to be tested? :) > No, because pushing packages into "testing" makes sense when chasing > specific bugs ("does this version fix kernel bug XYZ") or in case of > very complex packages (such as the kernel). It also makes sense in attempting to sustain a stable distribution and cultivate a team of community testers. luke From lmacken at redhat.com Sat Jun 2 00:27:57 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 1 Jun 2007 20:27:57 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180719010.26073.2.camel@dhcp83-186.boston.redhat.com> References: <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> <1180701824.5761.70.camel@vader.jdub.homelinux.org> <46601AB6.10602@leemhuis.info> <46605818.6050809@poolshark.org> <1180719010.26073.2.camel@dhcp83-186.boston.redhat.com> Message-ID: <20070602002757.GI4751@tomservo.rochester.rr.com> On Fri, Jun 01, 2007 at 01:30:10PM -0400, Matthias Clasen wrote: > On Fri, 2007-06-01 at 19:32 +0200, Denis Leroy wrote: > > > > My biggest question about the whole QA stuff is: while some packages are > > nice desktop applications with menu entries, many (most?) new packages > > are going to be somewhat obscure libraries, plugins, perl/py modules, > > i.e. things that are difficult to test. For example, if i push a new > > version of libgnomeuimm26 to updates-testing, will the QA folks know > > that the only way to test that is to actually test gcdmaster, workrave, > > referencer and wp_tray ? > > > Obviously not. Which is why the corresponding internal tools used for > RHEL errata have a field where the engineer is supposed to fill in QA > test instructions. Bodhi doesn't have that (yet ?) That's a good idea, I'll throw a task into bodhi's trac for it. I have zero experience with the RHEL errata tool, so I don't really know what it offers; are there any other features that it has that you'd like to see in bodhi? luke From jspaleta at gmail.com Sat Jun 2 00:29:56 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Jun 2007 16:29:56 -0800 Subject: Yum-presto not "submitted" in Bodhi In-Reply-To: <20070601235527.GE4751@tomservo.rochester.rr.com> References: <1180708734.4058.14.camel@jndwidescreen.lesbg.loc> <200706011039.29496.jkeating@redhat.com> <1180710237.4058.16.camel@jndwidescreen.lesbg.loc> <20070601235527.GE4751@tomservo.rochester.rr.com> Message-ID: <604aa7910706011729q25db19bfpd08d9c906703b775@mail.gmail.com> On 6/1/07, Luke Macken wrote: > Sounds good to me, I updated the wiki. Thanks! the typical bodhi interaction needs to be put into the package submission step-by-step breakdown wikipage as steps to do after you get the package into cvs, and after you build it in koji. -jef"A reference link out of the koji web interface to the bodhi web interface probably wouldn't hurt either."spaleta From rc040203 at freenet.de Sat Jun 2 01:46:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 02 Jun 2007 03:46:38 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <46603856.8020304@leemhuis.info> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> <1180701824.5761.70.camel@vader.jdub.homelinux.org> <46601AB6.10602@leemhuis.info> <1180706511.12595.281.camel@mccallum.corsepiu.local> <46603856.8020304@leemhuis.info> Message-ID: <1180748798.12595.386.camel@mccallum.corsepiu.local> On Fri, 2007-06-01 at 17:16 +0200, Thorsten Leemhuis wrote: > On 01.06.2007 16:01, Ralf Corsepius wrote: > > [...] > > Anybody being intimate with a SW probably is able to provide a case to > > expose a bug - So, what kind of additional quality would "testing" > > provide? I don't see any. > > * different users use software differently and thus hit different bugs users != testers > * some bugs might be arch specific -- I assume only a few of our > packagers have access to all the archs we support to test their packages > (especially when soon more arch come into the mix, which looks likely) Exactly. But a handful (or fewer) testers never reach the amount of testing mass exposure does. It the reason why so many kernel bugs exists: Neither upstream maintainers or @RH maintainers nor testers can test their setup. A handful of testers more doesn't help. > * some (?) packagers test (?) a update only on one distribution and > build the software for different distributions -- there is a chance that > a bug happens only on one, but not on the others Yes, such situations are exist (I presume them to be the standard), but does a handful/few "testers", who have no clue about a package nor use for a package change anything about this? They might be able to find a very obvious bug 2 days earlier than mass exposure would, but they never will be able to find the bug which kills a system in specific setups. I've tripped such "testers scenarios" too often to find it useful. Ralf From rc040203 at freenet.de Sat Jun 2 01:57:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 02 Jun 2007 03:57:22 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <46605818.6050809@poolshark.org> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> <4660037B.9090009@fedoraproject.org> <4660039D.1070500@hhs.nl> <46600829.1080301@fedoraproject.org> <46601001.1000201@hhs.nl> <1180701824.5761.70.camel@vader.jdub.homelinux.org> <46601AB6.10602@leemhuis.info> <46605818.6050809@poolshark.org> Message-ID: <1180749442.12595.397.camel@mccallum.corsepiu.local> On Fri, 2007-06-01 at 19:32 +0200, Denis Leroy wrote: > Thorsten Leemhuis wrote: > > On 01.06.2007 14:43, Josh Boyer wrote: > >> On Fri, 2007-06-01 at 14:24 +0200, Hans de Goede wrote: > >>> 1) Can it cause regressions for existing users? -> No > >> It can cause new problems. > > > > +1 > > > >>> 2) Will it get installed automatically by the relative few people who have > >>> updates -testing enabled, and thus see any kind of testing (atleast if its > >>> installable)? -> No > >> You're making an assumption that there are few people that enable > >> updates-testing. > > > > /me has it enabled on nearly all of his machines and that way prevented > > at least once or twice in the past that bad updates hit updates-proper > > I have updates-testing set up too, but remember it won't install new > packages, only update existing ones. Is anyone going to install all > *new* packages that hit updates-testing automatically ? As a "normal user", of a "stable distro", I would never want to use updates-testing, because the distro is defined as "stable". I would only consider using individual packages for "testing them locally", when being victim of bugs in "stable" and being asked/pointed to packages from other sources. It's essentially the same as with individual maintainers pointing bug reporters to private sites or to rawhide (The infamous FIXEDRAWHIDE). As a developer, I would only consider packages from "testing" if I know there is something new inside, I am particularly interested in. Ralf From caillon at redhat.com Sat Jun 2 07:49:16 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 02 Jun 2007 03:49:16 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070602000704.GG4751@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <20070602000704.GG4751@tomservo.rochester.rr.com> Message-ID: <466120FC.8070407@redhat.com> Luke Macken wrote: > Once we agree on a policy, I can implement it. I've heard some people > suggest letting updates sit in testing for 7 days, and if there are no > complaints, then they can be pushed to the stable repo. This sounds > fine to me, what does everyone else think? 7 days is a long time for people not used to this (everybody). While it might be the right thing to do, we might want to consider starting off with 3 or 4 days and then transitioning to 7. From caillon at redhat.com Sat Jun 2 07:59:40 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 02 Jun 2007 03:59:40 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <466120FC.8070407@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <20070602000704.GG4751@tomservo.rochester.rr.com> <466120FC.8070407@redhat.com> Message-ID: <4661236C.80502@redhat.com> Christopher Aillon wrote: > Luke Macken wrote: >> Once we agree on a policy, I can implement it. I've heard some people >> suggest letting updates sit in testing for 7 days, and if there are no >> complaints, then they can be pushed to the stable repo. This sounds >> fine to me, what does everyone else think? > > 7 days is a long time for people not used to this (everybody). While it > might be the right thing to do, we might want to consider starting off > with 3 or 4 days and then transitioning to 7. Maybe phasing it in by starting with 3 and then adding an extra day for each test/release up until FC8? From sundaram at redhat.com Sat Jun 2 16:49:51 2007 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 02 Jun 2007 22:19:51 +0530 Subject: [Fwd: Bugzilla news is the Zod announcement] Message-ID: <46619FAF.80000@redhat.com> An embedded message was scrubbed... From: Bruno Wolff III Subject: Bugzilla news is the Zod announcement Date: Sat, 2 Jun 2007 10:03:29 -0500 Size: 3016 URL: From Axel.Thimm at ATrpms.net Sat Jun 2 19:21:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Jun 2007 21:21:40 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531000022.GA10430@nostromo.devel.redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> Message-ID: <20070602192140.GM7159@neu.nirvana> On Wed, May 30, 2007 at 08:00:22PM -0400, Bill Nottingham wrote: > Bodhi is now available for update submission at: > https://admin.fedoraproject.org/updates/ After playing a bit with it, I must say that it looks very nice and makes a lot of sense: Nice work, Luke (and whoever else was involved)! Now if there were a pure CLI way (make bodhi-XXX) to do things that would be perfect. :) > You'll need to log in with your FAS username/password. > > For more information on what bodhi is, and how to use it, see: > http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT > > Bill > -- 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 Sat Jun 2 19:27:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 2 Jun 2007 15:27:30 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070602192140.GM7159@neu.nirvana> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <20070602192140.GM7159@neu.nirvana> Message-ID: <200706021527.31134.jkeating@redhat.com> On Saturday 02 June 2007 15:21:40 Axel Thimm wrote: > Now if there were a pure CLI way (make bodhi-XXX) to do things that > would be perfect. :) It's coming (: -- 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 tgl at redhat.com Sat Jun 2 21:06:25 2007 From: tgl at redhat.com (Tom Lane) Date: Sat, 02 Jun 2007 17:06:25 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070602000704.GG4751@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <20070602000704.GG4751@tomservo.rochester.rr.com> Message-ID: <27220.1180818385@sss.pgh.pa.us> Luke Macken writes: > Once we agree on a policy, I can implement it. I've heard some people > suggest letting updates sit in testing for 7 days, and if there are no > complaints, then they can be pushed to the stable repo. This sounds > fine to me, what does everyone else think? zero-day security patches A week as a guideline for noncritical updates sounds fine. A week enforced by the update tool would seriously suck. regards, tom lane From jwboyer at jdub.homelinux.org Sat Jun 2 22:04:49 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 02 Jun 2007 17:04:49 -0500 Subject: Pushing updates for Fedora 7 In-Reply-To: <27220.1180818385@sss.pgh.pa.us> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <20070602000704.GG4751@tomservo.rochester.rr.com> <27220.1180818385@sss.pgh.pa.us> Message-ID: <1180821889.3218.7.camel@vader.jdub.homelinux.org> On Sat, 2007-06-02 at 17:06 -0400, Tom Lane wrote: > Luke Macken writes: > > Once we agree on a policy, I can implement it. I've heard some people > > suggest letting updates sit in testing for 7 days, and if there are no > > complaints, then they can be pushed to the stable repo. This sounds > > fine to me, what does everyone else think? > > zero-day security patches > > A week as a guideline for noncritical updates sounds fine. A week > enforced by the update tool would seriously suck. It's not. It's enforced by people that can make that distinction. josh From jeff at ocjtech.us Sun Jun 3 03:23:09 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sat, 02 Jun 2007 22:23:09 -0500 Subject: Pushing updates for Fedora 7 In-Reply-To: <466001C9.1080704@hhs.nl> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> <1180655288.25009.12.camel@cookie.hadess.net> <465FC5B8.7060602@hhs.nl> <20070601103845.GB4751@tomservo.rochester.rr.com> <466001C9.1080704@hhs.nl> Message-ID: <1180840990.4465.34.camel@lt21223.campus.dmacc.edu> On Fri, 2007-06-01 at 13:23 +0200, Hans de Goede wrote: > Luke Macken wrote: > > Just because it's a new package means it doesn't need to be tested? :) > Can it cause regressions for existing users? -> No I don't think that this claim is true. There are many packages that have run-time checks for other programs/libraries/plugins that are not required for full functionality, and so aren't strict dependencies. The two examples that come to mind are Firefox and GStreamer plugins. Nautilus has a plugin mechanism as well, and many Perl and Python programs have run-time checks for optional libraries. 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 tchung at fedoraproject.org Sun Jun 3 06:28:00 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Sat, 2 Jun 2007 23:28:00 -0700 Subject: Fedora 7 Update Informatin for general users Message-ID: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> First all, thank you for Fedora Update System. It's wonderful to see that we finally have something we always wanted. While looking at the list of Stable Updates for Fedora 7[1], it gives me an idea that this could replace our static Fedora Security Advisories and Package Updates for Fedora 7[1] on our project wiki. What do you think? Could we open this system up so any general users can see this information anonymously without logging-in with Fedora Account System? Perhaps, we could create a new page specifically for anonymous users without comments field? This will be an enormous help and save my *endless-efforts* to update the wiki pages manually. :) Best Regards, [1] https://admin.fedoraproject.org/updates/F7 [2] http://fedoraproject.org/wiki/FSA/F7 -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From pertusus at free.fr Sun Jun 3 09:49:01 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 3 Jun 2007 11:49:01 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180821889.3218.7.camel@vader.jdub.homelinux.org> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <20070602000704.GG4751@tomservo.rochester.rr.com> <27220.1180818385@sss.pgh.pa.us> <1180821889.3218.7.camel@vader.jdub.homelinux.org> Message-ID: <20070603094901.GF2826@free.fr> On Sat, Jun 02, 2007 at 05:04:49PM -0500, Josh Boyer wrote: > > It's not. It's enforced by people that can make that distinction. In general those people are the packagers, isn't it? -- Pat From lmacken at redhat.com Sun Jun 3 10:10:40 2007 From: lmacken at redhat.com (Luke Macken) Date: Sun, 3 Jun 2007 06:10:40 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <27220.1180818385@sss.pgh.pa.us> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <20070602000704.GG4751@tomservo.rochester.rr.com> <27220.1180818385@sss.pgh.pa.us> Message-ID: <20070603101040.GG13318@tomservo.rochester.rr.com> On Sat, Jun 02, 2007 at 05:06:25PM -0400, Tom Lane wrote: > Luke Macken writes: > > Once we agree on a policy, I can implement it. I've heard some people > > suggest letting updates sit in testing for 7 days, and if there are no > > complaints, then they can be pushed to the stable repo. This sounds > > fine to me, what does everyone else think? > > zero-day security patches Security updates go straight to Stable already. > A week as a guideline for noncritical updates sounds fine. A week > enforced by the update tool would seriously suck. At the moment it's not enforcing anything, as anyone can mark their updates as stable whenever they want. To implement this guideline, I could have bodhi automatically submit updates to the stable repo after the n days are up. Whether or not we want to take away our ability to mark our own updates as stable and force approval or timeout on test updates is still up for discussion. luke From rc040203 at freenet.de Sun Jun 3 11:12:48 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 Jun 2007 13:12:48 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070603101040.GG13318@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <20070602000704.GG4751@tomservo.rochester.rr.com> <27220.1180818385@sss.pgh.pa.us> <20070603101040.GG13318@tomservo.rochester.rr.com> Message-ID: <1180869168.12595.556.camel@mccallum.corsepiu.local> On Sun, 2007-06-03 at 06:10 -0400, Luke Macken wrote: > On Sat, Jun 02, 2007 at 05:06:25PM -0400, Tom Lane wrote: > > Luke Macken writes: > > > Once we agree on a policy, I can implement it. I've heard some people > > > suggest letting updates sit in testing for 7 days, and if there are no > > > complaints, then they can be pushed to the stable repo. This sounds > > > fine to me, what does everyone else think? > > > > zero-day security patches > > Security updates go straight to Stable already. They shouldn't. They should undergo an automated procedure to assure they fit cleanly into the existing installations and don't break package deps. Ralf From fedora at leemhuis.info Sun Jun 3 13:17:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 15:17:49 +0200 Subject: EPEL report week 21, 2007 Message-ID: <4662BF7D.60308@leemhuis.info> = Weekly EPEL Summary = Week 22/2007 == Most important happenings == * MikeMcGrath, MaxSpevack and ThorstenLeemhuis meet Dag Wieers, AxelThimm, Lance Davis, Ralph Angenendt and some other CentOS guys on LinuxTag; we talked a bit (round about 100 Minutes iirc) about cooperation and communication; I'd say it was a good chat and I suppose we understand each others positions better. Repotags were discussed as well; but I'll bring that topic up over the next few days for EPEL separately. == EPEL SIG Meeting == No meeting this week due to MikeMcGrath and ThorstenLeemhuis on LinuxTag in another meeting and thus afk. === General === Number of EPEL Contributors 81 We welcome 1 new contributors: rayvd_AT_bludgeon.org === EPEL 5 === Number of source packages: 299 Number of binary packages: 480 There are 7 new Packages: * dwatch | A program that watches over other programs * ettercap | Network traffic sniffer/analyser, NCURSES interface version * gmrun | Lightweight "Run program" dialog box with search history and tab completion * perl-Net-IPv6Addr | Perl module to check validity of IPv6 addresses * perl-Net-Server | Extensible, general Perl server engine * remind | A sophisticated calendar and alarm program * vym | View your mind === EPEL 4 === Number of source packages: 201 Number of binary packages: 378 There are 7 new Packages: * dwatch | A program that watches over other programs * ettercap | Network traffic sniffer/analyser, NCURSES interface version * fontforge | Outline and bitmap font editor * perl-Net-IPv6Addr | Perl module to check validity of IPv6 addresses * perl-Net-Server | Extensible, general Perl server engine * remind | A sophisticated calendar and alarm program * wine | A Windows 16/32/64 bit emulator ---- ["CategoryEPELReports"] From jkeating at redhat.com Sun Jun 3 13:46:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 09:46:27 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180869168.12595.556.camel@mccallum.corsepiu.local> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <20070603101040.GG13318@tomservo.rochester.rr.com> <1180869168.12595.556.camel@mccallum.corsepiu.local> Message-ID: <200706030946.27285.jkeating@redhat.com> On Sunday 03 June 2007 07:12:48 Ralf Corsepius wrote: > > Security updates go straight to Stable already. > > They shouldn't. They should undergo an automated procedure to assure > they fit cleanly into the existing installations and don't break package > deps. This is not always practical. Should a firefox remote exploit fix be held up because a fringe package that builds against FF and is used by say 5 people hasn't been rebuilt yet? Should every use suffer? I seriously hope 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 bugs.michael at gmx.net Sun Jun 3 14:07:45 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 3 Jun 2007 16:07:45 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <200706030946.27285.jkeating@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <20070603101040.GG13318@tomservo.rochester.rr.com> <1180869168.12595.556.camel@mccallum.corsepiu.local> <200706030946.27285.jkeating@redhat.com> Message-ID: <20070603160745.d3643419.bugs.michael@gmx.net> On Sun, 3 Jun 2007 09:46:27 -0400, Jesse Keating wrote: > On Sunday 03 June 2007 07:12:48 Ralf Corsepius wrote: > > > Security updates go straight to Stable already. > > > > They shouldn't. They should undergo an automated procedure to assure > > they fit cleanly into the existing installations and don't break package > > deps. > > This is not always practical. Should a firefox remote exploit fix be held up > because a fringe package that builds against FF and is used by say 5 people > hasn't been rebuilt yet? Should every use suffer? I seriously hope not. Hence there must be strategies which deal with these situations. It is not acceptable that a user suffers from a broken dependency, which makes it impossible to update FF, while the packager who could fix the broken dep perhaps is on vacation, awol, whatever, and it takes days if not weeks to find out. From jkeating at redhat.com Sun Jun 3 14:07:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 10:07:05 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070603160745.d3643419.bugs.michael@gmx.net> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <200706030946.27285.jkeating@redhat.com> <20070603160745.d3643419.bugs.michael@gmx.net> Message-ID: <200706031007.05921.jkeating@redhat.com> On Sunday 03 June 2007 10:07:45 Michael Schwendt wrote: > Hence there must be strategies which deal with these situations. > It is not acceptable that a user suffers from a broken dependency, > which makes it impossible to update FF, while the packager who > could fix the broken dep perhaps is on vacation, awol, whatever, > and it takes days if not weeks to find out. Sure. The current security team ideals is that a security team member can step in and apply security fixes or rebuild dependent packages in the absence of a maintainer. There needs to be a reasonable timeout though no? So there may still be a window where the update gets released, and the fringe packages are not updated to suit, until a timeout is reached and a security team member has to step in and issue an update for the fringe package. -- 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 Sun Jun 3 14:12:49 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 Jun 2007 16:12:49 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <200706030946.27285.jkeating@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <20070603101040.GG13318@tomservo.rochester.rr.com> <1180869168.12595.556.camel@mccallum.corsepiu.local> <200706030946.27285.jkeating@redhat.com> Message-ID: <1180879969.12595.598.camel@mccallum.corsepiu.local> On Sun, 2007-06-03 at 09:46 -0400, Jesse Keating wrote: > On Sunday 03 June 2007 07:12:48 Ralf Corsepius wrote: > > > Security updates go straight to Stable already. > > > > They shouldn't. They should undergo an automated procedure to assure > > they fit cleanly into the existing installations and don't break package > > deps. > > This is not always practical. Should a firefox remote exploit fix be held up > because a fringe package that builds against FF and is used by say 5 people > hasn't been rebuilt yet? Should every use suffer? I seriously hope not. IMO, this has to be balanced on a case by case basis. * Does a broken update get installed at all or will yum refuse to install it due to broken deps? * Does postponing a security update for a few hours until things get "cleaned up" really hurt? In some cases it will, in most it will not. * Consider mirrors: Do security updates get immediately pushed to mirrors or will mirrors pull them with a several hours or days delay? Given the "out-of-syncness" many mirrors are in, delaying pushing packages by a couple of hours doesn't really make a difference. * Consider users: Many don't upgrade immediately. Most probably poll at intervals. Ralf From fedora at leemhuis.info Sun Jun 3 14:13:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 16:13:00 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <200706030946.27285.jkeating@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <20070603101040.GG13318@tomservo.rochester.rr.com> <1180869168.12595.556.camel@mccallum.corsepiu.local> <200706030946.27285.jkeating@redhat.com> Message-ID: <4662CC6C.5000804@leemhuis.info> On 03.06.2007 15:46, Jesse Keating wrote: > On Sunday 03 June 2007 07:12:48 Ralf Corsepius wrote: >>> Security updates go straight to Stable already. >> They shouldn't. They should undergo an automated procedure to assure >> they fit cleanly into the existing installations and don't break package >> deps. > This is not always practical. Should a firefox remote exploit fix be held up > because a fringe package that builds against FF and is used by say 5 people > hasn't been rebuilt yet? Should every use suffer? I seriously hope not. Well, the merged world should give us some benefits now. Can't those packagers that have packages depending on firefox give caillion the permission to rebuild their packages? Then he can simply build all those after the new firefox fished building. A script might be helpful and could automate most of it -- then it would be nothing more than one button someone has to push after a new firefox is through the buildsys. That might delay the firefox update by an hour maybe. That's acceptable for the benefit afaics. Ohh, and those packages that fail the rebuild simply don't get pushed -- not nice, but happens. That would improve the situation quite a lot. Knowingly breaking the repo is not the answer. CU thl From marek at mahut.sk Sun Jun 3 09:43:28 2007 From: marek at mahut.sk (Marek Mahut) Date: Sun, 03 Jun 2007 11:43:28 +0200 Subject: Fedora 7 Update Informatin for general users In-Reply-To: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> References: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> Message-ID: <46628D40.8090706@mahut.sk> Thomas Chung wrote: > First all, thank you for Fedora Update System. > It's wonderful to see that we finally have something we always wanted. > > While looking at the list of Stable Updates for Fedora 7[1], it gives > me an idea that this could replace our static Fedora Security > Advisories and Package Updates for Fedora 7[1] on our project wiki. > > What do you think? Could we open this system up so any general users > can see this information anonymously without logging-in with Fedora > Account System? I think it's a very good idea to open this system for public. > Perhaps, we could create a new page specifically for anonymous users > without comments field? > > This will be an enormous help and save my *endless-efforts* to update > the wiki pages manually. :) > > Best Regards, > > [1] https://admin.fedoraproject.org/updates/F7 > [2] http://fedoraproject.org/wiki/FSA/F7 -- Marek Mahut Tel.: +420-532-294-111 (ex. 826-2046) Fedora Ambassador GSM: +420-731-076-674 http://www.fedoraproject.org http://www.jamendo.com ____________________________________________________________________ From mtasaka at ioa.s.u-tokyo.ac.jp Sun Jun 3 14:25:16 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 03 Jun 2007 23:25:16 +0900 Subject: Pushing updates for Fedora 7 In-Reply-To: <200706030946.27285.jkeating@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <20070603101040.GG13318@tomservo.rochester.rr.com> <1180869168.12595.556.camel@mccallum.corsepiu.local> <200706030946.27285.jkeating@redhat.com> Message-ID: <4662CF4C.1060103@ioa.s.u-tokyo.ac.jp> Jesse Keating wrote, at 06/03/2007 10:46 PM +9:00: > On Sunday 03 June 2007 07:12:48 Ralf Corsepius wrote: >>> Security updates go straight to Stable already. >> They shouldn't. They should undergo an automated procedure to assure >> they fit cleanly into the existing installations and don't break package >> deps. > > This is not always practical. Should a firefox remote exploit fix be held up > because a fringe package that builds against FF and is used by say 5 people > hasn't been rebuilt yet? Should every use suffer? I seriously hope not. Well, while I feel now that I can hardly catch up with this long thread, I leave one comment for this. While I surely understand that we should take security updates very important, please keep in mind that I hear on Fedora BBS (in Japan) about the strong complaint about dependency break more and more times than the delay of security related updates. Regards, Mamoru From jkeating at redhat.com Sun Jun 3 14:27:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 10:27:28 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180879969.12595.598.camel@mccallum.corsepiu.local> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <200706030946.27285.jkeating@redhat.com> <1180879969.12595.598.camel@mccallum.corsepiu.local> Message-ID: <200706031027.32066.jkeating@redhat.com> On Sunday 03 June 2007 10:12:49 Ralf Corsepius wrote: > IMO, this has to be balanced on a case by case basis. I don't disagree one bit. That's why it is important that things use the update tool and mark themselves as security updates and whatnot. > * Does a broken update get installed at all or will yum refuse to > install it due to broken deps? It depends on what is broken. If you don't have the app that is broken, you'll get the update. Only if you have that app that is broken will you see the broken deps, and then you can decide whether or not to remove said broken app or skip update. > * Does postponing a security update for a few hours until things get > "cleaned up" really hurt? In some cases it will, in most it will not. ACK > * Consider mirrors: Do security updates get immediately pushed to > mirrors or will mirrors pull them with a several hours or days delay? > Given the "out-of-syncness" many mirrors are in, delaying pushing > packages by a couple of hours doesn't really make a difference. > > * Consider users: Many don't upgrade immediately. Most probably poll at > intervals. Actually both these could lean in favor of releasing it immediately. By the time the mirrors sync or people do their upgrade the rest of the missing packages could have been rebuilt and released. But all in all I definitely agree this has to be a case by case issue, one that is hopefully discussed within releng and the security team. -- 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 Sun Jun 3 14:30:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 10:30:17 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <4662CC6C.5000804@leemhuis.info> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <200706030946.27285.jkeating@redhat.com> <4662CC6C.5000804@leemhuis.info> Message-ID: <200706031030.17991.jkeating@redhat.com> On Sunday 03 June 2007 10:13:00 Thorsten Leemhuis wrote: > Well, the merged world should give us some benefits now. Can't those > packagers that have packages depending on firefox give caillion the > permission to rebuild their packages? Then he can simply build all those > after the new firefox fished building. A script might be helpful and > could automate most of it -- then it would be nothing more than one > button someone has to push after a new firefox is through the buildsys. We're not talking about a small number of packages though. caillon still has to do updates for older Core releases, RHEL*, etc... Perhaps somebody would like to help Chris with rebuilding the dependant packages, since in this merged world anybody else could as well. Dumping it on Chris is not a viable answer. > That might delay the firefox update by an hour maybe. That's acceptable > for the benefit afaics. I doubt it would be only an hour. > Ohh, and those packages that fail the rebuild simply don't get pushed -- > not nice, but happens. > > That would improve the situation quite a lot. Knowingly breaking the > repo is not the answer. Sure, to an extent. But just waiting for all the other packages to catch up before pushing an important security update that many could use without noticing the broken deps is not a good solution. -- 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 Sun Jun 3 14:31:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 10:31:17 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <4662CF4C.1060103@ioa.s.u-tokyo.ac.jp> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <200706030946.27285.jkeating@redhat.com> <4662CF4C.1060103@ioa.s.u-tokyo.ac.jp> Message-ID: <200706031031.17733.jkeating@redhat.com> On Sunday 03 June 2007 10:25:16 Mamoru Tasaka wrote: > While I surely understand that we should take security updates > very important, please keep in mind that I hear on Fedora BBS > (in Japan) about the strong complaint about dependency break more and > more times than the delay of security related updates. Often times users don't _know_ that a security update was delayed. -- 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 Jun 3 14:44:07 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 03 Jun 2007 23:44:07 +0900 Subject: Pushing updates for Fedora 7 In-Reply-To: <200706031031.17733.jkeating@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <200706030946.27285.jkeating@redhat.com> <4662CF4C.1060103@ioa.s.u-tokyo.ac.jp> <200706031031.17733.jkeating@redhat.com> Message-ID: <4662D3B7.9010603@ioa.s.u-tokyo.ac.jp> Jesse Keating wrote, at 06/03/2007 11:31 PM +9:00: > On Sunday 03 June 2007 10:25:16 Mamoru Tasaka wrote: >> While I surely understand that we should take security updates >> very important, please keep in mind that I hear on Fedora BBS >> (in Japan) about the strong complaint about dependency break more and >> more times than the delay of security related updates. > > Often times users don't _know_ that a security update was delayed. Yes. What I want to say here is that while the delay of the security updates is often invisible to end users, the dependency break becomes *obvious quickly* and so the latter (dependendy break) bears much complaint than the formar (for end users) and I wanted to notice this. The eyes of maintainers and end users are somewhat different. Mamoru From rc040203 at freenet.de Sun Jun 3 14:48:52 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 Jun 2007 16:48:52 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <200706031027.32066.jkeating@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <200706030946.27285.jkeating@redhat.com> <1180879969.12595.598.camel@mccallum.corsepiu.local> <200706031027.32066.jkeating@redhat.com> Message-ID: <1180882132.12595.622.camel@mccallum.corsepiu.local> On Sun, 2007-06-03 at 10:27 -0400, Jesse Keating wrote: > On Sunday 03 June 2007 10:12:49 Ralf Corsepius wrote: > > IMO, this has to be balanced on a case by case basis. > But all in all I definitely agree this has to be a case by case issue, one > that is hopefully discussed within releng and the security team. Let me put it this way: In any case an automated check should be implemented (Wrt. EVRs it must already be present somewhere), but it would at least have to notify the maintainer: "Your rpm is breaking EVRs x,y,z ... Release anyway?" Unless a security issue is too severe and if build-times are in "feasible orders" (say 2-3 hrs - Which I would expect to apply to the vast majority of packages) a maintainer should very carefully consider whether he really needs to push a packages "RSN", or whether he should take care about the breakages he is causing (Automated rebuilds of breaking packages would be an option if wanting to drive this to extremes) Ralf From bugs.michael at gmx.net Sun Jun 3 14:57:14 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 3 Jun 2007 16:57:14 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <4662CF4C.1060103@ioa.s.u-tokyo.ac.jp> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <20070603101040.GG13318@tomservo.rochester.rr.com> <1180869168.12595.556.camel@mccallum.corsepiu.local> <200706030946.27285.jkeating@redhat.com> <4662CF4C.1060103@ioa.s.u-tokyo.ac.jp> Message-ID: <20070603165714.db3ec8a3.bugs.michael@gmx.net> On Sun, 03 Jun 2007 23:25:16 +0900, Mamoru Tasaka wrote: > While I surely understand that we should take security updates > very important, please keep in mind that I hear on Fedora BBS > (in Japan) about the strong complaint about dependency break more and > more times than the delay of security related updates. +1 That guy has understood! The security-fix is useless to an unknown number of users, who run into broken deps. The repository remains broken till a packager is informed about the breakage and supplies a fix. My personal experience with the broken deps reports is that many packagers become active in cvs shortly after receiving the mail and seldomly before receiving the mail. That is a strong indication that (1) packagers could provide rebuilds quicker when learning about a security update in the queue, and (2) when being informed as soon as the security update is published. From jkeating at redhat.com Sun Jun 3 14:51:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 10:51:18 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180882132.12595.622.camel@mccallum.corsepiu.local> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <200706031027.32066.jkeating@redhat.com> <1180882132.12595.622.camel@mccallum.corsepiu.local> Message-ID: <200706031051.18268.jkeating@redhat.com> On Sunday 03 June 2007 10:48:52 Ralf Corsepius wrote: > Let me put it this way: > > In any case an automated check should be implemented (Wrt. EVRs it must > already be present somewhere), but it would at least have to notify the > maintainer: > "Your rpm is breaking EVRs x,y,z ... Release anyway?" > > Unless a security issue is too severe and if build-times are in > "feasible orders" (say 2-3 hrs - Which I would expect to apply to the > vast majority of packages) a maintainer should very carefully consider > whether he really needs to push a packages "RSN", or whether he should > take care about the breakages he is causing (Automated rebuilds of > breaking packages would be an option if wanting to drive this to > extremes) I don't disagree at all. We could use help in implementing such features into Bodhi. Care to help? -- 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 Sun Jun 3 15:08:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 11:08:23 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting Message-ID: <200706031108.23794.jkeating@redhat.com> Below you will find a list of topics that we'd like to go over in the next RelEng meeting that is scheduled for tomorrow, Monday at 1700 UTC in #fedora-meeting on irc.freenode.org: /topic RELENG-Meeting - Rawhide spam-o-matic - JesseKeating /topic RELENG-Meeting - Updates Policy - JesseKeating /topic RELENG-Meeting - Freeze Policy - JesseKeating /topic RELENG-Meeting - Flesh out SOPs for rel-eng tasks - JesseKeating /topic RELENG-Meeting - Open Discussion 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 "Open Discussion" phase. If your name/nick is on above list please update the status on the ReleaseEngineering/Meetings/Agenda page in the wiki ahead of the meeting. That way all the other RelEng members and interested contributors know whats 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... -- 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 Sun Jun 3 15:11:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 11:11:22 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706031108.23794.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> Message-ID: <200706031111.22625.jkeating@redhat.com> On Sunday 03 June 2007 11:08:23 Jesse Keating wrote: > /topic RELENG-Meeting - Updates Policy - JesseKeating > > /topic RELENG-Meeting - Freeze Policy - JesseKeating For these two topics I would really really like to get people to bring their ideas and thoughts about this to our meeting. Annoyances with the policies used for Fedora 7, ideas on how to make it better, etc... Come one, come all. I'll happily dedicate the entire meeting to these topics if need be. -- 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 Sun Jun 3 15:29:58 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 3 Jun 2007 17:29:58 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706031108.23794.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> Message-ID: <20070603152958.GA2912@free.fr> On Sun, Jun 03, 2007 at 11:08:23AM -0400, Jesse Keating wrote: > /topic RELENG-Meeting - Updates Policy - JesseKeating About update policy, first I think that it should be easy to do something like: make go-to-release which would use the changelog entry (or something similar). If I recall well this is already more or less agreed. It should also be possible for a maintainer to decide what amount of time the package should stay in the testing repo. The default would be something reasonable (one week?). The rel-eng team could have the possibility to block the update at any time if they find something is abnormal. For example make go-to-release 1 would make the package stay 1 day in testing repo. And there should be automatic checks for broken deps, for duplicated provides, for upgrade path. > /topic RELENG-Meeting - Freeze Policy - JesseKeating On that topic, I think that during a freeze there shouldn't be a need to mail to rel-eng to push to the frozen collection. It should be a specific target, so for example to push to the frozen collection one should do make build make go-to-freeze Then the rel-eng would see that (together with the changelog entry), and block if something seems dubious, or if it is too late in the freeze. It would be nice to have checks for broken deps, for duplicated provides, for upgrade path. And when rel-eng block something they should be able to simply contact the maintainer, for example by replying to a mail, or optionally on fedora-devel or a similar list. -- Pat From jonathan.underwood at gmail.com Sun Jun 3 15:40:07 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 3 Jun 2007 16:40:07 +0100 Subject: Unsigned package in repo - how do I get it signed? Message-ID: <645d17210706030840s4c381f7fjc77dffa1867afffc@mail.gmail.com> Hi, One of my packages (sunfidef) appears to have not been signed, but is in the repo. See BZ 242348. What's the procedure for getting it signed? Thanks, Jonathan From fedora at leemhuis.info Sun Jun 3 15:41:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 17:41:29 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706031111.22625.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706031111.22625.jkeating@redhat.com> Message-ID: <4662E129.7030903@leemhuis.info> On 03.06.2007 17:11, Jesse Keating wrote: > On Sunday 03 June 2007 11:08:23 Jesse Keating wrote: >> /topic RELENG-Meeting - Updates Policy - JesseKeating >> >> /topic RELENG-Meeting - Freeze Policy - JesseKeating > > For these two topics I would really really like to get people to bring their > ideas and thoughts about this to our meeting. Annoyances with the policies > used for Fedora 7, ideas on how to make it better, etc... Come one, come > all. I'll happily dedicate the entire meeting to these topics if need be. Just a though: I was wondering if we should somehow split development and release lines shortly before the release. Rough Example: Ship test3; get the tree release-ready for two or three weeks later. Create the release directories on the servers and issue a RC from them with ISOs. Spread them; if important bugs are found: Fix them in a rolling release scheme. One or two weeks later issue the real release and freeze the repos; all updates from now on get into the update repo. Some of the Benefits: - more testers might download the RC, as it will become the F7 final my just running "yum update". They might find new bugs regular testers did not hit - rawhide development can start earlier again and is not blocked for that long Some of the Disadvantages: - rawhide users don't test the final release. But at the point where we split the tree should be in a proper shape already, so those that are testing it for a long time already won't likely find new problems in any care. Risks: - we need to be really strict and release a RC that is meant as a real final and fix only important stuff afterwards that showed up in the RC (e.g. something like the maxcpus= As I said: Just a thought. CU thl From jonathan.underwood at gmail.com Sun Jun 3 15:52:48 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 3 Jun 2007 16:52:48 +0100 Subject: Unsigned package in repo - how do I get it signed? In-Reply-To: <645d17210706030840s4c381f7fjc77dffa1867afffc@mail.gmail.com> References: <645d17210706030840s4c381f7fjc77dffa1867afffc@mail.gmail.com> Message-ID: <645d17210706030852j2f788c6cg1d675c219114943e@mail.gmail.com> On 03/06/07, Jonathan Underwood wrote: > Hi, > > One of my packages (sunfidef) appears to have not been signed, but is > in the repo. See BZ 242348. What's the procedure for getting it > signed? > > Thanks, > Jonathan > Aha, I see that Jesse Keating is aware of the issue and plans to fix unsigned packages on Monday (see fedora-devel list). Sorry for the noise. Jonathan From jwboyer at jdub.homelinux.org Sun Jun 3 16:05:28 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 03 Jun 2007 11:05:28 -0500 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070603152958.GA2912@free.fr> References: <200706031108.23794.jkeating@redhat.com> <20070603152958.GA2912@free.fr> Message-ID: <1180886729.3218.32.camel@vader.jdub.homelinux.org> On Sun, 2007-06-03 at 17:29 +0200, Patrice Dumas wrote: > On Sun, Jun 03, 2007 at 11:08:23AM -0400, Jesse Keating wrote: > > /topic RELENG-Meeting - Updates Policy - JesseKeating > > About update policy, first I think that it should be easy to do > something like: > > make go-to-release > > which would use the changelog entry (or something similar). If I recall > well this is already more or less agreed. Yes. I think Luke is working on a bodhi command line client (or will be) that could be wrapped in the makefiles. > It should also be possible for a maintainer to decide what amount of > time the package should stay in the testing repo. The default would be > something reasonable (one week?). The rel-eng team could have the > possibility to block the update at any time if they find something is > abnormal. > > For example > make go-to-release 1 > would make the package stay 1 day in testing repo. That would be the point that needs the most discussion. > And there should be automatic checks for broken deps, for duplicated > provides, for upgrade path. That is planned. Just needs coding. I think everyone agrees that would be a very good thing to have. > > /topic RELENG-Meeting - Freeze Policy - JesseKeating > > On that topic, I think that during a freeze there shouldn't be a need to > mail to rel-eng to push to the frozen collection. It should be a > specific target, so for example to push to the frozen collection one > should do > > make build > make go-to-freeze > > Then the rel-eng would see that (together with the changelog entry), and > block if something seems dubious, or if it is too late in the freeze. It Their ability to do that, under those circumstances, might be limited. Rel-eng doesn't immediately know if it's too invasive, which is why a request is sent. Not all changelogs are descriptive. But perhaps something better could be done, yes. Also remember there will be a point in time where things are completely frozen so that ISOs can be made. During that (relatively) short period of time, the push feature would be disabled. josh From bpepple at fedoraproject.org Sun Jun 3 16:21:42 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 03 Jun 2007 12:21:42 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4662E129.7030903@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <200706031111.22625.jkeating@redhat.com> <4662E129.7030903@leemhuis.info> Message-ID: <1180887702.2809.32.camel@kennedy> On Sun, 2007-06-03 at 17:41 +0200, Thorsten Leemhuis wrote: > > On 03.06.2007 17:11, Jesse Keating wrote: > > On Sunday 03 June 2007 11:08:23 Jesse Keating wrote: > >> /topic RELENG-Meeting - Updates Policy - JesseKeating > >> > >> /topic RELENG-Meeting - Freeze Policy - JesseKeating > > > > For these two topics I would really really like to get people to bring their > > ideas and thoughts about this to our meeting. Annoyances with the policies > > used for Fedora 7, ideas on how to make it better, etc... Come one, come > > all. I'll happily dedicate the entire meeting to these topics if need be. > > Just a though: I was wondering if we should somehow split development > and release lines shortly before the release. This is one of the topics that is in FESCo, that we pushed off discussing until after F7 was released. /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 pertusus at free.fr Sun Jun 3 16:35:03 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 3 Jun 2007 18:35:03 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1180886729.3218.32.camel@vader.jdub.homelinux.org> References: <200706031108.23794.jkeating@redhat.com> <20070603152958.GA2912@free.fr> <1180886729.3218.32.camel@vader.jdub.homelinux.org> Message-ID: <20070603163503.GC2912@free.fr> On Sun, Jun 03, 2007 at 11:05:28AM -0500, Josh Boyer wrote: > > Then the rel-eng would see that (together with the changelog entry), and > > block if something seems dubious, or if it is too late in the freeze. It > > Their ability to do that, under those circumstances, might be limited. > Rel-eng doesn't immediately know if it's too invasive, which is why a > request is sent. Not all changelogs are descriptive. But perhaps Blocking if changelogs are not descriptive enough seems completly reasonable to me (in a period of freeze). > something better could be done, yes. > > Also remember there will be a point in time where things are completely > frozen so that ISOs can be made. During that (relatively) short period > of time, the push feature would be disabled. Of course. This period could be not so short, especially if the next release has been already branched. -- Pat From sundaram at fedoraproject.org Sun Jun 3 18:32:26 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 04 Jun 2007 00:02:26 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706031108.23794.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> Message-ID: <4663093A.6040003@fedoraproject.org> Jesse Keating wrote: > Below you will find a list of topics that we'd like to go over in the next > RelEng meeting that is scheduled for tomorrow, Monday at 1700 UTC in > #fedora-meeting on irc.freenode.org: > > /topic RELENG-Meeting - Rawhide spam-o-matic - JesseKeating > > /topic RELENG-Meeting - Updates Policy - JesseKeating > > /topic RELENG-Meeting - Freeze Policy - JesseKeating > > /topic RELENG-Meeting - Flesh out SOPs for rel-eng tasks - JesseKeating > > /topic RELENG-Meeting - Open Discussion > > 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 "Open > Discussion" phase. I would like rel eng to discuss a few things Torrent only release -------------------- I remember this was discussed before but when a new release is made and we are waiting for the mirrors to sync why not do a torrent only release immediately? The advantage is that we won't suffer as much from infrastructure and mirror problems with the mad rush in everybody trying to get it at the same time. Not sure if this has any disadvantages. Supported live upgrade from last test to general release --------------------------------------------------------- This was agreed upon for Fedora 7 test 4 in QA meetings but we didn't actually announce it. It would encourage us to be more careful in pushing out any updates after the last test release and it would encourage more people to try it out the development branch and provide us feedback. Rahul From jwboyer at jdub.homelinux.org Sun Jun 3 18:45:10 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 03 Jun 2007 13:45:10 -0500 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4663093A.6040003@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <4663093A.6040003@fedoraproject.org> Message-ID: <1180896310.3218.38.camel@vader.jdub.homelinux.org> On Mon, 2007-06-04 at 00:02 +0530, Rahul Sundaram wrote: > Jesse Keating wrote: > > Below you will find a list of topics that we'd like to go over in the next > > RelEng meeting that is scheduled for tomorrow, Monday at 1700 UTC in > > #fedora-meeting on irc.freenode.org: > > > > /topic RELENG-Meeting - Rawhide spam-o-matic - JesseKeating > > > > /topic RELENG-Meeting - Updates Policy - JesseKeating > > > > /topic RELENG-Meeting - Freeze Policy - JesseKeating > > > > /topic RELENG-Meeting - Flesh out SOPs for rel-eng tasks - JesseKeating > > > > /topic RELENG-Meeting - Open Discussion > > > > 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 "Open > > Discussion" phase. > > I would like rel eng to discuss a few things > > Torrent only release > -------------------- > > I remember this was discussed before but when a new release is made and > we are waiting for the mirrors to sync why not do a torrent only release > immediately? For this release, it would have been particularly bad to release it before the mirrors had at least synced the new layout. People would instinctively have done 'yum update' and had yum report that it couldn't find repodata from the mirrors. (I know the RC release already had that problem but adding to it wouldn't have been good.) > The advantage is that we won't suffer as much from infrastructure and > mirror problems with the mad rush in everybody trying to get it at the > same time. Not sure if this has any disadvantages. There are other disadvantages. Like the fact that release can't happen until the proper things are filed with the Export office. Depending on when gold is declared and when it's filed, you might not be able to release anyway. It's worth discussion though. > > Supported live upgrade from last test to general release > --------------------------------------------------------- > > This was agreed upon for Fedora 7 test 4 in QA meetings but we didn't > actually announce it. It would encourage us to be more careful in > pushing out any updates after the last test release and it would > encourage more people to try it out the development branch and provide > us feedback. We tried very hard to fix the upgrade paths to do this. I'd like to see it possible. We just need all package maintainers to be on the same page here. josh From sundaram at fedoraproject.org Sun Jun 3 19:03:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 04 Jun 2007 00:33:36 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1180896310.3218.38.camel@vader.jdub.homelinux.org> References: <200706031108.23794.jkeating@redhat.com> <4663093A.6040003@fedoraproject.org> <1180896310.3218.38.camel@vader.jdub.homelinux.org> Message-ID: <46631088.5020808@fedoraproject.org> Josh Boyer wrote: > For this release, it would have been particularly bad to release it > before the mirrors had at least synced the new layout. People would > instinctively have done 'yum update' and had yum report that it couldn't > find repodata from the mirrors. > > (I know the RC release already had that problem but adding to it > wouldn't have been good.) Pup might give a more informative error or we could explain it better in a help button or something in general. This release indeed had the mirror layout change issue. This alone is not sufficient enough a reason to avoid doing torrent only initial releases in the future. > There are other disadvantages. Like the fact that release can't happen > until the proper things are filed with the Export office. Depending on > when gold is declared and when it's filed, you might not be able to > release anyway. I believe that we can't even send to mirrors without export approval and there is always some leaked mirrors where users grab the images earlier. On some occasions they have downloaded the wrong release. We could ease it out a bit by providing them a early path so that the enthusiasts would get things without saturating the mirrors. > We tried very hard to fix the upgrade paths to do this. I'd like to see > it possible. We just need all package maintainers to be on the same > page here. I would go further and like rel eng to consider enforcing strongly a proper update path for all packages from all releases to future ones including test releases. I don't want to lump a lot but there is a number of related issues here. A policy on using Epoch's (there are differing opinions currently ranging from "it's just a number" to "it's the mother of all evil's") would be useful. Are you considering disabling ACL's by default on all packages and letting package maintainer's explicitly request with proper reasons? Is rel eng, all sponsors and QA team allowed to fix EVR issues when necessary? Rahul From jwboyer at jdub.homelinux.org Sun Jun 3 19:19:12 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 03 Jun 2007 14:19:12 -0500 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <46631088.5020808@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <4663093A.6040003@fedoraproject.org> <1180896310.3218.38.camel@vader.jdub.homelinux.org> <46631088.5020808@fedoraproject.org> Message-ID: <1180898353.3218.47.camel@vader.jdub.homelinux.org> On Mon, 2007-06-04 at 00:33 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > > For this release, it would have been particularly bad to release it > > before the mirrors had at least synced the new layout. People would > > instinctively have done 'yum update' and had yum report that it couldn't > > find repodata from the mirrors. > > > > (I know the RC release already had that problem but adding to it > > wouldn't have been good.) > > Pup might give a more informative error or we could explain it better in > a help button or something in general. This release indeed had the > mirror layout change issue. This alone is not sufficient enough a reason > to avoid doing torrent only initial releases in the future. I didn't say it was. Just offering one potential example of something that might prevent early torrent release. > > There are other disadvantages. Like the fact that release can't happen > > until the proper things are filed with the Export office. Depending on > > when gold is declared and when it's filed, you might not be able to > > release anyway. > > I believe that we can't even send to mirrors without export approval and That is correct. However it still takes time to get the mirrors synced. If they don't even have the release directories available, you still have the update issue. > there is always some leaked mirrors where users grab the images earlier. > On some occasions they have downloaded the wrong release. We could ease > it out a bit by providing them a early path so that the enthusiasts > would get things without saturating the mirrors. Sure. And you snipped the part where I said it's worth discussion. I wouldn't release the torrents immediately, but rather wait at least a day from it being released to the mirrors. > > We tried very hard to fix the upgrade paths to do this. I'd like to see > > it possible. We just need all package maintainers to be on the same > > page here. > > I would go further and like rel eng to consider enforcing strongly a > proper update path for all packages from all releases to future ones > including test releases. Assuming FESCo approves such a guideline, I think that can be done. Overall, I think for F7 we did pretty well considering all the changes. The vast majority of packages we fixed up for F7 were simply ones that had a build sitting in koji that wasn't tagged with f7-final for one reason or another. There were only a handful of updates the last time I ran the report that truly had broken upgrade paths. > I don't want to lump a lot but there is a > number of related issues here. A policy on using Epoch's (there are > differing opinions currently ranging from "it's just a number" to "it's > the mother of all evil's") would be useful. Are you considering > disabling ACL's by default on all packages and letting package > maintainer's explicitly request with proper reasons? Is rel eng, all > sponsors and QA team allowed to fix EVR issues when necessary? That's a decision FESCo needs to make. It can be discussed at the rel-eng meeting, but that definitely falls into the realm of FESCo for a final approval. josh From lmacken at redhat.com Sun Jun 3 19:31:06 2007 From: lmacken at redhat.com (Luke Macken) Date: Sun, 3 Jun 2007 15:31:06 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070603101040.GG13318@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <20070602000704.GG4751@tomservo.rochester.rr.com> <27220.1180818385@sss.pgh.pa.us> <20070603101040.GG13318@tomservo.rochester.rr.com> Message-ID: <20070603193106.GH13318@tomservo.rochester.rr.com> On Sun, Jun 03, 2007 at 06:10:40AM -0400, Luke Macken wrote: > On Sat, Jun 02, 2007 at 05:06:25PM -0400, Tom Lane wrote: > > Luke Macken writes: > > > Once we agree on a policy, I can implement it. I've heard some people > > > suggest letting updates sit in testing for 7 days, and if there are no > > > complaints, then they can be pushed to the stable repo. This sounds > > > fine to me, what does everyone else think? > > > > zero-day security patches > > Security updates go straight to Stable already. ... but will soon require an approval from a member of the security team before they hit any repo. Core security updates currently require approval from the Red Hat security response team. With F7, it will require approval from a member of the Fedora security response team. luke From jwboyer at jdub.homelinux.org Sun Jun 3 19:32:29 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 03 Jun 2007 14:32:29 -0500 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070603193106.GH13318@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <20070602000704.GG4751@tomservo.rochester.rr.com> <27220.1180818385@sss.pgh.pa.us> <20070603101040.GG13318@tomservo.rochester.rr.com> <20070603193106.GH13318@tomservo.rochester.rr.com> Message-ID: <1180899149.3218.49.camel@vader.jdub.homelinux.org> On Sun, 2007-06-03 at 15:31 -0400, Luke Macken wrote: > On Sun, Jun 03, 2007 at 06:10:40AM -0400, Luke Macken wrote: > > On Sat, Jun 02, 2007 at 05:06:25PM -0400, Tom Lane wrote: > > > Luke Macken writes: > > > > Once we agree on a policy, I can implement it. I've heard some people > > > > suggest letting updates sit in testing for 7 days, and if there are no > > > > complaints, then they can be pushed to the stable repo. This sounds > > > > fine to me, what does everyone else think? > > > > > > zero-day security patches > > > > Security updates go straight to Stable already. > > ... but will soon require an approval from a member of the security team > before they hit any repo. Core security updates currently require > approval from the Red Hat security response team. With F7, it will > require approval from a member of the Fedora security response team. Erm... wait. Where (other than this email) was that discussed? josh From lmacken at redhat.com Sun Jun 3 19:49:04 2007 From: lmacken at redhat.com (Luke Macken) Date: Sun, 3 Jun 2007 15:49:04 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180899149.3218.49.camel@vader.jdub.homelinux.org> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <20070602000704.GG4751@tomservo.rochester.rr.com> <27220.1180818385@sss.pgh.pa.us> <20070603101040.GG13318@tomservo.rochester.rr.com> <20070603193106.GH13318@tomservo.rochester.rr.com> <1180899149.3218.49.camel@vader.jdub.homelinux.org> Message-ID: <20070603194904.GI13318@tomservo.rochester.rr.com> On Sun, Jun 03, 2007 at 02:32:29PM -0500, Josh Boyer wrote: > On Sun, 2007-06-03 at 15:31 -0400, Luke Macken wrote: > > On Sun, Jun 03, 2007 at 06:10:40AM -0400, Luke Macken wrote: > > > On Sat, Jun 02, 2007 at 05:06:25PM -0400, Tom Lane wrote: > > > > Luke Macken writes: > > > > > Once we agree on a policy, I can implement it. I've heard some people > > > > > suggest letting updates sit in testing for 7 days, and if there are no > > > > > complaints, then they can be pushed to the stable repo. This sounds > > > > > fine to me, what does everyone else think? > > > > > > > > zero-day security patches > > > > > > Security updates go straight to Stable already. > > > > ... but will soon require an approval from a member of the security team > > before they hit any repo. Core security updates currently require > > approval from the Red Hat security response team. With F7, it will > > require approval from a member of the Fedora security response team. > > Erm... wait. Where (other than this email) was that discussed? It was discussed between some members of the Fedora Security Response Team, and was suggested by the Team Lead, Josh Bressers. This approval mechanism has yet to be implemented in bodhi, and I think should require an ACK from the board/FESCo before it does. luke From jwboyer at jdub.homelinux.org Sun Jun 3 19:55:09 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 03 Jun 2007 14:55:09 -0500 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070603194904.GI13318@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <20070602000704.GG4751@tomservo.rochester.rr.com> <27220.1180818385@sss.pgh.pa.us> <20070603101040.GG13318@tomservo.rochester.rr.com> <20070603193106.GH13318@tomservo.rochester.rr.com> <1180899149.3218.49.camel@vader.jdub.homelinux.org> <20070603194904.GI13318@tomservo.rochester.rr.com> Message-ID: <1180900509.3218.52.camel@vader.jdub.homelinux.org> On Sun, 2007-06-03 at 15:49 -0400, Luke Macken wrote: > On Sun, Jun 03, 2007 at 02:32:29PM -0500, Josh Boyer wrote: > > On Sun, 2007-06-03 at 15:31 -0400, Luke Macken wrote: > > > On Sun, Jun 03, 2007 at 06:10:40AM -0400, Luke Macken wrote: > > > > On Sat, Jun 02, 2007 at 05:06:25PM -0400, Tom Lane wrote: > > > > > Luke Macken writes: > > > > > > Once we agree on a policy, I can implement it. I've heard some people > > > > > > suggest letting updates sit in testing for 7 days, and if there are no > > > > > > complaints, then they can be pushed to the stable repo. This sounds > > > > > > fine to me, what does everyone else think? > > > > > > > > > > zero-day security patches > > > > > > > > Security updates go straight to Stable already. > > > > > > ... but will soon require an approval from a member of the security team > > > before they hit any repo. Core security updates currently require > > > approval from the Red Hat security response team. With F7, it will > > > require approval from a member of the Fedora security response team. > > > > Erm... wait. Where (other than this email) was that discussed? > > It was discussed between some members of the Fedora Security > Response Team, and was suggested by the Team Lead, Josh Bressers. > > This approval mechanism has yet to be implemented in bodhi, and I think > should require an ACK from the board/FESCo before it does. Agreed. Thanks for the clarification Luke. Let's get this added to the FESCo schedule. Could Josh Bressers perhaps attend when it gets discussed? josh From wolfy at nobugconsulting.ro Sun Jun 3 20:04:56 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sun, 03 Jun 2007 23:04:56 +0300 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1180896310.3218.38.camel@vader.jdub.homelinux.org> References: <200706031108.23794.jkeating@redhat.com> <4663093A.6040003@fedoraproject.org> <1180896310.3218.38.camel@vader.jdub.homelinux.org> Message-ID: <46631EE8.8010208@nobugconsulting.ro> On 06/03/2007 09:45 PM, Josh Boyer wrote: >> Torrent only release >> -------------------- >> >> I remember this was discussed before but when a new release is made and >> we are waiting for the mirrors to sync why not do a torrent only release >> immediately? >> > > For this release, it would have been particularly bad to release it > before the mirrors had at least synced the new layout. People would > instinctively have done 'yum update' and had yum report that it couldn't > find repodata from the mirrors. > FWIW: I know tons of mirrors - even among those listed at http://mirrors.fedoraproject.org/publiclist - who are still not accessible due to the new layout. A torrent would have bypassed this problem. And yum update is still not accessible for those who - like me - are still at FC6. From jkeating at redhat.com Mon Jun 4 00:49:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Jun 2007 20:49:27 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4663093A.6040003@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <4663093A.6040003@fedoraproject.org> Message-ID: <200706032049.27378.jkeating@redhat.com> On Sunday 03 June 2007 14:32:26 Rahul Sundaram wrote: > Torrent only release > -------------------- > > I remember this was discussed before but when a new release is made and > we are waiting for the mirrors to sync why not do a torrent only release > immediately? > > The advantage is that we won't suffer as much from infrastructure and > mirror problems with the mad rush in everybody trying to get it at the > same time. Not sure if this has any disadvantages. IIRC the last time we discussed this the mirrors felt rather jilted by it and wondered why they provide a service and why they couldn't just open when they had the bits ready. We set a release date on purpose and coordinate things on purpose. Releasing parts earlier than others just doesn't make sense to me and creates a kind of chaos much less controlled than that of a timed and coordinated release. However I'll discuss it again with more people if you show up at the meeting to talk about it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Jun 4 05:21:52 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 4 Jun 2007 01:21:52 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4662E129.7030903@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <200706031111.22625.jkeating@redhat.com> <4662E129.7030903@leemhuis.info> Message-ID: <20070604052152.GA10087@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > Rough Example: Ship test3; get the tree release-ready for two or three > weeks later. Create the release directories on the servers and issue a > RC from them with ISOs. Spread them; if important bugs are found: Fix > them in a rolling release scheme. One or two weeks later issue the real > release and freeze the repos; all updates from now on get into the > update repo. Seems disruptive from a mirror standpoint - maybe as another entry under /test, but I'm not sure tht putting it in the final directory is a good idea. Bill From notting at redhat.com Mon Jun 4 05:23:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 4 Jun 2007 01:23:10 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070603152958.GA2912@free.fr> References: <200706031108.23794.jkeating@redhat.com> <20070603152958.GA2912@free.fr> Message-ID: <20070604052310.GB10087@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > > /topic RELENG-Meeting - Freeze Policy - JesseKeating > > On that topic, I think that during a freeze there shouldn't be a need to > mail to rel-eng to push to the frozen collection. It should be a > specific target, so for example to push to the frozen collection one > should do Mails allow for tracking, as opposed to polling a collection and trying to figure out who in rel-eng has or hasn't looked at that particular build. Bill From fedora at leemhuis.info Mon Jun 4 05:39:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 07:39:12 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070604052152.GA10087@nostromo.devel.redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706031111.22625.jkeating@redhat.com> <4662E129.7030903@leemhuis.info> <20070604052152.GA10087@nostromo.devel.redhat.com> Message-ID: <4663A580.5050309@leemhuis.info> On 04.06.2007 07:21, Bill Nottingham wrote: > Thorsten Leemhuis (fedora at leemhuis.info) said: >> Rough Example: Ship test3; get the tree release-ready for two or three >> weeks later. Create the release directories on the servers and issue a >> RC from them with ISOs. Spread them; if important bugs are found: Fix >> them in a rolling release scheme. One or two weeks later issue the real >> release and freeze the repos; all updates from now on get into the >> update repo. > Seems disruptive from a mirror standpoint Why precisely? The files in the release dir could simply be hardlinked to rawhide when the release directories gets created for the first time. Then the mirror should get them in some minutes without much pain. > [...] CU thl From notting at redhat.com Mon Jun 4 06:17:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 4 Jun 2007 02:17:39 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4663A580.5050309@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <200706031111.22625.jkeating@redhat.com> <4662E129.7030903@leemhuis.info> <20070604052152.GA10087@nostromo.devel.redhat.com> <4663A580.5050309@leemhuis.info> Message-ID: <20070604061739.GD10087@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > Why precisely? > > The files in the release dir could simply be hardlinked to rawhide when > the release directories gets created for the first time. Then the mirror > should get them in some minutes without much pain. The actual release trees are (at least by some mirrors) treated as a sync-once-then-ignore target. Moreover, you'll have to explain to those users why the stuff in /8 isn't actually F8... Bill From fedora at leemhuis.info Mon Jun 4 07:05:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 09:05:35 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070604061739.GD10087@nostromo.devel.redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706031111.22625.jkeating@redhat.com> <4662E129.7030903@leemhuis.info> <20070604052152.GA10087@nostromo.devel.redhat.com> <4663A580.5050309@leemhuis.info> <20070604061739.GD10087@nostromo.devel.redhat.com> Message-ID: <4663B9BF.604@leemhuis.info> On 04.06.2007 08:17, Bill Nottingham wrote: > Thorsten Leemhuis (fedora at leemhuis.info) said: >> Why precisely? >> The files in the release dir could simply be hardlinked to rawhide when >> the release directories gets created for the first time. Then the mirror >> should get them in some minutes without much pain. > The actual release trees are (at least by some mirrors) treated > as a sync-once-then-ignore target. Well, I suppose that could be changed if we really want to. > Moreover, you'll have to explain > to those users why the stuff in /8 isn't actually F8... True. But the repos are in place and users that install the F8-RC can just continue to use it and will get F8 automatically by running "yum update" -- that's what a lot of people want afaics. But there are likely other and better solutions to make that work. A F8-7.98 tree in the proper place for example that gets symlinked to the final tree for a while later, so users that run yum update get the final bits automatically, without adjusting their yum configuration. CU thl From Axel.Thimm at ATrpms.net Mon Jun 4 09:45:16 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 11:45:16 +0200 Subject: "Fedora Update System" makes comments into bugzilla and closes bugs Message-ID: <20070604094516.GD14907@neu.nirvana> which is just great! I didn't realize that the updates system had such a functionality, I thought the bugzillas and cves should just be referenced for humans! The updates system is getting so much bashing these days, am I the only one that really likes it? :=) (just a minor nitpicking if Luke's watching: the version's field in CLOSED/*RELEASE should include the release, not only the version field) -- 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 Mon Jun 4 09:55:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 11:55:48 +0200 Subject: "Fedora Update System" makes comments into bugzilla and closes bugs In-Reply-To: <20070604094516.GD14907@neu.nirvana> References: <20070604094516.GD14907@neu.nirvana> Message-ID: <20070604095548.GE14907@neu.nirvana> On Mon, Jun 04, 2007 at 11:45:16AM +0200, Axel Thimm wrote: > which is just great! > > I didn't realize that the updates system had such a functionality, I > thought the bugzillas and cves should just be referenced for humans! > > The updates system is getting so much bashing these days, am I the > only one that really likes it? :=) > > (just a minor nitpicking if Luke's watching: the version's field in > CLOSED/*RELEASE should include the release, not only the version > field) And maybe automatically set the bug in "NEEDINFO from Reporter" state when pushing to testing? :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Mon Jun 4 09:59:23 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 04 Jun 2007 11:59:23 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706031108.23794.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> Message-ID: <4663E27B.509@hhs.nl> Jesse Keating wrote: > Below you will find a list of topics that we'd like to go over in the next > RelEng meeting that is scheduled for tomorrow, Monday at 1700 UTC in > #fedora-meeting on irc.freenode.org: > > /topic RELENG-Meeting - Updates Policy - JesseKeating > I'm afraid I can't make it to the meeting as I have to work on 1900 hours CET, so here is my 2 cents with regards to updates: 1) I like the general concept of updates-testing, I think it is usefull! 2) however I don't believe it is always usefull. There is a balance which needs to be struck between getting fixes for serious/crasher bugs to users asap and between doing QA. Unfortunately this cycle we haven't done a mass rebuild, but for now lets assume we would have. Then the build environment for an update should be very much like the one in which the original package was build. So the chance of introducing regressions through build environment changes should be small. (and in my experience is small in general anyways). Thus if the changes to a package themselves are well overseeable and the bug fixes is a grave bug, then I think that the package maintainer should be able to shorten or even skip the time a package sits in updates-testing 3) Thus I would like to advocate the addition of an automatically push to updates in X days drop downlist to the update submission form, with preferably the option to set it to 0 days. The default should be something like 5 days I think 4) I know the plan is to let a QA time do QA and push packages from updates-testing to updates, when a package passes QA. However I believe we still very much need the default push after X days, because I believe that the QA team may not be able to cope with the load of updates no that former extras goes through the same path. For example currently there are 129 packages in updates-testing, which I think is too much for the QA team to handle in 5 workdays (but thats just my estimation, I might be wrong here). Regards, Hans From pertusus at free.fr Mon Jun 4 10:10:50 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 12:10:50 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070604052310.GB10087@nostromo.devel.redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070603152958.GA2912@free.fr> <20070604052310.GB10087@nostromo.devel.redhat.com> Message-ID: <20070604101050.GC2856@free.fr> On Mon, Jun 04, 2007 at 01:23:10AM -0400, Bill Nottingham wrote: > Patrice Dumas (pertusus at free.fr) said: > > > /topic RELENG-Meeting - Freeze Policy - JesseKeating > > > > On that topic, I think that during a freeze there shouldn't be a need to > > mail to rel-eng to push to the frozen collection. It should be a > > specific target, so for example to push to the frozen collection one > > should do > > Mails allow for tracking, as opposed to polling a collection and > trying to figure out who in rel-eng has or hasn't looked at that > particular build. If that's an issue, rel-eng people could post to a list what they think about a package, in any case there is no need fo r a mail from the maintainer, the 'tagging' (whatever it implies technically) is enough. -- Pat From dev at nigelj.com Mon Jun 4 10:40:12 2007 From: dev at nigelj.com (Nigel Jones) Date: Mon, 4 Jun 2007 22:40:12 +1200 (NZST) Subject: "Fedora Update System" makes comments into bugzilla and closes bugs In-Reply-To: <20070604095548.GE14907@neu.nirvana> References: <20070604094516.GD14907@neu.nirvana> <20070604095548.GE14907@neu.nirvana> Message-ID: <51365.202.154.148.243.1180953612.squirrel@webmail.nigelj.com> > On Mon, Jun 04, 2007 at 11:45:16AM +0200, Axel Thimm wrote: >> which is just great! >> >> I didn't realize that the updates system had such a functionality, I >> thought the bugzillas and cves should just be referenced for humans! >> >> The updates system is getting so much bashing these days, am I the >> only one that really likes it? :=) Your not the only one. Personally I have the odd issue with it, but I'm trusting that the 1.1 milestone (see the hosted.fp.o trac) will fill the gaps. >> >> (just a minor nitpicking if Luke's watching: the version's field in >> CLOSED/*RELEASE should include the release, not only the version >> field) That'd be useful > > And maybe automatically set the bug in "NEEDINFO from Reporter" state > when pushing to testing? :) Yes, that would be a good way to encourage people to test the packages (if they choose). On a side comment: I like the close/etc and the needinfo idea, but maybe set it as a per-maintainer or per-update preference? I'm just thinking about the maintainers that may wish to approach bugs different. Something like "Update specified bugs? Yes/Comment/No" (Yes - The works; Comment - Make comments to the bug but do not change statuses; No - Leave it alone) N.J. From Axel.Thimm at ATrpms.net Mon Jun 4 10:48:09 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 12:48:09 +0200 Subject: "Fedora Update System" makes comments into bugzilla and closes bugs In-Reply-To: <51365.202.154.148.243.1180953612.squirrel@webmail.nigelj.com> References: <20070604094516.GD14907@neu.nirvana> <20070604095548.GE14907@neu.nirvana> <51365.202.154.148.243.1180953612.squirrel@webmail.nigelj.com> Message-ID: <20070604104809.GH14907@neu.nirvana> On Mon, Jun 04, 2007 at 10:40:12PM +1200, Nigel Jones wrote: > > On Mon, Jun 04, 2007 at 11:45:16AM +0200, Axel Thimm wrote: > >> which is just great! > >> > >> I didn't realize that the updates system had such a functionality, I > >> thought the bugzillas and cves should just be referenced for humans! > >> > >> The updates system is getting so much bashing these days, am I the > >> only one that really likes it? :=) > Your not the only one. :) Let's create the "protect the updates system" campagne ;) > Personally I have the odd issue with it, What is the "odd issue"? The only thing I have on my wishlist is a pure CLI, but I'm sure it will be there at some point and it's not that painful to use the web either. > but I'm trusting that the 1.1 milestone (see the hosted.fp.o trac) > will fill the gaps. > >> > >> (just a minor nitpicking if Luke's watching: the version's field in > >> CLOSED/*RELEASE should include the release, not only the version > >> field) > That'd be useful > > > > And maybe automatically set the bug in "NEEDINFO from Reporter" state > > when pushing to testing? :) > Yes, that would be a good way to encourage people to test the packages (if > they choose). > > On a side comment: > I like the close/etc and the needinfo idea, but maybe set it as a > per-maintainer or per-update preference? I'm just thinking about the > maintainers that may wish to approach bugs different. Something like > "Update specified bugs? Yes/Comment/No" (Yes - The works; Comment - Make > comments to the bug but do not change statuses; No - Leave it alone) Yes, that would make sense, as surely people will think differently on their workflow and offering choice will bring more people to the "protect the updates system" campagne. ;) -- 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 dev at nigelj.com Mon Jun 4 11:08:13 2007 From: dev at nigelj.com (Nigel Jones) Date: Mon, 4 Jun 2007 23:08:13 +1200 (NZST) Subject: "Fedora Update System" makes comments into bugzilla and closes bugs In-Reply-To: <20070604104809.GH14907@neu.nirvana> References: <20070604094516.GD14907@neu.nirvana> <20070604095548.GE14907@neu.nirvana> <51365.202.154.148.243.1180953612.squirrel@webmail.nigelj.com> <20070604104809.GH14907@neu.nirvana> Message-ID: <51567.202.154.148.243.1180955293.squirrel@webmail.nigelj.com> > On Mon, Jun 04, 2007 at 10:40:12PM +1200, Nigel Jones wrote: >> > On Mon, Jun 04, 2007 at 11:45:16AM +0200, Axel Thimm wrote: >> >> which is just great! >> >> >> >> I didn't realize that the updates system had such a functionality, I >> >> thought the bugzillas and cves should just be referenced for humans! >> >> >> >> The updates system is getting so much bashing these days, am I the >> >> only one that really likes it? :=) >> Your not the only one. > > :) Let's create the "protect the updates system" campagne ;) "Save Koji NOW"? > >> Personally I have the odd issue with it, > > What is the "odd issue"? The only thing I have on my wishlist is a > pure CLI, but I'm sure it will be there at some point and it's not > that painful to use the web either. Things like "what on earth is the next step" and stuff like sorting based on coloum etc. But I'm not too concerned. The AJAX for completing the NVR is extremely handy though. > >> but I'm trusting that the 1.1 milestone (see the hosted.fp.o trac) >> will fill the gaps. > >> >> >> >> (just a minor nitpicking if Luke's watching: the version's field in >> >> CLOSED/*RELEASE should include the release, not only the version >> >> field) >> That'd be useful >> > >> > And maybe automatically set the bug in "NEEDINFO from Reporter" state >> > when pushing to testing? :) >> Yes, that would be a good way to encourage people to test the packages >> (if >> they choose). >> >> On a side comment: >> I like the close/etc and the needinfo idea, but maybe set it as a >> per-maintainer or per-update preference? I'm just thinking about the >> maintainers that may wish to approach bugs different. Something like >> "Update specified bugs? Yes/Comment/No" (Yes - The works; Comment - Make >> comments to the bug but do not change statuses; No - Leave it alone) > > Yes, that would make sense, as surely people will think differently on > their workflow and offering choice will bring more people to the > "protect the updates system" campagne. ;) I wasn't really thinking workflow wise, I was thinking more email traffic wise. Email #1 - Bug has been updated - Some random message that makes sense but you don't know what you have to do Email #2 - Bug has been updated - Personal response from dev asking you if you can test the update Into Email - Bug updated - "A fix is in the testing system, any chance you could test it for me here, and give me some feedback". But yes, I guess it also protects the workflow so to speak. > -- > Axel.Thimm at ATrpms.net > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From Axel.Thimm at ATrpms.net Mon Jun 4 12:42:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 14:42:28 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706031108.23794.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> Message-ID: <20070604124228.GA5034@neu.nirvana> On Sun, Jun 03, 2007 at 11:08:23AM -0400, Jesse Keating wrote: > /topic RELENG-Meeting - Freeze Policy - JesseKeating I would suggest to consider at least one full rebuild [1] before the final freeze (e.g. as part of the pre-freeze process) and of course to allow for enough time between the freeze and the GA to shake out any bugs that will surface by that process. [1] "full" = where it makes sense, e.g. not for pure data packages, firmwares and other parts that are really not affected by the build environment. -- 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 bpepple at fedoraproject.org Mon Jun 4 13:11:45 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 04 Jun 2007 09:11:45 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180900509.3218.52.camel@vader.jdub.homelinux.org> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <20070602000704.GG4751@tomservo.rochester.rr.com> <27220.1180818385@sss.pgh.pa.us> <20070603101040.GG13318@tomservo.rochester.rr.com> <20070603193106.GH13318@tomservo.rochester.rr.com> <1180899149.3218.49.camel@vader.jdub.homelinux.org> <20070603194904.GI13318@tomservo.rochester.rr.com> <1180900509.3218.52.camel@vader.jdub.homelinux.org> Message-ID: <1180962705.2883.2.camel@kennedy> On Sun, 2007-06-03 at 14:55 -0500, Josh Boyer wrote: > On Sun, 2007-06-03 at 15:49 -0400, Luke Macken wrote: > > On Sun, Jun 03, 2007 at 02:32:29PM -0500, Josh Boyer wrote: > > > On Sun, 2007-06-03 at 15:31 -0400, Luke Macken wrote: > > > > On Sun, Jun 03, 2007 at 06:10:40AM -0400, Luke Macken wrote: > > > > > On Sat, Jun 02, 2007 at 05:06:25PM -0400, Tom Lane wrote: > > > > > > Luke Macken writes: > > > > > > > Once we agree on a policy, I can implement it. I've heard some people > > > > > > > suggest letting updates sit in testing for 7 days, and if there are no > > > > > > > complaints, then they can be pushed to the stable repo. This sounds > > > > > > > fine to me, what does everyone else think? > > > > > > > > > > > > zero-day security patches > > > > > > > > > > Security updates go straight to Stable already. > > > > > > > > ... but will soon require an approval from a member of the security team > > > > before they hit any repo. Core security updates currently require > > > > approval from the Red Hat security response team. With F7, it will > > > > require approval from a member of the Fedora security response team. > > > > > > Erm... wait. Where (other than this email) was that discussed? > > > > It was discussed between some members of the Fedora Security > > Response Team, and was suggested by the Team Lead, Josh Bressers. > > > > This approval mechanism has yet to be implemented in bodhi, and I think > > should require an ACK from the board/FESCo before it does. > > Agreed. Thanks for the clarification Luke. > > Let's get this added to the FESCo schedule. Could Josh Bressers perhaps > attend when it gets discussed? Added to the schedule. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Jun 4 13:45:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 09:45:10 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070604124228.GA5034@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> Message-ID: <200706040945.10887.jkeating@redhat.com> On Monday 04 June 2007 08:42:28 Axel Thimm wrote: > I would suggest to consider at least one full rebuild [1] before the > final freeze (e.g. as part of the pre-freeze process) and of course to > allow for enough time between the freeze and the GA to shake out any > bugs that will surface by that process. > > [1] "full" = where it makes sense, e.g. not for pure data packages, > ? ? firmwares and other parts that are really not affected by the > ? ? build environment. Hasn't this been discussed over and over again within FESCo? I'd much prefer to make this a case by case basis per 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 bpepple at fedoraproject.org Mon Jun 4 14:00:52 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 04 Jun 2007 10:00:52 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070604124228.GA5034@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> Message-ID: <1180965652.2883.4.camel@kennedy> On Mon, 2007-06-04 at 14:42 +0200, Axel Thimm wrote: > On Sun, Jun 03, 2007 at 11:08:23AM -0400, Jesse Keating wrote: > > /topic RELENG-Meeting - Freeze Policy - JesseKeating > > I would suggest to consider at least one full rebuild [1] before the > final freeze (e.g. as part of the pre-freeze process) and of course to > allow for enough time between the freeze and the GA to shake out any > bugs that will surface by that process. This is on FESCo's schedule to discuss after F7 was released. 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 jkeating at redhat.com Mon Jun 4 14:00:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 10:00:51 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4663B9BF.604@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <20070604061739.GD10087@nostromo.devel.redhat.com> <4663B9BF.604@leemhuis.info> Message-ID: <200706041000.51209.jkeating@redhat.com> On Monday 04 June 2007 03:05:35 Thorsten Leemhuis wrote: > True. But the repos are in place and users that install the F8-RC can > just continue to use it and will get F8 automatically by running "yum > update" -- that's what a lot of people want afaics. But there are likely > other and better solutions to make that work. A F8-7.98 tree in the > proper place for example that gets symlinked to the final tree for a > while later, so users that run yum update get the final bits > automatically, without adjusting their yum configuration. The people that installed F7 RC2 had yum configs that once F7 released they could just yum update and get to F7 without adjusting any configs. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Jun 4 14:09:44 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 16:09:44 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706040945.10887.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <200706040945.10887.jkeating@redhat.com> Message-ID: <20070604140944.GD5034@neu.nirvana> On Mon, Jun 04, 2007 at 09:45:10AM -0400, Jesse Keating wrote: > On Monday 04 June 2007 08:42:28 Axel Thimm wrote: > > I would suggest to consider at least one full rebuild [1] before the > > final freeze (e.g. as part of the pre-freeze process) and of course to > > allow for enough time between the freeze and the GA to shake out any > > bugs that will surface by that process. > > > > [1] "full" = where it makes sense, e.g. not for pure data packages, > > ? ? firmwares and other parts that are really not affected by the > > ? ? build environment. > > Hasn't this been discussed over and over again within FESCo? I'd much prefer > to make this a case by case basis per release. Can this really be case by case? Or perhaps even from a different POV: If the distribution hasn't changed enough to warrant a rebuild of many packages (for example for F7 we already had 80-90% non-mass rebuilds anyway), then is it worth releasing? -- 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 Mon Jun 4 14:11:41 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 16:11:41 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1180965652.2883.4.camel@kennedy> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> Message-ID: <20070604141141.GE5034@neu.nirvana> On Mon, Jun 04, 2007 at 10:00:52AM -0400, Brian Pepple wrote: > On Mon, 2007-06-04 at 14:42 +0200, Axel Thimm wrote: > > On Sun, Jun 03, 2007 at 11:08:23AM -0400, Jesse Keating wrote: > > > /topic RELENG-Meeting - Freeze Policy - JesseKeating > > > > I would suggest to consider at least one full rebuild [1] before the > > final freeze (e.g. as part of the pre-freeze process) and of course to > > allow for enough time between the freeze and the GA to shake out any > > bugs that will surface by that process. > > This is on FESCo's schedule to discuss after F7 was released. Does that mean that releng needs to wait for fesco to first decide on that to develop a freezing strategy for F8 and beyond? Because having mass-rebuilds shortly before or as part of the freeze certainly offers two completely different scenarios to start from to discuss freezing at all. -- 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 sundaram at fedoraproject.org Mon Jun 4 14:13:44 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 04 Jun 2007 19:43:44 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1180965652.2883.4.camel@kennedy> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> Message-ID: <46641E18.6080806@fedoraproject.org> Brian Pepple wrote: > On Mon, 2007-06-04 at 14:42 +0200, Axel Thimm wrote: >> On Sun, Jun 03, 2007 at 11:08:23AM -0400, Jesse Keating wrote: >>> /topic RELENG-Meeting - Freeze Policy - JesseKeating >> I would suggest to consider at least one full rebuild [1] before the >> final freeze (e.g. as part of the pre-freeze process) and of course to >> allow for enough time between the freeze and the GA to shake out any >> bugs that will surface by that process. > > This is on FESCo's schedule to discuss after F7 was released. Note that this has caused mass confusion as I thought it would. It is not just about technical requirements. https://www.redhat.com/archives/fedora-list/2007-June/msg00048.html https://www.redhat.com/archives/fedora-list/2007-June/msg01017.html https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00016.html Another reason to consider doing rebuilds https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01171.html Rahul From Axel.Thimm at ATrpms.net Mon Jun 4 14:19:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 16:19:40 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4663E27B.509@hhs.nl> References: <200706031108.23794.jkeating@redhat.com> <4663E27B.509@hhs.nl> Message-ID: <20070604141940.GF5034@neu.nirvana> On Mon, Jun 04, 2007 at 11:59:23AM +0200, Hans de Goede wrote: > Unfortunately this cycle we haven't done a mass rebuild, but for > now lets assume we would have. Then the build environment for an > update should be very much like the one in which the original > package was build. So the chance of introducing regressions > through build environment changes should be small. (and in my > experience is small in general anyways). I'm for mass rebuilds at freeze time, I also tagged that on this thread, and I'm glad I see this parallel issue: Just to give an example of what happens w/o mass rebuilds (and it had to be one of my packages ... ): A rebuild of apt for a minor buglet lead to different names of apt's library because apt wants to embed glibc's version in its libs, so the update broke synaptic and anything else that would be dependent on apt (I'm glad this happens now in the updates-testing repo!). The decision of apt to code in glibc' version may be questionable, but it is there and I had never bumbed over it for the last 3-4 years, so it was also forgotten by me. But I don't want to have to think about which package may break if there is no mass-rebuild and a single rebuild later will find a completely changed environment. Just to add some more random rant on the decision to not mass-rebuild: It was said that the glibc didn't change from FC6 to F7, still stuuf like fakeroot (or fakechroot, I forget) break due to changes in chownat and friends (just try installing the FC6 version on F7). So even though developers/packagers etc. were guaranteeing that the build chain changes from FC6 to F7 did not require a package rebuild I'm experiencing quite the contrary. In a nutshell: We need a mass-rebuild at the end of the development cycle, immediately before the freezing! -- 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 ajackson at redhat.com Mon Jun 4 14:23:30 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 04 Jun 2007 10:23:30 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531000022.GA10430@nostromo.devel.redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> Message-ID: <1180967010.8453.23.camel@localhost.localdomain> On Wed, 2007-05-30 at 20:00 -0400, Bill Nottingham wrote: > Bodhi is now available for update submission at: > https://admin.fedoraproject.org/updates/ > > You'll need to log in with your FAS username/password. > > For more information on what bodhi is, and how to use it, see: > http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT I have no complaints here, I just want to say thanks. Bodhi looks like it'll be as much an improvement over the old updates system as brew was over beehive. In particular, the automatic display of package tags in the NEVR box means I owe someone a beer. That's just hot. - ajax From jwboyer at jdub.homelinux.org Mon Jun 4 14:30:43 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 04 Jun 2007 09:30:43 -0500 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070604141940.GF5034@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <4663E27B.509@hhs.nl> <20070604141940.GF5034@neu.nirvana> Message-ID: <1180967443.2978.2.camel@zod.rchland.ibm.com> On Mon, 2007-06-04 at 16:19 +0200, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 11:59:23AM +0200, Hans de Goede wrote: > > Unfortunately this cycle we haven't done a mass rebuild, but for > > now lets assume we would have. Then the build environment for an > > update should be very much like the one in which the original > > package was build. So the chance of introducing regressions > > through build environment changes should be small. (and in my > > experience is small in general anyways). > > I'm for mass rebuilds at freeze time, I also tagged that on this > thread, and I'm glad I see this parallel issue: Just to give an > example of what happens w/o mass rebuilds (and it had to be one of my > packages ... ): > > A rebuild of apt for a minor buglet lead to different names of apt's > library because apt wants to embed glibc's version in its libs, so the > update broke synaptic and anything else that would be dependent on > apt (I'm glad this happens now in the updates-testing repo!). > > The decision of apt to code in glibc' version may be questionable, but > it is there and I had never bumbed over it for the last 3-4 years, so > it was also forgotten by me. But I don't want to have to think about > which package may break if there is no mass-rebuild and a single > rebuild later will find a completely changed environment. > > Just to add some more random rant on the decision to not mass-rebuild: > It was said that the glibc didn't change from FC6 to F7, still stuuf > like fakeroot (or fakechroot, I forget) break due to changes in > chownat and friends (just try installing the FC6 version on F7). Wait... what? Who said glibc didn't change from FC6 to F7? josh From jkeating at redhat.com Mon Jun 4 14:33:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 10:33:51 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1180967443.2978.2.camel@zod.rchland.ibm.com> References: <200706031108.23794.jkeating@redhat.com> <20070604141940.GF5034@neu.nirvana> <1180967443.2978.2.camel@zod.rchland.ibm.com> Message-ID: <200706041033.51796.jkeating@redhat.com> On Monday 04 June 2007 10:30:43 Josh Boyer wrote: > Wait... what? ?Who said glibc didn't change from FC6 to F7? Jakub said that it didn't change enough to warrent rebuilding every compiled package against it, unlike between FC5 and FC6. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Mon Jun 4 14:41:04 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 04 Jun 2007 10:41:04 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070604141141.GE5034@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <20070604141141.GE5034@neu.nirvana> Message-ID: <1180968064.2883.21.camel@kennedy> On Mon, 2007-06-04 at 16:11 +0200, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 10:00:52AM -0400, Brian Pepple wrote: > > On Mon, 2007-06-04 at 14:42 +0200, Axel Thimm wrote: > > > On Sun, Jun 03, 2007 at 11:08:23AM -0400, Jesse Keating wrote: > > > > /topic RELENG-Meeting - Freeze Policy - JesseKeating > > > > > > I would suggest to consider at least one full rebuild [1] before the > > > final freeze (e.g. as part of the pre-freeze process) and of course to > > > allow for enough time between the freeze and the GA to shake out any > > > bugs that will surface by that process. > > > > This is on FESCo's schedule to discuss after F7 was released. > > Does that mean that releng needs to wait for fesco to first decide on > that to develop a freezing strategy for F8 and beyond? Because having > mass-rebuilds shortly before or as part of the freeze certainly offers > two completely different scenarios to start from to discuss freezing > at all. To develop a freezing strategy for releases? No. The plan is for FESCo to discuss whether any changes to the build toolchain warrants a mass rebuild. My guess is this would be sometime around T1 time probably. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Mon Jun 4 14:45:45 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 04 Jun 2007 10:45:45 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <46641E18.6080806@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> Message-ID: <1180968345.2883.25.camel@kennedy> On Mon, 2007-06-04 at 19:43 +0530, Rahul Sundaram wrote: > Brian Pepple wrote: > > On Mon, 2007-06-04 at 14:42 +0200, Axel Thimm wrote: > >> On Sun, Jun 03, 2007 at 11:08:23AM -0400, Jesse Keating wrote: > >>> /topic RELENG-Meeting - Freeze Policy - JesseKeating > >> I would suggest to consider at least one full rebuild [1] before the > >> final freeze (e.g. as part of the pre-freeze process) and of course to > >> allow for enough time between the freeze and the GA to shake out any > >> bugs that will surface by that process. > > > > This is on FESCo's schedule to discuss after F7 was released. > > Note that this has caused mass confusion as I thought it would. It is > not just about technical requirements. > > https://www.redhat.com/archives/fedora-list/2007-June/msg00048.html > https://www.redhat.com/archives/fedora-list/2007-June/msg01017.html > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00016.html Wasn't it the case that most of these folks didn't read the release notes? > > Another reason to consider doing rebuilds > > https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01171.html Did we ever get a list of the packages that were actually effected by this? /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 Axel.Thimm at ATrpms.net Mon Jun 4 14:58:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 16:58:10 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1180967443.2978.2.camel@zod.rchland.ibm.com> References: <200706031108.23794.jkeating@redhat.com> <4663E27B.509@hhs.nl> <20070604141940.GF5034@neu.nirvana> <1180967443.2978.2.camel@zod.rchland.ibm.com> Message-ID: <20070604145810.GH5034@neu.nirvana> On Mon, Jun 04, 2007 at 09:30:43AM -0500, Josh Boyer wrote: > On Mon, 2007-06-04 at 16:19 +0200, Axel Thimm wrote: > > On Mon, Jun 04, 2007 at 11:59:23AM +0200, Hans de Goede wrote: > > > Unfortunately this cycle we haven't done a mass rebuild, but for > > > now lets assume we would have. Then the build environment for an > > > update should be very much like the one in which the original > > > package was build. So the chance of introducing regressions > > > through build environment changes should be small. (and in my > > > experience is small in general anyways). > > > > I'm for mass rebuilds at freeze time, I also tagged that on this > > thread, and I'm glad I see this parallel issue: Just to give an > > example of what happens w/o mass rebuilds (and it had to be one of my > > packages ... ): > > > > A rebuild of apt for a minor buglet lead to different names of apt's > > library because apt wants to embed glibc's version in its libs, so the > > update broke synaptic and anything else that would be dependent on > > apt (I'm glad this happens now in the updates-testing repo!). > > > > The decision of apt to code in glibc' version may be questionable, but > > it is there and I had never bumbed over it for the last 3-4 years, so > > it was also forgotten by me. But I don't want to have to think about > > which package may break if there is no mass-rebuild and a single > > rebuild later will find a completely changed environment. > > > > Just to add some more random rant on the decision to not mass-rebuild: > > It was said that the glibc didn't change from FC6 to F7, still stuuf > > like fakeroot (or fakechroot, I forget) break due to changes in > > chownat and friends (just try installing the FC6 version on F7). > > Wait... what? Who said glibc didn't change from FC6 to F7? Check out http://www.redhat.com/archives/fedora-devel-list/2007-April/msg00909.html http://www.redhat.com/archives/fedora-devel-list/2007-April/msg00936.html -- 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 Mon Jun 4 15:01:44 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 17:01:44 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1180968064.2883.21.camel@kennedy> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <20070604141141.GE5034@neu.nirvana> <1180968064.2883.21.camel@kennedy> Message-ID: <20070604150144.GI5034@neu.nirvana> On Mon, Jun 04, 2007 at 10:41:04AM -0400, Brian Pepple wrote: > On Mon, 2007-06-04 at 16:11 +0200, Axel Thimm wrote: > > On Mon, Jun 04, 2007 at 10:00:52AM -0400, Brian Pepple wrote: > > > On Mon, 2007-06-04 at 14:42 +0200, Axel Thimm wrote: > > > > On Sun, Jun 03, 2007 at 11:08:23AM -0400, Jesse Keating wrote: > > > > > /topic RELENG-Meeting - Freeze Policy - JesseKeating > > > > > > > > I would suggest to consider at least one full rebuild [1] before the > > > > final freeze (e.g. as part of the pre-freeze process) and of course to > > > > allow for enough time between the freeze and the GA to shake out any > > > > bugs that will surface by that process. > > > > > > This is on FESCo's schedule to discuss after F7 was released. > > > > Does that mean that releng needs to wait for fesco to first decide on > > that to develop a freezing strategy for F8 and beyond? Because having > > mass-rebuilds shortly before or as part of the freeze certainly offers > > two completely different scenarios to start from to discuss freezing > > at all. > > To develop a freezing strategy for releases? No. The plan is for FESCo > to discuss whether any changes to the build toolchain warrants a mass > rebuild. My guess is this would be sometime around T1 time probably. The freezing strategy is releng's job. So releng would have to wait until test1 to know whether there will be a mass-rebuild to really discuss freezing? Also when scheduling F8 one needs to be aware whether there will be any mass-rebuilds to make sure the freezing test release has enough time before GA. So deciding when test1 will be may be depending on the decision you want to make at test1 time, sounds a bit like catch22. -- 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 sundaram at fedoraproject.org Mon Jun 4 15:14:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 04 Jun 2007 20:44:17 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1180968345.2883.25.camel@kennedy> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <1180968345.2883.25.camel@kennedy> Message-ID: <46642C49.7010001@fedoraproject.org> Brian Pepple wrote: > > Wasn't it the case that most of these folks didn't read the release > notes? I wrote the major content including this information but I can tell you that many people don't read the release notes. It serves the purpose in some places that I can use it to answer questions when asked. Regardless of the cause it is guaranteed to cause confusion. >> >> https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01171.html > > Did we ever get a list of the packages that were actually effected by > this? No. It kept changing till the last minute and very few people send in content. Rahul From bpepple at fedoraproject.org Mon Jun 4 15:18:30 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 04 Jun 2007 11:18:30 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070604150144.GI5034@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <20070604141141.GE5034@neu.nirvana> <1180968064.2883.21.camel@kennedy> <20070604150144.GI5034@neu.nirvana> Message-ID: <1180970310.2883.35.camel@kennedy> On Mon, 2007-06-04 at 17:01 +0200, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 10:41:04AM -0400, Brian Pepple wrote: > > On Mon, 2007-06-04 at 16:11 +0200, Axel Thimm wrote: > > > On Mon, Jun 04, 2007 at 10:00:52AM -0400, Brian Pepple wrote: > > > > > > > > This is on FESCo's schedule to discuss after F7 was released. > > > > > > Does that mean that releng needs to wait for fesco to first decide on > > > that to develop a freezing strategy for F8 and beyond? Because having > > > mass-rebuilds shortly before or as part of the freeze certainly offers > > > two completely different scenarios to start from to discuss freezing > > > at all. > > > > To develop a freezing strategy for releases? No. The plan is for FESCo > > to discuss whether any changes to the build toolchain warrants a mass > > rebuild. My guess is this would be sometime around T1 time probably. > > The freezing strategy is releng's job. So releng would have to wait > until test1 to know whether there will be a mass-rebuild to really > discuss freezing? Also when scheduling F8 one needs to be aware > whether there will be any mass-rebuilds to make sure the freezing test > release has enough time before GA And it's not possible for the rel-eng to plan for scenarios where we may or may not have mass rebuilds beforehand? /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 jwboyer at jdub.homelinux.org Mon Jun 4 15:11:44 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 04 Jun 2007 10:11:44 -0500 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070604145810.GH5034@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <4663E27B.509@hhs.nl> <20070604141940.GF5034@neu.nirvana> <1180967443.2978.2.camel@zod.rchland.ibm.com> <20070604145810.GH5034@neu.nirvana> Message-ID: <1180969904.2978.4.camel@zod.rchland.ibm.com> On Mon, 2007-06-04 at 16:58 +0200, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 09:30:43AM -0500, Josh Boyer wrote: > > On Mon, 2007-06-04 at 16:19 +0200, Axel Thimm wrote: > > > On Mon, Jun 04, 2007 at 11:59:23AM +0200, Hans de Goede wrote: > > > > Unfortunately this cycle we haven't done a mass rebuild, but for > > > > now lets assume we would have. Then the build environment for an > > > > update should be very much like the one in which the original > > > > package was build. So the chance of introducing regressions > > > > through build environment changes should be small. (and in my > > > > experience is small in general anyways). > > > > > > I'm for mass rebuilds at freeze time, I also tagged that on this > > > thread, and I'm glad I see this parallel issue: Just to give an > > > example of what happens w/o mass rebuilds (and it had to be one of my > > > packages ... ): > > > > > > A rebuild of apt for a minor buglet lead to different names of apt's > > > library because apt wants to embed glibc's version in its libs, so the > > > update broke synaptic and anything else that would be dependent on > > > apt (I'm glad this happens now in the updates-testing repo!). > > > > > > The decision of apt to code in glibc' version may be questionable, but > > > it is there and I had never bumbed over it for the last 3-4 years, so > > > it was also forgotten by me. But I don't want to have to think about > > > which package may break if there is no mass-rebuild and a single > > > rebuild later will find a completely changed environment. > > > > > > Just to add some more random rant on the decision to not mass-rebuild: > > > It was said that the glibc didn't change from FC6 to F7, still stuuf > > > like fakeroot (or fakechroot, I forget) break due to changes in > > > chownat and friends (just try installing the FC6 version on F7). > > > > Wait... what? Who said glibc didn't change from FC6 to F7? > > Check out > > http://www.redhat.com/archives/fedora-devel-list/2007-April/msg00909.html > http://www.redhat.com/archives/fedora-devel-list/2007-April/msg00936.html Ah, right. Sorry, I took "didn't change" too literally. Thanks for the links. josh From fedora at leemhuis.info Mon Jun 4 15:20:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 17:20:47 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <46641E18.6080806@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> Message-ID: <46642DCF.7040503@leemhuis.info> On 04.06.2007 16:13, Rahul Sundaram wrote: > Brian Pepple wrote: >> On Mon, 2007-06-04 at 14:42 +0200, Axel Thimm wrote: >>> On Sun, Jun 03, 2007 at 11:08:23AM -0400, Jesse Keating wrote: >>>> /topic RELENG-Meeting - Freeze Policy - JesseKeating >>> I would suggest to consider at least one full rebuild [1] before the >>> final freeze (e.g. as part of the pre-freeze process) and of course to >>> allow for enough time between the freeze and the GA to shake out any >>> bugs that will surface by that process. >> This is on FESCo's schedule to discuss after F7 was released. > Note that this has caused mass confusion as I thought it would. It is > not just about technical requirements. The idea to use ".1" as disstag for devel (discusses weeks ago) still stands. The idea in short: x.1 is higher then x.fc7 and avoid the confusion if a package doesn't get rebuild during a devel cycle; and if there later is a update after releases x simply gets increased -- so there would no need to got for "x.2". I can outline the idea further if anybody is interested. Cu thl From bugs.michael at gmx.net Mon Jun 4 15:26:37 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Jun 2007 17:26:37 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4663E27B.509@hhs.nl> References: <200706031108.23794.jkeating@redhat.com> <4663E27B.509@hhs.nl> Message-ID: <20070604172637.67192a66.bugs.michael@gmx.net> On Mon, 04 Jun 2007 11:59:23 +0200, Hans de Goede wrote: > Unfortunately this cycle we haven't done a mass rebuild, but It's not unfortunate. It's great that packages, which work in FC6, don't need a rebuild and continue to work in F7. For several binaries the opposite is true, and you can install fc7 packages also for fc6. I don't like superfluous rebuilds or rebuilds which result in cosmetic changes only, such as an updated dist tag. For every rebuild there ought to be a good reason and a visible and worthwhile goal for the package, plus a packager who verifies the build results. There are problems in some packages, which are not fixed by automatic rebuilds and which are not found by automatic rebuilds either. Instead of a mass-rebuild I'd prefer a roadmap, so that after some clear and strict freeze there won't be any unexpected modifications anymore, such as API/ABI breaks. Planning-safety for packagers to know till when to prepare their packages. All the testing with rawhide and test releases is void when we test static packages, which are rebuilt automatically just for fun, and shortly after the final release of the distribution, packagers get active and push major version upgrades and stuff that breaks dependencies. From fedora at leemhuis.info Mon Jun 4 15:24:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 17:24:15 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706041000.51209.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070604061739.GD10087@nostromo.devel.redhat.com> <4663B9BF.604@leemhuis.info> <200706041000.51209.jkeating@redhat.com> Message-ID: <46642E9F.40208@leemhuis.info> On 04.06.2007 16:00, Jesse Keating wrote: > On Monday 04 June 2007 03:05:35 Thorsten Leemhuis wrote: >> True. But the repos are in place and users that install the F8-RC can >> just continue to use it and will get F8 automatically by running "yum >> update" -- that's what a lot of people want afaics. But there are likely >> other and better solutions to make that work. A F8-7.98 tree in the >> proper place for example that gets symlinked to the final tree for a >> while later, so users that run yum update get the final bits >> automatically, without adjusting their yum configuration. > The people that installed F7 RC2 had yum configs that once F7 released they > could just yum update and get to F7 without adjusting any configs. Sure -- but if the tree would have been online then people would have been able to test "Everything" and not just what the installer put on the harddisk from "Fedora". And I assume that's what we want ;-) CU thl From jkeating at redhat.com Mon Jun 4 15:27:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 11:27:18 -0400 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <46642DCF.7040503@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> Message-ID: <200706041127.21999.jkeating@redhat.com> On Monday 04 June 2007 11:20:47 Thorsten Leemhuis wrote: > The idea to use ".1" as disstag for devel (discusses weeks ago) still > stands. > > The idea in short: x.1 is higher then x.fc7 and avoid the confusion if a > package doesn't get rebuild during a devel cycle; and if there later is > a update after releases x simply gets increased -- so there would no > need to got for "x.2". > > I can outline the idea further if anybody is interested. I'm really really against playing games with dist tags like this. Just for the record. -- 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 Jun 4 15:27:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 11:27:48 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <46642E9F.40208@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <200706041000.51209.jkeating@redhat.com> <46642E9F.40208@leemhuis.info> Message-ID: <200706041127.49091.jkeating@redhat.com> On Monday 04 June 2007 11:24:15 Thorsten Leemhuis wrote: > Sure -- but if the tree would have been online then people would have > been able to test "Everything" and not just what the installer put on > the harddisk from "Fedora". And I assume that's what we want ;-) "Everything" was rawhide. -- 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 Jun 4 15:28:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 11:28:55 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070604172637.67192a66.bugs.michael@gmx.net> References: <200706031108.23794.jkeating@redhat.com> <4663E27B.509@hhs.nl> <20070604172637.67192a66.bugs.michael@gmx.net> Message-ID: <200706041128.55644.jkeating@redhat.com> On Monday 04 June 2007 11:26:37 Michael Schwendt wrote: > It's not unfortunate. It's great that packages, which work in FC6, don't > need a rebuild and continue to work in F7. For several binaries the > opposite is true, and you can install fc7 packages also for fc6. I don't > like superfluous rebuilds or rebuilds which result in cosmetic changes > only, such as an updated dist tag. For every rebuild there ought to be a > good reason and a visible and worthwhile goal for the package, plus a > packager who verifies the build results. > > There are problems in some packages, which are not fixed by automatic > rebuilds and which are not found by automatic rebuilds either. Instead > of a mass-rebuild I'd prefer a roadmap, so that after some clear and > strict freeze there won't be any unexpected modifications anymore, such > as API/ABI breaks. Planning-safety for packagers to know till when to > prepare their packages. > > All the testing with rawhide and test releases is void when we test > static packages, which are rebuilt automatically just for fun, and > shortly after the final release of the distribution, packagers get > active and push major version upgrades and stuff that breaks > dependencies. +10. Thank you Micheal for putting my thoughts into a clear email. -- 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 mclasen at redhat.com Mon Jun 4 15:30:41 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 04 Jun 2007 11:30:41 -0400 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <200706041127.21999.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> Message-ID: <1180971041.3573.8.camel@dhcp83-186.boston.redhat.com> On Mon, 2007-06-04 at 11:27 -0400, Jesse Keating wrote: > On Monday 04 June 2007 11:20:47 Thorsten Leemhuis wrote: > > The idea to use ".1" as disstag for devel (discusses weeks ago) still > > stands. > > > > The idea in short: x.1 is higher then x.fc7 and avoid the confusion if a > > package doesn't get rebuild during a devel cycle; and if there later is > > a update after releases x simply gets increased -- so there would no > > need to got for "x.2". > > > > I can outline the idea further if anybody is interested. > > I'm really really against playing games with dist tags like this. Just for > the record. > I thought this had been thoroughly shot down already ? From Axel.Thimm at ATrpms.net Mon Jun 4 15:39:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 17:39:28 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1180970310.2883.35.camel@kennedy> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <20070604141141.GE5034@neu.nirvana> <1180968064.2883.21.camel@kennedy> <20070604150144.GI5034@neu.nirvana> <1180970310.2883.35.camel@kennedy> Message-ID: <20070604153928.GB15001@neu.nirvana> On Mon, Jun 04, 2007 at 11:18:30AM -0400, Brian Pepple wrote: > On Mon, 2007-06-04 at 17:01 +0200, Axel Thimm wrote: > > On Mon, Jun 04, 2007 at 10:41:04AM -0400, Brian Pepple wrote: > > > On Mon, 2007-06-04 at 16:11 +0200, Axel Thimm wrote: > > > > On Mon, Jun 04, 2007 at 10:00:52AM -0400, Brian Pepple wrote: > > > > > > > > > > This is on FESCo's schedule to discuss after F7 was released. > > > > > > > > Does that mean that releng needs to wait for fesco to first decide on > > > > that to develop a freezing strategy for F8 and beyond? Because having > > > > mass-rebuilds shortly before or as part of the freeze certainly offers > > > > two completely different scenarios to start from to discuss freezing > > > > at all. > > > > > > To develop a freezing strategy for releases? No. The plan is for FESCo > > > to discuss whether any changes to the build toolchain warrants a mass > > > rebuild. My guess is this would be sometime around T1 time probably. > > > > The freezing strategy is releng's job. So releng would have to wait > > until test1 to know whether there will be a mass-rebuild to really > > discuss freezing? Also when scheduling F8 one needs to be aware > > whether there will be any mass-rebuilds to make sure the freezing test > > release has enough time before GA > > And it's not possible for the rel-eng to plan for scenarios where we may > or may not have mass rebuilds beforehand? Sure, people on rel-eng are smart enough. If this decision _really needs_ to be postponed they don't have another choice. But I don't think that looking at test1 would improve discussion grounds. It won't look better than F7 looked in comparison to FC6 and slowly more and more people are recognizing that the lack of a final mass-rebuild was more pain than gain. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Jun 4 15:45:06 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 17:45:06 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <1180971041.3573.8.camel@dhcp83-186.boston.redhat.com> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <1180971041.3573.8.camel@dhcp83-186.boston.redhat.com> Message-ID: <46643382.3010305@leemhuis.info> On 04.06.2007 17:30, Matthias Clasen wrote: > On Mon, 2007-06-04 at 11:27 -0400, Jesse Keating wrote: >> On Monday 04 June 2007 11:20:47 Thorsten Leemhuis wrote: >>> The idea to use ".1" as disstag for devel (discusses weeks ago) still >>> stands. >>> The idea in short: x.1 is higher then x.fc7 and avoid the confusion if a >>> package doesn't get rebuild during a devel cycle; and if there later is >>> a update after releases x simply gets increased -- so there would no >>> need to got for "x.2". >>> I can outline the idea further if anybody is interested. >> I'm really really against playing games with dist tags like this. Just for >> the record. /me would prefer to have a more detailed answer... But well, not that important. I don't care that much about that idea, but I think it could nicely solve the problems at hand. > I thought this had been thoroughly shot down already ? No, it was agreed on to let FESCo revisit that after F7 is out. CU thl From fedora at leemhuis.info Mon Jun 4 15:46:39 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 17:46:39 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706041128.55644.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <4663E27B.509@hhs.nl> <20070604172637.67192a66.bugs.michael@gmx.net> <200706041128.55644.jkeating@redhat.com> Message-ID: <466433DF.9030505@leemhuis.info> On 04.06.2007 17:28, Jesse Keating wrote: > On Monday 04 June 2007 11:26:37 Michael Schwendt wrote: >> It's not unfortunate. It's great that packages, which work in FC6, don't >> need a rebuild and continue to work in F7. For several binaries the >> opposite is true, and you can install fc7 packages also for fc6. I don't >> like superfluous rebuilds or rebuilds which result in cosmetic changes >> only, such as an updated dist tag. For every rebuild there ought to be a >> good reason and a visible and worthwhile goal for the package, plus a >> packager who verifies the build results. >> >> There are problems in some packages, which are not fixed by automatic >> rebuilds and which are not found by automatic rebuilds either. Instead >> of a mass-rebuild I'd prefer a roadmap, so that after some clear and >> strict freeze there won't be any unexpected modifications anymore, such >> as API/ABI breaks. Planning-safety for packagers to know till when to >> prepare their packages. >> >> All the testing with rawhide and test releases is void when we test >> static packages, which are rebuilt automatically just for fun, and >> shortly after the final release of the distribution, packagers get >> active and push major version upgrades and stuff that breaks >> dependencies. > > +10. Thank you Micheal for putting my thoughts into a clear email. +1 from my side as well CU thl From fedora at leemhuis.info Mon Jun 4 15:47:27 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 17:47:27 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706041127.49091.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706041000.51209.jkeating@redhat.com> <46642E9F.40208@leemhuis.info> <200706041127.49091.jkeating@redhat.com> Message-ID: <4664340F.9070401@leemhuis.info> On 04.06.2007 17:27, Jesse Keating wrote: > On Monday 04 June 2007 11:24:15 Thorsten Leemhuis wrote: >> Sure -- but if the tree would have been online then people would have >> been able to test "Everything" and not just what the installer put on >> the harddisk from "Fedora". And I assume that's what we want ;-) > "Everything" was rawhide. ...which could not be used by testers of RC1 without modifying repo files. CU thl From jkeating at redhat.com Mon Jun 4 15:46:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 11:46:39 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4664340F.9070401@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <200706041127.49091.jkeating@redhat.com> <4664340F.9070401@leemhuis.info> Message-ID: <200706041146.39641.jkeating@redhat.com> On Monday 04 June 2007 11:47:27 Thorsten Leemhuis wrote: > ...which could not be used by testers of RC1 without modifying repo files. You're not going to get it both ways. If you can't manage to do --enable development or fiddle with a repo file to enable a repo, are you really going to be providing valuable feedback at an RC level? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon Jun 4 15:51:22 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 04 Jun 2007 21:21:22 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706041146.39641.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706041127.49091.jkeating@redhat.com> <4664340F.9070401@leemhuis.info> <200706041146.39641.jkeating@redhat.com> Message-ID: <466434FA.9010002@fedoraproject.org> Jesse Keating wrote: > On Monday 04 June 2007 11:47:27 Thorsten Leemhuis wrote: >> ...which could not be used by testers of RC1 without modifying repo files. > > You're not going to get it both ways. If you can't manage to do --enable > development or fiddle with a repo file to enable a repo, are you really going > to be providing valuable feedback at an RC level? I can manage to fiddle with repository files but I would prefer not to. Rahul From jkeating at redhat.com Mon Jun 4 15:54:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 11:54:51 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <466434FA.9010002@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <200706041146.39641.jkeating@redhat.com> <466434FA.9010002@fedoraproject.org> Message-ID: <200706041154.51507.jkeating@redhat.com> On Monday 04 June 2007 11:51:22 Rahul Sundaram wrote: > I can manage to fiddle with repository files but I would prefer not to. Then don't. yum --enable development install -- 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 Mon Jun 4 15:59:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 17:59:47 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706041146.39641.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706041127.49091.jkeating@redhat.com> <4664340F.9070401@leemhuis.info> <200706041146.39641.jkeating@redhat.com> Message-ID: <466436F3.7070401@leemhuis.info> On 04.06.2007 17:46, Jesse Keating wrote: > On Monday 04 June 2007 11:47:27 Thorsten Leemhuis wrote: >> ...which could not be used by testers of RC1 without modifying repo files. > You're not going to get it both ways. Well, this thread had the idea to split "rawhide" and "release" trees a bit earlier. And that requires you have rawhide and "what becomes Everything" in seperate repos. Those things interact. CU thl From sundaram at fedoraproject.org Mon Jun 4 16:02:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 04 Jun 2007 21:32:08 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706041154.51507.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706041146.39641.jkeating@redhat.com> <466434FA.9010002@fedoraproject.org> <200706041154.51507.jkeating@redhat.com> Message-ID: <46643780.7000303@fedoraproject.org> Jesse Keating wrote: > On Monday 04 June 2007 11:51:22 Rahul Sundaram wrote: >> I can manage to fiddle with repository files but I would prefer not to. > > Then don't. yum --enable development install I don't think you understand the point being made. If someone installs the RC version and wants to continue to yum update and get the general version the current process does not make it easy and many people don't understand the development repository changes and continue to run yum update and get the next version changes instead. Thorsten's suggestion would help with this problem. Rahul From jkeating at redhat.com Mon Jun 4 16:03:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 12:03:58 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <46643780.7000303@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <200706041154.51507.jkeating@redhat.com> <46643780.7000303@fedoraproject.org> Message-ID: <200706041203.58789.jkeating@redhat.com> On Monday 04 June 2007 12:02:08 Rahul Sundaram wrote: > I don't think you understand the point being made. If someone installs > the RC version and wants to continue to yum update and get the general > version the current process does not make it easy and many people don't > understand the development repository changes and continue to run yum > update and get the next version changes instead. > > Thorsten's suggestion would help with this problem. If someone installs the RC version and they just want to get to the Final version when it's released, they do nothing except 'yum update' when the final version is released. Anything else is pre-releasing stuff and even _more_ confusion as to what is /really/ the release and when the release date actually is. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Jun 4 16:10:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 18:10:25 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <200706041127.21999.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> Message-ID: <20070604161025.GC15001@neu.nirvana> On Mon, Jun 04, 2007 at 11:27:18AM -0400, Jesse Keating wrote: > On Monday 04 June 2007 11:20:47 Thorsten Leemhuis wrote: > > The idea to use ".1" as disstag for devel (discusses weeks ago) still > > stands. > > > > The idea in short: x.1 is higher then x.fc7 and avoid the confusion if a > > package doesn't get rebuild during a devel cycle; and if there later is > > a update after releases x simply gets increased -- so there would no > > need to got for "x.2". > > > > I can outline the idea further if anybody is interested. > > I'm really really against playing games with dist tags like this. Just for > the record. And it's just replacing .fc8, .fc9 with .1, .2, not really helpful. Not to mention that it breaks all dotted releases. -- 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 tcallawa at redhat.com Mon Jun 4 16:14:51 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 04 Jun 2007 11:14:51 -0500 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <20070604161025.GC15001@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> Message-ID: <1180973691.6254.633.camel@localhost.localdomain> On Mon, 2007-06-04 at 18:10 +0200, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 11:27:18AM -0400, Jesse Keating wrote: > > On Monday 04 June 2007 11:20:47 Thorsten Leemhuis wrote: > > > The idea to use ".1" as disstag for devel (discusses weeks ago) still > > > stands. > > > > > > The idea in short: x.1 is higher then x.fc7 and avoid the confusion if a > > > package doesn't get rebuild during a devel cycle; and if there later is > > > a update after releases x simply gets increased -- so there would no > > > need to got for "x.2". > > > > > > I can outline the idea further if anybody is interested. > > > > I'm really really against playing games with dist tags like this. Just for > > the record. > > And it's just replacing .fc8, .fc9 with .1, .2, not really > helpful. Not to mention that it breaks all dotted releases. FWIW, I'm pretty solidly against this as well. I'm not against a pre-final-freeze, scheduled mass rebuild of devel. I think that would solve the "omg, my disttags look old" fears and catch some minor issues. Is it redundant for some packages? Yep. Does it hurt those packages to be rebuilt automagically once during the cycle? No. Does it help us catch broken packages before final freeze? Yes. Does it help identify AWOL maintainers? Yes. Does it catch subtle API breaks? Yes. Does it provide a tree consistency waterline test? Yes. (e.g. I built my package in devel a long time ago, all the underlying libs have changed, it doesn't build anymore, do we want to ship it like that?) Its not perfection, but I see the value in it, and the only downside is builder cpu-cycles and disk space. It also solves the dist-tag mismatch issue as a bonus. ~spot From fedora at leemhuis.info Mon Jun 4 16:20:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 18:20:12 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604161025.GC15001@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> Message-ID: <46643BBC.40609@leemhuis.info> On 04.06.2007 18:10, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 11:27:18AM -0400, Jesse Keating wrote: >> On Monday 04 June 2007 11:20:47 Thorsten Leemhuis wrote: >>> The idea to use ".1" as disstag for devel (discusses weeks ago) still >>> stands. >>> The idea in short: x.1 is higher then x.fc7 and avoid the confusion if a >>> package doesn't get rebuild during a devel cycle; and if there later is >>> a update after releases x simply gets increased -- so there would no >>> need to got for "x.2". >>> I can outline the idea further if anybody is interested. >> I'm really really against playing games with dist tags like this. Just for >> the record. > And it's just replacing .fc8, .fc9 with .1, .2, not really > helpful. Not to mention that it breaks all dotted releases. No. As I wrote (and you quoted it; see above): "so there would no need to got for "x.2". Cu thl From bpepple at fedoraproject.org Mon Jun 4 16:21:37 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 04 Jun 2007 12:21:37 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070604172637.67192a66.bugs.michael@gmx.net> References: <200706031108.23794.jkeating@redhat.com> <4663E27B.509@hhs.nl> <20070604172637.67192a66.bugs.michael@gmx.net> Message-ID: <1180974097.2883.36.camel@kennedy> On Mon, 2007-06-04 at 17:26 +0200, Michael Schwendt wrote: > On Mon, 04 Jun 2007 11:59:23 +0200, Hans de Goede wrote: > > > Unfortunately this cycle we haven't done a mass rebuild, but > > It's not unfortunate. It's great that packages, which work in FC6, don't > need a rebuild and continue to work in F7. For several binaries the > opposite is true, and you can install fc7 packages also for fc6. I don't > like superfluous rebuilds or rebuilds which result in cosmetic changes > only, such as an updated dist tag. For every rebuild there ought to be a > good reason and a visible and worthwhile goal for the package, plus a > packager who verifies the build results. > > There are problems in some packages, which are not fixed by automatic > rebuilds and which are not found by automatic rebuilds either. Instead > of a mass-rebuild I'd prefer a roadmap, so that after some clear and > strict freeze there won't be any unexpected modifications anymore, such > as API/ABI breaks. Planning-safety for packagers to know till when to > prepare their packages. > > All the testing with rawhide and test releases is void when we test > static packages, which are rebuilt automatically just for fun, and > shortly after the final release of the distribution, packagers get > active and push major version upgrades and stuff that breaks > dependencies. +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 Axel.Thimm at ATrpms.net Mon Jun 4 16:56:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 18:56:21 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <46643BBC.40609@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> Message-ID: <20070604165621.GA18693@neu.nirvana> On Mon, Jun 04, 2007 at 06:20:12PM +0200, Thorsten Leemhuis wrote: > On 04.06.2007 18:10, Axel Thimm wrote: > > On Mon, Jun 04, 2007 at 11:27:18AM -0400, Jesse Keating wrote: > >> On Monday 04 June 2007 11:20:47 Thorsten Leemhuis wrote: > >>> The idea to use ".1" as disstag for devel (discusses weeks ago) still > >>> stands. > >>> The idea in short: x.1 is higher then x.fc7 and avoid the confusion if a > >>> package doesn't get rebuild during a devel cycle; and if there later is > >>> a update after releases x simply gets increased -- so there would no > >>> need to got for "x.2". > >>> I can outline the idea further if anybody is interested. > >> I'm really really against playing games with dist tags like this. Just for > >> the record. > > And it's just replacing .fc8, .fc9 with .1, .2, not really > > helpful. Not to mention that it breaks all dotted releases. > > No. As I wrote (and you quoted it; see above): "so there would no > need to got for "x.2". You either have F9 go ".2" (if F8 is ".1") or you would had killed the usefulness of disttags altogether, so either way it's broken. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Jun 4 17:11:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 19:11:14 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604165621.GA18693@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> <20070604165621.GA18693@neu.nirvana> Message-ID: <466447B2.1070105@leemhuis.info> On 04.06.2007 18:56, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 06:20:12PM +0200, Thorsten Leemhuis wrote: >> On 04.06.2007 18:10, Axel Thimm wrote: >>> On Mon, Jun 04, 2007 at 11:27:18AM -0400, Jesse Keating wrote: >>>> On Monday 04 June 2007 11:20:47 Thorsten Leemhuis wrote: >>>>> The idea to use ".1" as disstag for devel (discusses weeks ago) still >>>>> stands. >>>>> The idea in short: x.1 is higher then x.fc7 and avoid the confusion if a >>>>> package doesn't get rebuild during a devel cycle; and if there later is >>>>> a update after releases x simply gets increased -- so there would no >>>>> need to got for "x.2". >>>>> I can outline the idea further if anybody is interested. >>>> I'm really really against playing games with dist tags like this. Just for >>>> the record. >>> And it's just replacing .fc8, .fc9 with .1, .2, not really >>> helpful. Not to mention that it breaks all dotted releases. >> No. As I wrote (and you quoted it; see above): "so there would no >> need to got for "x.2". > You either have F9 go ".2" (if F8 is ".1") or you would had killed the > usefulness of disttags altogether, so either way it's broken. No, you don't have to. It can stay at ".1" forever; if you update something for devel and/or a release distribution just increase the portion left of the disttag -- that's what we do in any case. /me more and more gets the feeling people don't understand what I'm up to; of I'm really missing something here. CU knurd From Axel.Thimm at ATrpms.net Mon Jun 4 17:12:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 19:12:59 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070604172637.67192a66.bugs.michael@gmx.net> References: <200706031108.23794.jkeating@redhat.com> <4663E27B.509@hhs.nl> <20070604172637.67192a66.bugs.michael@gmx.net> Message-ID: <20070604171259.GB18693@neu.nirvana> On Mon, Jun 04, 2007 at 05:26:37PM +0200, Michael Schwendt wrote: > On Mon, 04 Jun 2007 11:59:23 +0200, Hans de Goede wrote: > > > Unfortunately this cycle we haven't done a mass rebuild, but > > It's not unfortunate. It's great that packages, which work in FC6, don't > need a rebuild and continue to work in F7. Sure, if it would be that easy to setup this requirement. It's the typical difference of theory and practice. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 4 17:14:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 13:14:36 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <466447B2.1070105@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> Message-ID: <200706041314.36216.jkeating@redhat.com> On Monday 04 June 2007 13:11:14 Thorsten Leemhuis wrote: > /me more and more gets the feeling people don't understand what I'm up > to; of I'm really missing something here. Show some examples then, flowing form rawhide to release to next rawhide, with bump releases in between. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Jun 4 17:20:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 19:20:43 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <466447B2.1070105@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> Message-ID: <20070604172043.GC18693@neu.nirvana> On Mon, Jun 04, 2007 at 07:11:14PM +0200, Thorsten Leemhuis wrote: > On 04.06.2007 18:56, Axel Thimm wrote: > > On Mon, Jun 04, 2007 at 06:20:12PM +0200, Thorsten Leemhuis wrote: > >> On 04.06.2007 18:10, Axel Thimm wrote: > >>> On Mon, Jun 04, 2007 at 11:27:18AM -0400, Jesse Keating wrote: > >>>> On Monday 04 June 2007 11:20:47 Thorsten Leemhuis wrote: > >>>>> The idea to use ".1" as disstag for devel (discusses weeks ago) still > >>>>> stands. > >>>>> The idea in short: x.1 is higher then x.fc7 and avoid the confusion if a > >>>>> package doesn't get rebuild during a devel cycle; and if there later is > >>>>> a update after releases x simply gets increased -- so there would no > >>>>> need to got for "x.2". > >>>>> I can outline the idea further if anybody is interested. > >>>> I'm really really against playing games with dist tags like this. Just for > >>>> the record. > >>> And it's just replacing .fc8, .fc9 with .1, .2, not really > >>> helpful. Not to mention that it breaks all dotted releases. > >> No. As I wrote (and you quoted it; see above): "so there would no > >> need to got for "x.2". > > You either have F9 go ".2" (if F8 is ".1") or you would had killed the > > usefulness of disttags altogether, so either way it's broken. > > No, you don't have to. It can stay at ".1" forever; if you update > something for devel and/or a release distribution just increase the > portion left of the disttag -- that's what we do in any case. which is just the same as not having any disttags at all and led to the pain before the disttag. > /me more and more gets the feeling people don't understand what I'm up > to; of I'm really missing something here. /me thinks you should just fast forward to F9 and try to submit a package with your model to see what's wrong. /me also thinks you should start testing release ids of "1.1" vs "1" to id some more flaws in this. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Jun 4 17:36:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 19:36:37 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <200706041314.36216.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> <200706041314.36216.jkeating@redhat.com> Message-ID: <46644DA5.9010602@leemhuis.info> On 04.06.2007 19:14, Jesse Keating wrote: > On Monday 04 June 2007 13:11:14 Thorsten Leemhuis wrote: >> /me more and more gets the feeling people don't understand what I'm up >> to; of I'm really missing something here. > Show some examples then, flowing form rawhide to release to next rawhide, with > bump releases in between. Let's say we introduced that ".1" disttag some months ago: 20070415 - FC-6: foo-1.0-1.fc6 - rawhide: foo-1.0-1.1 (Note that ".1" is higher than ".fc6" in rpm ENVR comparisons afaics) 20070515 - rebuild in devel - FC-6: foo-1.0-1.fc6 (unchanged) - rawhide: foo-1.0-2.1 20070531 - F-7 release - FC-6: foo-1.0-1.fc6 (unchanged) - F-7: foo-1.0-2.1 (copied from rawhide) - rawhide: foo-1.0-2.1 (Note that F-7 and rawhide have the same package now, but that's normal and would have happened with a disttag "fc7" as well ) 20070631 - new upstream release - FC-6: foo-1.1-1.fc6 - F-7: foo-1.1-1.fc7 - rawhide: foo-1.1-1.1 20070815 - mass rebuild in rawhide - FC-6: foo-1.1-1.fc6 (unchanged) - F-7: foo-1.1-1.fc7 (unchanged) - rawhide: foo-1.1-2.1 20071031 - F-8 release - FC-6: foo-1.1-1.fc6 (unchanged) - F-7: foo-1.1-1.fc7 (unchanged) - F-8: foo-1.1-2.1 (copied from rawhide) - rawhide: foo-1.1-2.1 20071130 - rebuild in rawhide against a dep - FC-6: foo-1.1-1.fc6 (unchanged) - F-7: foo-1.1-1.fc7 (unchanged) - F-8: foo-1.1-2.1 (unchanged) - rawhide: foo-1.1-3.1 (Note that relase of ".3" is higher then ".2") Makes more sense now? CU thl From fedora at leemhuis.info Mon Jun 4 17:40:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 19:40:28 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604172043.GC18693@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> <20070604172043.GC18693@neu.nirvana> Message-ID: <46644E8C.1090602@leemhuis.info> On 04.06.2007 19:20, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 07:11:14PM +0200, Thorsten Leemhuis wrote: >> On 04.06.2007 18:56, Axel Thimm wrote: > [...] >> /me more and more gets the feeling people don't understand what I'm up >> to; of I'm really missing something here. > /me thinks you should just fast forward to F9 and try to submit a > package with your model to see what's wrong. Could you please use the example I gave in reply to Jesse to show me "what's wrong"? > /me also thinks you should start testing release ids of "1.1" vs "1" to > id some more flaws in this. What are you up to? "1.1" is of course higher then ".1" CU thl From bugs.michael at gmx.net Mon Jun 4 17:45:03 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Jun 2007 19:45:03 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <1180973691.6254.633.camel@localhost.localdomain> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <1180973691.6254.633.camel@localhost.localdomain> Message-ID: <20070604194503.0939b6c2.bugs.michael@gmx.net> On Mon, 04 Jun 2007 11:14:51 -0500, Tom "spot" Callaway wrote: > I'm not against a pre-final-freeze, scheduled mass rebuild of devel. I > think that would solve the "omg, my disttags look old" fears and catch > some minor issues. > > Is it redundant for some packages? Yep. > Does it hurt those packages to be rebuilt automagically once during the > cycle? No. > Does it help us catch broken packages before final freeze? Yes. Does it bear the risk of producing new breakage? Yes. (for lots of packages, features are dropped silently when configure tests fail) > Does it help identify AWOL maintainers? Yes. No. Or do you refer to a rebuild performed by the maintainers? An automatic mass-rebuild does not involve the maintainers at all. It would be different if the maintainers were asked to update/rebuild their packages prior to a deadline. Only that would request a sign of life. Preferably the maintainers participate in the devel cycle and don't wait with updates/upgrades until the final release. From tcallawa at redhat.com Mon Jun 4 17:45:07 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 04 Jun 2007 12:45:07 -0500 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <20070604194503.0939b6c2.bugs.michael@gmx.net> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <1180973691.6254.633.camel@localhost.localdomain> <20070604194503.0939b6c2.bugs.michael@gmx.net> Message-ID: <1180979107.6254.638.camel@localhost.localdomain> On Mon, 2007-06-04 at 19:45 +0200, Michael Schwendt wrote: > On Mon, 04 Jun 2007 11:14:51 -0500, Tom "spot" Callaway wrote: > > > I'm not against a pre-final-freeze, scheduled mass rebuild of devel. I > > think that would solve the "omg, my disttags look old" fears and catch > > some minor issues. > > > > Is it redundant for some packages? Yep. > > Does it hurt those packages to be rebuilt automagically once during the > > cycle? No. > > Does it help us catch broken packages before final freeze? Yes. > > Does it bear the risk of producing new breakage? Yes. > (for lots of packages, features are dropped silently when > configure tests fail) These are things that need to be fixed. We can either find out that they're broken or just hide from them. By having this on a set schedule, then asking maintainers (and QA) to test the mass-rebuild resulting packages, we'll find these things and fix them. > An automatic mass-rebuild does not involve the maintainers at all. No, but really broken packages help identify AWOL maintainers. Admittedly, the lucky AWOL maintainers whose packages keep building as is forever and ever will not be caught by this. > It would be different if the maintainers were asked to update/rebuild > their packages prior to a deadline. Only that would request a sign of > life. I thought about this, but it wouldn't ensure proper ordering between packages. Packager A rebuilds after Package B is done, but changes to Package A affect Package B's build. ~spot From bugs.michael at gmx.net Mon Jun 4 17:57:33 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Jun 2007 19:57:33 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604172043.GC18693@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> <20070604172043.GC18693@neu.nirvana> Message-ID: <20070604195733.d8caef1d.bugs.michael@gmx.net> On Mon, 4 Jun 2007 19:20:43 +0200, Axel Thimm wrote: > > No, you don't have to. It can stay at ".1" forever; if you update > > something for devel and/or a release distribution just increase the > > portion left of the disttag -- that's what we do in any case. > > which is just the same as not having any disttags at all and led to > the pain before the disttag. It's painless. Package is only updated when somebody maintains it. The longer it isn't touched by any maintainer, the older its timestamp gets, and old %dist tags in the filename can be spotted easily. On the contrary, unattended rebuilds cause pain and try to push unmaintained packages under the carpet. [...] As a side-note, I've understood thl's hack, but I don't like it for cosmetical reasons and because of the fact that it compares alpha-numerical dist tags with "1" which sounds wrong to me. It also opens the door to accidental and superfluous builds for "Released Updates", since a "make tag build" would tag and rebuild an unchanged package with the changed %dist. In short: 1.0-3.fc7 => 1.0-3.1 (forced rebuild with %dist changed at beginning of F8 devel cycle) => 1.0-3.fc8 (accidental make tag build after F8 release) Perhaps koji already rejects such requests, but EVR problem checkers won't recognise that 1.0-3.1 in F9 devel is out-of-sync with F8 Released Updates, since 1 > fc8, and overall, this hack with %dist has potential for more confusion than I like. All that only to change filenames? =:-O From fedora at leemhuis.info Mon Jun 4 18:11:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Jun 2007 20:11:14 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604195733.d8caef1d.bugs.michael@gmx.net> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> <20070604172043.GC18693@neu.nirvana> <20070604195733.d8caef1d.bugs.michael@gmx.net> Message-ID: <466455C2.2030807@leemhuis.info> On 04.06.2007 19:57, Michael Schwendt wrote: > On Mon, 4 Jun 2007 19:20:43 +0200, Axel Thimm wrote: > [...] > As a side-note, I've understood thl's hack, but I don't like it for > cosmetical reasons Well, it fixes cosmetical reasons ;-) > and because of the fact that it compares alpha-numerical > dist tags with "1" which sounds wrong to me. Yes, you have a point there. But *for me* the benefits overweight the "sounds wrong to me" part. > It also opens the door to accidental and superfluous builds for "Released > Updates", since a "make tag build" would tag and rebuild an unchanged > package with the changed %dist. In short: 1.0-3.fc7 => 1.0-3.1 (forced > rebuild with %dist changed at beginning of F8 devel cycle) => 1.0-3.fc8 > (accidental make tag build after F8 release) Well, yes, that could happen. But I think that's a corner case. if the maintainer runs "make tag" then he has a reason to -- e.g. he changed something. And when he changes something he should always update release left of %{?dist}. > Perhaps koji already rejects such requests, Don't think so. > but EVR problem checkers won't recognise that 1.0-3.1 in F9 > devel is out-of-sync with F8 Released Updates, since 1 > fc8, Well, that's afaics a general problem if somebody tries to build something in updates that has a lower %{release} as in the released repo. > [...] CU knurd (who still often types thl here...) From bugs.michael at gmx.net Mon Jun 4 18:21:33 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Jun 2007 20:21:33 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <1180979107.6254.638.camel@localhost.localdomain> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <1180973691.6254.633.camel@localhost.localdomain> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> Message-ID: <20070604202133.bc15071e.bugs.michael@gmx.net> On Mon, 04 Jun 2007 12:45:07 -0500, Tom "spot" Callaway wrote: > > It would be different if the maintainers were asked to update/rebuild > > their packages prior to a deadline. Only that would request a sign of > > life. > > I thought about this, but it wouldn't ensure proper ordering between > packages. Packager A rebuilds after Package B is done, but changes to > Package A affect Package B's build. It always does. In the past, our mass-rebuilds (whether partial or complete) have never been in the correct order. Scenario during devel cycle: libfoo is updated, built and published app based on libfoo is updated, built and published ... libfoo version upgrade is prepared in cvs, build fails (!) ... some of libfoo's build requirements are upgraded and published, or libfoo's packager has checked in a first set of patches, but no build request yet ... mass-rebuild: app based on libfoo is rebuilt successfully libfoo (the unpublished stuff in cvs) is rebuilt and published successfully => let's hope it breaks the app into many shiny pieces that are spotted easily You might argue that the mass-rebuild would only rebuild published src.rpms and never files from within cvs, oh well, ... From jkeating at redhat.com Mon Jun 4 18:15:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 14:15:58 -0400 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <1180979107.6254.638.camel@localhost.localdomain> References: <200706031108.23794.jkeating@redhat.com> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> Message-ID: <200706041415.58247.jkeating@redhat.com> On Monday 04 June 2007 13:45:07 Tom "spot" Callaway wrote: > I thought about this, but it wouldn't ensure proper ordering between > packages. Packager A rebuilds after Package B is done, but changes to > Package A affect Package B's build. How would a mass rebuild be any different? A mass rebuild is likely to go through in either ls ordering or python hash ordering.... -- 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 nicolas.mailhot at laposte.net Mon Jun 4 18:19:54 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 04 Jun 2007 20:19:54 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706041128.55644.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <4663E27B.509@hhs.nl> <20070604172637.67192a66.bugs.michael@gmx.net> <200706041128.55644.jkeating@redhat.com> Message-ID: <1180981194.15415.35.camel@rousalka.dyndns.org> Le lundi 04 juin 2007 ? 11:28 -0400, Jesse Keating a ?crit : > On Monday 04 June 2007 11:26:37 Michael Schwendt wrote: > > All the testing with rawhide and test releases is void when we test > > static packages, which are rebuilt automatically just for fun, and > > shortly after the final release of the distribution, packagers get > > active and push major version upgrades and stuff that breaks > > dependencies. > > +10. Thank you Micheal for putting my thoughts into a clear email. The breaker here is not the hypothetical pre-freeze rebuild but packagers that do not distinguish between releases and push new stuff everywhere indiscriminately (instead of reserving major upgrades for fedora-devel, and letting users enjoy the painfully-stabilised release) -- 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 lemenkov at gmail.com Mon Jun 4 18:24:36 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Mon, 4 Jun 2007 22:24:36 +0400 Subject: No sound on PowerPC Mac Mini after upgrading from fc6 to Fedora7 Message-ID: Hello All! I tried to modprode snd-aoa, to rmmod snd-powermac and vice versa, to rename any snd-powermac in /etc/modprobe to snd-aoa, to start kudzu, to stop kudzu but with zero success. Then I did ls /dev/snd I saw only seq and timer. Ok, I gave up - I have no idea how to enable sound after upgrading from FC6 to F7. Could anyone powerpc-guru point me out what should I try? [root at Sulaco ~]# lsmod Module Size Used by snd_aoa_soundbus 7908 0 radeon 141928 2 drm 94680 3 radeon nfs 287180 4 lockd 75224 2 nfs nfs_acl 4000 1 nfs sunrpc 195616 4 nfs,lockd,nfs_acl arc4 1952 2 ecb 3904 2 blkcipher 7364 1 ecb rc80211_simple 5120 1 bcm43xx_mac80211 421132 0 ssb 41540 1 bcm43xx_mac80211 mac80211 159752 2 rc80211_simple,bcm43xx_mac80211 cfg80211 9936 1 mac80211 sungem 34948 0 sungem_phy 12896 1 sungem ipv6 309644 24 dm_mirror 24596 0 dm_mod 67148 1 dm_mirror snd_aoa 20736 0 snd_seq_dummy 4036 0 snd_seq_oss 40308 0 snd_seq_midi_event 8064 1 snd_seq_oss snd_seq 60576 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event snd_seq_device 9548 3 snd_seq_dummy,snd_seq_oss,snd_seq snd_pcm_oss 53328 0 snd_mixer_oss 20896 1 snd_pcm_oss snd_pcm 91876 1 snd_pcm_oss snd_timer 26116 2 snd_seq,snd_pcm snd 68692 8 snd_aoa,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer soundcore 8900 1 snd snd_page_alloc 11336 1 snd_pcm parport_pc 41524 0 lp 14864 0 parport 43632 2 parport_pc,lp loop 20232 0 ext3 153416 2 jbd 68456 1 ext3 mbcache 9700 1 ext3 ehci_hcd 37868 0 ohci_hcd 36324 0 uhci_hcd 33328 0 [root at Sulaco ~]# ls /dev/snd seq timer [root at Sulaco ~]# alsamixer alsamixer: function snd_ctl_open failed for default: No such device [root at Sulaco ~]# -- With best regards! From jkeating at redhat.com Mon Jun 4 18:26:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 14:26:31 -0400 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <20070604202133.bc15071e.bugs.michael@gmx.net> References: <200706031108.23794.jkeating@redhat.com> <1180979107.6254.638.camel@localhost.localdomain> <20070604202133.bc15071e.bugs.michael@gmx.net> Message-ID: <200706041426.31484.jkeating@redhat.com> On Monday 04 June 2007 14:21:33 Michael Schwendt wrote: > You might argue that the mass-rebuild would only rebuild published src.rpms > and never files from within cvs, oh well, ... Or even then, do you wait for every built package to re-show up in the buildroots? IE waiting 20~ minutes between each and every build? If it's scripted you get libfoo and libbar building at the same exact time, with libfoo using the /old/ version of libbar. Both complete and now you have new libfoo and new libbar in the repo, but the new libfoo wasn't actually built against the new libbar and you've solved 0 problems. -- 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 Mon Jun 4 18:36:08 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 04 Jun 2007 14:36:08 -0400 Subject: Bodhi updates-testing Autopush, Anonymous Commenting Message-ID: <46645B98.70001@redhat.com> This thread contains only strawman ideas to solicit ideas and opinions for Bodhi. NOTE: This mail talks only about how updates-testing tickets in bodhi behave after they become updates-testing. The controversial matter of whether a package is required to go into updates-testing is a separate matter to be discussed and ratified during Thursday's FESCo meeting. Idea: updates-testing Autopush after Timeout ============================================ 1) Bodhi should auto-push updates-testing after a time-out period. 2) Bodhi interface allows others to comment on the goodness/badness of a test update. 3) Bodhi interface allows others to declare a test update broken, which freezes the auto-push after timeout. 4) Package maintainer or admins can override this and push anyway. Idea: Timeout Default, Configurable? ==================================== Default updates-testing timeout is 7 days. Package maintainer may set a different timeout period (i.e. 4, 9 or 14 days), or turn off the timeout entirely. Idea: Anonymous Commenting ========================== Update and updates-testing announcement mail will have links to the Bodhi ticket where users can comment on their experiences with that package. This should do good to improve communications between users and developers, and also be handy for users to know more details about the effect an updated package will have on their system. (Perhaps not a link to the Bodhi ticket, but a separate comment-and-view URL... lmacken can decide on this as an implementation detail.) Currently commenting on an update in bodhi requires you to have a FAS account, which can be inconvenient for the majority of Fedora users. We could potentially allow more convenient commenting to the public through some other means. http://en.wikipedia.org/wiki/Captcha Users not authenticated through FAS are given the option to type in a CAPTCHA string, which allows them to comment without authenticating. A CAPTCHA should be sufficient to control spam. Warren Togami wtogami at redhat.com From Axel.Thimm at ATrpms.net Mon Jun 4 18:45:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 20:45:55 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <46644E8C.1090602@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> <20070604172043.GC18693@neu.nirvana> <46644E8C.1090602@leemhuis.info> Message-ID: <20070604184555.GE18693@neu.nirvana> On Mon, Jun 04, 2007 at 07:40:28PM +0200, Thorsten Leemhuis wrote: > On 04.06.2007 19:20, Axel Thimm wrote: > > On Mon, Jun 04, 2007 at 07:11:14PM +0200, Thorsten Leemhuis wrote: > >> On 04.06.2007 18:56, Axel Thimm wrote: > > [...] > >> /me more and more gets the feeling people don't understand what I'm up > >> to; of I'm really missing something here. > > /me thinks you should just fast forward to F9 and try to submit a > > package with your model to see what's wrong. > > Could you please use the example I gave in reply to Jesse to show me > "what's wrong"? Where is the new package submission that wants to use the same specfile for F8/F9 and devel? Not possible anymore? That's the catch. As said, your proposal is just a disguised way back to not using disttags at all. Why bother having a ".1" then at all? > > /me also thinks you should start testing release ids of "1.1" vs "1" to > > id some more flaws in this. > > What are you up to? "1.1" is of course higher then ".1" I'm not talking disttags, but minor fixes in the buildid as in = choosing a disttag that start with letters was designed that way see the discussion during FC1. E.g. now kernel-1.2.3-4.EL5, small fix or simple rebuild (like your EPEL rebuild) => kernel-1.2.3-4.0.1.EL5 in your model kernel-1.2.3-4.1, => kernel-1.2.3-4.0.1.1 => broken upgrade paths. -- 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 Mon Jun 4 18:50:41 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 20:50:41 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604195733.d8caef1d.bugs.michael@gmx.net> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> <20070604172043.GC18693@neu.nirvana> <20070604195733.d8caef1d.bugs.michael@gmx.net> Message-ID: <20070604185041.GF18693@neu.nirvana> On Mon, Jun 04, 2007 at 07:57:33PM +0200, Michael Schwendt wrote: > On Mon, 4 Jun 2007 19:20:43 +0200, Axel Thimm wrote: > > > > No, you don't have to. It can stay at ".1" forever; if you update > > > something for devel and/or a release distribution just increase the > > > portion left of the disttag -- that's what we do in any case. > > > > which is just the same as not having any disttags at all and led to > > the pain before the disttag. > > It's painless. Package is only updated when somebody maintains it. We hope all packages are maintained. :) Just introduce a package into FC6 and F7. And then have a security update. You start juggling around with reserving build tags like foo-1.2.3-1 (fc6) foo-1.2.3-2 (f7) fix: foo-1.2.3-3 (fc6) foo-1.2.3-4 (f7) "Hey", some people cry in the background, "we still have fc5 maintained", "please push it to fc5 as well". "Sorry, no integers left anymore" "Hey", the RHEL users say, "what about packages for us?" "Ar, em, I need to go home now, see ya!" It's manual, error-prone and doesn't scale, neither with releases, nor with dists. That's what I call pain. -- 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 Mon Jun 4 18:56:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 20:56:27 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <1180979107.6254.638.camel@localhost.localdomain> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <1180973691.6254.633.camel@localhost.localdomain> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> Message-ID: <20070604185627.GG18693@neu.nirvana> On Mon, Jun 04, 2007 at 12:45:07PM -0500, Tom spot Callaway wrote: > On Mon, 2007-06-04 at 19:45 +0200, Michael Schwendt wrote: > > On Mon, 04 Jun 2007 11:14:51 -0500, Tom "spot" Callaway wrote: > > > > > I'm not against a pre-final-freeze, scheduled mass rebuild of devel. I > > > think that would solve the "omg, my disttags look old" fears and catch > > > some minor issues. > > > > > > Is it redundant for some packages? Yep. > > > Does it hurt those packages to be rebuilt automagically once during the > > > cycle? No. > > > Does it help us catch broken packages before final freeze? Yes. > > > > Does it bear the risk of producing new breakage? Yes. You need to take a firm standpoint, Michael, either the packages are not broken and a rebuild won't break them, or they are and a rebuild to uncover this is needed. :) > > (for lots of packages, features are dropped silently when > > configure tests fail) > > These are things that need to be fixed. We can either find out that > they're broken or just hide from them. By having this on a set > schedule, then asking maintainers (and QA) to test the mass-rebuild > resulting packages, we'll find these things and fix them. +1000^1000 > > An automatic mass-rebuild does not involve the maintainers at all. > > No, but really broken packages help identify AWOL maintainers. > Admittedly, the lucky AWOL maintainers whose packages keep building as > is forever and ever will not be caught by this. > > > It would be different if the maintainers were asked to update/rebuild > > their packages prior to a deadline. Only that would request a sign of > > life. > > I thought about this, but it wouldn't ensure proper ordering between > packages. Packager A rebuilds after Package B is done, but changes to > Package A affect Package B's build. The mass rebuilds won't place that in order either, but: If the people against mass rebuilds argue that ordering is an issue, e.g. building A against the old B will fail or give a broken result, then ordering is the least to worry about. The ordering is not an issue if the rebuild happens twice and the first set of packages are thrown away. Kind of bootstrapo convergence. Rebuild early, rebuild often ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 4 18:56:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 14:56:46 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604184555.GE18693@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <46644E8C.1090602@leemhuis.info> <20070604184555.GE18693@neu.nirvana> Message-ID: <200706041456.50473.jkeating@redhat.com> On Monday 04 June 2007 14:45:55 Axel Thimm wrote: > kernel-1.2.3-4.EL5, small fix or simple rebuild (like your EPEL rebuild) > ? => kernel-1.2.3-4.0.1.EL5 Actually we have to put the bump after dist tag or else there will be upgrade path breakage. foo-1.2-2.fc6 foo-1.2-2.fc7 Need to rebuild the fc6 one for a minor build problem that doesn't effect F7: foo-1.2-2.fc6.1 foo-1.2-2.fc7 Otherwise fc6 would have become "newer" than the fc7 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 ruben at rubenkerkhof.com Mon Jun 4 19:08:59 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Mon, 4 Jun 2007 21:08:59 +0200 Subject: Merge Review Message-ID: <9C08CEDE-D7F8-4F13-BA09-6C2C70F1343F@rubenkerkhof.com> Hi all, Now that Fedora 7 is out the door, I'd like to ask what the plans are for the big Merge Review. There are still a lot of unassigned tickets, and I think all the people working on the Review since january (thanks!) could use some help. Maybe we can do another Review Day before F-8? I would also like to now what to do with the tickets flagged with a +. Now that Core and Extras are merged, can we close them? Kind regards, Ruben Kerkhof From pertusus at free.fr Mon Jun 4 19:16:16 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 21:16:16 +0200 Subject: Merge Review In-Reply-To: <9C08CEDE-D7F8-4F13-BA09-6C2C70F1343F@rubenkerkhof.com> References: <9C08CEDE-D7F8-4F13-BA09-6C2C70F1343F@rubenkerkhof.com> Message-ID: <20070604191616.GB2831@free.fr> On Mon, Jun 04, 2007 at 09:08:59PM +0200, Ruben Kerkhof wrote: > Hi all, > > Now that Fedora 7 is out the door, I'd like to ask what the plans are > for the big Merge Review. > There are still a lot of unassigned tickets, and I think all the > people working on the Review since january (thanks!) could use some > help. Unassigned tickets may be in review nevertheless. In some tickets the next move should be from the maintainer, but indeed there are many merge review bugs that are not reviewed. > I would also like to now what to do with the tickets flagged with a > +. Now that Core and Extras are merged, can we close them? Unless I am forgetting something, they should be closed (and if I recall well RAWHIDE was proposed as a state for closing). -- Pat From Axel.Thimm at ATrpms.net Mon Jun 4 19:10:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 21:10:01 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <200706041456.50473.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <46644E8C.1090602@leemhuis.info> <20070604184555.GE18693@neu.nirvana> <200706041456.50473.jkeating@redhat.com> Message-ID: <20070604191001.GJ18693@neu.nirvana> On Mon, Jun 04, 2007 at 02:56:46PM -0400, Jesse Keating wrote: > On Monday 04 June 2007 14:45:55 Axel Thimm wrote: > > kernel-1.2.3-4.EL5, small fix or simple rebuild (like your EPEL rebuild) > > ? => kernel-1.2.3-4.0.1.EL5 > > Actually we have to put the bump after dist tag or else there will be upgrade > path breakage. Well, the above is actual practice in RHEL3, RHEL4, RHEL5, I didn't pick the name "kernel" by chance ;) I just wanted to demonstrate that we now have a natural non-mixing barrier of the buildid and the disttag, and using a pure numeric disttag will lift that protection introducing unexpected ordering in many cases. -- 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 Mon Jun 4 19:27:31 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Jun 2007 21:27:31 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <20070604185627.GG18693@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <1180973691.6254.633.camel@localhost.localdomain> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <20070604185627.GG18693@neu.nirvana> Message-ID: <20070604212731.ad205641.bugs.michael@gmx.net> On Mon, 4 Jun 2007 20:56:27 +0200, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 12:45:07PM -0500, Tom spot Callaway wrote: > > On Mon, 2007-06-04 at 19:45 +0200, Michael Schwendt wrote: > > > On Mon, 04 Jun 2007 11:14:51 -0500, Tom "spot" Callaway wrote: > > > > > > > I'm not against a pre-final-freeze, scheduled mass rebuild of devel. I > > > > think that would solve the "omg, my disttags look old" fears and catch > > > > some minor issues. > > > > > > > > Is it redundant for some packages? Yep. > > > > Does it hurt those packages to be rebuilt automagically once during the > > > > cycle? No. > > > > Does it help us catch broken packages before final freeze? Yes. > > > > > > Does it bear the risk of producing new breakage? Yes. > > You need to take a firm standpoint, Michael, either the packages are > not broken and a rebuild won't break them, or they are and a rebuild > to uncover this is needed. :) Provided that it is uncovered. You didn't quote enough. [Temporary] Side-effects in other [not closely related] packages can alter the build results, too, for example. The picture of when exactly the mass-rebuild would happen and how much the the maintainers would be involved, is way too blurred. Talking about QA and lots of automated tests, we're not there yet. How do a devel cycle and a test period fit into this? If we test previously built packages on the road to a final product that we want to ship, why do we rebuild packages although nothing wrong has been found with the binaries? Why take the risk of replacing working binaries (which are assumed to work fine unless there are PRs) with theoretically we should re-test from scratch? The dist tag alone is no sufficient reason to mass-rebuild an entire distribution. From Axel.Thimm at ATrpms.net Mon Jun 4 19:33:58 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 21:33:58 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <20070604212731.ad205641.bugs.michael@gmx.net> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <1180973691.6254.633.camel@localhost.localdomain> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <20070604185627.GG18693@neu.nirvana> <20070604212731.ad205641.bugs.michael@gmx.net> Message-ID: <20070604193358.GL18693@neu.nirvana> On Mon, Jun 04, 2007 at 09:27:31PM +0200, Michael Schwendt wrote: > The picture of when exactly the mass-rebuild would happen and how > much the the maintainers would be involved, is way too > blurred. Talking about QA and lots of automated tests, we're not > there yet. Right, so let's not test at all then. Close our eyes and ship a product that has build stamps from over a period of seven months all over. So pray instead of test? > How do a devel cycle and a test period fit into this? If we test > previously built packages on the road to a final product ... like for example 7 months ago, e.g. on FC6 ... > that we want to ship, why do we rebuild packages although nothing > wrong has been found with the binaries? Sure, let's ship the binaries and have the users find out. > Why take the risk of replacing working binaries (which are assumed > to work fine unless there are PRs) with theoretically we should > re-test from scratch? Anything is assumed to work fine until you get both (or more) pieces shipped back. There is a risk? Risk management says: "break it within a controled environment", e.g. break it while it is still labeled rawhide, not when it is at the user (bananaware). Furthermore this isn't Schr?dinger's cat, where the bug is only there if we look at it. > The dist tag alone is no sufficient reason to mass-rebuild an entire > distribution. No, that's not the reason at all. -- 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 Mon Jun 4 19:43:46 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Jun 2007 21:43:46 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604185041.GF18693@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> <20070604172043.GC18693@neu.nirvana> <20070604195733.d8caef1d.bugs.michael@gmx.net> <20070604185041.GF18693@neu.nirvana> Message-ID: <20070604214346.f43b34d0.bugs.michael@gmx.net> On Mon, 4 Jun 2007 20:50:41 +0200, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 07:57:33PM +0200, Michael Schwendt wrote: > > On Mon, 4 Jun 2007 19:20:43 +0200, Axel Thimm wrote: > > > > > > No, you don't have to. It can stay at ".1" forever; if you update > > > > something for devel and/or a release distribution just increase the > > > > portion left of the disttag -- that's what we do in any case. > > > > > > which is just the same as not having any disttags at all and led to > > > the pain before the disttag. > > > > It's painless. Package is only updated when somebody maintains it. > > We hope all packages are maintained. :) > > Just introduce a package into FC6 and F7. And then have a security > update. You start juggling around with reserving build tags like > > foo-1.2.3-1 (fc6) > foo-1.2.3-2 (f7) > > fix: > > foo-1.2.3-3 (fc6) > foo-1.2.3-4 (f7) or: foo-1.2.3-1.1 (fc6) foo-1.2.3-2.1 (f7) foo-1.2.3-1.3 (fc6) foo-1.2.3-2.2 (f7) foo-1.2.3-1.4 (fc6) foo-1.2.3-2.2 (f7) It has worked fine for many package maintainers for many years. And %dist does not help when bumping %version still breaks an ISO-based dist-upgrade. > "Hey", some people cry in the background, "we still have fc5 > maintained", "please push it to fc5 as well". The same people who cry when the untested mass-updates are broken? No, thanks. You are free to use %dist when it is available and fulfills your needs. I'm only convinced it bears the risk of sloppy cut'n'paste mass-updates, reduced spec readability because of conditional sections, no testing, %changelog madness, reduced package quality. Some of that experience has its origin in watching fellow packagers struggle with mass-updates for FE. From mszpak at wp.pl Mon Jun 4 19:40:47 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Mon, 04 Jun 2007 21:40:47 +0200 Subject: Merge Review In-Reply-To: <20070604191616.GB2831@free.fr> References: <9C08CEDE-D7F8-4F13-BA09-6C2C70F1343F@rubenkerkhof.com> <20070604191616.GB2831@free.fr> Message-ID: <46646ABF.2030807@wp.pl> On 2007-06-04 21:16:16 +0200, Patrice Dumas wrote: > On Mon, Jun 04, 2007 at 09:08:59PM +0200, Ruben Kerkhof wrote: >> Hi all, >> >> Now that Fedora 7 is out the door, I'd like to ask what the plans are >> for the big Merge Review. >> There are still a lot of unassigned tickets, and I think all the >> people working on the Review since january (thanks!) could use some >> help. > > Unassigned tickets may be in review nevertheless. In some tickets the > next move should be from the maintainer, Indeed, like: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226026 What should be done if a maintainer is already retired? Marcin > but indeed there are many merge review bugs that are not reviewed. >> I would also like to now what to do with the tickets flagged with a >> +. Now that Core and Extras are merged, can we close them? > > Unless I am forgetting something, they should be closed (and if I recall > well RAWHIDE was proposed as a state for closing). From cweyl at alumni.drew.edu Mon Jun 4 19:50:08 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 4 Jun 2007 12:50:08 -0700 Subject: Merge Review In-Reply-To: <9C08CEDE-D7F8-4F13-BA09-6C2C70F1343F@rubenkerkhof.com> References: <9C08CEDE-D7F8-4F13-BA09-6C2C70F1343F@rubenkerkhof.com> Message-ID: <7dd7ab490706041250m3f018190ne71b28627db021cd@mail.gmail.com> On 6/4/07, Ruben Kerkhof wrote: > Now that Fedora 7 is out the door, I'd like to ask what the plans are > for the big Merge Review. > There are still a lot of unassigned tickets, and I think all the > people working on the Review since january (thanks!) could use some > help. > Maybe we can do another Review Day before F-8? This is something I'd personally like to see FESCo address. If memory serves, originally the intent of the merge reviews was to make sure core packages were reviewed and complied to guidelines like any other package. As time wore on, for a variety of reasons the decision was made (by FESCo?) to treat the review tix as "advisory" and not blocking a package's inclusion in the Brave Merged World. Now that we've achieved BMWness and F-7 is out the door, I think there should be a renewed emphasis on merge reviews, with a timeframe and actual consequences for non-review. (Without teeth, they'll never be done...) Either that, or we should say "the merge reviews are dead; file packaging bugs when you find them." Note I'm not advocating the latter approach -- just including it here. Another issue to address now is what to review. I'd say devel as it stands in CVS -- reviewing the pakages (or state thereof) at the point of the tix being created seems rather pointless now. -Chris -- Chris Weyl Ex astris, scientia From bugs.michael at gmx.net Mon Jun 4 20:06:37 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Jun 2007 22:06:37 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <20070604193358.GL18693@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <1180973691.6254.633.camel@localhost.localdomain> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <20070604185627.GG18693@neu.nirvana> <20070604212731.ad205641.bugs.michael@gmx.net> <20070604193358.GL18693@neu.nirvana> Message-ID: <20070604220637.825b90e2.bugs.michael@gmx.net> On Mon, 4 Jun 2007 21:33:58 +0200, Axel Thimm wrote: > > The picture of when exactly the mass-rebuild would happen and how > > much the the maintainers would be involved, is way too > > blurred. Talking about QA and lots of automated tests, we're not > > there yet. > > Right, so let's not test at all then. Close our eyes and ship a > product that has build stamps from over a period of seven months all > over. So pray instead of test? "It (re)builds, let's ship it, we need not test it" is an equally short-sighted strategy. A period of seven months? Seven months without a bug report? Seven months without the maintainer using his own package? Sounds good. Instead you get up to seven month without a bug report, probably because the package works fine, and then during the test releases when all the fans of stable releases don't participate, you rebuild something just for fun, creating a new testing-target. > > How do a devel cycle and a test period fit into this? If we test > > previously built packages on the road to a final product > > ... like for example 7 months ago, e.g. on FC6 ... Don't generalise. How compatible are our distribution releases with eachother? Why rebuild ABI-compatible components? > > that we want to ship, why do we rebuild packages although nothing > > wrong has been found with the binaries? > > Sure, let's ship the binaries and have the users find out. No testing? No QA? Is your mass-rebuild the only form of "testing"? =:-O Anyway, I try to end this thread here. If we somehow try to prepare binaries right in time before test1 in accordance with a clear roadmap, I'm fine with that. I still would like to see maintainers be the ones to touch packages if they need to be touched and not just for rebuild-fun. From caillon at redhat.com Mon Jun 4 20:09:05 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jun 2007 16:09:05 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <46642DCF.7040503@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> Message-ID: <46647161.6070806@redhat.com> Thorsten Leemhuis wrote: > > On 04.06.2007 16:13, Rahul Sundaram wrote: >> Brian Pepple wrote: >>> On Mon, 2007-06-04 at 14:42 +0200, Axel Thimm wrote: >>>> On Sun, Jun 03, 2007 at 11:08:23AM -0400, Jesse Keating wrote: >>>>> /topic RELENG-Meeting - Freeze Policy - JesseKeating >>>> I would suggest to consider at least one full rebuild [1] before the >>>> final freeze (e.g. as part of the pre-freeze process) and of course to >>>> allow for enough time between the freeze and the GA to shake out any >>>> bugs that will surface by that process. >>> This is on FESCo's schedule to discuss after F7 was released. >> Note that this has caused mass confusion as I thought it would. It is >> not just about technical requirements. > > The idea to use ".1" as disstag for devel (discusses weeks ago) still > stands. > > The idea in short: x.1 is higher then x.fc7 and avoid the confusion if a > package doesn't get rebuild during a devel cycle; and if there later is > a update after releases x simply gets increased -- so there would no > need to got for "x.2". > > I can outline the idea further if anybody is interested. This is trying to work around a perceived problem by inventing a new problem. I've seen bugs filed on packagers for not using the disttag before. We should not encourage disttag everywhere, only where it makes sense. If packages don't get updated once between releases, maybe the disttag is not useful for that package and it's usage ought to be _dis_couraged in this situation. From Axel.Thimm at ATrpms.net Mon Jun 4 20:15:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 22:15:04 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604214346.f43b34d0.bugs.michael@gmx.net> References: <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> <20070604172043.GC18693@neu.nirvana> <20070604195733.d8caef1d.bugs.michael@gmx.net> <20070604185041.GF18693@neu.nirvana> <20070604214346.f43b34d0.bugs.michael@gmx.net> Message-ID: <20070604201504.GO18693@neu.nirvana> On Mon, Jun 04, 2007 at 09:43:46PM +0200, Michael Schwendt wrote: > > > > which is just the same as not having any disttags at all and led to > > > > the pain before the disttag. > > > > > > It's painless. Package is only updated when somebody maintains it. > > > > We hope all packages are maintained. :) > > > > Just introduce a package into FC6 and F7. And then have a security > > update. You start juggling around with reserving build tags like > > > > foo-1.2.3-1 (fc6) > > foo-1.2.3-2 (f7) > > > > fix: > > > > foo-1.2.3-3 (fc6) > > foo-1.2.3-4 (f7) > > or: > > foo-1.2.3-1.1 (fc6) > foo-1.2.3-2.1 (f7) > > foo-1.2.3-1.3 (fc6) > foo-1.2.3-2.2 (f7) > > foo-1.2.3-1.4 (fc6) > foo-1.2.3-2.2 (f7) > > It has worked fine for many package maintainers for many years. Don't talk about yourself in plural and in the 3rd person. ;) The above makes no real sense whatsoever, you have effectively reverted the order of buildids and disttags. BTW if that were your intention (which you would have said so), it would make sense, I would just not agree on doing so: If the disttag is to take precedence above the release it needs to do so above the version, too, e..g it would become a prefix to the epoch. And I left the best for the end: Where's support for F8/devel? foo-1.2.3-3.x? Or did the integers run out now? ;) > And %dist does not help when bumping %version still breaks an ISO-based > dist-upgrade. I can't understand this at all. What does the media of the update have to do with it and why does a bump of %version break anything? -- 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 Mon Jun 4 20:21:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 22:21:43 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <20070604220637.825b90e2.bugs.michael@gmx.net> References: <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <1180973691.6254.633.camel@localhost.localdomain> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <20070604185627.GG18693@neu.nirvana> <20070604212731.ad205641.bugs.michael@gmx.net> <20070604193358.GL18693@neu.nirvana> <20070604220637.825b90e2.bugs.michael@gmx.net> Message-ID: <20070604202143.GP18693@neu.nirvana> On Mon, Jun 04, 2007 at 10:06:37PM +0200, Michael Schwendt wrote: > On Mon, 4 Jun 2007 21:33:58 +0200, Axel Thimm wrote: > > > > The picture of when exactly the mass-rebuild would happen and how > > > much the the maintainers would be involved, is way too > > > blurred. Talking about QA and lots of automated tests, we're not > > > there yet. > > > > Right, so let's not test at all then. Close our eyes and ship a > > product that has build stamps from over a period of seven months all > > over. So pray instead of test? > > "It (re)builds, let's ship it, we need not test it" is an equally > short-sighted strategy. which is not what I suggested, I explicitely said that there is more time needed to test between the freeze and the GA. > A period of seven months? Seven months without a bug report? Seven months > without the maintainer using his own package? Sounds good. So you assume all 500 packagers run a bleeding edge rawhide on a daily basis? That's far from being the case. I don't for one, do you? > > > How do a devel cycle and a test period fit into this? If we test > > > previously built packages on the road to a final product > > > > ... like for example 7 months ago, e.g. on FC6 ... > > Don't generalise. > How compatible are our distribution releases with eachother? > Why rebuild ABI-compatible components? Fedora is not known about keeping ABI compatiblity for a long time, in fact not caring about legacy is part of Fedora's definition and flexibility. > > > that we want to ship, why do we rebuild packages although nothing > > > wrong has been found with the binaries? > > > > Sure, let's ship the binaries and have the users find out. > > No testing? No QA? Is your mass-rebuild the only form of "testing"? =:-O No, not at all. But put the QA at the end of the development cycle, not spreading from FC6 to F7. > Anyway, I try to end this thread here. > > If we somehow try to prepare binaries right in time before test1 in > accordance with a clear roadmap, I'm fine with that. I still would like to > see maintainers be the ones to touch packages if they need to be touched > and not just for rebuild-fun. I think I'll start assigning all bugs that show up due to missing rebuilds to Michael. :) -- 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 bpepple at fedoraproject.org Mon Jun 4 20:23:06 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 04 Jun 2007 16:23:06 -0400 Subject: Merge Review In-Reply-To: <7dd7ab490706041250m3f018190ne71b28627db021cd@mail.gmail.com> References: <9C08CEDE-D7F8-4F13-BA09-6C2C70F1343F@rubenkerkhof.com> <7dd7ab490706041250m3f018190ne71b28627db021cd@mail.gmail.com> Message-ID: <1180988586.8557.1.camel@kennedy> On Mon, 2007-06-04 at 12:50 -0700, Chris Weyl wrote: > On 6/4/07, Ruben Kerkhof wrote: > > Now that Fedora 7 is out the door, I'd like to ask what the plans are > > for the big Merge Review. > > There are still a lot of unassigned tickets, and I think all the > > people working on the Review since january (thanks!) could use some > > help. > > Maybe we can do another Review Day before F-8? > > This is something I'd personally like to see FESCo address. If memory > serves, originally the intent of the merge reviews was to make sure > core packages were reviewed and complied to guidelines like any other > package. As time wore on, for a variety of reasons the decision was > made (by FESCo?) to treat the review tix as "advisory" and not > blocking a package's inclusion in the Brave Merged World. the plan is to have these bug be blockers for F8. /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 Axel.Thimm at ATrpms.net Mon Jun 4 20:25:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Jun 2007 22:25:10 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <46647161.6070806@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> Message-ID: <20070604202510.GQ18693@neu.nirvana> On Mon, Jun 04, 2007 at 04:09:05PM -0400, Christopher Aillon wrote: > I've seen bugs filed on packagers for not using the disttag before. We > should not encourage disttag everywhere, only where it makes sense. If > packages don't get updated once between releases, maybe the disttag is > not useful for that package and it's usage ought to be _dis_couraged in > this situation. That's a sane attitude and IMHO is the current state of affairs: If the packager identifies that he shares specfiles across releases he grabs disttags to be able to keep the specfiles the same and not have to cache integers for managing concurrent releases. There are packages were disttags make no sense whatsoever like fedora-release(-notes), data packages, firmwares, very often fonts and so on. These should really not be disttagged only because it's custom to do so. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 4 20:25:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 16:25:08 -0400 Subject: Proposed patch to cvs-import.sh Message-ID: <200706041625.09228.jkeating@redhat.com> I've been requested to apply a patch to cvs-import.sh that will change the behaviour of how it works without a branch option applied. Basically if it finds a BRANCH file in $PWD, it will default to importing on the value of the BRANCH file. So if you're in F-7/ and you cvs-import.sh it'll attempt to import it onto the F-7/ branch. We've used this internally for a while without issues, but I wanted to post and see what folks thought about it before I applied it externally. Comments? -- 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 bnocera at redhat.com Mon Jun 4 20:28:47 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 04 Jun 2007 21:28:47 +0100 Subject: libwnck soname up Message-ID: <1180988927.25009.136.camel@cookie.hadess.net> A heads up, libwnck 2.19.3 changes the soname. I've hit just the one bug which seems to block pretty much everything else that needs rebuilding. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242567 If anyone has an idea on how to work-around the problem. What surprises me is that the library and daemon that uses it aren't in the same source package. Cheers From j.w.r.degoede at hhs.nl Mon Jun 4 20:44:12 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 04 Jun 2007 22:44:12 +0200 Subject: Bodhi updates-testing Autopush, Anonymous Commenting In-Reply-To: <46645B98.70001@redhat.com> References: <46645B98.70001@redhat.com> Message-ID: <4664799C.5060601@hhs.nl> Warren Togami wrote: > This thread contains only strawman ideas to solicit ideas and opinions > for Bodhi. > > NOTE: This mail talks only about how updates-testing tickets in bodhi > behave after they become updates-testing. The controversial matter of > whether a package is required to go into updates-testing is a separate > matter to be discussed and ratified during Thursday's FESCo meeting. > > Idea: updates-testing Autopush after Timeout > ============================================ > 1) Bodhi should auto-push updates-testing after a time-out period. > 2) Bodhi interface allows others to comment on the goodness/badness of a > test update. > 3) Bodhi interface allows others to declare a test update broken, which > freezes the auto-push after timeout. > 4) Package maintainer or admins can override this and push anyway. > > Idea: Timeout Default, Configurable? > ==================================== > Default updates-testing timeout is 7 days. Package maintainer may set a > different timeout period (i.e. 4, 9 or 14 days), or turn off the timeout > entirely. > > Idea: Anonymous Commenting > ========================== > Update and updates-testing announcement mail will have links to the > Bodhi ticket where users can comment on their experiences with that > package. This should do good to improve communications between users > and developers, and also be handy for users to know more details about > the effect an updated package will have on their system. > > (Perhaps not a link to the Bodhi ticket, but a separate comment-and-view > URL... lmacken can decide on this as an implementation detail.) > > Currently commenting on an update in bodhi requires you to have a FAS > account, which can be inconvenient for the majority of Fedora users. We > could potentially allow more convenient commenting to the public through > some other means. > > http://en.wikipedia.org/wiki/Captcha > Users not authenticated through FAS are given the option to type in a > CAPTCHA string, which allows them to comment without authenticating. A > CAPTCHA should be sufficient to control spam. > This all sounds good to me, +1 Regards, Hans From bugs.michael at gmx.net Mon Jun 4 20:34:52 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Jun 2007 22:34:52 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604201504.GO18693@neu.nirvana> References: <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> <20070604172043.GC18693@neu.nirvana> <20070604195733.d8caef1d.bugs.michael@gmx.net> <20070604185041.GF18693@neu.nirvana> <20070604214346.f43b34d0.bugs.michael@gmx.net> <20070604201504.GO18693@neu.nirvana> Message-ID: <20070604223452.03309327.bugs.michael@gmx.net> On Mon, 4 Jun 2007 22:15:04 +0200, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 09:43:46PM +0200, Michael Schwendt wrote: > > > > > which is just the same as not having any disttags at all and led to > > > > > the pain before the disttag. > > > > > > > > It's painless. Package is only updated when somebody maintains it. > > > > > > We hope all packages are maintained. :) > > > > > > Just introduce a package into FC6 and F7. And then have a security > > > update. You start juggling around with reserving build tags like > > > > > > foo-1.2.3-1 (fc6) > > > foo-1.2.3-2 (f7) > > > > > > fix: > > > > > > foo-1.2.3-3 (fc6) > > > foo-1.2.3-4 (f7) > > > > or: > > > > foo-1.2.3-1.1 (fc6) > > foo-1.2.3-2.1 (f7) > > > > foo-1.2.3-1.3 (fc6) > > foo-1.2.3-2.2 (f7) > > > > foo-1.2.3-1.4 (fc6) > > foo-1.2.3-2.2 (f7) > > > > It has worked fine for many package maintainers for many years. > > Don't talk about yourself in plural and in the 3rd person. ;) Keep moving closer to a "plonk" for this list. ;) > The above makes no real sense whatsoever, Why? > you have effectively > reverted the order of buildids and disttags. Elaborate. > BTW if that were your > intention (which you would have said so), it would make sense, I would > just not agree on doing so: If the disttag is to take precedence above > the release it needs to do so above the version, too, e..g it would > become a prefix to the epoch. Pardon? What are you talking about? > And I left the best for the end: Where's support for F8/devel? > foo-1.2.3-3.x? Or did the integers run out now? ;) All above or equal to 3 work fine for F8, pick either one, e.g.: foo-1.2.3-3 (f8) or: foo-1.2.3-4 (f8) or: foo-1.2.3-8 (f8) to continue above list, another fix: foo-1.2.3-1.5 (fc6) foo-1.2.3-2.3 (f7) foo-1.2.3-3.1 (f8) If you insist on copying the f8 spec to f7 and fc6, you can still do that with oh so many packages where it works. Adjusting %release is necessary, but not difficult. > > And %dist does not help when bumping %version still breaks an ISO-based > > dist-upgrade. > > I can't understand this at all. What does the media of the update have > to do with it and why does a bump of %version break anything? Are you serious? Do you really don't see what role %dist plays in conjunction with broken dist-upgrade paths? It has been the topic of many old threads about pros and cons of %dist. From sundaram at fedoraproject.org Mon Jun 4 20:31:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 05 Jun 2007 02:01:36 +0530 Subject: Merge Review In-Reply-To: <1180988586.8557.1.camel@kennedy> References: <9C08CEDE-D7F8-4F13-BA09-6C2C70F1343F@rubenkerkhof.com> <7dd7ab490706041250m3f018190ne71b28627db021cd@mail.gmail.com> <1180988586.8557.1.camel@kennedy> Message-ID: <466476A8.70700@fedoraproject.org> Brian Pepple wrote: > On Mon, 2007-06-04 at 12:50 -0700, Chris Weyl wrote: >> On 6/4/07, Ruben Kerkhof wrote: >>> Now that Fedora 7 is out the door, I'd like to ask what the plans are >>> for the big Merge Review. >>> There are still a lot of unassigned tickets, and I think all the >>> people working on the Review since january (thanks!) could use some >>> help. >>> Maybe we can do another Review Day before F-8? >> This is something I'd personally like to see FESCo address. If memory >> serves, originally the intent of the merge reviews was to make sure >> core packages were reviewed and complied to guidelines like any other >> package. As time wore on, for a variety of reasons the decision was >> made (by FESCo?) to treat the review tix as "advisory" and not >> blocking a package's inclusion in the Brave Merged World. > > the plan is to have these bug be blockers for F8. What happens when package reviews don't finish because the reviewers don't review it or package maintainers fix up the packages? Do we pull out packages (what if this was the kernel or glibc?) or delay release or is there other ideas? Rahul From caillon at redhat.com Mon Jun 4 20:31:56 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jun 2007 16:31:56 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604202510.GQ18693@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> Message-ID: <466476BC.90104@redhat.com> Axel Thimm wrote: > On Mon, Jun 04, 2007 at 04:09:05PM -0400, Christopher Aillon wrote: >> I've seen bugs filed on packagers for not using the disttag before. We >> should not encourage disttag everywhere, only where it makes sense. If >> packages don't get updated once between releases, maybe the disttag is >> not useful for that package and it's usage ought to be _dis_couraged in >> this situation. > > That's a sane attitude and IMHO is the current state of affairs: If > the packager identifies that he shares specfiles across releases he > grabs disttags to be able to keep the specfiles the same and not have > to cache integers for managing concurrent releases. My argument is that if packages don't get updated that often, disttag is rather useless as the chances are low that it will get a fedora udpate pushed. And on the off-chance it does, diverging a specfile once is not a big deal. I think this is _NOT_ the current state of affairs else we would not have as many .fc6 packages as we do in F-7. Those packages should have the disttag removed IMO. From packages at amiga-hardware.com Mon Jun 4 20:34:24 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Mon, 04 Jun 2007 21:34:24 +0100 Subject: cegui review & heads up Message-ID: <46647750.7030409@amiga-hardware.com> Hi, I maintain cegui in Fedora which is currently at version 0.4.1. I would eventually like to push the 0.5 branch for FC6+ but feel the SPEC has changed significantly enough that another review would prove useful. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242566 Currently AFAICS only chess and probably Ogre3D have dependancies on this. The maintainer (Hans de Goede) is aware of the intentions. So basically this is a heads up to anyone maintaining a package I might have missed or is planning on using cegui. -- Ian Chapman. From hp at redhat.com Mon Jun 4 20:36:34 2007 From: hp at redhat.com (Havoc Pennington) Date: Mon, 04 Jun 2007 16:36:34 -0400 Subject: libwnck soname up In-Reply-To: <1180988927.25009.136.camel@cookie.hadess.net> References: <1180988927.25009.136.camel@cookie.hadess.net> Message-ID: <466477D2.8050903@redhat.com> Bastien Nocera wrote: > A heads up, > > libwnck 2.19.3 changes the soname. I've hit just the one bug which seems > to block pretty much everything else that needs rebuilding. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242567 > > If anyone has an idea on how to work-around the problem. What surprises > me is that the library and daemon that uses it aren't in the same source > package. > Did the libwnck soname change on purpose? I haven't seen any bug traffic go by mentioning any API changes that would seem 'worth it' (not that I have been paying _that_ much attention) Havoc From tibbs at math.uh.edu Mon Jun 4 20:55:29 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Jun 2007 15:55:29 -0500 Subject: Merge Review In-Reply-To: <7dd7ab490706041250m3f018190ne71b28627db021cd@mail.gmail.com> References: <9C08CEDE-D7F8-4F13-BA09-6C2C70F1343F@rubenkerkhof.com> <7dd7ab490706041250m3f018190ne71b28627db021cd@mail.gmail.com> Message-ID: >>>>> "CW" == Chris Weyl writes: CW> As time wore on, for a variety of reasons the decision was made CW> (by FESCo?) to treat the review tix as "advisory" and not blocking CW> a package's inclusion in the Brave Merged World. It's should be pretty obvious to anyone that even assuming quick responses from the maintainers, we just didn't have the review pool necessary to get those merge review tickets done in time for F7. A bunch of us locked ourselves in a room at fudcon and still didn't make all that much progress. It was just too much work. CW> Now that we've achieved BMWness and F-7 is out the door, I think CW> there should be a renewed emphasis on merge reviews, with a CW> timeframe and actual consequences for non-review. Well, first I'd like to see some information from Red Hat folks about what we can actually require. What kind of enforcement can we get? Can someone actually force maintainers to deal with their merge review comments? RHEL5 and F7 are out, so it seems that we're in a good position to find just a little developer time and hopefully we can make a dent in them. But currently I'm trying to make more progress on the other review tickets, because I feel that the new contributor experience is more important right now. Only after that is under control do I want to spend more time doing merge reviews (besides those which I've promised to do). - J< From pertusus at free.fr Mon Jun 4 20:55:27 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 22:55:27 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <466476BC.90104@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> Message-ID: <20070604205527.GD2831@free.fr> On Mon, Jun 04, 2007 at 04:31:56PM -0400, Christopher Aillon wrote: > > My argument is that if packages don't get updated that often, disttag is > rather useless as the chances are low that it will get a fedora udpate > pushed. And on the off-chance it does, diverging a specfile once is not > a big deal. > > I think this is _NOT_ the current state of affairs else we would not > have as many .fc6 packages as we do in F-7. Those packages should have > the disttag removed IMO. Maybe some, but not necessarily all of them. Taking myself as an example, I own some python modules that may certainly be better without disttag, but I also have C/C++ stuff that, although stable and unfrequently updated are certainly better with a disttag. -- Pat From bnocera at redhat.com Mon Jun 4 20:58:11 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 04 Jun 2007 21:58:11 +0100 Subject: libwnck soname up In-Reply-To: <466477D2.8050903@redhat.com> References: <1180988927.25009.136.camel@cookie.hadess.net> <466477D2.8050903@redhat.com> Message-ID: <1180990691.25009.143.camel@cookie.hadess.net> On Mon, 2007-06-04 at 16:36 -0400, Havoc Pennington wrote: > > Bastien Nocera wrote: > > A heads up, > > > > libwnck 2.19.3 changes the soname. I've hit just the one bug which seems > > to block pretty much everything else that needs rebuilding. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242567 > > > > If anyone has an idea on how to work-around the problem. What surprises > > me is that the library and daemon that uses it aren't in the same source > > package. > > > > Did the libwnck soname change on purpose? I haven't seen any bug traffic > go by mentioning any API changes that would seem 'worth it' > > (not that I have been paying _that_ much attention) I believed it's fixing this bug: http://bugzilla.gnome.org/show_bug.cgi?id=164474 which (wrongly) brought to that commit: 2007-05-19 Vincent Untz * libwnck/screen.c: (wnck_screen_class_init): * libwnck/screen.h: I've already broken API, so add the few signals that were commented out, and re-break API before we release :-) and: 2007-05-20 Vincent Untz Remove all reference to _NET_WM_WINDOW_TYPE_MODAL_DIALOG since it's not in the EWMH spec. This breaks API again. Fix bug #124332. * libwnck/window.c: (wnck_window_set_window_type), (update_state), (update_wintype): don't handle the WNCK_WINDOW_MODAL_DIALOG cases * libwnck/window.h: remove WNCK_WINDOW_MODAL_DIALOG The last one is the only one to require a soname bump: http://svn.gnome.org/viewcvs/libwnck/trunk/libwnck/window.h?r1=1211&r2=1255&pathrev=1255 From caillon at redhat.com Mon Jun 4 20:56:50 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jun 2007 16:56:50 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604205527.GD2831@free.fr> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> Message-ID: <46647C92.2000700@redhat.com> Patrice Dumas wrote: > On Mon, Jun 04, 2007 at 04:31:56PM -0400, Christopher Aillon wrote: >> >> My argument is that if packages don't get updated that often, disttag is >> rather useless as the chances are low that it will get a fedora udpate >> pushed. And on the off-chance it does, diverging a specfile once is not >> a big deal. >> >> I think this is _NOT_ the current state of affairs else we would not >> have as many .fc6 packages as we do in F-7. Those packages should have >> the disttag removed IMO. > > Maybe some, but not necessarily all of them. Taking myself as an > example, I own some python modules that may certainly be better without > disttag, but I also have C/C++ stuff that, although stable and > unfrequently updated are certainly better with a disttag. Why is it better with a disttag, out of curiosity? From hp at redhat.com Mon Jun 4 21:03:48 2007 From: hp at redhat.com (Havoc Pennington) Date: Mon, 04 Jun 2007 17:03:48 -0400 Subject: libwnck soname up In-Reply-To: <1180990691.25009.143.camel@cookie.hadess.net> References: <1180988927.25009.136.camel@cookie.hadess.net> <466477D2.8050903@redhat.com> <1180990691.25009.143.camel@cookie.hadess.net> Message-ID: <46647E34.7080304@redhat.com> That change doesn't seem worth the pain of a soname bump to me but I will leave someone else to argue that point ;-) > The last one is the only one to require a soname bump: > http://svn.gnome.org/viewcvs/libwnck/trunk/libwnck/window.h?r1=1211&r2=1255&pathrev=1255 > From pertusus at free.fr Mon Jun 4 21:09:57 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 23:09:57 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <46647C92.2000700@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> Message-ID: <20070604210957.GE2831@free.fr> On Mon, Jun 04, 2007 at 04:56:50PM -0400, Christopher Aillon wrote: > > Why is it better with a disttag, out of curiosity? It is easier to copy over spec files for the different versions. Those are rebuilt quite often in any case for changes in gcc/libc, so there isn't much gain in avoiding disttag changes (like it is for packages less often rebuilt like noarch packages). -- Pat From caillon at redhat.com Mon Jun 4 21:12:43 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jun 2007 17:12:43 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604210957.GE2831@free.fr> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <20070604210957.GE2831@free.fr> Message-ID: <4664804B.6000200@redhat.com> Patrice Dumas wrote: > On Mon, Jun 04, 2007 at 04:56:50PM -0400, Christopher Aillon wrote: >> >> Why is it better with a disttag, out of curiosity? > > It is easier to copy over spec files for the different versions. Those > are rebuilt quite often in any case for changes in gcc/libc, > so there isn't much gain in avoiding disttag changes (like it is for > packages less often rebuilt like noarch packages). How often do those change ABI on stable released versions? Why would it need a rebuild on e.g. FC6? From pertusus at free.fr Mon Jun 4 21:21:21 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 4 Jun 2007 23:21:21 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <4664804B.6000200@redhat.com> References: <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <20070604210957.GE2831@free.fr> <4664804B.6000200@redhat.com> Message-ID: <20070604212121.GF2831@free.fr> On Mon, Jun 04, 2007 at 05:12:43PM -0400, Christopher Aillon wrote: > Patrice Dumas wrote: > >On Mon, Jun 04, 2007 at 04:56:50PM -0400, Christopher Aillon wrote: > >> > >>Why is it better with a disttag, out of curiosity? > > > >It is easier to copy over spec files for the different versions. Those > >are rebuilt quite often in any case for changes in gcc/libc, > >so there isn't much gain in avoiding disttag changes (like it is for > >packages less often rebuilt like noarch packages). > > How often do those change ABI on stable released versions? Why would it > need a rebuild on e.g. FC6? Not on stable release but on devel. What I was meaning is that for packages that don't need to be rebuilt a disttag may be problematic since a rebuild will trigger a new version and therefore an update even when it is not needed. For binary packages rebuilds in general should lead to updates. Now, on stable release a rebuild should be caused by a bugfix, an update or whatever, in that case having dist tags helps reusing spec files while keeping upgrade paths. -- Pat From bnocera at redhat.com Mon Jun 4 21:23:40 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 04 Jun 2007 22:23:40 +0100 Subject: libwnck soname up In-Reply-To: <46647E34.7080304@redhat.com> References: <1180988927.25009.136.camel@cookie.hadess.net> <466477D2.8050903@redhat.com> <1180990691.25009.143.camel@cookie.hadess.net> <46647E34.7080304@redhat.com> Message-ID: <1180992220.25009.145.camel@cookie.hadess.net> On Mon, 2007-06-04 at 17:03 -0400, Havoc Pennington wrote: > That change doesn't seem worth the pain of a soname bump to me but I > will leave someone else to argue that point ;-) And filed upstream: http://bugzilla.gnome.org/show_bug.cgi?id=444119 Hopefully, we'll get an answer before somebody finds a solution for the libnotify cyclic dependency. From bpepple at fedoraproject.org Mon Jun 4 21:28:40 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 04 Jun 2007 17:28:40 -0400 Subject: Merge Review In-Reply-To: <466476A8.70700@fedoraproject.org> References: <9C08CEDE-D7F8-4F13-BA09-6C2C70F1343F@rubenkerkhof.com> <7dd7ab490706041250m3f018190ne71b28627db021cd@mail.gmail.com> <1180988586.8557.1.camel@kennedy> <466476A8.70700@fedoraproject.org> Message-ID: <1180992520.8557.11.camel@kennedy> On Tue, 2007-06-05 at 02:01 +0530, Rahul Sundaram wrote: > Brian Pepple wrote: > > On Mon, 2007-06-04 at 12:50 -0700, Chris Weyl wrote: > >> On 6/4/07, Ruben Kerkhof wrote: > >>> Now that Fedora 7 is out the door, I'd like to ask what the plans are > >>> for the big Merge Review. > >>> There are still a lot of unassigned tickets, and I think all the > >>> people working on the Review since january (thanks!) could use some > >>> help. > >>> Maybe we can do another Review Day before F-8? > >> This is something I'd personally like to see FESCo address. If memory > >> serves, originally the intent of the merge reviews was to make sure > >> core packages were reviewed and complied to guidelines like any other > >> package. As time wore on, for a variety of reasons the decision was > >> made (by FESCo?) to treat the review tix as "advisory" and not > >> blocking a package's inclusion in the Brave Merged World. > > > > the plan is to have these bug be blockers for F8. > > What happens when package reviews don't finish because the reviewers > don't review it or package maintainers fix up the packages? Do we pull > out packages (what if this was the kernel or glibc?) or delay release or > is there other ideas? That is one of the items we are still discussing. /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 Mon Jun 4 20:42:45 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 4 Jun 2007 22:42:45 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <20070604202143.GP18693@neu.nirvana> References: <46642DCF.7040503@leemhuis.info> <200706041127.21999.jkeating@redhat.com> <20070604161025.GC15001@neu.nirvana> <1180973691.6254.633.camel@localhost.localdomain> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <20070604185627.GG18693@neu.nirvana> <20070604212731.ad205641.bugs.michael@gmx.net> <20070604193358.GL18693@neu.nirvana> <20070604220637.825b90e2.bugs.michael@gmx.net> <20070604202143.GP18693@neu.nirvana> Message-ID: <20070604224245.5aa1b9fd.bugs.michael@gmx.net> On Mon, 4 Jun 2007 22:21:43 +0200, Axel Thimm wrote: > So you assume all 500 packagers run a bleeding edge rawhide on a daily > basis? We have test1, test2, ... we have co-maintainers, we *need* to prepare the distribution early enough so we have something to offer when test1 is released. > That's far from being the case. I know. Now what? > I don't for one, do you? Around test1 and afterwards I've tried to prefer rawhide over FC6 as often as possible. > > > > How do a devel cycle and a test period fit into this? If we test > > > > previously built packages on the road to a final product > > > > > > ... like for example 7 months ago, e.g. on FC6 ... > > > > Don't generalise. > > How compatible are our distribution releases with eachother? > > Why rebuild ABI-compatible components? > > Fedora is not known about keeping ABI compatiblity for a long time, in > fact not caring about legacy is part of Fedora's definition and > flexibility. But the gcc, glibc, libstdc++ (and so on) developers inform us about when there are changes that ought to [or must] result in rebuilds. > I think I'll start assigning all bugs that show up due to missing > rebuilds to Michael. :) Do you keep a list already? Put it in the Wiki, and I'm certain, more people will take a close look at it. From caillon at redhat.com Mon Jun 4 21:57:24 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jun 2007 17:57:24 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604212121.GF2831@free.fr> References: <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <20070604210957.GE2831@free.fr> <4664804B.6000200@redhat.com> <20070604212121.GF2831@free.fr> Message-ID: <46648AC4.3040707@redhat.com> Patrice Dumas wrote: > On Mon, Jun 04, 2007 at 05:12:43PM -0400, Christopher Aillon wrote: >> Patrice Dumas wrote: >> >On Mon, Jun 04, 2007 at 04:56:50PM -0400, Christopher Aillon wrote: >> >> >> >>Why is it better with a disttag, out of curiosity? >> > >> >It is easier to copy over spec files for the different versions. Those >> >are rebuilt quite often in any case for changes in gcc/libc, >> >so there isn't much gain in avoiding disttag changes (like it is for >> >packages less often rebuilt like noarch packages). >> >> How often do those change ABI on stable released versions? Why would it >> need a rebuild on e.g. FC6? > > Not on stable release but on devel. And incrementing the release number will automatically make it newer than what's in older releases, so not sure where this comes into play. > What I was meaning is that for > packages that don't need to be rebuilt a disttag may be problematic > since a rebuild will trigger a new version and therefore an update even > when it is not needed. For binary packages rebuilds in general should > lead to updates. Um, how will something that doesn't get rebuilt trigger an update? Not quite sure what you were just saying here... > Now, on stable release a rebuild should be caused by a bugfix, an update > or whatever, in that case having dist tags helps reusing spec files > while keeping upgrade paths. Sure, for a bugfix. But if you haven't updated any of these packages between fc6 and fc7, you can agree that it is unlikely you'll ever have to do more than one or two. is it really a big deal on the rare occasion that you need to push a bugfix back to fork one thing? Sure it's convenience which saves you maybe 20 seconds once every year? and in the meantime confuses/pisses off alot of people apparently because there's an .fc6 devil package in F7. From Axel.Thimm at ATrpms.net Tue Jun 5 00:46:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 02:46:52 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <20070604224245.5aa1b9fd.bugs.michael@gmx.net> References: <20070604161025.GC15001@neu.nirvana> <1180973691.6254.633.camel@localhost.localdomain> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <20070604185627.GG18693@neu.nirvana> <20070604212731.ad205641.bugs.michael@gmx.net> <20070604193358.GL18693@neu.nirvana> <20070604220637.825b90e2.bugs.michael@gmx.net> <20070604202143.GP18693@neu.nirvana> <20070604224245.5aa1b9fd.bugs.michael@gmx.net> Message-ID: <20070605004652.GD11102@neu.nirvana> On Mon, Jun 04, 2007 at 10:42:45PM +0200, Michael Schwendt wrote: > On Mon, 4 Jun 2007 22:21:43 +0200, Axel Thimm wrote: > > > So you assume all 500 packagers run a bleeding edge rawhide on a > > daily basis? > > We have test1, test2, ... we have co-maintainers, we *need* to > prepare the distribution early enough so we have something to offer > when test1 is released. So do a rebuild for test1. > > That's far from being the case. > > I know. Now what? > > > I don't for one, do you? > > Around test1 and afterwards I've tried to prefer rawhide over FC6 as often > as possible. You tried. Did you also succeed? Succeed as in installing on your laptop and using for more than 5 minutes? If not, then please don't assume that there was a grand QA before the test releases came out. > > > > > How do a devel cycle and a test period fit into this? If we test > > > > > previously built packages on the road to a final product > > > > > > > > ... like for example 7 months ago, e.g. on FC6 ... > > > > > > Don't generalise. > > > How compatible are our distribution releases with eachother? > > > Why rebuild ABI-compatible components? > > > > Fedora is not known about keeping ABI compatiblity for a long > > time, in fact not caring about legacy is part of Fedora's > > definition and flexibility. > > But the gcc, glibc, libstdc++ (and so on) developers inform us about > when there are changes that ought to [or must] result in rebuilds. and obvioulsy this didn't cover all packages. I have about twenty that passed review and 3 of them broke. So that's ~ 1/7th. > > I think I'll start assigning all bugs that show up due to missing > > rebuilds to Michael. :) > > Do you keep a list already? Put it in the Wiki, and I'm certain, > more people will take a close look at it. No, assigning to you will be more fun. ;) -- 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 Tue Jun 5 00:51:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 02:51:36 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604205527.GD2831@free.fr> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> Message-ID: <20070605005136.GE11102@neu.nirvana> On Mon, Jun 04, 2007 at 10:55:27PM +0200, Patrice Dumas wrote: > On Mon, Jun 04, 2007 at 04:31:56PM -0400, Christopher Aillon wrote: > > > > My argument is that if packages don't get updated that often, disttag is > > rather useless as the chances are low that it will get a fedora udpate > > pushed. And on the off-chance it does, diverging a specfile once is not > > a big deal. > > > > I think this is _NOT_ the current state of affairs else we would not > > have as many .fc6 packages as we do in F-7. Those packages should have > > the disttag removed IMO. > > Maybe some, but not necessarily all of them. Taking myself as an > example, I own some python modules that may certainly be better without > disttag, python on different Fedoras have different ABIs and different module installation paths, so even if a python noarch module you have to rebuild python modules from FC6 (2.4) to F7 (2.5). > but I also have C/C++ stuff that, although stable and unfrequently > updated are certainly better with a disttag. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 5 00:51:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 4 Jun 2007 20:51:31 -0400 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <20070605004652.GD11102@neu.nirvana> References: <20070604161025.GC15001@neu.nirvana> <20070604224245.5aa1b9fd.bugs.michael@gmx.net> <20070605004652.GD11102@neu.nirvana> Message-ID: <200706042051.31310.jkeating@redhat.com> On Monday 04 June 2007 20:46:52 Axel Thimm wrote: > So do a rebuild for test1. Which is well before the feature freeze and thus not really suitable for what you're trying to accomplish. -- 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 Jun 5 00:56:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 02:56:37 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <466476BC.90104@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> Message-ID: <20070605005637.GF11102@neu.nirvana> On Mon, Jun 04, 2007 at 04:31:56PM -0400, Christopher Aillon wrote: > Axel Thimm wrote: > >On Mon, Jun 04, 2007 at 04:09:05PM -0400, Christopher Aillon wrote: > >>I've seen bugs filed on packagers for not using the disttag before. We > >>should not encourage disttag everywhere, only where it makes sense. If > >>packages don't get updated once between releases, maybe the disttag is > >>not useful for that package and it's usage ought to be _dis_couraged in > >>this situation. > > > >That's a sane attitude and IMHO is the current state of affairs: If > >the packager identifies that he shares specfiles across releases he > >grabs disttags to be able to keep the specfiles the same and not have > >to cache integers for managing concurrent releases. > > My argument is that if packages don't get updated that often, disttag is > rather useless as the chances are low that it will get a fedora udpate > pushed. And on the off-chance it does, diverging a specfile once is not > a big deal. > > I think this is _NOT_ the current state of affairs else we would not > have as many .fc6 packages as we do in F-7. Those packages should have > the disttag removed IMO. Oh, but that's a self-fulfilling prophecy. As I posted some weeks ago the stats up to F7 were that Core would rebuild almost everthing (99-100%) and Extras was more on 98%. Until F7, where it was said that no rebuilds are neccessary, so people did not do rebuilds. Therefore looking at how many packages were not rebuild (<=20%) to deduce that a rebuild was not neccessary is a catch22. -- 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 Tue Jun 5 01:06:45 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 03:06:45 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070604223452.03309327.bugs.michael@gmx.net> References: <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> <20070604172043.GC18693@neu.nirvana> <20070604195733.d8caef1d.bugs.michael@gmx.net> <20070604185041.GF18693@neu.nirvana> <20070604214346.f43b34d0.bugs.michael@gmx.net> <20070604201504.GO18693@neu.nirvana> <20070604223452.03309327.bugs.michael@gmx.net> Message-ID: <20070605010645.GG11102@neu.nirvana> On Mon, Jun 04, 2007 at 10:34:52PM +0200, Michael Schwendt wrote: > On Mon, 4 Jun 2007 22:15:04 +0200, Axel Thimm wrote: > > > On Mon, Jun 04, 2007 at 09:43:46PM +0200, Michael Schwendt wrote: > > > > > > which is just the same as not having any disttags at all and led to > > > > > > the pain before the disttag. > > > > > > > > > > It's painless. Package is only updated when somebody maintains it. > > > > > > > > We hope all packages are maintained. :) > > > > > > > > Just introduce a package into FC6 and F7. And then have a security > > > > update. You start juggling around with reserving build tags like > > > > > > > > foo-1.2.3-1 (fc6) > > > > foo-1.2.3-2 (f7) > > > > > > > > fix: > > > > > > > > foo-1.2.3-3 (fc6) > > > > foo-1.2.3-4 (f7) > > > > > > or: > > > > > > foo-1.2.3-1.1 (fc6) > > > foo-1.2.3-2.1 (f7) > > > > > > foo-1.2.3-1.3 (fc6) > > > foo-1.2.3-2.2 (f7) > > > > > > foo-1.2.3-1.4 (fc6) > > > foo-1.2.3-2.2 (f7) > > > > > > It has worked fine for many package maintainers for many years. > > > > Don't talk about yourself in plural and in the 3rd person. ;) > > Keep moving closer to a "plonk" for this list. ;) Yes, Your Higness. I shall keep His remark firmly noted. ;) > > The above makes no real sense whatsoever, > > Why? Because the minor integers seem to be assigned quite randomly and even the last nevr is the same as the previous on in the second group. So you have at least a typo and the number still make no sense. > > you have effectively reverted the order of buildids and disttags. > > Elaborate. You use "-1.", "-2.", "-3." as disttags. But not I should elaborate on your choice of manual integer fiddling, you should! > > BTW if that were your intention (which you would have said so), it > > would make sense, I would just not agree on doing so: If the > > disttag is to take precedence above the release it needs to do so > > above the version, too, e..g it would become a prefix to the > > epoch. > > Pardon? What are you talking about? > > > And I left the best for the end: Where's support for F8/devel? > > foo-1.2.3-3.x? Or did the integers run out now? ;) > > All above or equal to 3 work fine for F8, pick either one, e.g.: So you are indeed moving the disttag as an integer to the front and you don't even realize it. > foo-1.2.3-3 (f8) > or: foo-1.2.3-4 (f8) > or: foo-1.2.3-8 (f8) > > to continue above list, another fix: > > foo-1.2.3-1.5 (fc6) > foo-1.2.3-2.3 (f7) > foo-1.2.3-3.1 (f8) > > If you insist on copying the f8 spec to f7 and fc6, you can still do that > with oh so many packages where it works. Adjusting %release is necessary, > but not difficult. But manual and error-prone. All because you just don't like disttags? Come on give us a break. Or a plonk. > > > And %dist does not help when bumping %version still breaks an > > > ISO-based dist-upgrade. > > > > I can't understand this at all. What does the media of the update > > have to do with it and why does a bump of %version break anything? > > Are you serious? Do you really don't see what role %dist plays in > conjunction with broken dist-upgrade paths? It has been the topic of > many old threads about pros and cons of %dist. I can see that, but what on earth does the ISO have to do in this discussion and what does the version bump do here? Can you explain your sidetracking or not? And please don't threaten with plonks, somehow your killfile seems to be periodically wiped out. Too often, if you ask me. -- 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 Tue Jun 5 01:19:03 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 03:19:03 +0200 Subject: was: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706042051.31310.jkeating@redhat.com> References: <20070604161025.GC15001@neu.nirvana> <20070604224245.5aa1b9fd.bugs.michael@gmx.net> <20070605004652.GD11102@neu.nirvana> <200706042051.31310.jkeating@redhat.com> Message-ID: <20070605011903.GH11102@neu.nirvana> On Mon, Jun 04, 2007 at 08:51:31PM -0400, Jesse Keating wrote: > On Monday 04 June 2007 20:46:52 Axel Thimm wrote: > > So do a rebuild for test1. > > Which is well before the feature freeze and thus not really suitable for what > you're trying to accomplish. Well, that was a reply to some comments from Michael which w/o a quote I can't even remember if it was ironic or meant that way. But if it were in my powers I'd have every test release be a full rebuild. Give the masses something to really test, don't spread the OS's age over several different build environments. FWIW ATrpms may be 1/10th of Fedora's size, but that's what ATrpms does for a couple of releases: Mass rebuilds for every test release. And bugs just show up waiting to be squashed. Why not squash Fedora's bugs just the same? -- 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 lmacken at redhat.com Tue Jun 5 01:22:17 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 4 Jun 2007 21:22:17 -0400 Subject: "Fedora Update System" makes comments into bugzilla and closes bugs In-Reply-To: <20070604094516.GD14907@neu.nirvana> References: <20070604094516.GD14907@neu.nirvana> Message-ID: <20070605012217.GO13318@tomservo.rochester.rr.com> On Mon, Jun 04, 2007 at 11:45:16AM +0200, Axel Thimm wrote: > which is just great! > > I didn't realize that the updates system had such a functionality, I > thought the bugzillas and cves should just be referenced for humans! > > The updates system is getting so much bashing these days, am I the > only one that really likes it? :=) > > (just a minor nitpicking if Luke's watching: the version's field in > CLOSED/*RELEASE should include the release, not only the version > field) Thanks Axel, I fixed this in my development branch. I'll upgrade our production instance this evening. luke From lmacken at redhat.com Tue Jun 5 01:29:08 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 4 Jun 2007 21:29:08 -0400 Subject: "Fedora Update System" makes comments into bugzilla and closes bugs In-Reply-To: <51567.202.154.148.243.1180955293.squirrel@webmail.nigelj.com> References: <20070604094516.GD14907@neu.nirvana> <20070604095548.GE14907@neu.nirvana> <51365.202.154.148.243.1180953612.squirrel@webmail.nigelj.com> <20070604104809.GH14907@neu.nirvana> <51567.202.154.148.243.1180955293.squirrel@webmail.nigelj.com> Message-ID: <20070605012908.GP13318@tomservo.rochester.rr.com> On Mon, Jun 04, 2007 at 11:08:13PM +1200, Nigel Jones wrote: > Things like "what on earth is the next step" and stuff like sorting based > on coloum etc. But I'm not too concerned. The AJAX for completing the > NVR is extremely handy though. Yeah, and it'll get better soon. At the moment it just pulls a list of all builds available for that package, including ones that aren't tagged with dist-*-updates-candidate. I'm going to eventually make it only show builds that are valid update candidates. luke From bpepple at fedoraproject.org Tue Jun 5 01:53:48 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 04 Jun 2007 21:53:48 -0400 Subject: FESCo Meeting Summary for 2007-05-31 Message-ID: <1181008428.2819.0.camel@kennedy> 2007 May 31 FESCo Meeting Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jeremy Katz (jeremy) * Tom Callaway (spot) * Rex Dieter (rdieter) * Christian Iseli (c4chris) * Josh Boyer (jwb) * Warren Togami (warren) * == Summary == Various Static Libs * FESCo approved the proposal for a blanket exception for packages which link against flex's libfl.a * FESCo voted against a proposal for linking ipsvd statically against dietlibc. * FESCo voted against a proposal against statically link libgcrypt into gaim-otr. ACL's * Long discussion on how to solve some of our problems with the usage of acl's, which prevent people from fixing simple things like evr problems. * For the interim, until a more permanent solution is implemented, tibbs & nirik have been given cvsadmin access, and if there are other Fedora contributors that commonly help out with such issue, and wish to also be given access please contact FESCo. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070531 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 lmacken at redhat.com Tue Jun 5 02:03:02 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 4 Jun 2007 22:03:02 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180967010.8453.23.camel@localhost.localdomain> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180967010.8453.23.camel@localhost.localdomain> Message-ID: <20070605020302.GQ13318@tomservo.rochester.rr.com> On Mon, Jun 04, 2007 at 10:23:30AM -0400, Adam Jackson wrote: [...] > In particular, the automatic display of package tags in the NEVR box > means I owe someone a beer. That's just hot. I'll hit you up for that in September :) luke From caillon at redhat.com Tue Jun 5 03:02:05 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 04 Jun 2007 23:02:05 -0400 Subject: libwnck soname up In-Reply-To: <1180992220.25009.145.camel@cookie.hadess.net> References: <1180988927.25009.136.camel@cookie.hadess.net> <466477D2.8050903@redhat.com> <1180990691.25009.143.camel@cookie.hadess.net> <46647E34.7080304@redhat.com> <1180992220.25009.145.camel@cookie.hadess.net> Message-ID: <4664D22D.6080404@redhat.com> Bastien Nocera wrote: > On Mon, 2007-06-04 at 17:03 -0400, Havoc Pennington wrote: >> That change doesn't seem worth the pain of a soname bump to me but I >> will leave someone else to argue that point ;-) > > And filed upstream: > http://bugzilla.gnome.org/show_bug.cgi?id=444119 > > Hopefully, we'll get an answer before somebody finds a solution for the > libnotify cyclic dependency. Looks like mclasen went ahead and re-built everything so I guess this is kind of moot. Might as well let other distros suffer at this point. :-) From mtasaka at ioa.s.u-tokyo.ac.jp Tue Jun 5 03:12:00 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 05 Jun 2007 12:12:00 +0900 Subject: "Fedora Update System" makes comments into bugzilla and closes bugs In-Reply-To: <20070604094516.GD14907@neu.nirvana> References: <20070604094516.GD14907@neu.nirvana> Message-ID: <4664D480.6000205@ioa.s.u-tokyo.ac.jp> Axel Thimm wrote, at 06/04/2007 06:45 PM +9:00: > which is just great! > > I didn't realize that the updates system had such a functionality, I > thought the bugzillas and cves should just be referenced for humans! > > The updates system is getting so much bashing these days, am I the > only one that really likes it? :=) > > (just a minor nitpicking if Luke's watching: the version's field in > CLOSED/*RELEASE should include the release, not only the version > field) > One more comment: ------------------------------------------------------------ https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242349 updates at fedoraproject.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |CLOSED Resolution|ERRATA |NEXTRELEASE Fixed In Version|0.4-2 |0.4 ------------------------------------------------------------ Well, in this case, I closed this bug by myself as CLOSED ERRATA, and after that updates system changed the resolution. I think that there is a general confusion about NEXTRELEASE and ERRATA, but in this case RESOLUITON must be *ERRATA*, not *NEXTRELEASE*!! QUOTED: NEXTRELEASE The problem described has been fixed *in the next release of the product*, and *is not planned to be fixed in the release against which the bug was filed*. Include information on the release in which this was fixed in the summary when a bug is closed to this resolution. ERRATA The problem described has been fixed and will be available as an errata update from our support web site. Please check the site to see if it is currently available for download. And. as Axel commented, "Fixed In Version" should contain Version-Release information. Regards, Mamoru From lmacken at redhat.com Tue Jun 5 05:28:06 2007 From: lmacken at redhat.com (Luke Macken) Date: Tue, 5 Jun 2007 01:28:06 -0400 Subject: "Fedora Update System" makes comments into bugzilla and closes bugs In-Reply-To: <4664D480.6000205@ioa.s.u-tokyo.ac.jp> References: <20070604094516.GD14907@neu.nirvana> <4664D480.6000205@ioa.s.u-tokyo.ac.jp> Message-ID: <20070605052806.GV13318@tomservo.rochester.rr.com> On Tue, Jun 05, 2007 at 12:12:00PM +0900, Mamoru Tasaka wrote: > One more comment: [...] > Well, in this case, I closed this bug by myself as CLOSED ERRATA, and after that > updates system changed the resolution. I think that there is a general confusion > about NEXTRELEASE and ERRATA, but in this case RESOLUITON must be *ERRATA*, > not *NEXTRELEASE*!! Fixed. luke From bos at serpentine.com Tue Jun 5 06:03:32 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon, 04 Jun 2007 23:03:32 -0700 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706041203.58789.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706041154.51507.jkeating@redhat.com> <46643780.7000303@fedoraproject.org> <200706041203.58789.jkeating@redhat.com> Message-ID: <4664FCB4.2000509@serpentine.com> Jesse Keating wrote: > If someone installs the RC version and they just want to get to the Final > version when it's released, they do nothing except 'yum update' when the > final version is released. On a related note, I was running rawhide between test2 and F7 final. But yum didn't pick up any change to the fedora-release package, which left me picking up the first round of fc8 rebuilds after the dam broke, because I was still being pointed at the development repos. I spent a few hours on different machines downloading the F7 final packages that had been updated and manually rolling them back with "rpm -U --oldpackage". Ugh. References: <20070604094516.GD14907@neu.nirvana> <51567.202.154.148.243.1180955293.squirrel@webmail.nigelj.com> <20070605012908.GP13318@tomservo.rochester.rr.com> Message-ID: <200706050945.22542.ville.skytta@iki.fi> On Tuesday 05 June 2007, Luke Macken wrote: > On Mon, Jun 04, 2007 at 11:08:13PM +1200, Nigel Jones wrote: > > Things like "what on earth is the next step" and stuff like sorting based > > on coloum etc. But I'm not too concerned. The AJAX for completing the > > NVR is extremely handy though. > > Yeah, and it'll get better soon. At the moment it just pulls a list of > all builds available for that package, including ones that aren't tagged > with dist-*-updates-candidate. I'm going to eventually make it only > show builds that are valid update candidates. The feature is handy, that's right, but I'm having some problems with the popup list staying visible long enough to get something in it selected. No idea why, and I'm not doing anything else at the moment I'm trying to make a selection or waiting for the popup to appear. This is with Firefox 1.5.0.12 on x86_64 FC6, KDE. From caillon at redhat.com Tue Jun 5 07:07:33 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 05 Jun 2007 03:07:33 -0400 Subject: "Fedora Update System" makes comments into bugzilla and closes bugs In-Reply-To: <200706050945.22542.ville.skytta@iki.fi> References: <20070604094516.GD14907@neu.nirvana> <51567.202.154.148.243.1180955293.squirrel@webmail.nigelj.com> <20070605012908.GP13318@tomservo.rochester.rr.com> <200706050945.22542.ville.skytta@iki.fi> Message-ID: <46650BB5.1040507@redhat.com> Ville Skytt? wrote: > The feature is handy, that's right, but I'm having some problems with the > popup list staying visible long enough to get something in it selected. No > idea why, and I'm not doing anything else at the moment I'm trying to make a > selection or waiting for the popup to appear. This is with Firefox 1.5.0.12 > on x86_64 FC6, KDE. I wonder if this is because it's trying to poll too much for packages. I've noticed the same, so it's not just you. I think the ideal implementation would involve koji notifying bodhi when a build is done in a collection/tag it cares about, bodhi would then prepopulate a local database with the available builds and which collection, etc it goes into. Then when the package is pushed, it punts it from the list. An additional optimization (unsure how needed this is), would be each time the database changes, to regenerate the JavaScript file so that there's less time spent waiting for DB queries. From pertusus at free.fr Tue Jun 5 07:32:04 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 5 Jun 2007 09:32:04 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070605005136.GE11102@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <20070605005136.GE11102@neu.nirvana> Message-ID: <20070605073204.GB5736@free.fr> On Tue, Jun 05, 2007 at 02:51:36AM +0200, Axel Thimm wrote: > > python on different Fedoras have different ABIs and different module > installation paths, so even if a python noarch module you have to > rebuild python modules from FC6 (2.4) to F7 (2.5). Sure, but in my recalling this happens less often than changes in the C/C++ build chain, so it may be more worth not having disttag to limit unneeded updates. -- Pat From rc040203 at freenet.de Tue Jun 5 07:52:08 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Jun 2007 09:52:08 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <46647C92.2000700@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> Message-ID: <1181029928.27239.43.camel@mccallum.corsepiu.local> On Mon, 2007-06-04 at 16:56 -0400, Christopher Aillon wrote: > Patrice Dumas wrote: > > On Mon, Jun 04, 2007 at 04:31:56PM -0400, Christopher Aillon wrote: > >> > >> My argument is that if packages don't get updated that often, disttag is > >> rather useless as the chances are low that it will get a fedora udpate > >> pushed. And on the off-chance it does, diverging a specfile once is not > >> a big deal. > >> > >> I think this is _NOT_ the current state of affairs else we would not > >> have as many .fc6 packages as we do in F-7. Those packages should have > >> the disttag removed IMO. > > > > Maybe some, but not necessarily all of them. Taking myself as an > > example, I own some python modules that may certainly be better without > > disttag, but I also have C/C++ stuff that, although stable and > > unfrequently updated are certainly better with a disttag. > > Why is it better with a disttag, out of curiosity? In many cases it's: Though spec files are identical the contents of the binary rpms aren't. directories change (e.g. %_*dir), deps change etc. Ralf From Axel.Thimm at ATrpms.net Tue Jun 5 07:56:20 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 09:56:20 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605073204.GB5736@free.fr> References: <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <20070605005136.GE11102@neu.nirvana> <20070605073204.GB5736@free.fr> Message-ID: <20070605075620.GC23972@neu.nirvana> On Tue, Jun 05, 2007 at 09:32:04AM +0200, Patrice Dumas wrote: > On Tue, Jun 05, 2007 at 02:51:36AM +0200, Axel Thimm wrote: > > > > python on different Fedoras have different ABIs and different module > > installation paths, so even if a python noarch module you have to > > rebuild python modules from FC6 (2.4) to F7 (2.5). > > Sure, but in my recalling this happens less often than changes in the > C/C++ build chain, so it may be more worth not having disttag to limit > unneeded updates. It's about yearly or every other Fedora release. Or twice during the RHEL release cycle. We do want to support upgrading from FC to FC starting with N=5, so it is definitely within our range. Otherwise the transition from FC6 to F7 would had cost *all* python modules to be forked on the specfile level. There is no need to do so by just using the disttag. -- 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 jsafrane at redhat.com Tue Jun 5 08:21:40 2007 From: jsafrane at redhat.com (Jan Safranek) Date: Tue, 05 Jun 2007 10:21:40 +0200 Subject: Bodhi returns 500 Internal Error when submitting new update Message-ID: <1181031700.3911.30.camel@dhcp-lab-214.brq.redhat.com> Greetings, I would like to update xinetd package in F7. I built it few weeks ago [1] during devel. freeze and now I want to publish it. I log into https://admin.fedoraproject.org/updates/, press 'New update' and fill the form: Package: xinetd-2.3.14-12.fc7 Release: Fedora7 Type: bugfix Bugs: 195265 CVEs: Notes: Now, when pressing 'Submit', I get 500 Internal error. Any ideas what could be wrong? Thanks in advance Jan [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=6707 From caillon at redhat.com Tue Jun 5 08:32:51 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 05 Jun 2007 04:32:51 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <1181029928.27239.43.camel@mccallum.corsepiu.local> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> Message-ID: <46651FB3.6050000@redhat.com> Ralf Corsepius wrote: > On Mon, 2007-06-04 at 16:56 -0400, Christopher Aillon wrote: >> Patrice Dumas wrote: >> > On Mon, Jun 04, 2007 at 04:31:56PM -0400, Christopher Aillon wrote: >> >> >> >> My argument is that if packages don't get updated that often, disttag is >> >> rather useless as the chances are low that it will get a fedora udpate >> >> pushed. And on the off-chance it does, diverging a specfile once is not >> >> a big deal. >> >> >> >> I think this is _NOT_ the current state of affairs else we would not >> >> have as many .fc6 packages as we do in F-7. Those packages should have >> >> the disttag removed IMO. >> > >> > Maybe some, but not necessarily all of them. Taking myself as an >> > example, I own some python modules that may certainly be better without >> > disttag, but I also have C/C++ stuff that, although stable and >> > unfrequently updated are certainly better with a disttag. >> >> Why is it better with a disttag, out of curiosity? > In many cases it's: Though spec files are identical the contents of the > binary rpms aren't. directories change (e.g. %_*dir), deps change etc. You're missing the point. If a package is only updated e.g. once a year, and that one update is only for e.g. glibc ABI changes -- guess what, ABI in a release (Zod, Moonshine, etc) isn't changing so there's no need to rebuild that. Just bump in rawhide and rebuild there. disttag doesn't gain you anything here in the branches. From bnocera at redhat.com Tue Jun 5 09:08:55 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 05 Jun 2007 10:08:55 +0100 Subject: libwnck soname up In-Reply-To: <4664D22D.6080404@redhat.com> References: <1180988927.25009.136.camel@cookie.hadess.net> <466477D2.8050903@redhat.com> <1180990691.25009.143.camel@cookie.hadess.net> <46647E34.7080304@redhat.com> <1180992220.25009.145.camel@cookie.hadess.net> <4664D22D.6080404@redhat.com> Message-ID: <1181034535.25009.157.camel@cookie.hadess.net> On Mon, 2007-06-04 at 23:02 -0400, Christopher Aillon wrote: > Looks like mclasen went ahead and re-built everything so I guess this is > kind of moot. Might as well let other distros suffer at this point. :-) He fights crime when I'm sleeping, he's my hero. From Axel.Thimm at ATrpms.net Tue Jun 5 09:16:44 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 11:16:44 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <46651FB3.6050000@redhat.com> References: <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> Message-ID: <20070605091644.GF23972@neu.nirvana> On Tue, Jun 05, 2007 at 04:32:51AM -0400, Christopher Aillon wrote: > Ralf Corsepius wrote: > >On Mon, 2007-06-04 at 16:56 -0400, Christopher Aillon wrote: > >>Patrice Dumas wrote: > >>> On Mon, Jun 04, 2007 at 04:31:56PM -0400, Christopher Aillon wrote: > >>>> > >>>> My argument is that if packages don't get updated that often, disttag > >>is >> rather useless as the chances are low that it will get a fedora > >>udpate >> pushed. And on the off-chance it does, diverging a specfile > >>once is not >> a big deal. > >>>> > >>>> I think this is _NOT_ the current state of affairs else we would not > >>>> have as many .fc6 packages as we do in F-7. Those packages should > >>have >> the disttag removed IMO. > >>> > >>> Maybe some, but not necessarily all of them. Taking myself as an > >>> example, I own some python modules that may certainly be better without > >>> disttag, but I also have C/C++ stuff that, although stable and > >>> unfrequently updated are certainly better with a disttag. > >> > >>Why is it better with a disttag, out of curiosity? > >In many cases it's: Though spec files are identical the contents of the > >binary rpms aren't. directories change (e.g. %_*dir), deps change etc. > > You're missing the point. If a package is only updated e.g. once a > year, So you know beforehand how often a package will be updated in the future? > and that one update is only for e.g. glibc ABI changes -- guess > what, ABI in a release (Zod, Moonshine, etc) isn't changing Not true, for Zod -> Moonshine this was a first timer. And had gcc 4.2 landed in the usual timeframe (was expected around December) we wouldn't even be talking about rebuilds. gcc 4.2 which is now almost a month old will most probably make it into F8 very soon. > so there's no need to rebuild that. Just bump in rawhide and > rebuild there. disttag doesn't gain you anything here in the > branches. Let's revert the question: "Why is it better without a disttag, out of curiosity?". There is definitely a gain with a disttag, one can argue how big it is, but what are the drawbacks? That some packages give away their age? I see that as a feature, not a bug: "Hey, bridge-utils is broken on F7. Hm, it has an fc6 marker. OK, it was built on FC6's kernel-headers from 2.6.18, no wonder it doesn't know anything about 2.6.21" Bottom points: o full rebuilds should become a must o disttags are helpful either way -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Tue Jun 5 09:35:24 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 5 Jun 2007 11:35:24 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605075620.GC23972@neu.nirvana> References: <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <20070605005136.GE11102@neu.nirvana> <20070605073204.GB5736@free.fr> <20070605075620.GC23972@neu.nirvana> Message-ID: <20070605093524.GA2832@free.fr> On Tue, Jun 05, 2007 at 09:56:20AM +0200, Axel Thimm wrote: > On Tue, Jun 05, 2007 at 09:32:04AM +0200, Patrice Dumas wrote: > > On Tue, Jun 05, 2007 at 02:51:36AM +0200, Axel Thimm wrote: > > > > > > python on different Fedoras have different ABIs and different module > > > installation paths, so even if a python noarch module you have to > > > rebuild python modules from FC6 (2.4) to F7 (2.5). > > > > Sure, but in my recalling this happens less often than changes in the > > C/C++ build chain, so it may be more worth not having disttag to limit > > unneeded updates. > > It's about yearly or every other Fedora release. Or twice during the > RHEL release cycle. We do want to support upgrading from FC to > FC starting with N=5, so it is definitely within our range. It has advantages, but in my opinion this is clearly a case where the balance is not completly self evident and should be left to the packager (it should always be left to the packager, but the balance may be on one side or the other more clearly in other cases). -- Pat From Axel.Thimm at ATrpms.net Tue Jun 5 09:44:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 11:44:13 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605093524.GA2832@free.fr> References: <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <20070605005136.GE11102@neu.nirvana> <20070605073204.GB5736@free.fr> <20070605075620.GC23972@neu.nirvana> <20070605093524.GA2832@free.fr> Message-ID: <20070605094413.GH23972@neu.nirvana> On Tue, Jun 05, 2007 at 11:35:24AM +0200, Patrice Dumas wrote: > On Tue, Jun 05, 2007 at 09:56:20AM +0200, Axel Thimm wrote: > > On Tue, Jun 05, 2007 at 09:32:04AM +0200, Patrice Dumas wrote: > > > On Tue, Jun 05, 2007 at 02:51:36AM +0200, Axel Thimm wrote: > > > > > > > > python on different Fedoras have different ABIs and different module > > > > installation paths, so even if a python noarch module you have to > > > > rebuild python modules from FC6 (2.4) to F7 (2.5). > > > > > > Sure, but in my recalling this happens less often than changes in the > > > C/C++ build chain, so it may be more worth not having disttag to limit > > > unneeded updates. > > > > It's about yearly or every other Fedora release. Or twice during the > > RHEL release cycle. We do want to support upgrading from FC to > > FC starting with N=5, so it is definitely within our range. > > It has advantages, but in my opinion this is clearly a case where the > balance is not completly self evident and should be left to the packager > (it should always be left to the packager, but the balance may be on one > side or the other more clearly in other cases). Well, that's the case, disttags were never enforced, they made it into the majority of packages (89% with a 10% increase on each release for th epast 3 releases) because they are useful. If the maintainer of a package wants to use an integer cache in his basement, he's free to do so. He'll just get virtually kicked in the ass when his manual and error-prone procedure fails, until then everybody and his rabbit is happy. -- 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 Tue Jun 5 09:45:41 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Jun 2007 11:45:41 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <46651FB3.6050000@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> Message-ID: <1181036742.27239.66.camel@mccallum.corsepiu.local> On Tue, 2007-06-05 at 04:32 -0400, Christopher Aillon wrote: > Ralf Corsepius wrote: > > On Mon, 2007-06-04 at 16:56 -0400, Christopher Aillon wrote: > >> Patrice Dumas wrote: > >> > On Mon, Jun 04, 2007 at 04:31:56PM -0400, Christopher Aillon wrote: > >> >> > >> >> My argument is that if packages don't get updated that often, disttag is > >> >> rather useless as the chances are low that it will get a fedora udpate > >> >> pushed. And on the off-chance it does, diverging a specfile once is not > >> >> a big deal. > >> >> > >> >> I think this is _NOT_ the current state of affairs else we would not > >> >> have as many .fc6 packages as we do in F-7. Those packages should have > >> >> the disttag removed IMO. > >> > > >> > Maybe some, but not necessarily all of them. Taking myself as an > >> > example, I own some python modules that may certainly be better without > >> > disttag, but I also have C/C++ stuff that, although stable and > >> > unfrequently updated are certainly better with a disttag. > >> > >> Why is it better with a disttag, out of curiosity? > > In many cases it's: Though spec files are identical the contents of the > > binary rpms aren't. directories change (e.g. %_*dir), deps change etc. > > You're missing the point. I think, I am not ... > If a package is only updated e.g. once a > year, and that one update is only for e.g. glibc ABI changes -- guess > what, ABI in a release (Zod, Moonshine, etc) isn't changing so there's > no need to rebuild that. The %dist tags assure a steady upgrade path on packages' EVRs between distros. ABI's, API or SONAME changes etc. are not connected to %dist at all. It's mere maintainer's convenience wrt. EVR consistency, nothing else. > Just bump in rawhide and rebuild there. > disttag doesn't gain you anything here in the branches. Right, but it does when upgrading older distros. Eg. say, you released package-0.9-1 in FC6 and package-1.0-1 in FC-7. Applying your rationale, package-1.0 must use package-1.0-2 in rawhide, otherwise the upgrade path from FC7->FC8 is not assured. Now, a critical bug has been discovered in package-0.9, and upstream advises to upgrade to package-1.0. To be able to do so for FC6, you'll have to use a release number < 1 (otherwise the upgrade path from FC6->FC7 won't work). Using %dist for FC7 would have allowed to you to simply drop you package.spec from FC7 into FC6 and rebuild == convenience. Now, this doesn't make much of a difference when maintaining "a few packages", but it does when maintaining several dozens. Also the "update" strategy a maintainer applies makes a difference, e.g. wrt. perl packages, bug fixes usually are provided by upstream (CPAN). I.e. the usual perl update/bug-fixing strategy is to upgrade older packages to newer versions. Here, %dist is a massive relief to maintain specs, because each the perl-installation directories diverge between releases. It's the same wrt. your packages, e.g. there would not be any EVR probs with your firefox packages if you'd apply %dist. Ralf From bugs.michael at gmx.net Tue Jun 5 09:54:41 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Jun 2007 11:54:41 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <20070605004652.GD11102@neu.nirvana> References: <20070604161025.GC15001@neu.nirvana> <1180973691.6254.633.camel@localhost.localdomain> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <20070604185627.GG18693@neu.nirvana> <20070604212731.ad205641.bugs.michael@gmx.net> <20070604193358.GL18693@neu.nirvana> <20070604220637.825b90e2.bugs.michael@gmx.net> <20070604202143.GP18693@neu.nirvana> <20070604224245.5aa1b9fd.bugs.michael@gmx.net> <20070605004652.GD11102@neu.nirvana> Message-ID: <20070605115441.36c38ce9.bugs.michael@gmx.net> On Tue, 5 Jun 2007 02:46:52 +0200, Axel Thimm wrote: > > > I think I'll start assigning all bugs that show up due to missing > > > rebuilds to Michael. :) > > > > Do you keep a list already? Put it in the Wiki, and I'm certain, > > more people will take a close look at it. > > No, assigning to you will be more fun. ;) Where is the funny part of it? You plan something in bugzilla which you believe will annoy me. Guerrilla tactics. If you are serious about doing such things, your sponsor ought to watch you. If you just play with words here, the boring end of this thread has been reached finally. I understand a lot of fun, but I just don't see the goal of your plans. Certainly various people would be interested in learning about facts that might help in deciding on an adjusted roadmap. So, if you know about bugs which an unattended rebuild would have fixed, document it somewhere, please, so it can be evaluated. Mail, Wiki, tracker bug, whatever seems appropriate. Perhaps you've missed some of the development at Fedora. I'm not anymore involved in a position like FESCo where I'm a target which you believe is easy and worthwhile to point the finger at. Policies and guidelines are signed by other people and proposed by even different people. Even in the past multiple people have made the decisions and not just me. Get over it. From rc040203 at freenet.de Tue Jun 5 09:58:59 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Jun 2007 11:58:59 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605091644.GF23972@neu.nirvana> References: <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> <20070605091644.GF23972@neu.nirvana> Message-ID: <1181037539.27239.76.camel@mccallum.corsepiu.local> On Tue, 2007-06-05 at 11:16 +0200, Axel Thimm wrote: > Let's revert the question: "Why is it better without a disttag, out of > curiosity?". There is definitely a gain with a disttag, one can argue > how big it is, but what are the drawbacks? Exactly. At least to me both as a maintainer and as user the pros by way outweigh the cons. So far, the only "con" I came across is lack of clear conventions on %release in those (rare) occasions a package's EVR has to walk "sideways" (X.fcN -> X.fcN.1, X.fcN.2). > Bottom points: > o full rebuilds should become a must Well, I can only reiterate what I said before: IMO, "full rebuilds" are a hoax blending yourself unless they are performed in "sorted order" and a PITA to maintainers unless they are performed automatically. > o disttags are helpful either way Right. Ralf From bugs.michael at gmx.net Tue Jun 5 10:03:47 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Jun 2007 12:03:47 +0200 Subject: was: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070605011903.GH11102@neu.nirvana> References: <20070604161025.GC15001@neu.nirvana> <20070604224245.5aa1b9fd.bugs.michael@gmx.net> <20070605004652.GD11102@neu.nirvana> <200706042051.31310.jkeating@redhat.com> <20070605011903.GH11102@neu.nirvana> Message-ID: <20070605120347.82043a94.bugs.michael@gmx.net> On Tue, 5 Jun 2007 03:19:03 +0200, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 08:51:31PM -0400, Jesse Keating wrote: > > On Monday 04 June 2007 20:46:52 Axel Thimm wrote: > > > So do a rebuild for test1. > > > > Which is well before the feature freeze and thus not really suitable for what > > you're trying to accomplish. > > Well, that was a reply to some comments from Michael which w/o a quote > I can't even remember if it was ironic or meant that way. Which is one of the fundamental problems whenever we meet eachother. I don't have bad intentions or interest in non-obvious ironic comments (not in #240835 either). Here's the quote, some comments below: | If we somehow try to prepare binaries right in time before test1 in | accordance with a clear roadmap, I'm fine with that. I still would like to | see maintainers be the ones to touch packages if they need to be touched | and not just for rebuild-fun. It could be either one: A scheduled deadline in the roadmap with a request to maintainers to [at least] try rebuilding their packages once in a given period. Or a mass-rebuild like those Matt Domsch has done separately, but which publishes successful rebuilds in rawhide and collects build failure logs somewhere. In either case, I would prefer if the maintainers or co-maintainers had to push a button in that procedure. Such an attempt at touching/updating packages early, e.g. right in time before test1, is not to be understood as a freeze or final rebuild. It's just an event to test how many packages still build. From jonathan.underwood at gmail.com Tue Jun 5 10:05:19 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 5 Jun 2007 11:05:19 +0100 Subject: Disttags are nice, save the disttags In-Reply-To: <1181037539.27239.76.camel@mccallum.corsepiu.local> References: <1180965652.2883.4.camel@kennedy> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> <20070605091644.GF23972@neu.nirvana> <1181037539.27239.76.camel@mccallum.corsepiu.local> Message-ID: <645d17210706050305v5de9f0b4yd874842cfa9c362d@mail.gmail.com> On 05/06/07, Ralf Corsepius wrote: > > Well, I can only reiterate what I said before: IMO, "full rebuilds" are > a hoax blending yourself unless they are performed in "sorted order" > and a PITA to maintainers unless they are performed automatically. Aside: presumably CentOS and Scientific Linux etc have solved the full rebuild in order problem. Perhaps it's worth looking at their buildsystem. J From Axel.Thimm at ATrpms.net Tue Jun 5 10:06:12 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 12:06:12 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <20070605115441.36c38ce9.bugs.michael@gmx.net> References: <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <20070604185627.GG18693@neu.nirvana> <20070604212731.ad205641.bugs.michael@gmx.net> <20070604193358.GL18693@neu.nirvana> <20070604220637.825b90e2.bugs.michael@gmx.net> <20070604202143.GP18693@neu.nirvana> <20070604224245.5aa1b9fd.bugs.michael@gmx.net> <20070605004652.GD11102@neu.nirvana> <20070605115441.36c38ce9.bugs.michael@gmx.net> Message-ID: <20070605100612.GI23972@neu.nirvana> On Tue, Jun 05, 2007 at 11:54:41AM +0200, Michael Schwendt wrote: > On Tue, 5 Jun 2007 02:46:52 +0200, Axel Thimm wrote: > > > > > I think I'll start assigning all bugs that show up due to missing > > > > rebuilds to Michael. :) > > > > > > Do you keep a list already? Put it in the Wiki, and I'm certain, > > > more people will take a close look at it. > > > > No, assigning to you will be more fun. ;) > > Where is the funny part of it? > > You plan something in bugzilla which you believe will annoy me. Guerrilla > tactics. If you are serious about doing such things, your sponsor ought to > watch you. If you just play with words here, the boring end of this thread > has been reached finally. I understand a lot of fun, but I just don't see > the goal of your plans. My sponsor is watching me like Big Brother (not the modern TV stuff, but the real Big Brother). Of course I'm not going to assign these bugs to you. Do you need a smiley as big as your screen to understand humor? > Certainly various people would be interested in learning about facts that > might help in deciding on an adjusted roadmap. So, if you know about bugs > which an unattended rebuild would have fixed, document it somewhere, > please, so it can be evaluated. Mail, Wiki, tracker bug, whatever seems > appropriate. Read my lips^Wmails. It's all in there. There is no bugzilla, because when I find something I just fix it and send a note to the list. > Perhaps you've missed some of the development at Fedora. I'm not anymore > involved in a position like FESCo where I'm a target which you believe is > easy and worthwhile to point the finger at. Policies and guidelines are > signed by other people and proposed by even different people. Even in the > past multiple people have made the decisions and not just me. Get over > it. I wasn't even aware you were once in the fesco. These must had been hard times for everyone ;) Anyway it's not my finger pointing to you, it's your nose stucking everywhere. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Tue Jun 5 10:14:03 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Jun 2007 12:14:03 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070605010645.GG11102@neu.nirvana> References: <20070604161025.GC15001@neu.nirvana> <46643BBC.40609@leemhuis.info> <20070604165621.GA18693@neu.nirvana> <466447B2.1070105@leemhuis.info> <20070604172043.GC18693@neu.nirvana> <20070604195733.d8caef1d.bugs.michael@gmx.net> <20070604185041.GF18693@neu.nirvana> <20070604214346.f43b34d0.bugs.michael@gmx.net> <20070604201504.GO18693@neu.nirvana> <20070604223452.03309327.bugs.michael@gmx.net> <20070605010645.GG11102@neu.nirvana> Message-ID: <20070605121403.a6423705.bugs.michael@gmx.net> On Tue, 5 Jun 2007 03:06:45 +0200, Axel Thimm wrote: > On Mon, Jun 04, 2007 at 10:34:52PM +0200, Michael Schwendt wrote: > > On Mon, 4 Jun 2007 22:15:04 +0200, Axel Thimm wrote: > > > > > On Mon, Jun 04, 2007 at 09:43:46PM +0200, Michael Schwendt wrote: > > > > > > > which is just the same as not having any disttags at all and led to > > > > > > > the pain before the disttag. > > > > > > > > > > > > It's painless. Package is only updated when somebody maintains it. > > > > > > > > > > We hope all packages are maintained. :) > > > > > > > > > > Just introduce a package into FC6 and F7. And then have a security > > > > > update. You start juggling around with reserving build tags like > > > > > > > > > > foo-1.2.3-1 (fc6) > > > > > foo-1.2.3-2 (f7) > > > > > > > > > > fix: > > > > > > > > > > foo-1.2.3-3 (fc6) > > > > > foo-1.2.3-4 (f7) > > > > > > > > or: > > > > > > > > foo-1.2.3-1.1 (fc6) > > > > foo-1.2.3-2.1 (f7) > > > > > > > > foo-1.2.3-1.3 (fc6) > > > > foo-1.2.3-2.2 (f7) > > > > > > > > foo-1.2.3-1.4 (fc6) > > > > foo-1.2.3-2.2 (f7) > > > > > > > > It has worked fine for many package maintainers for many years. > > > > > > Don't talk about yourself in plural and in the 3rd person. ;) See bottom. > > Keep moving closer to a "plonk" for this list. ;) > > Yes, Your Higness. I shall keep His remark firmly noted. ;) > > > > The above makes no real sense whatsoever, > > > > Why? > > Because the minor integers seem to be assigned quite randomly and even > the last nevr is the same as the previous on in the second group. So > you have at least a typo and the number still make no sense. It does. > > > you have effectively reverted the order of buildids and disttags. > > > > Elaborate. > > You use "-1.", "-2.", "-3." as disttags. The scheme above does not even know what a dist tag is. It is a pure package release based scheme. > But not I should elaborate on > your choice of manual integer fiddling, you should! In your view, a spec is exactly the same for all dist releases. In this scheme, it need not be the same. > Come on give us a break. Or a plonk. "us"? -- This message reminded me of a certain thread of fab-list from March this year. From pertusus at free.fr Tue Jun 5 10:08:55 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 5 Jun 2007 12:08:55 +0200 Subject: was: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070605120347.82043a94.bugs.michael@gmx.net> References: <20070604161025.GC15001@neu.nirvana> <20070604224245.5aa1b9fd.bugs.michael@gmx.net> <20070605004652.GD11102@neu.nirvana> <200706042051.31310.jkeating@redhat.com> <20070605011903.GH11102@neu.nirvana> <20070605120347.82043a94.bugs.michael@gmx.net> Message-ID: <20070605100855.GB2832@free.fr> On Tue, Jun 05, 2007 at 12:03:47PM +0200, Michael Schwendt wrote: > > It could be either one: A scheduled deadline in the roadmap with a request > to maintainers to [at least] try rebuilding their packages once in a given > period. Or a mass-rebuild like those Matt Domsch has done separately, but > which publishes successful rebuilds in rawhide and collects build failure > logs somewhere. In either case, I would prefer if the maintainers or > co-maintainers had to push a button in that procedure. Such an attempt at > touching/updating packages early, e.g. right in time before test1, is not > to be understood as a freeze or final rebuild. It's just an event to > test how many packages still build. And also have a possibility to test those rebuilt packages before the release such that some time for testing is left, but it is sufficiently late such that the build environment is somehow stabilized. -- Pat From Axel.Thimm at ATrpms.net Tue Jun 5 10:12:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 12:12:29 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <645d17210706050305v5de9f0b4yd874842cfa9c362d@mail.gmail.com> References: <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> <20070605091644.GF23972@neu.nirvana> <1181037539.27239.76.camel@mccallum.corsepiu.local> <645d17210706050305v5de9f0b4yd874842cfa9c362d@mail.gmail.com> Message-ID: <20070605101229.GJ23972@neu.nirvana> On Tue, Jun 05, 2007 at 11:05:19AM +0100, Jonathan Underwood wrote: > On 05/06/07, Ralf Corsepius wrote: > > > >Well, I can only reiterate what I said before: IMO, "full rebuilds" are > >a hoax blending yourself unless they are performed in "sorted order" > >and a PITA to maintainers unless they are performed automatically. > > Aside: presumably CentOS and Scientific Linux etc have solved the full > rebuild in order problem. Perhaps it's worth looking at their > buildsystem. Oh, that's touchy subject. Not because of CentOS and SL, but because RHEL is all but self-hosting. Some parts have been taken from FC6 (~15%), so they have been built in some FC6 environment, others from not anymore existing gcc compilers (or internal ones). I talked to CentOS last week and there are cases where the CentOS kernel oopses, when the RHEL one doesn't and vice-versa. So RHEL and clones are a bad example when it comes to talking about (re)builds. I think Fedora can do far better than this. -- 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 Tue Jun 5 10:19:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 12:19:15 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <1181037539.27239.76.camel@mccallum.corsepiu.local> References: <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> <20070605091644.GF23972@neu.nirvana> <1181037539.27239.76.camel@mccallum.corsepiu.local> Message-ID: <20070605101915.GK23972@neu.nirvana> On Tue, Jun 05, 2007 at 11:58:59AM +0200, Ralf Corsepius wrote: > On Tue, 2007-06-05 at 11:16 +0200, Axel Thimm wrote: > > > Let's revert the question: "Why is it better without a disttag, out of > > curiosity?". There is definitely a gain with a disttag, one can argue > > how big it is, but what are the drawbacks? > Exactly. At least to me both as a maintainer and as user the pros by way > outweigh the cons. > > So far, the only "con" I came across is lack of clear conventions on > %release in those (rare) occasions a package's EVR has to walk > "sideways" (X.fcN -> X.fcN.1, X.fcN.2). Yes, that's true, but usually it implies that one modifies the specfile of say FC5 w/o modifying the identical specfile in FC6 (because the above implies that they were the same). I can't really think of many situations where this would happen (actually I can't think of any right now, but I'm not excluding it), but there is already a mechanism to deal with it as Ralf writes. > > Bottom points: > > o full rebuilds should become a must > Well, I can only reiterate what I said before: IMO, "full rebuilds" are > a hoax blending yourself unless they are performed in "sorted order" > and a PITA to maintainers unless they are performed automatically. I can think of a tool that sorts packages in a BR-sane manner (other than bootstrap loops). But I think the easiest is to simply rebuild twice in a row (automatically). > > o disttags are helpful either way > Right. > > Ralf > > -- 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 nicolas.mailhot at laposte.net Tue Jun 5 10:16:54 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Jun 2007 12:16:54 +0200 (CEST) Subject: Disttags are nice, save the disttags In-Reply-To: <1181037539.27239.76.camel@mccallum.corsepiu.local> References: <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> <20070605091644.GF23972@neu.nirvana> <1181037539.27239.76.camel@mccallum.corsepiu.local> Message-ID: <23312.192.54.193.51.1181038614.squirrel@rousalka.dyndns.org> Le Mar 5 juin 2007 11:58, Ralf Corsepius a ?crit : > On Tue, 2007-06-05 at 11:16 +0200, Axel Thimm wrote: >> Bottom points: >> o full rebuilds should become a must > Well, I can only reiterate what I said before: IMO, "full rebuilds" > are > a hoax blending yourself unless they are performed in "sorted order" > and a PITA to maintainers unless they are performed automatically. I certainly hope no one here is talking about full rebuilds that are not automated respecting the required build order -- Nicolas Mailhot From jonathan.underwood at gmail.com Tue Jun 5 10:23:12 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 5 Jun 2007 11:23:12 +0100 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605101229.GJ23972@neu.nirvana> References: <46647161.6070806@redhat.com> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> <20070605091644.GF23972@neu.nirvana> <1181037539.27239.76.camel@mccallum.corsepiu.local> <645d17210706050305v5de9f0b4yd874842cfa9c362d@mail.gmail.com> <20070605101229.GJ23972@neu.nirvana> Message-ID: <645d17210706050323y7be57a69t3976b0bc0ba769a2@mail.gmail.com> On 05/06/07, Axel Thimm wrote: > Oh, that's touchy subject. Not because of CentOS and SL, but because > RHEL is all but self-hosting. Some parts have been taken from FC6 > (~15%), so they have been built in some FC6 environment, others from > not anymore existing gcc compilers (or internal ones). I talked to > CentOS last week and there are cases where the CentOS kernel oopses, > when the RHEL one doesn't and vice-versa. > > So RHEL and clones are a bad example when it comes to talking about > (re)builds. I think Fedora can do far better than this. Quite - in this case it seems to me that CentOS did things "right" and did the full rebuild that RHEL should have had. Isn't this a really convincing argument for full rebuild testing of Fedora? From bugs.michael at gmx.net Tue Jun 5 10:29:33 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Jun 2007 12:29:33 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <1181036742.27239.66.camel@mccallum.corsepiu.local> References: <200706031108.23794.jkeating@redhat.com> <20070604124228.GA5034@neu.nirvana> <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> <1181036742.27239.66.camel@mccallum.corsepiu.local> Message-ID: <20070605122933.ecedfc2f.bugs.michael@gmx.net> On Tue, 05 Jun 2007 11:45:41 +0200, Ralf Corsepius wrote: > The %dist tags assure a steady upgrade path on packages' EVRs between > distros. That's a myth. Only R not EVR. Unless it's a full online dist-upgrade, EVR path breaks easily. From jkeating at redhat.com Tue Jun 5 10:28:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 06:28:02 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4664FCB4.2000509@serpentine.com> References: <200706031108.23794.jkeating@redhat.com> <200706041203.58789.jkeating@redhat.com> <4664FCB4.2000509@serpentine.com> Message-ID: <200706050628.05689.jkeating@redhat.com> On Tuesday 05 June 2007 02:03:32 Bryan O'Sullivan wrote: > On a related note, I was running rawhide between test2 and F7 final. > But yum didn't pick up any change to the fedora-release package, which > left me picking up the first round of fc8 rebuilds after the dam broke, > because I was still being pointed at the development repos. ?I spent a > few hours on different machines downloading the F7 final packages that > had been updated and manually rolling them back with "rpm -U > --oldpackage". ?Ugh. Rawhide is ever rolling. You'd have to ask to get off by adjusting your repo config. We don't release the final fedora-release package to rawhide. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 5 10:34:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 06:34:49 -0400 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605101915.GK23972@neu.nirvana> References: <46642DCF.7040503@leemhuis.info> <1181037539.27239.76.camel@mccallum.corsepiu.local> <20070605101915.GK23972@neu.nirvana> Message-ID: <200706050634.49335.jkeating@redhat.com> On Tuesday 05 June 2007 06:19:15 Axel Thimm wrote: > I can think of a tool that sorts packages in a BR-sane manner (other > than bootstrap loops). But I think the easiest is to simply rebuild > twice in a row (automatically). Circular build reqs can't be fixed by any tool ordering. Building twice in a row doesn't get things right either. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 5 10:37:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 06:37:27 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070605122933.ecedfc2f.bugs.michael@gmx.net> References: <200706031108.23794.jkeating@redhat.com> <1181036742.27239.66.camel@mccallum.corsepiu.local> <20070605122933.ecedfc2f.bugs.michael@gmx.net> Message-ID: <200706050637.27255.jkeating@redhat.com> On Tuesday 05 June 2007 06:29:33 Michael Schwendt wrote: > On Tue, 05 Jun 2007 11:45:41 +0200, Ralf Corsepius wrote: > > The %dist tags assure a steady upgrade path on packages' EVRs between > > distros. > > That's a myth. Only R not EVR. > > Unless it's a full online dist-upgrade, EVR path breaks easily. > Indeed. "proper upgrade path" can only really be achieved in the first week of a new release. After that updates to the older release will go beyond the versions in the new release iso set anyway. Until such time as we are able to enable doing Anaconda upgrades with the updates repo enabled this will continue to be the situation. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 5 10:40:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 06:40:19 -0400 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605094413.GH23972@neu.nirvana> References: <46641E18.6080806@fedoraproject.org> <20070605093524.GA2832@free.fr> <20070605094413.GH23972@neu.nirvana> Message-ID: <200706050640.19469.jkeating@redhat.com> On Tuesday 05 June 2007 05:44:13 Axel Thimm wrote: > Well, that's the case, disttags were never enforced, they made it into > the majority of packages (89% with a 10% increase on each release for > th epast 3 releases) because they are useful. Lets not attribute to conscious thought that which can easily be attributed to "this other spec did it, so shall I". Especially when our tools for creating new spec files from scratch automatically put a %{?dist} tag in 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 Axel.Thimm at ATrpms.net Tue Jun 5 11:03:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 13:03:27 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <645d17210706050323y7be57a69t3976b0bc0ba769a2@mail.gmail.com> References: <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> <20070605091644.GF23972@neu.nirvana> <1181037539.27239.76.camel@mccallum.corsepiu.local> <645d17210706050305v5de9f0b4yd874842cfa9c362d@mail.gmail.com> <20070605101229.GJ23972@neu.nirvana> <645d17210706050323y7be57a69t3976b0bc0ba769a2@mail.gmail.com> Message-ID: <20070605110327.GM23972@neu.nirvana> On Tue, Jun 05, 2007 at 11:23:12AM +0100, Jonathan Underwood wrote: > On 05/06/07, Axel Thimm wrote: > >Oh, that's touchy subject. Not because of CentOS and SL, but because > >RHEL is all but self-hosting. Some parts have been taken from FC6 > >(~15%), so they have been built in some FC6 environment, others from > >not anymore existing gcc compilers (or internal ones). I talked to > >CentOS last week and there are cases where the CentOS kernel oopses, > >when the RHEL one doesn't and vice-versa. > > > >So RHEL and clones are a bad example when it comes to talking about > >(re)builds. I think Fedora can do far better than this. > > Quite - in this case it seems to me that CentOS did things "right" and > did the full rebuild that RHEL should have had. I think CentOS is trying to make an exact compatible clone of RHEL including all bugs etc. So they do want to recreate the same same build environment the RHEl packages where built in, but unfortunately this is sometimes not even possible due to gcc being either internal or already obsoleted by a newer update (because the gcc used when building these RHEL packages is not the one on the GA). > Isn't this a really convincing argument for full rebuild testing of > Fedora? I think reproducability is a must everywhere, so yes, it is. -- 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 Tue Jun 5 11:04:17 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 13:04:17 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <200706050634.49335.jkeating@redhat.com> References: <46642DCF.7040503@leemhuis.info> <1181037539.27239.76.camel@mccallum.corsepiu.local> <20070605101915.GK23972@neu.nirvana> <200706050634.49335.jkeating@redhat.com> Message-ID: <20070605110417.GN23972@neu.nirvana> On Tue, Jun 05, 2007 at 06:34:49AM -0400, Jesse Keating wrote: > On Tuesday 05 June 2007 06:19:15 Axel Thimm wrote: > > I can think of a tool that sorts packages in a BR-sane manner (other > > than bootstrap loops). But I think the easiest is to simply rebuild > > twice in a row (automatically). > > Circular build reqs can't be fixed by any tool ordering. That's what I called bootstrap loops. > Building twice in a row doesn't get things right either. Why not? Care to detail this? -- 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 Tue Jun 5 11:09:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 13:09:11 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <200706050640.19469.jkeating@redhat.com> References: <46641E18.6080806@fedoraproject.org> <20070605093524.GA2832@free.fr> <20070605094413.GH23972@neu.nirvana> <200706050640.19469.jkeating@redhat.com> Message-ID: <20070605110911.GO23972@neu.nirvana> On Tue, Jun 05, 2007 at 06:40:19AM -0400, Jesse Keating wrote: > On Tuesday 05 June 2007 05:44:13 Axel Thimm wrote: > > Well, that's the case, disttags were never enforced, they made it into > > the majority of packages (89% with a 10% increase on each release for > > th epast 3 releases) because they are useful. > > Lets not attribute to conscious thought that which can easily be attributed > to "this other spec did it, so shall I". Especially when our tools for > creating new spec files from scratch automatically put a %{?dist} tag in > there. Let's not assume packagers are dump package monkeys. Packages from *Core* have been the ones that didn't carry disttags, Extras always did to an extreme high percentage from day one. And there were not really 10% worth of the whole distribution new packages in Core each release, these were packages *consciously* moved to using disttags by @redhat.com employees. And the people that added %{?dist} to the templates (Ville?) aren't that unconscious either. ;) -- 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 jonathan.underwood at gmail.com Tue Jun 5 11:12:39 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 5 Jun 2007 12:12:39 +0100 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605110417.GN23972@neu.nirvana> References: <46642DCF.7040503@leemhuis.info> <1181037539.27239.76.camel@mccallum.corsepiu.local> <20070605101915.GK23972@neu.nirvana> <200706050634.49335.jkeating@redhat.com> <20070605110417.GN23972@neu.nirvana> Message-ID: <645d17210706050412o63ad8544q66ff52c49d6544dc@mail.gmail.com> On 05/06/07, Axel Thimm wrote: > > Building twice in a row doesn't get things right either. > > Why not? Care to detail this? Well, I can think of one case where building twice does do the trick, but it requires a changing of the BuildRequires between building. The example is emacs-bbdb and emacs-vm. Both packages require the elisp source of the other package (emacs-bbdb-el and emacs-vm-el) to be in the buildroot if you want bbdb functionality in vm. So the way to achieve that is: a) build emacs-vm without BuildRequires: emacs-bbdb-el b) build emacs-bbdb with BuildRequires: emacs-vm-el c) rebuild emacs-vm with BuildRequires: emacs-bbdb-el added. [Yes, I realize this is ugly] Scripting quirky stuff like that I can see would be hard. What's really needed is some sort of optional BuildRequires directive in RPM, that afaik doesn't yet exist. J. From jkeating at redhat.com Tue Jun 5 11:11:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 07:11:35 -0400 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605110417.GN23972@neu.nirvana> References: <46642DCF.7040503@leemhuis.info> <200706050634.49335.jkeating@redhat.com> <20070605110417.GN23972@neu.nirvana> Message-ID: <200706050711.35259.jkeating@redhat.com> On Tuesday 05 June 2007 07:04:17 Axel Thimm wrote: > Why not? Care to detail this? It's a simple timing issue. Given you have a build chain 4 packages deep. First rebuild will rebuild the first package, and all other 3 packages against the old build of the first package. Second rebuild will rebuild the first package again, and all other 3 packages against the first rebuild of the first package. That still leaves packages 3 and 4 as not being rebuilt against the resultant rebuilt of package 2 against rebuild of package 1. You'd have to either rebuild 4 times, or insert delays into the rebuild so that 1 lands in buildroot before 2, then 2 lands in buildroot before 3, so on and so forth. This is just one example where automated rebuild, while it does some good, doesn't really fix all the problems you think it would. It just hides them further under the rug under the assumption "But we did a full rebuild, everything should just build fine now..." when in reality your full rebuild didn't accomplish that, it just gave you a warm and (false) fuzzy feeling. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 5 11:15:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 07:15:03 -0400 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605110911.GO23972@neu.nirvana> References: <46641E18.6080806@fedoraproject.org> <200706050640.19469.jkeating@redhat.com> <20070605110911.GO23972@neu.nirvana> Message-ID: <200706050715.03767.jkeating@redhat.com> On Tuesday 05 June 2007 07:09:11 Axel Thimm wrote: > Let's not assume packagers are dump package monkeys. Packages from > *Core* have been the ones that didn't carry disttags, Extras always > did to an extreme high percentage from day one. And there were not > really 10% worth of the whole distribution new packages in Core each > release, these were packages *consciously* moved to using disttags by > @redhat.com employees. Many core packages picked up dist tags because reviewers recommended them and so packagers just added that with the rest of the stuff they had to change. Seriously I be if we polled all the packagers whom use dist tags, the majority would state something along the line of "the rest of the repo does" or "I use them on all my other packages so now it's consistant" or "the spec generated for me already had it, I didn't know what it was so I didn't remove it". I highly highly doubt each and every dist tag was a result of a well thought out process that investigated the long term effects and usefulness of having a dist tag in the spec. > And the people that added %{?dist} to the templates (Ville?) aren't > that unconscious either. ;) So one maintainer decides that dist tags are useful for every single new package in Fedora, and is /right/ about every single new package in Fedora? I think not. It's great that it is there and shows how to properly use it. However just assuming that everybody KNOWS what it is there for when making a new package and understands the consequences of using it is pretty laughable. -- 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 jonathan.underwood at gmail.com Tue Jun 5 11:19:26 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 5 Jun 2007 12:19:26 +0100 Subject: Disttags are nice, save the disttags In-Reply-To: <200706050711.35259.jkeating@redhat.com> References: <46642DCF.7040503@leemhuis.info> <200706050634.49335.jkeating@redhat.com> <20070605110417.GN23972@neu.nirvana> <200706050711.35259.jkeating@redhat.com> Message-ID: <645d17210706050419n7c03e71dkd7510b453323d853@mail.gmail.com> On 05/06/07, Jesse Keating wrote: > On Tuesday 05 June 2007 07:04:17 Axel Thimm wrote: > > Why not? Care to detail this? > > It's a simple timing issue. Given you have a build chain 4 packages deep. > > First rebuild will rebuild the first package, and all other 3 packages against > the old build of the first package. > > Second rebuild will rebuild the first package again, and all other 3 packages > against the first rebuild of the first package. > > That still leaves packages 3 and 4 as not being rebuilt against the resultant > rebuilt of package 2 against rebuild of package 1. You'd have to either > rebuild 4 times, or insert delays into the rebuild so that 1 lands in > buildroot before 2, then 2 lands in buildroot before 3, so on and so forth. > Right. That's the problem that needs solving, not a reason for not doing full rebuilds. > This is just one example where automated rebuild, while it does some good, > doesn't really fix all the problems you think it would. It just hides them > further under the rug under the assumption "But we did a full rebuild, > everything should just build fine now..." when in reality your full rebuild > didn't accomplish that, it just gave you a warm and (false) fuzzy feeling. Isn't the warm fuzzy feeling warranted if the above issue is solved reproducibly ? J. From jkeating at redhat.com Tue Jun 5 11:22:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 07:22:32 -0400 Subject: Disttags are nice, save the disttags In-Reply-To: <645d17210706050419n7c03e71dkd7510b453323d853@mail.gmail.com> References: <46642DCF.7040503@leemhuis.info> <200706050711.35259.jkeating@redhat.com> <645d17210706050419n7c03e71dkd7510b453323d853@mail.gmail.com> Message-ID: <200706050722.32787.jkeating@redhat.com> On Tuesday 05 June 2007 07:19:26 Jonathan Underwood wrote: > Right. That's the problem that needs solving, not a reason for not > doing full rebuilds. > > > This is just one example where automated rebuild, while it does some > > good, doesn't really fix all the problems you think it would. ?It just > > hides them further under the rug under the assumption "But we did a full > > rebuild, everything should just build fine now..." when in reality your > > full rebuild didn't accomplish that, it just gave you a warm and (false) > > fuzzy feeling. > > Isn't the warm fuzzy feeling warranted if the above issue is solved > reproducibly ? You only solve at the point in which you do the rebuild. Doing such rebuilds really invalidates any QA done on the binaries up to that point, so you'd need to do it early, but then more changes happen throughout the release so you can't really feel warm and fuzzy at the end of the release that your rebuilds at the beginning of the release are still valid anymore. So unless we do rebuilds again at the end and introduce a long period of testing where no other builds but bugfixes (but even that changes things!!) are accepted you don't get your desired results. And then we have 1 or 2 month old builds in our release and we get trounced in the media for shipping old software, and people loose interest in fixing the release if we open rawhide during that re-testing period, and if we don't we get very upset maintainers who don't have anything to do... Seriously the only time rebuilds are really worth it is when you're rebuilding for a specific reason such as a gcc or rpm change. Then you ensure what you're rebuilding for is already in the buildroot, and you build things that A) make use of it, and B) haven't already been built. And you do these things before the Feature freeze. -- 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 gemi at bluewin.ch Tue Jun 5 11:38:24 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 05 Jun 2007 13:38:24 +0200 Subject: Info for package maintainers Message-ID: <1181043504.5163.4.camel@localhost.localdomain> Hi, I am confused about the various changes in F7 that affect packagers. Although I have successfully set up koji and build some of my packages with it, I really do not know if everything was correct and complete. For example I read about the updates system on the ML, but I have not found any usable information on the wiki. It would be nice if there was a FAQ on the wiki with everything that a packager for F7 must know in order to publish his packages. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From jonathan.underwood at gmail.com Tue Jun 5 11:39:05 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 5 Jun 2007 12:39:05 +0100 Subject: Disttags are nice, save the disttags In-Reply-To: <200706050722.32787.jkeating@redhat.com> References: <46642DCF.7040503@leemhuis.info> <200706050711.35259.jkeating@redhat.com> <645d17210706050419n7c03e71dkd7510b453323d853@mail.gmail.com> <200706050722.32787.jkeating@redhat.com> Message-ID: <645d17210706050439g1d3f9e37xbaf6cef4c2d36967@mail.gmail.com> On 05/06/07, Jesse Keating wrote: > You only solve at the point in which you do the rebuild. Doing such rebuilds > really invalidates any QA done on the binaries up to that point, so you'd > need to do it early, but then more changes happen throughout the release so > you can't really feel warm and fuzzy at the end of the release that your > rebuilds at the beginning of the release are still valid anymore. So unless > we do rebuilds again at the end and introduce a long period of testing where > no other builds but bugfixes (but even that changes things!!) are accepted > you don't get your desired results. And then we have 1 or 2 month old builds > in our release and we get trounced in the media for shipping old software, > and people loose interest in fixing the release if we open rawhide during > that re-testing period, and if we don't we get very upset maintainers who > don't have anything to do... > > Seriously the only time rebuilds are really worth it is when you're rebuilding > for a specific reason such as a gcc or rpm change. Then you ensure what > you're rebuilding for is already in the buildroot, and you build things that > A) make use of it, and B) haven't already been built. And you do these > things before the Feature freeze. Yep, I entirely see your point. It could also be summarized as "Fedora QA is binary RPM focussed". QA of binaries takes precedent over reproducibility of packages and the distribution, and changing that would be a fundamental change to the distribution. Is that more or less right ? [I'm not trying to be a jerk, but am trying to understand the details - one of us has years of experience as a release manager, and one of us doesn't :)] J. From jkeating at redhat.com Tue Jun 5 11:41:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 07:41:04 -0400 Subject: Disttags are nice, save the disttags In-Reply-To: <645d17210706050439g1d3f9e37xbaf6cef4c2d36967@mail.gmail.com> References: <46642DCF.7040503@leemhuis.info> <200706050722.32787.jkeating@redhat.com> <645d17210706050439g1d3f9e37xbaf6cef4c2d36967@mail.gmail.com> Message-ID: <200706050741.04299.jkeating@redhat.com> On Tuesday 05 June 2007 07:39:05 Jonathan Underwood wrote: > Yep, I entirely see your point. It could also be summarized as "Fedora > QA is binary RPM focussed". QA of binaries takes precedent over > reproducibility of packages and the distribution, and changing that > would be a fundamental change to the distribution. Is that more or > less right ? Yes. IMHO our responsibility to our end users in having stable and tested binaries is slightly higher than our responsibility to those that are doing full rebuilds of our packages for whatever reason. > [I'm not trying to be a jerk, but am trying to understand the details > - one of us has years of experience as a release manager, and one of > us doesn't :)] Heh, dialog is good, and I don't think you're being a jerk at 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 jkeating at redhat.com Tue Jun 5 11:43:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 07:43:33 -0400 Subject: Info for package maintainers In-Reply-To: <1181043504.5163.4.camel@localhost.localdomain> References: <1181043504.5163.4.camel@localhost.localdomain> Message-ID: <200706050743.34142.jkeating@redhat.com> On Tuesday 05 June 2007 07:38:24 G?rard Milmeister wrote: > Hi, > I am confused about the various changes in F7 that affect packagers. > Although I have successfully set up koji and build some of my packages > with it, I really do not know if everything was correct and complete. > For example I read about the updates system on the ML, but I have not > found any usable information on the wiki. It would be nice if there was > a FAQ on the wiki with everything that a packager for F7 must know in > order to publish his packages. The start of the updates tool FAQ is at http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT -- 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 Tue Jun 5 12:00:02 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Jun 2007 14:00:02 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <200706050637.27255.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <1181036742.27239.66.camel@mccallum.corsepiu.local> <20070605122933.ecedfc2f.bugs.michael@gmx.net> <200706050637.27255.jkeating@redhat.com> Message-ID: <1181044803.27239.85.camel@mccallum.corsepiu.local> On Tue, 2007-06-05 at 06:37 -0400, Jesse Keating wrote: > On Tuesday 05 June 2007 06:29:33 Michael Schwendt wrote: > > On Tue, 05 Jun 2007 11:45:41 +0200, Ralf Corsepius wrote: > > > The %dist tags assure a steady upgrade path on packages' EVRs between > > > distros. > > > > That's a myth. Only R not EVR. OK, ok, yes, you are right. > > Unless it's a full online dist-upgrade, EVR path breaks easily. Well, in practice, nobody will use a CD/DVD only Fedora distro. > Indeed. "proper upgrade path" can only really be achieved in the first week > of a new release. > > After that updates to the older release will go beyond the > versions in the new release iso set anyway. Until such time as we are able > to enable doing Anaconda upgrades with the updates repo enabled this will > continue to be the situation. Agreed, upgrading an online-updated FC6 to "FC7-DVD-only" won't work, but I don't see why upgrading an "online-updated FC6" to "an online-updated FC7" can't be assured. Ralf From jkeating at redhat.com Tue Jun 5 12:12:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 08:12:16 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <1181044803.27239.85.camel@mccallum.corsepiu.local> References: <200706031108.23794.jkeating@redhat.com> <200706050637.27255.jkeating@redhat.com> <1181044803.27239.85.camel@mccallum.corsepiu.local> Message-ID: <200706050812.16242.jkeating@redhat.com> On Tuesday 05 June 2007 08:00:02 Ralf Corsepius wrote: > Agreed, upgrading an online-updated FC6 to "FC7-DVD-only" won't work, > but I don't see why upgrading an "online-updated FC6" to "an > online-updated FC7" can't be assured. It should indeed. -- 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 cra at WPI.EDU Tue Jun 5 12:31:18 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 5 Jun 2007 08:31:18 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <200706050637.27255.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <1181036742.27239.66.camel@mccallum.corsepiu.local> <20070605122933.ecedfc2f.bugs.michael@gmx.net> <200706050637.27255.jkeating@redhat.com> Message-ID: <20070605123118.GC25663@angus.ind.WPI.EDU> On Tue, Jun 05, 2007 at 06:37:27AM -0400, Jesse Keating wrote: > On Tuesday 05 June 2007 06:29:33 Michael Schwendt wrote: > > On Tue, 05 Jun 2007 11:45:41 +0200, Ralf Corsepius wrote: > > > The %dist tags assure a steady upgrade path on packages' EVRs between > > > distros. > > > > That's a myth. Only R not EVR. > > > > Unless it's a full online dist-upgrade, EVR path breaks easily. > > > > Indeed. "proper upgrade path" can only really be achieved in the first week > of a new release. After that updates to the older release will go beyond the > versions in the new release iso set anyway. Until such time as we are able > to enable doing Anaconda upgrades with the updates repo enabled this will > continue to be the situation. Why can't the entire lifetime of FC6 updates be guaranteed to be < F7 or future distros? From gemi at bluewin.ch Tue Jun 5 12:35:32 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 05 Jun 2007 14:35:32 +0200 Subject: Info for package maintainers In-Reply-To: <200706050743.34142.jkeating@redhat.com> References: <1181043504.5163.4.camel@localhost.localdomain> <200706050743.34142.jkeating@redhat.com> Message-ID: <1181046932.5736.4.camel@localhost.localdomain> On Tue, 2007-06-05 at 07:43 -0400, Jesse Keating wrote: > The start of the updates tool FAQ is at > http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT Ok, I had already found this page. The problem is that there seems to be no doc about how all the pieces work together. Of course everything could be inferred by following the ML closely, but this is impossible with the current amount of traffic. I think there should be a link on the wiki frontpage "Everything you always wanted to know about packaging, but were afraid to ask". Anyway, I tried to push an update through bodhi, but I get the following internal error: The server encountered an unexpected condition which prevented it from fulfilling the request. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From jkeating at redhat.com Tue Jun 5 12:50:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 08:50:49 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070605123118.GC25663@angus.ind.WPI.EDU> References: <200706031108.23794.jkeating@redhat.com> <200706050637.27255.jkeating@redhat.com> <20070605123118.GC25663@angus.ind.WPI.EDU> Message-ID: <200706050850.49256.jkeating@redhat.com> On Tuesday 05 June 2007 08:31:18 Chuck Anderson wrote: > Why can't the entire lifetime of FC6 updates be guaranteed to be < F7 > or future distros? Horrible games with faking the version of packages? Do you really want to package foo-4.2 as foo-3.1-1.fc6.4.2 ? Or would you rather prevent a package in a release from ever doing a version (version, not just release) bump? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 5 12:52:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 08:52:26 -0400 Subject: Info for package maintainers In-Reply-To: <1181046932.5736.4.camel@localhost.localdomain> References: <1181043504.5163.4.camel@localhost.localdomain> <200706050743.34142.jkeating@redhat.com> <1181046932.5736.4.camel@localhost.localdomain> Message-ID: <200706050852.27060.jkeating@redhat.com> On Tuesday 05 June 2007 08:35:32 G?rard Milmeister wrote: > I think there should be a link on > the wiki frontpage "Everything you always wanted to know about > packaging, but were afraid to ask". But in order for somebody to make that page, they'd need to know what people are going to ask for... Perhaps an FAQGEN page that people drop questions in the bucket and somebody turns it into a Question/Answer pair. > Anyway, I tried to push an update through bodhi, but I get the following > internal error: > The server encountered an unexpected condition which prevented it from > fulfilling the request. Yeah, something is not quite right in the infrastructure space this morning, we're looking into 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 Axel.Thimm at ATrpms.net Tue Jun 5 13:31:23 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 15:31:23 +0200 Subject: koji: not building against koji-built packages? bug or user issue? Message-ID: <20070605133123.GP23972@neu.nirvana> Hi, I built apt and synaptic in this order: ID: 7866: apt-0.5.15lorg3.2-10.fc7 (Finished: Sun, 03 Jun 2007 02:46:43 MST) ID: 7943: synaptic-0.57.2-7.fc7 (Started Mon, 04 Jun 2007 03:59:34 MST) e.g. there was more than one day in between. Still the synaptic build used the old apt package, for example: http://koji.fedoraproject.org/koji/getfile?taskID=25522&name=root.log ... 0:apt-devel-0.5.15lorg3.2-9.fc7.i386 ... The proper apt package was even in updates-testing since 2007-06-03 21:12:03. Did I do something wrong? If yes, how do I ensure that packages get built against each-other before pushing to updates(-testing)? With the former setup (plague) this was automatic. If not, why did koji not see the 25h old package it built? -- 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 Tue Jun 5 13:35:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 15:35:10 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <200706050715.03767.jkeating@redhat.com> References: <46641E18.6080806@fedoraproject.org> <200706050640.19469.jkeating@redhat.com> <20070605110911.GO23972@neu.nirvana> <200706050715.03767.jkeating@redhat.com> Message-ID: <20070605133510.GQ23972@neu.nirvana> On Tue, Jun 05, 2007 at 07:15:03AM -0400, Jesse Keating wrote: > On Tuesday 05 June 2007 07:09:11 Axel Thimm wrote: > > Let's not assume packagers are dump package monkeys. Packages from > > *Core* have been the ones that didn't carry disttags, Extras always > > did to an extreme high percentage from day one. And there were not > > really 10% worth of the whole distribution new packages in Core each > > release, these were packages *consciously* moved to using disttags by > > @redhat.com employees. > > Many core packages picked up dist tags because reviewers recommended > them There were no such reviews for FC6 or FC5, and the increase was steadily 10% over these as well. So it is far more likely that they "just work" and persuade the packagers to use them. > However just assuming that everybody KNOWS what it is there for when making a > new package and understands the consequences of using it is pretty laughable. Sure, not everyone understands all rpm intricacies, and if all were geniouses we wouldn't need disttags to aid people to keep their packages in a proper update ordering. So that's in fact an argument in favour of disttags. -- 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 Tue Jun 5 13:36:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 15:36:38 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <645d17210706050412o63ad8544q66ff52c49d6544dc@mail.gmail.com> References: <46642DCF.7040503@leemhuis.info> <1181037539.27239.76.camel@mccallum.corsepiu.local> <20070605101915.GK23972@neu.nirvana> <200706050634.49335.jkeating@redhat.com> <20070605110417.GN23972@neu.nirvana> <645d17210706050412o63ad8544q66ff52c49d6544dc@mail.gmail.com> Message-ID: <20070605133638.GR23972@neu.nirvana> On Tue, Jun 05, 2007 at 12:12:39PM +0100, Jonathan Underwood wrote: > On 05/06/07, Axel Thimm wrote: > >> Building twice in a row doesn't get things right either. > > > >Why not? Care to detail this? > > Well, I can think of one case where building twice does do the trick, > but it requires a changing of the BuildRequires between building. > > The example is emacs-bbdb and emacs-vm. Both packages require the > elisp source of the other package (emacs-bbdb-el and emacs-vm-el) to > be in the buildroot if you want bbdb functionality in vm. So the way > to achieve that is: > > a) build emacs-vm without BuildRequires: emacs-bbdb-el > b) build emacs-bbdb with BuildRequires: emacs-vm-el > c) rebuild emacs-vm with BuildRequires: emacs-bbdb-el added. > > [Yes, I realize this is ugly] > > Scripting quirky stuff like that I can see would be hard. What's > really needed is some sort of optional BuildRequires directive in RPM, > that afaik doesn't yet exist. You misunderstood the building twice: a) first against the current rawhide b) then against the result from above so you would have emacs-vm and emacs-bbdb already in pass a) -- 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 Tue Jun 5 13:39:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 15:39:27 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <200706050711.35259.jkeating@redhat.com> References: <46642DCF.7040503@leemhuis.info> <200706050634.49335.jkeating@redhat.com> <20070605110417.GN23972@neu.nirvana> <200706050711.35259.jkeating@redhat.com> Message-ID: <20070605133927.GS23972@neu.nirvana> On Tue, Jun 05, 2007 at 07:11:35AM -0400, Jesse Keating wrote: > On Tuesday 05 June 2007 07:04:17 Axel Thimm wrote: > > Why not? Care to detail this? > > It's a simple timing issue. Given you have a build chain 4 packages deep. > > First rebuild will rebuild the first package, and all other 3 packages against > the old build of the first package. > > Second rebuild will rebuild the first package again, and all other 3 packages > against the first rebuild of the first package. > > That still leaves packages 3 and 4 as not being rebuilt against the resultant > rebuilt of package 2 against rebuild of package 1. You'd have to either > rebuild 4 times, or insert delays into the rebuild so that 1 lands in > buildroot before 2, then 2 lands in buildroot before 3, so on and so forth. > > This is just one example where automated rebuild, while it does some good, > doesn't really fix all the problems you think it would. It just hides them > further under the rug under the assumption "But we did a full rebuild, > everything should just build fine now..." when in reality your full rebuild > didn't accomplish that, it just gave you a warm and (false) fuzzy feeling. No, you also got it wrong. I'm not talking rebuilding from scratch, but against rawhide. That's what all mass-rebuild were like until now. Both rebuilds will succeed (unless there is a bug in the package and that would be good, so we can fix it): the first one will have buildrequires from FC6->F7 since that's what the repo looked like, the second will have fresh buildrequires from the previous pass. No need to look at N-folded-recusion. -- 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 Christian.Iseli at licr.org Tue Jun 5 13:41:44 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 5 Jun 2007 15:41:44 +0200 Subject: Fedora Package Status of Jun 5, 2007 Message-ID: <20070605154144.63aeb1ef@ludwig-alpha.unil.ch> Hi folks, Here is a new batch. The wiki update is still painfully *slow*, but at least this time it went through on the first attempt. The bugzilla migration is not done yet, so the open bugs count has no real meaning currently. Cheers, Christian ==== Fedora Package Status of Jun 5, 2007 The full report can be found here: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus Owners file stats: - 4532 packages - 7363 binary rpms in devel - 100 orphans - 124 packages not available in devel or release Axel dot Thimm at ATrpms dot net vtk Axel dot Thimm at ATrpms dot net vtk-data Fedora at FamilleCollet dot com php-pear-Net-Ping Fedora at FamilleCollet dot com php-pear-Net-Traceroute ajackson at redhat dot com xorg-x11-drv-vermilion andreas at bawue dot net perl-HTML-CalendarMonthSimple andreas at bawue dot net ddrescue andreas at bawue dot net perl-NetAddr-IP arnd at arndb dot de dtc bdpepple at ameritech dot net galago-filesystem bdpepple at ameritech dot net gaim-galago belegdol at gmail dot com goffice04 belegdol at gmail dot com bodr bjohnson at symetrix dot com dwatch bnocera at redhat dot com gnome-vfs2-obexftp bnocera at redhat dot com gnome-launch-box cgoorah at yahoo dot com dot au netgen cweyl at alumni dot drew dot edu perl-Text-RecordParser cweyl at alumni dot drew dot edu gaim-gaym cweyl at alumni dot drew dot edu perl-GD-Barcode cweyl at alumni dot drew dot edu perl-URI-Fetch cweyl at alumni dot drew dot edu perl-CPANPLUS-Dist-Build dbhole at redhat dot com dom2-core-tests dbhole at redhat dot com objectweb-anttask dcantrell at redhat dot com repoman dev at nigelj dot com calcurse devrim at commandprompt dot com postgresql-pgpool-II dgoodwin at dangerouslyinc dot com wuja fangqq at gmail dot com wqy-bitmap-fonts foolish at guezz dot net arp-scan foolish at guezz dot net perl-Net-Libdnet foolish at guezz dot net perl-DBIx-SQLite-Simple foolish at guezz dot net perl-Net-IPv6Addr foolish at guezz dot net perl-Net-Pcap foolish at guezz dot net bottlerocket foolish at guezz dot net perl-SQLite-Simple foolish at guezz dot net perl-Class-Gomor foolish at guezz dot net perl-Math-Base85 foolish at guezz dot net ike-scan foolish at guezz dot net firewalk foolish at guezz dot net perl-Nmap-Parser foolish at guezz dot net onesixtyone foolish at guezz dot net halberd foolish at guezz dot net perl-Net-Write foolish at guezz dot net telepathy-mission-control foolish at guezz dot net muine-scrobbler gauret at free dot fr pdftohtml green at redhat dot com ws-common-utils guillaume dot thouvenin at bull dot net elsa i at stingr dot net weechat i at stingr dot net libnetfilter_log icon at fedoraproject dot org mod_evasive ingvar at linpro dot no varnish j dot w dot r dot degoede at hhs dot nl blobAndConquer jbowes at redhat dot com tig jhrozek at redhat dot com dwdiff jkeating at redhat dot com trac-webadmin jmp at safe dot ca clement johan at x-tnd dot be kftpgrabber jonathansteffan at gmail dot com revisor jorton at redhat dot com libc-client jorton at redhat dot com perl-Newt jwboyer at jdub dot homelinux dot org gaim-meanwhile k dot georgiou at imperial dot ac dot uk ruby-shadow kwizart at gmail dot com lcdproc kwizart at gmail dot com libgii kwizart at gmail dot com yafray lightsolphoenix at gmail dot com kio_p7zip lightsolphoenix at gmail dot com tastymenu limb at jcomserv dot net dgae limb at jcomserv dot net agistudio limb at jcomserv dot net archivemail limb at jcomserv dot net sergueis-destiny limb at jcomserv dot net roundcubemail limb at jcomserv dot net nagi livinded at deadbytes dot net surfraw lmacken at redhat dot com python-TurboMail lukasim at atlas dot cz ruby-ncurses lxtnow at gmail dot com gammu lxtnow at gmail dot com specto mastahnke at gmail dot com kflickr mastahnke at gmail dot com epel-release mastahnke at gmail dot com php-magpierss maxime dot carron at fedoraproject dot org pypar2 mcepl at redhat dot com gstreamer-plugins-pulseaudio mgarski at post dot pl libkdcraw mtasaka at ioa dot s dot u-tokyo dot ac dot jp alexandria mtasaka at ioa dot s dot u-tokyo dot ac dot jp cmigemo notting at redhat dot com mash paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net paul at xelerance dot com perl-IO-LockedFile pcheung at redhat dot com asm2 pertusus at free dot fr ivman rafalzaq at gmail dot com glob2 rayvd at bludgeon dot org remind rcritten at redhat dot com jss rob dot myers at gtri dot gatech dot edu eclipse-checkstyle ruben at rubenkerkhof dot com perl-Danga-Socket ruben at rubenkerkhof dot com perl-IO-AIO rvinyard at cs dot nmsu dot edu xournal rvokal at redhat dot com gaim-guifications splinux at fedoraproject dot org lostirc splinux at fedoraproject dot org drapes steve at silug dot org perl-Pugs-Compiler-Rule steve at silug dot org perl-Image-Math-Constrain steve at silug dot org perl-YAML-Tiny steve at silug dot org perl-Affix-Infix2Postfix stransky at redhat dot com berusky stransky at redhat dot com berusky-data tcallawa at redhat dot com ftplib vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp walters at redhat dot com hotwire walters at redhat dot com hippo-canvas walters at redhat dot com bigboard wjhns174 at hardakers dot net perl-Crypt-OpenSSL-DSA wjhns174 at hardakers dot net perl-Crypt-OpenSSL-AES wjhns174 at hardakers dot net perl-Crypt-OpenSSL-Random wjhns174 at hardakers dot net perl-Crypt-OpenSSL-X509 wjhns174 at hardakers dot net perl-Crypt-OpenSSL-Bignum wjhns174 at hardakers dot net perl-Crypt-OpenSSL-PKCS10 wjhns174 at hardakers dot net perl-Crypt-OpenSSL-RSA wjhns174 at hardakers dot net perl-Digest-SHA - 16 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=199405,211737,212003,222191,231303,236162,239939 vtk Axel.Thimm at ATrpms.net perl-Class-Data-Accessor adpacifico at users.sourceforge.net mugshot otaylor at redhat.com eclipse bkonrath at redhat.com xmlunit pcheung at redhat.com kadischi jasperhartline at adelphia.net libgii kwizart at gmail.com https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=221084,221717,222347,224458,226725,227091,231861,236091,242566 dkms Matt_Domsch at dell.com agg caolanm at redhat.com g-wrap notting at redhat.com libsilc wtogami at redhat.com netgen cgoorah at yahoo.com.au objectweb-anttask rafaels at redhat.com cyrus-imapd tjanouse at redhat.com dolphin johan at x-tnd.be cegui packages at amiga-hardware.com - 3 packages present in the development repo which have no owners entry gstreamer-plugins-pulse s390utils ws-commons-util - 8 orphaned packages, yet available in devel driftnet libedit luks-tools obconf obmenu openbox pam_usb udftools FE-ACCEPT packages stats: - 2561 accepted, closed package reviews - 84 accepted, closed package reviews not in repo - 8 accepted, closed package reviews not in owners - 114 accepted, open package reviews older than 4 weeks; - 123 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 224 open tickets - 4 tickets with no activity in eight weeks - 130 tickets with no activity in four weeks - 14 closed tickets FE-NEW packages stats: - 1018 open tickets - 1 tickets with no activity in eight weeks - 867 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 50 open tickets - 15 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets - 1 tickets with no activity in four weeks FE-GUIDELINES packages stats: - open tickets OPEN-BUGS packages stats: - 44 open tickets - 3 tickets with no activity in eight weeks - 21 tickets with no activity in four weeks CVS stats: - 4537 packages with a devel directory - 5 packages with no owners entry isorelax-0-0.1.release20050331.1jpp.1.src.rpm mysql-administrator postgis tdma vtkdata - 199 packages were dropped from Fedora Maintainers stats: - 373 maintainers - 2 inactive maintainers with open bugs - 3 inactive maintainers Comps.xml files stats: - 2370 packages in comps-f8 file - 938 packages missing from comps-f8 file - 40 packages in comps-f8 but not in repo - 2371 packages in comps-f7 file - 938 packages missing from comps-f7 file - 41 packages in comps-f7 but not in repo From Axel.Thimm at ATrpms.net Tue Jun 5 13:42:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 15:42:02 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070605123118.GC25663@angus.ind.WPI.EDU> References: <200706031108.23794.jkeating@redhat.com> <1181036742.27239.66.camel@mccallum.corsepiu.local> <20070605122933.ecedfc2f.bugs.michael@gmx.net> <200706050637.27255.jkeating@redhat.com> <20070605123118.GC25663@angus.ind.WPI.EDU> Message-ID: <20070605134202.GT23972@neu.nirvana> On Tue, Jun 05, 2007 at 08:31:18AM -0400, Chuck Anderson wrote: > Why can't the entire lifetime of FC6 updates be guaranteed to be < F7 > or future distros? Like staying on kernel 2.6.18? -- 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 cra at WPI.EDU Tue Jun 5 13:55:37 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 5 Jun 2007 09:55:37 -0400 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070605134202.GT23972@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <1181036742.27239.66.camel@mccallum.corsepiu.local> <20070605122933.ecedfc2f.bugs.michael@gmx.net> <200706050637.27255.jkeating@redhat.com> <20070605123118.GC25663@angus.ind.WPI.EDU> <20070605134202.GT23972@neu.nirvana> Message-ID: <20070605135537.GF25663@angus.ind.WPI.EDU> On Tue, Jun 05, 2007 at 03:42:02PM +0200, Axel Thimm wrote: > On Tue, Jun 05, 2007 at 08:31:18AM -0400, Chuck Anderson wrote: > > Why can't the entire lifetime of FC6 updates be guaranteed to be < F7 > > or future distros? > > Like staying on kernel 2.6.18? Should RPM versions be based on upstream versions? Or should we care to make distro upgrades actually work all the time, every time? We've already abused RPM version in kernel packages to meet the goal of RPM upgradeability. So how about something like this? FC6: kernel-6.2.6.18 kernel-6.2.6.20 kernel-6.2.6.21 F7: kernel-7.2.6.20 kernel-7.2.6.21 Or perhaps: FC6: kernel-6.20061204 kernel-6.20070305 kernel-6.20070605 F7: kernel-7.20070605 kernel-7.20070612 Yes I realize these are radical ideas, but perhaps we need to rethink what we use for ordering packages and stop pretending that upstream version numbers can do this for us. From jonathan.underwood at gmail.com Tue Jun 5 13:59:15 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 5 Jun 2007 14:59:15 +0100 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605133638.GR23972@neu.nirvana> References: <46642DCF.7040503@leemhuis.info> <1181037539.27239.76.camel@mccallum.corsepiu.local> <20070605101915.GK23972@neu.nirvana> <200706050634.49335.jkeating@redhat.com> <20070605110417.GN23972@neu.nirvana> <645d17210706050412o63ad8544q66ff52c49d6544dc@mail.gmail.com> <20070605133638.GR23972@neu.nirvana> Message-ID: <645d17210706050659m608a3183m87546216a949a0dd@mail.gmail.com> On 05/06/07, Axel Thimm wrote: > You misunderstood the building twice: > > a) first against the current rawhide > b) then against the result from above > > so you would have emacs-vm and emacs-bbdb already in pass a) Nono - I think I understood... The point I was making was that between your (a) and (b), to get all functionality, a change to one of the spec files would be required. J. From Axel.Thimm at ATrpms.net Tue Jun 5 14:01:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 16:01:27 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070605135537.GF25663@angus.ind.WPI.EDU> References: <200706031108.23794.jkeating@redhat.com> <1181036742.27239.66.camel@mccallum.corsepiu.local> <20070605122933.ecedfc2f.bugs.michael@gmx.net> <200706050637.27255.jkeating@redhat.com> <20070605123118.GC25663@angus.ind.WPI.EDU> <20070605134202.GT23972@neu.nirvana> <20070605135537.GF25663@angus.ind.WPI.EDU> Message-ID: <20070605140127.GU23972@neu.nirvana> On Tue, Jun 05, 2007 at 09:55:37AM -0400, Chuck Anderson wrote: > On Tue, Jun 05, 2007 at 03:42:02PM +0200, Axel Thimm wrote: > > On Tue, Jun 05, 2007 at 08:31:18AM -0400, Chuck Anderson wrote: > > > Why can't the entire lifetime of FC6 updates be guaranteed to be < F7 > > > or future distros? > > > > Like staying on kernel 2.6.18? > > Should RPM versions be based on upstream versions? Or should we care > to make distro upgrades actually work all the time, every time? We've > already abused RPM version in kernel packages to meet the goal of RPM > upgradeability. So how about something like this? But what's better in the follwing case: foo-1.2.3-4.fc6 -> foo-1.2.3-5.fc6 (security fix in updates) foo-1.2.3-4.fc7 (iso) -> foo-1.2.3-5.fc7 (security fix in updates) An updated FC6 will carry foo-1.2.3-5.fc6 and the ISO will not offer foo-1.2.3-4.fc7 unless it is forced by anaconda (like kernels). That's a feature not a bug, as otherwise you would suddenly introduce an already fixed security issue. So in fact the non-upgrading from FC6-updates to F7-noupdates is good! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 5 14:01:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 10:01:32 -0400 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605133927.GS23972@neu.nirvana> References: <46642DCF.7040503@leemhuis.info> <200706050711.35259.jkeating@redhat.com> <20070605133927.GS23972@neu.nirvana> Message-ID: <200706051001.35400.jkeating@redhat.com> On Tuesday 05 June 2007 09:39:27 Axel Thimm wrote: > No, you also got it wrong. I'm not talking rebuilding from scratch, > but against rawhide. That's what all mass-rebuild were like until now. > > Both rebuilds will succeed (unless there is a bug in the package and > that would be good, so we can fix it): the first one will have > buildrequires from FC6->F7 since that's what the repo looked like, the > second will have fresh buildrequires from the previous pass. No need > to look at N-folded-recusion. You're still not getting it as well. Are you talking about building one package a day so that said rebuilt package is assured to be in the buildroot? If you rebuild A, the rebuilt A (well call it A.1) isn't available in the buildroot for another 20+ minutes. Quite a bit more if there are 4K other builds queued up. So B which is next on the list rebuilds against the old A, not A.1, C rebuilds against B, not B.1, D against A, and B, not the .1's. The next time you build, you get A.2, B.2 rebuilt against A.1, C.2 rebuilt against A.1 and B.1 (which is still a build against A, not A.1), so on and so forth. The only way to ensure that everything is up to date is to insert delays inside the chain (using something like chain-build) so that A builds to A.1, pause for it to be in the buildroot, B rebuilds against A.1 to become B.1, pause for it to be in the buildroot, C rebuilds against B.1 and A.1 to become C.1, etc... This is just one chain, there are /many/. -- 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 Jun 5 14:11:26 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 16:11:26 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <645d17210706050659m608a3183m87546216a949a0dd@mail.gmail.com> References: <46642DCF.7040503@leemhuis.info> <1181037539.27239.76.camel@mccallum.corsepiu.local> <20070605101915.GK23972@neu.nirvana> <200706050634.49335.jkeating@redhat.com> <20070605110417.GN23972@neu.nirvana> <645d17210706050412o63ad8544q66ff52c49d6544dc@mail.gmail.com> <20070605133638.GR23972@neu.nirvana> <645d17210706050659m608a3183m87546216a949a0dd@mail.gmail.com> Message-ID: <20070605141126.GV23972@neu.nirvana> On Tue, Jun 05, 2007 at 02:59:15PM +0100, Jonathan Underwood wrote: > On 05/06/07, Axel Thimm wrote: > >You misunderstood the building twice: > > > >a) first against the current rawhide > >b) then against the result from above > > > >so you would have emacs-vm and emacs-bbdb already in pass a) > > Nono - I think I understood... The point I was making was that between > your (a) and (b), to get all functionality, a change to one of the > spec files would be required. You mean for the case that the elisp sources moved between emacs releases? Yes, that's true, but in that case you *have* to rebuild both in whatever fashion anyway, this is no longer a nice-to-have rebuild. :) Same will be true for perl/python/etc modules when suddenly the paths change (although less for perl). But all these core upgrades in rawhide always require all the dependent package to be rebuilt, in fact the packages are then usually just broken (e.g. depending on a non-existing python abi and the like). The proposed mass rebuilds assume that the rawhide pool of package is in some sane state already, it is not assumed that we change the development model to throw anything against rawhide and have the mass-rebuilds comb the issues out. :) Or rephrased otherwise: The mass-rebuilds should ensure that the packages really see the same build environment and that their builds are really reproducible. If the claims that the state of the tree at that point in time is sane are really true, then they will just burn some CPU cycles, and the QA after this will not find anything, so Jesse will say "told you so, all is fine", and we'll believe him, as proof was given. ;) But we'd also have the case were some packages suddenly find that the changes from kernel-devel-2.6.18 to 2.6.21 are that big that they'd rather break on the rebuild or offer different, more appropriate functionality. Like for example when PAGE_MASK or other userland header bits are suddenly missing. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Jun 5 14:14:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 05 Jun 2007 16:14:43 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070605140127.GU23972@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <1181036742.27239.66.camel@mccallum.corsepiu.local> <20070605122933.ecedfc2f.bugs.michael@gmx.net> <200706050637.27255.jkeating@redhat.com> <20070605123118.GC25663@angus.ind.WPI.EDU> <20070605134202.GT23972@neu.nirvana> <20070605135537.GF25663@angus.ind.WPI.EDU> <20070605140127.GU23972@neu.nirvana> Message-ID: <46656FD3.8090300@leemhuis.info> On 05.06.2007 16:01, Axel Thimm wrote: > [...] > An updated FC6 will carry foo-1.2.3-5.fc6 and the ISO will not offer > foo-1.2.3-4.fc7 unless it is forced by anaconda (like kernels). That's > a feature not a bug, as otherwise you would suddenly introduce an > already fixed security issue. It would even bad in other situations as well; say foo-1.2.3-5.fc6 introduced a configfile change that foo-1.2.3-4.fc7 does not understand. So you might end with a unworkable foo if foo gets "downgraded" to foo-1.2.3-4.fc7 while "upgrading" from FC6 to F-7 CU thl From Axel.Thimm at ATrpms.net Tue Jun 5 14:23:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 16:23:49 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706031111.22625.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706031111.22625.jkeating@redhat.com> Message-ID: <20070605142349.GX23972@neu.nirvana> On Sun, Jun 03, 2007 at 11:11:22AM -0400, Jesse Keating wrote: > On Sunday 03 June 2007 11:08:23 Jesse Keating wrote: > > /topic RELENG-Meeting - Updates Policy - JesseKeating > > > > /topic RELENG-Meeting - Freeze Policy - JesseKeating > > For these two topics I would really really like to get people to bring their > ideas and thoughts about this to our meeting. Annoyances with the policies > used for Fedora 7, ideas on how to make it better, etc... Come one, come > all. I'll happily dedicate the entire meeting to these topics if need be. So what was the outcome of the meeting regarding these topics, especially the freeze and rebuild strategies? Waiting for fesco's decision? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Tue Jun 5 14:30:29 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Jun 2007 16:30:29 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <20070605140127.GU23972@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <1181036742.27239.66.camel@mccallum.corsepiu.local> <20070605122933.ecedfc2f.bugs.michael@gmx.net> <200706050637.27255.jkeating@redhat.com> <20070605123118.GC25663@angus.ind.WPI.EDU> <20070605134202.GT23972@neu.nirvana> <20070605135537.GF25663@angus.ind.WPI.EDU> <20070605140127.GU23972@neu.nirvana> Message-ID: <20070605163029.3d72ac5a.bugs.michael@gmx.net> On Tue, 5 Jun 2007 16:01:27 +0200, Axel Thimm wrote: > But what's better in the follwing case: > > foo-1.2.3-4.fc6 -> foo-1.2.3-5.fc6 (security fix in updates) > foo-1.2.3-4.fc7 (iso) -> foo-1.2.3-5.fc7 (security fix in updates) > > An updated FC6 will carry foo-1.2.3-5.fc6 and the ISO will not offer > foo-1.2.3-4.fc7 unless it is forced by anaconda (like kernels). That's > a feature not a bug, as otherwise you would suddenly introduce an > already fixed security issue. > > So in fact the non-upgrading from FC6-updates to F7-noupdates is good! Even if it requires a library soname that is only available in FC6 Updates? No. The dist-upgrade to F7 will be broken until foo-1.2.3-5.fc7 is fetched from the online repo and replaces foo-1.2.3-5.fc6 In your scenario, the fc6 and fc7 builds can be swapped. That is not true for many dist-upgrades. From jkeating at redhat.com Tue Jun 5 14:28:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 10:28:25 -0400 Subject: koji: not building against koji-built packages? bug or user issue? In-Reply-To: <20070605133123.GP23972@neu.nirvana> References: <20070605133123.GP23972@neu.nirvana> Message-ID: <200706051028.25740.jkeating@redhat.com> On Tuesday 05 June 2007 09:31:23 Axel Thimm wrote: > I built apt and synaptic in this order: > > ID: 7866: apt-0.5.15lorg3.2-10.fc7 (Finished: Sun, 03 Jun 2007 02:46:43 > MST) ID: 7943: synaptic-0.57.2-7.fc7 (Started Mon, 04 Jun 2007 03:59:34 > MST) > > e.g. there was more than one day in between. Still the synaptic build > used the old apt package, for example: > > http://koji.fedoraproject.org/koji/getfile?taskID=25522&name=root.log > ... > 0:apt-devel-0.5.15lorg3.2-9.fc7.i386 > ... > > The proper apt package was even in updates-testing since 2007-06-03 > 21:12:03. > > Did I do something wrong? If yes, how do I ensure that packages get > built against each-other before pushing to updates(-testing)? With the > former setup (plague) this was automatic. If not, why did koji not see > the 25h old package it built? It got buried before, but the way that release trees are handled are different than rawhide. In Core, our release update candidates do not autopopulate the buildroot. This is to protect our buildroot from being poisoned by potentially bad updates. They are treated as candidate updates and not entered into the buildroot until they are pushed as a stable update. There is an override tag that rel-eng can use to make a build temporarily available to build the rest of a stack for an update. I don't like the scenario at all and I'm welcome to ideas. Just self updating the buildroot seems like a bad idea to me and some of my colleagues who have been doing RHL/RHEL stuff for far longer than I have. Ideally we'd have a way to chainbuild things together in such a way that it doesn't poison the rest of the buildroots for that tag, basically making them available for your build and your build alone. I honestly don't know what kind of work it would take to get this though. Anyway I'm open for discussion. I went forward with what Core developers are used to, and I hoped I had warned people but it probably got lost. I would love to discuss it at a rel-eng meeting, we ran out of time last week. For now, you can request buildroot overrides by mailing 'rel-eng at fedoraproject.org'. What place in the wiki should this information go? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 5 14:29:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 10:29:10 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070605142349.GX23972@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <200706031111.22625.jkeating@redhat.com> <20070605142349.GX23972@neu.nirvana> Message-ID: <200706051029.10517.jkeating@redhat.com> On Tuesday 05 June 2007 10:23:49 Axel Thimm wrote: > So what was the outcome of the meeting regarding these topics, > especially the freeze and rebuild strategies? Waiting for fesco's > decision? See the meeting notes sent out. Freeze was put off until next week (we ran out of time), same with rebuild. -- 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 Tue Jun 5 14:41:41 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Jun 2007 16:41:41 +0200 Subject: use disttag ".1" for devel to avoid confusion In-Reply-To: <46656FD3.8090300@leemhuis.info> References: <200706031108.23794.jkeating@redhat.com> <1181036742.27239.66.camel@mccallum.corsepiu.local> <20070605122933.ecedfc2f.bugs.michael@gmx.net> <200706050637.27255.jkeating@redhat.com> <20070605123118.GC25663@angus.ind.WPI.EDU> <20070605134202.GT23972@neu.nirvana> <20070605135537.GF25663@angus.ind.WPI.EDU> <20070605140127.GU23972@neu.nirvana> <46656FD3.8090300@leemhuis.info> Message-ID: <20070605164141.48dfc002.bugs.michael@gmx.net> On Tue, 05 Jun 2007 16:14:43 +0200, Thorsten Leemhuis wrote: > On 05.06.2007 16:01, Axel Thimm wrote: > > [...] > > An updated FC6 will carry foo-1.2.3-5.fc6 and the ISO will not offer > > foo-1.2.3-4.fc7 unless it is forced by anaconda (like kernels). That's > > a feature not a bug, as otherwise you would suddenly introduce an > > already fixed security issue. > > It would even bad in other situations as well; say foo-1.2.3-5.fc6 > introduced a configfile change that foo-1.2.3-4.fc7 does not understand. > So you might end with a unworkable foo if foo gets "downgraded" to > foo-1.2.3-4.fc7 while "upgrading" from FC6 to F-7 Only and only if F-7 offers everything the FC6 build of foo needs and when that is guaranteed by the distributor. That includes all of foo's requirements, e.g. compatibility libraries. Remember that upwards compatible APIs can still use new SONAMEs, so the fc6 build of foo might require a library SONAME that is not available for fc7. This is firstboot fun. From Axel.Thimm at ATrpms.net Tue Jun 5 14:21:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 16:21:18 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <200706051001.35400.jkeating@redhat.com> References: <46642DCF.7040503@leemhuis.info> <200706050711.35259.jkeating@redhat.com> <20070605133927.GS23972@neu.nirvana> <200706051001.35400.jkeating@redhat.com> Message-ID: <20070605142118.GW23972@neu.nirvana> On Tue, Jun 05, 2007 at 10:01:32AM -0400, Jesse Keating wrote: > On Tuesday 05 June 2007 09:39:27 Axel Thimm wrote: > > No, you also got it wrong. I'm not talking rebuilding from scratch, > > but against rawhide. That's what all mass-rebuild were like until now. > > > > Both rebuilds will succeed (unless there is a bug in the package and > > that would be good, so we can fix it): the first one will have > > buildrequires from FC6->F7 since that's what the repo looked like, the > > second will have fresh buildrequires from the previous pass. No need > > to look at N-folded-recusion. > > You're still not getting it as well. Are you talking about building one > package a day so that said rebuilt package is assured to be in the buildroot? > If you rebuild A, the rebuilt A (well call it A.1) isn't available in the > buildroot for another 20+ minutes. No, no waiting for the results, these are used in the second pass. Only one createrepo between the two mass-builds. > Quite a bit more if there are 4K other builds queued up. So B which > is next on the list rebuilds against the old A, not A.1, C rebuilds > against B, not B.1, D against A, and B, not the .1's. Correct all packages from the first pass build against the snapshot of what was just before the mass-rebuild. > The next time you build, you get A.2, B.2 rebuilt against A.1, C.2 rebuilt > against A.1 and B.1 (which is still a build against A, not A.1), so on and so > forth. Correct. > The only way to ensure that everything is up to date is to insert > delays inside the chain (using something like chain-build) so that A > builds to A.1, pause for it to be in the buildroot, B rebuilds > against A.1 to become B.1, pause for it to be in the buildroot, C > rebuilds against B.1 and A.1 to become C.1, etc... This is just one > chain, there are /many/. Why should that be neccessary? Unless the state of the tree is that bad, that the ABIs toggle around during the rebuild, you will end up with the proper interfaces after the first pass already and that's what counts. If you claim that the state of the tree will be that bad that this will not be the case, then you are giving the best arguments to mass-rebuild early, mass-rebuild often. But the point is that if you already assume the tree to be sane and would rather not do mass-rebuilds just out of the fun of mass-rebuilds, then according to this logic you wouldn't even need a two pass mass-rebuild, but only a single pass mass-rebuild. And the ordering would also not matter to you in this case, since the resulting packages are assumed to be as good as the starting ones. That would be fine with me as well, I just mentioned the two pass rebuild scenario because you or someone else started mocking on build orders. In a nutshell: If build orders are an issue then the tree is in desperate need of a rbeuild anyway, no matter what the method, if not then scheduling a mass-rebuild at least once per development cycle won't hurt either. -- 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 caillon at redhat.com Tue Jun 5 15:23:30 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 05 Jun 2007 11:23:30 -0400 Subject: koji: not building against koji-built packages? bug or user issue? In-Reply-To: <200706051028.25740.jkeating@redhat.com> References: <20070605133123.GP23972@neu.nirvana> <200706051028.25740.jkeating@redhat.com> Message-ID: <46657FF2.6030708@redhat.com> Jesse Keating wrote: > Just self updating the buildroot seems like a bad > idea to me and some of my colleagues who have been doing RHL/RHEL stuff for > far longer than I have. Ideally we'd have a way to chainbuild things > together in such a way that it doesn't poison the rest of the buildroots for > that tag, basically making them available for your build and your build > alone. I honestly don't know what kind of work it would take to get this > though. Agreed we shouldn't auto update the buildroot. Crazy thought: Lazy chain. I personally am one of the people that needs to do multiple builds at a time with the Firefox set of updates. I do not like the idea of being forced to specify all the builds at one time, one bit. There are many cases where I wait to see the results of a build before pushing another build because it might alter what goes into that build. The ability to do make build ADD_TO_BR=firefox-x.y-z or similar as something I need to add to dependent packages is much more appealing than having to specify everything at once. From Axel.Thimm at ATrpms.net Tue Jun 5 15:05:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 17:05:48 +0200 Subject: koji: not building against koji-built packages? bug or user issue? In-Reply-To: <200706051028.25740.jkeating@redhat.com> References: <20070605133123.GP23972@neu.nirvana> <200706051028.25740.jkeating@redhat.com> Message-ID: <20070605150548.GF23972@neu.nirvana> On Tue, Jun 05, 2007 at 10:28:25AM -0400, Jesse Keating wrote: > On Tuesday 05 June 2007 09:31:23 Axel Thimm wrote: > > I built apt and synaptic in this order: > > > > ID: 7866: apt-0.5.15lorg3.2-10.fc7 (Finished: Sun, 03 Jun 2007 02:46:43 > > MST) ID: 7943: synaptic-0.57.2-7.fc7 (Started Mon, 04 Jun 2007 03:59:34 > > MST) > > > > e.g. there was more than one day in between. Still the synaptic build > > used the old apt package, for example: > > > > http://koji.fedoraproject.org/koji/getfile?taskID=25522&name=root.log > > ... > > 0:apt-devel-0.5.15lorg3.2-9.fc7.i386 > > ... > > > > The proper apt package was even in updates-testing since 2007-06-03 > > 21:12:03. > > > > Did I do something wrong? If yes, how do I ensure that packages get > > built against each-other before pushing to updates(-testing)? With the > > former setup (plague) this was automatic. If not, why did koji not see > > the 25h old package it built? > > It got buried before, but the way that release trees are handled are different > than rawhide. In Core, our release update candidates do not autopopulate the > buildroot. This is to protect our buildroot from being poisoned by > potentially bad updates. They are treated as candidate updates and not > entered into the buildroot until they are pushed as a stable update. There > is an override tag that rel-eng can use to make a build temporarily available > to build the rest of a stack for an update. I don't like the scenario at all > and I'm welcome to ideas. Just self updating the buildroot seems like a bad > idea to me and some of my colleagues who have been doing RHL/RHEL stuff for > far longer than I have. Ideally we'd have a way to chainbuild things > together in such a way that it doesn't poison the rest of the buildroots for > that tag, basically making them available for your build and your build > alone. I honestly don't know what kind of work it would take to get this > though. > > Anyway I'm open for discussion. I went forward with what Core developers are > used to, and I hoped I had warned people but it probably got lost. I would > love to discuss it at a rel-eng meeting, we ran out of time last week. Did this poisoning happen often in Fedora Extras? If not then maybe it's better to assume that the packages are not poisoning the buildroots, and assume the Fedora Extras way instead of the Core way? > For now, you can request buildroot overrides by > mailing 'rel-eng at fedoraproject.org'. What place in the wiki should this > information go? > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 5 15:27:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 11:27:50 -0400 Subject: koji: not building against koji-built packages? bug or user issue? In-Reply-To: <20070605150548.GF23972@neu.nirvana> References: <20070605133123.GP23972@neu.nirvana> <200706051028.25740.jkeating@redhat.com> <20070605150548.GF23972@neu.nirvana> Message-ID: <200706051127.51058.jkeating@redhat.com> On Tuesday 05 June 2007 11:05:48 Axel Thimm wrote: > Did this poisoning happen often in Fedora Extras? If not then maybe > it's better to assume that the packages are not poisoning the > buildroots, and assume the Fedora Extras way instead of the Core way? Different data sets really, but still worthy of discussion. Honestly this is the way it's been internally for a while, since before I got here, and now we're using a different buildsystem so past data is not exactly relevant. Maybe we could experiment with Fedora 7 updates and see what happens? Seems risky though :/ -- 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 Jun 5 15:46:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 17:46:36 +0200 Subject: koji: not building against koji-built packages? bug or user issue? In-Reply-To: <200706051127.51058.jkeating@redhat.com> References: <20070605133123.GP23972@neu.nirvana> <200706051028.25740.jkeating@redhat.com> <20070605150548.GF23972@neu.nirvana> <200706051127.51058.jkeating@redhat.com> Message-ID: <20070605154636.GH23972@neu.nirvana> On Tue, Jun 05, 2007 at 11:27:50AM -0400, Jesse Keating wrote: > On Tuesday 05 June 2007 11:05:48 Axel Thimm wrote: > > Did this poisoning happen often in Fedora Extras? If not then maybe > > it's better to assume that the packages are not poisoning the > > buildroots, and assume the Fedora Extras way instead of the Core way? > > Different data sets really, but still worthy of discussion. Honestly this is > the way it's been internally for a while, since before I got here, and now > we're using a different buildsystem so past data is not exactly relevant. > > Maybe we could experiment with Fedora 7 updates and see what happens? Seems > risky though :/ Alternatively maybe bodhi comes to the rescue and packagers could have another (parallel) level of pushing? Because ideally I would had built apt/synaptic before pushing any of the two to updates-testing. -- 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 caillon at redhat.com Tue Jun 5 15:51:26 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 05 Jun 2007 11:51:26 -0400 Subject: Disttags are nice, save the disttags In-Reply-To: <20070605091644.GF23972@neu.nirvana> References: <1180965652.2883.4.camel@kennedy> <46641E18.6080806@fedoraproject.org> <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> <20070605091644.GF23972@neu.nirvana> Message-ID: <4665867E.1080301@redhat.com> Axel Thimm wrote: >> You're missing the point. If a package is only updated e.g. once a >> year, > > So you know beforehand how often a package will be updated in the > future? For every package I maintain, I am able to give you a reasonable estimate yes. For new packages, I am able to also give you a reasonable guess based on the interaction I have with upstream for new packages and looking at project history. I think all maintainers should have a very good idea of how often releases are made. >> and that one update is only for e.g. glibc ABI changes -- guess >> what, ABI in a release (Zod, Moonshine, etc) isn't changing > > Not true, for Zod -> Moonshine this was a first timer. And had gcc 4.2 > landed in the usual timeframe (was expected around December) we > wouldn't even be talking about rebuilds. gcc 4.2 which is now almost a > month old will most probably make it into F8 very soon. > >> so there's no need to rebuild that. Just bump in rawhide and >> rebuild there. disttag doesn't gain you anything here in the >> branches. > > Let's revert the question: "Why is it better without a disttag, out of > curiosity?". There is definitely a gain with a disttag, one can argue > how big it is, but what are the drawbacks? That some packages give > away their age? I see that as a feature, not a bug: "Hey, bridge-utils > is broken on F7. Hm, it has an fc6 marker. OK, it was built on FC6's > kernel-headers from 2.6.18, no wonder it doesn't know anything about > 2.6.21" I honestly don't care one way either way about the disttag. I use it, but I never had the pain that other people had, and I've had to deal with packaging all the way back to RHEL2. But one of the arguments being made is that rebuilds should be done to avoid old disttags in newer releases. I think that's silly. If there's a package that doesn't need a rebuild, it doesn't need a rebuild. Enforcing once due to disttags is a dumb idea, IMO[1]. If people are going to enforce the "if your package has a disttag, it must get rebuilt" rule, I'd just start using less disttags. [1] Actually, I think we shouldn't necessary show the RPM release number by default to the user in e.g. the installer. The average user doesn't know what half+ the things they are installing are anyway, let alone whether the numbers after it mean it's new or old. And if we can avoid it in places such as pirut/pupplet by default (I imagine some people might want to turn it on and we could perhaps offer that) then I think that would be a win, too and would help combat the "omg, i thought this was fc7 not fc6 lol" general sentiment. From Axel.Thimm at ATrpms.net Tue Jun 5 16:01:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Jun 2007 18:01:08 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <4665867E.1080301@redhat.com> References: <46642DCF.7040503@leemhuis.info> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> <20070605091644.GF23972@neu.nirvana> <4665867E.1080301@redhat.com> Message-ID: <20070605160108.GI23972@neu.nirvana> On Tue, Jun 05, 2007 at 11:51:26AM -0400, Christopher Aillon wrote: > >Let's revert the question: "Why is it better without a disttag, out of > >curiosity?". There is definitely a gain with a disttag, one can argue > >how big it is, but what are the drawbacks? That some packages give > >away their age? I see that as a feature, not a bug: "Hey, bridge-utils > >is broken on F7. Hm, it has an fc6 marker. OK, it was built on FC6's > >kernel-headers from 2.6.18, no wonder it doesn't know anything about > >2.6.21" > > I honestly don't care one way either way about the disttag. I use it, > but I never had the pain that other people had, and I've had to deal > with packaging all the way back to RHEL2. > > But one of the arguments being made is that rebuilds should be done to > avoid old disttags in newer releases. I think that's silly. I completely agree, this is more than silly. Never rebuild just for the disttag's sake, noone here advocates this (I hope), at least I don't. > If there's a package that doesn't need a rebuild, it doesn't need a > rebuild. Enforcing once due to disttags is a dumb idea, IMO[1]. If > people are going to enforce the "if your package has a disttag, it > must get rebuilt" rule, I'd just start using less disttags. The discussion about disttags and mass-rebuilds need to be orthogonal. Disttags are a mean to an ends, not the other way around. If both are decided to be used they *can* be combined, but that's another story. -- 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 lmacken at redhat.com Tue Jun 5 16:05:34 2007 From: lmacken at redhat.com (Luke Macken) Date: Tue, 5 Jun 2007 12:05:34 -0400 Subject: Bodhi returns 500 Internal Error when submitting new update In-Reply-To: <1181031700.3911.30.camel@dhcp-lab-214.brq.redhat.com> References: <1181031700.3911.30.camel@dhcp-lab-214.brq.redhat.com> Message-ID: <20070605160534.GX13318@tomservo.rochester.rr.com> On Tue, Jun 05, 2007 at 10:21:40AM +0200, Jan Safranek wrote: > Greetings, > > I would like to update xinetd package in F7. I built it few weeks ago > [1] during devel. freeze and now I want to publish it. > > I log into https://admin.fedoraproject.org/updates/, press 'New update' > and fill the form: > > Package: xinetd-2.3.14-12.fc7 > Release: Fedora7 > Type: bugfix > Bugs: 195265 > CVEs: > Notes: > > Now, when pressing 'Submit', I get 500 Internal error. > > Any ideas what could be wrong? Thanks in advance > > Jan > > [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=6707 Unicode (or lack of) issue with your full name and getting it into the db. I'm working on it now. Sorry for the inconvenience. luke From caillon at redhat.com Tue Jun 5 16:03:49 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 05 Jun 2007 12:03:49 -0400 Subject: Disttags are nice, save the disttags In-Reply-To: <200706050715.03767.jkeating@redhat.com> References: <46641E18.6080806@fedoraproject.org> <200706050640.19469.jkeating@redhat.com> <20070605110911.GO23972@neu.nirvana> <200706050715.03767.jkeating@redhat.com> Message-ID: <46658965.9030805@redhat.com> Jesse Keating wrote: > On Tuesday 05 June 2007 07:09:11 Axel Thimm wrote: >> Let's not assume packagers are dump package monkeys. Packages from >> *Core* have been the ones that didn't carry disttags, Extras always >> did to an extreme high percentage from day one. And there were not >> really 10% worth of the whole distribution new packages in Core each >> release, these were packages *consciously* moved to using disttags by >> @redhat.com employees. > > Many core packages picked up dist tags because reviewers recommended them and > so packagers just added that with the rest of the stuff they had to change. > Seriously I be if we polled all the packagers whom use dist tags, the > majority would state something along the line of "the rest of the repo does" > or "I use them on all my other packages so now it's consistant" or "the spec > generated for me already had it, I didn't know what it was so I didn't remove > it". * I kept getting patches where people kept adding a disttag. * Some people actually added it into my package "for me". * To make everyone STFU. are my reasons. I've had no problems maintaining a proper upgrade path with all the crazy mozilla/seamonkey/firefox/thunderbird stuff all the way back to RHEL2. Dist tag is there not because it saves me time with packaging but because it wastes less time listening to others whine about it. > I highly highly doubt each and every dist tag was a result of a well > thought out process that investigated the long term effects and usefulness of > having a dist tag in the spec. Agreed. >> And the people that added %{?dist} to the templates (Ville?) aren't >> that unconscious either. ;) > > So one maintainer decides that dist tags are useful for every single new > package in Fedora, and is /right/ about every single new package in Fedora? > I think not. It's great that it is there and shows how to properly use it. > However just assuming that everybody KNOWS what it is there for when making a > new package and understands the consequences of using it is pretty laughable. Agreed. From bugs.michael at gmx.net Tue Jun 5 16:05:06 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Jun 2007 18:05:06 +0200 Subject: koji: not building against koji-built packages? bug or user issue? In-Reply-To: <20070605150548.GF23972@neu.nirvana> References: <20070605133123.GP23972@neu.nirvana> <200706051028.25740.jkeating@redhat.com> <20070605150548.GF23972@neu.nirvana> Message-ID: <20070605180506.2db7f455.bugs.michael@gmx.net> On Tue, 5 Jun 2007 17:05:48 +0200, Axel Thimm wrote: > Did this poisoning happen often in Fedora Extras? If not then maybe > it's better to assume that the packages are not poisoning the > buildroots, and assume the Fedora Extras way instead of the Core way? With fatal effects on subsequent build jobs? Around half a dozen times since Fedora Extras uses plague. (the typical shortest pkg name wins during depsolving and provides something it must not provide) In those cases somebody had to clean up the needsign repo after a packaged had asked for help. With other forms of dep breakage (that could become visible for subsequent build jobs, too) it has happened more often, perhaps 1-2 times a week, and packagers usually fix it with rebuilds. From fedora-packaging at dw-perspective.org.uk Tue Jun 5 16:06:00 2007 From: fedora-packaging at dw-perspective.org.uk (David Anderson) Date: Tue, 5 Jun 2007 17:06:00 +0100 Subject: Announcements list for packagers Message-ID: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> I'd like to +1 the recent suggestions for a mailing list solely dedicated to spreading necessary information to packagers. I have not much interest in most of the discussions that go on on fedora-maintainers, but I have to read them all in order to find the valuable information. I only maintain 4 packages, so it doesn't take much pain before I start wondering if the effort is worth it. I wonder how many packages in Fedora are maintained by people like me who have less than 10, say? At times I am tempted to unsubscribe and just check the wiki once I find that something seems to have changed (e.g. my packages don't build or appear), instead of trawling through all the discussions. I want to maintain my packages; if this gets too time-consuming I'll have to drop them. Kind regards, David -- "For the wages of sin is death; but the gift of God is eternal life through Jesus Christ our Lord." - Romans 6:23 From notting at redhat.com Tue Jun 5 16:07:13 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 5 Jun 2007 12:07:13 -0400 Subject: libwnck soname up In-Reply-To: <1181034535.25009.157.camel@cookie.hadess.net> References: <1180988927.25009.136.camel@cookie.hadess.net> <466477D2.8050903@redhat.com> <1180990691.25009.143.camel@cookie.hadess.net> <46647E34.7080304@redhat.com> <1180992220.25009.145.camel@cookie.hadess.net> <4664D22D.6080404@redhat.com> <1181034535.25009.157.camel@cookie.hadess.net> Message-ID: <20070605160713.GD19228@nostromo.devel.redhat.com> Bastien Nocera (bnocera at redhat.com) said: > > Looks like mclasen went ahead and re-built everything so I guess this is > > kind of moot. Might as well let other distros suffer at this point. :-) > > He fights crime when I'm sleeping, he's my hero. He's Batman? Bill From Jochen at herr-schmitt.de Tue Jun 5 16:22:16 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 05 Jun 2007 18:22:16 +0200 Subject: Announcements list for packagers In-Reply-To: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> Message-ID: <0ML25U-1Hvbnx3OZc-0006P0@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 5 Jun 2007 17:06:00 +0100, you wrote: >I'd like to +1 the recent suggestions for a mailing list solely >dedicated to spreading necessary information to packagers. +1 too. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) Charset: us-ascii wj8DBQFGZY3QT2AHK6txfgwRAq15AKDWY3DZReyI2lCabH5qZekPXMFkngCfR31s CiFHAshxLBTdhdCkZFwXZow= =LpsV -----END PGP SIGNATURE----- From david at lovesunix.net Tue Jun 5 16:29:23 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 05 Jun 2007 18:29:23 +0200 Subject: koji: not building against koji-built packages? bug or user issue? In-Reply-To: <200706051028.25740.jkeating@redhat.com> References: <20070605133123.GP23972@neu.nirvana> <200706051028.25740.jkeating@redhat.com> Message-ID: <1181060963.28187.6.camel@dawkins> tir, 05 06 2007 kl. 10:28 -0400, skrev Jesse Keating: > On Tuesday 05 June 2007 09:31:23 Axel Thimm wrote: > > I built apt and synaptic in this order: > > > > ID: 7866: apt-0.5.15lorg3.2-10.fc7 (Finished: Sun, 03 Jun 2007 02:46:43 > > MST) ID: 7943: synaptic-0.57.2-7.fc7 (Started Mon, 04 Jun 2007 03:59:34 > > MST) > > > > e.g. there was more than one day in between. Still the synaptic build > > used the old apt package, for example: > > > > http://koji.fedoraproject.org/koji/getfile?taskID=25522&name=root.log > > ... > > 0:apt-devel-0.5.15lorg3.2-9.fc7.i386 > > ... > > > > The proper apt package was even in updates-testing since 2007-06-03 > > 21:12:03. > > > > Did I do something wrong? If yes, how do I ensure that packages get > > built against each-other before pushing to updates(-testing)? With the > > former setup (plague) this was automatic. If not, why did koji not see > > the 25h old package it built? > > It got buried before, but the way that release trees are handled are different > than rawhide. In Core, our release update candidates do not autopopulate the > buildroot. This is to protect our buildroot from being poisoned by > potentially bad updates. They are treated as candidate updates and not > entered into the buildroot until they are pushed as a stable update. There > is an override tag that rel-eng can use to make a build temporarily available > to build the rest of a stack for an update. I don't like the scenario at all > and I'm welcome to ideas. Just self updating the buildroot seems like a bad > idea to me and some of my colleagues who have been doing RHL/RHEL stuff for > far longer than I have. Ideally we'd have a way to chainbuild things > together in such a way that it doesn't poison the rest of the buildroots for > that tag, basically making them available for your build and your build > alone. I honestly don't know what kind of work it would take to get this > though. > > Anyway I'm open for discussion. I went forward with what Core developers are > used to, and I hoped I had warned people but it probably got lost. I would > love to discuss it at a rel-eng meeting, we ran out of time last week. > > For now, you can request buildroot overrides by > mailing 'rel-eng at fedoraproject.org'. What place in the wiki should this > information go? It would be nice if this was at least documented somewhere and it was included in the "first package" guide. I just submitted Empathy and was greatly shocked when it built on FC-6 and Devel but failed on F-7 considering I'd done several mock builds just to make sure this would go smoothly. Now it failed because it depends on telepathy-mission-control-devel which was introduced a few days ago, I naively assumed this would work, it's in Fedora after all. This illogic definitely needs to be mentioned to new users as well as a guide on how to make the problem go away. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From dwmw2 at infradead.org Tue Jun 5 17:07:59 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 05 Jun 2007 18:07:59 +0100 Subject: No sound on PowerPC Mac Mini after upgrading from fc6 to Fedora7 In-Reply-To: References: Message-ID: <1181063279.16089.37.camel@hades.cambridge.redhat.com> On Mon, 2007-06-04 at 22:24 +0400, Peter Lemenkov wrote: > I tried to modprode snd-aoa, to rmmod snd-powermac and vice versa, to > rename any snd-powermac in /etc/modprobe to snd-aoa, to start kudzu, > to stop kudzu but with zero success. Then I did ls /dev/snd I saw only > seq and timer. Hm... I think there's a Mini in the passenger footwell of my car (damn computers get everywhere). I'll take it indoors and see if it makes noise. Does it help if you load all the other modules under /lib/modules/`uname -r`/kernel/sound/aoa ? -- dwmw2 From spr at astrax.fis.ucm.es Tue Jun 5 17:10:43 2007 From: spr at astrax.fis.ucm.es (Sergio Pascual) Date: Tue, 05 Jun 2007 19:10:43 +0200 Subject: Announcements list for packagers In-Reply-To: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> Message-ID: <1181063444.3035.0.camel@elric.sttl.org> El mar, 05-06-2007 a las 17:06 +0100, David Anderson escribi?: > I'd like to +1 the recent suggestions for a mailing list solely > dedicated to spreading necessary information to packagers. > +1, I agree Best Regards, Sergio Pascual From bos at serpentine.com Tue Jun 5 17:12:07 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue, 05 Jun 2007 10:12:07 -0700 Subject: Announcements list for packagers In-Reply-To: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> Message-ID: <46659967.3040706@serpentine.com> David Anderson wrote: > I'd like to +1 the recent suggestions for a mailing list solely > dedicated to spreading necessary information to packagers. +1 from me, too. From jkeating at redhat.com Tue Jun 5 17:52:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 13:52:58 -0400 Subject: koji: not building against koji-built packages? bug or user issue? In-Reply-To: <1181060963.28187.6.camel@dawkins> References: <20070605133123.GP23972@neu.nirvana> <200706051028.25740.jkeating@redhat.com> <1181060963.28187.6.camel@dawkins> Message-ID: <200706051353.04432.jkeating@redhat.com> On Tuesday 05 June 2007 12:29:23 David Nielsen wrote: > It would be nice if this was at least documented somewhere and it was > included in the "first package" guide. I just submitted Empathy and was > greatly shocked when it built on FC-6 and Devel but failed on F-7 > considering I'd done several mock builds just to make sure this would go > smoothly. Now it failed because it depends on > telepathy-mission-control-devel which was introduced a few days ago, I > naively assumed this would work, it's in Fedora after all. > > This illogic definitely needs to be mentioned to new users as well as a > guide on how to make the problem go away. Can you recommend which pages to edit? I get lost in the sea of pages... -- 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 david at lovesunix.net Tue Jun 5 18:27:05 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 05 Jun 2007 20:27:05 +0200 Subject: koji: not building against koji-built packages? bug or user issue? In-Reply-To: <200706051353.04432.jkeating@redhat.com> References: <20070605133123.GP23972@neu.nirvana> <200706051028.25740.jkeating@redhat.com> <1181060963.28187.6.camel@dawkins> <200706051353.04432.jkeating@redhat.com> Message-ID: <1181068025.28187.14.camel@dawkins> tir, 05 06 2007 kl. 13:52 -0400, skrev Jesse Keating: > On Tuesday 05 June 2007 12:29:23 David Nielsen wrote: > > It would be nice if this was at least documented somewhere and it was > > included in the "first package" guide. I just submitted Empathy and was > > greatly shocked when it built on FC-6 and Devel but failed on F-7 > > considering I'd done several mock builds just to make sure this would go > > smoothly. Now it failed because it depends on > > telepathy-mission-control-devel which was introduced a few days ago, I > > naively assumed this would work, it's in Fedora after all. > > > > This illogic definitely needs to be mentioned to new users as well as a > > guide on how to make the problem go away. > > Can you recommend which pages to edit? I get lost in the sea of pages... http://fedoraproject.org/wiki/PackageMaintainers/Join definitely needs a note on why this happens and how to fix it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From fedora at leemhuis.info Tue Jun 5 18:53:59 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 05 Jun 2007 20:53:59 +0200 Subject: Easier way to maintain comps.xml ? Message-ID: <4665B147.9010206@leemhuis.info> Hi all! Just fishing for opinions here. EPEL will likely have a comps.xml soon, too. Thus if you add a new package to Fedora and build it for all supported dists you have to add the entry to five comps.xml files in the future (Fedora current, Fedora current-1, Fedora devel, EPEL4 and EPEL5 (not counting Fedora current-2, which would be FC-5 currently, but that is EOL soon)). Isn't there a easier way to maintain that information in the long term? Maybe via the package database? The only thing that might be different in the different comps.xml files is afaics the group a package belongs to. Or do we simply don't care as we have bigger problems right now? CU thl From sundaram at fedoraproject.org Tue Jun 5 18:56:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 Jun 2007 00:26:16 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4664FCB4.2000509@serpentine.com> References: <200706031108.23794.jkeating@redhat.com> <200706041154.51507.jkeating@redhat.com> <46643780.7000303@fedoraproject.org> <200706041203.58789.jkeating@redhat.com> <4664FCB4.2000509@serpentine.com> Message-ID: <4665B1D0.3040507@fedoraproject.org> Bryan O'Sullivan wrote: > Jesse Keating wrote: > >> If someone installs the RC version and they just want to get to the >> Final version when it's released, they do nothing except 'yum update' >> when the final version is released. > > On a related note, I was running rawhide between test2 and F7 final. But > yum didn't pick up any change to the fedora-release package, which left > me picking up the first round of fc8 rebuilds after the dam broke, > because I was still being pointed at the development repos. I spent a > few hours on different machines downloading the F7 final packages that > had been updated and manually rolling them back with "rpm -U > --oldpackage". Ugh. This is precisely what I wanted to avoid. Simply pushing out a updated fedora-release to the development tree which will point users to the general release repository before the next version updates are pushed out would avoid this problem. This time a number of people have been caught up by the devel - F8 changes. Rahul From jkeating at redhat.com Tue Jun 5 18:53:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 5 Jun 2007 14:53:44 -0400 Subject: Easier way to maintain comps.xml ? In-Reply-To: <4665B147.9010206@leemhuis.info> References: <4665B147.9010206@leemhuis.info> Message-ID: <200706051453.45084.jkeating@redhat.com> On Tuesday 05 June 2007 14:53:59 Thorsten Leemhuis wrote: > Hi all! > > Just fishing for opinions here. > > EPEL will likely have a comps.xml soon, too. Thus if you add a new > package to Fedora and build it for all supported dists you have to add > the entry to five comps.xml files in the future (Fedora current, Fedora > current-1, Fedora devel, EPEL4 and EPEL5 (not counting Fedora current-2, > which would be FC-5 currently, but that is EOL soon)). > > Isn't there a easier way to maintain that information in the long term? > Maybe via the package database? The only thing that might be different > in the different comps.xml files is afaics the group a package belongs to. > > Or do we simply don't care as we have bigger problems right now? > We know that comps sucks, and we want to fix it. Time and bandwidth are the issues. -- 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 Tue Jun 5 19:06:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 05 Jun 2007 21:06:57 +0200 Subject: Easier way to maintain comps.xml ? In-Reply-To: <200706051453.45084.jkeating@redhat.com> References: <4665B147.9010206@leemhuis.info> <200706051453.45084.jkeating@redhat.com> Message-ID: <4665B451.9000106@leemhuis.info> On 05.06.2007 20:53, Jesse Keating wrote: > On Tuesday 05 June 2007 14:53:59 Thorsten Leemhuis wrote: >> Just fishing for opinions here. >> >> EPEL will likely have a comps.xml soon, too. Thus if you add a new >> package to Fedora and build it for all supported dists you have to add >> the entry to five comps.xml files in the future (Fedora current, Fedora >> current-1, Fedora devel, EPEL4 and EPEL5 (not counting Fedora current-2, >> which would be FC-5 currently, but that is EOL soon)). >> >> Isn't there a easier way to maintain that information in the long term? >> Maybe via the package database? The only thing that might be different >> in the different comps.xml files is afaics the group a package belongs to. >> >> Or do we simply don't care as we have bigger problems right now? > > We know that comps sucks, and we want to fix it. Time and bandwidth are the > issues. Ohh, sorry, I didn't know there were bigger plans on the horizon. The it's likely the easiest to just create comps.xml for EPEL and forget about the "package db integration" idea for now. Thanks Jesse. CU knurd From jwboyer at jdub.homelinux.org Tue Jun 5 19:16:32 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 05 Jun 2007 14:16:32 -0500 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4665B1D0.3040507@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <200706041154.51507.jkeating@redhat.com> <46643780.7000303@fedoraproject.org> <200706041203.58789.jkeating@redhat.com> <4664FCB4.2000509@serpentine.com> <4665B1D0.3040507@fedoraproject.org> Message-ID: <1181070992.11302.3.camel@zod.rchland.ibm.com> On Wed, 2007-06-06 at 00:26 +0530, Rahul Sundaram wrote: > Bryan O'Sullivan wrote: > > Jesse Keating wrote: > > > >> If someone installs the RC version and they just want to get to the > >> Final version when it's released, they do nothing except 'yum update' > >> when the final version is released. > > > > On a related note, I was running rawhide between test2 and F7 final. But > > yum didn't pick up any change to the fedora-release package, which left > > me picking up the first round of fc8 rebuilds after the dam broke, > > because I was still being pointed at the development repos. I spent a > > few hours on different machines downloading the F7 final packages that > > had been updated and manually rolling them back with "rpm -U > > --oldpackage". Ugh. > > This is precisely what I wanted to avoid. Simply pushing out a updated > fedora-release to the development tree which will point users to the > general release repository before the next version updates are pushed > out would avoid this problem. This time a number of people have been > caught up by the devel - F8 changes. How would pushing that out have helped? You need to manually enable the development repos. Pushing an updated fedora-release for F7 would have marked fedora-development.repo as .rpmnew but that wouldn't be picked up by yum. Either way, manual intervention is required for people who are coming from rawhide. josh From wolters.liste at gmx.net Tue Jun 5 20:12:03 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Tue, 5 Jun 2007 22:12:03 +0200 Subject: Announcements list for packagers In-Reply-To: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> Message-ID: <200706052213.22573.wolters.liste@gmx.net> Once upon a time David Anderson wrote: > I'd like to +1 the recent suggestions for a mailing list solely > dedicated to spreading necessary information to packagers. > +1, same here. Fortunately I didn't have to figure out the new build system yet, because as I read there is still not a real good FAQ for that. And no, the mailing list is not an option for someone with only a few packages. Roland -- Ich kann nicht so viel fressen, wie ich kotzen m?chte. -- Max Liebermann -------------- 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 Tue Jun 5 20:17:47 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 5 Jun 2007 22:17:47 +0200 Subject: Bodhi updates-testing Autopush, Anonymous Commenting In-Reply-To: <46645B98.70001@redhat.com> References: <46645B98.70001@redhat.com> Message-ID: <20070605201747.GC14845@ryvius.pekin.waw.pl> On Monday, 04 June 2007 at 20:36, Warren Togami wrote: > This thread contains only strawman ideas to solicit ideas and opinions > for Bodhi. > > NOTE: This mail talks only about how updates-testing tickets in bodhi > behave after they become updates-testing. The controversial matter of > whether a package is required to go into updates-testing is a separate > matter to be discussed and ratified during Thursday's FESCo meeting. > > Idea: updates-testing Autopush after Timeout > ============================================ > 1) Bodhi should auto-push updates-testing after a time-out period. Definitely. As long as no negative comments were entered. > 2) Bodhi interface allows others to comment on the goodness/badness of a > test update. > 3) Bodhi interface allows others to declare a test update broken, which > freezes the auto-push after timeout. > 4) Package maintainer or admins can override this and push anyway. Sounds good. > Idea: Timeout Default, Configurable? > ==================================== > Default updates-testing timeout is 7 days. Package maintainer may set a > different timeout period (i.e. 4, 9 or 14 days), or turn off the timeout > entirely. 7 days is a bit long, but as long as it's configurable, I have no objections. > Idea: Anonymous Commenting +1 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 caillon at redhat.com Tue Jun 5 20:21:17 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 05 Jun 2007 16:21:17 -0400 Subject: Announcements list for packagers In-Reply-To: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> Message-ID: <4665C5BD.7000503@redhat.com> David Anderson wrote: > I'd like to +1 the recent suggestions for a mailing list solely > dedicated to spreading necessary information to packagers. Actually, I thought that was this list. Can we move all the other discussion to fedora-devel? From dominik at greysector.net Tue Jun 5 20:27:19 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 5 Jun 2007 22:27:19 +0200 Subject: Pushing updates for Fedora 7 In-Reply-To: <200706010929.50800.jkeating@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180701824.5761.70.camel@vader.jdub.homelinux.org> <466017DE.5050006@hhs.nl> <200706010929.50800.jkeating@redhat.com> Message-ID: <20070605202719.GD14845@ryvius.pekin.waw.pl> On Friday, 01 June 2007 at 15:29, Jesse Keating wrote: > On Friday 01 June 2007 08:58:06 Hans de Goede wrote: > > I _really_ see no use for new packages being in updates-testing, this only > > makes the process to get new packages into Fedora one step longer, which > > makes it less attractive to add new packages, without giving anything > > substantial in return. Remember new packages have just been thoroughly > > vetted during review and are already installed and run by the reviewer. > > Look, you're adding a new package to a stable platform. The review most > likely focused on devel, where you can get your instant gratification. I beg to differ here. All my reviews were done on latest release, NOT devel. devel was only used for mockbuilds. [...] > And you know what, adding software to a stable platform _should_ be a bit > harder. We don't want to just chuck every new package that tickles our fancy > at the released products, especially as many of the maintainers are working > on rawhide and not on the past release, or the past release -1. You say they are working on rawhide... but I see a different image. My maintainer colleagues and I work on past release, NOT rawhide. > These > packages to stable platforms deserve extra scrutiny and extra care as to not > destabilize a release and feed to the negative impressions of Fedora as > nothing but a perpetual beta. It'd be difficult to beat Gentoo. ;) Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From opensource at till.name Tue Jun 5 20:33:57 2007 From: opensource at till.name (Till Maas) Date: Tue, 05 Jun 2007 22:33:57 +0200 Subject: Announcements list for packagers In-Reply-To: <4665C5BD.7000503@redhat.com> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4665C5BD.7000503@redhat.com> Message-ID: <200706052234.00251.opensource@till.name> On Di Juni 5 2007, Christopher Aillon wrote: > Actually, I thought that was this list. Can we move all the other > discussion to fedora-devel? The information on https://www.redhat.com/mailman/listinfo/fedora-maintainers does not give any hint into this direction. It is quite contrary, as the following sentence shows: | If you wish to follow discussions on this list without being a package ^^^^^^^^^^^^^^^^^^^^^^^^ | maintainers, please subscribe to fedora-maintainers-readonly Regards, Till From belegdol at gmail.com Tue Jun 5 21:11:14 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Tue, 5 Jun 2007 22:11:14 +0100 Subject: Announcements list for packagers In-Reply-To: <200706052234.00251.opensource@till.name> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4665C5BD.7000503@redhat.com> <200706052234.00251.opensource@till.name> Message-ID: <9b1b20e70706051411x596c023fl935ac70abf03acc1@mail.gmail.com> 2007/6/5, Till Maas : > On Di Juni 5 2007, Christopher Aillon wrote: > > > Actually, I thought that was this list. Can we move all the other > > discussion to fedora-devel? > > The information on > https://www.redhat.com/mailman/listinfo/fedora-maintainers > does not give any hint into this direction. It is quite contrary, as the > following sentence shows: > > | If you wish to follow discussions on this list without being a package > ^^^^^^^^^^^^^^^^^^^^^^^^ > | maintainers, please subscribe to fedora-maintainers-readonly > > Regards, > Till > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > +1. I am maintaining 10 packages (and thinking about handing one over) and when fedora-extras list closed I did not subscribe to fedora-devel because it is too much traffic for me. Apparently, the list that has taken over fedora-extras list discussions is fedora-maintainers, not fedora-devel. Now my mailbox is bombed with lots of email, and some important info is sometimes well hidden. And, with all due respect, I am quite reluctant to read all this stuff folks wrote since quite a large part of it is irrelevant to me (and especially now drifting into flamewars). From lmacken at redhat.com Tue Jun 5 22:25:41 2007 From: lmacken at redhat.com (Luke Macken) Date: Tue, 5 Jun 2007 18:25:41 -0400 Subject: Bodhi returns 500 Internal Error when submitting new update In-Reply-To: <1181031700.3911.30.camel@dhcp-lab-214.brq.redhat.com> References: <1181031700.3911.30.camel@dhcp-lab-214.brq.redhat.com> Message-ID: <20070605222541.GD13318@tomservo.rochester.rr.com> On Tue, Jun 05, 2007 at 10:21:40AM +0200, Jan Safranek wrote: > Greetings, > > I would like to update xinetd package in F7. I built it few weeks ago > [1] during devel. freeze and now I want to publish it. > > I log into https://admin.fedoraproject.org/updates/, press 'New update' > and fill the form: > > Package: xinetd-2.3.14-12.fc7 > Release: Fedora7 > Type: bugfix > Bugs: 195265 > CVEs: > Notes: > > Now, when pressing 'Submit', I get 500 Internal error. > > Any ideas what could be wrong? Thanks in advance So I think we may have hit a weird SQLObject bug, or something in the python db libraries. Either way, I reverted back to only storing people's usernames in the db until we can figure this out. Let me know if you have any problems. luke From lmacken at redhat.com Tue Jun 5 22:25:56 2007 From: lmacken at redhat.com (Luke Macken) Date: Tue, 5 Jun 2007 18:25:56 -0400 Subject: Info for package maintainers In-Reply-To: <1181046932.5736.4.camel@localhost.localdomain> References: <1181043504.5163.4.camel@localhost.localdomain> <200706050743.34142.jkeating@redhat.com> <1181046932.5736.4.camel@localhost.localdomain> Message-ID: <20070605222556.GE13318@tomservo.rochester.rr.com> On Tue, Jun 05, 2007 at 02:35:32PM +0200, G?rard Milmeister wrote: > On Tue, 2007-06-05 at 07:43 -0400, Jesse Keating wrote: > > The start of the updates tool FAQ is at > > http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT > Ok, I had already found this page. The problem is that there seems to be > no doc about how all the pieces work together. Of course everything > could be inferred by following the ML closely, but this is impossible > with the current amount of traffic. I think there should be a link on > the wiki frontpage "Everything you always wanted to know about > packaging, but were afraid to ask". > > Anyway, I tried to push an update through bodhi, but I get the following > internal error: > The server encountered an unexpected condition which prevented it from > fulfilling the request. This should be fixed. luke From rc040203 at freenet.de Tue Jun 5 22:38:46 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Jun 2007 00:38:46 +0200 Subject: Announcements list for packagers In-Reply-To: <9b1b20e70706051411x596c023fl935ac70abf03acc1@mail.gmail.com> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4665C5BD.7000503@redhat.com> <200706052234.00251.opensource@till.name> <9b1b20e70706051411x596c023fl935ac70abf03acc1@mail.gmail.com> Message-ID: <1181083126.3238.5.camel@mccallum.corsepiu.local> On Tue, 2007-06-05 at 22:11 +0100, Julian Sikorski wrote: > 2007/6/5, Till Maas : > > On Di Juni 5 2007, Christopher Aillon wrote: > > > > > Actually, I thought that was this list. Can we move all the other > > > discussion to fedora-devel? Why should we? Are the topics currently discussed here of interest to non-maintainers? > +1. I am maintaining 10 packages (and thinking about handing one over) > and when fedora-extras list closed I did not subscribe to fedora-devel > because it is too much traffic for me. Apparently, the list that has > taken over fedora-extras list discussions is fedora-maintainers, not > fedora-devel. Nope. The reason this list currently sees a nice amount of traffic is many changes and bugs of the build system affecting a maintainer's workflow. Ralf From mastahnke at gmail.com Tue Jun 5 22:40:03 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 5 Jun 2007 17:40:03 -0500 Subject: Easier way to maintain comps.xml ? In-Reply-To: <4665B451.9000106@leemhuis.info> References: <4665B147.9010206@leemhuis.info> <200706051453.45084.jkeating@redhat.com> <4665B451.9000106@leemhuis.info> Message-ID: <7874d9dd0706051540g22916555x7c233067ee71c71d@mail.gmail.com> Can I help with the comps.xml issue? I don't much about it, but it sounds interesting to me. stahnma On 6/5/07, Thorsten Leemhuis wrote: > On 05.06.2007 20:53, Jesse Keating wrote: > > On Tuesday 05 June 2007 14:53:59 Thorsten Leemhuis wrote: > >> Just fishing for opinions here. > >> > >> EPEL will likely have a comps.xml soon, too. Thus if you add a new > >> package to Fedora and build it for all supported dists you have to add > >> the entry to five comps.xml files in the future (Fedora current, Fedora > >> current-1, Fedora devel, EPEL4 and EPEL5 (not counting Fedora current-2, > >> which would be FC-5 currently, but that is EOL soon)). > >> > >> Isn't there a easier way to maintain that information in the long term? > >> Maybe via the package database? The only thing that might be different > >> in the different comps.xml files is afaics the group a package belongs to. > >> > >> Or do we simply don't care as we have bigger problems right now? > > > > We know that comps sucks, and we want to fix it. Time and bandwidth are the > > issues. > > Ohh, sorry, I didn't know there were bigger plans on the horizon. The > it's likely the easiest to just create comps.xml for EPEL and forget > about the "package db integration" idea for now. > > Thanks Jesse. > > CU > knurd > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From sundaram at fedoraproject.org Tue Jun 5 23:56:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 Jun 2007 05:26:45 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1181070992.11302.3.camel@zod.rchland.ibm.com> References: <200706031108.23794.jkeating@redhat.com> <200706041154.51507.jkeating@redhat.com> <46643780.7000303@fedoraproject.org> <200706041203.58789.jkeating@redhat.com> <4664FCB4.2000509@serpentine.com> <4665B1D0.3040507@fedoraproject.org> <1181070992.11302.3.camel@zod.rchland.ibm.com> Message-ID: <4665F83D.6040706@fedoraproject.org> Josh Boyer wrote: > How would pushing that out have helped? > > You need to manually enable the development repos. Pushing an updated > fedora-release for F7 would have marked fedora-development.repo > as .rpmnew but that wouldn't be picked up by yum. Couldn't the package be change to disable the development repo? I think that's what would be useful in this particular instance. Other possibilities though possibly not as effective include adding a different package that turns off devel repository or adding a yum distribution upgrade command that increments that does this job. Rahul From sundaram at fedoraproject.org Wed Jun 6 00:12:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 Jun 2007 05:42:32 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070605142349.GX23972@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <200706031111.22625.jkeating@redhat.com> <20070605142349.GX23972@neu.nirvana> Message-ID: <4665FBF0.9060401@fedoraproject.org> Axel Thimm wrote: > On Sun, Jun 03, 2007 at 11:11:22AM -0400, Jesse Keating wrote: >> On Sunday 03 June 2007 11:08:23 Jesse Keating wrote: >>> /topic RELENG-Meeting - Updates Policy - JesseKeating >>> >>> /topic RELENG-Meeting - Freeze Policy - JesseKeating >> For these two topics I would really really like to get people to bring their >> ideas and thoughts about this to our meeting. Annoyances with the policies >> used for Fedora 7, ideas on how to make it better, etc... Come one, come >> all. I'll happily dedicate the entire meeting to these topics if need be. > > So what was the outcome of the meeting regarding these topics, > especially the freeze and rebuild strategies? Waiting for fesco's > decision? See https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00640.html Rahul From jwboyer at jdub.homelinux.org Wed Jun 6 00:25:35 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 05 Jun 2007 19:25:35 -0500 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4665F83D.6040706@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <200706041154.51507.jkeating@redhat.com> <46643780.7000303@fedoraproject.org> <200706041203.58789.jkeating@redhat.com> <4664FCB4.2000509@serpentine.com> <4665B1D0.3040507@fedoraproject.org> <1181070992.11302.3.camel@zod.rchland.ibm.com> <4665F83D.6040706@fedoraproject.org> Message-ID: <1181089535.7952.7.camel@vader.jdub.homelinux.org> On Wed, 2007-06-06 at 05:26 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > > How would pushing that out have helped? > > > > You need to manually enable the development repos. Pushing an updated > > fedora-release for F7 would have marked fedora-development.repo > > as .rpmnew but that wouldn't be picked up by yum. > > Couldn't the package be change to disable the development repo? I think > that's what would be useful in this particular instance. Other > possibilities though possibly not as effective include adding a > different package that turns off devel repository or adding a yum > distribution upgrade command that increments that does this job. Um... no. Because enabling development in the first place is a manual step. They are config files. Pushing a release version of fedora-release that blindly turned that off would violate the "don't change users configs if they are modified" rule. And it would piss off the rawhide users that actually _want_ to remain on rawhide and help test the next release of Fedora. Seriously, using rawhide is a manual choice that has to be made and if you want to undo that, it should be manual as well. josh From sundaram at fedoraproject.org Wed Jun 6 00:46:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 Jun 2007 06:16:49 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1181089535.7952.7.camel@vader.jdub.homelinux.org> References: <200706031108.23794.jkeating@redhat.com> <200706041154.51507.jkeating@redhat.com> <46643780.7000303@fedoraproject.org> <200706041203.58789.jkeating@redhat.com> <4664FCB4.2000509@serpentine.com> <4665B1D0.3040507@fedoraproject.org> <1181070992.11302.3.camel@zod.rchland.ibm.com> <4665F83D.6040706@fedoraproject.org> <1181089535.7952.7.camel@vader.jdub.homelinux.org> Message-ID: <466603F9.4090703@fedoraproject.org> Josh Boyer wrote: > Um... no. Because enabling development in the first place is a manual > step. They are config files. Pushing a release version of > fedora-release that blindly turned that off would violate the "don't > change users configs if they are modified" rule. Right. In normal situations changing user configurations is something that we should not do. And it would piss off > the rawhide users that actually _want_ to remain on rawhide and help > test the next release of Fedora. Testers usually want to test a single version of Fedora though. Folks who continuously run rawhide are probably low in number and should be experienced enough to switch back the devel repository. > Seriously, using rawhide is a manual choice that has to be made and if > you want to undo that, it should be manual as well. Problem with that is many testers did not know when the devel repository moves beyond Fedora 7 into Fedora 8 and ended with a number of broken FC8 packages. I don't know whether we consider it a problem worth solving but I have seen it bite a considerably large number of folks this time. Rahul From mclasen at redhat.com Wed Jun 6 02:55:09 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 05 Jun 2007 22:55:09 -0400 Subject: libwnck soname bumps Message-ID: <1181098509.3620.5.camel@localhost.localdomain> This is a somewhat late notice about a soname bump in libwnck that happened last night. If you haven't rebuild your dependent packages yet, you may want to hold off a little longer, since there is another soname bump coming down the pipe tonight. This one is for adding padding that will help avoiding future soname bumps. Sorry about this, but you all signed it with WNCK_I_KNOW_THIS_IS_UNSTABLE... Matthias From lemenkov at gmail.com Wed Jun 6 03:44:57 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Wed, 6 Jun 2007 07:44:57 +0400 Subject: No sound on PowerPC Mac Mini after upgrading from fc6 to Fedora7 In-Reply-To: <1181063279.16089.37.camel@hades.cambridge.redhat.com> References: <1181063279.16089.37.camel@hades.cambridge.redhat.com> Message-ID: 2007/6/5, David Woodhouse : > On Mon, 2007-06-04 at 22:24 +0400, Peter Lemenkov wrote: > > I tried to modprode snd-aoa, to rmmod snd-powermac and vice versa, to > > rename any snd-powermac in /etc/modprobe to snd-aoa, to start kudzu, > > to stop kudzu but with zero success. Then I did ls /dev/snd I saw only > > seq and timer. > > Hm... I think there's a Mini in the passenger footwell of my car (damn > computers get everywhere). I'll take it indoors and see if it makes > noise. > > Does it help if you load all the other modules under > /lib/modules/`uname -r`/kernel/sound/aoa ? Yes! It finally works after I added next lines to /etc/rc.local ============================== modprobe snd-aoa-i2sbus modprobe snd-aoa-soundbus modprobe snd-aoa-fabric-layout modprobe snd-aoa ============================== My /etc/modprobe.conf: ============================== blacklist snd_powermac blacklist snd-powermac blacklist bcm43xx alias eth0 sungem alias wlan0 bcm43xx-mac80211 alias snd-card-0 snd-aoa options snd-card-0 index=0 options snd-aoa index=0 remove snd-aoa { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-aoa ============================== -- With best regards! From wtogami at redhat.com Wed Jun 6 04:09:35 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 06 Jun 2007 00:09:35 -0400 Subject: JUST DO IT Re: Announcements list for packagers In-Reply-To: <4665C5BD.7000503@redhat.com> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4665C5BD.7000503@redhat.com> Message-ID: <4666337F.3070105@redhat.com> Christopher Aillon wrote: > David Anderson wrote: >> I'd like to +1 the recent suggestions for a mailing list solely >> dedicated to spreading necessary information to packagers. > > Actually, I thought that was this list. Can we move all the other > discussion to fedora-devel? > This list is supposed to be for discussions. They are asking for a development announcement only list. Many want this. It is insane that a few key fedora leaders are against this, because they feel that everyone should be reading everything on these flooded discussion lists, and if they miss anything then it is their fault. https://www.redhat.com/mailman/listinfo/fedora-maintainers-announce For this reason, FESCO approved a development announce-only list for important stuff to cut through the noise of discussion lists. But it was never launched due to disagreement from key people. I think we should JUST DO IT. https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list This wouldn't be the first list that I created where other people thought it wouldn't be worthwhile. https://www.redhat.com/mailman/listinfo/fedora-php-devel-list And was later copied due to its success. JUST DO IT. IT WILL WORK. Warren Togami wtogami at redhat.com From wtogami at redhat.com Wed Jun 6 04:15:56 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 06 Jun 2007 00:15:56 -0400 Subject: JUST DO IT Re: Announcements list for packagers In-Reply-To: <4666337F.3070105@redhat.com> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4665C5BD.7000503@redhat.com> <4666337F.3070105@redhat.com> Message-ID: <466634FC.7060908@redhat.com> Warren Togami wrote: > Christopher Aillon wrote: >> David Anderson wrote: >>> I'd like to +1 the recent suggestions for a mailing list solely >>> dedicated to spreading necessary information to packagers. >> >> Actually, I thought that was this list. Can we move all the other >> discussion to fedora-devel? >> > > This list is supposed to be for discussions. > > They are asking for a development announcement only list. Let's make this explicitly clear. fedora-announce-list Project level announcements, news mainly for users. http://www.redhat.com/mailman/listinfo/fedora-package-announce fedora-package-announce Subscribe to receive notifications of new/updated packages. fedora-devel-announce Announcements specifically for developers. Stuff like policy, infrastructure or tool changes that would be relevant to developers. VERY INFREQUENT posts that rise above the difficult to follow bulk of the devel/maintainers discussion lists. THIS IS WHAT IS NEEDED. Warren Togami wtogami at redhat.com From peter at thecodergeek.com Wed Jun 6 04:20:23 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 05 Jun 2007 21:20:23 -0700 Subject: JUST DO IT Re: Announcements list for packagers In-Reply-To: <466634FC.7060908@redhat.com> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4665C5BD.7000503@redhat.com> <4666337F.3070105@redhat.com> <466634FC.7060908@redhat.com> Message-ID: <1181103623.8022.0.camel@tuxhugs> On Wed, 2007-06-06 at 00:15 -0400, Warren Togami wrote: > Let's make this explicitly clear. > > fedora-announce-list > Project level announcements, news mainly for users. > > http://www.redhat.com/mailman/listinfo/fedora-package-announce > fedora-package-announce > Subscribe to receive notifications of new/updated packages. > > fedora-devel-announce > Announcements specifically for developers. Stuff like policy, > infrastructure or tool changes that would be relevant to developers. > VERY INFREQUENT posts that rise above the difficult to follow bulk of > the devel/maintainers discussion lists. THIS IS WHAT IS NEEDED. > +1 from me. Thanks, Warren! -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Wed Jun 6 04:48:09 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Jun 2007 23:48:09 -0500 Subject: Summary of the 2007-06-05 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-06-05 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070605 Executive summary: No new guidelines this week. No proposals were voted upon this week due to lack of quorum. Misc business: * OCaml guidelines: http://fedoraproject.org/wiki/PackagingDrafts/OCaml These are nearly done now. - J< From braden at endoframe.com Wed Jun 6 06:25:27 2007 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 06 Jun 2007 02:25:27 -0400 Subject: Broken libcurl.so.3 dependency Message-ID: <1181111127.3270.36.camel@hinge.endoframe.net> I maintain a package that links to libcurl, openvrml-player. A recent curl update changed the library version from libcurl.so.3 to libcurl.so.4. yum installed this update (on Fedora 7) without squawking. Either I've done something wrong in the spec file for openvrml, or... something worse. Can anyone shed some light on this? -- Braden McDaniel e-mail: Jabber: From jsafrane at redhat.com Wed Jun 6 07:08:53 2007 From: jsafrane at redhat.com (Jan Safranek) Date: Wed, 06 Jun 2007 09:08:53 +0200 Subject: Bodhi returns 500 Internal Error when submitting new update In-Reply-To: <20070605222541.GD13318@tomservo.rochester.rr.com> References: <1181031700.3911.30.camel@dhcp-lab-214.brq.redhat.com> <20070605222541.GD13318@tomservo.rochester.rr.com> Message-ID: <1181113733.5055.2.camel@dhcp-lab-214.brq.redhat.com> On Tue, 2007-06-05 at 18:25 -0400, Luke Macken wrote: > On Tue, Jun 05, 2007 at 10:21:40AM +0200, Jan Safranek wrote: > > Greetings, > > > > I would like to update xinetd package in F7. I built it few weeks ago > > [1] during devel. freeze and now I want to publish it. > > > > I log into https://admin.fedoraproject.org/updates/, press 'New update' > > and fill the form: > > > > Package: xinetd-2.3.14-12.fc7 > > Release: Fedora7 > > Type: bugfix > > Bugs: 195265 > > CVEs: > > Notes: > > > > Now, when pressing 'Submit', I get 500 Internal error. > > > > Any ideas what could be wrong? Thanks in advance > > So I think we may have hit a weird SQLObject bug, or something in the > python db libraries. Either way, I reverted back to only storing > people's usernames in the db until we can figure this out. > > Let me know if you have any problems. Now it works for me, my update was pushed to testing. Thanks. Jan From rc040203 at freenet.de Wed Jun 6 07:22:09 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Jun 2007 09:22:09 +0200 Subject: bogus debuginfo*rpms in updates/repodata Message-ID: <1181114529.29024.11.camel@mccallum.corsepiu.local> Hi, I would have bugzilla'ed this, but don't have any idea how to file it in bugzilla (No category for Fedora Infrastructure), therefore ... IMO, there is a bug the way the updates/7//repodata for is being generated: For FC6, we have fedora/linux/core/updates/6/i386/repodata fedora/linux/core/updates/6/i386/debug/repodata with i386/repodata containing non-debuginfo rpms only and i386/debug/repodata containing debuginfo rpms only. For FC7, we have fedora/linux/updates/7/i386/repodata fedora/linux/updates/7/i386/debug/repodata with i386/repodata also containing the *debuginfo*.rpms from debug/*.rpm. This doesn't seem right to me. Looks like there is a "-x '*debuginfo*'" missing in the call to createrepo for /repodata to me. Ralf From fedora at camperquake.de Wed Jun 6 07:21:43 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 6 Jun 2007 09:21:43 +0200 Subject: Broken libcurl.so.3 dependency In-Reply-To: <1181111127.3270.36.camel@hinge.endoframe.net> References: <1181111127.3270.36.camel@hinge.endoframe.net> Message-ID: <20070606092143.644ca79d@banea.int.addix.net> Hi. On Wed, 06 Jun 2007 02:25:27 -0400, Braden McDaniel wrote: > Either I've done something wrong in the spec file for openvrml, or... > something worse. Can anyone shed some light on this? There are some other threads on stuff like this on the devel list. It somehow looks like a depsolver bug in yum, but nothing is confirmed yet. From rc040203 at freenet.de Wed Jun 6 07:29:06 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Jun 2007 09:29:06 +0200 Subject: Disttags are nice, save the disttags In-Reply-To: <645d17210706050305v5de9f0b4yd874842cfa9c362d@mail.gmail.com> References: <1180965652.2883.4.camel@kennedy> <46647161.6070806@redhat.com> <20070604202510.GQ18693@neu.nirvana> <466476BC.90104@redhat.com> <20070604205527.GD2831@free.fr> <46647C92.2000700@redhat.com> <1181029928.27239.43.camel@mccallum.corsepiu.local> <46651FB3.6050000@redhat.com> <20070605091644.GF23972@neu.nirvana> <1181037539.27239.76.camel@mccallum.corsepiu.local> <645d17210706050305v5de9f0b4yd874842cfa9c362d@mail.gmail.com> Message-ID: <1181114946.29024.13.camel@mccallum.corsepiu.local> On Tue, 2007-06-05 at 11:05 +0100, Jonathan Underwood wrote: > On 05/06/07, Ralf Corsepius wrote: > > > > Well, I can only reiterate what I said before: IMO, "full rebuilds" are > > a hoax blending yourself unless they are performed in "sorted order" > > and a PITA to maintainers unless they are performed automatically. > > Aside: presumably CentOS and Scientific Linux etc have solved the full > rebuild in order problem. Perhaps it's worth looking at their > buildsystem. Sounds like being worth a look. URL? Ralf From bkoz at redhat.com Wed Jun 6 07:31:35 2007 From: bkoz at redhat.com (Benjamin Kosnik) Date: Wed, 6 Jun 2007 09:31:35 +0200 Subject: JUST DO IT Re: Announcements list for packagers In-Reply-To: <1181103623.8022.0.camel@tuxhugs> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4665C5BD.7000503@redhat.com> <4666337F.3070105@redhat.com> <466634FC.7060908@redhat.com> <1181103623.8022.0.camel@tuxhugs> Message-ID: <20070606093135.55424205@concorde.artheist.org> > > fedora-devel-announce > > Announcements specifically for developers. Stuff like policy, > > infrastructure or tool changes that would be relevant to > > developers. VERY INFREQUENT posts that rise above the difficult to > > follow bulk of the devel/maintainers discussion lists. THIS IS > > WHAT IS NEEDED. > +1 from me. Thanks, Warren! +2. And please, for everybody's sanity, can you put a nicely written up overview of administrative changes in the development process here? Keeping up with this stuff is exhausting, and the wiki docs are usually far behind reality. Thank goodness that FWN is starting to have a summary of the devel list. -benjamin From jnovy at redhat.com Wed Jun 6 07:41:41 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 06 Jun 2007 09:41:41 +0200 Subject: Broken libcurl.so.3 dependency In-Reply-To: <1181111127.3270.36.camel@hinge.endoframe.net> References: <1181111127.3270.36.camel@hinge.endoframe.net> Message-ID: <1181115703.3214.17.camel@dhcp-lab-186.brq.redhat.com> On Wed, 2007-06-06 at 02:25 -0400, Braden McDaniel wrote: > I maintain a package that links to libcurl, openvrml-player. A recent > curl update changed the library version from libcurl.so.3 to > libcurl.so.4. yum installed this update (on Fedora 7) without squawking. curl-7.16.1 and newer which bumps soname to libcurl.so.4 has been around for a while (since Jan 29 2007) and all of the packages, I was aware of, dependent on libcurl.so.3 were rebuilt prior to F7 release. I haven't released any curl update to F7 yet. > Either I've done something wrong in the spec file for openvrml, or... > something worse. Can anyone shed some light on this? I don't know how openvrml is dependent on libcurl, but just rebuild should help here as the API hasn't been changed much by the upstream. (only some obsolete and compatibility symbols removed) Jindrich -- Jindrich Novy From pertusus at free.fr Wed Jun 6 07:46:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 6 Jun 2007 09:46:56 +0200 Subject: JUST DO IT Re: Announcements list for packagers In-Reply-To: <466634FC.7060908@redhat.com> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4665C5BD.7000503@redhat.com> <4666337F.3070105@redhat.com> <466634FC.7060908@redhat.com> Message-ID: <20070606074656.GC2847@free.fr> On Wed, Jun 06, 2007 at 12:15:56AM -0400, Warren Togami wrote: > > fedora-devel-announce > Announcements specifically for developers. Stuff like policy, > infrastructure or tool changes that would be relevant to developers. > VERY INFREQUENT posts that rise above the difficult to follow bulk of > the devel/maintainers discussion lists. THIS IS WHAT IS NEEDED. I agree with that, and when responding to mail from that list response would go to fedora-devel-list. Also (or alternatively) maybe it could be cross-posted to fedora-devel-list. -- Pat From braden at endoframe.com Wed Jun 6 08:32:04 2007 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 06 Jun 2007 04:32:04 -0400 Subject: Broken libcurl.so.3 dependency In-Reply-To: <1181115703.3214.17.camel@dhcp-lab-186.brq.redhat.com> References: <1181111127.3270.36.camel@hinge.endoframe.net> <1181115703.3214.17.camel@dhcp-lab-186.brq.redhat.com> Message-ID: <1181118724.3270.48.camel@hinge.endoframe.net> On Wed, 2007-06-06 at 09:41 +0200, Jindrich Novy wrote: > On Wed, 2007-06-06 at 02:25 -0400, Braden McDaniel wrote: > > I maintain a package that links to libcurl, openvrml-player. A recent > > curl update changed the library version from libcurl.so.3 to > > libcurl.so.4. yum installed this update (on Fedora 7) without squawking. > > curl-7.16.1 and newer which bumps soname to libcurl.so.4 has been around > for a while (since Jan 29 2007) and all of the packages, I was aware of, > dependent on libcurl.so.3 were rebuilt prior to F7 release. I haven't > released any curl update to F7 yet. openvrml-player-0.16.4-2.fc7--which shows a build date of May 2, 2007--depends on libcurl.so.3. > > Either I've done something wrong in the spec file for openvrml, or... > > something worse. Can anyone shed some light on this? > > I don't know how openvrml is dependent on libcurl, but just rebuild > should help here as the API hasn't been changed much by the upstream. > (only some obsolete and compatibility symbols removed) I know; and a new release of openvrml is in testing. (Any way I can expedite getting this pushed to updates?) The point was, Why is my system in this state? It may be the case that I didn't get libcurl via an update; rather, it got upgraded from the DVD by the Fedora 7 installer. In this sort of situation, I'm not sure what's supposed to happen. -- Braden McDaniel e-mail: Jabber: From nicolas.mailhot at laposte.net Wed Jun 6 08:48:03 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 6 Jun 2007 10:48:03 +0200 (CEST) Subject: Broken libcurl.so.3 dependency In-Reply-To: <1181118724.3270.48.camel@hinge.endoframe.net> References: <1181111127.3270.36.camel@hinge.endoframe.net> <1181115703.3214.17.camel@dhcp-lab-186.brq.redhat.com> <1181118724.3270.48.camel@hinge.endoframe.net> Message-ID: <29601.192.54.193.51.1181119683.squirrel@rousalka.dyndns.org> Le Mer 6 juin 2007 10:32, Braden McDaniel a ?crit : > The point was, Why is my system in this state? IIRC Anaconda has code to ignore third-party packages/dependencies it does not know of during system updates (system update is priorised over rpm db consistency). I wonder if the single-CD spins we've been doing for Fedora 7 do not make anaconda consider anything not in the spin a third-party package. That's why you should be real careful to never push updates in past releases which are not already in fedora-devel/next release update queue (checking upgrade paths and dependencies), especially around release time. That way even if anaconda messes-up next yum run will fix stuff. Also there's been a string of reports pointing to brokeness in yum dependency checking recently. -- Nicolas Mailhot From bugs.michael at gmx.net Wed Jun 6 08:57:38 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Jun 2007 10:57:38 +0200 Subject: Broken libcurl.so.3 dependency In-Reply-To: <1181118724.3270.48.camel@hinge.endoframe.net> References: <1181111127.3270.36.camel@hinge.endoframe.net> <1181115703.3214.17.camel@dhcp-lab-186.brq.redhat.com> <1181118724.3270.48.camel@hinge.endoframe.net> Message-ID: <20070606105738.5b720d56.bugs.michael@gmx.net> On Wed, 06 Jun 2007 04:32:04 -0400, Braden McDaniel wrote: > On Wed, 2007-06-06 at 09:41 +0200, Jindrich Novy wrote: > > On Wed, 2007-06-06 at 02:25 -0400, Braden McDaniel wrote: > > > I maintain a package that links to libcurl, openvrml-player. A recent > > > curl update changed the library version from libcurl.so.3 to > > > libcurl.so.4. yum installed this update (on Fedora 7) without squawking. > > > > curl-7.16.1 and newer which bumps soname to libcurl.so.4 has been around > > for a while (since Jan 29 2007) and all of the packages, I was aware of, > > dependent on libcurl.so.3 were rebuilt prior to F7 release. I haven't > > released any curl update to F7 yet. > > openvrml-player-0.16.4-2.fc7--which shows a build date of May 2, > 2007--depends on libcurl.so.3. It doesn't: http://koji.fedoraproject.org/koji/rpminfo?rpmID=51312 btw, libcurl.so.4 was introduced prior to the FE merge on May 2nd. From tla at rasmil.dk Wed Jun 6 09:00:16 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Wed, 06 Jun 2007 11:00:16 +0200 Subject: bogus debuginfo*rpms in updates/repodata In-Reply-To: <1181114529.29024.11.camel@mccallum.corsepiu.local> References: <1181114529.29024.11.camel@mccallum.corsepiu.local> Message-ID: <466677A0.5040807@rasmil.dk> Ralf Corsepius wrote: > Hi, > > I would have bugzilla'ed this, but don't have any idea how to file it in > bugzilla (No category for Fedora Infrastructure), therefore ... > > Info about infrastructure tickets https://admin.fedoraproject.org/wikifpo/IndexAdmin#head-0961200a51afe7af188e41e30dc656faf8d07ba4 Tim From jonathan.underwood at gmail.com Wed Jun 6 09:09:44 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 6 Jun 2007 10:09:44 +0100 Subject: Unsigned package in repo - how do I get it signed? In-Reply-To: <645d17210706030852j2f788c6cg1d675c219114943e@mail.gmail.com> References: <645d17210706030840s4c381f7fjc77dffa1867afffc@mail.gmail.com> <645d17210706030852j2f788c6cg1d675c219114943e@mail.gmail.com> Message-ID: <645d17210706060209p6b220aa4ibf70c36063270eff@mail.gmail.com> On 03/06/07, Jonathan Underwood wrote: > On 03/06/07, Jonathan Underwood wrote: > > Hi, > > > > One of my packages (sunfidef) appears to have not been signed, but is > > in the repo. See BZ 242348. What's the procedure for getting it > > signed? > > > > Thanks, > > Jonathan > > > > Aha, I see that Jesse Keating is aware of the issue and plans to fix > unsigned packages on Monday (see fedora-devel list). Sorry for the > noise. Hi Jesse - I am still seeing unsigned sunifdef packages - did this get missed off the list? J. From rc040203 at freenet.de Wed Jun 6 10:13:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Jun 2007 12:13:38 +0200 Subject: bogus debuginfo*rpms in updates/repodata In-Reply-To: <466677A0.5040807@rasmil.dk> References: <1181114529.29024.11.camel@mccallum.corsepiu.local> <466677A0.5040807@rasmil.dk> Message-ID: <1181124818.3222.2.camel@mccallum.corsepiu.local> On Wed, 2007-06-06 at 11:00 +0200, Tim Lauridsen wrote: > Ralf Corsepius wrote: > > Hi, > > > > I would have bugzilla'ed this, but don't have any idea how to file it in > > bugzilla (No category for Fedora Infrastructure), therefore ... > > > > > Info about infrastructure tickets > https://admin.fedoraproject.org/wikifpo/IndexAdmin#head-0961200a51afe7af188e41e30dc656faf8d07ba4 Well, I can't get into it. https://admin.fedoraproject.org/tickets simply doesn't respond. Seemingly another unfinished construction site :( Ralf From rc040203 at freenet.de Wed Jun 6 10:27:58 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Jun 2007 12:27:58 +0200 Subject: bogus debuginfo*rpms in updates/repodata In-Reply-To: <1181124818.3222.2.camel@mccallum.corsepiu.local> References: <1181114529.29024.11.camel@mccallum.corsepiu.local> <466677A0.5040807@rasmil.dk> <1181124818.3222.2.camel@mccallum.corsepiu.local> Message-ID: <1181125678.3222.13.camel@mccallum.corsepiu.local> On Wed, 2007-06-06 at 12:13 +0200, Ralf Corsepius wrote: > On Wed, 2007-06-06 at 11:00 +0200, Tim Lauridsen wrote: > > Ralf Corsepius wrote: > > > Hi, > > > > > > I would have bugzilla'ed this, but don't have any idea how to file it in > > > bugzilla (No category for Fedora Infrastructure), therefore ... > > > > > > > > Info about infrastructure tickets > > https://admin.fedoraproject.org/wikifpo/IndexAdmin#head-0961200a51afe7af188e41e30dc656faf8d07ba4 > Well, I can't get into it. > > https://admin.fedoraproject.org/tickets simply doesn't respond. Now I can, ... it's simply doooog slow, ... turn-around/response times in the order of several minutes :( Ralf From jwboyer at jdub.homelinux.org Wed Jun 6 12:55:36 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 06 Jun 2007 07:55:36 -0500 Subject: JUST DO IT Re: Announcements list for packagers In-Reply-To: <466634FC.7060908@redhat.com> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4665C5BD.7000503@redhat.com> <4666337F.3070105@redhat.com> <466634FC.7060908@redhat.com> Message-ID: <1181134536.464.1.camel@zod.rchland.ibm.com> On Wed, 2007-06-06 at 00:15 -0400, Warren Togami wrote: > Warren Togami wrote: > > Christopher Aillon wrote: > >> David Anderson wrote: > >>> I'd like to +1 the recent suggestions for a mailing list solely > >>> dedicated to spreading necessary information to packagers. > >> > >> Actually, I thought that was this list. Can we move all the other > >> discussion to fedora-devel? > >> > > > > This list is supposed to be for discussions. > > > > They are asking for a development announcement only list. > > Let's make this explicitly clear. > > fedora-announce-list > Project level announcements, news mainly for users. > > http://www.redhat.com/mailman/listinfo/fedora-package-announce > fedora-package-announce > Subscribe to receive notifications of new/updated packages. > > fedora-devel-announce > Announcements specifically for developers. Stuff like policy, > infrastructure or tool changes that would be relevant to developers. > VERY INFREQUENT posts that rise above the difficult to follow bulk of > the devel/maintainers discussion lists. THIS IS WHAT IS NEEDED. Make this read-only and have it's Reply-to: set to this list. Then it might work. Otherwise, people will have _more_ discussion on that list for changes they didn't see coming. josh From jima at beer.tclug.org Wed Jun 6 13:31:07 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 6 Jun 2007 08:31:07 -0500 (CDT) Subject: JUST DO IT Re: Announcements list for packagers In-Reply-To: <20070606074656.GC2847@free.fr> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4665C5BD.7000503@redhat.com> <4666337F.3070105@redhat.com> <466634FC.7060908@redhat.com> <20070606074656.GC2847@free.fr> Message-ID: On Wed, 6 Jun 2007, Patrice Dumas wrote: > On Wed, Jun 06, 2007 at 12:15:56AM -0400, Warren Togami wrote: >> fedora-devel-announce >> Announcements specifically for developers. Stuff like policy, >> infrastructure or tool changes that would be relevant to developers. >> VERY INFREQUENT posts that rise above the difficult to follow bulk of >> the devel/maintainers discussion lists. THIS IS WHAT IS NEEDED. > > I agree with that, and when responding to mail from that list response > would go to fedora-devel-list. Also (or alternatively) maybe it could be > cross-posted to fedora-devel-list. Personally, I'd prefer that A) fedora-devel-announce were moderated, and B) the Reply-To for the list were set to fedora-devel-list (if that's possible). That way, ensuing discussion on an announcement doesn't continue to clog up the announcement list. Thoughts? Jima From jkeating at redhat.com Wed Jun 6 14:17:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 10:17:02 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <466603F9.4090703@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <1181089535.7952.7.camel@vader.jdub.homelinux.org> <466603F9.4090703@fedoraproject.org> Message-ID: <200706061017.05863.jkeating@redhat.com> On Tuesday 05 June 2007 20:46:49 Rahul Sundaram wrote: > Problem with that is many testers did not know when the devel repository > moves beyond Fedora 7 into Fedora 8 and ended with a number of broken > FC8 packages. I don't know whether we consider it a problem worth > solving but I have seen it bite a considerably large number of folks > this time. Maybe you're just paying more attention this time. This is not a new problem (nor a problem in many eyes). Using rawhide comes with consequences. I announced when we were changing to pick up new rawhide 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 Wed Jun 6 14:17:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 10:17:37 -0400 Subject: Unsigned package in repo - how do I get it signed? In-Reply-To: <645d17210706060209p6b220aa4ibf70c36063270eff@mail.gmail.com> References: <645d17210706030840s4c381f7fjc77dffa1867afffc@mail.gmail.com> <645d17210706030852j2f788c6cg1d675c219114943e@mail.gmail.com> <645d17210706060209p6b220aa4ibf70c36063270eff@mail.gmail.com> Message-ID: <200706061017.37307.jkeating@redhat.com> On Wednesday 06 June 2007 05:09:44 Jonathan Underwood wrote: > Hi Jesse - I am still seeing unsigned sunifdef packages - did this get > missed off the list? No, I haven't yet synced the signed set. Was going to last night but got sick instead. -- 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 Jun 6 14:20:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 10:20:54 -0400 Subject: bogus debuginfo*rpms in updates/repodata In-Reply-To: <1181114529.29024.11.camel@mccallum.corsepiu.local> References: <1181114529.29024.11.camel@mccallum.corsepiu.local> Message-ID: <200706061020.54329.jkeating@redhat.com> On Wednesday 06 June 2007 03:22:09 Ralf Corsepius wrote: > Looks like there is a "-x '*debuginfo*'" missing in the call to > createrepo for /repodata to me. This should be fixed in the next updates push, which I hope to do relatively soon today. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Wed Jun 6 14:33:51 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 06 Jun 2007 10:33:51 -0400 Subject: Plan for tomorrows (20070607) FESCO meeting Message-ID: <1181140431.2818.6.camel@kennedy> 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 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- rel-eng proposal for Update tool defaults pushing to updates-testing - https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00640.html - f13 /topic FESCO-Meeting -- MISC -- Policy Drafts w/ wiki changes -- f13 /topic FESCO-Meeting -- MISC -- Security Updates needing Security Team approval proposal -- jbressers, jwb /topic FESCo-Meeting -- MISC -- Bugzilla components merger status -- bpepple, poelcat /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-meeting -- Statically link libuu (uulib-static) into klibido -- tibbs -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218599 /topic FESCo meeting -- Free discussion around Fedora 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" 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 jkeating at redhat.com Wed Jun 6 14:37:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 10:37:17 -0400 Subject: Plan for tomorrows (20070607) FESCO meeting In-Reply-To: <1181140431.2818.6.camel@kennedy> References: <1181140431.2818.6.camel@kennedy> Message-ID: <200706061037.17447.jkeating@redhat.com> On Wednesday 06 June 2007 10:33:51 Brian Pepple wrote: > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora" phase. I would like to talk to FESCo about allowing the OLPC project to make use of our infrastructure to work on their migration to a Fedora 7 base. In the past they've used Red Hat's infrastructure to base themselves on Fedora 6, but since the merge they can't do that anymore. They'd need to be able to add/sponsor packagers, olpc specific branches of some packages, some packages that are olpc only, tags within Koji for olpc, and the ability to produce repos of the olpc packages out of koji. John (J5) Palmieri should be able to join the meeting to represent OLPC in this topic. -- 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 katzj at redhat.com Wed Jun 6 14:46:34 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 06 Jun 2007 10:46:34 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706061017.05863.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <1181089535.7952.7.camel@vader.jdub.homelinux.org> <466603F9.4090703@fedoraproject.org> <200706061017.05863.jkeating@redhat.com> Message-ID: <1181141194.8071.18.camel@erebor.boston.redhat.com> On Wed, 2007-06-06 at 10:17 -0400, Jesse Keating wrote: > On Tuesday 05 June 2007 20:46:49 Rahul Sundaram wrote: > > Problem with that is many testers did not know when the devel repository > > moves beyond Fedora 7 into Fedora 8 and ended with a number of broken > > FC8 packages. I don't know whether we consider it a problem worth > > solving but I have seen it bite a considerably large number of folks > > this time. > > Maybe you're just paying more attention this time. This is not a new problem > (nor a problem in many eyes). Using rawhide comes with consequences. I > announced when we were changing to pick up new rawhide packages. At the same time, since we've already said we want to look at how to make test releases (and testing test releases) more streamlined, maybe we can also include this as something to consider. Because people installing test releases don't necessarily expect to be getting onto the rawhide train forever and installing and testing test releases is definitely something we want to encourage. Jeremy From bpepple at fedoraproject.org Wed Jun 6 14:48:00 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 06 Jun 2007 10:48:00 -0400 Subject: Plan for tomorrows (20070607) FESCO meeting In-Reply-To: <200706061037.17447.jkeating@redhat.com> References: <1181140431.2818.6.camel@kennedy> <200706061037.17447.jkeating@redhat.com> Message-ID: <1181141280.2818.7.camel@kennedy> On Wed, 2007-06-06 at 10:37 -0400, Jesse Keating wrote: > On Wednesday 06 June 2007 10:33:51 Brian Pepple wrote: > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora" phase. > > I would like to talk to FESCo about allowing the OLPC project to make use of > our infrastructure to work on their migration to a Fedora 7 base. In the > past they've used Red Hat's infrastructure to base themselves on Fedora 6, > but since the merge they can't do that anymore. They'd need to be able to > add/sponsor packagers, olpc specific branches of some packages, some packages > that are olpc only, tags within Koji for olpc, and the ability to produce > repos of the olpc packages out of koji. John (J5) Palmieri should be able to > join the meeting to represent OLPC in this topic. I'll add it to the schedule. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From braden at endoframe.com Wed Jun 6 14:51:00 2007 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 06 Jun 2007 10:51:00 -0400 Subject: Broken libcurl.so.3 dependency In-Reply-To: <20070606105738.5b720d56.bugs.michael@gmx.net> References: <1181111127.3270.36.camel@hinge.endoframe.net> <1181115703.3214.17.camel@dhcp-lab-186.brq.redhat.com> <1181118724.3270.48.camel@hinge.endoframe.net> <20070606105738.5b720d56.bugs.michael@gmx.net> Message-ID: <1181141460.3270.54.camel@hinge.endoframe.net> On Wed, 2007-06-06 at 10:57 +0200, Michael Schwendt wrote: > On Wed, 06 Jun 2007 04:32:04 -0400, Braden McDaniel wrote: > > > On Wed, 2007-06-06 at 09:41 +0200, Jindrich Novy wrote: > > > On Wed, 2007-06-06 at 02:25 -0400, Braden McDaniel wrote: > > > > I maintain a package that links to libcurl, openvrml-player. A recent > > > > curl update changed the library version from libcurl.so.3 to > > > > libcurl.so.4. yum installed this update (on Fedora 7) without squawking. > > > > > > curl-7.16.1 and newer which bumps soname to libcurl.so.4 has been around > > > for a while (since Jan 29 2007) and all of the packages, I was aware of, > > > dependent on libcurl.so.3 were rebuilt prior to F7 release. I haven't > > > released any curl update to F7 yet. > > > > openvrml-player-0.16.4-2.fc7--which shows a build date of May 2, > > 2007--depends on libcurl.so.3. > > It doesn't: > > http://koji.fedoraproject.org/koji/rpminfo?rpmID=51312 > > btw, libcurl.so.4 was introduced prior to the FE merge on May 2nd. Well, now... color me confused. What's going on here? [braden at hinge ~]$ ldd /usr/bin/openvrml-player | grep libcurl.so.3 [braden at hinge ~]$ ldd /usr/bin/openvrml-player | grep libcurl.so.4 libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x0000003b50a00000) [braden at hinge ~]$ openvrml-player openvrml-player: error while loading shared libraries: libcurl.so.3: cannot open shared object file: No such file or directory -- Braden McDaniel e-mail: Jabber: From dwmw2 at infradead.org Wed Jun 6 14:53:46 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 06 Jun 2007 15:53:46 +0100 Subject: No sound on PowerPC Mac Mini after upgrading from fc6 to Fedora7 In-Reply-To: References: <1181063279.16089.37.camel@hades.cambridge.redhat.com> Message-ID: <1181141626.4096.58.camel@pmac.infradead.org> On Wed, 2007-06-06 at 07:44 +0400, Peter Lemenkov wrote: > It finally works after I added next lines to /etc/rc.local Do you need _all_ of those, or just snd-aoa-i2sbus? Can you undo it so it's as it was before, then (as root) run: udevmonitor --env | grep MODALIAS | tee foo.txt and leave that running while you run 'udevtrigger'. Mail me the resulting foo.txt along with the output of 'modinfo snd-aoa-i2sbus' What happens when if you run 'modprobe of:Ni2sTi2sC' instead of specifying snd-aoa-i2sbus by name? -- dwmw2 From jkeating at redhat.com Wed Jun 6 14:52:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 10:52:16 -0400 Subject: Broken libcurl.so.3 dependency In-Reply-To: <1181141460.3270.54.camel@hinge.endoframe.net> References: <1181111127.3270.36.camel@hinge.endoframe.net> <20070606105738.5b720d56.bugs.michael@gmx.net> <1181141460.3270.54.camel@hinge.endoframe.net> Message-ID: <200706061052.16616.jkeating@redhat.com> On Wednesday 06 June 2007 10:51:00 Braden McDaniel wrote: > Well, now... color me confused. What's going on here? > > ? ? ? ? [braden at hinge ~]$ ldd /usr/bin/openvrml-player | grep libcurl.so.3 > ? ? ? ? [braden at hinge ~]$ ldd /usr/bin/openvrml-player | grep libcurl.so.4 > ? ? ? ? ? ? ? ? libcurl.so.4 => /usr/lib64/libcurl.so.4 > (0x0000003b50a00000) [braden at hinge ~]$ openvrml-player > ? ? ? ? openvrml-player: error while loading shared libraries: > libcurl.so.3: cannot open shared object file: No such file or directory Missing an ldconfig call? -- 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 Jun 6 14:59:25 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 06 Jun 2007 09:59:25 -0500 Subject: Plan for tomorrows (20070607) FESCO meeting In-Reply-To: <200706061037.17447.jkeating@redhat.com> References: <1181140431.2818.6.camel@kennedy> <200706061037.17447.jkeating@redhat.com> Message-ID: <1181141965.464.27.camel@zod.rchland.ibm.com> On Wed, 2007-06-06 at 10:37 -0400, Jesse Keating wrote: > On Wednesday 06 June 2007 10:33:51 Brian Pepple wrote: > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora" phase. > > I would like to talk to FESCo about allowing the OLPC project to make use of > our infrastructure to work on their migration to a Fedora 7 base. In the > past they've used Red Hat's infrastructure to base themselves on Fedora 6, > but since the merge they can't do that anymore. They'd need to be able to > add/sponsor packagers, olpc specific branches of some packages, some packages > that are olpc only, tags within Koji for olpc, and the ability to produce > repos of the olpc packages out of koji. John (J5) Palmieri should be able to > join the meeting to represent OLPC in this topic. Could we treat OLPC as a secondary arch? josh From jkeating at redhat.com Wed Jun 6 15:06:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 11:06:44 -0400 Subject: Plan for tomorrows (20070607) FESCO meeting In-Reply-To: <1181141965.464.27.camel@zod.rchland.ibm.com> References: <1181140431.2818.6.camel@kennedy> <200706061037.17447.jkeating@redhat.com> <1181141965.464.27.camel@zod.rchland.ibm.com> Message-ID: <200706061106.48144.jkeating@redhat.com> On Wednesday 06 June 2007 10:59:25 Josh Boyer wrote: > Could we treat OLPC as a secondary arch? If we had the secondary arch stuff online today, and an SCM that would allow for easy push/pull from upstream/downstream, perhaps. However they have a short runway and are very heavily integrated with us so it is best for now is to treat them almost like EPEL, but even closer. -- 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 Jun 6 15:08:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 11:08:47 -0400 Subject: JUST DO IT Re: Announcements list for packagers In-Reply-To: <466634FC.7060908@redhat.com> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4666337F.3070105@redhat.com> <466634FC.7060908@redhat.com> Message-ID: <200706061108.47895.jkeating@redhat.com> On Wednesday 06 June 2007 00:15:56 Warren Togami wrote: > Let's make this explicitly clear. > fedora-devel-announce > Announcements specifically for developers. ?Stuff like policy, > infrastructure or tool changes that would be relevant to developers. > VERY INFREQUENT posts that rise above the difficult to follow bulk of > the devel/maintainers discussion lists. ?THIS IS WHAT IS NEEDED. Make postings that go to fedora-devel-announce also go to fedora-devel or fedora-maintainers. That way you don't have to have people subscribe to Yet Another List, and we capture all the people on these lists already. -- 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 j.w.r.degoede at hhs.nl Wed Jun 6 15:10:01 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 06 Jun 2007 17:10:01 +0200 Subject: Plan for tomorrows (20070607) FESCO meeting In-Reply-To: <1181140431.2818.6.camel@kennedy> References: <1181140431.2818.6.camel@kennedy> Message-ID: <4666CE49.3000309@hhs.nl> 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 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCO-Meeting -- MISC -- rel-eng proposal for Update tool > defaults pushing to updates-testing - > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00640.html - f13 > I somehow missed the original post which the link above points to, after reading it I must say that I'm very, very, happy with the proposal as presented by rel-eng. After all my negative feedback lately I felt obligated to also say something positive about this, well done rel-eng! Also please don't take all my negative remarks as meaning that I don't like any of the chances, as said before over all I think the merge is great and all the hard work done to make this happen is much appreciated! Regards, Hans From braden at endoframe.com Wed Jun 6 15:32:27 2007 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 06 Jun 2007 11:32:27 -0400 Subject: Broken libcurl.so.3 dependency In-Reply-To: <200706061052.16616.jkeating@redhat.com> References: <1181111127.3270.36.camel@hinge.endoframe.net> <20070606105738.5b720d56.bugs.michael@gmx.net> <1181141460.3270.54.camel@hinge.endoframe.net> <200706061052.16616.jkeating@redhat.com> Message-ID: <1181143947.3270.57.camel@hinge.endoframe.net> On Wed, 2007-06-06 at 10:52 -0400, Jesse Keating wrote: > On Wednesday 06 June 2007 10:51:00 Braden McDaniel wrote: > > Well, now... color me confused. What's going on here? > > > > [braden at hinge ~]$ ldd /usr/bin/openvrml-player | grep libcurl.so.3 > > [braden at hinge ~]$ ldd /usr/bin/openvrml-player | grep libcurl.so.4 > > libcurl.so.4 => /usr/lib64/libcurl.so.4 > > (0x0000003b50a00000) [braden at hinge ~]$ openvrml-player > > openvrml-player: error while loading shared libraries: > > libcurl.so.3: cannot open shared object file: No such file or directory > > Missing an ldconfig call? Missing from where? openvrml-player doesn't have one; should it? If I just run ldconfig manually, it doesn't seem to affect this. -- Braden McDaniel e-mail: Jabber: From katzj at redhat.com Wed Jun 6 15:38:01 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 06 Jun 2007 11:38:01 -0400 Subject: Broken libcurl.so.3 dependency In-Reply-To: <1181141460.3270.54.camel@hinge.endoframe.net> References: <1181111127.3270.36.camel@hinge.endoframe.net> <1181115703.3214.17.camel@dhcp-lab-186.brq.redhat.com> <1181118724.3270.48.camel@hinge.endoframe.net> <20070606105738.5b720d56.bugs.michael@gmx.net> <1181141460.3270.54.camel@hinge.endoframe.net> Message-ID: <1181144281.8071.44.camel@erebor.boston.redhat.com> On Wed, 2007-06-06 at 10:51 -0400, Braden McDaniel wrote: > On Wed, 2007-06-06 at 10:57 +0200, Michael Schwendt wrote: > > On Wed, 06 Jun 2007 04:32:04 -0400, Braden McDaniel wrote: > > > > > On Wed, 2007-06-06 at 09:41 +0200, Jindrich Novy wrote: > > > > On Wed, 2007-06-06 at 02:25 -0400, Braden McDaniel wrote: > > > > > I maintain a package that links to libcurl, openvrml-player. A recent > > > > > curl update changed the library version from libcurl.so.3 to > > > > > libcurl.so.4. yum installed this update (on Fedora 7) without squawking. > > > > > > > > curl-7.16.1 and newer which bumps soname to libcurl.so.4 has been around > > > > for a while (since Jan 29 2007) and all of the packages, I was aware of, > > > > dependent on libcurl.so.3 were rebuilt prior to F7 release. I haven't > > > > released any curl update to F7 yet. > > > > > > openvrml-player-0.16.4-2.fc7--which shows a build date of May 2, > > > 2007--depends on libcurl.so.3. > > > > It doesn't: > > > > http://koji.fedoraproject.org/koji/rpminfo?rpmID=51312 > > > > btw, libcurl.so.4 was introduced prior to the FE merge on May 2nd. > > Well, now... color me confused. What's going on here? > > [braden at hinge ~]$ ldd /usr/bin/openvrml-player | grep libcurl.so.3 > [braden at hinge ~]$ ldd /usr/bin/openvrml-player | grep libcurl.so.4 > libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x0000003b50a00000) > [braden at hinge ~]$ openvrml-player > openvrml-player: error while loading shared libraries: libcurl.so.3: cannot open shared object file: No such file or directory I suspect you have another copy of openvrml-player in your $PATH... try running which openvrml-player Jeremy From bugs.michael at gmx.net Wed Jun 6 15:42:28 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 6 Jun 2007 17:42:28 +0200 Subject: Broken libcurl.so.3 dependency In-Reply-To: <1181141460.3270.54.camel@hinge.endoframe.net> References: <1181111127.3270.36.camel@hinge.endoframe.net> <1181115703.3214.17.camel@dhcp-lab-186.brq.redhat.com> <1181118724.3270.48.camel@hinge.endoframe.net> <20070606105738.5b720d56.bugs.michael@gmx.net> <1181141460.3270.54.camel@hinge.endoframe.net> Message-ID: <20070606174228.6ab45f1b.bugs.michael@gmx.net> On Wed, 06 Jun 2007 10:51:00 -0400, Braden McDaniel wrote: > On Wed, 2007-06-06 at 10:57 +0200, Michael Schwendt wrote: > > On Wed, 06 Jun 2007 04:32:04 -0400, Braden McDaniel wrote: > > > > > On Wed, 2007-06-06 at 09:41 +0200, Jindrich Novy wrote: > > > > On Wed, 2007-06-06 at 02:25 -0400, Braden McDaniel wrote: > > > > > I maintain a package that links to libcurl, openvrml-player. A recent > > > > > curl update changed the library version from libcurl.so.3 to > > > > > libcurl.so.4. yum installed this update (on Fedora 7) without squawking. > > > > > > > > curl-7.16.1 and newer which bumps soname to libcurl.so.4 has been around > > > > for a while (since Jan 29 2007) and all of the packages, I was aware of, > > > > dependent on libcurl.so.3 were rebuilt prior to F7 release. I haven't > > > > released any curl update to F7 yet. > > > > > > openvrml-player-0.16.4-2.fc7--which shows a build date of May 2, > > > 2007--depends on libcurl.so.3. > > > > It doesn't: > > > > http://koji.fedoraproject.org/koji/rpminfo?rpmID=51312 > > > > btw, libcurl.so.4 was introduced prior to the FE merge on May 2nd. > > Well, now... color me confused. What's going on here? > > [braden at hinge ~]$ ldd /usr/bin/openvrml-player | grep libcurl.so.3 > [braden at hinge ~]$ ldd /usr/bin/openvrml-player | grep libcurl.so.4 > libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x0000003b50a00000) > [braden at hinge ~]$ openvrml-player > openvrml-player: error while loading shared libraries: libcurl.so.3: cannot open shared object file: No such file or directory > Does "which openvrml-player" return /usr/bin/openvrml-player? And what does "ll /usr/lib64/libcurl*" give? From caillon at redhat.com Wed Jun 6 15:45:22 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 06 Jun 2007 11:45:22 -0400 Subject: JUST DO IT Re: Announcements list for packagers In-Reply-To: <1181134536.464.1.camel@zod.rchland.ibm.com> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4665C5BD.7000503@redhat.com> <4666337F.3070105@redhat.com> <466634FC.7060908@redhat.com> <1181134536.464.1.camel@zod.rchland.ibm.com> Message-ID: <4666D692.7000001@redhat.com> Josh Boyer wrote: > Make this read-only and have it's Reply-to: set to this list. Then it > might work. Also subscribe this list to that list so we get the original posts, too. From rdieter at math.unl.edu Wed Jun 6 15:56:05 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Jun 2007 10:56:05 -0500 Subject: libmpcdec-1.2.6, soname++ Message-ID: <4666D915.7040306@math.unl.edu> FYI, just pushed libmpcdec-1.2.6 to rawhide, which includes a soname bump. libmpcdec-consuming apps will need to be rebuilt. According to repoquery this includes: audacious-plugins libtunepimp (me) xine-lib xmms-musepack + a handful of unmentionable packages from that other repo. -- Rex From braden at endoframe.com Wed Jun 6 15:56:51 2007 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 06 Jun 2007 11:56:51 -0400 Subject: Broken libcurl.so.3 dependency In-Reply-To: <20070606174228.6ab45f1b.bugs.michael@gmx.net> References: <1181111127.3270.36.camel@hinge.endoframe.net> <1181115703.3214.17.camel@dhcp-lab-186.brq.redhat.com> <1181118724.3270.48.camel@hinge.endoframe.net> <20070606105738.5b720d56.bugs.michael@gmx.net> <1181141460.3270.54.camel@hinge.endoframe.net> <20070606174228.6ab45f1b.bugs.michael@gmx.net> Message-ID: <1181145411.3270.59.camel@hinge.endoframe.net> On Wed, 2007-06-06 at 17:42 +0200, Michael Schwendt wrote: [snip] > Does "which openvrml-player" return /usr/bin/openvrml-player? Ugh. Of course not. I'm a damn moron. Sorry for wasting time. -- Braden McDaniel e-mail: Jabber: From ville.skytta at iki.fi Wed Jun 6 16:12:45 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 6 Jun 2007 19:12:45 +0300 Subject: owners.epel.list problem Message-ID: <200706061912.45723.ville.skytta@iki.fi> owners.epel.list appears broken, I see this on commits: Traceback (most recent call last): File "/cvs/pkgs/CVSROOT/getnotifylist", line 26, in ? owners = owners.OwnerList(populate_all = 0) File "/cvs/pkgs/CVSROOT/owners.py", line 51, in __init__ self.populate_owners() File "/cvs/pkgs/CVSROOT/owners.py", line 125, in populate_owners parse_file(self.owners_epel_list) File "/cvs/pkgs/CVSROOT/owners.py", line 106, in parse_file (product, component, desc, owner, qa, cclist) = l.split("|") ValueError: unpack list of wrong size grep -v '[^|]*|[^|]*|[^|]*|[^|]*|[^|]*' owners.epel.list Maybe it's the empty line after perl-GDTextUtil? From sundaram at fedoraproject.org Wed Jun 6 16:16:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 Jun 2007 21:46:06 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706061017.05863.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <1181089535.7952.7.camel@vader.jdub.homelinux.org> <466603F9.4090703@fedoraproject.org> <200706061017.05863.jkeating@redhat.com> Message-ID: <4666DDC6.4070802@fedoraproject.org> Jesse Keating wrote: > On Tuesday 05 June 2007 20:46:49 Rahul Sundaram wrote: >> Problem with that is many testers did not know when the devel repository >> moves beyond Fedora 7 into Fedora 8 and ended with a number of broken >> FC8 packages. I don't know whether we consider it a problem worth >> solving but I have seen it bite a considerably large number of folks >> this time. > > Maybe you're just paying more attention this time. This is not a new problem > (nor a problem in many eyes). Using rawhide comes with consequences. I > announced when we were changing to pick up new rawhide packages. It's not about *me*. It is about other testers. You should atleast consider what I am proposing if you want more testers. Rahul From jkeating at redhat.com Wed Jun 6 16:32:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 12:32:02 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4666DDC6.4070802@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <200706061017.05863.jkeating@redhat.com> <4666DDC6.4070802@fedoraproject.org> Message-ID: <200706061232.03047.jkeating@redhat.com> On Wednesday 06 June 2007 12:16:06 Rahul Sundaram wrote: > It's not about *me*. It is about other testers. You should atleast > consider what I am proposing if you want more testers. I am considering better ways to handle the handoff. I'm not considering allowing fedora-release to stomp on locally configured repo files. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Jun 6 16:41:19 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 06 Jun 2007 22:11:19 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706061232.03047.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706061017.05863.jkeating@redhat.com> <4666DDC6.4070802@fedoraproject.org> <200706061232.03047.jkeating@redhat.com> Message-ID: <4666E3AF.5000302@fedoraproject.org> Jesse Keating wrote: > On Wednesday 06 June 2007 12:16:06 Rahul Sundaram wrote: >> It's not about *me*. It is about other testers. You should atleast >> consider what I am proposing if you want more testers. > > I am considering better ways to handle the handoff. I'm not considering > allowing fedora-release to stomp on locally configured repo files. Note that we aren't talking about custom repositories or anything like that. User switches on fedora-devel repo and runs yum update. Just before a new release a new fedora-release gets pushed that turns off the devel repo and points to the stable branch. The rule about not changing user configuration is all about preventing surprises to end users. I would argue that not doing what I just described is much more surprising to many testers. Rahul From jkeating at redhat.com Wed Jun 6 16:42:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 12:42:27 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4666E3AF.5000302@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <200706061232.03047.jkeating@redhat.com> <4666E3AF.5000302@fedoraproject.org> Message-ID: <200706061242.27832.jkeating@redhat.com> On Wednesday 06 June 2007 12:41:19 Rahul Sundaram wrote: > Note that we aren't talking about custom repositories or anything like > that. User switches on fedora-devel repo and runs yum update. Just > before a new release a new fedora-release gets pushed that turns off the > devel repo and points to the stable branch. > > The rule about not changing user configuration is all about preventing > surprises to end users. I would argue that not doing what I just > described is much more surprising to many testers. People change the repo files for many reasons, like pointing to their own local mirror. If we release a package that stomps on those changes that's really crappy of us. Not something that I am willing to consider. Period. -- 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 Jun 6 16:41:08 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 06 Jun 2007 11:41:08 -0500 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <4666E3AF.5000302@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <200706061017.05863.jkeating@redhat.com> <4666DDC6.4070802@fedoraproject.org> <200706061232.03047.jkeating@redhat.com> <4666E3AF.5000302@fedoraproject.org> Message-ID: <1181148068.464.33.camel@zod.rchland.ibm.com> On Wed, 2007-06-06 at 22:11 +0530, Rahul Sundaram wrote: > Jesse Keating wrote: > > On Wednesday 06 June 2007 12:16:06 Rahul Sundaram wrote: > >> It's not about *me*. It is about other testers. You should atleast > >> consider what I am proposing if you want more testers. > > > > I am considering better ways to handle the handoff. I'm not considering > > allowing fedora-release to stomp on locally configured repo files. > > Note that we aren't talking about custom repositories or anything like > that. User switches on fedora-devel repo and runs yum update. Just > before a new release a new fedora-release gets pushed that turns off the > devel repo and points to the stable branch. > > The rule about not changing user configuration is all about preventing > surprises to end users. I would argue that not doing what I just > described is much more surprising to many testers. And I would argue that it doesn't matter because both sides are speculation. We should look at ways to do this other than pissing off one group or the other. josh From tibbs at math.uh.edu Wed Jun 6 17:17:12 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jun 2007 12:17:12 -0500 Subject: owners.epel.list problem In-Reply-To: <200706061912.45723.ville.skytta@iki.fi> References: <200706061912.45723.ville.skytta@iki.fi> Message-ID: >>>>> "VS" == Ville Skytt? writes: VS> Maybe it's the empty line after perl-GDTextUtil? It was; I fixed this up when I saw it. - J< From wtogami at redhat.com Wed Jun 6 18:02:18 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 06 Jun 2007 14:02:18 -0400 Subject: RFC: fedora-devel-announce Message-ID: <4666F6AA.6090209@redhat.com> Request for Comments before we do this. Purpose ======= This list is intended to be an INFREQUENTLY used announce-only list. Whenever there is something important that developers should know about, those subscribed to this list should be able to easily follow changes within the development project. Posts are moderated by . Acceptable Types of Announcements ================================= - Policy or process changes that affect developers. - Infrastructure changes that affect developers. - Tools changes that affect developers. - Schedule changes - Freeze reminders Unacceptable Types of Announcements =================================== - Periodic automated reports (violates the INFREQUENT rule) - Discussion - Anything else not mentioned above Setup Details ============= - fedora-devel-announce seems like a better name than fedora-maintainers-announce. - fedora-devel-announce posts to fedora-devel-list. - Reply-To: fedora-devel-list Subscription ============ - Auto-subscribe by default upon NEW sponsorships to cvsextras. - Anybody else may subscribe manually. - Anybody may remove themselves, nobody is required to be subscribed. Any questions or comments? Warren Togami wtogami at redhat.com From jkeating at redhat.com Wed Jun 6 18:05:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 14:05:42 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <4666F6AA.6090209@redhat.com> References: <4666F6AA.6090209@redhat.com> Message-ID: <200706061405.42275.jkeating@redhat.com> On Wednesday 06 June 2007 14:02:18 Warren Togami wrote: > Request for Comments before we do this. > > Purpose > ======= > This list is intended to be an INFREQUENTLY used announce-only list. > Whenever there is something important that developers should know about, > those subscribed to this list should be able to easily follow changes > within the development project. > > Posts are moderated by . > > Acceptable Types of Announcements > ================================= > - Policy or process changes that affect developers. > - Infrastructure changes that affect developers. > - Tools changes that affect developers. > - Schedule changes > - Freeze reminders > > Unacceptable Types of Announcements > =================================== > - Periodic automated reports (violates the INFREQUENT rule) > - Discussion > - Anything else not mentioned above > > Setup Details > ============= > - fedora-devel-announce seems like a better name than > fedora-maintainers-announce. > - fedora-devel-announce posts to fedora-devel-list. > - Reply-To: fedora-devel-list > > Subscription > ============ > - Auto-subscribe by default upon NEW sponsorships to cvsextras. > - Anybody else may subscribe manually. > - Anybody may remove themselves, nobody is required to be subscribed. > > Any questions or comments? > *shrug* I'll give this a +1. Although if discussion goes to 'fedora-devel' one wonders what the usefulness of fedora-maintainers will start to be? -- 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 katzj at redhat.com Wed Jun 6 18:12:05 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 06 Jun 2007 14:12:05 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <4666F6AA.6090209@redhat.com> References: <4666F6AA.6090209@redhat.com> Message-ID: <1181153525.8071.86.camel@erebor.boston.redhat.com> On Wed, 2007-06-06 at 14:02 -0400, Warren Togami wrote: > Request for Comments before we do this. > > Purpose > ======= > This list is intended to be an INFREQUENTLY used announce-only list. > Whenever there is something important that developers should know about, > those subscribed to this list should be able to easily follow changes > within the development project. > > Posts are moderated by . If we do this, we should kill fedora-maintainers. Since the above was the original intent of -maintainers and why it was separated off from fedora-devel-list. Jeremy From clumens at redhat.com Wed Jun 6 18:15:51 2007 From: clumens at redhat.com (Chris Lumens) Date: Wed, 6 Jun 2007 14:15:51 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <1181153525.8071.86.camel@erebor.boston.redhat.com> References: <4666F6AA.6090209@redhat.com> <1181153525.8071.86.camel@erebor.boston.redhat.com> Message-ID: <20070606181551.GG32403@exeter.boston.redhat.com> > > Purpose > > ======= > > This list is intended to be an INFREQUENTLY used announce-only list. > > Whenever there is something important that developers should know about, > > those subscribed to this list should be able to easily follow changes > > within the development project. > > > > Posts are moderated by . > > If we do this, we should kill fedora-maintainers. Since the above was > the original intent of -maintainers and why it was separated off from > fedora-devel-list. Agreed - I've never seen much of a difference between fedora-devel and fedora-maintainers. One less list to follow for devel discussions would be nice. Also agree with the purpose of this new list. I like the idea of having a very low-traffic list with these important policy changes and notices posted. As everyone else has said, fedora-maintainers is just too noisy for these sorts of things and my puny human brain loses the important things in all the less-important things. Bring on change! - Chris From blizzard at redhat.com Wed Jun 6 18:18:15 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 06 Jun 2007 14:18:15 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <200706061405.42275.jkeating@redhat.com> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> Message-ID: <1181153895.22157.62.camel@localhost.localdomain> On Wed, 2007-06-06 at 14:05 -0400, Jesse Keating wrote: > > > *shrug* I'll give this a +1. Although if discussion goes to > 'fedora-devel' > one wonders what the usefulness of fedora-maintainers will start to > be? > Yeah, I don't get this. fedora-maintainers is pretty useful - high signal, low crap. The proper reaction to things like this is almost never _another_ mailing list. --Chris From bpepple at fedoraproject.org Wed Jun 6 18:18:38 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 06 Jun 2007 14:18:38 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <200706061405.42275.jkeating@redhat.com> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> Message-ID: <1181153918.2818.14.camel@kennedy> On Wed, 2007-06-06 at 14:05 -0400, Jesse Keating wrote: > On Wednesday 06 June 2007 14:02:18 Warren Togami wrote: > > Request for Comments before we do this. > > > > Purpose > > ======= > > This list is intended to be an INFREQUENTLY used announce-only list. > > Whenever there is something important that developers should know about, > > those subscribed to this list should be able to easily follow changes > > within the development project. > > > > Posts are moderated by . > > > > Acceptable Types of Announcements > > ================================= > > - Policy or process changes that affect developers. > > - Infrastructure changes that affect developers. > > - Tools changes that affect developers. > > - Schedule changes > > - Freeze reminders > > > > Unacceptable Types of Announcements > > =================================== > > - Periodic automated reports (violates the INFREQUENT rule) > > - Discussion > > - Anything else not mentioned above > > > > Setup Details > > ============= > > - fedora-devel-announce seems like a better name than > > fedora-maintainers-announce. > > - fedora-devel-announce posts to fedora-devel-list. > > - Reply-To: fedora-devel-list > > > > Subscription > > ============ > > - Auto-subscribe by default upon NEW sponsorships to cvsextras. > > - Anybody else may subscribe manually. > > - Anybody may remove themselves, nobody is required to be subscribed. > > > > Any questions or comments? > > > > *shrug* I'll give this a +1. Although if discussion goes to 'fedora-devel' > one wonders what the usefulness of fedora-maintainers will start to be? Maybe we should consider applying these rules to the current maintainers list, instead of creating a new list. /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 ajackson at redhat.com Wed Jun 6 18:17:37 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 06 Jun 2007 14:17:37 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <1181153525.8071.86.camel@erebor.boston.redhat.com> References: <4666F6AA.6090209@redhat.com> <1181153525.8071.86.camel@erebor.boston.redhat.com> Message-ID: <1181153857.30663.3.camel@localhost.localdomain> On Wed, 2007-06-06 at 14:12 -0400, Jeremy Katz wrote: > On Wed, 2007-06-06 at 14:02 -0400, Warren Togami wrote: > > Request for Comments before we do this. > > > > Purpose > > ======= > > This list is intended to be an INFREQUENTLY used announce-only list. > > Whenever there is something important that developers should know about, > > those subscribed to this list should be able to easily follow changes > > within the development project. > > > > Posts are moderated by . > > If we do this, we should kill fedora-maintainers. Since the above was > the original intent of -maintainers and why it was separated off from > fedora-devel-list. What he said. Not another list, please. - ajax From lmacken at redhat.com Wed Jun 6 18:45:39 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 6 Jun 2007 14:45:39 -0400 Subject: Fedora 7 Update Informatin for general users In-Reply-To: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> References: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> Message-ID: <20070606184539.GA10574@tomservo.rochester.rr.com> On Sat, Jun 02, 2007 at 11:28:00PM -0700, Thomas Chung wrote: > First all, thank you for Fedora Update System. > It's wonderful to see that we finally have something we always wanted. > > While looking at the list of Stable Updates for Fedora 7[1], it gives > me an idea that this could replace our static Fedora Security > Advisories and Package Updates for Fedora 7[1] on our project wiki. > > What do you think? Could we open this system up so any general users > can see this information anonymously without logging-in with Fedora > Account System? I think this is a great idea. I opened a new ticket[0] to try and get this done fairly soon. I'm in the process of revamping bodhi's database schema a little bit, so after that I'll work on getting RSS feeds[1] working and throw up a public site. > Perhaps, we could create a new page specifically for anonymous users > without comments field? We could, although getting comments from the average user regarding test updates may be useful, or even provide a simple form that allows people to easily file bugs against that component. luke [0]: https://hosted.fedoraproject.org/projects/bodhi/ticket/43 [1]: https://hosted.fedoraproject.org/projects/bodhi/ticket/12 From mmcgrath at redhat.com Wed Jun 6 18:46:43 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 06 Jun 2007 13:46:43 -0500 Subject: Outage Notification - 2007-06-07 04:00 [UTC] Message-ID: <46670113.1020102@redhat.com> There will be an outage starting at 2007-06-07 04:00 [UTC], which will last approximately 30 minutes. To convert UTC to your local time, use: http://www.timeanddate.com/worldclock/converter.html Affected Services: Buildsystem Unaffected Services: Websites CVS / Source Control Database DNS Mail Torrent Reason for Outage: Upgrading Koji Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. From pertusus at free.fr Wed Jun 6 18:44:35 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 6 Jun 2007 20:44:35 +0200 Subject: RFC: fedora-devel-announce In-Reply-To: <4666F6AA.6090209@redhat.com> References: <4666F6AA.6090209@redhat.com> Message-ID: <20070606184434.GA3154@free.fr> On Wed, Jun 06, 2007 at 02:02:18PM -0400, Warren Togami wrote: > Request for Comments before we do this. > > Purpose > ======= > This list is intended to be an INFREQUENTLY used announce-only list. > Whenever there is something important that developers should know about, > those subscribed to this list should be able to easily follow changes > within the development project. > > Posts are moderated by . > > Acceptable Types of Announcements > ================================= > - Policy or process changes that affect developers. > - Infrastructure changes that affect developers. > - Tools changes that affect developers. > - Schedule changes > - Freeze reminders Should we announce orphans and call for co-maintainers there too? (and similar stuff I don't have immediatly in my head). -- Pat From wtogami at redhat.com Wed Jun 6 19:00:10 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 06 Jun 2007 15:00:10 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <20070606184434.GA3154@free.fr> References: <4666F6AA.6090209@redhat.com> <20070606184434.GA3154@free.fr> Message-ID: <4667043A.2030907@redhat.com> Patrice Dumas wrote: > On Wed, Jun 06, 2007 at 02:02:18PM -0400, Warren Togami wrote: >> Request for Comments before we do this. >> >> Purpose >> ======= >> This list is intended to be an INFREQUENTLY used announce-only list. >> Whenever there is something important that developers should know about, >> those subscribed to this list should be able to easily follow changes >> within the development project. >> >> Posts are moderated by . >> >> Acceptable Types of Announcements >> ================================= >> - Policy or process changes that affect developers. >> - Infrastructure changes that affect developers. >> - Tools changes that affect developers. >> - Schedule changes >> - Freeze reminders > > Should we announce orphans and call for co-maintainers there too? > (and similar stuff I don't have immediatly in my head). > I suppose, but not often. Warren From caillon at redhat.com Wed Jun 6 19:01:20 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 06 Jun 2007 15:01:20 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <1181153525.8071.86.camel@erebor.boston.redhat.com> References: <4666F6AA.6090209@redhat.com> <1181153525.8071.86.camel@erebor.boston.redhat.com> Message-ID: <46670480.5010004@redhat.com> Jeremy Katz wrote: > On Wed, 2007-06-06 at 14:02 -0400, Warren Togami wrote: >> Request for Comments before we do this. >> >> Purpose >> ======= >> This list is intended to be an INFREQUENTLY used announce-only list. >> Whenever there is something important that developers should know about, >> those subscribed to this list should be able to easily follow changes >> within the development project. >> >> Posts are moderated by . > > If we do this, we should kill fedora-maintainers. Since the above was > the original intent of -maintainers and why it was separated off from > fedora-devel-list. Why can't we just move our discussions to -devel? From wtogami at redhat.com Wed Jun 6 19:04:45 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 06 Jun 2007 15:04:45 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <1181153895.22157.62.camel@localhost.localdomain> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> Message-ID: <4667054D.4040900@redhat.com> Christopher Blizzard wrote: > On Wed, 2007-06-06 at 14:05 -0400, Jesse Keating wrote: >> >> *shrug* I'll give this a +1. Although if discussion goes to >> 'fedora-devel' >> one wonders what the usefulness of fedora-maintainers will start to >> be? >> > > Yeah, I don't get this. fedora-maintainers is pretty useful - high > signal, low crap. The proper reaction to things like this is almost > never _another_ mailing list. > It is pretty useful if you have the time to follow all the posts and read everything. It is wrong-minded however to expect everyone with lesser commitments to be able to read and follow everything on a busy discussion list. For them, they could opt to follow minimally fedora-devel-announce. I'm half-decided on if fedora-devel-announce then kill fedora-maintainers. fedora-maintainers has the benefit of having a significantly better signal to noise ratio than fedora-devel-list. There is however a detriment to the redundancy. If folks were willing to be more MILITANT AND CONSISTENT in enforcing the "devel only" rules for fedora-devel-list I might be happier about killing fedora-maintainers. But consistent enforcement has proven to be impossible to maintain in the past. We should talk about this issues in tomorrow's FESCO meeting. Warren Togami wtogami at redhat.com From pertusus at free.fr Wed Jun 6 19:17:39 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 6 Jun 2007 21:17:39 +0200 Subject: RFC: fedora-devel-announce In-Reply-To: <4667054D.4040900@redhat.com> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> Message-ID: <20070606191739.GA2869@free.fr> On Wed, Jun 06, 2007 at 03:04:45PM -0400, Warren Togami wrote: > > If folks were willing to be more MILITANT AND CONSISTENT in enforcing > the "devel only" rules for fedora-devel-list I might be happier about > killing fedora-maintainers. But consistent enforcement has proven to be > impossible to maintain in the past. Isn't it the case? I don't see many wrong posts here. -- Pat From wtogami at redhat.com Wed Jun 6 19:25:06 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 06 Jun 2007 15:25:06 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <20070606191739.GA2869@free.fr> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <20070606191739.GA2869@free.fr> Message-ID: <46670A12.9080101@redhat.com> Patrice Dumas wrote: > On Wed, Jun 06, 2007 at 03:04:45PM -0400, Warren Togami wrote: >> If folks were willing to be more MILITANT AND CONSISTENT in enforcing >> the "devel only" rules for fedora-devel-list I might be happier about >> killing fedora-maintainers. But consistent enforcement has proven to be >> impossible to maintain in the past. > > Isn't it the case? I don't see many wrong posts here. > by "here" do you mean fedora-maintainers? If so, the signal to noise ratio here is good, because we are selective about who we allow on this list. Warren From pertusus at free.fr Wed Jun 6 19:26:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 6 Jun 2007 21:26:56 +0200 Subject: RFC: fedora-devel-announce In-Reply-To: <46670A12.9080101@redhat.com> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <20070606191739.GA2869@free.fr> <46670A12.9080101@redhat.com> Message-ID: <20070606192656.GB2869@free.fr> On Wed, Jun 06, 2007 at 03:25:06PM -0400, Warren Togami wrote: > Patrice Dumas wrote: > >On Wed, Jun 06, 2007 at 03:04:45PM -0400, Warren Togami wrote: > >>If folks were willing to be more MILITANT AND CONSISTENT in enforcing > >>the "devel only" rules for fedora-devel-list I might be happier about > >>killing fedora-maintainers. But consistent enforcement has proven to be > >>impossible to maintain in the past. > > > >Isn't it the case? I don't see many wrong posts here. > > > > by "here" do you mean fedora-maintainers? > > If so, the signal to noise ratio here is good, because we are selective > about who we allow on this list. No, I am speaking about fedora-devel. I don't see a lot of noise, most posts are development related. -- Pat From Axel.Thimm at ATrpms.net Wed Jun 6 19:53:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Jun 2007 21:53:27 +0200 Subject: RFC: fedora-devel-announce In-Reply-To: <1181153525.8071.86.camel@erebor.boston.redhat.com> References: <4666F6AA.6090209@redhat.com> <1181153525.8071.86.camel@erebor.boston.redhat.com> Message-ID: <20070606195327.GD30757@neu.nirvana> On Wed, Jun 06, 2007 at 02:12:05PM -0400, Jeremy Katz wrote: > On Wed, 2007-06-06 at 14:02 -0400, Warren Togami wrote: > > Request for Comments before we do this. > > > > Purpose > > ======= > > This list is intended to be an INFREQUENTLY used announce-only list. > > Whenever there is something important that developers should know about, > > those subscribed to this list should be able to easily follow changes > > within the development project. > > > > Posts are moderated by . > > If we do this, we should kill fedora-maintainers. Since the above was > the original intent of -maintainers and why it was separated off from > fedora-devel-list. My feeling on the development of -devel and -maintainers is the latter focuses more on the packaging/distribution/infrastructure side of things. Sure we have dedicated lists for some of these, but tangetial questions do come up here rather than on the dedicated lists (and it's understandable, subscribing to fedora-infrastruture to query something trivial about say the updates system seems like unneeded overhead). I wouldn't like to see both list "merge" as regardless of SNR the volume will be just to high. I'm subscribed to both, but fedora-devel is too much to handle. So maybe redefining the purposes of these lists is better than throwing them together? fedora-devel: development of fedora not regarding packaging, releasing, infrastruture etc. fedora-maintainers: packaging, repo management, release process related topics, contributor issues etc. One could perhaps classify this as high and low level development discussions. Both lists should then use the fedora-devel-announce list for the summaries/announcements etc. and the submitter should choose what to set the reply-to to, default to one of the two lists (mailman can be configured to only set a reply-to if one isn't there already). -- 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 cra at WPI.EDU Wed Jun 6 20:07:04 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 6 Jun 2007 16:07:04 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706061242.27832.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706061232.03047.jkeating@redhat.com> <4666E3AF.5000302@fedoraproject.org> <200706061242.27832.jkeating@redhat.com> Message-ID: <20070606200704.GD2776@angus.ind.WPI.EDU> On Wed, Jun 06, 2007 at 12:42:27PM -0400, Jesse Keating wrote: > > The rule about not changing user configuration is all about preventing > > surprises to end users. I would argue that not doing what I just > > described is much more surprising to many testers. > > People change the repo files for many reasons, like pointing to their own > local mirror. If we release a package that stomps on those changes that's > really crappy of us. Not something that I am willing to consider. Period. We already stomp repo files on distro upgrades. From jkeating at redhat.com Wed Jun 6 20:10:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 16:10:44 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070606200704.GD2776@angus.ind.WPI.EDU> References: <200706031108.23794.jkeating@redhat.com> <200706061242.27832.jkeating@redhat.com> <20070606200704.GD2776@angus.ind.WPI.EDU> Message-ID: <200706061610.44544.jkeating@redhat.com> On Wednesday 06 June 2007 16:07:04 Chuck Anderson wrote: > > People change the repo files for many reasons, like pointing to their own > > local mirror. ?If we release a package that stomps on those changes > > that's really crappy of us. ?Not something that I am willing to consider. > > ?Period. > > We already stomp repo files on distro upgrades. Unless anaconda is doing something kind of evil here, we don't. Repo files are %config(noreplace), and thus you wind up with .rpmnew or .rpmsave (if the file was removed in the new -release package) files instead of stomped repo files. -- 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 lxtnow at gmail.com Wed Jun 6 20:38:08 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Wed, 6 Jun 2007 16:38:08 -0400 Subject: Koji failed to build [checkout error] Message-ID: <62bc09df0706061338v4c577582if0dd41f446c08d39@mail.gmail.com> it seem that i'm unable to build my package here the error: ----------------------------------------------------------------------------------- Created task: 29339 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=29339 Watching tasks (this may be safely interrupted)... 29339 build (dist-fc7-updates-candidate, F-7:specto-0_2_0-4_fc7): free 29339 build (dist-fc7-updates-candidate, F-7:specto-0_2_0-4_fc7): free -> open (ppc4.fedora.phx.redhat.com) 29340 buildSRPMFromCVS (F-7:specto-0_2_0-4_fc7): open ( ppc1.fedora.redhat.com) 29340 buildSRPMFromCVS (F-7:specto-0_2_0-4_fc7): open ( ppc1.fedora.redhat.com) -> FAILED: BuildError: Error with checkout ': pserver:anonymous at 209.132.176.51:/cvs/pkgs': cvs [checkout aborted]: connect to [209.132.176.51]:2401 failed: Connection timed out 0 free 1 open 0 done 1 failed 29339 build (dist-fc7-updates-candidate, F-7:specto-0_2_0-4_fc7): open ( ppc4.fedora.phx.redhat.com) -> FAILED: BuildError: Error with checkout ': pserver:anonymous at 209.132.176.51:/cvs/pkgs': cvs [checkout aborted]: connect to [209.132.176.51]:2401 failed: Connection timed out 0 free 0 open 0 done 2 failed make: *** [koji] Error 1 ------------------------------------------------------------------------------------ -- Xavier.t Lamien -- French Fedora Ambassador Fedora Extras Contributor GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From blizzard at redhat.com Wed Jun 6 20:44:53 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 06 Jun 2007 16:44:53 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <4667054D.4040900@redhat.com> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> Message-ID: <1181162693.22157.83.camel@localhost.localdomain> On Wed, 2007-06-06 at 15:04 -0400, Warren Togami wrote: > > It is pretty useful if you have the time to follow all the posts and > read everything. It is wrong-minded however to expect everyone with > lesser commitments to be able to read and follow everything on a busy > discussion list. For them, they could opt to follow minimally > fedora-devel-announce. I'm the poster boy for that description, by the way. I have 10,000 messages sitting unread in other folders (including fedora-devel!) but fedora-maintainers is just about right right amount of mail for me to be able to keep up and know what's going on in Fedora with the movers and shakers. --Chris From jkeating at redhat.com Wed Jun 6 20:55:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 6 Jun 2007 16:55:44 -0400 Subject: Koji failed to build [checkout error] In-Reply-To: <62bc09df0706061338v4c577582if0dd41f446c08d39@mail.gmail.com> References: <62bc09df0706061338v4c577582if0dd41f446c08d39@mail.gmail.com> Message-ID: <200706061655.44347.jkeating@redhat.com> On Wednesday 06 June 2007 16:38:08 SmootherFrOgZ wrote: > it seem that i'm unable to build my package Please try again, we think it was a transient hiccup in the network. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Wed Jun 6 21:01:04 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 06 Jun 2007 17:01:04 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <4667054D.4040900@redhat.com> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> Message-ID: <1181163664.2818.20.camel@kennedy> On Wed, 2007-06-06 at 15:04 -0400, Warren Togami wrote: > Christopher Blizzard wrote: > > On Wed, 2007-06-06 at 14:05 -0400, Jesse Keating wrote: > >> > >> *shrug* I'll give this a +1. Although if discussion goes to > >> 'fedora-devel' > >> one wonders what the usefulness of fedora-maintainers will start to > >> be? > >> > > > > Yeah, I don't get this. fedora-maintainers is pretty useful - high > > signal, low crap. The proper reaction to things like this is almost > > never _another_ mailing list. > > > > It is pretty useful if you have the time to follow all the posts and > read everything. It is wrong-minded however to expect everyone with > lesser commitments to be able to read and follow everything on a busy > discussion list. For them, they could opt to follow minimally > fedora-devel-announce. > > I'm half-decided on if fedora-devel-announce then kill > fedora-maintainers. fedora-maintainers has the benefit of having a > significantly better signal to noise ratio than fedora-devel-list. > There is however a detriment to the redundancy. > > If folks were willing to be more MILITANT AND CONSISTENT in enforcing > the "devel only" rules for fedora-devel-list I might be happier about > killing fedora-maintainers. But consistent enforcement has proven to be > impossible to maintain in the past. > > We should talk about this issues in tomorrow's FESCO meeting. I've added it to the schedule. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From caillon at redhat.com Wed Jun 6 21:06:20 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 06 Jun 2007 17:06:20 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <20070606195327.GD30757@neu.nirvana> References: <4666F6AA.6090209@redhat.com> <1181153525.8071.86.camel@erebor.boston.redhat.com> <20070606195327.GD30757@neu.nirvana> Message-ID: <466721CC.4040408@redhat.com> Axel Thimm wrote: > On Wed, Jun 06, 2007 at 02:12:05PM -0400, Jeremy Katz wrote: >> On Wed, 2007-06-06 at 14:02 -0400, Warren Togami wrote: >> > Request for Comments before we do this. >> > >> > Purpose >> > ======= >> > This list is intended to be an INFREQUENTLY used announce-only list. >> > Whenever there is something important that developers should know about, >> > those subscribed to this list should be able to easily follow changes >> > within the development project. >> > >> > Posts are moderated by . >> >> If we do this, we should kill fedora-maintainers. Since the above was >> the original intent of -maintainers and why it was separated off from >> fedora-devel-list. > > My feeling on the development of -devel and -maintainers is the latter > focuses more on the packaging/distribution/infrastructure side of > things. Sure we have dedicated lists for some of these, but tangetial > questions do come up here rather than on the dedicated lists (and it's > understandable, subscribing to fedora-infrastruture to query something > trivial about say the updates system seems like unneeded overhead). > > I wouldn't like to see both list "merge" as regardless of SNR the > volume will be just to high. I'm subscribed to both, but fedora-devel > is too much to handle. > > So maybe redefining the purposes of these lists is better than > throwing them together? > > fedora-devel: development of fedora not regarding packaging, > releasing, infrastruture etc. > > fedora-maintainers: packaging, repo management, release process > related topics, contributor issues etc. Except this is what the noise is. I'm guessing not too many people want to hear about proposals to change packaging guidelines, or release processes. They just want to package stuff up and will abide by whatever guidelines those who care about it decide on. They don't want to be involved with the actual process. Announce the change when it's ready, but don't discuss the proposal here. That's what people seem to be wanting AFAICT. From wtogami at redhat.com Wed Jun 6 21:09:48 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 06 Jun 2007 17:09:48 -0400 Subject: Koji failed to build [checkout error] In-Reply-To: <200706061655.44347.jkeating@redhat.com> References: <62bc09df0706061338v4c577582if0dd41f446c08d39@mail.gmail.com> <200706061655.44347.jkeating@redhat.com> Message-ID: <4667229C.7050203@redhat.com> Jesse Keating wrote: > On Wednesday 06 June 2007 16:38:08 SmootherFrOgZ wrote: >> it seem that i'm unable to build my package > > Please try again, we think it was a transient hiccup in the network. > not a transient hiccup... configs somehow got screwed. We're investigating now. Warren From jwboyer at jdub.homelinux.org Wed Jun 6 21:05:24 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 06 Jun 2007 16:05:24 -0500 Subject: RFC: fedora-devel-announce In-Reply-To: <20070606195327.GD30757@neu.nirvana> References: <4666F6AA.6090209@redhat.com> <1181153525.8071.86.camel@erebor.boston.redhat.com> <20070606195327.GD30757@neu.nirvana> Message-ID: <1181163924.464.47.camel@zod.rchland.ibm.com> On Wed, 2007-06-06 at 21:53 +0200, Axel Thimm wrote: > On Wed, Jun 06, 2007 at 02:12:05PM -0400, Jeremy Katz wrote: > > On Wed, 2007-06-06 at 14:02 -0400, Warren Togami wrote: > > > Request for Comments before we do this. > > > > > > Purpose > > > ======= > > > This list is intended to be an INFREQUENTLY used announce-only list. > > > Whenever there is something important that developers should know about, > > > those subscribed to this list should be able to easily follow changes > > > within the development project. > > > > > > Posts are moderated by . > > > > If we do this, we should kill fedora-maintainers. Since the above was > > the original intent of -maintainers and why it was separated off from > > fedora-devel-list. > > My feeling on the development of -devel and -maintainers That's the whole problem. Everyone has a different interpretation of what list is for what and nobody really knows what's "right" because to some degree everyone's definition makes sense. "Enforcement" of list use is complicated for that same reason. Sorry Axel. That isn't a specific attack at you. Just using your words to highlight the general problem. Please don't take offense. /me goes off into mailing list hell again josh From fedora-packaging at dw-perspective.org.uk Wed Jun 6 21:12:32 2007 From: fedora-packaging at dw-perspective.org.uk (David Anderson) Date: Wed, 6 Jun 2007 22:12:32 +0100 Subject: RFC: fedora-devel-announce In-Reply-To: <466721CC.4040408@redhat.com> References: <4666F6AA.6090209@redhat.com> <20070606195327.GD30757@neu.nirvana> <466721CC.4040408@redhat.com> Message-ID: <200706062212.33001.fedora-packaging@dw-perspective.org.uk> On Wednesday 06 Jun 2007, Christopher Aillon wrote: > > fedora-maintainers: packaging, repo management, release process > > ? ? ? ? ? ? ? related topics, contributor issues etc. > > Except this is what the noise is. ?I'm guessing not too many people > want to hear about proposals to change packaging guidelines, or > release processes. ?They just want to package stuff up and will abide > by whatever guidelines those who care about it decide on. ?They don't > want to be involved with the actual process. ?Announce the change > when it's ready, but don't discuss the proposal here. ?That's what > people seem to be wanting AFAICT. Spot on for me. I am interested in Fedora, but my motivation for packaging is just to get those packages into Fedora, not to affect the long-term direction of the distro: I don't have time for that. I did send my introduction to the list; twice, through different ISPs. Neither seems to have got through, so I appear rather rude! I tried! David -- "For the wages of sin is death; but the gift of God is eternal life through Jesus Christ our Lord." - Romans 6:23 From mmcgrath at redhat.com Wed Jun 6 21:25:49 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 06 Jun 2007 16:25:49 -0500 Subject: Koji failed to build [checkout error] In-Reply-To: <4667229C.7050203@redhat.com> References: <62bc09df0706061338v4c577582if0dd41f446c08d39@mail.gmail.com> <200706061655.44347.jkeating@redhat.com> <4667229C.7050203@redhat.com> Message-ID: <4667265D.3050208@redhat.com> Warren Togami wrote: > Jesse Keating wrote: >> On Wednesday 06 June 2007 16:38:08 SmootherFrOgZ wrote: >>> it seem that i'm unable to build my package >> >> Please try again, we think it was a transient hiccup in the network. >> > > not a transient hiccup... configs somehow got screwed. We're > investigating now. Hiccup should be fixed now. I committed a Makefile.common that I shouldn't have. Its now been reverted. -Mike From Axel.Thimm at ATrpms.net Wed Jun 6 21:44:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Jun 2007 23:44:48 +0200 Subject: RFC: fedora-devel-announce In-Reply-To: <466721CC.4040408@redhat.com> References: <4666F6AA.6090209@redhat.com> <1181153525.8071.86.camel@erebor.boston.redhat.com> <20070606195327.GD30757@neu.nirvana> <466721CC.4040408@redhat.com> Message-ID: <20070606214448.GC16592@neu.nirvana> On Wed, Jun 06, 2007 at 05:06:20PM -0400, Christopher Aillon wrote: > Axel Thimm wrote: > >On Wed, Jun 06, 2007 at 02:12:05PM -0400, Jeremy Katz wrote: > >>On Wed, 2007-06-06 at 14:02 -0400, Warren Togami wrote: > >>> Request for Comments before we do this. > >>> > >>> Purpose > >>> ======= > >>> This list is intended to be an INFREQUENTLY used announce-only list. > >>> Whenever there is something important that developers should know > >>about, > those subscribed to this list should be able to easily follow > >>changes > within the development project. > >>> > >>> Posts are moderated by . > >> > >>If we do this, we should kill fedora-maintainers. Since the above was > >>the original intent of -maintainers and why it was separated off from > >>fedora-devel-list. > > > >My feeling on the development of -devel and -maintainers is the latter > >focuses more on the packaging/distribution/infrastructure side of > >things. Sure we have dedicated lists for some of these, but tangetial > >questions do come up here rather than on the dedicated lists (and it's > >understandable, subscribing to fedora-infrastruture to query something > >trivial about say the updates system seems like unneeded overhead). > > > >I wouldn't like to see both list "merge" as regardless of SNR the > >volume will be just to high. I'm subscribed to both, but fedora-devel > >is too much to handle. > > > >So maybe redefining the purposes of these lists is better than > >throwing them together? > > > >fedora-devel: development of fedora not regarding packaging, > > releasing, infrastruture etc. > > > >fedora-maintainers: packaging, repo management, release process > > related topics, contributor issues etc. > > Except this is what the noise is. I'm guessing not too many people want > to hear about proposals to change packaging guidelines, I didn't imply to merge fedora-packaging or anything else into fedora-maintainers, heaven sake! :) > or release processes. They just want to package stuff up and will > abide by whatever guidelines those who care about it decide on. > They don't want to be involved with the actual process. Announce > the change when it's ready, but don't discuss the proposal here. > That's what people seem to be wanting AFAICT. For the packaging guidelines this is clear, and wasn't suggested to move to this list. But there are other processes that are discussed here, and perhaps rightfully so. What you really want is the fedora-devel-announce list, which I would also like to see, the matter of fedora-maintainers vs -devel is a different subject, and was what I was referring to above. -- 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 Jun 6 21:58:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Jun 2007 23:58:56 +0200 Subject: RFC: fedora-devel-announce In-Reply-To: <1181163924.464.47.camel@zod.rchland.ibm.com> References: <4666F6AA.6090209@redhat.com> <1181153525.8071.86.camel@erebor.boston.redhat.com> <20070606195327.GD30757@neu.nirvana> <1181163924.464.47.camel@zod.rchland.ibm.com> Message-ID: <20070606215856.GD16592@neu.nirvana> On Wed, Jun 06, 2007 at 04:05:24PM -0500, Josh Boyer wrote: > On Wed, 2007-06-06 at 21:53 +0200, Axel Thimm wrote: > > On Wed, Jun 06, 2007 at 02:12:05PM -0400, Jeremy Katz wrote: > > > On Wed, 2007-06-06 at 14:02 -0400, Warren Togami wrote: > > > > Request for Comments before we do this. > > > > > > > > Purpose > > > > ======= > > > > This list is intended to be an INFREQUENTLY used announce-only list. > > > > Whenever there is something important that developers should know about, > > > > those subscribed to this list should be able to easily follow changes > > > > within the development project. > > > > > > > > Posts are moderated by . > > > > > > If we do this, we should kill fedora-maintainers. Since the above was > > > the original intent of -maintainers and why it was separated off from > > > fedora-devel-list. > > > > My feeling on the development of -devel and -maintainers > > That's the whole problem. Everyone has a different interpretation of > what list is for what and nobody really knows what's "right" because to > some degree everyone's definition makes sense. "Enforcement" of list > use is complicated for that same reason. > > Sorry Axel. That isn't a specific attack at you. Just using your words > to highlight the general problem. Please don't take offense. No problem, everyone has a different perception of reality. And indeed I articulated my POV to induce an analytic discussion on content of the lists instead of just deciding on merging or not. Someone (not me ;) should seriously analyse the topics of fedora-devel and -maintainers, check their relationship and objectively identify what is the discrepancy of the de jure and de facto split of topics and either document practice (good) or enforce a different model (less good, but also an option). Aside from topics one also needs to take different target groups into account (maybe that's even the higher priority than topics). Again my personal perception, which I think could also be considered historically attestable is that -maintainers is more populated with packagers reflecting Fedora Extras days, while -devel has the more dedicated bunch of full-time developers that really drive core development in Fedora and has a legacy membership base of people involved with Fedora Core. For example I wouldn't expect "My package foo does not build, help me" on -devel and also no discussion on kernel patches (which now happens on its own list, but for example's sake ignore this new list's existance) or xorg modularization on -maintainers (other than feeding in the resulting output, which would now go to fedora-devel-announce). Both groups overlap to some extend and the line is very blurry, but if one want to spot the differences I think that's the way to think about it. -- 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 laxathom at fedoraproject.org Wed Jun 6 22:03:22 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Wed, 6 Jun 2007 18:03:22 -0400 Subject: Koji failed to build [checkout error] In-Reply-To: <4667265D.3050208@redhat.com> References: <62bc09df0706061338v4c577582if0dd41f446c08d39@mail.gmail.com> <200706061655.44347.jkeating@redhat.com> <4667229C.7050203@redhat.com> <4667265D.3050208@redhat.com> Message-ID: <62bc09df0706061503w3adca3f7nc502cb8e13c9603a@mail.gmail.com> 2007/6/6, Mike McGrath : > > Warren Togami wrote: > > Jesse Keating wrote: > >> On Wednesday 06 June 2007 16:38:08 SmootherFrOgZ wrote: > >>> it seem that i'm unable to build my package > >> > >> Please try again, we think it was a transient hiccup in the network. > >> > > > > not a transient hiccup... configs somehow got screwed. We're > > investigating now. > Hiccup should be fixed now. I committed a Makefile.common that I > shouldn't have. Its now been reverted. > > -Mike Build done, thanks -- Xavier.t Lamien -- French Fedora Ambassador Fedora Extras Contributor GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From tchung at fedoraproject.org Wed Jun 6 22:04:23 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Wed, 6 Jun 2007 15:04:23 -0700 Subject: Fedora 7 Update Informatin for general users In-Reply-To: <20070606184539.GA10574@tomservo.rochester.rr.com> References: <369bce3b0706022328m2f2fe419hd62a447b97c05d98@mail.gmail.com> <20070606184539.GA10574@tomservo.rochester.rr.com> Message-ID: <369bce3b0706061504s377c7d2by47f146e85705f1b6@mail.gmail.com> On 6/6/07, Luke Macken wrote: > On Sat, Jun 02, 2007 at 11:28:00PM -0700, Thomas Chung wrote: > > First all, thank you for Fedora Update System. > > It's wonderful to see that we finally have something we always wanted. > > > > While looking at the list of Stable Updates for Fedora 7[1], it gives > > me an idea that this could replace our static Fedora Security > > Advisories and Package Updates for Fedora 7[1] on our project wiki. > > > > What do you think? Could we open this system up so any general users > > can see this information anonymously without logging-in with Fedora > > Account System? > > I think this is a great idea. I opened a new ticket[0] to try and get > this done fairly soon. I'm in the process of revamping bodhi's database > schema a little bit, so after that I'll work on getting RSS feeds[1] > working and throw up a public site. > > > Perhaps, we could create a new page specifically for anonymous users > > without comments field? > > We could, although getting comments from the average user regarding test > updates may be useful, or even provide a simple form that allows people to > easily file bugs against that component. > > luke > > [0]: https://hosted.fedoraproject.org/projects/bodhi/ticket/43 > [1]: https://hosted.fedoraproject.org/projects/bodhi/ticket/12 Thank you Luke! Please note this supposed to be replacement for current FSA/F7 wiki page[1] which we report via FWN every week. So, we don't really need updates-testing with comments. We just need updates-stable without comments. Preferably one long page with read-only access for anonymous users. [1] http://fedoraproject.org/wiki/FSA/F7 Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From caillon at redhat.com Wed Jun 6 22:24:33 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 06 Jun 2007 18:24:33 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <20070606215856.GD16592@neu.nirvana> References: <4666F6AA.6090209@redhat.com> <1181153525.8071.86.camel@erebor.boston.redhat.com> <20070606195327.GD30757@neu.nirvana> <1181163924.464.47.camel@zod.rchland.ibm.com> <20070606215856.GD16592@neu.nirvana> Message-ID: <46673421.20706@redhat.com> Axel Thimm wrote: > Someone (not me ;) should seriously analyse the topics of fedora-devel > and -maintainers, check their relationship and objectively identify > what is the discrepancy of the de jure and de facto split of topics > and either document practice (good) or enforce a different model (less > good, but also an option). Okay. I just did a quick run on threads (excluding this one) from now back to the beginning of June on -maintainers. Looks like over half of them could have been moved off this list as they didn't affect most maintainers and/or were reporting bugs, etc. Koji failed to build [checkout error] not every maintainer needs to know that one specific package failed to build, should be on -devel or a bug filed. Outage Notification - 2007-06-07 04:00 [UTC] Every maintainer needs to know about this. Good. owners.epel.list problem Bug in a repo file. Not every maintainer needs to know this. Bug can be filed or moved to -devel. libmpcdec-1.2.6, soname++ Only 4 packages are affected by this including one by the sender of the mail, so this would affect 3 people total. Probably best to send them direct mail. Plan for tomorrows (20070607) FESCO meeting Most people probably don't care. bogus debuginfo*rpms in updates/repodata Most people don't care unless they have to do something. Broken libcurl.so.3 dependency Affects some people, but until we figure out what, should probably be posted to -devel. Summary of the 2007-06-05 Packaging Committee meeting In general, this affects people when they need to know about new guidelines, so probably good that it's on -maintainers. libwnck soname bumps Affects a lot of packagers. -maintainers is fine Easier way to maintain comps.xml ? This is looking for opinions about comps.xml which most people don't know/care about. Wrong list for this IMO. Fedora Package Status of Jun 5, 2007 While all-encompassing, do we need this to be mailed out to all the maintainers? People like stats, not sure if this is useful here or not. Should we just have a page for it (which we do) and people can look when they want? koji: not building against koji-built packages? bug or user issue? Affects everyone, but is trying to figure out policy. Probably should move somewhere else first. Info for package maintainers Help in general for maintainers. Probably fine here. Bodhi returns 500 Internal Error when submitting new update Small thread that affected some maintainers but probably should have been filed as a bug. FESCo Meeting Summary for 2007-05-31 Okay. cegui review & heads up No replies. But probably should have gone to -devel or something where there are more devel type people. libwnck soname up This should definitely have been sent to -devel. Proposed patch to cvs-import.sh ->bugzilla? Merge Review Probably good for this list as it's trying to clarify what the existing policy is for maintainers. Bodhi updates-testing Autopush, Anonymous Commenting Brainstorm thread. The announcement of bodhi should have pointed to a place to file ideas for it where people can go to. Else, this is more for development of a tool and should have gone to -devel where a fair number of maintainers live anyway. No sound on PowerPC Mac Mini after upgrading from fc6 to Fedora7 Wrong list -- should have been to -test or some user forum. "Fedora Update System" makes comments into bugzilla and closes bugs Letting maintainers know about a feature. Probably okay. Unsigned package in repo - how do I get it signed? This should have been a bug filed against something, though the thread poster didn't know where to file. We should make this easier to learn. Asking where to file is probably okay here, though. Plan for tomorrow's (20070604) Release Engineering meeting There's probably other lists that people who care about this stuff can go to. Come back with results. EPEL report week 21, 2007 relates to a large number of contributors, though this might do better as a newsletter, etc. Fedora 7 Update Informatin for general users Probably should have been to -devel [Fwd: Bugzilla news is the Zod announcement] This is a bug report about our bugzilla page. -maintainers is absolutely the wrong list here. Updates notification information on Fedora 7? Clarification on a brand new update tool, okay to post on -maintainers. HOWTO for bodhi and friends? Asking for more clarification, okay for this list. Pushing from updates-testing to updates Looking for clarification. Okay. Yum-presto not "submitted" in Bodhi Asking about a specific package, but since it's confusion on bodhi, probably okay. From wtogami at redhat.com Thu Jun 7 03:35:23 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 06 Jun 2007 23:35:23 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <20070606214448.GC16592@neu.nirvana> References: <4666F6AA.6090209@redhat.com> <1181153525.8071.86.camel@erebor.boston.redhat.com> <20070606195327.GD30757@neu.nirvana> <466721CC.4040408@redhat.com> <20070606214448.GC16592@neu.nirvana> Message-ID: <46677CFB.8040506@redhat.com> Axel Thimm wrote: > > What you really want is the fedora-devel-announce list, which I would > also like to see, the matter of fedora-maintainers vs -devel is a > different subject, and was what I was referring to above. I am in agreement, fedora-maintainers and -devel is a different issue from fedora-devel-announce and should be treated independently as such. I believe we should treat fedora-devel-announce as a useful but OPTIONAL resource. If others don't wish to subscribe then nothing is lost, because they might be the ones following the discussion lists. Let us optimize and improve the discussion mediums as a separate matter. Warren Togami wtogami at redhat.com From lxtnow at gmail.com Thu Jun 7 04:42:04 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Thu, 7 Jun 2007 00:42:04 -0400 Subject: Koji failed to build [dependencies missing error] Message-ID: <62bc09df0706062142g27a8b60em7591606f654ebf74@mail.gmail.com> Hi, after launched build for F-7 branch, koji reply me an error about missing dependencies "gammu-devel" which i already imported and built on koji. see koji build status page http://koji.fedoraproject.org/koji/buildinfo?buildID=7277 Indeed this package seem do not be yet in F-7 repository. note this package gammu-devel has been built before bodhi has been setting up and announced. -- Xavier.t Lamien -- French Fedora Ambassador Fedora Extras Contributor GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Thu Jun 7 04:48:44 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 07 Jun 2007 06:48:44 +0200 Subject: general mailing list reorganization? (was Re: RFC: fedora-devel-announce) In-Reply-To: <1181163664.2818.20.camel@kennedy> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <1181163664.2818.20.camel@kennedy> Message-ID: <46678E2C.9000500@leemhuis.info> On 06.06.2007 23:01, Brian Pepple wrote: > On Wed, 2007-06-06 at 15:04 -0400, Warren Togami wrote: >> Christopher Blizzard wrote: >>> On Wed, 2007-06-06 at 14:05 -0400, Jesse Keating wrote: >>>> *shrug* I'll give this a +1. Although if discussion goes to >>>> 'fedora-devel' >>>> one wonders what the usefulness of fedora-maintainers will start to >>>> be? >>>> >>> Yeah, I don't get this. fedora-maintainers is pretty useful - high >>> signal, low crap. The proper reaction to things like this is almost >>> never _another_ mailing list. >>> >> It is pretty useful if you have the time to follow all the posts and >> read everything. It is wrong-minded however to expect everyone with >> lesser commitments to be able to read and follow everything on a busy >> discussion list. For them, they could opt to follow minimally >> fedora-devel-announce. >> >> I'm half-decided on if fedora-devel-announce then kill >> fedora-maintainers. fedora-maintainers has the benefit of having a >> significantly better signal to noise ratio than fedora-devel-list. >> There is however a detriment to the redundancy. >> >> If folks were willing to be more MILITANT AND CONSISTENT in enforcing >> the "devel only" rules for fedora-devel-list I might be happier about >> killing fedora-maintainers. But consistent enforcement has proven to be >> impossible to maintain in the past. >> >> We should talk about this issues in tomorrow's FESCO meeting. > > I've added it to the schedule. Killing fedora-maintainers is part of the plan for the mailing list reorganization the Board put on my plate months ago. The hardware for that was promised for mid April. :-( Mike, any update when something really happens? BTW, I agree with the fedora-devel-announce idea as something like that was part of the mailing list reorganization as well. But if the hardware for that is not that far away (e.g. less then one month) I'd say we create that on the new hardware directly. CU knurd From bugs.michael at gmx.net Thu Jun 7 08:28:12 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 7 Jun 2007 10:28:12 +0200 Subject: Koji failed to build [dependencies missing error] In-Reply-To: <62bc09df0706062142g27a8b60em7591606f654ebf74@mail.gmail.com> References: <62bc09df0706062142g27a8b60em7591606f654ebf74@mail.gmail.com> Message-ID: <20070607102812.002e251e.bugs.michael@gmx.net> On Thu, 7 Jun 2007 00:42:04 -0400, SmootherFrOgZ wrote: > Hi, > > after launched build for F-7 branch, koji reply me an error about missing > dependencies "gammu-devel" which i already imported and built on koji. > see koji build status page > http://koji.fedoraproject.org/koji/buildinfo?buildID=7277 > Indeed this package seem do not be yet in F-7 repository. > > note this package gammu-devel has been built before bodhi has been setting > up and announced. It is not available in koji as an earlier build: http://koji.fedoraproject.org/koji/packageinfo?packageID=4412 And if it doesn't appear in the buildroots, check out the thread on this list that discusses buildroot poisoning: Subject: koji: not building against koji-built packages? bug or user issue? From andreas.bierfert at lowlatency.de Thu Jun 7 09:11:25 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 7 Jun 2007 11:11:25 +0200 Subject: koji: not building against koji-built packages? bug or user issue? In-Reply-To: <46657FF2.6030708@redhat.com> References: <20070605133123.GP23972@neu.nirvana> <200706051028.25740.jkeating@redhat.com> <46657FF2.6030708@redhat.com> Message-ID: <20070607111125.5440e3f5@alkaid.a.lan> On Tue, 05 Jun 2007 11:23:30 -0400 Christopher Aillon wrote: > The ability to do make build ADD_TO_BR=firefox-x.y-z or similar as > something I need to add to dependent packages is much more appealing > than having to specify everything at once. +1 Sounds good to me. Maybe not the NVR but the cvs tag could be used. Also maybe there could/should be a visual way to do it for people that don't like cli. Say you do a make tag and then in bodhi/koji you can specify what packages should go into the buildroot for the build of that specific tag that are sitting around besides the release/updates packages. That would mean to create a repository special to this build but in keeping this optional for the packages that need it it won't slow down building simple updates. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- 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 Thu Jun 7 11:27:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 07:27:32 -0400 Subject: RFC: fedora-devel-announce In-Reply-To: <46677CFB.8040506@redhat.com> References: <4666F6AA.6090209@redhat.com> <20070606214448.GC16592@neu.nirvana> <46677CFB.8040506@redhat.com> Message-ID: <200706070727.32697.jkeating@redhat.com> On Wednesday 06 June 2007 23:35:23 Warren Togami wrote: > I believe we should treat fedora-devel-announce as a useful but OPTIONAL > resource. ?If others don't wish to subscribe then nothing is lost, > because they might be the ones following the discussion lists. > > Let us optimize and improve the discussion mediums as a separate matter. Optional in the way that you can subscribe if you want to if you're already a maintainer right? New maintainers will still get autosubscribed, and mails from it will still go to one of fedora-devel-list or fedora-maintainers? The real value to me in this proposal is that I can post announcements to a singular address and capture all relevant folks. If the discussion afterward doesn't, well that's just too bad, and I don't really care _where_ it happens, so long as it happens on only one list, not cross-post of doom like we sometimes have. -- 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 Thu Jun 7 12:44:01 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 07 Jun 2007 08:44:01 -0400 Subject: general mailing list reorganization? (was Re: RFC: fedora-devel-announce) In-Reply-To: <46678E2C.9000500@leemhuis.info> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <1181163664.2818.20.camel@kennedy> <46678E2C.9000500@leemhuis.info> Message-ID: <4667FD91.5040602@redhat.com> Thorsten Leemhuis wrote: > On 06.06.2007 23:01, Brian Pepple wrote: >> On Wed, 2007-06-06 at 15:04 -0400, Warren Togami wrote: >>> Christopher Blizzard wrote: >>>> On Wed, 2007-06-06 at 14:05 -0400, Jesse Keating wrote: >>>>> *shrug* I'll give this a +1. Although if discussion goes to >>>>> 'fedora-devel' >>>>> one wonders what the usefulness of fedora-maintainers will start to >>>>> be? >>>>> >>>> Yeah, I don't get this. fedora-maintainers is pretty useful - high >>>> signal, low crap. The proper reaction to things like this is almost >>>> never _another_ mailing list. >>>> >>> It is pretty useful if you have the time to follow all the posts and >>> read everything. It is wrong-minded however to expect everyone with >>> lesser commitments to be able to read and follow everything on a busy >>> discussion list. For them, they could opt to follow minimally >>> fedora-devel-announce. >>> >>> I'm half-decided on if fedora-devel-announce then kill >>> fedora-maintainers. fedora-maintainers has the benefit of having a >>> significantly better signal to noise ratio than fedora-devel-list. >>> There is however a detriment to the redundancy. >>> >>> If folks were willing to be more MILITANT AND CONSISTENT in enforcing >>> the "devel only" rules for fedora-devel-list I might be happier about >>> killing fedora-maintainers. But consistent enforcement has proven to be >>> impossible to maintain in the past. >>> >>> We should talk about this issues in tomorrow's FESCO meeting. >> I've added it to the schedule. > > Killing fedora-maintainers is part of the plan for the mailing list > reorganization the Board put on my plate months ago. The hardware for > that was promised for mid April. :-( Mike, any update when something > really happens? > > BTW, I agree with the fedora-devel-announce idea as something like that > was part of the mailing list reorganization as well. But if the hardware > for that is not that far away (e.g. less then one month) I'd say we > create that on the new hardware directly. > Are we past the of running our own mail server? Warren From mmcgrath at redhat.com Thu Jun 7 13:30:28 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 07 Jun 2007 08:30:28 -0500 Subject: general mailing list reorganization? (was Re: RFC: fedora-devel-announce) In-Reply-To: <46678E2C.9000500@leemhuis.info> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <1181163664.2818.20.camel@kennedy> <46678E2C.9000500@leemhuis.info> Message-ID: <46680874.9060600@redhat.com> Thorsten Leemhuis wrote: > On 06.06.2007 23:01, Brian Pepple wrote: > >> On Wed, 2007-06-06 at 15:04 -0400, Warren Togami wrote: >> >>> Christopher Blizzard wrote: >>> >>>> On Wed, 2007-06-06 at 14:05 -0400, Jesse Keating wrote: >>>> >>>>> *shrug* I'll give this a +1. Although if discussion goes to >>>>> 'fedora-devel' >>>>> one wonders what the usefulness of fedora-maintainers will start to >>>>> be? >>>>> >>>>> >>>> Yeah, I don't get this. fedora-maintainers is pretty useful - high >>>> signal, low crap. The proper reaction to things like this is almost >>>> never _another_ mailing list. >>>> >>>> >>> It is pretty useful if you have the time to follow all the posts and >>> read everything. It is wrong-minded however to expect everyone with >>> lesser commitments to be able to read and follow everything on a busy >>> discussion list. For them, they could opt to follow minimally >>> fedora-devel-announce. >>> >>> I'm half-decided on if fedora-devel-announce then kill >>> fedora-maintainers. fedora-maintainers has the benefit of having a >>> significantly better signal to noise ratio than fedora-devel-list. >>> There is however a detriment to the redundancy. >>> >>> If folks were willing to be more MILITANT AND CONSISTENT in enforcing >>> the "devel only" rules for fedora-devel-list I might be happier about >>> killing fedora-maintainers. But consistent enforcement has proven to be >>> impossible to maintain in the past. >>> >>> We should talk about this issues in tomorrow's FESCO meeting. >>> >> I've added it to the schedule. >> > > Killing fedora-maintainers is part of the plan for the mailing list > reorganization the Board put on my plate months ago. The hardware for > that was promised for mid April. :-( Mike, any update when something > really happens? > > No hardware was actually promised for this particular project and its still a very low priority to the infrastructure team (AFAIK). We have a current working solution in place right now for this. We did get the new netapp setup but we are still waiting on a new disktray for it. Also when you're talking about the plan, can you send me a link to it? It will better help me plan A) how important this is to ensure the continuance of Fedora and B) what we need to do to get it done. -Mike From fedora at leemhuis.info Thu Jun 7 16:38:17 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 07 Jun 2007 18:38:17 +0200 Subject: general mailing list reorganization? (was Re: RFC: fedora-devel-announce) In-Reply-To: <4667FD91.5040602@redhat.com> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <1181163664.2818.20.camel@kennedy> <46678E2C.9000500@leemhuis.info> <4667FD91.5040602@redhat.com> Message-ID: <46683479.6090705@leemhuis.info> On 07.06.2007 14:44, Warren Togami wrote: > [...] > Are we past the of running our own mail server? I asked on fedora-advisory-board for more info. I'll report here when I know more. Cu thl From fedora at leemhuis.info Thu Jun 7 16:42:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 07 Jun 2007 18:42:43 +0200 Subject: general mailing list reorganization? (was Re: RFC: fedora-devel-announce) In-Reply-To: <46680874.9060600@redhat.com> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <1181163664.2818.20.camel@kennedy> <46678E2C.9000500@leemhuis.info> <46680874.9060600@redhat.com> Message-ID: <46683583.2090804@leemhuis.info> On 07.06.2007 15:30, Mike McGrath wrote: > Thorsten Leemhuis wrote: >> On 06.06.2007 23:01, Brian Pepple wrote: >>> On Wed, 2007-06-06 at 15:04 -0400, Warren Togami wrote: > [...] >>>> We should talk about this issues in tomorrow's FESCO meeting. >>> I've added it to the schedule. >> Killing fedora-maintainers is part of the plan for the mailing list >> reorganization the Board put on my plate months ago. The hardware for >> that was promised for mid April. :-( Mike, any update when something >> really happens? > No hardware was actually promised for this particular project Sorry, I thought is was. > and its > still a very low priority to the infrastructure team (AFAIK). I asked for the Board's opinion on fedora-advisory-board ; maybe the board can make it a higher priority *if* we want it to be one. > We have > a current working solution in place right now for this. You mean the mailman that runs this list? Or for a lists.fedoraproject.org? I'm fine with doing the reorganization on this server, but back months ago a lot of people wanted a dedicated server. > We did get the > new netapp setup but we are still waiting on a new disktray for it. > Also when you're talking about the plan, can you send me a link to it? The proposal from the last discussion can be found at http://fedoraproject.org/wiki/ThorstenLeemhuis/MailingListReorganization -- *warning*, wasn't touched much in the past months and likely needs some adjustments, so don't look at it to close ;-) > [...] Cu thl From caillon at redhat.com Thu Jun 7 16:50:01 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 07 Jun 2007 12:50:01 -0400 Subject: koji: not building against koji-built packages? bug or user issue? In-Reply-To: <20070607111125.5440e3f5@alkaid.a.lan> References: <20070605133123.GP23972@neu.nirvana> <200706051028.25740.jkeating@redhat.com> <46657FF2.6030708@redhat.com> <20070607111125.5440e3f5@alkaid.a.lan> Message-ID: <46683739.2040303@redhat.com> Andreas Bierfert wrote: > On Tue, 05 Jun 2007 11:23:30 -0400 > Christopher Aillon wrote: > >> The ability to do make build ADD_TO_BR=firefox-x.y-z or similar as >> something I need to add to dependent packages is much more appealing >> than having to specify everything at once. > > +1 For reference, a more detailed proposal is laid out here: https://hosted.fedoraproject.org/projects/koji/ticket/23 From mmcgrath at redhat.com Thu Jun 7 16:55:45 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 07 Jun 2007 11:55:45 -0500 Subject: general mailing list reorganization? (was Re: RFC: fedora-devel-announce) In-Reply-To: <46683583.2090804@leemhuis.info> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <1181163664.2818.20.camel@kennedy> <46678E2C.9000500@leemhuis.info> <46680874.9060600@redhat.com> <46683583.2090804@leemhuis.info> Message-ID: <46683891.4080503@redhat.com> Thorsten Leemhuis wrote: > > I asked for the Board's opinion on fedora-advisory-board ; maybe the > board can make it a higher priority *if* we want it to be one. > > If we get more people requesting it it will be easier to justify giving it a higher priority. >> We have >> a current working solution in place right now for this. >> > > You mean the mailman that runs this list? Or for a > lists.fedoraproject.org? I'm fine with doing the reorganization on this > server, but back months ago a lot of people wanted a dedicated server. > > Nope, I mean where its hosted now. >> We did get the >> new netapp setup but we are still waiting on a new disktray for it. >> Also when you're talking about the plan, can you send me a link to it? >> > > The proposal from the last discussion can be found at > http://fedoraproject.org/wiki/ThorstenLeemhuis/MailingListReorganization > -- *warning*, wasn't touched much in the past months and likely needs > some adjustments, so don't look at it to close ;-) > Excellent, thanks. I'm reading it now. -Mike From fedora at leemhuis.info Thu Jun 7 17:07:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 07 Jun 2007 19:07:18 +0200 Subject: general mailing list reorganization? (was Re: RFC: fedora-devel-announce) In-Reply-To: <46683891.4080503@redhat.com> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <1181163664.2818.20.camel@kennedy> <46678E2C.9000500@leemhuis.info> <46680874.9060600@redhat.com> <46683583.2090804@leemhuis.info> <46683891.4080503@redhat.com> Message-ID: <46683B46.2080209@leemhuis.info> On 07.06.2007 18:55, Mike McGrath wrote: > Thorsten Leemhuis wrote: >> I asked for the Board's opinion on fedora-advisory-board ; maybe the >> board can make it a higher priority *if* we want it to be one. > If we get more people requesting it it will be easier to justify giving > it a higher priority. Well, the Board afaics months ago already agreed that we need to do something. We just let it slip a bit due to the merge being more important ;-) >>> We have >>> a current working solution in place right now for this. >> You mean the mailman that runs this list? Or for a >> lists.fedoraproject.org? I'm fine with doing the reorganization on this >> server, but back months ago a lot of people wanted a dedicated server. > Nope, I mean where its hosted now. As I said: I'm fine with continuing to use it. But back earlier this year 1. -- people wanted to get a subdomain with a "list" prefix 2. -- I think there were concerns because none of us had direct access to the mailman servers 3. -- people wanted to be independent of red hat Mike are the solution to problem "2"? Could the first problem maybe solved with an alias or something like that? The only point "3" would remain. Cu thl From oliver at linux-kernel.at Thu Jun 7 18:22:29 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 07 Jun 2007 20:22:29 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <200706061242.27832.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706061232.03047.jkeating@redhat.com> <4666E3AF.5000302@fedoraproject.org> <200706061242.27832.jkeating@redhat.com> Message-ID: <46684CE5.2020308@linux-kernel.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating schrieb: > On Wednesday 06 June 2007 12:41:19 Rahul Sundaram wrote: >> Note that we aren't talking about custom repositories or anything like >> that. User switches on fedora-devel repo and runs yum update. Just >> before a new release a new fedora-release gets pushed that turns off the >> devel repo and points to the stable branch. >> >> The rule about not changing user configuration is all about preventing >> surprises to end users. I would argue that not doing what I just >> described is much more surprising to many testers. > > People change the repo files for many reasons, like pointing to their own > local mirror. If we release a package that stomps on those changes that's > really crappy of us. Not something that I am willing to consider. Period. Copy that. For myself and my few servers I can say: I have removed anything in /etc/yum.repos.d/ and have one include line in /etc/yum.conf, that actually is a script on a remote server. Perl it is, but nevermind, it does what it should - depending on the release number and architecture, it returns a list of repos... If some package would change this configuration in some way, I wouldn't be happy! :-) At company we have a very simliar setup; BUT: More than 120 (Linux) servers. If I would have to manually fix this........ Don't want to even think about... - -of -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGaEzlxWN5Ge8lKUMRAqTnAKDvvIEeENLSOBOGbpSyZA7btQ0sWACg3XXC isrCIyokokSTCP/LlneOOUY= =LYIV -----END PGP SIGNATURE----- From dominik at greysector.net Thu Jun 7 18:14:55 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 7 Jun 2007 20:14:55 +0200 Subject: verifying comps Message-ID: <20070607181455.GA6238@ryvius.pekin.waw.pl> Hello. I was just wondering... could there be some automated check and weekly report implemented for verifying if all appropriate packages are present in the comps files? 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 Jun 7 18:49:06 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Thu, 7 Jun 2007 20:49:06 +0200 Subject: verifying comps In-Reply-To: <20070607181455.GA6238@ryvius.pekin.waw.pl> References: <20070607181455.GA6238@ryvius.pekin.waw.pl> Message-ID: On 7-jun-2007, at 20:14, Dominik 'Rathann' Mierzejewski wrote: > Hello. > > I was just wondering... could there be some automated check and > weekly report > implemented for verifying if all appropriate packages are present > in the > comps files? Have a look at http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus#head- e83a47eb0097eaa3765fb33c1cdf1c94932d1acd Ruben From sundaram at fedoraproject.org Thu Jun 7 18:55:19 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 Jun 2007 00:25:19 +0530 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <46684CE5.2020308@linux-kernel.at> References: <200706031108.23794.jkeating@redhat.com> <200706061232.03047.jkeating@redhat.com> <4666E3AF.5000302@fedoraproject.org> <200706061242.27832.jkeating@redhat.com> <46684CE5.2020308@linux-kernel.at> Message-ID: <46685497.1090709@fedoraproject.org> Oliver Falk wrote: > For myself and my few servers I can say: I have removed anything in > /etc/yum.repos.d/ and have one include line in /etc/yum.conf, that > actually is a script on a remote server. Perl it is, but nevermind, it > does what it should - depending on the release number and architecture, > it returns a list of repos... If some package would change this > configuration in some way, I wouldn't be happy! :-) At company we have a > very simliar setup; BUT: More than 120 (Linux) servers. If I would have > to manually fix this........ Don't want to even think about... Are you running those 120 Linux servers in rawhide? That's all we are talking about here. Rahul From jkeating at redhat.com Thu Jun 7 19:05:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 15:05:20 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <46685497.1090709@fedoraproject.org> References: <200706031108.23794.jkeating@redhat.com> <46684CE5.2020308@linux-kernel.at> <46685497.1090709@fedoraproject.org> Message-ID: <200706071505.20296.jkeating@redhat.com> On Thursday 07 June 2007 14:55:19 Rahul Sundaram wrote: > Are you running those 120 Linux servers in rawhide? That's all we are > talking about here. Doesn't matter. It's the package that installed the file that determines if it should be kept or not. So the released fedora-release says config(noreplace), even if rawhide has it as just config, it won't replace 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 jkeating at redhat.com Thu Jun 7 19:05:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 15:05:55 -0400 Subject: verifying comps In-Reply-To: <20070607181455.GA6238@ryvius.pekin.waw.pl> References: <20070607181455.GA6238@ryvius.pekin.waw.pl> Message-ID: <200706071505.56110.jkeating@redhat.com> On Thursday 07 June 2007 14:14:55 Dominik 'Rathann' Mierzejewski wrote: > Hello. > > I was just wondering... could there be some automated check and weekly > report implemented for verifying if all appropriate packages are present in > the comps files? How do you determine what is "appropriate" ? Comps lists high level packages, not low level 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 Axel.Thimm at ATrpms.net Thu Jun 7 19:13:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 7 Jun 2007 21:13:18 +0200 Subject: "people wanted to be independent of red hat" ??? (was: general mailing list reorganization?) In-Reply-To: <46683B46.2080209@leemhuis.info> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <1181163664.2818.20.camel@kennedy> <46678E2C.9000500@leemhuis.info> <46680874.9060600@redhat.com> <46683583.2090804@leemhuis.info> <46683891.4080503@redhat.com> <46683B46.2080209@leemhuis.info> Message-ID: <20070607191318.GE12450@neu.nirvana> On Thu, Jun 07, 2007 at 07:07:18PM +0200, Thorsten Leemhuis wrote: > On 07.06.2007 18:55, Mike McGrath wrote: > > Thorsten Leemhuis wrote: > >> I asked for the Board's opinion on fedora-advisory-board ; maybe the > >> board can make it a higher priority *if* we want it to be one. > > If we get more people requesting it it will be easier to justify giving > > it a higher priority. > > Well, the Board afaics months ago already agreed that we need to do > something. We just let it slip a bit due to the merge being more > important ;-) > > >>> We have > >>> a current working solution in place right now for this. > >> You mean the mailman that runs this list? Or for a > >> lists.fedoraproject.org? I'm fine with doing the reorganization on this > >> server, but back months ago a lot of people wanted a dedicated server. > > Nope, I mean where its hosted now. > > As I said: I'm fine with continuing to use it. But back earlier this year > > 1. -- people wanted to get a subdomain with a "list" prefix Who are these people? Maybe they should speak up if this is such an issue? > 2. -- I think there were concerns because none of us had direct access > to the mailman servers That's a valid point, but maybe Mike can get access for himself, so there will be one Fedora insider who can fix things? > 3. -- people wanted to be independent of red hat So let's cancel Red Hat's sponsoring and find a new role for Max, Mike and all other Fedora dedicated @redhat.com folks. We should also find new sponsoring for Red Hat's donated hardware and bandwidth resources. ;) What's the problem with being dependent on Red Hat? Some (most) see this as a feature, not a bug, and it's Fedora's tagline "sponsored by Red Hat". Changing the domain name, while it will be nice, is not a way to become independent of Red Hat or to falsly demonstrate such independence. It isn't wrong to use the fp.o domain, but not for the reasons stated, more for consistent cosmetic/asthetic reasons and "corporate design". And these reasons are indeed rather low priority. > Mike are the solution to problem "2"? Could the first problem maybe > solved with an alias or something like that? The only point "3" > would remain. Let's invest resources into smoothing our tools and getting into the next phase of the improved merged buildsystem, aka scm business. Wasting resources in hardware and man power just to fix a domain suffix seems wrong at this point in time. I think Warren's "let's just create the new needed lists" attitude is far better suited. -- 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 nicolas.mailhot at laposte.net Thu Jun 7 19:30:12 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 07 Jun 2007 21:30:12 +0200 Subject: verifying comps In-Reply-To: <200706071505.56110.jkeating@redhat.com> References: <20070607181455.GA6238@ryvius.pekin.waw.pl> <200706071505.56110.jkeating@redhat.com> Message-ID: <1181244612.18723.30.camel@rousalka.dyndns.org> Le jeudi 07 juin 2007 ? 15:05 -0400, Jesse Keating a ?crit : > On Thursday 07 June 2007 14:14:55 Dominik 'Rathann' Mierzejewski wrote: > > Hello. > > > > I was just wondering... could there be some automated check and weekly > > report implemented for verifying if all appropriate packages are present in > > the comps files? > > How do you determine what is "appropriate" ? Comps lists high level packages, > not low level deps. The best we could do is check every package is reacheable directly or indirectly from comps -- 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 fedora at leemhuis.info Thu Jun 7 19:31:34 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 07 Jun 2007 21:31:34 +0200 Subject: "people wanted to be independent of red hat" ??? In-Reply-To: <20070607191318.GE12450@neu.nirvana> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <1181163664.2818.20.camel@kennedy> <46678E2C.9000500@leemhuis.info> <46680874.9060600@redhat.com> <46683583.2090804@leemhuis.info> <46683891.4080503@redhat.com> <46683B46.2080209@leemhuis.info> <20070607191318.GE12450@neu.nirvana> Message-ID: <46685D16.3050003@leemhuis.info> On 07.06.2007 21:13, Axel Thimm wrote: > On Thu, Jun 07, 2007 at 07:07:18PM +0200, Thorsten Leemhuis wrote: >> On 07.06.2007 18:55, Mike McGrath wrote: >>>>> We have >>>>> a current working solution in place right now for this. >>>> You mean the mailman that runs this list? Or for a >>>> lists.fedoraproject.org? I'm fine with doing the reorganization on this >>>> server, but back months ago a lot of people wanted a dedicated server. >>> Nope, I mean where its hosted now. >> As I said: I'm fine with continuing to use it. But back earlier this year >> 1. -- people wanted to get a subdomain with a "list" prefix > Who are these people? Maybe they should speak up if this is such an > issue? They spoke. It's should be in the archives (December or January iirc) of fedora-devel somewhere; on fab also. The situation in short as far as I remember it: I asked people if they wanted a list prefix or not. There were people for both camps. Then someone said: having a "list" in the domainname (such as lists.fedora-project.org or lists.gnome.org) makes it obvious that you are writing to a list. Back then that was afaics the solution most people preferred. > [...] >> 3. -- people wanted to be independent of red hat > So let's cancel Red Hat's sponsoring and find a new role for Max, Mike > and all other Fedora dedicated @redhat.com folks. We should also find > new sponsoring for Red Hat's donated hardware and bandwidth > resources. ;) > [...] It was not my opinion, I just laid down the opinions that I heard back then. > Let's invest resources into smoothing our tools and getting into the > next phase of the improved merged buildsystem, aka scm > business. Wasting resources in hardware and man power just to fix a > domain suffix seems wrong at this point in time. In a project as large as Fedora different people work on different areas and have different interests. The Boards noticed that the mailing lists could needs some adjustments. They asked me to do that and I said "yes". If you don't like that contact the board. > I think Warren's "let's just create the new needed lists" attitude is > far better suited. I agree in this case, as I was one of the drivers for such a list back when I was FESCo chair. But as I said, some people in important positions blocked it back then so we never started to use it. I really like that we get the list now. But a general "let's just create the new needed lists" attitude just leads to chaos. CU thl From jkeating at redhat.com Thu Jun 7 19:41:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 15:41:54 -0400 Subject: verifying comps In-Reply-To: <1181244612.18723.30.camel@rousalka.dyndns.org> References: <20070607181455.GA6238@ryvius.pekin.waw.pl> <200706071505.56110.jkeating@redhat.com> <1181244612.18723.30.camel@rousalka.dyndns.org> Message-ID: <200706071541.54678.jkeating@redhat.com> On Thursday 07 June 2007 15:30:12 Nicolas Mailhot wrote: > The best we could do is check every package is reacheable directly or > indirectly from comps Great! When will we see a proof of concept? (: -- 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 Jun 7 19:42:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 7 Jun 2007 15:42:38 -0400 Subject: verifying comps In-Reply-To: <1181244612.18723.30.camel@rousalka.dyndns.org> References: <20070607181455.GA6238@ryvius.pekin.waw.pl> <200706071505.56110.jkeating@redhat.com> <1181244612.18723.30.camel@rousalka.dyndns.org> Message-ID: <20070607194238.GB29380@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > How do you determine what is "appropriate" ? Comps lists high level packages, > > not low level deps. > > The best we could do is check every package is reacheable directly or > indirectly from comps I don't think that's really appropriate - not everything makes sense to be there. 'search' is a much better metaphor. Bill From dev at nigelj.com Thu Jun 7 20:20:49 2007 From: dev at nigelj.com (Nigel Jones) Date: Fri, 08 Jun 2007 08:20:49 +1200 Subject: "people wanted to be independent of red hat" ??? In-Reply-To: <46685D16.3050003@leemhuis.info> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <1181163664.2818.20.camel@kennedy> <46678E2C.9000500@leemhuis.info> <46680874.9060600@redhat.com> <46683583.2090804@leemhuis.info> <46683891.4080503@redhat.com> <46683B46.2080209@leemhuis.info> <20070607191318.GE12450@neu.nirvana> <46685D16.3050003@leemhuis.info> Message-ID: <466868A1.2000300@nigelj.com> Thorsten Leemhuis wrote: > On 07.06.2007 21:13, Axel Thimm wrote: >> On Thu, Jun 07, 2007 at 07:07:18PM +0200, Thorsten Leemhuis wrote: >>> On 07.06.2007 18:55, Mike McGrath wrote: >>>>>> We have >>>>>> a current working solution in place right now for this. >>>>> You mean the mailman that runs this list? Or for a >>>>> lists.fedoraproject.org? I'm fine with doing the reorganization on this >>>>> server, but back months ago a lot of people wanted a dedicated server. >>>> Nope, I mean where its hosted now. >>> As I said: I'm fine with continuing to use it. But back earlier this year >>> 1. -- people wanted to get a subdomain with a "list" prefix >> Who are these people? Maybe they should speak up if this is such an >> issue? > > They spoke. It's should be in the archives (December or January iirc) of > fedora-devel somewhere; on fab also. > > The situation in short as far as I remember it: I asked people if they > wanted a list prefix or not. There were people for both camps. Then > someone said: having a "list" in the domainname (such as > lists.fedora-project.org or lists.gnome.org) makes it obvious that you > are writing to a list. Back then that was afaics the solution most > people preferred. My understanding is this can be done without Fedora having their own mailman servers (I believe mailman has settings for this as I seem to recall Wikimedia doing this). N.J. From nphilipp at redhat.com Thu Jun 7 21:18:46 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 07 Jun 2007 23:18:46 +0200 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <200706041415.58247.jkeating@redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <200706041415.58247.jkeating@redhat.com> Message-ID: <1181251126.5206.7.camel@gibraltar.stuttgart.redhat.com> On Mon, 2007-06-04 at 14:15 -0400, Jesse Keating wrote: > On Monday 04 June 2007 13:45:07 Tom "spot" Callaway wrote: > > I thought about this, but it wouldn't ensure proper ordering between > > packages. Packager A rebuilds after Package B is done, but changes to > > Package A affect Package B's build. > > How would a mass rebuild be any different? A mass rebuild is likely to go > through in either ls ordering or python hash ordering.... That needn't be the case. Packages could be built in a "from the ground up" order beginning with what's by default in the buildroots (i.e. what doesn't need to be build-required). This gets only ambiguous with cyclic build-dependencies in which case we'd have to fall back to something else (ls ordering, python hash ordering or even "bug the release engineers and let them decide" ;-)). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From fedora at leemhuis.info Thu Jun 7 20:46:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 07 Jun 2007 22:46:26 +0200 Subject: "people wanted to be independent of red hat" ??? In-Reply-To: <466868A1.2000300@nigelj.com> References: <4666F6AA.6090209@redhat.com> <200706061405.42275.jkeating@redhat.com> <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <1181163664.2818.20.camel@kennedy> <46678E2C.9000500@leemhuis.info> <46680874.9060600@redhat.com> <46683583.2090804@leemhuis.info> <46683891.4080503@redhat.com> <46683B46.2080209@leemhuis.info> <20070607191318.GE12450@neu.nirvana> <46685D16.3050003@leemhuis.info> <466868A1.2000300@nigelj.com> Message-ID: <46686EA2.3090808@leemhuis.info> On 07.06.2007 22:20, Nigel Jones wrote: > Thorsten Leemhuis wrote: >> On 07.06.2007 21:13, Axel Thimm wrote: >>> On Thu, Jun 07, 2007 at 07:07:18PM +0200, Thorsten Leemhuis wrote: >>>> On 07.06.2007 18:55, Mike McGrath wrote: >>>>>>> We have >>>>>>> a current working solution in place right now for this. >>>>>> You mean the mailman that runs this list? Or for a >>>>>> lists.fedoraproject.org? I'm fine with doing the reorganization on this >>>>>> server, but back months ago a lot of people wanted a dedicated server. >>>>> Nope, I mean where its hosted now. >>>> As I said: I'm fine with continuing to use it. But back earlier this year >>>> 1. -- people wanted to get a subdomain with a "list" prefix >>> Who are these people? Maybe they should speak up if this is such an >>> issue? >> They spoke. It's should be in the archives (December or January iirc) of >> fedora-devel somewhere; on fab also. >> >> The situation in short as far as I remember it: I asked people if they >> wanted a list prefix or not. There were people for both camps. Then >> someone said: having a "list" in the domainname (such as >> lists.fedora-project.org or lists.gnome.org) makes it obvious that you >> are writing to a list. Back then that was afaics the solution most >> people preferred. > My understanding is this can be done without Fedora having their own > mailman servers (I believe mailman has settings for this as I seem to > recall Wikimedia doing this). That's my understanding as well. It wasn't me who brought the separate server issue up and I'm totally fine if we continue with the current servers (but it would be really good if mike or someone else has direct access to them). CU knurd From Axel.Thimm at ATrpms.net Thu Jun 7 23:20:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 8 Jun 2007 01:20:49 +0200 Subject: "people wanted to be independent of red hat" ??? In-Reply-To: <46685D16.3050003@leemhuis.info> References: <1181153895.22157.62.camel@localhost.localdomain> <4667054D.4040900@redhat.com> <1181163664.2818.20.camel@kennedy> <46678E2C.9000500@leemhuis.info> <46680874.9060600@redhat.com> <46683583.2090804@leemhuis.info> <46683891.4080503@redhat.com> <46683B46.2080209@leemhuis.info> <20070607191318.GE12450@neu.nirvana> <46685D16.3050003@leemhuis.info> Message-ID: <20070607232049.GL12450@neu.nirvana> On Thu, Jun 07, 2007 at 09:31:34PM +0200, Thorsten Leemhuis wrote: > On 07.06.2007 21:13, Axel Thimm wrote: > > On Thu, Jun 07, 2007 at 07:07:18PM +0200, Thorsten Leemhuis wrote: > >> On 07.06.2007 18:55, Mike McGrath wrote: > >>>>> We have a current working solution in place right now for > >>>>> this. > >> 1. -- people wanted to get a subdomain with a "list" prefix > > Who are these people? Maybe they should speak up if this is such an > > issue? > > They spoke. It's should be in the archives (December or January iirc) of > fedora-devel somewhere; on fab also. If these people still exist and really want that to happen they will reappear, otherwise they probably don't care. > >> 3. -- people wanted to be independent of red hat > > So let's cancel Red Hat's sponsoring and find a new role for Max, Mike > > and all other Fedora dedicated @redhat.com folks. We should also find > > new sponsoring for Red Hat's donated hardware and bandwidth > > resources. ;) > > [...] > > It was not my opinion, I just laid down the opinions that I heard back > then. But you're throwing this as an argument to something which looks like you're backing this up. > The Boards noticed that the mailing lists could needs some > adjustments. They asked me to do that and I said "yes". If you > don't like that contact the board. No, by all means, you should carry on the task. It is a tough job to do a thorough evaluation of topics/target groups and deduce a sane commendation, but where the going gets tough the tough get going. > > I think Warren's "let's just create the new needed lists" attitude is > > far better suited. > > But as I said, some people in important positions blocked it back > then so we never started to use it. Well, maybe these people are the same that you mentioned in 1. above and aren't objecting anymore, so nothing stop us anymore. > But a general "let's just create the new needed lists" attitude just > leads to chaos. Fedora is creative chaos, we wouldn't want it otherwise ;) -- 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 Thu Jun 7 23:21:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 7 Jun 2007 19:21:28 -0400 Subject: use disttag ".1" for devel to avoid confusion (was: Re: Plan for tomorrow's (20070604) Release Engineering meeting) In-Reply-To: <1181251126.5206.7.camel@gibraltar.stuttgart.redhat.com> References: <200706031108.23794.jkeating@redhat.com> <200706041415.58247.jkeating@redhat.com> <1181251126.5206.7.camel@gibraltar.stuttgart.redhat.com> Message-ID: <200706071921.28936.jkeating@redhat.com> On Thursday 07 June 2007 17:18:46 Nils Philippsen wrote: > That needn't be the case. Packages could be built in a "from the ground > up" order beginning with what's by default in the buildroots (i.e. what > doesn't need to be build-required). This gets only ambiguous with cyclic > build-dependencies in which case we'd have to fall back to something > else (ls ordering, python hash ordering or even "bug the release > engineers and let them decide" ;-)). And even then, unless we introduce pauses between each build (to the order of 20~ minutes) we're not really going to make use of those rebuilt packages for later builds. -- 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 Thu Jun 7 23:32:23 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 8 Jun 2007 01:32:23 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1181251126.5206.7.camel@gibraltar.stuttgart.redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <200706041415.58247.jkeating@redhat.com> <1181251126.5206.7.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20070607233223.GM12450@neu.nirvana> On Thu, Jun 07, 2007 at 11:18:46PM +0200, Nils Philippsen wrote: > On Mon, 2007-06-04 at 14:15 -0400, Jesse Keating wrote: > > On Monday 04 June 2007 13:45:07 Tom "spot" Callaway wrote: > > > I thought about this, but it wouldn't ensure proper ordering between > > > packages. Packager A rebuilds after Package B is done, but changes to > > > Package A affect Package B's build. > > > > How would a mass rebuild be any different? A mass rebuild is likely to go > > through in either ls ordering or python hash ordering.... > > That needn't be the case. Packages could be built in a "from the ground > up" order beginning with what's by default in the buildroots (i.e. what > doesn't need to be build-required). This gets only ambiguous with cyclic > build-dependencies in which case we'd have to fall back to something > else (ls ordering, python hash ordering or even "bug the release > engineers and let them decide" ;-)). But Jesse rightfully argues that doing so requires a createrepo running after each build [1], which takes 20-30 minutes. So for 4000 packages you would need 55-83 *days* just for createrepo. Of course this can be sped up, 20-30 minutes sounds like a lot even for a blank non-cached createrepo run. And the repomd data could be optimized in both creating and downloading to only take a tiny fraction of time & bandwidth of what it takes today, so the createrepo command is of the order of seconds instead of minutes. This would also benefit any yum user as a side-effect. But a two-phase rebuild would already cater for most ordering issues anyway, especially when the tree is considered in a good shape. [1] This isn't completely true however, since package N+1 will not always depend on package N, so an intelligent mass-rebuilder could skip a lot of createrepo steps by only issuing a createrepo when really needed. But even if we kill say 3/4 of all createrepo commands we would still spend 2 weeks in createrepo alone. -- 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 dominik at greysector.net Fri Jun 8 00:29:14 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 8 Jun 2007 02:29:14 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070607233223.GM12450@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <200706041415.58247.jkeating@redhat.com> <1181251126.5206.7.camel@gibraltar.stuttgart.redhat.com> <20070607233223.GM12450@neu.nirvana> Message-ID: <20070608002914.GC6898@ryvius.pekin.waw.pl> On Friday, 08 June 2007 at 01:32, Axel Thimm wrote: > On Thu, Jun 07, 2007 at 11:18:46PM +0200, Nils Philippsen wrote: > > On Mon, 2007-06-04 at 14:15 -0400, Jesse Keating wrote: > > > On Monday 04 June 2007 13:45:07 Tom "spot" Callaway wrote: > > > > I thought about this, but it wouldn't ensure proper ordering between > > > > packages. Packager A rebuilds after Package B is done, but changes to > > > > Package A affect Package B's build. > > > > > > How would a mass rebuild be any different? A mass rebuild is likely to go > > > through in either ls ordering or python hash ordering.... > > > > That needn't be the case. Packages could be built in a "from the ground > > up" order beginning with what's by default in the buildroots (i.e. what > > doesn't need to be build-required). This gets only ambiguous with cyclic > > build-dependencies in which case we'd have to fall back to something > > else (ls ordering, python hash ordering or even "bug the release > > engineers and let them decide" ;-)). > > But Jesse rightfully argues that doing so requires a createrepo > running after each build [1], which takes 20-30 minutes. So for 4000 > packages you would need 55-83 *days* just for createrepo. > > Of course this can be sped up, 20-30 minutes sounds like a lot even > for a blank non-cached createrepo run. And the repomd data could be > optimized in both creating and downloading to only take a tiny > fraction of time & bandwidth of what it takes today, so the createrepo > command is of the order of seconds instead of minutes. This would also > benefit any yum user as a side-effect. > > But a two-phase rebuild would already cater for most ordering issues > anyway, especially when the tree is considered in a good shape. > > [1] This isn't completely true however, since package N+1 will not > always depend on package N, so an intelligent mass-rebuilder could > skip a lot of createrepo steps by only issuing a createrepo when > really needed. But even if we kill say 3/4 of all createrepo > commands we would still spend 2 weeks in createrepo alone. We could split the tree into self-contained subtrees and let the build process "see" a repository containing only those packages it needs to build. That'd speed up the metadata regeneration after rebuilds considerably and we'd need only one (or a couple) of full tree metadata rebuilds. 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 mclasen at redhat.com Fri Jun 8 00:55:03 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 07 Jun 2007 20:55:03 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070607233223.GM12450@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <200706041415.58247.jkeating@redhat.com> <1181251126.5206.7.camel@gibraltar.stuttgart.redhat.com> <20070607233223.GM12450@neu.nirvana> Message-ID: <1181264103.4404.1.camel@localhost.localdomain> On Fri, 2007-06-08 at 01:32 +0200, Axel Thimm wrote: > [1] This isn't completely true however, since package N+1 will not > always depend on package N, so an intelligent mass-rebuilder could > skip a lot of createrepo steps by only issuing a createrepo when > really needed. But even if we kill say 3/4 of all createrepo > commands we would still spend 2 weeks in createrepo alone. That would give up one of the main advantages of the current way of doing things, namely that every build takes place in a minimal build root containing only the build requires that the package lists. From dev at nigelj.com Fri Jun 8 05:01:05 2007 From: dev at nigelj.com (Nigel Jones) Date: Fri, 8 Jun 2007 17:01:05 +1200 (NZST) Subject: Adding a note to the package review guidelines Message-ID: <32728.202.74.202.139.1181278865.squirrel@webmail.nigelj.com> I think it'd be a good idea to make a note on the Package Review Guidelines/checklist effectively saying: "Potential reviewers are encouraged to please check that the reportee/submitter of a review request is current in the cvsextras package group before commencing a review" There is a dynamically generated list that I generally work off from admin.fp.o, but I'm sure there is the potential to create a static list (or provide another means to check if a contributor is able to commit their packages to CVS (of course, this wouldn't apply to people that could sponsor someone). I know this would normally go to the fedora-packaging list, but I think this is more of a reminder than policy that should be added. From pertusus at free.fr Fri Jun 8 06:46:17 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 8 Jun 2007 08:46:17 +0200 Subject: Adding a note to the package review guidelines In-Reply-To: <32728.202.74.202.139.1181278865.squirrel@webmail.nigelj.com> References: <32728.202.74.202.139.1181278865.squirrel@webmail.nigelj.com> Message-ID: <20070608064617.GC2846@free.fr> On Fri, Jun 08, 2007 at 05:01:05PM +1200, Nigel Jones wrote: > I think it'd be a good idea to make a note on the Package Review > Guidelines/checklist effectively saying: > > "Potential reviewers are encouraged to please check that the > reportee/submitter of a review request is current in the cvsextras package > group before commencing a review" This is not completely true. A sponsor can approve packages from somebody not in the cvsextras package -- that's how somebody not in this group become part of it, in general. It should block FE-NEEDSPONSOR, however. And a reviewer may well do a review, even a full review of a package proposed by a submitter who is not a contributor already. This could help sponsors. Of course the reviewer should make clear that he isn't a sponsor and can't approve the package. -- Pat From dev at nigelj.com Fri Jun 8 07:54:40 2007 From: dev at nigelj.com (Nigel Jones) Date: Fri, 08 Jun 2007 19:54:40 +1200 Subject: Adding a note to the package review guidelines In-Reply-To: <20070608064617.GC2846@free.fr> References: <32728.202.74.202.139.1181278865.squirrel@webmail.nigelj.com> <20070608064617.GC2846@free.fr> Message-ID: <46690B40.9080507@nigelj.com> Patrice Dumas wrote: > On Fri, Jun 08, 2007 at 05:01:05PM +1200, Nigel Jones wrote: >> I think it'd be a good idea to make a note on the Package Review >> Guidelines/checklist effectively saying: >> >> "Potential reviewers are encouraged to please check that the >> reportee/submitter of a review request is current in the cvsextras package >> group before commencing a review" > > This is not completely true. A sponsor can approve packages from > somebody not in the cvsextras package -- that's how somebody not in this > group become part of it, in general. It should block FE-NEEDSPONSOR, > however. I'm aware of the sponsor process, I wonder if you caught the small bit in brackets "(of course, this wouldn't apply to people that could sponsor someone)". FE-NEEDSPONSOR is a good idea in theory, but it doesn't always work, people make honest mistakes in forgetting to add it other packages they put in for review, or they are not aware they need to do this. Checking against fedoracvs by general maintainers is the only foolproof way. > > And a reviewer may well do a review, even a full review of a package > proposed by a submitter who is not a contributor already. This could > help sponsors. Of course the reviewer should make clear that he isn't a > sponsor and can't approve the package. In which case, the packages are not normally assigned to the person who is providing a pre-review, I'm only suggesting placing a note in the top of the review guidelines reminding people to check that the person that is asking for a review has already been granted fedoracvs before performing a review and granting the fedora-review flag. N.J. From Axel.Thimm at ATrpms.net Fri Jun 8 08:19:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 8 Jun 2007 10:19:43 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1181264103.4404.1.camel@localhost.localdomain> References: <200706031108.23794.jkeating@redhat.com> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <200706041415.58247.jkeating@redhat.com> <1181251126.5206.7.camel@gibraltar.stuttgart.redhat.com> <20070607233223.GM12450@neu.nirvana> <1181264103.4404.1.camel@localhost.localdomain> Message-ID: <20070608081943.GA23703@neu.nirvana> On Thu, Jun 07, 2007 at 08:55:03PM -0400, Matthias Clasen wrote: > On Fri, 2007-06-08 at 01:32 +0200, Axel Thimm wrote: > > > [1] This isn't completely true however, since package N+1 will not > > always depend on package N, so an intelligent mass-rebuilder could > > skip a lot of createrepo steps by only issuing a createrepo when > > really needed. But even if we kill say 3/4 of all createrepo > > commands we would still spend 2 weeks in createrepo alone. > > That would give up one of the main advantages of the current way of > doing things, namely that every build takes place in a minimal build > root containing only the build requires that the package lists. Nobody said that package N would have to be installed, it has to be added to the repo, though if package N+1 BuildRequires it. The minimality of the buildroots remains untouched in any case. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Fri Jun 8 08:58:26 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 8 Jun 2007 10:58:26 +0200 Subject: Adding a note to the package review guidelines In-Reply-To: <46690B40.9080507@nigelj.com> References: <32728.202.74.202.139.1181278865.squirrel@webmail.nigelj.com> <20070608064617.GC2846@free.fr> <46690B40.9080507@nigelj.com> Message-ID: <20070608085721.GB2849@free.fr> On Fri, Jun 08, 2007 at 07:54:40PM +1200, Nigel Jones wrote: > >> "Potential reviewers are encouraged to please check that the > >> reportee/submitter of a review request is current in the cvsextras package > >> group before commencing a review" > I'm aware of the sponsor process, I wonder if you caught the small bit > in brackets "(of course, this wouldn't apply to people that could > sponsor someone)". Ah, ok I missed it. > FE-NEEDSPONSOR is a good idea in theory, but it doesn't always work, > people make honest mistakes in forgetting to add it other packages they > put in for review, or they are not aware they need to do this. Checking > against fedoracvs by general maintainers is the only foolproof way. Indeed. > In which case, the packages are not normally assigned to the person who > is providing a pre-review, I'm only suggesting placing a note in the top > of the review guidelines reminding people to check that the person that > is asking for a review has already been granted fedoracvs before > performing a review and granting the fedora-review flag. Ok, this makes sense. Should say no assign and no grant, but may do an informal review. My fear was that non-sponsors would think they can't do an informal review. -- Pat From mclasen at redhat.com Fri Jun 8 14:12:35 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 08 Jun 2007 10:12:35 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070608081943.GA23703@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <200706041415.58247.jkeating@redhat.com> <1181251126.5206.7.camel@gibraltar.stuttgart.redhat.com> <20070607233223.GM12450@neu.nirvana> <1181264103.4404.1.camel@localhost.localdomain> <20070608081943.GA23703@neu.nirvana> Message-ID: <1181311955.3553.3.camel@dhcp83-186.boston.redhat.com> On Fri, 2007-06-08 at 10:19 +0200, Axel Thimm wrote: > On Thu, Jun 07, 2007 at 08:55:03PM -0400, Matthias Clasen wrote: > > On Fri, 2007-06-08 at 01:32 +0200, Axel Thimm wrote: > > > > > [1] This isn't completely true however, since package N+1 will not > > > always depend on package N, so an intelligent mass-rebuilder could > > > skip a lot of createrepo steps by only issuing a createrepo when > > > really needed. But even if we kill say 3/4 of all createrepo > > > commands we would still spend 2 weeks in createrepo alone. > > > > That would give up one of the main advantages of the current way of > > doing things, namely that every build takes place in a minimal build > > root containing only the build requires that the package lists. > > Nobody said that package N would have to be installed, it has to be > added to the repo, though if package N+1 BuildRequires it. > > The minimality of the buildroots remains untouched in any case. Ah, right. I misread what you said, sorry. From nphilipp at redhat.com Fri Jun 8 16:32:19 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 08 Jun 2007 18:32:19 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <20070607233223.GM12450@neu.nirvana> References: <200706031108.23794.jkeating@redhat.com> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <200706041415.58247.jkeating@redhat.com> <1181251126.5206.7.camel@gibraltar.stuttgart.redhat.com> <20070607233223.GM12450@neu.nirvana> Message-ID: <1181320340.12061.32.camel@gibraltar.stuttgart.redhat.com> On Fri, 2007-06-08 at 01:32 +0200, Axel Thimm wrote: > On Thu, Jun 07, 2007 at 11:18:46PM +0200, Nils Philippsen wrote: > > On Mon, 2007-06-04 at 14:15 -0400, Jesse Keating wrote: > > > On Monday 04 June 2007 13:45:07 Tom "spot" Callaway wrote: > > > > I thought about this, but it wouldn't ensure proper ordering between > > > > packages. Packager A rebuilds after Package B is done, but changes to > > > > Package A affect Package B's build. > > > > > > How would a mass rebuild be any different? A mass rebuild is likely to go > > > through in either ls ordering or python hash ordering.... > > > > That needn't be the case. Packages could be built in a "from the ground > > up" order beginning with what's by default in the buildroots (i.e. what > > doesn't need to be build-required). This gets only ambiguous with cyclic > > build-dependencies in which case we'd have to fall back to something > > else (ls ordering, python hash ordering or even "bug the release > > engineers and let them decide" ;-)). > > But Jesse rightfully argues that doing so requires a createrepo > running after each build [1], which takes 20-30 minutes. So for 4000 > packages you would need 55-83 *days* just for createrepo. Only if you'd do a whole createrepo for each package built. Surely it must be possible to take the existing repo metadata and just update them with that of the newly built package and surely it wouldn't take so much time, right? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From jkeating at redhat.com Fri Jun 8 16:49:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Jun 2007 12:49:19 -0400 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1181320340.12061.32.camel@gibraltar.stuttgart.redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070607233223.GM12450@neu.nirvana> <1181320340.12061.32.camel@gibraltar.stuttgart.redhat.com> Message-ID: <200706081249.22593.jkeating@redhat.com> On Friday 08 June 2007 12:32:19 Nils Philippsen wrote: > Only if you'd do a whole createrepo for each package built. Surely it > must be possible to take the existing repo metadata and just update them > with that of the newly built package and surely it wouldn't take so much > time, right? That would still fill the repodata with older package builds. We /do/ do just an update to the repodata. Some of the pain comes from the hardlinking steps where the latest build of every package is hardlinked into a directory and then createrepo is ran over that. However Jeremy is threatening to create an API for createrepo so that we in koji can just say "here is a list of paths, here is some metadata we already know about these packages in these paths, write out the xml here ->" and significantly speed up the process. -- 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 stickster at gmail.com Fri Jun 8 17:07:43 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 08 Jun 2007 13:07:43 -0400 Subject: JUST DO IT Re: Announcements list for packagers In-Reply-To: <1181134536.464.1.camel@zod.rchland.ibm.com> References: <200706051706.01143.fedora-packaging@dw-perspective.org.uk> <4665C5BD.7000503@redhat.com> <4666337F.3070105@redhat.com> <466634FC.7060908@redhat.com> <1181134536.464.1.camel@zod.rchland.ibm.com> Message-ID: <1181322463.4583.3.camel@localhost.localdomain> On Wed, 2007-06-06 at 07:55 -0500, Josh Boyer wrote: > On Wed, 2007-06-06 at 00:15 -0400, Warren Togami wrote: > > Warren Togami wrote: > > > Christopher Aillon wrote: > > >> David Anderson wrote: > > >>> I'd like to +1 the recent suggestions for a mailing list solely > > >>> dedicated to spreading necessary information to packagers. > > >> > > >> Actually, I thought that was this list. Can we move all the other > > >> discussion to fedora-devel? > > >> > > > > > > This list is supposed to be for discussions. > > > > > > They are asking for a development announcement only list. > > > > Let's make this explicitly clear. > > > > fedora-announce-list > > Project level announcements, news mainly for users. > > > > http://www.redhat.com/mailman/listinfo/fedora-package-announce > > fedora-package-announce > > Subscribe to receive notifications of new/updated packages. > > > > fedora-devel-announce > > Announcements specifically for developers. Stuff like policy, > > infrastructure or tool changes that would be relevant to developers. > > VERY INFREQUENT posts that rise above the difficult to follow bulk of > > the devel/maintainers discussion lists. THIS IS WHAT IS NEEDED. +1 > Make this read-only and have it's Reply-to: set to this list. Then it > might work. > > Otherwise, people will have _more_ discussion on that list for changes > they didn't see coming. +1 -- 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 Axel.Thimm at ATrpms.net Fri Jun 8 17:18:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 8 Jun 2007 19:18:51 +0200 Subject: Plan for tomorrow's (20070604) Release Engineering meeting In-Reply-To: <1181320340.12061.32.camel@gibraltar.stuttgart.redhat.com> References: <200706031108.23794.jkeating@redhat.com> <20070604194503.0939b6c2.bugs.michael@gmx.net> <1180979107.6254.638.camel@localhost.localdomain> <200706041415.58247.jkeating@redhat.com> <1181251126.5206.7.camel@gibraltar.stuttgart.redhat.com> <20070607233223.GM12450@neu.nirvana> <1181320340.12061.32.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20070608171851.GA17010@neu.nirvana> On Fri, Jun 08, 2007 at 06:32:19PM +0200, Nils Philippsen wrote: > On Fri, 2007-06-08 at 01:32 +0200, Axel Thimm wrote: > > On Thu, Jun 07, 2007 at 11:18:46PM +0200, Nils Philippsen wrote: > > > On Mon, 2007-06-04 at 14:15 -0400, Jesse Keating wrote: > > > > On Monday 04 June 2007 13:45:07 Tom "spot" Callaway wrote: > > > > > I thought about this, but it wouldn't ensure proper ordering between > > > > > packages. Packager A rebuilds after Package B is done, but changes to > > > > > Package A affect Package B's build. > > > > > > > > How would a mass rebuild be any different? A mass rebuild is likely to go > > > > through in either ls ordering or python hash ordering.... > > > > > > That needn't be the case. Packages could be built in a "from the ground > > > up" order beginning with what's by default in the buildroots (i.e. what > > > doesn't need to be build-required). This gets only ambiguous with cyclic > > > build-dependencies in which case we'd have to fall back to something > > > else (ls ordering, python hash ordering or even "bug the release > > > engineers and let them decide" ;-)). > > > > But Jesse rightfully argues that doing so requires a createrepo > > running after each build [1], which takes 20-30 minutes. So for 4000 > > packages you would need 55-83 *days* just for createrepo. > > Only if you'd do a whole createrepo for each package built. Surely it > must be possible to take the existing repo metadata and just update them > with that of the newly built package and surely it wouldn't take so much > time, right? There is a patch to do so that doesn't apply anymore to the current createrepo sources. But other than that: The 20-30 required minutes are what the current buildsystem really needs to add a package to pool of BR-available packages, yes. The patch mentioned would certainly help, but I even have the bad feeling that it is already applied to an older createrepo as used by the buildsystem ... :/ -- 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 laroche at redhat.com Sat Jun 9 07:01:54 2007 From: laroche at redhat.com (Florian La Roche) Date: Sat, 9 Jun 2007 09:01:54 +0200 Subject: obsoleted rpm packages that can be blocked Message-ID: <20070609070154.GA17386@dudweiler.stuttgart.redhat.com> Here some obsoleted packages we can block from pushing out: digikamimageplugins-0.9.1-1.fc7.i386.rpm is obsoleted by digikam-0.9.2-0.3.beta3.fc8.i386.rpm digikamimageplugins-doc-0.9.0-1.noarch.rpm is obsoleted by digikam-doc-0.9.2-0.1.beta2.fc8.noarch.rpm evolution-connector-2.11.3.1-1.fc8.i386.rpm is obsoleted by evolution-exchange-2.11.3.1-2.fc8.i386.rpm jaxen-bootstrap-1.1-1jpp.1.fc7.noarch.rpm is obsoleted by jaxen-1.1-1jpp.2.fc7.noarch.rpm openpbx-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-alsa-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-alsa-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-bluetooth-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-bluetooth-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-capi-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-capi-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-devel-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-devel-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-jabber-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-jabber-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-javascript-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-javascript-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-ldap-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-ldap-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-misdn-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-misdn-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-mysql-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-mysql-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-odbc-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-odbc-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-ogi-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-ogi-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-postgresql-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-postgresql-1.2-0.1.rc3.svn2861.fc8.i386.rpm openpbx-zaptel-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by callweaver-zaptel-1.2-0.1.rc3.svn2861.fc8.i386.rpm regards, Florian La Roche From jkeating at redhat.com Sat Jun 9 12:32:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Jun 2007 08:32:37 -0400 Subject: obsoleted rpm packages that can be blocked In-Reply-To: <20070609070154.GA17386@dudweiler.stuttgart.redhat.com> References: <20070609070154.GA17386@dudweiler.stuttgart.redhat.com> Message-ID: <200706090832.37984.jkeating@redhat.com> On Saturday 09 June 2007 03:01:54 Florian La Roche wrote: > Here some obsoleted packages we can block from > pushing out: > > digikamimageplugins-0.9.1-1.fc7.i386.rpm is obsoleted by > digikam-0.9.2-0.3.beta3.fc8.i386.rpm > digikamimageplugins-doc-0.9.0-1.noarch.rpm is obsoleted by > digikam-doc-0.9.2-0.1.beta2.fc8.noarch.rpm > evolution-connector-2.11.3.1-1.fc8.i386.rpm is obsoleted by > evolution-exchange-2.11.3.1-2.fc8.i386.rpm > jaxen-bootstrap-1.1-1jpp.1.fc7.noarch.rpm is obsoleted by > jaxen-1.1-1jpp.2.fc7.noarch.rpm openpbx-1.2-3.rc3.svn2540.fc7.i386.rpm is > obsoleted by callweaver-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-alsa-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-alsa-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-bluetooth-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-bluetooth-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-capi-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-capi-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-devel-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-devel-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-jabber-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-jabber-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-javascript-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-javascript-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-ldap-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-ldap-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-misdn-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-misdn-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-mysql-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-mysql-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-odbc-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-odbc-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-ogi-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-ogi-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-postgresql-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-postgresql-1.2-0.1.rc3.svn2861.fc8.i386.rpm > openpbx-zaptel-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > callweaver-zaptel-1.2-0.1.rc3.svn2861.fc8.i386.rpm While you have this list, can you generate the srpm the obsoleted package comes from, to know if the srpm itself needs to be obsoleted, or just these subpackages? -- 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 lxtnow at gmail.com Sat Jun 9 19:19:10 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Sat, 9 Jun 2007 15:19:10 -0400 Subject: Koji Failed to Build (was: Dependencies missing) Message-ID: <62bc09df0706091219r3316362eyc84e3a0b5d45cc6a@mail.gmail.com> Just re-send my thread cause i found no issue until now to build my package for F-7 branch. my tthread was: ------------------------------------------------------------------------------------------------------------------------------------------------------------- after launched build for F-7 branch, koji reply me an error about missing dependencies "gammu-devel" which i already imported and built on koji. see koji build status page http://koji.fedoraproject.org/koji/buildinfo?buildID=7277 Indeed this package seem do not be yet in F-7 repository. note this package gammu-devel has been built before bodhi has been setting up and announced. ------------------------------------------------------------------------------------------------------------------------------------------------------------- -- Xavier.t Lamien -- French Fedora Ambassador Fedora Extras Contributor GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Iseli at licr.org Sat Jun 9 21:32:56 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 9 Jun 2007 23:32:56 +0200 Subject: verifying comps In-Reply-To: <20070607194238.GB29380@nostromo.devel.redhat.com> References: <20070607181455.GA6238@ryvius.pekin.waw.pl> <200706071505.56110.jkeating@redhat.com> <1181244612.18723.30.camel@rousalka.dyndns.org> <20070607194238.GB29380@nostromo.devel.redhat.com> Message-ID: <20070609233256.0ebaaf3c@ludwig-alpha.unil.ch> On Thu, 7 Jun 2007 15:42:38 -0400, Bill Nottingham wrote: > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > > How do you determine what is "appropriate" ? Comps lists high level packages, > > > not low level deps. > > > > The best we could do is check every package is reacheable directly or > > indirectly from comps > > I don't think that's really appropriate - not everything makes sense > to be there. 'search' is a much better metaphor. Could you elaborate a bit please ? What do you mean by 'search' ? And a metaphor for what ? C From tla at rasmil.dk Sun Jun 10 07:15:54 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Sun, 10 Jun 2007 03:15:54 -0400 Subject: Weird issue in bodhi Message-ID: <466BA52A.50000@rasmil.dk> I am trying to mark the following packages as stable https://admin.fedoraproject.org/updates/testing/F7/yumex-1.9.8-2.0.fc7 But when i press the 'Mark as Stable' link, then i get the following message. Cannot move an update you did not submit Anybody know how to fix it. Tim From sundaram at fedoraproject.org Sun Jun 10 05:18:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 10 Jun 2007 10:48:57 +0530 Subject: Koji Failed to Build (was: Dependencies missing) In-Reply-To: <62bc09df0706091219r3316362eyc84e3a0b5d45cc6a@mail.gmail.com> References: <62bc09df0706091219r3316362eyc84e3a0b5d45cc6a@mail.gmail.com> Message-ID: <466B89C1.8090006@fedoraproject.org> SmootherFrOgZ wrote: > Xavier.t Lamien > -- > French Fedora Ambassador > Fedora Extras Contributor ^^^^^^ Might want to change that. Rahul From jkeating at redhat.com Sun Jun 10 11:56:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 07:56:49 -0400 Subject: Weird issue in bodhi In-Reply-To: <466BA52A.50000@rasmil.dk> References: <466BA52A.50000@rasmil.dk> Message-ID: <200706100756.49759.jkeating@redhat.com> On Sunday 10 June 2007 03:15:54 Tim Lauridsen wrote: > I am trying to mark the following packages as stable > https://admin.fedoraproject.org/updates/testing/F7/yumex-1.9.8-2.0.fc7 > > But when i press the 'Mark as Stable' link, then i get the following > message. > Cannot move an update you did not submit > > Anybody know how to fix it. > Luke glitched something (: I'll mark yous as stable for you. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jun 10 11:58:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Jun 2007 07:58:50 -0400 Subject: Weird issue in bodhi In-Reply-To: <200706100756.49759.jkeating@redhat.com> References: <466BA52A.50000@rasmil.dk> <200706100756.49759.jkeating@redhat.com> Message-ID: <200706100758.50964.jkeating@redhat.com> On Sunday 10 June 2007 07:56:49 Jesse Keating wrote: > On Sunday 10 June 2007 03:15:54 Tim Lauridsen wrote: > > I am trying to mark the following packages as stable > > https://admin.fedoraproject.org/updates/testing/F7/yumex-1.9.8-2.0.fc7 > > > > But when i press the 'Mark as Stable' link, then i get the following > > message. > > Cannot move an update you did not submit > > > > Anybody know how to fix it. > > Luke glitched something (: I'll mark yous as stable for you. Hrm, I noticed that it has an invalid bug number listed. Can you provide me the right bug number and I'll edit it for you (if you're unable 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 tla at rasmil.dk Sun Jun 10 17:38:51 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Sun, 10 Jun 2007 19:38:51 +0200 Subject: Weird issue in bodhi In-Reply-To: <200706100758.50964.jkeating@redhat.com> References: <466BA52A.50000@rasmil.dk> <200706100756.49759.jkeating@redhat.com> <200706100758.50964.jkeating@redhat.com> Message-ID: <466C372B.8050800@rasmil.dk> Jesse Keating wrote: > On Sunday 10 June 2007 07:56:49 Jesse Keating wrote: > >> On Sunday 10 June 2007 03:15:54 Tim Lauridsen wrote: >> >>> I am trying to mark the following packages as stable >>> https://admin.fedoraproject.org/updates/testing/F7/yumex-1.9.8-2.0.fc7 >>> >>> But when i press the 'Mark as Stable' link, then i get the following >>> message. >>> Cannot move an update you did not submit >>> >>> Anybody know how to fix it. >>> >> Luke glitched something (: I'll mark yous as stable for you. >> > > Hrm, I noticed that it has an invalid bug number listed. Can you provide me > the right bug number and I'll edit it for you (if you're unable to) > > The right bugzilla number is 242100 Thanks, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Sun Jun 10 17:48:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 10 Jun 2007 19:48:57 +0200 Subject: EPEL report week 23, 2007 Message-ID: <466C3989.5020607@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week23 = Weekly EPEL Summary = Week 23/2007 == Most important happenings == No major happenings. == EPEL SIG Meeting == === Attending === >From the Steering Committee: * knurd (ThorstenLeemhuis) (partly) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * dgilmore (DennisGilmore) * stahnma (MichaelStahnke) Missing from the Steering Committee: * quiad (KarstenWade) (had fun at the dentist) Others that participated the meeting: Jeff_S, rdieter f13 === Summary === * some discussions about a new meeting time; we'll talk about it when we are full again * repotags -- all; the steering committee talks about it in private currently if and (mainly) how to do them; we mainly need to put in in words * EPEL mock configs in Fedora's mock package; nirik and Jeff_S will look into this over the next few days * comps.xml for EPEL -- dgilmore will get one started; stahnma volunteered to help * bodhi/testing repo/final repo layout -- bodhi needs koji these days, so EPEL needs to switch to koji to use bodhi (which we want for several reasons); dgimore will talk to mbonnet about a timeframe to use koji (which needs adjustments) for EPEL * vacant seat in the steering committee -- Jeff_S self nominated; but we want to solve the repotags issue first (over the next week), and fill the vacant seat afterwards * template for requesting a contributer to get their packages into EPEL -- idea is welcomed, further discussion on the list appreciated === Full meeting log === See https://www.redhat.com/archives/epel-devel-list/2007-June/msg00007.html == Stats == === General === Number of EPEL Contributors 86 We welcome 5 new contributors: devrim_AT_CommandPrompt.com, jbowes_AT_redhat.com, jwboyer_AT_jdub.homelinux.org, mricon_AT_gmail.com, notting_AT_redhat.com === EPEL 5 === Number of source packages: 310 Number of binary packages: 497 There are 36 new Packages: * arp-scan | Scanning and fingerprinting tool * bottlerocket | Utilities to use the FireCracker X10 kit * bugzilla | Bug tracking system * bwidget | Extended widget set for Tk * calcurse | Text-based personal organizer * clearsilver | Fast and powerful HTML templating system * dwatch | A program that watches over other programs * ettercap | Network traffic sniffer/analyser, NCURSES interface version * gammu | Command Line utility to work with mobile phones * gmrun | Lightweight "Run program" dialog box with search history and tab completion * graphviz | Graph Visualization Tools * halberd | Tool to discover HTTP load balancers * jasper | Implementation of the JPEG-2000 standard, Part 1 * mod_fcgid | Apache2 module for high-performance server-side scripting * ncarg | A Fortran and C based software package for scientific visualization * netcdf | Libraries for the Unidata network Common Data Form (NetCDF v3) * onesixtyone | An efficient SNMP scanner * perl-Affix-Infix2Postfix | Perl extension for converting from infix notation to postfix notation * perl-Image-Math-Constrain | Scaling math used in image size constraining (such as thumbnails) * perl-MailTools | Various mail-related perl modules * perl-Math-Base85 | Perl extension for base 85 numbers, as referenced by RFC 1924 * perl-Net-IPv6Addr | Perl module to check validity of IPv6 addresses * perl-Net-Pcap | Interface to pcap(3) LBL packet capture library * perl-Net-Server | Extensible, general Perl server engine * perl-Nmap-Parser | Parse nmap scan data with perl * perl-Proc-Daemon | Run Perl program as a daemon process * php-pear-Net-Ping | Execute ping * php-pear-Net-Traceroute | Execute traceroute * plone | User friendly and powerful open source Content Management System * postgresql-pgpool-II | Pgpool is a connection pooling/replication server for PostgreSQL * remind | A sophisticated calendar and alarm program * trac | Enhanced wiki and issue tracking system * trac-webadmin | Web interface for administration of Trac * vym | View your mind * zope | Web application server for flexible content management applications === EPEL 4 === Number of source packages: 210 Number of binary packages: 392 There are 9 new Packages: * bottlerocket | Utilities to use the FireCracker X10 kit * bwidget | Extended widget set for Tk * calcurse | Text-based personal organizer * clearsilver | Fast and powerful HTML templating system * onesixtyone | An efficient SNMP scanner * perl-MailTools | Various mail-related perl modules * postgresql-pgpool-II | Pgpool is a connection pooling/replication server for PostgreSQL * trac | Enhanced wiki and issue tracking system * trac-webadmin | Web interface for administration of Trac ---- ["CategoryEPELReports"] From lmacken at redhat.com Mon Jun 11 02:37:07 2007 From: lmacken at redhat.com (Luke Macken) Date: Sun, 10 Jun 2007 22:37:07 -0400 Subject: Weird issue in bodhi In-Reply-To: <200706100756.49759.jkeating@redhat.com> References: <466BA52A.50000@rasmil.dk> <200706100756.49759.jkeating@redhat.com> Message-ID: <20070611023707.GB27167@tomservo.rochester.rr.com> On Sun, Jun 10, 2007 at 07:56:49AM -0400, Jesse Keating wrote: > On Sunday 10 June 2007 03:15:54 Tim Lauridsen wrote: > > I am trying to mark the following packages as stable > > https://admin.fedoraproject.org/updates/testing/F7/yumex-1.9.8-2.0.fc7 > > > > But when i press the 'Mark as Stable' link, then i get the following > > message. > > Cannot move an update you did not submit > > > > Anybody know how to fix it. > > > > Luke glitched something (: I'll mark yous as stable for you. I fixed this issue earlier today. luke From notting at redhat.com Mon Jun 11 04:43:59 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 00:43:59 -0400 Subject: verifying comps In-Reply-To: <20070609233256.0ebaaf3c@ludwig-alpha.unil.ch> References: <20070607181455.GA6238@ryvius.pekin.waw.pl> <200706071505.56110.jkeating@redhat.com> <1181244612.18723.30.camel@rousalka.dyndns.org> <20070607194238.GB29380@nostromo.devel.redhat.com> <20070609233256.0ebaaf3c@ludwig-alpha.unil.ch> Message-ID: <20070611044359.GA18869@nostromo.devel.redhat.com> Christian Iseli (Christian.Iseli at licr.org) said: > > > The best we could do is check every package is reacheable directly or > > > indirectly from comps > > > > I don't think that's really appropriate - not everything makes sense > > to be there. 'search' is a much better metaphor. > > Could you elaborate a bit please ? What do you mean by 'search' ? And > a metaphor for what ? If I want to find 'a perl module that deals with timezones', searching is better than scrolling through perl-*. If I want to find 'a library for accessing tiff files', searching is better than scrolling through *-devel. comps just doesn't scale to all 7600 packages... it's *too much data*. Bill From Christian.Iseli at licr.org Mon Jun 11 13:48:20 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 11 Jun 2007 15:48:20 +0200 Subject: verifying comps In-Reply-To: <20070611044359.GA18869@nostromo.devel.redhat.com> References: <20070607181455.GA6238@ryvius.pekin.waw.pl> <200706071505.56110.jkeating@redhat.com> <1181244612.18723.30.camel@rousalka.dyndns.org> <20070607194238.GB29380@nostromo.devel.redhat.com> <20070609233256.0ebaaf3c@ludwig-alpha.unil.ch> <20070611044359.GA18869@nostromo.devel.redhat.com> Message-ID: <20070611154820.1efdbcf1@ludwig-alpha.unil.ch> On Mon, 11 Jun 2007 00:43:59 -0400, Bill Nottingham wrote: > If I want to find 'a perl module that deals with timezones', searching > is better than scrolling through perl-*. > > If I want to find 'a library for accessing tiff files', searching is > better than scrolling through *-devel. > > comps just doesn't scale to all 7600 packages... it's *too much data*. Thanks for explaining. comps is pretty nice to make groups and mark things as base, optional, etc. I agree it doesn't scale too well though. Maybe more groups would be nice but it's really difficult to properly categorize some things. But this issue is pretty orthogonal to the question of whether or not all leaf packages should end up in comps... which is also unresolved yet C From mikeb at redhat.com Mon Jun 11 14:41:37 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 11 Jun 2007 10:41:37 -0400 Subject: Koji Failed to Build (was: Dependencies missing) In-Reply-To: <62bc09df0706091219r3316362eyc84e3a0b5d45cc6a@mail.gmail.com> References: <62bc09df0706091219r3316362eyc84e3a0b5d45cc6a@mail.gmail.com> Message-ID: <1181572897.5233.0.camel@burren.boston.redhat.com> On Sat, 2007-06-09 at 15:19 -0400, SmootherFrOgZ wrote: > Just re-send my thread cause i found no issue until now to build my > package for F-7 branch. > > my tthread was: > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > after launched build for F-7 branch, koji reply me an error about > missing dependencies "gammu-devel" which i already imported and built > on koji. > see koji build status page > http://koji.fedoraproject.org/koji/buildinfo?buildID=7277 > Indeed this package seem do not be yet in F-7 repository. This package won't be available in the repository until it is pushed live using bodhi. > note this package gammu-devel has been built before bodhi has been > setting up and announced. > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > -- > Xavier.t Lamien > -- > French Fedora Ambassador > Fedora Extras Contributor > GPG-Key ID: F3903DEB > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From dwmw2 at infradead.org Mon Jun 11 14:54:05 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 11 Jun 2007 15:54:05 +0100 Subject: obsoleted rpm packages that can be blocked In-Reply-To: <200706090832.37984.jkeating@redhat.com> References: <20070609070154.GA17386@dudweiler.stuttgart.redhat.com> <200706090832.37984.jkeating@redhat.com> Message-ID: <1181573645.25228.2.camel@pmac.infradead.org> On Sat, 2007-06-09 at 08:32 -0400, Jesse Keating wrote: > While you have this list, can you generate the srpm the obsoleted package > comes from, to know if the srpm itself needs to be obsoleted, or just these > subpackages? In the openpbx/callweaver case it's the srpm. -- dwmw2 From laxathom at fedoraproject.org Mon Jun 11 15:04:19 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Mon, 11 Jun 2007 11:04:19 -0400 Subject: Koji Failed to Build (was: Dependencies missing) In-Reply-To: <1181572897.5233.0.camel@burren.boston.redhat.com> References: <62bc09df0706091219r3316362eyc84e3a0b5d45cc6a@mail.gmail.com> <1181572897.5233.0.camel@burren.boston.redhat.com> Message-ID: <62bc09df0706110804m2ca82446sb5e44f9e01ac4199@mail.gmail.com> 2007/6/11, Mike Bonnet : > > On Sat, 2007-06-09 at 15:19 -0400, SmootherFrOgZ wrote: > > Just re-send my thread cause i found no issue until now to build my > > package for F-7 branch. > > > > my tthread was: > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > after launched build for F-7 branch, koji reply me an error about > > missing dependencies "gammu-devel" which i already imported and built > > on koji. > > see koji build status page > > http://koji.fedoraproject.org/koji/buildinfo?buildID=7277 > > Indeed this package seem do not be yet in F-7 repository. > > This package won't be available in the repository until it is pushed > live using bodhi. I've just re-requested them to bodhi. i'll wait. thx > note this package gammu-devel has been built before bodhi has been > > setting up and announced. > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > -- > > Xavier.t Lamien > > -- > > French Fedora Ambassador > > Fedora Extras Contributor > > GPG-Key ID: F3903DEB > > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB > > -- > > Fedora-maintainers mailing list > > Fedora-maintainers at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-maintainers > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From laroche at redhat.com Mon Jun 11 15:17:04 2007 From: laroche at redhat.com (Florian La Roche) Date: Mon, 11 Jun 2007 17:17:04 +0200 Subject: obsoleted rpm packages that can be blocked In-Reply-To: <200706090832.37984.jkeating@redhat.com> References: <20070609070154.GA17386@dudweiler.stuttgart.redhat.com> <200706090832.37984.jkeating@redhat.com> Message-ID: <20070611151704.GA9580@dudweiler.stuttgart.redhat.com> On Sat, Jun 09, 2007 at 08:32:37AM -0400, Jesse Keating wrote: > On Saturday 09 June 2007 03:01:54 Florian La Roche wrote: > > Here some obsoleted packages we can block from > > pushing out: > > > > digikamimageplugins-0.9.1-1.fc7.i386.rpm is obsoleted by > > digikam-0.9.2-0.3.beta3.fc8.i386.rpm > > digikamimageplugins-doc-0.9.0-1.noarch.rpm is obsoleted by > > digikam-doc-0.9.2-0.1.beta2.fc8.noarch.rpm > > evolution-connector-2.11.3.1-1.fc8.i386.rpm is obsoleted by > > evolution-exchange-2.11.3.1-2.fc8.i386.rpm > > jaxen-bootstrap-1.1-1jpp.1.fc7.noarch.rpm is obsoleted by > > jaxen-1.1-1jpp.2.fc7.noarch.rpm openpbx-1.2-3.rc3.svn2540.fc7.i386.rpm is > > obsoleted by callweaver-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-alsa-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-alsa-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-bluetooth-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-bluetooth-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-capi-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-capi-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-devel-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-devel-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-jabber-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-jabber-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-javascript-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-javascript-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-ldap-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-ldap-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-misdn-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-misdn-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-mysql-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-mysql-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-odbc-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-odbc-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-ogi-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-ogi-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-postgresql-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-postgresql-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > openpbx-zaptel-1.2-3.rc3.svn2540.fc7.i386.rpm is obsoleted by > > callweaver-zaptel-1.2-0.1.rc3.svn2861.fc8.i386.rpm > > While you have this list, can you generate the srpm the obsoleted package > comes from, to know if the srpm itself needs to be obsoleted, or just these > subpackages? Hello Jesse, seems like the following srpms should be blocked from being pushed out: - digikamimageplugins-0.9.1-1.fc7.src.rpm - digikamimageplugins-doc-0.9.0-1.src.rpm - evolution-connector-2.11.3.1-1.fc8.src.rpm - openpbx-1.2-3.rc3.svn2540.fc7.src.rpm I'm not sure if jaxen-bootstrap should stay or not. Maybe only the src.rpm, but no binary rpms if this really is for bootstrapping as the name suggests. (Haven't looked at this at all.) regards, Florian La Roche From notting at redhat.com Mon Jun 11 14:40:51 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 10:40:51 -0400 Subject: verifying comps In-Reply-To: <20070611154820.1efdbcf1@ludwig-alpha.unil.ch> References: <20070607181455.GA6238@ryvius.pekin.waw.pl> <200706071505.56110.jkeating@redhat.com> <1181244612.18723.30.camel@rousalka.dyndns.org> <20070607194238.GB29380@nostromo.devel.redhat.com> <20070609233256.0ebaaf3c@ludwig-alpha.unil.ch> <20070611044359.GA18869@nostromo.devel.redhat.com> <20070611154820.1efdbcf1@ludwig-alpha.unil.ch> Message-ID: <20070611144051.GA3882@nostromo.devel.redhat.com> Christian Iseli (Christian.Iseli at licr.org) said: > But this issue is pretty orthogonal to the question of whether or not > all leaf packages should end up in comps... which is also unresolved yet What I'm saying is that trying to include all leaf nodes in comps makes it even less useful (due to the extra noise) for the cases where it doesn't make sense. The other issue is graphical vs. nongraphical apps - is someone really going to fire up pirut (or whatever) to find sox? Or psutils? Bill From wolters.liste at gmx.net Mon Jun 11 15:51:59 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Mon, 11 Jun 2007 17:51:59 +0200 Subject: ntfs-config not signed Message-ID: <200706111752.27601.wolters.liste@gmx.net> See subject - is it better to write a bug report or is a posting here ok enough? Roland -- Let us try to teach generosity and altruism, because we are born selfish. -- Richard Dawkins -------------- 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 Jun 11 16:01:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 12:01:54 -0400 Subject: ntfs-config not signed In-Reply-To: <200706111752.27601.wolters.liste@gmx.net> References: <200706111752.27601.wolters.liste@gmx.net> Message-ID: <200706111201.54268.jkeating@redhat.com> On Monday 11 June 2007 11:51:59 Roland Wolters wrote: > See subject - is it better to write a bug report or is a posting here ok > enough? > > Roland We're working on getting the signed packages in 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 Christian.Iseli at licr.org Mon Jun 11 16:11:14 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 11 Jun 2007 18:11:14 +0200 Subject: verifying comps In-Reply-To: <20070611144051.GA3882@nostromo.devel.redhat.com> References: <20070607181455.GA6238@ryvius.pekin.waw.pl> <200706071505.56110.jkeating@redhat.com> <1181244612.18723.30.camel@rousalka.dyndns.org> <20070607194238.GB29380@nostromo.devel.redhat.com> <20070609233256.0ebaaf3c@ludwig-alpha.unil.ch> <20070611044359.GA18869@nostromo.devel.redhat.com> <20070611154820.1efdbcf1@ludwig-alpha.unil.ch> <20070611144051.GA3882@nostromo.devel.redhat.com> Message-ID: <20070611181114.569e987b@ludwig-alpha.unil.ch> On Mon, 11 Jun 2007 10:40:51 -0400, Bill Nottingham wrote: > What I'm saying is that trying to include all leaf nodes in comps > makes it even less useful (due to the extra noise) for the cases > where it doesn't make sense. I hear you and I'm pretty tempted to agree. The remaining question to solve then is: how do we make sure all the packages that should be listed in comps actually are (and how do we check this) ... > The other issue is graphical vs. nongraphical apps - is someone really > going to fire up pirut (or whatever) to find sox? Or psutils? No idea. I know I won't (but I might have a peek using vi...). C From jkeating at redhat.com Mon Jun 11 16:43:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 12:43:29 -0400 Subject: Plan for Today's (20070611) Release Engineering meeting Message-ID: <200706111243.33320.jkeating@redhat.com> Below you will find a list of topics that we'd like to go over in the next RelEng meeting that is scheduled for Today, Monday at 1700 UTC in #fedora-meeting on irc.freenode.org: /topic RELENG-Meeting - Buildroot contents for updates - JesseKeating /topic RELENG-Meeting - Flesh out SOPs for rel-eng tasks - JesseKeating /topic RELENG-Meeting - Early Torrent Release - RahulSundaram /topic RELENG-Meeting - Upgrade path enforcement - RahulSundaram 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 "Open Discussion" phase. If your name/nick is on above list please update the status on the ReleaseEngineering/Meetings/Agenda page in the wiki ahead of the meeting. That way all the other RelEng members and interested contributors know whats 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... -- 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 Jun 11 17:07:36 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 13:07:36 -0400 Subject: verifying comps In-Reply-To: <20070611181114.569e987b@ludwig-alpha.unil.ch> References: <20070607181455.GA6238@ryvius.pekin.waw.pl> <200706071505.56110.jkeating@redhat.com> <1181244612.18723.30.camel@rousalka.dyndns.org> <20070607194238.GB29380@nostromo.devel.redhat.com> <20070609233256.0ebaaf3c@ludwig-alpha.unil.ch> <20070611044359.GA18869@nostromo.devel.redhat.com> <20070611154820.1efdbcf1@ludwig-alpha.unil.ch> <20070611144051.GA3882@nostromo.devel.redhat.com> <20070611181114.569e987b@ludwig-alpha.unil.ch> Message-ID: <20070611170736.GC3882@nostromo.devel.redhat.com> Christian Iseli (Christian.Iseli at licr.org) said: > On Mon, 11 Jun 2007 10:40:51 -0400, Bill Nottingham wrote: > > What I'm saying is that trying to include all leaf nodes in comps > > makes it even less useful (due to the extra noise) for the cases > > where it doesn't make sense. > > I hear you and I'm pretty tempted to agree. The remaining question to > solve then is: how do we make sure all the packages that should be > listed in comps actually are (and how do we check this) ... Not sure, other than 'make sure maintainers know that they should requrest it be added/add it themselves' when the package gets imported; I did a run-through a few weeks before F7 looking for things that should be in comps. Bill From laxathom at fedoraproject.org Mon Jun 11 17:09:58 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Mon, 11 Jun 2007 13:09:58 -0400 Subject: ntfs-config not signed In-Reply-To: <200706111201.54268.jkeating@redhat.com> References: <200706111752.27601.wolters.liste@gmx.net> <200706111201.54268.jkeating@redhat.com> Message-ID: <62bc09df0706111009t7205cca7v1d9293f7488750bf@mail.gmail.com> On Monday 11 June 2007 11:51:59 Roland Wolters wrote: > > See subject - is it better to write a bug report or is a posting here ok > > enough? > > > > Roland A bug report has already been resquested to my about that. And i already reply that Jessy and other Admin are working to fix this trouble. 2007/6/11, Jesse Keating : | We're working on getting the signed packages in place. > > -- > Jesse Keating > Release Engineer: Fedora > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > > > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor || http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Mon Jun 11 19:33:05 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 11 Jun 2007 11:33:05 -0800 Subject: verifying comps In-Reply-To: <20070611170736.GC3882@nostromo.devel.redhat.com> References: <20070607181455.GA6238@ryvius.pekin.waw.pl> <200706071505.56110.jkeating@redhat.com> <1181244612.18723.30.camel@rousalka.dyndns.org> <20070607194238.GB29380@nostromo.devel.redhat.com> <20070609233256.0ebaaf3c@ludwig-alpha.unil.ch> <20070611044359.GA18869@nostromo.devel.redhat.com> <20070611154820.1efdbcf1@ludwig-alpha.unil.ch> <20070611144051.GA3882@nostromo.devel.redhat.com> <20070611181114.569e987b@ludwig-alpha.unil.ch> <20070611170736.GC3882@nostromo.devel.redhat.com> Message-ID: <604aa7910706111233r4e0f4254qdc3363893c8c9352@mail.gmail.com> On 6/11/07, Bill Nottingham wrote: > Not sure, other than 'make sure maintainers know that they should > requrest it be added/add it themselves' when the package gets imported; > I did a run-through a few weeks before F7 looking for things that > should be in comps. "should be"... that's the 24 thousand dollar question. What was your criteria when you did your run-through? Where you looking for packages with .desktop files? -jef From notting at redhat.com Mon Jun 11 19:38:24 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Jun 2007 15:38:24 -0400 Subject: verifying comps In-Reply-To: <604aa7910706111233r4e0f4254qdc3363893c8c9352@mail.gmail.com> References: <200706071505.56110.jkeating@redhat.com> <1181244612.18723.30.camel@rousalka.dyndns.org> <20070607194238.GB29380@nostromo.devel.redhat.com> <20070609233256.0ebaaf3c@ludwig-alpha.unil.ch> <20070611044359.GA18869@nostromo.devel.redhat.com> <20070611154820.1efdbcf1@ludwig-alpha.unil.ch> <20070611144051.GA3882@nostromo.devel.redhat.com> <20070611181114.569e987b@ludwig-alpha.unil.ch> <20070611170736.GC3882@nostromo.devel.redhat.com> <604aa7910706111233r4e0f4254qdc3363893c8c9352@mail.gmail.com> Message-ID: <20070611193824.GB3888@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > >Not sure, other than 'make sure maintainers know that they should > >requrest it be added/add it themselves' when the package gets imported; > >I did a run-through a few weeks before F7 looking for things that > >should be in comps. > > "should be"... that's the 24 thousand dollar question. What was your > criteria when you did your run-through? Where you looking for packages > with .desktop files? 1. Language-specific stuff that needed thrown in the language groups 2. Apps that either a) are fairly mature in well-understood categories (music players, etc.) or b) are fairly unique (Democracy, moodle) 3. well-known server/web things (mediawiki, Django, gallery2) Not sure there are any real hard and fast rules. Bill From jkeating at redhat.com Mon Jun 11 21:27:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Jun 2007 17:27:22 -0400 Subject: Latest update push failed, updates were rolled back Message-ID: <200706111727.23041.jkeating@redhat.com> Some of you noticed a bit of back/forth with your updates today. The update failed on unsigned packages and the package moves were rolled back until we could resolve it. A good push should happen later today. -- 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 Tue Jun 12 21:26:57 2007 From: jdennis at redhat.com (John Dennis) Date: Tue, 12 Jun 2007 17:26:57 -0400 Subject: Koji login error Message-ID: <1181683618.19325.165.camel@junko.usersys.redhat.com> I get the following error when I attempt to log into Koji using the login link in the upper right corner. To the best of my knowledge ~/.fedora.cert and all all other credentials are valid. Anybody know what might cause this: koji.fedoraproject.org has received an incorrect or unexpected message. Error Code: -12227 -- John Dennis From bugs.michael at gmx.net Tue Jun 12 21:38:57 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 12 Jun 2007 23:38:57 +0200 Subject: Koji login error In-Reply-To: <1181683618.19325.165.camel@junko.usersys.redhat.com> References: <1181683618.19325.165.camel@junko.usersys.redhat.com> Message-ID: <20070612233857.6d9a1cb0.bugs.michael@gmx.net> On Tue, 12 Jun 2007 17:26:57 -0400, John Dennis wrote: > I get the following error when I attempt to log into Koji using the > login link in the upper right corner. To the best of my knowledge > ~/.fedora.cert and all all other credentials are valid. Anybody know > what might cause this: > > koji.fedoraproject.org has received an incorrect or unexpected message. > Error Code: -12227 Have you created and imported a cert into your browser already? From jdennis at redhat.com Tue Jun 12 21:56:41 2007 From: jdennis at redhat.com (John Dennis) Date: Tue, 12 Jun 2007 17:56:41 -0400 Subject: Koji login error In-Reply-To: <20070612233857.6d9a1cb0.bugs.michael@gmx.net> References: <1181683618.19325.165.camel@junko.usersys.redhat.com> <20070612233857.6d9a1cb0.bugs.michael@gmx.net> Message-ID: <1181685401.19325.170.camel@junko.usersys.redhat.com> On Tue, 2007-06-12 at 23:38 +0200, Michael Schwendt wrote: > On Tue, 12 Jun 2007 17:26:57 -0400, John Dennis wrote: > > > I get the following error when I attempt to log into Koji using the > > login link in the upper right corner. To the best of my knowledge > > ~/.fedora.cert and all all other credentials are valid. Anybody know > > what might cause this: > > > > koji.fedoraproject.org has received an incorrect or unexpected message. > > Error Code: -12227 > > Have you created and imported a cert into your browser already? Thank you Michael, that was it, I had forgotten to perform that step on this particular local machine. A more informative error message have allowed me to self correct, hopefully that will get fixed. -- John Dennis From rc040203 at freenet.de Wed Jun 13 00:58:32 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 13 Jun 2007 02:58:32 +0200 Subject: gprolog i386,i486,i586,i686 rpms?!? Message-ID: <1181696312.3233.294.camel@mccallum.corsepiu.local> Hi, The latest bunch of updates came along with this: # ls updates/gprolog-* updates/gprolog-1.3.0-8.fc7.i386.rpm updates/gprolog-docs-1.3.0-8.fc7.i386.rpm updates/gprolog-examples-1.3.0-8.fc7.i386.rpm updates/gprolog-1.3.0-8.fc7.i486.rpm updates/gprolog-docs-1.3.0-8.fc7.i486.rpm updates/gprolog-examples-1.3.0-8.fc7.i486.rpm updates/gprolog-1.3.0-8.fc7.i586.rpm updates/gprolog-docs-1.3.0-8.fc7.i586.rpm updates/gprolog-examples-1.3.0-8.fc7.i586.rpm updates/gprolog-1.3.0-8.fc7.i686.rpm updates/gprolog-docs-1.3.0-8.fc7.i686.rpm updates/gprolog-examples-1.3.0-8.fc7.i686.rpm Could somebody please explain this? Ralf From rdieter at math.unl.edu Wed Jun 13 04:08:20 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 12 Jun 2007 23:08:20 -0500 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <1181696312.3233.294.camel@mccallum.corsepiu.local> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> Message-ID: <466F6DB4.5000701@math.unl.edu> Ralf Corsepius wrote: > The latest bunch of updates came along with this: > > # ls updates/gprolog-* > updates/gprolog-1.3.0-8.fc7.i386.rpm > updates/gprolog-1.3.0-8.fc7.i486.rpm > updates/gprolog-1.3.0-8.fc7.i586.rpm ... > Could somebody please explain this? gprolog.spec includes: ExclusiveArch: %{ix86} and koji at one time expanded this to build for *all* of those archs. That koji bug has been fixed since. Too bad the pkg maintainer didn't notice before pushing the update. (The fix I used in packages of mine that I noticed this was to use ExclusiveArch: i386 instead). -- Rex From adrian at lisas.de Wed Jun 13 06:46:34 2007 From: adrian at lisas.de (Adrian Reber) Date: Wed, 13 Jun 2007 08:46:34 +0200 Subject: Orphaning nexuiz Message-ID: <20070613064634.GA20727@lisas.de> I have not used nexuiz for a long time and I am therefore orphaning nexuiz and nexuiz-data. Adrian From j.w.r.degoede at hhs.nl Wed Jun 13 07:21:01 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 13 Jun 2007 09:21:01 +0200 Subject: Orphaning nexuiz In-Reply-To: <20070613064634.GA20727@lisas.de> References: <20070613064634.GA20727@lisas.de> Message-ID: <466F9ADD.1010201@hhs.nl> Adrian Reber wrote: > I have not used nexuiz for a long time and I am therefore orphaning > nexuiz and nexuiz-data. > Any chance we could get you to reconcider? I'm sure someone of the games SIG will pick it up, but most of us are already handling a pretty heavy load of packages. IMHO not using something yourself is not necessarily a problem when maintaining the package, since the only open nexuiz bug report is a version bump request, I think you've been doing a great job sofar! Trust me I do not daily use all of my 125 + packages, of which 64 games daily. If I would play all those games daily I wouldn't have much time left to even breath :) Regards, Hans From mlichvar at redhat.com Wed Jun 13 08:02:28 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Wed, 13 Jun 2007 10:02:28 +0200 Subject: Orphans: openbox, obconf, obmenu In-Reply-To: <20070605122619.GB5002@localhost> References: <1180819457.27569.16.camel@tuxhugs> <20070605122619.GB5002@localhost> Message-ID: <20070613080228.GD11738@localhost> On Tue, Jun 05, 2007 at 02:26:19PM +0200, Miroslav Lichvar wrote: > On Sat, Jun 02, 2007 at 02:24:17PM -0700, Peter Gordon wrote: > > With the 3.4 Preview releases of Openbox as well as related obconf and > > obmenu releases, I'm officially putting these three packages into Orphan > > status. > > I'm a long time openbox user and I'm willing to take the packages. Ok, no one else has showed interest in maintaining these packages, so I'm taking them. -- Miroslav Lichvar From Axel.Thimm at ATrpms.net Wed Jun 13 08:50:41 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 13 Jun 2007 10:50:41 +0200 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <466F6DB4.5000701@math.unl.edu> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <466F6DB4.5000701@math.unl.edu> Message-ID: <20070613085041.GC13329@neu.nirvana> On Tue, Jun 12, 2007 at 11:08:20PM -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > > The latest bunch of updates came along with this: > > > > # ls updates/gprolog-* > > updates/gprolog-1.3.0-8.fc7.i386.rpm > > updates/gprolog-1.3.0-8.fc7.i486.rpm > > updates/gprolog-1.3.0-8.fc7.i586.rpm > ... > > Could somebody please explain this? > > gprolog.spec includes: > ExclusiveArch: %{ix86} > and koji at one time expanded this to build for *all* of those archs. > That koji bug has been fixed since. Too bad the pkg maintainer didn't > notice before pushing the update. > (The fix I used in packages of mine that I noticed this was to use > ExclusiveArch: i386 > instead). But that breaks when people are building with --target i686 explicitely or implicitely which some downstream may consider (how many times have there been people asking for rebuilding Fedora on i686 ...) Using ExclusiveArch to control the buildsystem is not correct. I wonder how glibc does it. Also ExclusiveArch hacks? Anyway ATM I wouldn't dare suggest a better alternative, let the dust settle first ;) -- 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 limb at jcomserv.net Wed Jun 13 11:45:16 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 13 Jun 2007 06:45:16 -0500 (CDT) Subject: Orphaning nexuiz In-Reply-To: <466F9ADD.1010201@hhs.nl> References: <20070613064634.GA20727@lisas.de> <466F9ADD.1010201@hhs.nl> Message-ID: <19689.65.192.24.164.1181735116.squirrel@mail.jcomserv.net> If Adrian won't reconsider, I will pick it up. > Adrian Reber wrote: >> I have not used nexuiz for a long time and I am therefore orphaning >> nexuiz and nexuiz-data. >> > > Any chance we could get you to reconcider? I'm sure someone of the games > SIG > will pick it up, but most of us are already handling a pretty heavy load > of > packages. > > IMHO not using something yourself is not necessarily a problem when > maintaining > the package, since the only open nexuiz bug report is a version bump > request, I > think you've been doing a great job sofar! > > Trust me I do not daily use all of my 125 + packages, of which 64 games > daily. > If I would play all those games daily I wouldn't have much time left to > even > breath :) > > Regards, > > Hans > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From rdieter at math.unl.edu Wed Jun 13 12:26:08 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 13 Jun 2007 07:26:08 -0500 Subject: gprolog i386,i486,i586,i686 rpms?!? References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <466F6DB4.5000701@math.unl.edu> <20070613085041.GC13329@neu.nirvana> Message-ID: <200706131226.l5DCQ81i012763@mathstat.unl.edu> Axel Thimm wrote: > On Tue, Jun 12, 2007 at 11:08:20PM -0500, Rex Dieter wrote: >> gprolog.spec includes: >> ExclusiveArch: %{ix86} >> and koji at one time expanded this to build for *all* of those archs. >> That koji bug has been fixed since. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Anyway ATM I wouldn't dare suggest a better alternative, let the dust > settle first ;) The dust *has* settled, though that doesn't help with already built, biffed packages. -- Rex From Axel.Thimm at ATrpms.net Wed Jun 13 12:34:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 13 Jun 2007 14:34:32 +0200 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <200706131226.l5DCQ81i012763@mathstat.unl.edu> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <466F6DB4.5000701@math.unl.edu> <20070613085041.GC13329@neu.nirvana> <200706131226.l5DCQ81i012763@mathstat.unl.edu> Message-ID: <20070613123432.GE19588@neu.nirvana> On Wed, Jun 13, 2007 at 07:26:08AM -0500, Rex Dieter wrote: > Axel Thimm wrote: > > > On Tue, Jun 12, 2007 at 11:08:20PM -0500, Rex Dieter wrote: > > >> gprolog.spec includes: > >> ExclusiveArch: %{ix86} > >> and koji at one time expanded this to build for *all* of those archs. > >> That koji bug has been fixed since. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Anyway ATM I wouldn't dare suggest a better alternative, let the dust > > settle first ;) > > The dust *has* settled, though that doesn't help with already built, biffed > packages. I'm not referring to the fixed koji bug, but the ExclusiveArch abuse. Semantically wrong field to embed this information, and this information doesn't belong into specfiles or rpm headers anyway. But let's first get settled with the new tools and suggest improvements later (not that plague did better in this respect). -- 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 Jun 13 13:24:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Jun 2007 09:24:53 -0400 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <20070613123432.GE19588@neu.nirvana> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706131226.l5DCQ81i012763@mathstat.unl.edu> <20070613123432.GE19588@neu.nirvana> Message-ID: <200706130924.53824.jkeating@redhat.com> On Wednesday 13 June 2007 08:34:32 Axel Thimm wrote: > I'm not referring to the fixed koji bug, but the ExclusiveArch > abuse. Semantically wrong field to embed this information, and this > information doesn't belong into specfiles or rpm headers anyway. > > But let's first get settled with the new tools and suggest > improvements later (not that plague did better in this respect). Koji doesn't use this anymore. Koji uses a field in the entry for that package in the database to list the "extra arches" a package should build for. That triggers koji to issue multiple builds of the package when the request comes in, one for each arch listed. Using ExclusiveArch was an attempt at doing away from this manual configuration per package with Extra arches and rely upon information provided by the spec, but it had undesired side-effects. -- 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 Jochen at herr-schmitt.de Wed Jun 13 14:14:41 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 13 Jun 2007 16:14:41 +0200 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <200706130924.53824.jkeating@redhat.com> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706131226.l5DCQ81i012763@mathstat.unl.edu> <20070613123432.GE19588@neu.nirvana> <200706130924.53824.jkeating@redhat.com> Message-ID: <0ML25U-1HyTfb1O46-0006H0@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 13 Jun 2007 09:24:53 -0400, you wrote: >for. That triggers koji to issue multiple builds of the package when the >request comes in, one for each arch listed. Using ExclusiveArch was an >attempt at doing away from this manual configuration per package with Extra >arches and rely upon information provided by the spec, but it had undesired >side-effects. Question: Should I create a updated version of gprolog to solve this issue? Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) Charset: us-ascii wj8DBQFGb/vzT2AHK6txfgwRAi+cAJ9cpNShWeHplZGDSecSAnNJdDRPdACgzG7K d0HU61eGuPx1afS1B2abhOU= =9q38 -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Wed Jun 13 14:01:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 13 Jun 2007 16:01:24 +0200 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <200706130924.53824.jkeating@redhat.com> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706131226.l5DCQ81i012763@mathstat.unl.edu> <20070613123432.GE19588@neu.nirvana> <200706130924.53824.jkeating@redhat.com> Message-ID: <20070613140124.GE27674@neu.nirvana> On Wed, Jun 13, 2007 at 09:24:53AM -0400, Jesse Keating wrote: > On Wednesday 13 June 2007 08:34:32 Axel Thimm wrote: > > I'm not referring to the fixed koji bug, but the ExclusiveArch > > abuse. Semantically wrong field to embed this information, and this > > information doesn't belong into specfiles or rpm headers anyway. > > > > But let's first get settled with the new tools and suggest > > improvements later (not that plague did better in this respect). > > Koji doesn't use this anymore. Koji uses a field in the entry for that > package in the database to list the "extra arches" a package should build > for. That triggers koji to issue multiple builds of the package when the > request comes in, one for each arch listed. Using ExclusiveArch was an > attempt at doing away from this manual configuration per package with Extra > arches and rely upon information provided by the spec, but it had undesired > side-effects. That's wonderful news! If you would also pass over how this is being taught to koji you'd make my day. :) -- 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 Jun 13 15:11:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Jun 2007 11:11:19 -0400 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <20070613140124.GE27674@neu.nirvana> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706130924.53824.jkeating@redhat.com> <20070613140124.GE27674@neu.nirvana> Message-ID: <200706131111.19442.jkeating@redhat.com> On Wednesday 13 June 2007 10:01:24 Axel Thimm wrote: > That's wonderful news! If you would also pass over how this is being > taught to koji you'd make my day. :) Well, it's a simple 'koji set-pkg-arches "" [ ]' I think it requires admin access, not entirely sure. Other than kernel, glibc, openssl, and maybe a few others, what packages need specific say i686 builds? -- 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 ville.skytta at iki.fi Wed Jun 13 15:19:31 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 13 Jun 2007 18:19:31 +0300 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <200706131111.19442.jkeating@redhat.com> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <20070613140124.GE27674@neu.nirvana> <200706131111.19442.jkeating@redhat.com> Message-ID: <200706131819.31349.ville.skytta@iki.fi> On Wednesday 13 June 2007, Jesse Keating wrote: > On Wednesday 13 June 2007 10:01:24 Axel Thimm wrote: > > That's wonderful news! If you would also pass over how this is being > > taught to koji you'd make my day. :) > > Well, it's a simple 'koji set-pkg-arches "" > [ ]' > > I think it requires admin access, not entirely sure. It at least used to. https://bugzilla.redhat.com/239359#c4 > Other than kernel, > glibc, openssl, and maybe a few others, what packages need specific say > i686 builds? All kernel module packages. From jkeating at redhat.com Wed Jun 13 15:25:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Jun 2007 11:25:43 -0400 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <200706131819.31349.ville.skytta@iki.fi> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706131111.19442.jkeating@redhat.com> <200706131819.31349.ville.skytta@iki.fi> Message-ID: <200706131125.43815.jkeating@redhat.com> On Wednesday 13 June 2007 11:19:31 Ville Skytt? wrote: > All kernel module packages. Can you get me list to rel-eng at fedoraproject.org so that we can fix that up? -- 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 qspencer at ieee.org Wed Jun 13 15:49:56 2007 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 13 Jun 2007 10:49:56 -0500 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <200706131111.19442.jkeating@redhat.com> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706130924.53824.jkeating@redhat.com> <20070613140124.GE27674@neu.nirvana> <200706131111.19442.jkeating@redhat.com> Message-ID: <46701224.1000508@ieee.org> Jesse Keating wrote: > On Wednesday 13 June 2007 10:01:24 Axel Thimm wrote: > >> That's wonderful news! If you would also pass over how this is being >> taught to koji you'd make my day. :) >> > > Well, it's a simple 'koji set-pkg-arches "" [ > ]' > > I think it requires admin access, not entirely sure. Other than kernel, > glibc, openssl, and maybe a few others, what packages need specific say i686 > builds? > The atlas package could benefit from this. It provides speed-optimized binary compatible versions of blas and lapack libs. Currently it uses the somewhat ugly solution of creating separate atlas-sse, atlas-3dnow, and atlas-sse2 subpackages. Quentin From jkeating at redhat.com Wed Jun 13 15:57:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Jun 2007 11:57:46 -0400 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <46701224.1000508@ieee.org> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706131111.19442.jkeating@redhat.com> <46701224.1000508@ieee.org> Message-ID: <200706131157.47238.jkeating@redhat.com> On Wednesday 13 June 2007 11:49:56 Quentin Spencer wrote: > The atlas package could benefit from this. It provides speed-optimized > binary compatible versions of blas and lapack libs. Currently it uses > the somewhat ugly solution of creating separate atlas-sse, atlas-3dnow, > and atlas-sse2 subpackages. Can that be encapsulated by an i386 and an i686 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 qspencer at ieee.org Wed Jun 13 15:57:14 2007 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 13 Jun 2007 10:57:14 -0500 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <200706131157.47238.jkeating@redhat.com> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706131111.19442.jkeating@redhat.com> <46701224.1000508@ieee.org> <200706131157.47238.jkeating@redhat.com> Message-ID: <467013DA.4050203@ieee.org> Jesse Keating wrote: > On Wednesday 13 June 2007 11:49:56 Quentin Spencer wrote: > >> The atlas package could benefit from this. It provides speed-optimized >> binary compatible versions of blas and lapack libs. Currently it uses >> the somewhat ugly solution of creating separate atlas-sse, atlas-3dnow, >> and atlas-sse2 subpackages. >> > > Can that be encapsulated by an i386 and an i686 build? > Well, no. I was hoping that the implication of this discussion was that other subarches, such as pentium4, were also supported. Quentin From notting at redhat.com Wed Jun 13 16:31:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 13 Jun 2007 12:31:46 -0400 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <467013DA.4050203@ieee.org> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706131111.19442.jkeating@redhat.com> <46701224.1000508@ieee.org> <200706131157.47238.jkeating@redhat.com> <467013DA.4050203@ieee.org> Message-ID: <20070613163146.GB5724@nostromo.devel.redhat.com> Quentin Spencer (qspencer at ieee.org) said: > Well, no. I was hoping that the implication of this discussion was that > other subarches, such as pentium4, were also supported. Any chance it could check cpu capabilities at runtime and DTRT? Bill From rdieter at math.unl.edu Wed Jun 13 17:32:05 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 13 Jun 2007 12:32:05 -0500 Subject: gprolog i386,i486,i586,i686 rpms?!? References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706131226.l5DCQ81i012763@mathstat.unl.edu> <20070613123432.GE19588@neu.nirvana> <200706130924.53824.jkeating@redhat.com> <0ML25U-1HyTfb1O46-0006H0@mrelayeu.kundenserver.de> Message-ID: <200706131732.l5DHW5EI012212@mathstat.unl.edu> Jochen Schmitt wrote: > Question: > Should I create a updated version of gprolog to solve this issue? That would probably be the best/easiest fix. -- Rex From qspencer at ieee.org Wed Jun 13 17:32:17 2007 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 13 Jun 2007 12:32:17 -0500 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <20070613163146.GB5724@nostromo.devel.redhat.com> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706131111.19442.jkeating@redhat.com> <46701224.1000508@ieee.org> <200706131157.47238.jkeating@redhat.com> <467013DA.4050203@ieee.org> <20070613163146.GB5724@nostromo.devel.redhat.com> Message-ID: <46702A21.4020202@ieee.org> Bill Nottingham wrote: > Quentin Spencer (qspencer at ieee.org) said: > >> Well, no. I was hoping that the implication of this discussion was that >> other subarches, such as pentium4, were also supported. >> > > Any chance it could check cpu capabilities at runtime and DTRT? > Right now, it does do that with the sse2 extensions by putting them in /usr/lib/sse2. I believe if sse2 is supported, the library loader automatically puts /usr/lib/sse2 at the top of the path, so even if the base atlas libs are also installed in /usr/lib, it picks the right ones. However, when I last checked, this isn't necessarily the case for the other subarch-specific extensions, such as sse and 3dnow. For those ones, I also created subdirectories in /usr/lib, but I had to create custom paths in /etc/ld.so.conf.d. It would be nice if all of these were supported, but the other ones are a bit dated and less common now anyway, so it probably doesn't matter too much. Quentin From ville.skytta at iki.fi Wed Jun 13 18:36:19 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 13 Jun 2007 21:36:19 +0300 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <200706131125.43815.jkeating@redhat.com> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706131819.31349.ville.skytta@iki.fi> <200706131125.43815.jkeating@redhat.com> Message-ID: <200706132136.19619.ville.skytta@iki.fi> On Wednesday 13 June 2007, Jesse Keating wrote: > On Wednesday 13 June 2007 11:19:31 Ville Skytt? wrote: > > All kernel module packages. > > Can you get me list to rel-eng at fedoraproject.org so that we can fix that > up? Done, TIA. From lmacken at redhat.com Wed Jun 13 18:54:25 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 13 Jun 2007 14:54:25 -0400 Subject: Orphans: openbox, obconf, obmenu In-Reply-To: <20070613080228.GD11738@localhost> References: <1180819457.27569.16.camel@tuxhugs> <20070605122619.GB5002@localhost> <20070613080228.GD11738@localhost> Message-ID: <20070613185425.GA4557@tomservo.rochester.rr.com> On Wed, Jun 13, 2007 at 10:02:28AM +0200, Miroslav Lichvar wrote: > On Tue, Jun 05, 2007 at 02:26:19PM +0200, Miroslav Lichvar wrote: > > On Sat, Jun 02, 2007 at 02:24:17PM -0700, Peter Gordon wrote: > > > With the 3.4 Preview releases of Openbox as well as related obconf and > > > obmenu releases, I'm officially putting these three packages into Orphan > > > status. > > > > I'm a long time openbox user and I'm willing to take the packages. > > Ok, no one else has showed interest in maintaining these packages, > so I'm taking them. I didn't notice that these were orphaned. I'm a long time openbox user as well. If you would like a co-maintainer, feel free to sign me up. luke From adrian at lisas.de Thu Jun 14 06:36:49 2007 From: adrian at lisas.de (Adrian Reber) Date: Thu, 14 Jun 2007 08:36:49 +0200 Subject: Orphaning nexuiz In-Reply-To: <19689.65.192.24.164.1181735116.squirrel@mail.jcomserv.net> References: <20070613064634.GA20727@lisas.de> <466F9ADD.1010201@hhs.nl> <19689.65.192.24.164.1181735116.squirrel@mail.jcomserv.net> Message-ID: <20070614063648.GA30177@lisas.de> On Wed, Jun 13, 2007 at 06:45:16AM -0500, Jon Ciesla wrote: > If Adrian won't reconsider, I will pick it up. Please take it. Adrian From tibbs at math.uh.edu Thu Jun 14 06:55:46 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Jun 2007 01:55:46 -0500 Subject: Summary of the 2007-06-12 Packaging Committee meeting Message-ID: I must apologize for my terrible lack of punctuality in getting these minutes out; my time has been occupied by work issues the last couple of days. And this is doubly unfortunate, because the OCaml folks have worked are blocked behind the adoption of their guidelines and I'd hate to delay that. Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-06-12 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070612 Executive summary: No votes last week, so no new guidelines this week. Issues pending FESCO ratification: * Minor corrections to the recommended scriptlets: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippetsFixes * Accepted (7 - 0) * OCaml guidelines: http://fedoraproject.org/wiki/PackagingDrafts/OCaml * Accepted (7 - 0) * Revisions to the rule on directory ownership: http://fedoraproject.org/wiki/PackagingDrafts/DirectoryOwnershipImprovement * Accepted (7 - 0) - J< From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jun 14 12:54:44 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 14 Jun 2007 14:54:44 +0200 Subject: Bodhi can push updates with broken dependencies? Message-ID: <20070614145444.41edba9d@python3.es.egwn.lan> Hi, I was wondering... it seems that bodhi can push updates with broken dependencies if I'm not mistaken. The current kernel from "updates" requires the newer mkinitrd which is still in "updates-testing" from what I can see :-/ Almost certainly a known bug or limitation, but just in case... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 0.96 1.47 1.77 From limb at jcomserv.net Thu Jun 14 13:07:58 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 14 Jun 2007 08:07:58 -0500 (CDT) Subject: Orphaning nexuiz In-Reply-To: <20070614063648.GA30177@lisas.de> References: <20070613064634.GA20727@lisas.de> <466F9ADD.1010201@hhs.nl> <19689.65.192.24.164.1181735116.squirrel@mail.jcomserv.net> <20070614063648.GA30177@lisas.de> Message-ID: <11546.65.192.24.164.1181826478.squirrel@mail.jcomserv.net> Ownership change bugs filed and cvs?ed. > On Wed, Jun 13, 2007 at 06:45:16AM -0500, Jon Ciesla wrote: >> If Adrian won't reconsider, I will pick it up. > > Please take it. > > Adrian > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From jkeating at redhat.com Thu Jun 14 13:14:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 09:14:02 -0400 Subject: Bodhi can push updates with broken dependencies? In-Reply-To: <20070614145444.41edba9d@python3.es.egwn.lan> References: <20070614145444.41edba9d@python3.es.egwn.lan> Message-ID: <200706140914.02320.jkeating@redhat.com> On Thursday 14 June 2007 08:54:44 Matthias Saou wrote: > I was wondering... it seems that bodhi can push updates with broken > dependencies if I'm not mistaken. The current kernel from "updates" > requires the newer mkinitrd which is still in "updates-testing" from > what I can see :-/ > > Almost certainly a known bug or limitation, but just in case... It's a current limitation. Repclosure is very slow, especially when you take multilib into account. We'd love to be able to tell when a package is submitted that it will break deps, or when I 'prep' for release that it will break deps, but these are not currently cheap operations. This has to be solved, and I'm not entirely sure how to do this yet, but I'm open for reasonable 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 bugs.michael at gmx.net Thu Jun 14 14:06:36 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 14 Jun 2007 16:06:36 +0200 Subject: Bodhi can push updates with broken dependencies? In-Reply-To: <200706140914.02320.jkeating@redhat.com> References: <20070614145444.41edba9d@python3.es.egwn.lan> <200706140914.02320.jkeating@redhat.com> Message-ID: <20070614160636.042529d5.bugs.michael@gmx.net> On Thu, 14 Jun 2007 09:14:02 -0400, Jesse Keating wrote: > On Thursday 14 June 2007 08:54:44 Matthias Saou wrote: > > I was wondering... it seems that bodhi can push updates with broken > > dependencies if I'm not mistaken. The current kernel from "updates" > > requires the newer mkinitrd which is still in "updates-testing" from > > what I can see :-/ > > > > Almost certainly a known bug or limitation, but just in case... > > It's a current limitation. Repclosure is very slow, especially when you take > multilib into account. Better run it, it takes only 10-15 minutes. And multilib packages should not break so often. In Extras they have lead to a few false positives when somebody released ABI incompatible updates, but no packager has ever complained about that, since usually it is obvious when a broken deps report refers to multilib breakage (e.g. i386.rpm in repo-x86_64). With koji it might even be possible to use some of the package Req/Prov details in the koji database. But until this is implemented and tested, we should reuse existing tools wherever it makes sense. From jkeating at redhat.com Thu Jun 14 14:36:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 10:36:01 -0400 Subject: Bodhi can push updates with broken dependencies? In-Reply-To: <20070614160636.042529d5.bugs.michael@gmx.net> References: <20070614145444.41edba9d@python3.es.egwn.lan> <200706140914.02320.jkeating@redhat.com> <20070614160636.042529d5.bugs.michael@gmx.net> Message-ID: <200706141036.01989.jkeating@redhat.com> On Thursday 14 June 2007 10:06:36 Michael Schwendt wrote: > Better run it, it takes only 10-15 minutes. And multilib packages should > not break so often. In Extras they have lead to a few false positives when > somebody released ABI incompatible updates, but no packager has ever > complained about that, since usually it is obvious when a broken deps > report refers to multilib breakage (e.g. i386.rpm in repo-x86_64). > > With koji it might even be possible to use some of the package Req/Prov > details in the koji database. But until this is implemented and tested, > we should reuse existing tools wherever it makes sense. Unfortunately the existing tools don't mesh well with how we're producing updates now. bodhi adjusts package tags within koji and then we ask mash to do a compose of that tag. This is vastly different than how we did things before and not easy to pause in the middle of it to give the pusher the option to either allow a push to go through with broken deps (getting say a firefox security fix out that may break a few ancillary packages, or a new kernel for security out that may break a few kernel modules), or to roll back the push and uncheck the things that will cause problems. Last time I talked with somebody I don't think koji tracks everything that would be necessary to use it's data for dep checking. -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jun 14 14:43:52 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 14 Jun 2007 16:43:52 +0200 Subject: Bodhi can push updates with broken dependencies? In-Reply-To: <200706141036.01989.jkeating@redhat.com> References: <20070614145444.41edba9d@python3.es.egwn.lan> <200706140914.02320.jkeating@redhat.com> <20070614160636.042529d5.bugs.michael@gmx.net> <200706141036.01989.jkeating@redhat.com> Message-ID: <20070614164352.183f5efd@python3.es.egwn.lan> Jesse Keating wrote : > On Thursday 14 June 2007 10:06:36 Michael Schwendt wrote: > > Better run it, it takes only 10-15 minutes. And multilib packages should > > not break so often. In Extras they have lead to a few false positives when > > somebody released ABI incompatible updates, but no packager has ever > > complained about that, since usually it is obvious when a broken deps > > report refers to multilib breakage (e.g. i386.rpm in repo-x86_64). > > > > With koji it might even be possible to use some of the package Req/Prov > > details in the koji database. But until this is implemented and tested, > > we should reuse existing tools wherever it makes sense. > > Unfortunately the existing tools don't mesh well with how we're producing > updates now. bodhi adjusts package tags within koji and then we ask mash to > do a compose of that tag. This is vastly different than how we did things > before and not easy to pause in the middle of it to give the pusher the > option to either allow a push to go through with broken deps (getting say a > firefox security fix out that may break a few ancillary packages, or a new > kernel for security out that may break a few kernel modules), or to roll back > the push and uncheck the things that will cause problems. > > Last time I talked with somebody I don't think koji tracks everything that > would be necessary to use it's data for dep checking. Well, ultimately it would be best to prevent any kind of breakage, but in the particular case of the updated kernel being pushed without the newer mkinitrd it requires, the check could be much simpler : It wouldn't check the consistency of the entire repo, nor even if the updates pushed would break existing stuff... it would just check if it's not pushing something broken, i.e. check if all requirements of the packages being pushed are met. Not ideal, but maybe quite easy and yet very useful? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 0.09 0.10 0.05 From jkeating at redhat.com Thu Jun 14 14:57:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 10:57:43 -0400 Subject: Bodhi can push updates with broken dependencies? In-Reply-To: <20070614164352.183f5efd@python3.es.egwn.lan> References: <20070614145444.41edba9d@python3.es.egwn.lan> <200706141036.01989.jkeating@redhat.com> <20070614164352.183f5efd@python3.es.egwn.lan> Message-ID: <200706141057.43653.jkeating@redhat.com> On Thursday 14 June 2007 10:43:52 Matthias Saou wrote: > Well, ultimately it would be best to prevent any kind of breakage, but > in the particular case of the updated kernel being pushed without the > newer mkinitrd it requires, the check could be much simpler : It > wouldn't check the consistency of the entire repo, nor even if the > updates pushed would break existing stuff... it would just check if > it's not pushing something broken, i.e. check if all requirements of the > packages being pushed are met. > > Not ideal, but maybe quite easy and yet very useful? But what if the requirements are being met by other things that are set to be pushed? And what if you asked to push something and the requirements were met at that time, but then somebody came along and say unpushed a broken package like mkinitrd, so that the kernel which once WAS satisfied is no longer satisfied? You can't rely upon things at the request for push time, it has to be at the actual 'process this set of requests' time, and it has to take the entire request set into account. -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jun 14 15:31:24 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 14 Jun 2007 17:31:24 +0200 Subject: Bodhi can push updates with broken dependencies? In-Reply-To: <200706141057.43653.jkeating@redhat.com> References: <20070614145444.41edba9d@python3.es.egwn.lan> <200706141036.01989.jkeating@redhat.com> <20070614164352.183f5efd@python3.es.egwn.lan> <200706141057.43653.jkeating@redhat.com> Message-ID: <20070614173124.7bdef939@python3.es.egwn.lan> Jesse Keating wrote : > On Thursday 14 June 2007 10:43:52 Matthias Saou wrote: > > Well, ultimately it would be best to prevent any kind of breakage, but > > in the particular case of the updated kernel being pushed without the > > newer mkinitrd it requires, the check could be much simpler : It > > wouldn't check the consistency of the entire repo, nor even if the > > updates pushed would break existing stuff... it would just check if > > it's not pushing something broken, i.e. check if all requirements of the > > packages being pushed are met. > > > > Not ideal, but maybe quite easy and yet very useful? > > But what if the requirements are being met by other things that are set to be > pushed? And what if you asked to push something and the requirements were > met at that time, but then somebody came along and say unpushed a broken > package like mkinitrd, so that the kernel which once WAS satisfied is no > longer satisfied? You can't rely upon things at the request for push time, > it has to be at the actual 'process this set of requests' time, and it has to > take the entire request set into account. Then it's what Michael said : Run repoclosure. Reliable, but very slow. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 0.02 0.08 0.08 From jkeating at redhat.com Thu Jun 14 15:43:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 11:43:34 -0400 Subject: Bodhi can push updates with broken dependencies? In-Reply-To: <20070614173124.7bdef939@python3.es.egwn.lan> References: <20070614145444.41edba9d@python3.es.egwn.lan> <200706141057.43653.jkeating@redhat.com> <20070614173124.7bdef939@python3.es.egwn.lan> Message-ID: <200706141143.34645.jkeating@redhat.com> On Thursday 14 June 2007 11:31:24 Matthias Saou wrote: > Then it's what Michael said : Run repoclosure. Reliable, but very slow. And difficult to clean up from. We have to "mash" the repos through koji tags, which means tagging the packages, so if there is a broken dep, then there has to be some sort of roll back + remash + re-repoclose. and then locking to make sure that two rel-eng people don't try to do the same updates at the same time (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jun 14 15:53:38 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 14 Jun 2007 17:53:38 +0200 Subject: Bodhi can push updates with broken dependencies? In-Reply-To: <200706141143.34645.jkeating@redhat.com> References: <20070614145444.41edba9d@python3.es.egwn.lan> <200706141057.43653.jkeating@redhat.com> <20070614173124.7bdef939@python3.es.egwn.lan> <200706141143.34645.jkeating@redhat.com> Message-ID: <20070614175338.75e806a1@python3.es.egwn.lan> Jesse Keating wrote : > On Thursday 14 June 2007 11:31:24 Matthias Saou wrote: > > Then it's what Michael said : Run repoclosure. Reliable, but very slow. > > And difficult to clean up from. We have to "mash" the repos through koji > tags, which means tagging the packages, so if there is a broken dep, then > there has to be some sort of roll back + remash + re-repoclose. > > and then locking to make sure that two rel-eng people don't try to do the same > updates at the same time (: "all sorts of fun", it the positive look at it :-D Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7 Load : 0.08 0.21 0.17 From Jochen at herr-schmitt.de Thu Jun 14 16:18:56 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 14 Jun 2007 18:18:56 +0200 Subject: Dependencies issue on the update process Message-ID: <46716A70.6070906@herr-schmitt.de> Hello, unfortunately, the following issue with the update process was rise for me. I'm the maintainer of luma package and one guy has complaint, that luma doesn't work correctly on Fedora 7. (#221167). Now I have found out, that this was raise by the python-ldap-2.0.c package, which is not compatible to Python 2.5 which is installed on Fedora 7. When I installed python-ldap-2.3 luma works fine. Now I want to add a Requires: python-ldap >= 2.3 in my package to make sure, that python-ldap-2.3 will be installed, if any user try to install luma on Fedora 7. Unfortunately, koji doesn't include the update-testing repository for the F-7 update build, so I have waiting until the maintainer of python-ldap will release his package as stable. So I have to create and submit my update request after python-ldap 2.3 will be released as an stable update. I think it will be nice, if we can has any improvement to avoid this kind of bottlelacke. Best Regards: Jochen Schmitt From limb at jcomserv.net Thu Jun 14 16:51:15 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 14 Jun 2007 11:51:15 -0500 (CDT) Subject: Orphaning nexuiz In-Reply-To: <11546.65.192.24.164.1181826478.squirrel@mail.jcomserv.net> References: <20070613064634.GA20727@lisas.de> <466F9ADD.1010201@hhs.nl> <19689.65.192.24.164.1181735116.squirrel@mail.jcomserv.net> <20070614063648.GA30177@lisas.de> <11546.65.192.24.164.1181826478.squirrel@mail.jcomserv.net> Message-ID: <15400.65.192.24.164.1181839875.squirrel@mail.jcomserv.net> Transfer complete. I'll try to get an update out soon, probably no later than next week. > Ownership change bugs filed and cvs?ed. > >> On Wed, Jun 13, 2007 at 06:45:16AM -0500, Jon Ciesla wrote: >>> If Adrian won't reconsider, I will pick it up. >> >> Please take it. >> >> Adrian >> >> -- >> Fedora-maintainers mailing list >> Fedora-maintainers at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-maintainers >> > > > -- > novus ordo absurdum > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From j.w.r.degoede at hhs.nl Thu Jun 14 18:30:28 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 14 Jun 2007 20:30:28 +0200 Subject: Orphaning nexuiz In-Reply-To: <15400.65.192.24.164.1181839875.squirrel@mail.jcomserv.net> References: <20070613064634.GA20727@lisas.de> <466F9ADD.1010201@hhs.nl> <19689.65.192.24.164.1181735116.squirrel@mail.jcomserv.net> <20070614063648.GA30177@lisas.de> <11546.65.192.24.164.1181826478.squirrel@mail.jcomserv.net> <15400.65.192.24.164.1181839875.squirrel@mail.jcomserv.net> Message-ID: <46718944.5020502@hhs.nl> Jon Ciesla wrote: > Transfer complete. I'll try to get an update out soon, probably no later > than next week. > Thank you! Regards, Hans From rdieter at math.unl.edu Thu Jun 14 18:39:05 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Jun 2007 13:39:05 -0500 Subject: Dependencies issue on the update process References: <46716A70.6070906@herr-schmitt.de> Message-ID: <200706141839.l5EId6KQ019362@mathstat.unl.edu> Jochen Schmitt wrote: > Unfortunately, koji doesn't include the update-testing repository for > the F-7 update > build, so I have waiting until the maintainer of python-ldap will > release his package > as stable. No need to wait. python-ldap maintainer (or you?) mails rel-eng at fedoraproject.org asking a particular build be tagged for inclusion the buildroot. fwiw, rel-eng is considering how to make this easier/better. -- Rex From Jochen at herr-schmitt.de Thu Jun 14 18:48:07 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 14 Jun 2007 20:48:07 +0200 Subject: Strange CVS issue Message-ID: <46718D67.80807@herr-schmitt.de> Hello, when I try to commit the last luma changes for F-7, I have got the following error messages: ew revision: 1.6; previous revision: 1.5 done Traceback (most recent call last): File "/cvs/extras/CVSROOT/getnotifylist", line 26, in ? owners = owners.OwnerList(populate_all = 0) File "/cvs/pkgs/CVSROOT/owners.py", line 49, in __init__ self.populate_users() File "/cvs/pkgs/CVSROOT/owners.py", line 64, in populate_users f = urllib2.urlopen("http://app2.fedora.phx.redhat.com/admin/accounts/dump-group.cgi?group=cla_done&format=plain") File "/usr/lib64/python2.3/urllib2.py", line 129, in urlopen return _opener.open(url, data) File "/usr/lib64/python2.3/urllib2.py", line 326, in open '_open', req) File "/usr/lib64/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/lib64/python2.3/urllib2.py", line 901, in http_open return self.do_open(httplib.HTTP, req) File "/usr/lib64/python2.3/urllib2.py", line 886, in do_open raise URLError(err) urllib2.URLError: Running syncmail... Mailing cvsextras at fedora.redhat.com ... ...syncmail done. It this harm anything in the CVS? Best Regards: Jochen Schmitt From Jochen at herr-schmitt.de Thu Jun 14 19:01:41 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 14 Jun 2007 21:01:41 +0200 Subject: Dependencies issue on the update process In-Reply-To: <200706141839.l5EId6KQ019362@mathstat.unl.edu> References: <46716A70.6070906@herr-schmitt.de> <200706141839.l5EId6KQ019362@mathstat.unl.edu> Message-ID: <46719095.8050302@herr-schmitt.de> Rex Dieter schrieb: > python-ldap maintainer (or you?) mails rel-eng at fedoraproject.org asking a > particular build be tagged for inclusion the buildroot. > Thank you for your answer. I saw, that python-ldap-2.3 is now marked as an stable update. Best Regards: Jochen Schmitt From mmcgrath at redhat.com Thu Jun 14 19:32:19 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 14 Jun 2007 14:32:19 -0500 Subject: Strange CVS issue In-Reply-To: <46718D67.80807@herr-schmitt.de> References: <46718D67.80807@herr-schmitt.de> Message-ID: <467197C3.4070001@redhat.com> Jochen Schmitt wrote: > Hello, > > when I try to commit the last luma changes for F-7, I have got the > following > error messages: > > ew revision: 1.6; previous revision: 1.5 > done > Traceback (most recent call last): > File "/cvs/extras/CVSROOT/getnotifylist", line 26, in ? > owners = owners.OwnerList(populate_all = 0) > File "/cvs/pkgs/CVSROOT/owners.py", line 49, in __init__ > self.populate_users() > File "/cvs/pkgs/CVSROOT/owners.py", line 64, in populate_users > f = > urllib2.urlopen("http://app2.fedora.phx.redhat.com/admin/accounts/dump-group.cgi?group=cla_done&format=plain") > > File "/usr/lib64/python2.3/urllib2.py", line 129, in urlopen > return _opener.open(url, data) > File "/usr/lib64/python2.3/urllib2.py", line 326, in open > '_open', req) > File "/usr/lib64/python2.3/urllib2.py", line 306, in _call_chain > result = func(*args) > File "/usr/lib64/python2.3/urllib2.py", line 901, in http_open > return self.do_open(httplib.HTTP, req) > File "/usr/lib64/python2.3/urllib2.py", line 886, in do_open > raise URLError(err) > urllib2.URLError: > Running syncmail... > Mailing cvsextras at fedora.redhat.com ... > ...syncmail done. > > > It this harm anything in the CVS? interesting. Ok. I'm going to look into this, it should be fixed soon anyway. -Mike From lmacken at redhat.com Thu Jun 14 20:24:41 2007 From: lmacken at redhat.com (Luke Macken) Date: Thu, 14 Jun 2007 16:24:41 -0400 Subject: Bodhi can push updates with broken dependencies? In-Reply-To: <200706140914.02320.jkeating@redhat.com> References: <20070614145444.41edba9d@python3.es.egwn.lan> <200706140914.02320.jkeating@redhat.com> Message-ID: <20070614202441.GG4557@tomservo.rochester.rr.com> On Thu, Jun 14, 2007 at 09:14:02AM -0400, Jesse Keating wrote: > On Thursday 14 June 2007 08:54:44 Matthias Saou wrote: > > I was wondering... it seems that bodhi can push updates with broken > > dependencies if I'm not mistaken. The current kernel from "updates" > > requires the newer mkinitrd which is still in "updates-testing" from > > what I can see :-/ > > > > Almost certainly a known bug or limitation, but just in case... > > It's a current limitation. Repclosure is very slow, especially when you take > multilib into account. We'd love to be able to tell when a package is > submitted that it will break deps, or when I 'prep' for release that it will > break deps, but these are not currently cheap operations. This has to be > solved, and I'm not entirely sure how to do this yet, but I'm open for > reasonable suggestions. Bill mentioned doing a mini-rpmdiff at submit time to check the Provides versus previous n-v-rs, then do a quick check of the repo for that. Anyone have any suggestions/comments wrt this approach? luke From jkeating at redhat.com Thu Jun 14 20:30:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 14 Jun 2007 16:30:17 -0400 Subject: Bodhi can push updates with broken dependencies? In-Reply-To: <20070614202441.GG4557@tomservo.rochester.rr.com> References: <20070614145444.41edba9d@python3.es.egwn.lan> <200706140914.02320.jkeating@redhat.com> <20070614202441.GG4557@tomservo.rochester.rr.com> Message-ID: <200706141630.18304.jkeating@redhat.com> On Thursday 14 June 2007 16:24:41 Luke Macken wrote: > Bill mentioned doing a mini-rpmdiff at submit time to check the Provides > versus previous n-v-rs, then do a quick check of the repo for that. > Anyone have any suggestions/comments wrt this approach? Would it be able to take into account /other/ packages in the update queue? -- 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 Jun 14 21:22:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 14 Jun 2007 17:22:46 -0400 Subject: Bodhi can push updates with broken dependencies? In-Reply-To: <200706141630.18304.jkeating@redhat.com> References: <20070614145444.41edba9d@python3.es.egwn.lan> <200706140914.02320.jkeating@redhat.com> <20070614202441.GG4557@tomservo.rochester.rr.com> <200706141630.18304.jkeating@redhat.com> Message-ID: <20070614212246.GB5658@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > On Thursday 14 June 2007 16:24:41 Luke Macken wrote: > > Bill mentioned doing a mini-rpmdiff at submit time to check the Provides > > versus previous n-v-rs, then do a quick check of the repo for that. > > Anyone have any suggestions/comments wrt this approach? > > Would it be able to take into account /other/ packages in the update queue? Not really. However, if each package that breaks deps has a list of deps that it breaks, it should be reasonable for rel-eng to see if those packages have new versions in the pending-for-push pile. Bill From seg at haxxed.com Fri Jun 15 05:15:10 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 15 Jun 2007 00:15:10 -0500 Subject: gprolog i386,i486,i586,i686 rpms?!? In-Reply-To: <200706131111.19442.jkeating@redhat.com> References: <1181696312.3233.294.camel@mccallum.corsepiu.local> <200706130924.53824.jkeating@redhat.com> <20070613140124.GE27674@neu.nirvana> <200706131111.19442.jkeating@redhat.com> Message-ID: <1181884510.15983.35.camel@localhost> On Wed, 2007-06-13 at 11:11 -0400, Jesse Keating wrote: > I think it requires admin access, not entirely sure. Other than kernel, > glibc, openssl, and maybe a few others, what packages need specific say i686 > builds? I'm working on submitting the Second Life viewer, and I wish to compile for -march=pentium2 on i386 so that MMX can potentially be taken advantage of among other things. Its not critical, but Second Life can't be reasonably expected to run on anything less than that, and in fact the official upstream minimum is an 800mhz Pentium III or Athlon, I'd compile for PIII if not for the Athlon T-bird, which doesn't support SSE. http://secondlife.com/corporate/sysreqs.php Is this out of line? Buildarch would be i686, of course. There's that pesky cmov problem with the VIA C3, but I'm doubting anyone would want to run the viewer on one of those... -------------- 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 Jun 15 14:13:48 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Jun 2007 10:13:48 -0400 Subject: Restarting desktop session services on RPM upgrade? Message-ID: <1181916829.19325.278.camel@junko.usersys.redhat.com> We've long had a way to restart system services on an RPM upgrade via condrestart in the initscript. However, there is another kind of service which runs, services bound to desktop sessions. Rather that global, these are per user session. Is there a mechanism by which an RPM which installs a desktop service can perform the equivalent of a condrestart on the session service? I imagine such a mechanism would work by iterating over every DBus session bus, query for the existence of the service, if it exists send it a stop signal and then after the service leaves the bus perform a StartServiceByName within the session. Do we have anything like that? I suspect not. If not then how can a root process iterate over existing sessions? -- John Dennis From hp at redhat.com Fri Jun 15 15:44:55 2007 From: hp at redhat.com (Havoc Pennington) Date: Fri, 15 Jun 2007 11:44:55 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181916829.19325.278.camel@junko.usersys.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> Message-ID: <4672B3F7.4030502@redhat.com> The Mugshot client daemon does this itself by installing a file called "version" with the package version, and if said file changes it restarts itself. The version file doesn't have the RPM release in it, but presumably could. An advantage of this approach is that it doesn't require magic in the spec file, though presumably it has downsides too. One downside is that the restart can be a bit too early (before the upgrade is complete). Havoc From alan at redhat.com Fri Jun 15 15:58:50 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 15 Jun 2007 11:58:50 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <4672B3F7.4030502@redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> Message-ID: <20070615155850.GA15466@devserv.devel.redhat.com> On Fri, Jun 15, 2007 at 11:44:55AM -0400, Havoc Pennington wrote: > The Mugshot client daemon does this itself by installing a file called > "version" with the package version, and if said file changes it restarts > itself. init stats its own binary and librarie (or used to) From jdennis at redhat.com Fri Jun 15 16:11:49 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Jun 2007 12:11:49 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <20070615155850.GA15466@devserv.devel.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <20070615155850.GA15466@devserv.devel.redhat.com> Message-ID: <1181923909.19325.326.camel@junko.usersys.redhat.com> On Fri, 2007-06-15 at 11:58 -0400, Alan Cox wrote: > On Fri, Jun 15, 2007 at 11:44:55AM -0400, Havoc Pennington wrote: > > The Mugshot client daemon does this itself by installing a file called > > "version" with the package version, and if said file changes it restarts > > itself. > > init stats its own binary and librarie (or used to) But that exposes you to a race condition as you don't know when all the files have been upgraded and it requires inefficient periodic polling. -- John Dennis From jdennis at redhat.com Fri Jun 15 16:12:36 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Jun 2007 12:12:36 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <4672B3F7.4030502@redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> Message-ID: <1181923956.19325.328.camel@junko.usersys.redhat.com> On Fri, 2007-06-15 at 11:44 -0400, Havoc Pennington wrote: > The Mugshot client daemon does this itself by installing a file called > "version" with the package version, and if said file changes it restarts > itself. > > The version file doesn't have the RPM release in it, but presumably could. > > An advantage of this approach is that it doesn't require magic in the > spec file, though presumably it has downsides too. One downside is that > the restart can be a bit too early (before the upgrade is complete). Ah yes, the incomplete upgrade race condition problem. This is precisely the problem I'm trying to solve. I had done something similar to what mugshot did except it noticed when a socket was closed and reopened (result of a restart and the newly opened connection reported a different version). The package is divided into independent client and server packages. Client in this case being a desktop session service. The session service notices the upgrade which yum or rpm just finished installing and restarted and then decides to restart itself. But opps! Yum or rpm is now in the middle of updating the code for the desktop session component and the restart generates errors. One has to know to restart the desktop session service only after its files have been upgraded fully, e.g. in %post. Any scheme based on watching other components will expose you to a race condition. >From this I conclude: * There must be some mechanism callable in %post to signal the desktop session service to restart. -OR- * One must let the old desktop session service run until the user logs out and back in again thus restarting it. That might be a very long time and is clearly counter intuitive to someone who just installed an upgrade. Perhaps I've not understood all the issues but it seems to me one is between a rock and a hard place if one wants to do the right thing robustly. -- John Dennis From ssorce at redhat.com Fri Jun 15 17:01:37 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 15 Jun 2007 13:01:37 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181923956.19325.328.camel@junko.usersys.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181923956.19325.328.camel@junko.usersys.redhat.com> Message-ID: <1181926897.4214.14.camel@willson> On Fri, 2007-06-15 at 12:12 -0400, John Dennis wrote: > * There must be some mechanism callable in %post to signal the desktop > session service to restart. Change a file in the post and watch it from userspace with inotify or similar mechanisms. Simo. From walters at redhat.com Fri Jun 15 17:07:30 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 15 Jun 2007 13:07:30 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181923956.19325.328.camel@junko.usersys.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181923956.19325.328.camel@junko.usersys.redhat.com> Message-ID: <1181927250.3348.33.camel@neutron.verbum.private> On Fri, 2007-06-15 at 12:12 -0400, John Dennis wrote: > * There must be some mechanism callable in %post to signal the desktop > session service to restart. It sounds like the Fedora architecture is moving towards everything calling yum-updatesd to do work. In that case, it should be fairly trivial to have yum-updatesd send a D-BUS signal on the system bus when the entire package set installation is complete. This would have the advantage that it avoids problems with interdependent packages being restarted out of sync[1], and you don't have to mess with horror that is RPM spec files[2] and %post for every package. Doing it this way, you then need a nice way to figure out which applications need to be restarted. One possibility is to standardize watching on the mtime of the .desktop file the package installs - though this might interact badly with menu editing, not sure. An alternative would be that the post-installation system sends out signals with the Exec= line of every .desktop file it changed, and then apps have to be modified to catch that signal and restart. Too bad .desktop files don't have a GUID in them =/ Finally, anyone tackling this problem should also think about the issue right now with key library packages like gtk+ being updated for security issues. Say there is a flaw in a pixbuf loader - this potentially affects all applications and thus requires a logout/login. Have some way for the system to handle that (this could just be a different signal that something like puplet catches). [1] An example is the mugshot client and loudmouth libraries being upgraded at the same time - it is key that the client gets restarted using the new loudmouth library. [2] (unprintable) From caillon at redhat.com Fri Jun 15 17:11:54 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 15 Jun 2007 13:11:54 -0400 Subject: Bodhi updates-testing Autopush, Anonymous Commenting In-Reply-To: <46645B98.70001@redhat.com> References: <46645B98.70001@redhat.com> Message-ID: <4672C85A.4060509@redhat.com> Warren Togami wrote: > This thread contains only strawman ideas to solicit ideas and opinions > for Bodhi. > > NOTE: This mail talks only about how updates-testing tickets in bodhi > behave after they become updates-testing. The controversial matter of > whether a package is required to go into updates-testing is a separate > matter to be discussed and ratified during Thursday's FESCo meeting. > > Idea: updates-testing Autopush after Timeout > ============================================ > 1) Bodhi should auto-push updates-testing after a time-out period. No. I want to push out RCs from time to time. I do not ever want an RC to make it out of testing. No matter how long it has been sitting there. > 2) Bodhi interface allows others to comment on the goodness/badness of a > test update. > 3) Bodhi interface allows others to declare a test update broken, which > freezes the auto-push after timeout. > 4) Package maintainer or admins can override this and push anyway. > > Idea: Timeout Default, Configurable? > ==================================== > Default updates-testing timeout is 7 days. Package maintainer may set a > different timeout period (i.e. 4, 9 or 14 days), or turn off the timeout > entirely. Default should be off, IMO. Maintainer should have to set a timeout IMO if they want it. I don't know that in 7 days I will have enough feedback in all cases. Trying to get feedback on a hard-to-reproduce bug might take 8 days. And if I forget to turn off the default timeout, users will get a needless update if the fix doesn't actually work. I am okay with configuring the timeout as long as the default is off. > Idea: Anonymous Commenting > ========================== > Update and updates-testing announcement mail will have links to the > Bodhi ticket where users can comment on their experiences with that > package. This should do good to improve communications between users > and developers, and also be handy for users to know more details about > the effect an updated package will have on their system. > > (Perhaps not a link to the Bodhi ticket, but a separate comment-and-view > URL... lmacken can decide on this as an implementation detail.) > > Currently commenting on an update in bodhi requires you to have a FAS > account, which can be inconvenient for the majority of Fedora users. We > could potentially allow more convenient commenting to the public through > some other means. > > http://en.wikipedia.org/wiki/Captcha > Users not authenticated through FAS are given the option to type in a > CAPTCHA string, which allows them to comment without authenticating. A > CAPTCHA should be sufficient to control spam. Yuck. If we have to do this, please let's not go overboard. http://www.nytimes.com/2007/06/11/technology/11code.html?_r=2&pagewanted=1&oref=slogin Furthermore: Idea: implement some sort of voting mechanism. That way users can simply do a vote for yes or no. (if it needs to have captcha, so be it). Having more than N number of nos might stop the autopush. We should highly encourage comments on "no" votes so we can determine whether to push or not. If after a timeout, all we have are "yes" votes, continue with the autopush if there was one selected before. From nicolas.mailhot at laposte.net Fri Jun 15 17:19:28 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 15 Jun 2007 19:19:28 +0200 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181923956.19325.328.camel@junko.usersys.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181923956.19325.328.camel@junko.usersys.redhat.com> Message-ID: <1181927968.4388.8.camel@rousalka.dyndns.org> Le vendredi 15 juin 2007 ? 12:12 -0400, John Dennis a ?crit : > One has to know to restart the desktop session service only after its > files have been upgraded fully, e.g. in %post. Any scheme based on > watching other components will expose you to a race condition. user starts gnome-terminal user launches a yum update first gui package reaches the %post stage session is restarted gnome-term is killed yum is killed in the middle of an upgrade user system is broken user is angry -- 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 jdennis at redhat.com Fri Jun 15 17:36:45 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Jun 2007 13:36:45 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181927968.4388.8.camel@rousalka.dyndns.org> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181923956.19325.328.camel@junko.usersys.redhat.com> <1181927968.4388.8.camel@rousalka.dyndns.org> Message-ID: <1181929005.19325.373.camel@junko.usersys.redhat.com> On Fri, 2007-06-15 at 19:19 +0200, Nicolas Mailhot wrote: > Le vendredi 15 juin 2007 ? 12:12 -0400, John Dennis a ?crit : > > > One has to know to restart the desktop session service only after its > > files have been upgraded fully, e.g. in %post. Any scheme based on > > watching other components will expose you to a race condition. > > user starts gnome-terminal > user launches a yum update > first gui package reaches the %post stage > session is restarted > gnome-term is killed > yum is killed in the middle of an upgrade > user system is broken > user is angry No, we are not discussing restarting the entire desktop session, that would be a huge problem. We are talking about restarting specific session *services*. -- John Dennis From a.badger at gmail.com Fri Jun 15 20:30:48 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 15 Jun 2007 13:30:48 -0700 Subject: Merging Core and Extras Bugzilla Products -- owners.list Message-ID: <1181939448.28801.106.camel@localhost.localdomain> Hi all, The Fedora Core and Fedora Extras Bugzilla products will be merged into a single Fedora product Sometime Very Soon (TM). When that happens we will have to merge the ownership details in owners.list as well. For most packages, this merge will be a rather humdrum announcement that won't affect you at all. For a few, the packages that were in Fedora Core for some releases and Fedora Extras for some others, the ownership details of the packages will be merged. For instance, these entries for ccid: Fedora Core|ccid|Generic USB CCID smart card reader driver| rrelyea at redhat.com|extras-qa at fedoraproject.org| Fedora Extras|ccid|Generic USB CCID smart card reader driver| ville.skytta at iki.fi|extras-qa at fedoraproject.org| ludovic.rousseau at gmail.com Will be merged into this: Fedora|ccid|Generic USB CCID smart card reader driver| rrelyea at redhat.com,ville.skytta at iki.fi|extras-qa at fedoraproject.org| ludovic.rousseau at gmail.com If you were happy to give up your duties as a maintainer of one of these packages when it shifted repositories before you'll want to take a look at the owners.list file after we announce the Bugzilla Merge has taken place and request cleanups be made where appropriate. Once again, this is just a heads up. We'll be sure to announce the bugzilla and owners.list merge when it actually takes place. 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 mszpak at wp.pl Fri Jun 15 20:31:42 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Fri, 15 Jun 2007 22:31:42 +0200 Subject: How to remove wrong tag in CVS? Message-ID: <4672F72E.3000904@wp.pl> Hi, I tried to update my package and due to old common directory make tagged by devel directory with isomaster-1_0-1_fc7. Later I updated it and the right tag was made, but I have obvious problem with F-7 branch. I tried to remove wrong tag, but without success: [szpak at szpak devel]$ cvs tag -d isomaster-1_0-1_fc7 ERROR: Tag removal not allowed for tag isomaster-1_0-1_fc7 cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! Is it possible to remove that tag? Or I have to bump release number to be able to make F-7 tag? Regards Marcin From otaylor at redhat.com Fri Jun 15 19:57:58 2007 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 15 Jun 2007 15:57:58 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <4672B3F7.4030502@redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> Message-ID: <1181937478.12039.31.camel@fresnel.dumbhippo.com> On Fri, 2007-06-15 at 11:44 -0400, Havoc Pennington wrote: > The Mugshot client daemon does this itself by installing a file called > "version" with the package version, and if said file changes it restarts > itself. > > The version file doesn't have the RPM release in it, but presumably could. > > An advantage of this approach is that it doesn't require magic in the > spec file, though presumably it has downsides too. One downside is that > the restart can be a bit too early (before the upgrade is complete). We changed a while ago so Mugshot no longer installs the version file as a normal file .. instead it's %ghost and the end of the %post does: echo %{version} > %{_datadir}/mugshot/version Now, there are still a downside: you have to wake up to check for an upgrade every so often. If you wake up too often, you drain power. If you wake up less often, it might be a while before you switch versions, so the desktop component needs to be robust against that. (Doesn't try to read a file that gets removed in the newer version, say) For Mugshot, we know when we've told the user to go get a new version, so we check more frequently for a while after that. - Owen From a.badger at gmail.com Fri Jun 15 20:11:52 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 15 Jun 2007 13:11:52 -0700 Subject: Bodhi updates-testing Autopush, Anonymous Commenting In-Reply-To: <4672C85A.4060509@redhat.com> References: <46645B98.70001@redhat.com> <4672C85A.4060509@redhat.com> Message-ID: <1181938312.28801.91.camel@localhost.localdomain> On Fri, 2007-06-15 at 13:11 -0400, Christopher Aillon wrote: > Warren Togami wrote: > > Idea: Timeout Default, Configurable? > > ==================================== > > Default updates-testing timeout is 7 days. Package maintainer may set a > > different timeout period (i.e. 4, 9 or 14 days), or turn off the timeout > > entirely. > > Default should be off, IMO. Maintainer should have to set a timeout IMO > if they want it. I don't know that in 7 days I will have enough > feedback in all cases. Trying to get feedback on a hard-to-reproduce > bug might take 8 days. And if I forget to turn off the default timeout, > users will get a needless update if the fix doesn't actually work. > > I am okay with configuring the timeout as long as the default is off. > I have a different view on this. I would like updates-testing to be strictly for updates that are headed for the repository. As such, there should be no way to disable the timeout on updates-testing. This is to help those users who want to constantly run later packages from the testing repo to run them knowing that they are all candidates for release. Caillon has another valid use case. We've tossed it around before as some kind of sandbox repo. I'd love to see that enabled in addition to updates-testing so that you can push an RC, beta, or maybe-this-fixes-your-bug build to the sandbox; wait for _specific_ feedback that tells you that this build satisfies your criteria for sending out to the rest of the world; and then choose to push to updates-testing if that happens. Basically, I think there's two different audiences and use cases for "I'm pretty sure this is good, let's have people beat on it to make sure" and "this is probably a bad update but I need to have it tested and proven so I know what still needs fixing." The big question is, are we going to see sandbox repos that can enable this? If so, is it something of high or 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 dominik at greysector.net Fri Jun 15 18:11:24 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 15 Jun 2007 20:11:24 +0200 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181929005.19325.373.camel@junko.usersys.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181923956.19325.328.camel@junko.usersys.redhat.com> <1181927968.4388.8.camel@rousalka.dyndns.org> <1181929005.19325.373.camel@junko.usersys.redhat.com> Message-ID: <20070615181124.GA12374@ryvius.pekin.waw.pl> On Friday, 15 June 2007 at 19:36, John Dennis wrote: > On Fri, 2007-06-15 at 19:19 +0200, Nicolas Mailhot wrote: > > Le vendredi 15 juin 2007 ? 12:12 -0400, John Dennis a ?crit : > > > > > One has to know to restart the desktop session service only after its > > > files have been upgraded fully, e.g. in %post. Any scheme based on > > > watching other components will expose you to a race condition. > > > > user starts gnome-terminal > > user launches a yum update > > first gui package reaches the %post stage > > session is restarted > > gnome-term is killed > > yum is killed in the middle of an upgrade > > user system is broken > > user is angry > > No, we are not discussing restarting the entire desktop session, that > would be a huge problem. We are talking about restarting specific > session *services*. It did happen at some point in FC6 though. When updating from fresh install to (then) current updates-released. Regards, R. -- Fedora 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 buildsys at fedoraproject.org Fri Jun 15 18:22:23 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 15 Jun 2007 14:22:23 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-06-15 Message-ID: <20070615182223.8E941152131@buildsys.fedoraproject.org> andy AT smile.org.ua: jack-audio-connection-kit FE6 > F7 (0:0.103.0-1.fc6 > 0:0.102.20-4.fc7) bjohnson AT symetrix.com: gscan2pdf FE5 > F7 (0:0.9.10-2.fc5 > 0:0.9.9-3.fc7) FE6 > F7 (0:0.9.10-2.fc6 > 0:0.9.9-3.fc7) cgoorah AT yahoo.com.au: crystal FE5 > F7 (0:1.0.4-1.fc5 > 0:1.0.3-1.fc7) FE6 > F7 (0:1.0.4-1.fc6 > 0:1.0.3-1.fc7) kmenu-gnome FE5 > F7 (0:0.6.5-2.fc5 > 0:0.6.3-1.fc7) FE6 > F7 (0:0.6.5-2.fc6 > 0:0.6.3-1.fc7) kshutdown FE5 > F7 (0:1.0-3.fc5 > 0:1.0-2.fc7) FE6 > F7 (0:1.0-3.fc6 > 0:1.0-2.fc7) chris.stone AT gmail.com: php-pear-HTTP-Request FE5 > F7 (0:1.4.1-1.fc5 > 0:1.4.0-1.fc7) FE6 > F7 (0:1.4.1-1.fc6 > 0:1.4.0-1.fc7) cweyl AT alumni.drew.edu: perl-Algorithm-C3 FE5 > F7 (0:0.07-1.fc5 > 0:0.06-1.fc7) FE6 > F7 (0:0.07-1.fc6 > 0:0.06-1.fc7) perl-CGI-Ex FE5 > F7 (0:2.13-1.fc5 > 0:2.12-1.fc7) FE6 > F7 (0:2.13-1.fc6 > 0:2.12-1.fc7) perl-Class-C3 FE5 > F7 (0:0.18-1.fc5 > 0:0.14-1.fc6) FE6 > F7 (0:0.18-1.fc6 > 0:0.14-1.fc6) perl-Class-C3-XS FE5 > F7 (0:0.06-1.fc5 > 0:0.04-1.fc7) FE6 > F7 (0:0.06-1.fc6 > 0:0.04-1.fc7) perl-Class-Data-Accessor FE5 > F7 (0:0.04001-1.fc5 > 0:0.04000-3.fc7) FE6 > F7 (0:0.04001-1.fc6 > 0:0.04000-3.fc7) perl-Class-MOP FE5 > F7 (0:0.38-1.fc5 > 0:0.37-1.fc7) FE6 > F7 (0:0.38-1.fc6 > 0:0.37-1.fc7) perl-Data-Alias FE5 > F7 (0:1.05-1.fc5 > 0:1.04-1.fc7) FE6 > F7 (0:1.05-1.fc6 > 0:1.04-1.fc7) perl-Event FE6 > F7 (0:1.09-1.fc6 > 0:1.08-1.fc7) perl-Gtk2-Notify FE6 > F7 (0:0.03-1.fc6 > 0:0.02-4.fc7) perl-Gtk2-TrayIcon FE5 > F7 (0:0.06-1.fc5 > 0:0.03-3.fc6) FE6 > F7 (0:0.06-1.fc6 > 0:0.03-3.fc6) perl-JSON-XS FE5 > F7 (0:1.22-1.fc5 > 0:1.21-3.fc7) FE6 > F7 (0:1.22-1.fc6 > 0:1.21-3.fc7) perl-Moose FE5 > F7 (0:0.22-1.fc5 > 0:0.21-1.fc7) FE6 > F7 (0:0.22-1.fc6 > 0:0.21-1.fc7) perl-POE-Component-Server-SOAP FE5 > F7 (0:1.11-1.fc5 > 0:1.10-1.fc6) FE6 > F7 (0:1.11-1.fc6 > 0:1.10-1.fc6) perl-POE-Component-SimpleDBI FE5 > F7 (0:1.16-1.fc5 > 0:1.15-1.fc6) FE6 > F7 (0:1.16-1.fc6 > 0:1.15-1.fc6) perl-POE-Component-SSLify FE5 > F7 (0:0.08-1.fc5 > 0:0.07-1.fc7) FE6 > F7 (0:0.08-1.fc6 > 0:0.07-1.fc7) perl-Sub-Exporter FE5 > F7 (0:0.974-1.fc5 > 0:0.972-1.fc7) FE6 > F7 (0:0.974-1.fc6 > 0:0.972-1.fc7) dakingun AT gmail.com: texmaker FE5 > F7 (1:1.5-2.fc5 > 1:1.5-1.fc7) FE6 > F7 (1:1.5-2.fc6 > 1:1.5-1.fc7) devrim AT commandprompt.com: phpPgAdmin FE5 > F7 (0:4.1.2-1.fc5 > 0:4.1.1-1.fc7) FE6 > F7 (0:4.1.2-1.fc6 > 0:4.1.1-1.fc7) python-psycopg2 FE5 > F7 (0:2.0.6-1.fc5 > 0:2.0.5.1-8.fc7) FE6 > F7 (0:2.0.6-1.fc6 > 0:2.0.5.1-8.fc7) dm AT mensa.se: initng FE6 > F7 (0:0.6.10.1-1.fc6 > 0:0.6.10-2.fc7) initng-ifiles FE6 > F7 (0:0.1.3-1.fc6 > 0:0.1.2-1.fc7) dmitry AT butskoy.name: freetds FE6 > F7-updates-testing (0:0.64-6.fc6 > 0:0.64-5.fc7) drzeus-bugzilla AT drzeus.cx: pulseaudio FE5 > F7 (0:0.9.6-2.fc5 > 0:0.9.5-5.fc7) FE6 > F7 (0:0.9.6-2.fc6 > 0:0.9.5-5.fc7) enrico.scholz AT informatik.tu-chemnitz.de: libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-1.fc6 > 0:0.30.212-3.fc7) xmlrpc-c FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.14-1.fc6 > 0:1.06.11-2.fc7) fedora-packaging AT dw-perspective.org.uk: bibletime FE6 > F7 (0:1.6.4-2.fc6 > 0:1.6.3b-3.fc7) foolish AT guezz.net: gtranslator FE6 > F7 (0:1.1.7-3.fc6 > 0:1.1.7-2.fc7) gemi AT bluewin.ch: ocaml FE6 > F7 (0:3.09.3-2.fc6 > 0:3.09.3-1.fc7) ianburrell AT gmail.com: perl-Module-Depends FE5 > F7 (0:0.12-1.fc5 > 0:0.10-2.fc7) FE6 > F7 (0:0.12-1.fc6 > 0:0.10-2.fc7) perl-SVN-Mirror FE5 > F7 (0:0.73-1.fc5 > 0:0.72-1.fc7) FE6 > F7 (0:0.73-1.fc6 > 0:0.72-1.fc7) jeff AT ocjtech.us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) jkeating AT redhat.com: iscsi-initiator-utils FC6-updates > F7 (0:6.2.0.865-0.0.fc6 > 0:6.2.0.754-0.0.fc7) jpo AT di.uminho.pt: perl-Test-WWW-Mechanize FE6 > F7 (0:1.14-1.fc6 > 0:1.12-1.fc6) lemenkov AT gmail.com: fuse FE5 > F7 (0:2.6.5-2.fc5 > 0:2.6.5-1.fc7) FE6 > F7 (0:2.6.5-2.fc6 > 0:2.6.5-1.fc7) lists AT forevermore.net: dar FE6 > F7 (0:2.3.3-1.fc6 > 0:2.3.1-4.fc7) rsnapshot FE6 > F7 (0:1.3.0-1.fc6 > 0:1.2.9-5.fc6) sec FE6 > F7 (0:2.4.1-1.fc6 > 0:2.4.0-1.fc7) luya_tfz AT thefinalzone.com: gdesklets FE6 > F7-updates (0:0.35.4-6.1.fc6 > 0:0.35.4-6.fc7) matthias AT rpmforge.net: easytag FE6 > F7 (0:2.1-1.fc6 > 0:2.0.1-1.fc7) starfighter FE5 > F7 (0:1.1-9.fc5 > 0:1.1-8.fc6) FE6 > F7 (0:1.1-9.fc6 > 0:1.1-8.fc6) viruskiller FE5 > F7 (0:1.0-4.fc5 > 0:1.0-3.fc7) FE6 > F7 (0:1.0-4.fc6 > 0:1.0-3.fc7) mbacovsk AT redhat.com: file FC5-updates > F7 (0:4.21-1.fc5 > 0:4.20-1.fc7) FC6-updates > F7 (0:4.21-1.fc6 > 0:4.20-1.fc7) quagga FC6-updates > F7 (0:0.99.7-1.fc6 > 0:0.99.6-1.fc7) meme AT daughtersoftiresias.org: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-2.fc6 > 0:2.1.1-2.fc6) mikeb AT redhat.com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) mmcgrath AT redhat.com: perl-File-RsyncP FE6 > F7 (0:0.68-1.fc6 > 0:0.62-3.fc6) nhorman AT redhat.com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) ovasik AT redhat.com: taskjuggler FE6 > F7 (0:2.3.1-2.fc6 > 0:2.3.1-1.fc7) pawsa AT theochem.kth.se: balsa FE5 > FE6 (0:2.3.16-3.fc5 > 0:2.3.16-2.fc6) FE5 > F7 (0:2.3.16-3.fc5 > 0:2.3.14-1.fc7) FE6 > F7 (0:2.3.16-2.fc6 > 0:2.3.14-1.fc7) pmejzlik AT redhat.com: docbook-utils FC6-updates > F7 (0:0.6.14-8.fc6 > 0:0.6.14-5.1) rc040203 AT freenet.de: perl-Params-Util FE5 > F7 (0:0.25-1.fc5 > 0:0.24-1.fc7) FE6 > F7 (0:0.25-1.fc6 > 0:0.24-1.fc7) rdieter AT math.unl.edu: maxima FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) ryo-dairiki AT users.sourceforge.net: VLGothic-fonts FE5 > F7 (0:20070507-1.fc5 > 0:20070328-1.fc7) FE6 > F7 (0:20070507-1.fc6 > 0:20070328-1.fc7) seg AT haxxed.com: rosegarden4 FE5 > F7 (0:1.5.1-1.fc5 > 0:1.4.0-1.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.4.0-1.fc7) splinux AT fedoraproject.org: libgtksourceviewmm FE6 > F7 (0:0.3.1-1.fc6 > 0:0.3.0-2.fc7) spr AT astrax.fis.ucm.es: funtools FE5 > FE6 (0:1.3.0-0.5.b33.fc5 > 0:1.3.0-0.4.b29.fc6) ssorce AT redhat.com: samba FC5-updates > FC6-updates (0:3.0.24-7.fc5 > 0:3.0.24-5.fc6) ---------------------------------------------------------------------- balsa: pawsa AT theochem.kth.se FE5 > FE6 (0:2.3.16-3.fc5 > 0:2.3.16-2.fc6) FE5 > F7 (0:2.3.16-3.fc5 > 0:2.3.14-1.fc7) FE6 > F7 (0:2.3.16-2.fc6 > 0:2.3.14-1.fc7) bibletime: fedora-packaging AT dw-perspective.org.uk FE6 > F7 (0:1.6.4-2.fc6 > 0:1.6.3b-3.fc7) crystal: cgoorah AT yahoo.com.au FE5 > F7 (0:1.0.4-1.fc5 > 0:1.0.3-1.fc7) FE6 > F7 (0:1.0.4-1.fc6 > 0:1.0.3-1.fc7) dar: lists AT forevermore.net FE6 > F7 (0:2.3.3-1.fc6 > 0:2.3.1-4.fc7) docbook-utils: pmejzlik AT redhat.com FC6-updates > F7 (0:0.6.14-8.fc6 > 0:0.6.14-5.1) easytag: matthias AT rpmforge.net FE6 > F7 (0:2.1-1.fc6 > 0:2.0.1-1.fc7) file: mbacovsk AT redhat.com FC5-updates > F7 (0:4.21-1.fc5 > 0:4.20-1.fc7) FC6-updates > F7 (0:4.21-1.fc6 > 0:4.20-1.fc7) fortune-firefly: meme AT daughtersoftiresias.org FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-2.fc6 > 0:2.1.1-2.fc6) freetds: dmitry AT butskoy.name FE6 > F7-updates-testing (0:0.64-6.fc6 > 0:0.64-5.fc7) funtools: spr AT astrax.fis.ucm.es FE5 > FE6 (0:1.3.0-0.5.b33.fc5 > 0:1.3.0-0.4.b29.fc6) fuse: lemenkov AT gmail.com FE5 > F7 (0:2.6.5-2.fc5 > 0:2.6.5-1.fc7) FE6 > F7 (0:2.6.5-2.fc6 > 0:2.6.5-1.fc7) gdesklets: luya_tfz AT thefinalzone.com FE6 > F7-updates (0:0.35.4-6.1.fc6 > 0:0.35.4-6.fc7) gscan2pdf: bjohnson AT symetrix.com FE5 > F7 (0:0.9.10-2.fc5 > 0:0.9.9-3.fc7) FE6 > F7 (0:0.9.10-2.fc6 > 0:0.9.9-3.fc7) gtranslator: foolish AT guezz.net FE6 > F7 (0:1.1.7-3.fc6 > 0:1.1.7-2.fc7) initng: dm AT mensa.se FE6 > F7 (0:0.6.10.1-1.fc6 > 0:0.6.10-2.fc7) initng-ifiles: dm AT mensa.se FE6 > F7 (0:0.1.3-1.fc6 > 0:0.1.2-1.fc7) irqbalance: nhorman AT redhat.com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) iscsi-initiator-utils: jkeating AT redhat.com FC6-updates > F7 (0:6.2.0.865-0.0.fc6 > 0:6.2.0.754-0.0.fc7) jack-audio-connection-kit: andy AT smile.org.ua FE6 > F7 (0:0.103.0-1.fc6 > 0:0.102.20-4.fc7) jrtplib: jeff AT ocjtech.us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kmenu-gnome: cgoorah AT yahoo.com.au FE5 > F7 (0:0.6.5-2.fc5 > 0:0.6.3-1.fc7) FE6 > F7 (0:0.6.5-2.fc6 > 0:0.6.3-1.fc7) kshutdown: cgoorah AT yahoo.com.au FE5 > F7 (0:1.0-3.fc5 > 0:1.0-2.fc7) FE6 > F7 (0:1.0-3.fc6 > 0:1.0-2.fc7) libgtksourceviewmm: splinux AT fedoraproject.org FE6 > F7 (0:0.3.1-1.fc6 > 0:0.3.0-2.fc7) libtasn1: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) maxima: rdieter AT math.unl.edu FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) mimetic: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) ocaml: gemi AT bluewin.ch FE6 > F7 (0:3.09.3-2.fc6 > 0:3.09.3-1.fc7) perl-Algorithm-C3: cweyl AT alumni.drew.edu FE5 > F7 (0:0.07-1.fc5 > 0:0.06-1.fc7) FE6 > F7 (0:0.07-1.fc6 > 0:0.06-1.fc7) perl-CGI-Ex: cweyl AT alumni.drew.edu FE5 > F7 (0:2.13-1.fc5 > 0:2.12-1.fc7) FE6 > F7 (0:2.13-1.fc6 > 0:2.12-1.fc7) perl-Class-C3: cweyl AT alumni.drew.edu FE5 > F7 (0:0.18-1.fc5 > 0:0.14-1.fc6) FE6 > F7 (0:0.18-1.fc6 > 0:0.14-1.fc6) perl-Class-C3-XS: cweyl AT alumni.drew.edu FE5 > F7 (0:0.06-1.fc5 > 0:0.04-1.fc7) FE6 > F7 (0:0.06-1.fc6 > 0:0.04-1.fc7) perl-Class-Data-Accessor: cweyl AT alumni.drew.edu FE5 > F7 (0:0.04001-1.fc5 > 0:0.04000-3.fc7) FE6 > F7 (0:0.04001-1.fc6 > 0:0.04000-3.fc7) perl-Class-MOP: cweyl AT alumni.drew.edu FE5 > F7 (0:0.38-1.fc5 > 0:0.37-1.fc7) FE6 > F7 (0:0.38-1.fc6 > 0:0.37-1.fc7) perl-Data-Alias: cweyl AT alumni.drew.edu FE5 > F7 (0:1.05-1.fc5 > 0:1.04-1.fc7) FE6 > F7 (0:1.05-1.fc6 > 0:1.04-1.fc7) perl-Event: cweyl AT alumni.drew.edu FE6 > F7 (0:1.09-1.fc6 > 0:1.08-1.fc7) perl-File-RsyncP: mmcgrath AT redhat.com FE6 > F7 (0:0.68-1.fc6 > 0:0.62-3.fc6) perl-Gtk2-Notify: cweyl AT alumni.drew.edu FE6 > F7 (0:0.03-1.fc6 > 0:0.02-4.fc7) perl-Gtk2-TrayIcon: cweyl AT alumni.drew.edu FE5 > F7 (0:0.06-1.fc5 > 0:0.03-3.fc6) FE6 > F7 (0:0.06-1.fc6 > 0:0.03-3.fc6) perl-JSON-XS: cweyl AT alumni.drew.edu FE5 > F7 (0:1.22-1.fc5 > 0:1.21-3.fc7) FE6 > F7 (0:1.22-1.fc6 > 0:1.21-3.fc7) perl-Module-Depends: ianburrell AT gmail.com FE5 > F7 (0:0.12-1.fc5 > 0:0.10-2.fc7) FE6 > F7 (0:0.12-1.fc6 > 0:0.10-2.fc7) perl-Moose: cweyl AT alumni.drew.edu FE5 > F7 (0:0.22-1.fc5 > 0:0.21-1.fc7) FE6 > F7 (0:0.22-1.fc6 > 0:0.21-1.fc7) perl-Params-Util: rc040203 AT freenet.de FE5 > F7 (0:0.25-1.fc5 > 0:0.24-1.fc7) FE6 > F7 (0:0.25-1.fc6 > 0:0.24-1.fc7) perl-POE-Component-Server-SOAP: cweyl AT alumni.drew.edu FE5 > F7 (0:1.11-1.fc5 > 0:1.10-1.fc6) FE6 > F7 (0:1.11-1.fc6 > 0:1.10-1.fc6) perl-POE-Component-SimpleDBI: cweyl AT alumni.drew.edu FE5 > F7 (0:1.16-1.fc5 > 0:1.15-1.fc6) FE6 > F7 (0:1.16-1.fc6 > 0:1.15-1.fc6) perl-POE-Component-SSLify: cweyl AT alumni.drew.edu FE5 > F7 (0:0.08-1.fc5 > 0:0.07-1.fc7) FE6 > F7 (0:0.08-1.fc6 > 0:0.07-1.fc7) perl-Sub-Exporter: cweyl AT alumni.drew.edu FE5 > F7 (0:0.974-1.fc5 > 0:0.972-1.fc7) FE6 > F7 (0:0.974-1.fc6 > 0:0.972-1.fc7) perl-SVN-Mirror: ianburrell AT gmail.com FE5 > F7 (0:0.73-1.fc5 > 0:0.72-1.fc7) FE6 > F7 (0:0.73-1.fc6 > 0:0.72-1.fc7) perl-Test-WWW-Mechanize: jpo AT di.uminho.pt FE6 > F7 (0:1.14-1.fc6 > 0:1.12-1.fc6) php-pear-HTTP-Request: chris.stone AT gmail.com FE5 > F7 (0:1.4.1-1.fc5 > 0:1.4.0-1.fc7) FE6 > F7 (0:1.4.1-1.fc6 > 0:1.4.0-1.fc7) phpPgAdmin: devrim AT commandprompt.com FE5 > F7 (0:4.1.2-1.fc5 > 0:4.1.1-1.fc7) FE6 > F7 (0:4.1.2-1.fc6 > 0:4.1.1-1.fc7) pulseaudio: drzeus-bugzilla AT drzeus.cx FE5 > F7 (0:0.9.6-2.fc5 > 0:0.9.5-5.fc7) FE6 > F7 (0:0.9.6-2.fc6 > 0:0.9.5-5.fc7) python-cheetah: mikeb AT redhat.com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-psycopg2: devrim AT commandprompt.com FE5 > F7 (0:2.0.6-1.fc5 > 0:2.0.5.1-8.fc7) FE6 > F7 (0:2.0.6-1.fc6 > 0:2.0.5.1-8.fc7) quagga: mbacovsk AT redhat.com FC6-updates > F7 (0:0.99.7-1.fc6 > 0:0.99.6-1.fc7) rosegarden4: seg AT haxxed.com FE5 > F7 (0:1.5.1-1.fc5 > 0:1.4.0-1.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.4.0-1.fc7) rsnapshot: lists AT forevermore.net FE6 > F7 (0:1.3.0-1.fc6 > 0:1.2.9-5.fc6) samba: ssorce AT redhat.com FC5-updates > FC6-updates (0:3.0.24-7.fc5 > 0:3.0.24-5.fc6) sec: lists AT forevermore.net FE6 > F7 (0:2.4.1-1.fc6 > 0:2.4.0-1.fc7) starfighter: matthias AT rpmforge.net FE5 > F7 (0:1.1-9.fc5 > 0:1.1-8.fc6) FE6 > F7 (0:1.1-9.fc6 > 0:1.1-8.fc6) taskjuggler: ovasik AT redhat.com FE6 > F7 (0:2.3.1-2.fc6 > 0:2.3.1-1.fc7) texmaker: dakingun AT gmail.com FE5 > F7 (1:1.5-2.fc5 > 1:1.5-1.fc7) FE6 > F7 (1:1.5-2.fc6 > 1:1.5-1.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.213-1.fc6 > 0:0.30.212-3.fc7) viruskiller: matthias AT rpmforge.net FE5 > F7 (0:1.0-4.fc5 > 0:1.0-3.fc7) FE6 > F7 (0:1.0-4.fc6 > 0:1.0-3.fc7) VLGothic-fonts: ryo-dairiki AT users.sourceforge.net FE5 > F7 (0:20070507-1.fc5 > 0:20070328-1.fc7) FE6 > F7 (0:20070507-1.fc6 > 0:20070328-1.fc7) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:1.06.14-1.fc5 > 0:1.06.11-2.fc7) FE6 > F7 (0:1.06.14-1.fc6 > 0:1.06.11-2.fc7) From rstrode at redhat.com Fri Jun 15 20:57:20 2007 From: rstrode at redhat.com (Ray Strode) Date: Fri, 15 Jun 2007 16:57:20 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181937478.12039.31.camel@fresnel.dumbhippo.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181937478.12039.31.camel@fresnel.dumbhippo.com> Message-ID: <1181941040.2567.5.camel@halflap.boston.devel.redhat.com> Hi, > echo %{version} > %{_datadir}/mugshot/version > > Now, there are still a downside: you have to wake up to check for an > upgrade every so often. If you wake up too often, you drain power. > If you wake up less often, it might be a while before you switch > versions, so the desktop component needs to be robust against that. Why aren't you just watching the file with inotify or gamin or whatever? --Ray From jspaleta at gmail.com Fri Jun 15 21:10:53 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 15 Jun 2007 13:10:53 -0800 Subject: Bodhi updates-testing Autopush, Anonymous Commenting In-Reply-To: <1181938312.28801.91.camel@localhost.localdomain> References: <46645B98.70001@redhat.com> <4672C85A.4060509@redhat.com> <1181938312.28801.91.camel@localhost.localdomain> Message-ID: <604aa7910706151410y118843ct47383c436bd3ec29@mail.gmail.com> On 6/15/07, Toshio Kuratomi wrote: > Basically, I think there's two different audiences and use cases for > "I'm pretty sure this is good, let's have people beat on it to make > sure" and "this is probably a bad update but I need to have it tested > and proven so I know what still needs fixing." > > The big question is, are we going to see sandbox repos that can enable > this? If so, is it something of high or low priority? These sandbox repos you want to see sound a lot like repos that have appeared sporadically in people.redhat.com on a per maintainer basis. Here's the problem with sandbox repos... how do I as a willing consumer discover which sandboxes exist at any given moment in time? Testing-updates already suffer from a discoverability penalty, even with the repository definition included but disabled in client systems. If maintainers are counting on my reading through the flood of the test mailinglist to notice that a sandbox has gone up... you can forget it happening reliably. And bugzilla only guarantees you that the people watching specific bugs gets a notice... but for rc releases you may need to cast a wider net than that looking for regressions...especially hardware specific regressions. If maintainers can't reliably tell people like me about sandbox creation so I can eat the rc packages.. then there's no bloody point in wasting the time letting this crap sit in a sandbox, collecting moss. Moss covered shards of broken glass still hurt when eaten, only difference is they are deceptively soft looking. I am concerned that the sandbox concept maybe defining usage cases too narrowly compared to size of the testing audience who are consuming any testing packages at all. Do we have stats on the consumption of testing-updates referenced to the consumption of released updates? -jef"uses test updates hoping to see a package result in a kitten maiming"spaleta From caillon at redhat.com Fri Jun 15 21:23:02 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 15 Jun 2007 17:23:02 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181937478.12039.31.camel@fresnel.dumbhippo.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181937478.12039.31.camel@fresnel.dumbhippo.com> Message-ID: <46730336.40903@redhat.com> Owen Taylor wrote: > On Fri, 2007-06-15 at 11:44 -0400, Havoc Pennington wrote: >> The Mugshot client daemon does this itself by installing a file called >> "version" with the package version, and if said file changes it restarts >> itself. >> >> The version file doesn't have the RPM release in it, but presumably could. >> >> An advantage of this approach is that it doesn't require magic in the >> spec file, though presumably it has downsides too. One downside is that >> the restart can be a bit too early (before the upgrade is complete). > > We changed a while ago so Mugshot no longer installs the version file as > a normal file .. instead it's %ghost and the end of the %post does: > > echo %{version} > %{_datadir}/mugshot/version > > Now, there are still a downside: you have to wake up to check for an > upgrade every so often. If you wake up too often, you drain power. > If you wake up less often, it might be a while before you switch > versions, so the desktop component needs to be robust against that. > > (Doesn't try to read a file that gets removed in the newer version, say) > > For Mugshot, we know when we've told the user to go get a new version, > so we check more frequently for a while after that. I have actually been wanting to do this for Firefox, as the /usr/lib/firefox-x.y directory changes. I've pondered having the %postun script check to check $1 == 1 or something to see if it was an upgrade, and if so call dbus-send to firefox on the system bus (which firefox would listen to) to load a webpage telling the user they need to restart the browser. From bugs.michael at gmx.net Fri Jun 15 22:15:26 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 16 Jun 2007 00:15:26 +0200 Subject: Package EVR problems in Fedora 2007-06-15 In-Reply-To: <20070615182223.8E941152131@buildsys.fedoraproject.org> References: <20070615182223.8E941152131@buildsys.fedoraproject.org> Message-ID: <20070616001526.ea9b0b04.bugs.michael@gmx.net> On Fri, 15 Jun 2007 14:22:23 -0400 (EDT), buildsys fedoraproject org wrote a long list of broken upgrade path problems. -snip- I've forked the script to create one that sends these issues to the package owners, co-owners and Cc. Have fun with the extra spam. ;) From jkeating at redhat.com Fri Jun 15 22:15:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 15 Jun 2007 18:15:25 -0400 Subject: Bodhi updates-testing Autopush, Anonymous Commenting In-Reply-To: <1181938312.28801.91.camel@localhost.localdomain> References: <46645B98.70001@redhat.com> <4672C85A.4060509@redhat.com> <1181938312.28801.91.camel@localhost.localdomain> Message-ID: <200706151815.25891.jkeating@redhat.com> On Friday 15 June 2007 16:11:52 Toshio Kuratomi wrote: > Caillon has another valid use case. ?We've tossed it around before as > some kind of sandbox repo. ?I'd love to see that enabled in addition to > updates-testing so that you can push an RC, beta, or > maybe-this-fixes-your-bug build to the sandbox; wait for _specific_ > feedback that tells you that this build satisfies your criteria for > sending out to the rest of the world; and then choose to push to > updates-testing if that happens. Wouldn't the public koji build suffice for this? Drop comments in a bug report with the url to the package in koji? I've even toyed with some of the UI you could do in hte Makefiles so that when you make the build, if successful it would automatically comment in the bug number you provided to look at the koji 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 notting at redhat.com Fri Jun 15 22:20:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 15 Jun 2007 18:20:42 -0400 Subject: Bodhi updates-testing Autopush, Anonymous Commenting In-Reply-To: <1181938312.28801.91.camel@localhost.localdomain> References: <46645B98.70001@redhat.com> <4672C85A.4060509@redhat.com> <1181938312.28801.91.camel@localhost.localdomain> Message-ID: <20070615222042.GA17783@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > The big question is, are we going to see sandbox repos that can enable > this? If so, is it something of high or low priority? Note that for *true* one-off sandboxing, there's always scratch build or not-pushed build, downloaded via the koji web interface. Bill From belegdol at gmail.com Sat Jun 16 00:56:46 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sat, 16 Jun 2007 01:56:46 +0100 Subject: How to remove wrong tag in CVS? In-Reply-To: <4672F72E.3000904@wp.pl> References: <4672F72E.3000904@wp.pl> Message-ID: <9b1b20e70706151756u21689c12m7e8bc7e960ec4187@mail.gmail.com> 2007/6/15, Marcin Zaj?czkowski : > Hi, > > > I tried to update my package and due to old common directory make tagged > by devel directory with isomaster-1_0-1_fc7. Later I updated it and the > right tag was made, but I have obvious problem with F-7 branch. > I tried to remove wrong tag, but without success: > > [szpak at szpak devel]$ cvs tag -d isomaster-1_0-1_fc7 > ERROR: Tag removal not allowed for tag isomaster-1_0-1_fc7 > cvs tag: Pre-tag check failed > cvs [tag aborted]: correct the above errors first! > > > Is it possible to remove that tag? > Or I have to bump release number to be able to make F-7 tag? > > > Regards > Marcin > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > IIRC it was possible with TAG_OPTS= -R or sth like that. Take a look at cvsadminprocedure wiki page. From caillon at redhat.com Sat Jun 16 03:22:06 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 15 Jun 2007 23:22:06 -0400 Subject: Bodhi updates-testing Autopush, Anonymous Commenting In-Reply-To: <1181938312.28801.91.camel@localhost.localdomain> References: <46645B98.70001@redhat.com> <4672C85A.4060509@redhat.com> <1181938312.28801.91.camel@localhost.localdomain> Message-ID: <4673575E.5010904@redhat.com> Toshio Kuratomi wrote: > I have a different view on this. I would like updates-testing to be > strictly for updates that are headed for the repository. As such, there > should be no way to disable the timeout on updates-testing. This is to > help those users who want to constantly run later packages from the > testing repo to run them knowing that they are all candidates for > release. And what is to guarantee maintainers actually look at feedback? Maybe a package is pushed to testing with a timeout of 7 days, and for whatever reason, they don't notice 50 "this update eats my file system" comments on the update. Sounds like a great idea. The whole point of -testing is that we're assuming updates might not ready for production. If we want to assume that updates _are_ ready to be pushed, let's just skip -testing altogether and fix bugs post facto. From a.badger at gmail.com Sat Jun 16 06:08:22 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 15 Jun 2007 23:08:22 -0700 Subject: Bodhi updates-testing Autopush, Anonymous Commenting In-Reply-To: <4673575E.5010904@redhat.com> References: <46645B98.70001@redhat.com> <4672C85A.4060509@redhat.com> <1181938312.28801.91.camel@localhost.localdomain> <4673575E.5010904@redhat.com> Message-ID: <1181974102.20039.7.camel@localhost.localdomain> On Fri, 2007-06-15 at 23:22 -0400, Christopher Aillon wrote: > Toshio Kuratomi wrote: > > I have a different view on this. I would like updates-testing to be > > strictly for updates that are headed for the repository. As such, there > > should be no way to disable the timeout on updates-testing. This is to > > help those users who want to constantly run later packages from the > > testing repo to run them knowing that they are all candidates for > > release. > > And what is to guarantee maintainers actually look at feedback? Maybe a > package is pushed to testing with a timeout of 7 days, and for whatever > reason, they don't notice 50 "this update eats my file system" comments > on the update. Sounds like a great idea. > The comments go to Bodhi -> Bodhi flags the package as being unavailable to push and sends a message to the maintainer. Pretty simple. > The whole point of -testing is that we're assuming updates might not > ready for production. If we want to assume that updates _are_ ready to > be pushed, let's just skip -testing altogether and fix bugs post facto. That's not the impression I've been receiving. What I've been reading is that -testing is there because the maintainer assumes the package is ready for production but sitting in -testing gives automated testing and human driven QA a chance to take place. Which is why I think there's two audiences and two use cases being proposed for the same repository currently. -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 Sat Jun 16 08:35:20 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 16 Jun 2007 10:35:20 +0200 Subject: How to remove wrong tag in CVS? In-Reply-To: <9b1b20e70706151756u21689c12m7e8bc7e960ec4187@mail.gmail.com> References: <4672F72E.3000904@wp.pl> <9b1b20e70706151756u21689c12m7e8bc7e960ec4187@mail.gmail.com> Message-ID: <20070616103520.4b3c7182.bugs.michael@gmx.net> On Sat, 16 Jun 2007 01:56:46 +0100, Julian Sikorski wrote: > 2007/6/15, Marcin Zaj?czkowski: > > Hi, > > > > > > I tried to update my package and due to old common directory make tagged > > by devel directory with isomaster-1_0-1_fc7. Later I updated it and the > > right tag was made, but I have obvious problem with F-7 branch. > > I tried to remove wrong tag, but without success: > > > > [szpak at szpak devel]$ cvs tag -d isomaster-1_0-1_fc7 > > ERROR: Tag removal not allowed for tag isomaster-1_0-1_fc7 > > cvs tag: Pre-tag check failed > > cvs [tag aborted]: correct the above errors first! > > > > > > Is it possible to remove that tag? > > Or I have to bump release number to be able to make F-7 tag? > IIRC it was possible with TAG_OPTS= -R or sth like that. Take a look > at cvsadminprocedure wiki page. cvs tag --help For the ordinary case of moving a tag on an incomplete set of files, it is TAG_OPTS=-F, but you cannot move tags between branches anyway, so better bump release and don't worry anymore. This is "devel". From j.w.r.degoede at hhs.nl Sat Jun 16 08:50:57 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 16 Jun 2007 10:50:57 +0200 Subject: How to remove wrong tag in CVS? In-Reply-To: <20070616103520.4b3c7182.bugs.michael@gmx.net> References: <4672F72E.3000904@wp.pl> <9b1b20e70706151756u21689c12m7e8bc7e960ec4187@mail.gmail.com> <20070616103520.4b3c7182.bugs.michael@gmx.net> Message-ID: <4673A471.7080707@hhs.nl> Michael Schwendt wrote: > On Sat, 16 Jun 2007 01:56:46 +0100, Julian Sikorski wrote: > >> 2007/6/15, Marcin Zaj?czkowski: >>> Hi, >>> >>> >>> I tried to update my package and due to old common directory make tagged >>> by devel directory with isomaster-1_0-1_fc7. Later I updated it and the >>> right tag was made, but I have obvious problem with F-7 branch. >>> I tried to remove wrong tag, but without success: >>> >>> [szpak at szpak devel]$ cvs tag -d isomaster-1_0-1_fc7 >>> ERROR: Tag removal not allowed for tag isomaster-1_0-1_fc7 >>> cvs tag: Pre-tag check failed >>> cvs [tag aborted]: correct the above errors first! >>> >>> >>> Is it possible to remove that tag? >>> Or I have to bump release number to be able to make F-7 tag? > >> IIRC it was possible with TAG_OPTS= -R or sth like that. Take a look >> at cvsadminprocedure wiki page. > > cvs tag --help > > For the ordinary case of moving a tag on an incomplete set of files, > it is TAG_OPTS=-F, but you cannot move tags between branches anyway, > so better bump release and don't worry anymore. This is "devel". > Or just do the following for the real F-7 package: Release: X%{?dist}.1 That will give it a different tag and a lower EVR then F-8/devel Regards, Hans From mszpak at wp.pl Sat Jun 16 10:27:24 2007 From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=) Date: Sat, 16 Jun 2007 12:27:24 +0200 Subject: How to remove wrong tag in CVS? In-Reply-To: <4673A471.7080707@hhs.nl> References: <4672F72E.3000904@wp.pl> <9b1b20e70706151756u21689c12m7e8bc7e960ec4187@mail.gmail.com> <20070616103520.4b3c7182.bugs.michael@gmx.net> <4673A471.7080707@hhs.nl> Message-ID: <4673BB0C.3040808@wp.pl> On 2007-06-16 10:50:57 +0200, Hans de Goede wrote: > Michael Schwendt wrote: >> On Sat, 16 Jun 2007 01:56:46 +0100, Julian Sikorski wrote: >>> 2007/6/15, Marcin Zaj?czkowski: >>>> I tried to update my package and due to old common directory make >>>> tagged >>>> by devel directory with isomaster-1_0-1_fc7. Later I updated it and the >>>> right tag was made, but I have obvious problem with F-7 branch. >>>> I tried to remove wrong tag, but without success: >>>> >>>> [szpak at szpak devel]$ cvs tag -d isomaster-1_0-1_fc7 >>>> ERROR: Tag removal not allowed for tag isomaster-1_0-1_fc7 >>>> cvs tag: Pre-tag check failed >>>> cvs [tag aborted]: correct the above errors first! >>>> >>>> >>>> Is it possible to remove that tag? >>>> Or I have to bump release number to be able to make F-7 tag? >> >>> IIRC it was possible with TAG_OPTS= -R or sth like that. Take a look >>> at cvsadminprocedure wiki page. >> >> cvs tag --help >> >> For the ordinary case of moving a tag on an incomplete set of files, >> it is TAG_OPTS=-F, but you cannot move tags between branches anyway, >> so better bump release and don't worry anymore. This is "devel". >> > > Or just do the following for the real F-7 package: > > Release: X%{?dist}.1 > > That will give it a different tag and a lower EVR then F-8/devel Before my first post and tried "standard" CVS procedure, but -F didn't work with error about different branches and -d with mentioned error. Error after -d looked like the one caused by CVS configuration, so I asked about possible options. In that situation I'll bump release number for F-7 (FC5 and FC6 branches were built successfully and hopefully will be available in a repository soon) to workaround the problem. Thanks for your answers. Marcin From otaylor at redhat.com Sat Jun 16 11:56:26 2007 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 16 Jun 2007 07:56:26 -0400 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181941040.2567.5.camel@halflap.boston.devel.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <1181937478.12039.31.camel@fresnel.dumbhippo.com> <1181941040.2567.5.camel@halflap.boston.devel.redhat.com> Message-ID: <1181994986.30526.0.camel@huygens.home.fishsoup.net> On Fri, 2007-06-15 at 16:57 -0400, Ray Strode wrote: > Hi, > > echo %{version} > %{_datadir}/mugshot/version > > > > Now, there are still a downside: you have to wake up to check for an > > upgrade every so often. If you wake up too often, you drain power. > > If you wake up less often, it might be a while before you switch > > versions, so the desktop component needs to be robust against that. > > Why aren't you just watching the file with inotify or gamin or whatever? ^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think that sort of answers the question :-) - Owen From debarshi.ray at gmail.com Sat Jun 16 16:40:26 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 16 Jun 2007 22:10:26 +0530 Subject: Orphaning nexuiz In-Reply-To: <15400.65.192.24.164.1181839875.squirrel@mail.jcomserv.net> References: <20070613064634.GA20727@lisas.de> <466F9ADD.1010201@hhs.nl> <19689.65.192.24.164.1181735116.squirrel@mail.jcomserv.net> <20070614063648.GA30177@lisas.de> <11546.65.192.24.164.1181826478.squirrel@mail.jcomserv.net> <15400.65.192.24.164.1181839875.squirrel@mail.jcomserv.net> Message-ID: <3170f42f0706160940u7249e763j875c5ae7ad6866ec@mail.gmail.com> > Transfer complete. I'll try to get an update out soon, probably no later > than next week. http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages still lists nexuiz and in #fedora-devel: bzbot: whoowns nexuiz rishi: nexuiz is owned by adrian at lisas.de Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From peter at thecodergeek.com Sat Jun 16 18:19:09 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 16 Jun 2007 11:19:09 -0700 Subject: Orphaning nexuiz In-Reply-To: <3170f42f0706160940u7249e763j875c5ae7ad6866ec@mail.gmail.com> References: <20070613064634.GA20727@lisas.de> <466F9ADD.1010201@hhs.nl> <19689.65.192.24.164.1181735116.squirrel@mail.jcomserv.net> <20070614063648.GA30177@lisas.de> <11546.65.192.24.164.1181826478.squirrel@mail.jcomserv.net> <15400.65.192.24.164.1181839875.squirrel@mail.jcomserv.net> <3170f42f0706160940u7249e763j875c5ae7ad6866ec@mail.gmail.com> Message-ID: <1182017949.3403.1.camel@tuxhugs> On Sat, 2007-06-16 at 22:10 +0530, Debarshi 'Rishi' Ray wrote: > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages > still lists nexuiz and in #fedora-devel: I've fixed the wiki page. nexuiz and nexuiz-data are no longer listed. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- 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 pertusus at free.fr Sun Jun 17 09:09:28 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 17 Jun 2007 11:09:28 +0200 Subject: wiki edit needed for new review process Message-ID: <20070617090928.GA3064@free.fr> Hello, I found that http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored still refers to the FE-* blocker bugs. This seems wrong to me. I think that the references should be changed to what replaces FE-* blocker bugs, whatever it is. -- Pat From andreas.bierfert at lowlatency.de Sun Jun 17 15:07:26 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 17 Jun 2007 17:07:26 +0200 Subject: devel builds and desktop-file-utils check Message-ID: <20070617170726.553a344a@alkaid.a.lan> Hi, a couple of hours ago I tried to build a new wine release on devel. It failed because of a valid error in a desktop file s/True/true/ and it was fine. I kicked a rebuild to see that it fails again (only on devel though) with this message: desktop-file-install --vendor=fedora --dir=/var/tmp/wine-0.9.39-1.fc8-root-kojibuilder/usr/share/applications /builddir/build/SOURCES/wine-notepad.desktop /var/tmp/wine-0.9.39-1.fc8-root-kojibuilder/usr/share/applications/fedora-wine-notepad.desktop: error: value "Application;Wine;" for key "Categories" in group "Desktop Entry" contains an unregistered value "Wine" desktop-file-install created an invalid desktop file! I guess from the standpoint of the script it is right to complain about this but putting all wine related programs into a wine folder has been talked about a while back and agreed to be ok. Especially as wine also created per user wine dirs which now after a small bugfix in .38-1 get merged with the system menu. Could somebody enlighten me how I can force desktop-file-utils to install this file without killing the build? - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Sun Jun 17 15:06:07 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 17 Jun 2007 11:06:07 -0400 Subject: devel builds and desktop-file-utils check In-Reply-To: <20070617170726.553a344a@alkaid.a.lan> References: <20070617170726.553a344a@alkaid.a.lan> Message-ID: <1182092767.3446.2.camel@localhost.localdomain> On Sun, 2007-06-17 at 17:07 +0200, Andreas Bierfert wrote: > Hi, > > a couple of hours ago I tried to build a new wine release on devel. It failed > because of a valid error in a desktop file s/True/true/ and it was fine. I > kicked a rebuild to see that it fails again (only on devel though) with this > message: > > desktop-file-install --vendor=fedora > --dir=/var/tmp/wine-0.9.39-1.fc8-root-kojibuilder/usr/share/applications /builddir/build/SOURCES/wine-notepad.desktop /var/tmp/wine-0.9.39-1.fc8-root-kojibuilder/usr/share/applications/fedora-wine-notepad.desktop: > error: value "Application;Wine;" for key "Categories" in group "Desktop Entry" > contains an unregistered value "Wine" desktop-file-install created an invalid > desktop file! > > I guess from the standpoint of the script it is right to complain about this > but putting all wine related programs into a wine folder has been talked about > a while back and agreed to be ok. Especially as wine also created per user wine > dirs which now after a small bugfix in .38-1 get merged with the system menu. > > Could somebody enlighten me how I can force desktop-file-utils to install this > file without killing the build? You cannot force desktop-file-install to install an invalid desktop file. This was always the case, and recently desktop-file-install has become much better at detecting violations of the desktop entry spec. We have intentionally pushed this new version of desktop-file-utils into rawhide early, so that people have plenty of time to fix up their desktop files. Wrt to your desktop file, remove "Application" and change "Wine" to "X-Wine", and it should be ok. From arjan at infradead.org Sun Jun 17 16:01:50 2007 From: arjan at infradead.org (Arjan van de Ven) Date: Sun, 17 Jun 2007 09:01:50 -0700 Subject: Restarting desktop session services on RPM upgrade? In-Reply-To: <1181923909.19325.326.camel@junko.usersys.redhat.com> References: <1181916829.19325.278.camel@junko.usersys.redhat.com> <4672B3F7.4030502@redhat.com> <20070615155850.GA15466@devserv.devel.redhat.com> <1181923909.19325.326.camel@junko.usersys.redhat.com> Message-ID: <1182096110.19654.0.camel@laptopd505.fenrus.org> On Fri, 2007-06-15 at 12:11 -0400, John Dennis wrote: > On Fri, 2007-06-15 at 11:58 -0400, Alan Cox wrote: > > On Fri, Jun 15, 2007 at 11:44:55AM -0400, Havoc Pennington wrote: > > > The Mugshot client daemon does this itself by installing a file called > > > "version" with the package version, and if said file changes it restarts > > > itself. > > > > init stats its own binary and librarie (or used to) > > But that exposes you to a race condition as you don't know when all the > files have been upgraded fair enough > and it requires inefficient periodic polling. no it doesn't... inotify to the rescue. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org From Jochen at herr-schmitt.de Sun Jun 17 18:18:37 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 17 Jun 2007 20:18:37 +0200 Subject: Broken Dependencies when updating F7 Message-ID: <46757AFD.7070704@herr-schmitt.de> Hello, I have try to update F7 with a yum update. Unfortunately, I have got the following error message: Error: libraw1394 conflicts with kernel < 2.6.21-1.3194.fc7 I complaint it here on the list, becouse I thought that the introduction of the update system should avoid such situations. Best Regards: Jochen Schmitt From sdl.web at gmail.com Sun Jun 17 18:37:57 2007 From: sdl.web at gmail.com (Leo) Date: Sun, 17 Jun 2007 19:37:57 +0100 Subject: xorg-x11-drv-i810 Message-ID: Dear all, The other day, I compiled the i810 driver from source and I can see the installed file "/usr/lib/xorg/modules/drivers/i810_drv.so" is a symbolic link. However, in xorg-x11-drv-i810-2.0.0-4.fc7 "/usr/lib/xorg/modules/drivers/i810_drv.so" is not a symbolic link. Do you think this is a bug? Best, -- Leo (GPG Key: 9283AA3F) From bugs.michael at gmx.net Sun Jun 17 19:07:12 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 17 Jun 2007 21:07:12 +0200 Subject: Broken Dependencies when updating F7 In-Reply-To: <46757AFD.7070704@herr-schmitt.de> References: <46757AFD.7070704@herr-schmitt.de> Message-ID: <20070617210712.af4db887.bugs.michael@gmx.net> On Sun, 17 Jun 2007 20:18:37 +0200, Jochen Schmitt wrote: > Hello, > > I have try to update F7 with a yum update. > > Unfortunately, I have got the following error message: > > Error: libraw1394 conflicts with kernel < 2.6.21-1.3194.fc7 F7's kernel _is_ 2.6.21-1.3194.fc7, so the conflict doesn't apply. From ivazqueznet at gmail.com Sun Jun 17 19:08:21 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 17 Jun 2007 15:08:21 -0400 Subject: Broken Dependencies when updating F7 In-Reply-To: <20070617210712.af4db887.bugs.michael@gmx.net> References: <46757AFD.7070704@herr-schmitt.de> <20070617210712.af4db887.bugs.michael@gmx.net> Message-ID: <1182107301.21142.4.camel@ignacio.lan> On Sun, 2007-06-17 at 21:07 +0200, Michael Schwendt wrote: > On Sun, 17 Jun 2007 20:18:37 +0200, Jochen Schmitt wrote: > > Error: libraw1394 conflicts with kernel < 2.6.21-1.3194.fc7 > > F7's kernel _is_ 2.6.21-1.3194.fc7, so the conflict doesn't apply. Except, of course, for the Xen kernel, which is 2.6.20-2925.9.fc7. -- Ignacio Vazquez-Abrams -------------- 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 Jochen at herr-schmitt.de Sun Jun 17 19:46:15 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 17 Jun 2007 21:46:15 +0200 Subject: Broken Dependencies when updating F7 In-Reply-To: <1182107301.21142.4.camel@ignacio.lan> References: <46757AFD.7070704@herr-schmitt.de> <20070617210712.af4db887.bugs.michael@gmx.net> <1182107301.21142.4.camel@ignacio.lan> Message-ID: <46758F87.7070007@herr-schmitt.de> Ignacio Vazquez-Abrams schrieb: > Except, of course, for the Xen kernel, which is 2.6.20-2925.9.fc7. > The maintainer of the libraw1394 package has wrote in #244474 that he want to push an update which should solve this issue. I have built it from the cvs and can report, that the issue will be solve. The aint of this posting was to notify, that something in the update system doesn't seems to work correctly, becouse I thing the gain of the update system is to avoid issues like the reported. Best Regards: Jochen Schmitt From bugs.michael at gmx.net Sun Jun 17 19:55:56 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 17 Jun 2007 21:55:56 +0200 Subject: Broken Dependencies when updating F7 In-Reply-To: <1182107301.21142.4.camel@ignacio.lan> References: <46757AFD.7070704@herr-schmitt.de> <20070617210712.af4db887.bugs.michael@gmx.net> <1182107301.21142.4.camel@ignacio.lan> Message-ID: <20070617215556.f0308fb3.bugs.michael@gmx.net> On Sun, 17 Jun 2007 15:08:21 -0400, Ignacio Vazquez-Abrams wrote: > > > Error: libraw1394 conflicts with kernel < 2.6.21-1.3194.fc7 > > > > F7's kernel _is_ 2.6.21-1.3194.fc7, so the conflict doesn't apply. > > Except, of course, for the Xen kernel, which is 2.6.20-2925.9.fc7. Okay. It is less than that, kernel-xen "Provides: kernel = 2.6.20". Assume somebody uninstalls F7's normal kernel. Then a yum _update_ cannot run into the libraw1394 "Conflicts:", unless a dependency pulls in libraw1394 as a new package to be installed. So, what is the full story here? From Jochen at herr-schmitt.de Sun Jun 17 19:59:01 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 17 Jun 2007 21:59:01 +0200 Subject: Script to determinate packages wich need comaintainership Message-ID: <46759285.7050206@herr-schmitt.de> Hello, I have try to develop a python script which should able to determinate which packages need comaintainership on base of the owners.list. I have uploaded it to: http://www.herr-schmitt.de/pub/comaint/comaint.txt I have used the .txt extension, becouse I have got some trouble with my webspace when uploading a file with the .py extension. Best Regards: Jochen Schmitt From andreas.bierfert at lowlatency.de Sun Jun 17 22:15:05 2007 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Mon, 18 Jun 2007 00:15:05 +0200 Subject: Script to determinate packages wich need comaintainership In-Reply-To: <46759285.7050206@herr-schmitt.de> References: <46759285.7050206@herr-schmitt.de> Message-ID: <20070618001505.289880b0@alkaid.a.lan> On Sun, 17 Jun 2007 21:59:01 +0200 Jochen Schmitt wrote: > Hello, > > I have try to develop a python script which should able to determinate which > packages need comaintainership on base of the owners.list. Just a question: How is it suppose to know if a package needs comaintainership? I guess it is telling which packages do not have comaintainers but my impression is that it is up to a maintainer to decide of he/she wants/needs comaintainers. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- 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 Jun 18 00:12:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 17 Jun 2007 20:12:07 -0400 Subject: Broken Dependencies when updating F7 In-Reply-To: <20070617215556.f0308fb3.bugs.michael@gmx.net> References: <46757AFD.7070704@herr-schmitt.de> <1182107301.21142.4.camel@ignacio.lan> <20070617215556.f0308fb3.bugs.michael@gmx.net> Message-ID: <200706172012.07755.jkeating@redhat.com> On Sunday 17 June 2007 15:55:56 Michael Schwendt wrote: > Okay. It is less than that, kernel-xen "Provides: kernel = 2.6.20". > > Assume somebody uninstalls F7's normal kernel. > Then a yum _update_ cannot run into the libraw1394 "Conflicts:", > unless a dependency pulls in libraw1394 as a new package to be > installed. > > So, what is the full story here? Actually libraw1394 may not actually work with that kernel-xen. Will work with the maintainer's tomorrow to sort out this issue. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rvokal at redhat.com Mon Jun 18 06:36:32 2007 From: rvokal at redhat.com (=?UTF-8?B?UmFkZWsgVm9rw6Fs?=) Date: Mon, 18 Jun 2007 08:36:32 +0200 Subject: Merging Core and Extras Bugzilla Products -- owners.list In-Reply-To: <1181939448.28801.106.camel@localhost.localdomain> References: <1181939448.28801.106.camel@localhost.localdomain> Message-ID: <467627F0.4040600@redhat.com> Toshio Kuratomi wrote: > Hi all, > > The Fedora Core and Fedora Extras Bugzilla products will be merged into > a single Fedora product Sometime Very Soon (TM). When that happens we > will have to merge the ownership details in owners.list as well. > > For most packages, this merge will be a rather humdrum announcement that > won't affect you at all. For a few, the packages that were in Fedora > Core for some releases and Fedora Extras for some others, the ownership > details of the packages will be merged. > > For instance, these entries for ccid: > Fedora Core|ccid|Generic USB CCID smart card reader driver| > rrelyea at redhat.com|extras-qa at fedoraproject.org| > Fedora Extras|ccid|Generic USB CCID smart card reader driver| > ville.skytta at iki.fi|extras-qa at fedoraproject.org| > ludovic.rousseau at gmail.com > > Will be merged into this: > Fedora|ccid|Generic USB CCID smart card reader driver| > rrelyea at redhat.com,ville.skytta at iki.fi|extras-qa at fedoraproject.org| > ludovic.rousseau at gmail.com > > If you were happy to give up your duties as a maintainer of one of these > packages when it shifted repositories before you'll want to take a look > at the owners.list file after we announce the Bugzilla Merge has taken > place and request cleanups be made where appropriate. > > Once again, this is just a heads up. We'll be sure to announce the > bugzilla and owners.list merge when it actually takes place. > So what is the current procedure of changing ownership of the package? Does editing the owners.list file still has the same effect on bugzilla or do we have to go through a bugzilla bug as it was proposed some time ago? Radek -- Radek Vok?l Base OS Engineering - Team Lead Office: +420 532 294 111 Mobile: +420 608 437 507 Red Hat Inc. http://cz.redhat.com From dennis at ausil.us Mon Jun 18 11:56:16 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 18 Jun 2007 06:56:16 -0500 Subject: Merging Core and Extras Bugzilla Products -- owners.list In-Reply-To: <467627F0.4040600@redhat.com> References: <1181939448.28801.106.camel@localhost.localdomain> <467627F0.4040600@redhat.com> Message-ID: <200706180656.17397.dennis@ausil.us> Once upon a time Monday 18 June 2007, Radek Vok?l wrote: > So what is the current procedure of changing ownership of the package? > Does editing the owners.list file still has the same effect on bugzilla > or do we have to go through a bugzilla bug as it was proposed some time > ago? You need to set the cvs flag to ? in bugzilla for the review with the details of the change and have a cvs admin do it. The package database that Toshio is working on will let you change owners without a cvs admin. Dennis From jwboyer at jdub.homelinux.org Mon Jun 18 11:26:37 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 18 Jun 2007 06:26:37 -0500 Subject: Merging Core and Extras Bugzilla Products -- owners.list In-Reply-To: <467627F0.4040600@redhat.com> References: <1181939448.28801.106.camel@localhost.localdomain> <467627F0.4040600@redhat.com> Message-ID: <1182165997.2890.1.camel@vader.jdub.homelinux.org> On Mon, 2007-06-18 at 08:36 +0200, Radek Vok?l wrote: > Toshio Kuratomi wrote: > > Hi all, > > > > The Fedora Core and Fedora Extras Bugzilla products will be merged into > > a single Fedora product Sometime Very Soon (TM). When that happens we > > will have to merge the ownership details in owners.list as well. > > > > For most packages, this merge will be a rather humdrum announcement that > > won't affect you at all. For a few, the packages that were in Fedora > > Core for some releases and Fedora Extras for some others, the ownership > > details of the packages will be merged. > > > > For instance, these entries for ccid: > > Fedora Core|ccid|Generic USB CCID smart card reader driver| > > rrelyea at redhat.com|extras-qa at fedoraproject.org| > > Fedora Extras|ccid|Generic USB CCID smart card reader driver| > > ville.skytta at iki.fi|extras-qa at fedoraproject.org| > > ludovic.rousseau at gmail.com > > > > Will be merged into this: > > Fedora|ccid|Generic USB CCID smart card reader driver| > > rrelyea at redhat.com,ville.skytta at iki.fi|extras-qa at fedoraproject.org| > > ludovic.rousseau at gmail.com > > > > If you were happy to give up your duties as a maintainer of one of these > > packages when it shifted repositories before you'll want to take a look > > at the owners.list file after we announce the Bugzilla Merge has taken > > place and request cleanups be made where appropriate. > > > > Once again, this is just a heads up. We'll be sure to announce the > > bugzilla and owners.list merge when it actually takes place. > > > > So what is the current procedure of changing ownership of the package? > Does editing the owners.list file still has the same effect on bugzilla > or do we have to go through a bugzilla bug as it was proposed some time > ago? You currently can't edit owners.list today anyway. You need to follow the procedure outlined here: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure josh From Jochen at herr-schmitt.de Mon Jun 18 13:34:56 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 18 Jun 2007 15:34:56 +0200 Subject: Script to determinate packages wich need comaintainership In-Reply-To: <20070618001505.289880b0@alkaid.a.lan> References: <46759285.7050206@herr-schmitt.de> <20070618001505.289880b0@alkaid.a.lan> Message-ID: <0MKxQS-1I0HQy0hhC-0008Jl@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 18 Jun 2007 00:15:05 +0200, you wrote: >Just a question: How is it suppose to know if a package needs comaintainership? >I guess it is telling which packages do not have comaintainers but my >impression is that it is up to a maintainer to decide of he/she wants/needs >comaintainers. The idea of the script is to examinate the owner field of a package in the owner.list. If you have enter a comaintainer in the owner.list, you will find a ',' in the owner field. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) Charset: us-ascii wj8DBQFGdoolT2AHK6txfgwRAmkaAJwLIVZ0PMeEngxXxGaOt+/qHlErSwCg5OXO fdblZom4IC+FMNMrQBEy7tA= =Nfhp -----END PGP SIGNATURE----- From opensource at till.name Mon Jun 18 13:50:27 2007 From: opensource at till.name (Till Maas) Date: Mon, 18 Jun 2007 15:50:27 +0200 Subject: Merging Core and Extras Bugzilla Products -- owners.list In-Reply-To: <1182165997.2890.1.camel@vader.jdub.homelinux.org> References: <1181939448.28801.106.camel@localhost.localdomain> <467627F0.4040600@redhat.com> <1182165997.2890.1.camel@vader.jdub.homelinux.org> Message-ID: <200706181550.32886.opensource@till.name> On Mo Juni 18 2007, Josh Boyer wrote: > You currently can't edit owners.list today anyway. You need to follow > the procedure outlined here: > > http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure Would you please add this explanation to the owners.*.list comment at the head of the file? Regards, Till From jwboyer at jdub.homelinux.org Mon Jun 18 14:48:06 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 18 Jun 2007 09:48:06 -0500 Subject: Merging Core and Extras Bugzilla Products -- owners.list In-Reply-To: <200706181550.32886.opensource@till.name> References: <1181939448.28801.106.camel@localhost.localdomain> <467627F0.4040600@redhat.com> <1182165997.2890.1.camel@vader.jdub.homelinux.org> <200706181550.32886.opensource@till.name> Message-ID: <1182178086.29471.2.camel@weaponx.rchland.ibm.com> On Mon, 2007-06-18 at 15:50 +0200, Till Maas wrote: > On Mo Juni 18 2007, Josh Boyer wrote: > > > You currently can't edit owners.list today anyway. You need to follow > > the procedure outlined here: > > > > http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure > > Would you please add this explanation to the owners.*.list comment at the head > of the file? Done. Thanks for the suggestion. josh From ajackson at redhat.com Mon Jun 18 14:44:49 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 18 Jun 2007 10:44:49 -0400 Subject: xorg-x11-drv-i810 In-Reply-To: References: Message-ID: <1182177889.30663.156.camel@localhost.localdomain> On Sun, 2007-06-17 at 19:37 +0100, Leo wrote: > Dear all, > > The other day, I compiled the i810 driver from source and I can see the > installed file "/usr/lib/xorg/modules/drivers/i810_drv.so" is a symbolic > link. > > However, in xorg-x11-drv-i810-2.0.0-4.fc7 > "/usr/lib/xorg/modules/drivers/i810_drv.so" is not a symbolic link. Do > you think this is a bug? No, it's not. The upstream driver has been renamed 'intel', and it installs a symlink for compatibility. However, it still doesn't work perfectly on older chips. So the -i810 srpm builds two drivers, both the new 'intel' driver and an older, known-stable version of the i810 driver. - ajax From jkeating at redhat.com Mon Jun 18 14:53:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 18 Jun 2007 10:53:11 -0400 Subject: Topics for this week's Release Engineering meeting? Message-ID: <200706181053.12279.jkeating@redhat.com> We didn't have anything brought to rel-eng so far for this week's meeting. Are there any 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 jspaleta at gmail.com Mon Jun 18 16:34:37 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 18 Jun 2007 08:34:37 -0800 Subject: Script to determinate packages wich need comaintainership In-Reply-To: <20070618001505.289880b0@alkaid.a.lan> References: <46759285.7050206@herr-schmitt.de> <20070618001505.289880b0@alkaid.a.lan> Message-ID: <604aa7910706180934y5f55d4d0gc8dcf3550a2c61c@mail.gmail.com> On 6/17/07, Andreas Bierfert wrote: > Just a question: How is it suppose to know if a package needs comaintainership? > I guess it is telling which packages do not have comaintainers but my > impression is that it is up to a maintainer to decide of he/she wants/needs > comaintainers. Now that we are post F7, I'd like to see a second round of discussion concerning the strawman proposal (i believe warren proposed) on how to get limited cvs access to upstream developers so I can pull upstream people in as co-maintainers on the packages for software they themselves develop, while I act as the responsible and trusted fedora contributor to push updates. I don't necessarily need other established fedora package monkeys to help me co-maintain. What I need is to find a way to get new people, specifically upstream developers enough cvs and build system access to help me deal with codebase issues instead of shallow fedora packaging adminstrata . The current sponsorship path is fine to evaluate people who will be acting as primary maintainers . But what I need is a way to bring upstream developers partway into the process to act as comaintainers on specific packages so that I can mentor them towards a fully sponsored contributor status if that is a direction they want to go. -jef From caillon at redhat.com Mon Jun 18 16:35:20 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 18 Jun 2007 12:35:20 -0400 Subject: Bodhi updates-testing Autopush, Anonymous Commenting In-Reply-To: <1181974102.20039.7.camel@localhost.localdomain> References: <46645B98.70001@redhat.com> <4672C85A.4060509@redhat.com> <1181938312.28801.91.camel@localhost.localdomain> <4673575E.5010904@redhat.com> <1181974102.20039.7.camel@localhost.localdomain> Message-ID: <4676B448.4000806@redhat.com> Toshio Kuratomi wrote: > The comments go to Bodhi -> Bodhi flags the package as being unavailable > to push and sends a message to the maintainer. Pretty simple. Um, how does it do that? From Jochen at herr-schmitt.de Mon Jun 18 16:43:43 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 18 Jun 2007 18:43:43 +0200 Subject: Script to determinate packages wich need comaintainership In-Reply-To: <604aa7910706180934y5f55d4d0gc8dcf3550a2c61c@mail.gmail.com> References: <46759285.7050206@herr-schmitt.de> <20070618001505.289880b0@alkaid.a.lan> <604aa7910706180934y5f55d4d0gc8dcf3550a2c61c@mail.gmail.com> Message-ID: <4676B63F.9080403@herr-schmitt.de> Jeff Spaleta schrieb: > The current sponsorship path is fine to evaluate people who will be > acting as primary maintainers . But what I need is a way to bring > upstream developers partway into the process to act as comaintainers > on specific packages so that I can mentor them towards a fully > sponsored contributor status if that is a direction they want to go. I'm not sure, that upstream authors are willing to handle with distribution specific standards and issues. Of course it should be possible to invite a upstream author which is not a fedora contributor to be a comaintainer for a specific packages, but I think this is not the common situation. A comaintainter should ensure, that someone is available, if a fix on a package is necessary, which doesn't allow a delay, because the maintainer is in vacation and so on. Best Regards: Jochen Schmitt From sundaram at fedoraproject.org Mon Jun 18 16:54:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 18 Jun 2007 22:24:23 +0530 Subject: Topics for this week's Release Engineering meeting? In-Reply-To: <200706181053.12279.jkeating@redhat.com> References: <200706181053.12279.jkeating@redhat.com> Message-ID: <4676B8BF.6080102@fedoraproject.org> Jesse Keating wrote: > We didn't have anything brought to rel-eng so far for this week's meeting. > Are there any suggestions? > It might be good to discuss how the team is going to deal with file conflicts between packages in the repository. Block them at the level of Koji? Rahul From jkeating at redhat.com Mon Jun 18 16:55:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 18 Jun 2007 12:55:36 -0400 Subject: Topics for this week's Release Engineering meeting? In-Reply-To: <4676B8BF.6080102@fedoraproject.org> References: <200706181053.12279.jkeating@redhat.com> <4676B8BF.6080102@fedoraproject.org> Message-ID: <200706181255.40288.jkeating@redhat.com> On Monday 18 June 2007 12:54:23 Rahul Sundaram wrote: > It might be good to discuss how the team is going to deal with file > conflicts between packages in the repository. Block them at the level of > Koji? That really only hurts the user and doesn't fix the problem. In reality bugs should be filed and fixed, using ever increasing bat sizes to get the point across. -- 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 Mon Jun 18 17:07:48 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 18 Jun 2007 09:07:48 -0800 Subject: Script to determinate packages wich need comaintainership In-Reply-To: <4676B63F.9080403@herr-schmitt.de> References: <46759285.7050206@herr-schmitt.de> <20070618001505.289880b0@alkaid.a.lan> <604aa7910706180934y5f55d4d0gc8dcf3550a2c61c@mail.gmail.com> <4676B63F.9080403@herr-schmitt.de> Message-ID: <604aa7910706181007g2acfd303xcc304e35545bb161@mail.gmail.com> On 6/18/07, Jochen Schmitt wrote: > Jeff Spaleta schrieb: > I'm not sure, that upstream authors are willing to handle with distribution > specific standards and issues. And I'm not sure that maintainers who are not involved in upstream development can fix more important codebase bugs that have absolutely nothing to do with packaging guidance and standards. I've got the packaging guidance covered pretty well. What I need are upstream developers who are invested in working with me to run point on codebase bug issues not more packaging experts that can collectively stand around and scratch their heads with me when a real software bug is exposed. Of course whether or not an upstream developer is willing to be involved with fedora packages will be a case by case basis. But right now I don't really have the ability to chat up developers upstream of me to get involved more directly. Contribution is an all or nothing affair at the moment.. we are not leveraging our infrastructures strengths to build bridges between package maintainers and upstream developers. > > Of course it should be possible to invite a upstream author which is not > a fedora contributor to be a comaintainer for a specific packages, but I > think this is not the common situation. Actually we dont have a way to do that. The sponsorship process does not have a concept of probationary access or mentored access. You get sponsored and you get the kings to the kingdom. > A comaintainter should ensure, that someone is available, if a fix on a > package is necessary, which doesn't allow a delay, because the maintainer > is in vacation and so on. Again.... I want to stress... that not all problems are shallow packaging problems. Some are in fact deeper problems in the codebase, that expert knowledge of the packaging guidance will not help. For these much more important problems, being able to have an upstream developer work with me within the fedora infrastructure to produce scratch koji builds in response to specific bugreports is the best way to fix problems quickly. Packaging level issues at the end of the day are just shallow annoyances, even when its multilib problems, compared to crasher or data corruption bugs in the codebase itself. -jef From sundaram at fedoraproject.org Mon Jun 18 17:09:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 18 Jun 2007 22:39:55 +0530 Subject: Topics for this week's Release Engineering meeting? In-Reply-To: <200706181255.40288.jkeating@redhat.com> References: <200706181053.12279.jkeating@redhat.com> <4676B8BF.6080102@fedoraproject.org> <200706181255.40288.jkeating@redhat.com> Message-ID: <4676BC63.9050502@fedoraproject.org> Jesse Keating wrote: > On Monday 18 June 2007 12:54:23 Rahul Sundaram wrote: >> It might be good to discuss how the team is going to deal with file >> conflicts between packages in the repository. Block them at the level of >> Koji? > > That really only hurts the user and doesn't fix the problem. In reality bugs > should be filed and fixed, using ever increasing bat sizes to get the point > across. I am not sure how it would hurt the user if we enforce good practices using tools as opposed to retroactively fixing it after the users get hit by the problems. Can you explain? Can bug reports be automated for existing packages? Can a RFE be filed against the build system to prevent new packages from being introduced into the repository with such issues? Rahul From tmz at pobox.com Mon Jun 18 17:10:02 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 18 Jun 2007 13:10:02 -0400 Subject: Script to determinate packages wich need comaintainership In-Reply-To: <604aa7910706180934y5f55d4d0gc8dcf3550a2c61c@mail.gmail.com> References: <46759285.7050206@herr-schmitt.de> <20070618001505.289880b0@alkaid.a.lan> <604aa7910706180934y5f55d4d0gc8dcf3550a2c61c@mail.gmail.com> Message-ID: <20070618171002.GK32409@psilocybe.teonanacatl.org> Jeff Spaleta wrote: > Now that we are post F7, I'd like to see a second round of > discussion concerning the strawman proposal (i believe warren > proposed) on how to get limited cvs access to upstream developers so > I can pull upstream people in as co-maintainers on the packages for > software they themselves develop, while I act as the responsible and > trusted fedora contributor to push updates. I don't necessarily need > other established fedora package monkeys to help me co-maintain. > What I need is to find a way to get new people, specifically > upstream developers enough cvs and build system access to help me > deal with codebase issues instead of shallow fedora packaging > adminstrata . Would it be sufficient to work this in the opposite direction? For the few packages I maintain I've tried to be active with the upstream project as much as possible. For me, that's mostly helping with packaging, SCM, and documentation issues, as well as helping to answer questions on the mailing lists for these projects. That helps me earn respect from the main developers and frees up their time to do more cool development. Then if I run into a problem building or running the software I can go to the list and likely get quick help and usually a quick fix as well. That in turn means I don't have to manage many Fedora specific patches, which makes my life simpler. As far as the greater goal of bringing more developers into Fedora, it's not so direct an approach. But I think that it makes Fedora look good when we have the latest upstream offerings and are active upstream. If one of the upstream folks gets tired of their particular distro shipping outdated versions of their software, they'll know they can use Fedora and stay current. Then perhaps they'll also consider joining as a maintainer. (Just keep my kneecaps out of this discussion Jef. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eat drink and be merry, for tomorrow they may make it illegal. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 18 17:11:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 18 Jun 2007 13:11:33 -0400 Subject: Topics for this week's Release Engineering meeting? In-Reply-To: <4676BC63.9050502@fedoraproject.org> References: <200706181053.12279.jkeating@redhat.com> <200706181255.40288.jkeating@redhat.com> <4676BC63.9050502@fedoraproject.org> Message-ID: <200706181311.33410.jkeating@redhat.com> On Monday 18 June 2007 13:09:55 Rahul Sundaram wrote: > I am not sure how it would hurt the user if we enforce good practices > using tools as opposed to retroactively fixing it after the users get > hit by the problems. ?Can you explain? ?Can bug reports be automated for > existing packages? Can a RFE be filed against the build system to > prevent new packages from being introduced into the repository with such > issues? Because it's not just about new packages, so just dropping a package which grows a file conflict isn't a good solution as that leaves the end user holding the bag. Also a new package may have perfectly valid files/provides but an existing package has the improper one, so why penalize the new correct package because of the errors of an existing package. Just dropping the package again hides the problem instead of fixing 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 sundaram at fedoraproject.org Mon Jun 18 17:19:52 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 18 Jun 2007 22:49:52 +0530 Subject: Topics for this week's Release Engineering meeting? In-Reply-To: <200706181311.33410.jkeating@redhat.com> References: <200706181053.12279.jkeating@redhat.com> <200706181255.40288.jkeating@redhat.com> <4676BC63.9050502@fedoraproject.org> <200706181311.33410.jkeating@redhat.com> Message-ID: <4676BEB8.1020004@fedoraproject.org> Jesse Keating wrote: > On Monday 18 June 2007 13:09:55 Rahul Sundaram wrote: >> I am not sure how it would hurt the user if we enforce good practices >> using tools as opposed to retroactively fixing it after the users get >> hit by the problems. Can you explain? Can bug reports be automated for >> existing packages? Can a RFE be filed against the build system to >> prevent new packages from being introduced into the repository with such >> issues? > > Because it's not just about new packages, so just dropping a package which > grows a file conflict isn't a good solution as that leaves the end user > holding the bag. It also provides a compelling reason for the maintainer to fix the issue but that's probably the last measure for a existing package. Can bug reports be automated? Also a new package may have perfectly valid files/provides > but an existing package has the improper one, so why penalize the new correct > package because of the errors of an existing package. Think about this from the end users perspective. They shouldn't be dealing with conflicting files in packages that was not there before the new package got introduced regardless of where the fault lies. How you deal with that is a internal issue. If blocking it in the build system is not the right solution then find another one that solves the problem without it hitting end users. Rahul From jspaleta at gmail.com Mon Jun 18 17:31:54 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 18 Jun 2007 09:31:54 -0800 Subject: Script to determinate packages wich need comaintainership In-Reply-To: <20070618171002.GK32409@psilocybe.teonanacatl.org> References: <46759285.7050206@herr-schmitt.de> <20070618001505.289880b0@alkaid.a.lan> <604aa7910706180934y5f55d4d0gc8dcf3550a2c61c@mail.gmail.com> <20070618171002.GK32409@psilocybe.teonanacatl.org> Message-ID: <604aa7910706181031j59854763ga9336c0739ac0c84@mail.gmail.com> On 6/18/07, Todd Zullinger wrote: > As far as the greater goal of bringing more developers into Fedora, > it's not so direct an approach. But I think that it makes Fedora look > good when we have the latest upstream offerings and are active > upstream. If one of the upstream folks gets tired of their particular > distro shipping outdated versions of their software, they'll know they > can use Fedora and stay current. Then perhaps they'll also consider > joining as a maintainer. Join Fedora how? By submitting new packages they aren't already involved in the upstream development of so they can earn sponsorship status? That's crap, and it arbitrarily raises the bar for developers to be involved. Look I'm not saying that maintainers shouldn't be involved in upstream. But the reality is we simply do not have an established mechanism to turn upstream developers into maintainers for existing packages..and we really sort of need it.. if we want sustainable long term package maintainence across the repository. Here's the question that I need answering. What is the process by which upstream developers can take some to all of the maintainership duties of currently existing packages? The fedora sponsorship process is driven around the concept of package submission... but how do we get people sponsored for maintainership for packages that already exist? We need a transitional process by which to bring developers into the package maintainership process for software that already exists. Currently, sponsorship involves a review of 'right action', and I want to help interested developers gain enough access to the packaging infrastructure for their software to build up the track record of 'right action' so when and if they want sponsored contributor status... it won't sit stalled for weeks because they haven't submitted a package or haven't chimed in on pending reviews. -jef From tmz at pobox.com Mon Jun 18 18:00:27 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 18 Jun 2007 14:00:27 -0400 Subject: Script to determinate packages wich need comaintainership In-Reply-To: <604aa7910706181031j59854763ga9336c0739ac0c84@mail.gmail.com> References: <46759285.7050206@herr-schmitt.de> <20070618001505.289880b0@alkaid.a.lan> <604aa7910706180934y5f55d4d0gc8dcf3550a2c61c@mail.gmail.com> <20070618171002.GK32409@psilocybe.teonanacatl.org> <604aa7910706181031j59854763ga9336c0739ac0c84@mail.gmail.com> Message-ID: <20070618180027.GO32409@psilocybe.teonanacatl.org> Jeff Spaleta wrote: > On 6/18/07, Todd Zullinger wrote: >> As far as the greater goal of bringing more developers into Fedora, >> it's not so direct an approach. But I think that it makes Fedora >> look good when we have the latest upstream offerings and are active >> upstream. If one of the upstream folks gets tired of their >> particular distro shipping outdated versions of their software, >> they'll know they can use Fedora and stay current. Then perhaps >> they'll also consider joining as a maintainer. > > Join Fedora how? By submitting new packages they aren't already > involved in the upstream development of so they can earn sponsorship > status? That's crap, and it arbitrarily raises the bar for > developers to be involved. Okay, true enough. I missed that important piece of the goal. > Here's the question that I need answering. > > What is the process by which upstream developers can take some to > all of the maintainership duties of currently existing packages? > The fedora sponsorship process is driven around the concept of > package submission... but how do we get people sponsored for > maintainership for packages that already exist? It would need another level of access, just below full maintainer level. Is that something that the PackageDB can help with at all? I agree with you that it would be handy to be able to ease someone from upstream into the process if they could at least start by building their own software instead of someone else's. I do still think that much of the need for them to be involved as packagers can be minimized by those of us who are packaging stuff being involved upstream (e.g. codebase issues and fixing non-packaging bugs). Not that I think you disagree on that point. Just that it may shape the timeframe in which any changes need to happen in. Anyway, I'll leave the discussion to folks that can actually implement the needed changes. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When I think about all the crap I learned in high school ... it's a wonder I can think at all. -- Paul Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From a.badger at gmail.com Mon Jun 18 18:31:31 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 18 Jun 2007 11:31:31 -0700 Subject: Script to determinate packages wich need comaintainership In-Reply-To: <20070618180027.GO32409@psilocybe.teonanacatl.org> References: <46759285.7050206@herr-schmitt.de> <20070618001505.289880b0@alkaid.a.lan> <604aa7910706180934y5f55d4d0gc8dcf3550a2c61c@mail.gmail.com> <20070618171002.GK32409@psilocybe.teonanacatl.org> <604aa7910706181031j59854763ga9336c0739ac0c84@mail.gmail.com> <20070618180027.GO32409@psilocybe.teonanacatl.org> Message-ID: <1182191491.13047.39.camel@localhost.localdomain> On Mon, 2007-06-18 at 14:00 -0400, Todd Zullinger wrote: > Jeff Spaleta wrote: > > Here's the question that I need answering. > > > > What is the process by which upstream developers can take some to > > all of the maintainership duties of currently existing packages? > > The fedora sponsorship process is driven around the concept of > > package submission... but how do we get people sponsored for > > maintainership for packages that already exist? > > It would need another level of access, just below full maintainer > level. Is that something that the PackageDB can help with at all? > I think these would be the technical things that need to be addressed to add just this features: A) cvs ACL system that understands groups. c4chris sent a patch that should do this for the current code. I'll take another look at this and apply it. It shouldn't actually do anything until we do the rest of the steps. B) a new group who's acl allows them to checkout/connect to the cvs server but not commit. C) Modification to our acl generating scripts to output the group definitions and new acls based on them. Something like: D) Upstream will need to have an account in the FAS. [*]_ 1: [all packages] | [anyone] | deny 2: [all packages] | @cvsadmin | allow 3: [packages with no current policy] | @cvsextras | allow 4: [packages with policy] | user1,user2,user3 | allow Notice that this definition does not include the new group anywhere. A user in the new group only gains access by being explicitly listed on a line like #4. [*]_: This leads us into the non-technical realm. Currently, everyone who can contributes content directly (docs, packages committed to cvs, etc) agrees to the CLA. Must upstream maintainers sign the CLA as well? If (A) works as expected only (C) would need coding. I'm working to get the PackageDB out this week or early next so my inclination is to wait until that is out and rewrite the script from within that framework once (D) is decided. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Jun 18 18:54:59 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 18 Jun 2007 14:54:59 -0400 Subject: Script to determinate packages wich need comaintainership In-Reply-To: <1182191491.13047.39.camel@localhost.localdomain> References: <46759285.7050206@herr-schmitt.de> <20070618001505.289880b0@alkaid.a.lan> <604aa7910706180934y5f55d4d0gc8dcf3550a2c61c@mail.gmail.com> <20070618171002.GK32409@psilocybe.teonanacatl.org> <604aa7910706181031j59854763ga9336c0739ac0c84@mail.gmail.com> <20070618180027.GO32409@psilocybe.teonanacatl.org> <1182191491.13047.39.camel@localhost.localdomain> Message-ID: <20070618185458.GC16470@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > A) cvs ACL system that understands groups. c4chris sent a patch that > should do this for the current code. I'll take another look at this and > apply it. It shouldn't actually do anything until we do the rest of the > steps. > B) a new group who's acl allows them to checkout/connect to the cvs > server but not commit. > C) Modification to our acl generating scripts to output the group > definitions and new acls based on them. Something like: > D) Upstream will need to have an account in the FAS. [*]_ > > 1: [all packages] | [anyone] | deny > 2: [all packages] | @cvsadmin | allow > 3: [packages with no current policy] | @cvsextras | allow > 4: [packages with policy] | user1,user2,user3 | allow > > Notice that this definition does not include the new group anywhere. A > user in the new group only gains access by being explicitly listed on a > line like #4. Will still fail without either filesystem level ACLs or permission changes due to being unable to write to the rawh files. Unless I'm misreading? Bill From a.badger at gmail.com Mon Jun 18 19:08:38 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 18 Jun 2007 12:08:38 -0700 Subject: Script to determinate packages wich need comaintainership In-Reply-To: <20070618185458.GC16470@nostromo.devel.redhat.com> References: <46759285.7050206@herr-schmitt.de> <20070618001505.289880b0@alkaid.a.lan> <604aa7910706180934y5f55d4d0gc8dcf3550a2c61c@mail.gmail.com> <20070618171002.GK32409@psilocybe.teonanacatl.org> <604aa7910706181031j59854763ga9336c0739ac0c84@mail.gmail.com> <20070618180027.GO32409@psilocybe.teonanacatl.org> <1182191491.13047.39.camel@localhost.localdomain> <20070618185458.GC16470@nostromo.devel.redhat.com> Message-ID: <1182193718.13047.59.camel@localhost.localdomain> On Mon, 2007-06-18 at 14:54 -0400, Bill Nottingham wrote: > Toshio Kuratomi (a.badger at gmail.com) said: > > A) cvs ACL system that understands groups. c4chris sent a patch that > > should do this for the current code. I'll take another look at this and > > apply it. It shouldn't actually do anything until we do the rest of the > > steps. > > B) a new group who's acl allows them to checkout/connect to the cvs > > server but not commit. > > C) Modification to our acl generating scripts to output the group > > definitions and new acls based on them. Something like: > > D) Upstream will need to have an account in the FAS. [*]_ > > > > 1: [all packages] | [anyone] | deny > > 2: [all packages] | @cvsadmin | allow > > 3: [packages with no current policy] | @cvsextras | allow > > 4: [packages with policy] | user1,user2,user3 | allow > > > > Notice that this definition does not include the new group anywhere. A > > user in the new group only gains access by being explicitly listed on a > > line like #4. > > Will still fail without either filesystem level ACLs or permission > changes due to being unable to write to the rawh files. Unless I'm > misreading? I haven't mucked with cvs repositories in a while so you could be right. If I'm reading the code and the repository correctly, things should work if we change the filesystem group from cvsextras to a new group like "cvsuser" and add everyone in that group, right? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Jun 18 19:16:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 18 Jun 2007 15:16:46 -0400 Subject: Script to determinate packages wich need comaintainership In-Reply-To: <1182193718.13047.59.camel@localhost.localdomain> References: <46759285.7050206@herr-schmitt.de> <20070618001505.289880b0@alkaid.a.lan> <604aa7910706180934y5f55d4d0gc8dcf3550a2c61c@mail.gmail.com> <20070618171002.GK32409@psilocybe.teonanacatl.org> <604aa7910706181031j59854763ga9336c0739ac0c84@mail.gmail.com> <20070618180027.GO32409@psilocybe.teonanacatl.org> <1182191491.13047.39.camel@localhost.localdomain> <20070618185458.GC16470@nostromo.devel.redhat.com> <1182193718.13047.59.camel@localhost.localdomain> Message-ID: <20070618191646.GD16470@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > I haven't mucked with cvs repositories in a while so you could be right. > If I'm reading the code and the repository correctly, things should work > if we change the filesystem group from cvsextras to a new group like > "cvsuser" and add everyone in that group, right? Should, yes. But that removes some of the sandboxing having them as !cvsextras would have. Bill From petersen at redhat.com Tue Jun 19 03:19:42 2007 From: petersen at redhat.com (Jens Petersen) Date: Tue, 19 Jun 2007 13:19:42 +1000 Subject: Merging Core and Extras Bugzilla Products In-Reply-To: <1181939448.28801.106.camel@localhost.localdomain> References: <1181939448.28801.106.camel@localhost.localdomain> Message-ID: <46774B4E.8080206@redhat.com> > The Fedora Core and Fedora Extras Bugzilla products will be merged into > a single Fedora product Sometime Very Soon (TM). This seems to have now happened :) so I went ahead and started editing some of the most obvious bugzilla links in the wiki. But there are many more left: http://fedoraproject.org/wiki/?action=fullsearch&context=180&value=product%3DFedora&fullsearch=Text Jens ps Probably an announcement should also go to fedora-devel-announce? From bpepple at fedoraproject.org Tue Jun 19 03:28:18 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 18 Jun 2007 23:28:18 -0400 Subject: FESCo elections Message-ID: <1182223698.2796.0.camel@kennedy> Hi all, This is a reminder that we are still in the self-nominations phase for the upcoming FESCo election. If you are interested in being part of the committee that oversees the engineering side of Fedora, you might want to consider running for a seat. If your interested, please place your nomination on this page in the wiki: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations Originally, we were planning to have the election this week, but with the Fedora Board having their election soon, it made sense to push the FESCo election back a bit, since we haven't had a lot of people nominated yet. So, the plan is to have the FESCo election the week after the Fedora Board election. I will be sending out another reminder as we get closer to that date. For more information regarding the election, please refer to this: http://fedoraproject.org/wiki/Extras/Policy/FESCoElections Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Tue Jun 19 03:28:18 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 18 Jun 2007 23:28:18 -0400 Subject: FESCo elections Message-ID: <1182223698.2796.0.camel@kennedy> Hi all, This is a reminder that we are still in the self-nominations phase for the upcoming FESCo election. If you are interested in being part of the committee that oversees the engineering side of Fedora, you might want to consider running for a seat. If your interested, please place your nomination on this page in the wiki: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations Originally, we were planning to have the election this week, but with the Fedora Board having their election soon, it made sense to push the FESCo election back a bit, since we haven't had a lot of people nominated yet. So, the plan is to have the FESCo election the week after the Fedora Board election. I will be sending out another reminder as we get closer to that date. For more information regarding the election, please refer to this: http://fedoraproject.org/wiki/Extras/Policy/FESCoElections 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 Tue Jun 19 11:55:07 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 19 Jun 2007 13:55:07 +0200 Subject: EPEL report week 24, 2007 Message-ID: <4677C41B.3060209@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week24 = Weekly EPEL Summary = Week 24/2007 == Most important happenings == The EPEL Steering Committee discussed the repotags issue once again and once again voted to not use repotags for EPEL. Some discussions started after that; see https://www.redhat.com/archives/epel-devel-list/2007-June/msg00041.html for their start. == EPEL SIG Meeting == === Attending === >From the Steering Committee: * knurd (ThorstenLeemhuis) (partly) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * dgilmore (DennisGilmore) * stahnma (MichaelStahnke) * quiad (KarstenWade) (had fun at the dentist) Missing from the Steering Committee: nobody Others that participated the meeting: Jeff_S, smooge, notting, lancelan, f13, spot, === Summary === * lots of discussion around repotags again; see the full log for details; four votes against repotags, two people are undecided; so once again the decision is "no repotags" * EPEL mock configs in Fedora's mock package -- should be part of the latest release * comps.xml for EPEL -- dgilmore is working on it; he'll check something into cvs soon and then post to the list asking people to look over it * finish the wiki docs and remove the warnings by end of may ; quaid, puts in up on his to-do list as a high priority == Stats == === General === Number of EPEL Contributors 90 We welcome 4 new contributors: dan_AT_danny.cz, jafo-redhat_AT_tummy.com, jafo_AT_tummy.com, mmahut_AT_redhat.com, rob.myers_AT_gtri.gatech.edu, ville.skytta_AT_iki.fi === EPEL 5 === Number of source packages: 359 Number of binary packages: 578 There are 48 new Packages: * akode | Audio-decoding framework * bonnie++ | Filesystem and disk benchmark & burn-in suite * digitemp | Dallas Semiconductor 1-wire device reading console application * exiv2 | Exif and Iptc metadata manipulation library * factory | C++ class library for multivariate polynomial data * fltk | C++ user interface toolkit * gc | C++ Garbage Collector * glump | A small web application to glue files from multiple sources * kannel | WAP and SMS gateway * kflickr | Standalone Flickr Uploader for KDE * kodos | Visual regular expression editor * libfac | An extension to Singular-factory * libksba | X.509 library * lua | Powerful light-weight programming language * Macaulay2 | System for algebraic geometry and commutative algebra * maxima | Symbolic Computation Program * mdsplib | METAR Decoder Software Package Library * nikto | Web server scanner * ntfs-config | A front-end to Enable/disable NTFS write support * ntl | High-performance algorithms for vectors, matrices, and polynomials * OpenEXR | A high dynamic-range (HDR) image file format * openslp | Open implementation of Service Location Protocol V2 * perl-Convert-BinHex | Macintosh BinHex extractor library for Perl * perl-GDGraph | Graph generation package for Perl * perl-GD | Perl interface to the GD graphics library * perl-GDTextUtil | Text utilities for use with GD * perl-IO-stringy | I/O on in-core objects like strings and arrays for Perl * perl-MIME-tools | Modules for parsing and creating MIME entities in Perl * php-pear-PhpDocumentor | The complete documentation solution for PHP * postgresql-pgpoolAdmin | PgpoolAdmin - web-based pgpool administration * python-genshi | Toolkit for stream-based generation of output for the web * python-imaging | Python's own image processing library * python-IPy | Python module for handling IPv4 and IPv6 Addresses and Networks * python-kid | Kid - A simple and pythonic XML template language * python-pgsql | Enhanced python interface to PostgreSQL * qgit | QGit is a git GUI repository browser * redet-doc | Documentation for redet * redet | Regular expression development and execution tool * sbcl | Steel Bank Common Lisp * SDL_image | Image loading library for SDL * SDL_mixer | Simple DirectMedia Layer - Sample Mixer Library * SDL_net | SDL portable network library * SDL_ttf | Simple DirectMedia Layer TrueType Font library * xar | The eXtensible ARchiver * xdg-utils | Basic desktop integration functions * xforms | XForms toolkit library === EPEL 4 === Number of source packages: 230 Number of binary packages: 423 There are 19 new Packages: * bonnie++ | Filesystem and disk benchmark & burn-in suite * digitemp | Dallas Semiconductor 1-wire device reading console application * lua | A powerful light-weight programming language * mdsplib | METAR Decoder Software Package Library * mock | Builds packages inside chroots * nikto | Web server scanner * perl-Convert-BinHex | Macintosh BinHex extractor library for Perl * perl-IO-stringy | I/O on in-core objects like strings and arrays for Perl * postgresql-pgpoolAdmin | PgpoolAdmin - web-based pgpool administration * python-IPy | Python module for handling IPv4 and IPv6 Addresses and Networks * python-pgsql | Enhanced python interface to PostgreSQL * qgit | QGit is a git GUI repository browser * redet-doc | Documentation for redet * redet | Regular expression development and execution tool * SDL_image | Image loading library for SDL * SDL_mixer | Simple DirectMedia Layer - Sample Mixer Library * SDL_net | SDL portable network library * SDL_ttf | Simple DirectMedia Layer TrueType Font library * xar | The eXtensible ARchiver ---- ["CategoryEPELReports"] From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jun 19 12:38:57 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Jun 2007 14:38:57 +0200 Subject: Portaudio v19 update Message-ID: <20070619143857.6dbdba3b@python3.es.egwn.lan> Hi, I've updated the devel portaudio package from v18 to v19, since it has been promoted to "stable" at the end of 2006, which breaks binary compatibility. I don't have any packages on my system which require portaudio, but I'm sending out this email anyway just in case. But note that some projects possibly required v19 to enable portaudio support, so this might be the time to give it another look. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 0.31 0.40 0.38 From laxathom at fedoraproject.org Tue Jun 19 12:54:35 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Tue, 19 Jun 2007 08:54:35 -0400 Subject: Portaudio v19 update In-Reply-To: <20070619143857.6dbdba3b@python3.es.egwn.lan> References: <20070619143857.6dbdba3b@python3.es.egwn.lan> Message-ID: <62bc09df0706190554uce3523eg587a24f1c59e4861@mail.gmail.com> 2007/6/19, Matthias Saou < thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net>: > > Hi, > > I've updated the devel portaudio package from v18 to v19, since it has > been promoted to "stable" at the end of 2006, which breaks binary > compatibility. > > I don't have any packages on my system which require portaudio, but I'm > sending out this email anyway just in case. But note that some > projects possibly required v19 to enable portaudio support, so this > might be the time to give it another look. \\o// Well, i will now be able to enable portaudio support for Wengophone which require v19. actually i used some patch to make it work with v18 but now it'll work better with v19. i'll send you feedback if you want. thanks Matthias > > -- > Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ > Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 > Load : 0.31 0.40 0.38 > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jun 19 13:05:27 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Jun 2007 15:05:27 +0200 Subject: SDL_gfx update to 2.0.16 Message-ID: <20070619150527.199a1642@python3.es.egwn.lan> Hi, I've updated the devel SDL_gfx to the latest release. The soname bump (hmm, it's a decrease, actually...) will require rebuilds of all packages build requiring it. Quickly looking at my system, I see that perl-SDL will need a rebuild (Hans! ;-)). Possibly others, but few for sure. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 0.78 0.76 0.51 From atkac at redhat.com Tue Jun 19 13:13:36 2007 From: atkac at redhat.com (Adam Tkac) Date: Tue, 19 Jun 2007 15:13:36 +0200 Subject: SDL_gfx update to 2.0.16 In-Reply-To: <20070619150527.199a1642@python3.es.egwn.lan> References: <20070619150527.199a1642@python3.es.egwn.lan> Message-ID: <4677D680.4000004@redhat.com> Matthias Saou napsal(a): > Hi, > > I've updated the devel SDL_gfx to the latest release. The soname bump > (hmm, it's a decrease, actually...) will require rebuilds of all > packages build requiring it. > > Quickly looking at my system, I see that perl-SDL will need a rebuild > (Hans! ;-)). Possibly others, but few for sure. > > Matthias This could be list of all packages whose could be affected: xblast-0:2.10.4-2.fc7.i386 mjpegtools-gui-0:1.9.0-0.1.rc2.lvn8.i386 openlierox-0:0.57-0.3.beta2.fc7.i386 wormux-0:0.7.9-3.fc7.i386 lincity-ng-0:1.1.0-1.fc7.i386 ClanLib-0:0.8.0-4.fc7.i386 glyph-keeper-0:0.32-1.fc7.i386 perl-SDL-0:2.1.3-3.fc6.i386 Adam From j.w.r.degoede at hhs.nl Tue Jun 19 14:42:43 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 19 Jun 2007 16:42:43 +0200 Subject: SDL_gfx update to 2.0.16 In-Reply-To: <4677D680.4000004@redhat.com> References: <20070619150527.199a1642@python3.es.egwn.lan> <4677D680.4000004@redhat.com> Message-ID: <4677EB63.8040201@hhs.nl> Adam Tkac wrote: > Matthias Saou napsal(a): >> Hi, >> >> I've updated the devel SDL_gfx to the latest release. The soname bump >> (hmm, it's a decrease, actually...) will require rebuilds of all >> packages build requiring it. >> >> Quickly looking at my system, I see that perl-SDL will need a rebuild >> (Hans! ;-)). Possibly others, but few for sure. >> >> Matthias > This could be list of all packages whose could be affected: > > xblast-0:2.10.4-2.fc7.i386 > mjpegtools-gui-0:1.9.0-0.1.rc2.lvn8.i386 > openlierox-0:0.57-0.3.beta2.fc7.i386 > wormux-0:0.7.9-3.fc7.i386 > lincity-ng-0:1.1.0-1.fc7.i386 > ClanLib-0:0.8.0-4.fc7.i386 > glyph-keeper-0:0.32-1.fc7.i386 > perl-SDL-0:2.1.3-3.fc6.i386 > 6 of of which are mine, since I'm flying to Israel for the wedding of a friend of mine tonight, I will not have the time todo this. I hereby give others a blanket permission todo this for me, and I have opened up access to all my packages to allow this. xblast-0:2.10.4-2.fc7.i386 openlierox-0:0.57-0.3.beta2.fc7.i386 wormux-0:0.7.9-3.fc7.i386 ClanLib-0:0.8.0-4.fc7.i386 glyph-keeper-0:0.32-1.fc7.i386 perl-SDL-0:2.1.3-3.fc6.i386 Thanks & Regards, Hans From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jun 19 14:51:55 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Jun 2007 16:51:55 +0200 Subject: SDL_gfx update to 2.0.16 In-Reply-To: <4677EB63.8040201@hhs.nl> References: <20070619150527.199a1642@python3.es.egwn.lan> <4677D680.4000004@redhat.com> <4677EB63.8040201@hhs.nl> Message-ID: <20070619165155.24c5f358@python3.es.egwn.lan> Hans de Goede wrote : > Adam Tkac wrote: > > Matthias Saou napsal(a): > >> Hi, > >> > >> I've updated the devel SDL_gfx to the latest release. The soname bump > >> (hmm, it's a decrease, actually...) will require rebuilds of all > >> packages build requiring it. > >> > >> Quickly looking at my system, I see that perl-SDL will need a rebuild > >> (Hans! ;-)). Possibly others, but few for sure. > >> > >> Matthias > > This could be list of all packages whose could be affected: > > > > xblast-0:2.10.4-2.fc7.i386 > > mjpegtools-gui-0:1.9.0-0.1.rc2.lvn8.i386 > > openlierox-0:0.57-0.3.beta2.fc7.i386 > > wormux-0:0.7.9-3.fc7.i386 > > lincity-ng-0:1.1.0-1.fc7.i386 > > ClanLib-0:0.8.0-4.fc7.i386 > > glyph-keeper-0:0.32-1.fc7.i386 > > perl-SDL-0:2.1.3-3.fc6.i386 > > > > 6 of of which are mine, since I'm flying to Israel for the wedding of a friend > of mine tonight, I will not have the time todo this. I hereby give others a > blanket permission todo this for me, and I have opened up access to all my > packages to allow this. > xblast-0:2.10.4-2.fc7.i386 > openlierox-0:0.57-0.3.beta2.fc7.i386 > wormux-0:0.7.9-3.fc7.i386 > ClanLib-0:0.8.0-4.fc7.i386 > glyph-keeper-0:0.32-1.fc7.i386 > perl-SDL-0:2.1.3-3.fc6.i386 This is devel, no rush. But I'll rebuild them then, it's no problem at all ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 2.37 1.56 1.36 From j.w.r.degoede at hhs.nl Tue Jun 19 14:49:57 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 19 Jun 2007 16:49:57 +0200 Subject: I'll be away (on holliday) for the coming week Message-ID: <4677ED15.3030500@hhs.nl> Hi all, A close friend of mine is getting maried in Israel in two days, I'll be flying to Israel tonight, and stay there for about a week. Thus I will not be available to answer bug reports, etc. I hereby give others with CVS access permission to make any necessary fixes for urgent issues like broken deps in rawhide. I might have internet access at the hotel and then I might read my mail, but don't count on it :) Regards, Hans From j.w.r.degoede at hhs.nl Tue Jun 19 14:40:59 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 19 Jun 2007 16:40:59 +0200 Subject: ACL removal day?! Message-ID: <4677EAFB.50000@hhs.nl> Hi All, After receiving the below mail from Matthias and not being able todo the rebuild myself as I'm out of town for a week, I've decided to "implement" and old idea of mine, remove all pkg.acl files from my packages so that others can fix them when needed. I invite everyone else who never felt the need for ACL's to join me, and hereby declare this day ACL removal day. Regards, Hans --- Hi, I've updated the devel SDL_gfx to the latest release. The soname bump (hmm, it's a decrease, actually...) will require rebuilds of all packages build requiring it. Quickly looking at my system, I see that perl-SDL will need a rebuild (Hans! ;-)). Possibly others, but few for sure. Matthias From jima at beer.tclug.org Tue Jun 19 15:17:35 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 19 Jun 2007 10:17:35 -0500 (CDT) Subject: ACL removal day?! In-Reply-To: <4677EAFB.50000@hhs.nl> References: <4677EAFB.50000@hhs.nl> Message-ID: On Tue, 19 Jun 2007, Hans de Goede wrote: > I invite everyone else who never felt the need for ACL's to join me, and > hereby declare this day ACL removal day. Hmm, good idea. You're also raising awareness; I hadn't even noticed that my two newest packages *had* pkg.acl files, which I'm now remedying. Jima From belegdol at gmail.com Tue Jun 19 15:38:17 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Tue, 19 Jun 2007 16:38:17 +0100 Subject: ACL removal day?! In-Reply-To: References: <4677EAFB.50000@hhs.nl> Message-ID: <9b1b20e70706190838p78b4a939w119a2efa8b0c14f0@mail.gmail.com> 2007/6/19, Jima : > On Tue, 19 Jun 2007, Hans de Goede wrote: > > I invite everyone else who never felt the need for ACL's to join me, and > > hereby declare this day ACL removal day. > > Hmm, good idea. You're also raising awareness; I hadn't even noticed > that my two newest packages *had* pkg.acl files, which I'm now remedying. > > Jima > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > All my packages have open access for anyone, they have always had since I am killing pkg.acl right after import. Cheers, Julian From ajackson at redhat.com Tue Jun 19 15:31:28 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 19 Jun 2007 11:31:28 -0400 Subject: ACL removal day?! In-Reply-To: References: <4677EAFB.50000@hhs.nl> Message-ID: <1182267088.30663.174.camel@localhost.localdomain> On Tue, 2007-06-19 at 10:17 -0500, Jima wrote: > On Tue, 19 Jun 2007, Hans de Goede wrote: > > I invite everyone else who never felt the need for ACL's to join me, and > > hereby declare this day ACL removal day. > > Hmm, good idea. You're also raising awareness; I hadn't even noticed > that my two newest packages *had* pkg.acl files, which I'm now remedying. Suggestion for FESCO: new packages must explicitly request an ACL. - ajax From sundaram at fedoraproject.org Tue Jun 19 15:42:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Jun 2007 21:12:48 +0530 Subject: ACL removal day?! In-Reply-To: <1182267088.30663.174.camel@localhost.localdomain> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> Message-ID: <4677F978.3090806@fedoraproject.org> Adam Jackson wrote: > On Tue, 2007-06-19 at 10:17 -0500, Jima wrote: >> On Tue, 19 Jun 2007, Hans de Goede wrote: >>> I invite everyone else who never felt the need for ACL's to join me, and >>> hereby declare this day ACL removal day. >> Hmm, good idea. You're also raising awareness; I hadn't even noticed >> that my two newest packages *had* pkg.acl files, which I'm now remedying. > > Suggestion for FESCO: new packages must explicitly request an ACL. I would go further. Even for existing packages, package maintainers must specify good reasons for retaining ACL's and that must be documented explicitly in some prominent place. Rahul From rc040203 at freenet.de Tue Jun 19 15:46:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 19 Jun 2007 17:46:13 +0200 Subject: ACL removal day?! In-Reply-To: <1182267088.30663.174.camel@localhost.localdomain> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> Message-ID: <1182267974.29976.8.camel@mccallum.corsepiu.local> On Tue, 2007-06-19 at 11:31 -0400, Adam Jackson wrote: > On Tue, 2007-06-19 at 10:17 -0500, Jima wrote: > > On Tue, 19 Jun 2007, Hans de Goede wrote: > > > I invite everyone else who never felt the need for ACL's to join me, and > > > hereby declare this day ACL removal day. > > > > Hmm, good idea. You're also raising awareness; I hadn't even noticed > > that my two newest packages *had* pkg.acl files, which I'm now remedying. > > Suggestion for FESCO: new packages must explicitly request an ACL. > > - ajax +1 Ralf From dwmw2 at infradead.org Tue Jun 19 15:49:09 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 19 Jun 2007 23:49:09 +0800 Subject: ACL removal day?! In-Reply-To: <4677F978.3090806@fedoraproject.org> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> Message-ID: <1182268150.3016.105.camel@shinybook.infradead.org> On Tue, 2007-06-19 at 21:12 +0530, Rahul Sundaram wrote: > I would go further. Even for existing packages, package maintainers must > specify good reasons for retaining ACL's and that must be documented > explicitly in some prominent place. Absolutely. And the existing ACLs which were added without the knowledge or consent of the package maintainer should be removed immediately. -- dwmw2 From dwmw2 at infradead.org Tue Jun 19 15:50:40 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 19 Jun 2007 23:50:40 +0800 Subject: Portaudio v19 update In-Reply-To: <20070619143857.6dbdba3b@python3.es.egwn.lan> References: <20070619143857.6dbdba3b@python3.es.egwn.lan> Message-ID: <1182268241.3016.109.camel@shinybook.infradead.org> On Tue, 2007-06-19 at 14:38 +0200, Matthias Saou wrote: > I've updated the devel portaudio package from v18 to v19, since it has > been promoted to "stable" at the end of 2006, which breaks binary > compatibility. Ooh, shiny. Does this mean we can have audacity with ALSA support? -- dwmw2 From Christian.Iseli at licr.org Tue Jun 19 15:49:57 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 19 Jun 2007 17:49:57 +0200 Subject: ACL removal day?! In-Reply-To: <1182267088.30663.174.camel@localhost.localdomain> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> Message-ID: <20070619174957.55051b84@ludwig-alpha.unil.ch> On Tue, 19 Jun 2007 11:31:28 -0400, Adam Jackson wrote: > Suggestion for FESCO: new packages must explicitly request an ACL. I'm all for it, but I was lead to believe that putting ACLs *by default* was a "sine qua non" of the Core + Extras merge... Cheers, C From SteveD at redhat.com Tue Jun 19 15:52:51 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 19 Jun 2007 11:52:51 -0400 Subject: ACL removal day?! In-Reply-To: <4677F978.3090806@fedoraproject.org> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> Message-ID: <4677FBD3.6080602@RedHat.com> Rahul Sundaram wrote: > Adam Jackson wrote: >> On Tue, 2007-06-19 at 10:17 -0500, Jima wrote: >>> On Tue, 19 Jun 2007, Hans de Goede wrote: >>>> I invite everyone else who never felt the need for ACL's to join me, >>>> and hereby declare this day ACL removal day. >>> Hmm, good idea. You're also raising awareness; I hadn't even >>> noticed that my two newest packages *had* pkg.acl files, which I'm >>> now remedying. >> >> Suggestion for FESCO: new packages must explicitly request an ACL. > > I would go further. Even for existing packages, package maintainers must > specify good reasons for retaining ACL's and that must be documented > explicitly in some prominent place. Does this include all packages like core packages like the kernel, setup and such? Things that are crucial to the stability of the system? steved. From pertusus at free.fr Tue Jun 19 15:56:01 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 19 Jun 2007 17:56:01 +0200 Subject: ACL removal day?! In-Reply-To: <4677FBD3.6080602@RedHat.com> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <4677FBD3.6080602@RedHat.com> Message-ID: <20070619155601.GB3144@free.fr> On Tue, Jun 19, 2007 at 11:52:51AM -0400, Steve Dickson wrote: > > > Does this include all packages like core packages like the kernel, setup > and such? Things that are crucial to the stability of the system? No, for those packages ACL are right. But for new packages, in general there is no need for ACL, new packages are more like former extras packages than former core packages. Of course there could be ACLs for some critical new packages, or for packagers who don't want others to touch their packages. -- Pat From pertusus at free.fr Tue Jun 19 15:58:52 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 19 Jun 2007 17:58:52 +0200 Subject: ACL removal day?! In-Reply-To: <20070619174957.55051b84@ludwig-alpha.unil.ch> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <20070619174957.55051b84@ludwig-alpha.unil.ch> Message-ID: <20070619155852.GC3144@free.fr> On Tue, Jun 19, 2007 at 05:49:57PM +0200, Christian Iseli wrote: > On Tue, 19 Jun 2007 11:31:28 -0400, Adam Jackson wrote: > > Suggestion for FESCO: new packages must explicitly request an ACL. > > I'm all for it, but I was lead to believe that putting ACLs *by default* > was a "sine qua non" of the Core + Extras merge... Maybe now that the core packages are merged with ACLs, the default could be set to what is most used for new packages which are, in general more like former extras packages and put by people with former extras 'ideology'. People can still add them afterwards. Couldn't it be discussed by FESCO? Or I recall vaguely that it already had been. -- Pat From bugs.michael at gmx.net Tue Jun 19 16:08:25 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 19 Jun 2007 18:08:25 +0200 Subject: Portaudio v19 update In-Reply-To: <1182268241.3016.109.camel@shinybook.infradead.org> References: <20070619143857.6dbdba3b@python3.es.egwn.lan> <1182268241.3016.109.camel@shinybook.infradead.org> Message-ID: <20070619180825.f7fe4fc7.bugs.michael@gmx.net> On Tue, 19 Jun 2007 23:50:40 +0800, David Woodhouse wrote: > On Tue, 2007-06-19 at 14:38 +0200, Matthias Saou wrote: > > I've updated the devel portaudio package from v18 to v19, since it has > > been promoted to "stable" at the end of 2006, which breaks binary > > compatibility. > > Ooh, shiny. Does this mean we can have audacity with ALSA support? Audacity in Fedora 6 and 7 is built with an included and modified PortAudio v19 and offers ALSA support. From limb at jcomserv.net Tue Jun 19 16:01:19 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 19 Jun 2007 11:01:19 -0500 (CDT) Subject: ACL removal day?! In-Reply-To: <20070619155852.GC3144@free.fr> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <20070619174957.55051b84@ludwig-alpha.unil.ch> <20070619155852.GC3144@free.fr> Message-ID: <44837.65.192.24.164.1182268879.squirrel@mail.jcomserv.net> > On Tue, Jun 19, 2007 at 05:49:57PM +0200, Christian Iseli wrote: >> On Tue, 19 Jun 2007 11:31:28 -0400, Adam Jackson wrote: >> > Suggestion for FESCO: new packages must explicitly request an ACL. >> >> I'm all for it, but I was lead to believe that putting ACLs *by default* >> was a "sine qua non" of the Core + Extras merge... > > Maybe now that the core packages are merged with ACLs, the default could > be set to what is most used for new packages which are, in general more > like former extras packages and put by people with former extras > 'ideology'. People can still add them afterwards. > > Couldn't it be discussed by FESCO? Or I recall vaguely that it already > had been. It was, and IIRC the reason it is as it is is that* the default provides security and can be easily opened up, but won't leave an unsuspecting packager with a community-alterable package without their intervention. That said, I prefer an open model and keep meaning to get around to whacking my acls. But I don't think there's much reason to change the current policy, as it maximizes choice, security, and minimized work for the admin side of the equation. Just my 2000 lire. * this is technically correct English. Damn. > -- > Pat > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From notting at redhat.com Tue Jun 19 16:07:35 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Jun 2007 12:07:35 -0400 Subject: ACL removal day?! In-Reply-To: <4677F978.3090806@fedoraproject.org> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> Message-ID: <20070619160735.GC19682@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > I would go further. Even for existing packages, package maintainers must > specify good reasons for retaining ACL's and that must be documented > explicitly in some prominent place. I'd NAK this. If you don't want them on your own package, you're free to remove them. Bill From SteveD at redhat.com Tue Jun 19 16:11:54 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 19 Jun 2007 12:11:54 -0400 Subject: ACL removal day?! In-Reply-To: <20070619160735.GC19682@nostromo.devel.redhat.com> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <20070619160735.GC19682@nostromo.devel.redhat.com> Message-ID: <4678004A.1010400@RedHat.com> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> I would go further. Even for existing packages, package maintainers must >> specify good reasons for retaining ACL's and that must be documented >> explicitly in some prominent place. > > I'd NAK this. If you don't want them on your own package, you're free to > remove them. Right... The maintainer must have the final says as to what does or does not happen to that their packages... Responsibility along with accountability is a good thing imho... steved. From sundaram at fedoraproject.org Tue Jun 19 16:18:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Jun 2007 21:48:00 +0530 Subject: ACL removal day?! In-Reply-To: <4677FBD3.6080602@RedHat.com> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <4677FBD3.6080602@RedHat.com> Message-ID: <467801B8.6070505@fedoraproject.org> Steve Dickson wrote: >> >> I would go further. Even for existing packages, package maintainers >> must specify good reasons for retaining ACL's and that must be >> documented explicitly in some prominent place. > Does this include all packages like core packages like the kernel, setup > and such? Things that are crucial to the stability of the system? Sure. Documenting the select set of packages which are considered very critical shouldn't be a problem at all. Rahul From martin.sourada at seznam.cz Tue Jun 19 16:20:11 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 19 Jun 2007 18:20:11 +0200 Subject: ACL removal day?! In-Reply-To: <44837.65.192.24.164.1182268879.squirrel@mail.jcomserv.net> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <20070619174957.55051b84@ludwig-alpha.unil.ch> <20070619155852.GC3144@free.fr> <44837.65.192.24.164.1182268879.squirrel@mail.jcomserv.net> Message-ID: <1182270011.31675.2.camel@pc-notebook> On Tue, 2007-06-19 at 18:01 +0200, Jon Ciesla wrote: > It was, and IIRC the reason it is as it is is that* the default provides > security and can be easily opened up, but won't leave an unsuspecting > packager with a community-alterable package without their intervention. > > That said, I prefer an open model and keep meaning to get around to > whacking my acls. But I don't think there's much reason to change the > current policy, as it maximizes choice, security, and minimized work for > the admin side of the equation. Just my 2000 lire. > Yep, totally agree with it. I think this policy is good, nevertheless I'll remove my ACLs as well (probably tomorrow). > * this is technically correct English. Damn. > Yep, English is a wonderful language, don't you think? :-) > > -- > > Pat > > > > -- > > Fedora-maintainers mailing list > > Fedora-maintainers at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-maintainers > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wart at kobold.org Tue Jun 19 16:21:25 2007 From: wart at kobold.org (Michael Thomas) Date: Tue, 19 Jun 2007 09:21:25 -0700 Subject: SDL_gfx update to 2.0.16 In-Reply-To: <4677EB63.8040201@hhs.nl> References: <20070619150527.199a1642@python3.es.egwn.lan> <4677D680.4000004@redhat.com> <4677EB63.8040201@hhs.nl> Message-ID: <46780285.90402@kobold.org> Hans de Goede wrote: > Adam Tkac wrote: >> Matthias Saou napsal(a): >>> Hi, >>> >>> I've updated the devel SDL_gfx to the latest release. The soname bump >>> (hmm, it's a decrease, actually...) will require rebuilds of all >>> packages build requiring it. >>> >>> Quickly looking at my system, I see that perl-SDL will need a rebuild >>> (Hans! ;-)). Possibly others, but few for sure. >>> >>> Matthias >> This could be list of all packages whose could be affected: >> >> xblast-0:2.10.4-2.fc7.i386 >> mjpegtools-gui-0:1.9.0-0.1.rc2.lvn8.i386 >> openlierox-0:0.57-0.3.beta2.fc7.i386 >> wormux-0:0.7.9-3.fc7.i386 >> lincity-ng-0:1.1.0-1.fc7.i386 >> ClanLib-0:0.8.0-4.fc7.i386 >> glyph-keeper-0:0.32-1.fc7.i386 >> perl-SDL-0:2.1.3-3.fc6.i386 >> > > 6 of of which are mine, since I'm flying to Israel for the wedding of a > friend of mine tonight, I will not have the time todo this. I hereby > give others a blanket permission todo this for me, and I have opened up > access to all my packages to allow this. > xblast-0:2.10.4-2.fc7.i386 > openlierox-0:0.57-0.3.beta2.fc7.i386 > wormux-0:0.7.9-3.fc7.i386 Actually, wormux is mine. But I retroactively grant you permission to grant Matthias permission to rebuild it for me, which he already did. :) --Wart From ville.skytta at iki.fi Tue Jun 19 16:31:50 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 19 Jun 2007 19:31:50 +0300 Subject: Portaudio v19 update In-Reply-To: <20070619143857.6dbdba3b@python3.es.egwn.lan> References: <20070619143857.6dbdba3b@python3.es.egwn.lan> Message-ID: <200706191931.50984.ville.skytta@iki.fi> On Tuesday 19 June 2007, Matthias Saou wrote: > I don't have any packages on my system which require portaudio, but I'm > sending out this email anyway just in case. $ repoquery --repoid=development --whatrequires --alldeps portaudio espeak-0:1.25-1.fc8.i386 espeak-0:1.25-1.fc8.x86_64 From SteveD at redhat.com Tue Jun 19 16:34:23 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 19 Jun 2007 12:34:23 -0400 Subject: ACL removal day?! In-Reply-To: <467801B8.6070505@fedoraproject.org> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <4677FBD3.6080602@RedHat.com> <467801B8.6070505@fedoraproject.org> Message-ID: <4678058F.9010807@RedHat.com> Rahul Sundaram wrote: > Steve Dickson wrote: >>> >>> I would go further. Even for existing packages, package maintainers >>> must specify good reasons for retaining ACL's and that must be >>> documented explicitly in some prominent place. >> Does this include all packages like core packages like the kernel, setup >> and such? Things that are crucial to the stability of the system? > > Sure. Documenting the select set of packages which are considered very > critical shouldn't be a problem at all. Well as long as the maintainer has the final say of what does or does not go into the package and who is or is not on the ACL list I guess opening up the critical packages would be Okay... I don't think its a good idea, but as long as there are some safeguards that will maintain stability it should be ok... Just curious... Do (or have) other distro opened up their packages to the world? I know FreeBSD does not... There is a maintainer list one need to be on to do commits... So is Fedora leading the pack this area?? steved. From caillon at redhat.com Tue Jun 19 16:33:42 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 19 Jun 2007 12:33:42 -0400 Subject: ACL removal day?! In-Reply-To: <1182268150.3016.105.camel@shinybook.infradead.org> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <1182268150.3016.105.camel@shinybook.infradead.org> Message-ID: <46780566.9080401@redhat.com> David Woodhouse wrote: > On Tue, 2007-06-19 at 21:12 +0530, Rahul Sundaram wrote: >> I would go further. Even for existing packages, package maintainers must >> specify good reasons for retaining ACL's and that must be documented >> explicitly in some prominent place. > > Absolutely. And the existing ACLs which were added without the knowledge > or consent of the package maintainer should be removed immediately. How do we know which ones were added without knowledge/consent? I for one know about them, and require them for some packages I own. I don't believe this info is tracked anywhere though. From sundaram at fedoraproject.org Tue Jun 19 16:43:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Jun 2007 22:13:36 +0530 Subject: ACL removal day?! In-Reply-To: <46780566.9080401@redhat.com> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <1182268150.3016.105.camel@shinybook.infradead.org> <46780566.9080401@redhat.com> Message-ID: <467807B8.7070907@fedoraproject.org> Christopher Aillon wrote: > David Woodhouse wrote: >> On Tue, 2007-06-19 at 21:12 +0530, Rahul Sundaram wrote: >>> I would go further. Even for existing packages, package maintainers >>> must specify good reasons for retaining ACL's and that must be >>> documented explicitly in some prominent place. >> >> Absolutely. And the existing ACLs which were added without the knowledge >> or consent of the package maintainer should be removed immediately. > > How do we know which ones were added without knowledge/consent? I for > one know about them, and require them for some packages I own. I don't > believe this info is tracked anywhere though. There is a pretty easy solution to that. Ask the maintainers. New package maintainers are likely to be not aware of the current policy of automatically adding ACL's to their packages. I suspect many of them would prefer to share the work in things that can be done by a group like rebuilding packages. Rahul From sundaram at fedoraproject.org Tue Jun 19 16:46:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Jun 2007 22:16:28 +0530 Subject: ACL removal day?! In-Reply-To: <4678058F.9010807@RedHat.com> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <4677FBD3.6080602@RedHat.com> <467801B8.6070505@fedoraproject.org> <4678058F.9010807@RedHat.com> Message-ID: <46780864.8020609@fedoraproject.org> Steve Dickson wrote: > Well as long as the maintainer has the final say of what does or > does not go into the package and who is or is not on the ACL list Definitely. Would you support giving blanket permission to select groups like FESCo or Fedora Security Team? > Just curious... Do (or have) other distro opened up their packages > to the world? I know FreeBSD does not... There is a maintainer > list one need to be on to do commits... So is Fedora leading > the pack this area?? Nobody is suggesting that packages be opened up to the entire world. The current discussion is about whether only the package maintainers should get access by default with ACL's blocking everybody else out or whether every maintainer should get access to a common package pool by default with exceptions as explicitly requested by package maintainers. Rahul From SteveD at redhat.com Tue Jun 19 16:51:34 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 19 Jun 2007 12:51:34 -0400 Subject: ACL removal day?! In-Reply-To: <46780864.8020609@fedoraproject.org> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <4677FBD3.6080602@RedHat.com> <467801B8.6070505@fedoraproject.org> <4678058F.9010807@RedHat.com> <46780864.8020609@fedoraproject.org> Message-ID: <46780996.6010005@RedHat.com> Rahul Sundaram wrote: > Nobody is suggesting that packages be opened up to the entire world. The > current discussion is about whether only the package maintainers should > get access by default with ACL's blocking everybody else out or whether > every maintainer should get access to a common package pool by default > with exceptions as explicitly requested by package maintainers. Cool... thanks for the clarification.... steved. From notting at redhat.com Tue Jun 19 16:58:31 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Jun 2007 12:58:31 -0400 Subject: ACL removal day?! In-Reply-To: <467807B8.7070907@fedoraproject.org> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <1182268150.3016.105.camel@shinybook.infradead.org> <46780566.9080401@redhat.com> <467807B8.7070907@fedoraproject.org> Message-ID: <20070619165831.GA21506@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > There is a pretty easy solution to that. Ask the maintainers. New > package maintainers are likely to be not aware of the current policy of > automatically adding ACL's to their packages. I suspect many of them > would prefer to share the work in things that can be done by a group > like rebuilding packages. ... then they are able to remove them, and we can discuss changing the defaults/adding something to the CVS request form/whatever. I'm not seeing the problem here? Bill From sundaram at fedoraproject.org Tue Jun 19 17:10:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Jun 2007 22:40:10 +0530 Subject: ACL removal day?! In-Reply-To: <20070619165831.GA21506@nostromo.devel.redhat.com> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <1182268150.3016.105.camel@shinybook.infradead.org> <46780566.9080401@redhat.com> <467807B8.7070907@fedoraproject.org> <20070619165831.GA21506@nostromo.devel.redhat.com> Message-ID: <46780DF2.4020205@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> There is a pretty easy solution to that. Ask the maintainers. New >> package maintainers are likely to be not aware of the current policy of >> automatically adding ACL's to their packages. I suspect many of them >> would prefer to share the work in things that can be done by a group >> like rebuilding packages. > > ... then they are able to remove them, and we can discuss changing the > defaults/adding something to the CVS request form/whatever. I'm not > seeing the problem here? The need for ACL's by default that restrict the package to only the package maintainers is not clear and package maintainers are not aware that ACL are added by default to their packages. If it is explicitly documented that ACL's are added by default that solves the latter problem. I would prefer that ACL are only added if explicitly requested since having a common pool allows some of the work (mass rebuilds, rebuilds for soname bumps, resolving conflicting files in between packages, E-V-R issues, security problems etc) to be shared by other package maintainers interested in maintaining the quality of the repository on the whole. Rahul From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jun 19 17:11:17 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Jun 2007 19:11:17 +0200 Subject: SDL_gfx update to 2.0.16 In-Reply-To: <46780285.90402@kobold.org> References: <20070619150527.199a1642@python3.es.egwn.lan> <4677D680.4000004@redhat.com> <4677EB63.8040201@hhs.nl> <46780285.90402@kobold.org> Message-ID: <20070619191117.070afc0c@python3.es.egwn.lan> Michael Thomas wrote : > > 6 of of which are mine, since I'm flying to Israel for the wedding of a > > friend of mine tonight, I will not have the time todo this. I hereby > > give others a blanket permission todo this for me, and I have opened up > > access to all my packages to allow this. > > xblast-0:2.10.4-2.fc7.i386 > > openlierox-0:0.57-0.3.beta2.fc7.i386 > > wormux-0:0.7.9-3.fc7.i386 > > Actually, wormux is mine. But I retroactively grant you permission to > grant Matthias permission to rebuild it for me, which he already did. :) Oops. Retroactive thanks! :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 0.19 0.30 0.37 From sgrubb at redhat.com Tue Jun 19 17:24:30 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 19 Jun 2007 13:24:30 -0400 Subject: ACL removal day?! In-Reply-To: <46780DF2.4020205@fedoraproject.org> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> Message-ID: <200706191324.30769.sgrubb@redhat.com> On Tuesday 19 June 2007 13:10:10 Rahul Sundaram wrote: > > ... then they are able to remove them, and we can discuss changing the > > defaults/adding something to the CVS request form/whatever. I'm not > > seeing the problem here? > > The need for ACL's by default that restrict the package to only the > package maintainers is not clear This needs to be clear. Its for security. If you take all ACLs off the packages and an account becomes compromised, the attacker can get to everything. Please keep the ACLs by default so that there is not a window where a package is left unguarded if it needed to be. -Steve From notting at redhat.com Tue Jun 19 17:26:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Jun 2007 13:26:18 -0400 Subject: ACL removal day?! In-Reply-To: <46780DF2.4020205@fedoraproject.org> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <1182268150.3016.105.camel@shinybook.infradead.org> <46780566.9080401@redhat.com> <467807B8.7070907@fedoraproject.org> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> Message-ID: <20070619172618.GB21506@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > The need for ACL's by default that restrict the package to only the > package maintainers is not clear and package maintainers are not aware > that ACL are added by default to their packages. If it is explicitly > documented that ACL's are added by default that solves the latter > problem. http://fedoraproject.org/wiki/JeremyKatz/DraftPackageAccess Jeremy, want to push that to finalized? Bill From fedora at leemhuis.info Tue Jun 19 17:33:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 19 Jun 2007 19:33:53 +0200 Subject: ACL removal day?! In-Reply-To: <200706191324.30769.sgrubb@redhat.com> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <200706191324.30769.sgrubb@redhat.com> Message-ID: <46781381.8030707@leemhuis.info> On 19.06.2007 19:24, Steve Grubb wrote: > On Tuesday 19 June 2007 13:10:10 Rahul Sundaram wrote: >>> ... then they are able to remove them, and we can discuss changing the >>> defaults/adding something to the CVS request form/whatever. I'm not >>> seeing the problem here? >> The need for ACL's by default that restrict the package to only the >> package maintainers is not clear > > This needs to be clear. Its for security. If you take all ACLs off the > packages and an account becomes compromised, the attacker can get to > everything. > > Please keep the ACLs by default so that there is not a window where a package > is left unguarded if it needed to be. I'd say we should work towards a middle ground -- ACLs by default, but create some kind of "trusted contributers group (say sponsors, FESCo members and packagers with more then 25 packages) that get access everywhere. Just my 2 cent. CU thl From sundaram at fedoraproject.org Tue Jun 19 17:39:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Jun 2007 23:09:55 +0530 Subject: ACL removal day?! In-Reply-To: <200706191324.30769.sgrubb@redhat.com> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <200706191324.30769.sgrubb@redhat.com> Message-ID: <467814EB.6000107@fedoraproject.org> Steve Grubb wrote: > On Tuesday 19 June 2007 13:10:10 Rahul Sundaram wrote: >>> ... then they are able to remove them, and we can discuss changing the >>> defaults/adding something to the CVS request form/whatever. I'm not >>> seeing the problem here? >> The need for ACL's by default that restrict the package to only the >> package maintainers is not clear > > This needs to be clear. Its for security. If you take all ACLs off the > packages and an account becomes compromised, the attacker can get to > everything. > > Please keep the ACLs by default so that there is not a window where a package > is left unguarded if it needed to be. It can work the other way around too. Remember that the large majority of packages are maintained in Fedora on a voluntary basis and many of them are very important ones. What happens if there is a highly critical security issue on one of those packages where the maintainers are not responding as quickly as ideal because they got sick, went on a vacation or simply lost interest? If you are going to have ACL's by default: 1) Document it explicitly. 2) Recommend that package maintainers consider the need for ACL's carefully. 3) Give blanket access to a select set of groups to fix issues as necessary - Rel Eng, FESCo, Fedora Security Team and possibly a small number of people who have a well known history of doing good QA work on the repository. Rahul From caillon at redhat.com Tue Jun 19 17:37:24 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 19 Jun 2007 13:37:24 -0400 Subject: ACL removal day?! In-Reply-To: <46780DF2.4020205@fedoraproject.org> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <1182268150.3016.105.camel@shinybook.infradead.org> <46780566.9080401@redhat.com> <467807B8.7070907@fedoraproject.org> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> Message-ID: <46781454.7030802@redhat.com> Rahul Sundaram wrote: > The need for ACL's by default that restrict the package to only the > package maintainers is not clear and package maintainers are not aware > that ACL are added by default to their packages. If it is explicitly > documented that ACL's are added by default that solves the latter > problem. So let's document it. > I would prefer that ACL are only added if explicitly requested > since having a common pool allows some of the work (mass rebuilds, > rebuilds for soname bumps, resolving conflicting files in between > packages, E-V-R issues, security problems etc) to be shared by other > package maintainers interested in maintaining the quality of the > repository on the whole. Do you mean if explicitly requested or if explicitly requested and they manage to convince $acl_giving_body. I imagine that this is going to turn into a government-like regulatory thing where people are going to make maintainers feel bad for even thinking about adding an ACL. We'd need this to be no-questions-asked IFF we do this. But a better question is: why are we trying to be different from the way every open source project works? You typically get commit access to what you need. I have access at freedesktop.org to a few select modules that I work on, but not to the whole of fd.o. Likewise, even at mozilla.org, I have access to a big chunk of stuff because I've proven myself to be good there, but I don't have access to some stuff such as the JavaScript engine or NSS for example. I'm not sure where "fills out a form" is the same as "competent enough to have open access to every package in the repo". They may overlap in some cases, but please keep in mind that this is not about freedom. This is about trust, security, and integrity of the project. From i at stingr.net Tue Jun 19 17:43:00 2007 From: i at stingr.net (Paul P Komkoff Jr) Date: Tue, 19 Jun 2007 21:43:00 +0400 Subject: Unorphaning roundup Message-ID: <20070619174300.GA22452@stingr.net> Hi! I want to catch and carry roundup. Any objections? Yours, -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From notting at redhat.com Tue Jun 19 17:46:40 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Jun 2007 13:46:40 -0400 Subject: ACL removal day?! In-Reply-To: <467814EB.6000107@fedoraproject.org> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <200706191324.30769.sgrubb@redhat.com> <467814EB.6000107@fedoraproject.org> Message-ID: <20070619174640.GD21506@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > If you are going to have ACL's by default: > > 1) Document it explicitly. Being worked on. > 3) Give blanket access to a select set of groups to fix issues as > necessary - Rel Eng, FESCo, Fedora Security Team and possibly a small > number of people who have a well known history of doing good QA work on > the repository. Already exists for a set of groups at the moment. Can be extened, although that really wants to wait for packagedb. Bill From a.badger at gmail.com Tue Jun 19 17:52:17 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 Jun 2007 10:52:17 -0700 Subject: ACL removal day?! In-Reply-To: <20070619174640.GD21506@nostromo.devel.redhat.com> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <200706191324.30769.sgrubb@redhat.com> <467814EB.6000107@fedoraproject.org> <20070619174640.GD21506@nostromo.devel.redhat.com> Message-ID: <1182275537.29855.33.camel@localhost.localdomain> On Tue, 2007-06-19 at 13:46 -0400, Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: > > 3) Give blanket access to a select set of groups to fix issues as > > necessary - Rel Eng, FESCo, Fedora Security Team and possibly a small > > number of people who have a well known history of doing good QA work on > > the repository. > > Already exists for a set of groups at the moment. Can be extened, although > that really wants to wait for packagedb. > And just so people know, extending this will not be in the initial deployment of the packagedb. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Tue Jun 19 17:54:24 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 19 Jun 2007 13:54:24 -0400 Subject: ACL removal day?! In-Reply-To: <467814EB.6000107@fedoraproject.org> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <200706191324.30769.sgrubb@redhat.com> <467814EB.6000107@fedoraproject.org> Message-ID: <1182275664.2800.13.camel@kennedy> On Tue, 2007-06-19 at 23:09 +0530, Rahul Sundaram wrote: > > 3) Give blanket access to a select set of groups to fix issues as > necessary - Rel Eng, FESCo, Fedora Security Team and possibly a small > number of people who have a well known history of doing good QA work on > the repository. That is one of the things planned for the future, but all the pieces necessary to implement it aren't there yet. /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 Tue Jun 19 18:00:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Jun 2007 23:30:40 +0530 Subject: ACL removal day?! In-Reply-To: <46781454.7030802@redhat.com> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <1182268150.3016.105.camel@shinybook.infradead.org> <46780566.9080401@redhat.com> <467807B8.7070907@fedoraproject.org> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <46781454.7030802@redhat.com> Message-ID: <467819C8.6030102@fedoraproject.org> Christopher Aillon wrote: > Do you mean if explicitly requested or if explicitly requested and they > manage to convince $acl_giving_body. I imagine that this is going to > turn into a government-like regulatory thing where people are going to > make maintainers feel bad for even thinking about adding an ACL. We'd > need this to be no-questions-asked IFF we do this. I don't think ACL requests by package maintainers need to be regulated as long as some groups which really need them get access as outlined in my other mail. I would really like to have maintainer's explicitly document the need for ACL's on their packages. There is a balance between security, critical nature of a package vs benefits of shared work via more open access. On some packages such as the kernel or glibc I think it is clear that ACL's are justified but it might be more appropriate to special case such packages instead of restricting ACL's by default. > But a better question is: why are we trying to be different from the way > every open source project works? I don't think we are all that different. Comparing individual projects to a distribution which needs to integrate thousands of packages together doesn't seem to work well but if you do compare other distributions there are is some similarities in the sense that there is a group of people who share the work across the repository or a smaller subset. Debian has FTP masters and NMU's. Gentoo has herds and so on. Also note that what is being discussed is not a entirely new change and Fedora Extras had always had open access to package maintainers and we haven't had any security or integrity issues with that. Rahul From jwboyer at jdub.homelinux.org Tue Jun 19 18:00:45 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 19 Jun 2007 13:00:45 -0500 Subject: ACL removal day?! In-Reply-To: <1182275664.2800.13.camel@kennedy> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <200706191324.30769.sgrubb@redhat.com> <467814EB.6000107@fedoraproject.org> <1182275664.2800.13.camel@kennedy> Message-ID: <1182276045.6126.57.camel@weaponx.rchland.ibm.com> On Tue, 2007-06-19 at 13:54 -0400, Brian Pepple wrote: > On Tue, 2007-06-19 at 23:09 +0530, Rahul Sundaram wrote: > > > > 3) Give blanket access to a select set of groups to fix issues as > > necessary - Rel Eng, FESCo, Fedora Security Team and possibly a small > > number of people who have a well known history of doing good QA work on > > the repository. > > That is one of the things planned for the future, but all the pieces > necessary to implement it aren't there yet. I will, however, note that a good portion of FESCo already has authority. And since several of them overlap with rel-eng and the security team, all of those bases are covered at the moment from a "who has access" standpoint. Now discussion as to when that authority can be used for issues such as Rahul described has not happened really. So those with access aren't using it for those means today. josh From katzj at redhat.com Tue Jun 19 18:01:53 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Jun 2007 14:01:53 -0400 Subject: ACL removal day?! In-Reply-To: <20070619172618.GB21506@nostromo.devel.redhat.com> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <1182268150.3016.105.camel@shinybook.infradead.org> <46780566.9080401@redhat.com> <467807B8.7070907@fedoraproject.org> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <20070619172618.GB21506@nostromo.devel.redhat.com> Message-ID: <1182276113.11891.10.camel@aglarond.local> On Tue, 2007-06-19 at 13:26 -0400, Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: > > The need for ACL's by default that restrict the package to only the > > package maintainers is not clear and package maintainers are not aware > > that ACL are added by default to their packages. If it is explicitly > > documented that ACL's are added by default that solves the latter > > problem. > > http://fedoraproject.org/wiki/JeremyKatz/DraftPackageAccess > > Jeremy, want to push that to finalized? While useful in and of itself, we really need to revisit the idea of a developer's guide... having lots of little pages like this one is really good for people that want to know. But it sucks if I'm a new maintainer and have to then dredge through 20 bazillion (okay, exaggeration :-) pages on the wiki. At the same time, I'll clean this one up and we can get it into what we've got for now at least Jeremy From faucamp at csir.co.za Tue Jun 19 18:33:04 2007 From: faucamp at csir.co.za (Francois Aucamp) Date: Tue, 19 Jun 2007 20:33:04 +0200 Subject: Portaudio v19 update In-Reply-To: <200706191931.50984.ville.skytta@iki.fi> References: <20070619143857.6dbdba3b@python3.es.egwn.lan> <200706191931.50984.ville.skytta@iki.fi> Message-ID: <46783E8D.91A7.006A.0@csir.co.za> >>> On Tue, Jun 19, 2007, Ville Skytt? wrote: > On Tuesday 19 June 2007, Matthias Saou wrote: > >> I don't have any packages on my system which require portaudio, but I'm >> sending out this email anyway just in case. > > $ repoquery -- repoid=development -- whatrequires -- alldeps portaudio > espeak- 0:1.25- 1.fc8.i386 > espeak- 0:1.25- 1.fc8.x86_64 > Thanks for the heads-up, guys. espeak (version 1.26) builds against portaudio v19 with a trivial tweak to the spec file; I submit a build for espeak-1.26 for rawhide in just a bit. This may be a dumb question, but are we going to push portaudio v19 to f7 (and possibly fc6) as well? Cheers, -Francois -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre at csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From opensource at till.name Tue Jun 19 19:02:30 2007 From: opensource at till.name (Till Maas) Date: Tue, 19 Jun 2007 21:02:30 +0200 Subject: ACL removal day?! In-Reply-To: <1182276113.11891.10.camel@aglarond.local> References: <4677EAFB.50000@hhs.nl> <20070619172618.GB21506@nostromo.devel.redhat.com> <1182276113.11891.10.camel@aglarond.local> Message-ID: <200706192102.37984.opensource@till.name> On Di Juni 19 2007, Jeremy Katz wrote: > While useful in and of itself, we really need to revisit the idea of a > developer's guide... having lots of little pages like this one is > really good for people that want to know. But it sucks if I'm a new > maintainer and have to then dredge through 20 bazillion (okay, Imho having several pages makes it easier to bookmark the information that one forgets faster than the other. Also one can create a big page through inclusion of the other pages, in wiki Syntax: [[Include(/WikiPage)]], e.g. this is done on the front pages. Regards, Till From triad at df.lth.se Tue Jun 19 19:36:25 2007 From: triad at df.lth.se (Linus Walleij) Date: Tue, 19 Jun 2007 21:36:25 +0200 (CEST) Subject: ACL removal day?! In-Reply-To: <1182267088.30663.174.camel@localhost.localdomain> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> Message-ID: On Tue, 19 Jun 2007, Adam Jackson wrote: > Suggestion for FESCO: new packages must explicitly request an ACL. +1 Linus From dwmw2 at infradead.org Wed Jun 20 02:15:31 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 20 Jun 2007 10:15:31 +0800 Subject: ACL removal day?! In-Reply-To: <46780864.8020609@fedoraproject.org> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <4677FBD3.6080602@RedHat.com> <467801B8.6070505@fedoraproject.org> <4678058F.9010807@RedHat.com> <46780864.8020609@fedoraproject.org> Message-ID: <1182305731.3016.124.camel@shinybook.infradead.org> On Tue, 2007-06-19 at 22:16 +0530, Rahul Sundaram wrote: > Nobody is suggesting that packages be opened up to the entire world. Indeed. Only to those people who have agreed to the CLA and been sponsored as Fedora packagers. > The current discussion is about whether only the package maintainers > should get access by default with ACL's blocking everybody else out or > whether every maintainer should get access to a common package pool by > default with exceptions as explicitly requested by package maintainers. I see no reason why we shouldn't allow any sponsored packager to commit and build packages. It may make sense to say that only the package owner(s) can push updates to the public, but just committing and building should be unrestricted. -- dwmw2 From pjones at redhat.com Wed Jun 20 14:36:50 2007 From: pjones at redhat.com (Peter Jones) Date: Wed, 20 Jun 2007 10:36:50 -0400 Subject: ACL removal day?! In-Reply-To: <46781381.8030707@leemhuis.info> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <200706191324.30769.sgrubb@redhat.com> <46781381.8030707@leemhuis.info> Message-ID: <46793B82.7000607@redhat.com> Thorsten Leemhuis wrote: > On 19.06.2007 19:24, Steve Grubb wrote: >> This needs to be clear. Its for security. If you take all ACLs off the >> packages and an account becomes compromised, the attacker can get to >> everything. >> >> Please keep the ACLs by default so that there is not a window where a package >> is left unguarded if it needed to be. > > I'd say we should work towards a middle ground -- ACLs by default, but > create some kind of "trusted contributers group (say sponsors, FESCo > members and packagers with more then 25 packages) that get access > everywhere. I'm just playing devil's advocate here, but I don't think Steve is worried about what I might do to your precious, precious packages. He's worried about what the guy who roots my laptop in a coffee shop might do to them. (In Eastern Massachusetts, the odds are actually fairly high that there's more than one coder geek in any given coffee shop at a time. Some of them are Debian users. Think about it...) -- Peter, who knows of no attacks on his laptop by Debian users. From rc040203 at freenet.de Wed Jun 20 14:56:58 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 20 Jun 2007 16:56:58 +0200 Subject: ACL removal day?! In-Reply-To: <46793B82.7000607@redhat.com> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <200706191324.30769.sgrubb@redhat.com> <46781381.8030707@leemhuis.info> <46793B82.7000607@redhat.com> Message-ID: <1182351419.6271.25.camel@mccallum.corsepiu.local> On Wed, 2007-06-20 at 10:36 -0400, Peter Jones wrote: > Thorsten Leemhuis wrote: > > On 19.06.2007 19:24, Steve Grubb wrote: > >> This needs to be clear. Its for security. If you take all ACLs off the > >> packages and an account becomes compromised, the attacker can get to > >> everything. > >> > >> Please keep the ACLs by default so that there is not a window where a package > >> is left unguarded if it needed to be. > > > > I'd say we should work towards a middle ground -- ACLs by default, but > > create some kind of "trusted contributers group (say sponsors, FESCo > > members and packagers with more then 25 packages) that get access > > everywhere. > > I'm just playing devil's advocate here, but I don't think Steve is > worried about what I might do to your precious, precious packages. He's > worried about what the guy who roots my laptop in a coffee shop might do > to them. Nothing much. 1. He needs to be a Linux user 2. He needs to be deeply familiar with the Fedora build-system. 3. He will have to crack your passwords/ssh-phrases If 1.-3. are fulfilled, with ACLs in effect he will be able to compromise your packages. Without ACLs in effect he will be able to compromise other packages than yours. Ralf From dwmw2 at infradead.org Wed Jun 20 15:18:29 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 20 Jun 2007 23:18:29 +0800 Subject: ACL removal day?! In-Reply-To: <1182351419.6271.25.camel@mccallum.corsepiu.local> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <200706191324.30769.sgrubb@redhat.com> <46781381.8030707@leemhuis.info> <46793B82.7000607@redhat.com> <1182351419.6271.25.camel@mccallum.corsepiu.local> Message-ID: <1182352709.3016.214.camel@shinybook.infradead.org> On Wed, 2007-06-20 at 16:56 +0200, Ralf Corsepius wrote: > Without ACLs in effect he will be able to > compromise other packages than yours. We don't need an ACL on _commits_. We can have one on _builds_. Or preferably just on _pushes_ to the repository -- people other than the maintainer can build an untagged package and the maintainer (or someone in the ACL) would have to tag it for the intended collection. -- dwmw2 From alan at redhat.com Wed Jun 20 15:18:29 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 20 Jun 2007 11:18:29 -0400 Subject: ACL removal day?! In-Reply-To: <1182351419.6271.25.camel@mccallum.corsepiu.local> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <200706191324.30769.sgrubb@redhat.com> <46781381.8030707@leemhuis.info> <46793B82.7000607@redhat.com> <1182351419.6271.25.camel@mccallum.corsepiu.local> Message-ID: <20070620151829.GL19376@devserv.devel.redhat.com> On Wed, Jun 20, 2007 at 04:56:58PM +0200, Ralf Corsepius wrote: > 1. He needs to be a Linux user > 2. He needs to be deeply familiar with the Fedora build-system. > 3. He will have to crack your passwords/ssh-phrases All false He needs to be a 1. Trojan script 2. Have been scripted to attack Fedora, or generically attack cvs 3. Steal your ssh keys automatically via patched tools Its a minor perl problem to produce such a tool and just wait for a Fedora developer to catch it, then it can merge itself from one project into the next and infect the next person whol builds it on their own box and so on and so forth. From rc040203 at freenet.de Wed Jun 20 15:22:28 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 20 Jun 2007 17:22:28 +0200 Subject: ACL removal day?! In-Reply-To: <20070620151829.GL19376@devserv.devel.redhat.com> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <200706191324.30769.sgrubb@redhat.com> <46781381.8030707@leemhuis.info> <46793B82.7000607@redhat.com> <1182351419.6271.25.camel@mccallum.corsepiu.local> <20070620151829.GL19376@devserv.devel.redhat.com> Message-ID: <1182352948.6271.28.camel@mccallum.corsepiu.local> On Wed, 2007-06-20 at 11:18 -0400, Alan Cox wrote: > On Wed, Jun 20, 2007 at 04:56:58PM +0200, Ralf Corsepius wrote: > > 1. He needs to be a Linux user > > 2. He needs to be deeply familiar with the Fedora build-system. > > 3. He will have to crack your passwords/ssh-phrases > > All false > > He needs to be a > 1. Trojan script > 2. Have been scripted to attack Fedora, or generically attack cvs > 3. Steal your ssh keys automatically via patched tools Or a man-in-the middle attack ... in such cases ACL's won't help at all. > Its a minor perl problem to produce such a tool and just wait for a Fedora > developer to catch it, then it can merge itself from one project into the > next and infect the next person whol builds it on their own box and so on > and so forth. Ralf From rc040203 at freenet.de Wed Jun 20 15:27:05 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 20 Jun 2007 17:27:05 +0200 Subject: ACL removal day?! In-Reply-To: <1182352709.3016.214.camel@shinybook.infradead.org> References: <4677EAFB.50000@hhs.nl> <20070619165831.GA21506@nostromo.devel.redhat.com> <46780DF2.4020205@fedoraproject.org> <200706191324.30769.sgrubb@redhat.com> <46781381.8030707@leemhuis.info> <46793B82.7000607@redhat.com> <1182351419.6271.25.camel@mccallum.corsepiu.local> <1182352709.3016.214.camel@shinybook.infradead.org> Message-ID: <1182353226.6271.30.camel@mccallum.corsepiu.local> On Wed, 2007-06-20 at 23:18 +0800, David Woodhouse wrote: > On Wed, 2007-06-20 at 16:56 +0200, Ralf Corsepius wrote: > > Without ACLs in effect he will be able to > > compromise other packages than yours. > > We don't need an ACL on _commits_. We can have one on _builds_. Absolutely. IMO, this would be a reasonable compromise. > Or > preferably just on _pushes_ to the repository -- people other than the > maintainer can build an untagged package and the maintainer (or someone > in the ACL) would have to tag it for the intended collection. Don't get me wrong, I am vehemently opposed to the current ACLs. IMO, all they do is to close out "people who are following the rules of the game" and are unlikely to help in cases of real attacks. Ralf From pjones at redhat.com Wed Jun 20 15:36:00 2007 From: pjones at redhat.com (Peter Jones) Date: Wed, 20 Jun 2007 11:36:00 -0400 Subject: ACL removal day?! In-Reply-To: <1182305731.3016.124.camel@shinybook.infradead.org> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <4677FBD3.6080602@RedHat.com> <467801B8.6070505@fedoraproject.org> <4678058F.9010807@RedHat.com> <46780864.8020609@fedoraproject.org> <1182305731.3016.124.camel@shinybook.infradead.org> Message-ID: <46794960.9000806@redhat.com> David Woodhouse wrote: > It may make sense to say that only the package owner(s) can push updates > to the public, but just committing and building should be unrestricted. I think this is another case where too much regulation hurts us. The policy shouldn't be "other people can't do it". It should be "act responsibly." Every once in a while, some package maintainer might have good cause to modify somebody else's package and push it. Usually, it won't be the case. If there's a good reason. I also think your (later) comment on irc was more correct than your comment here -- if you're not the maintainer, you should be able to change things and even build. But you shouldn't be able to push to repos. The maintainer (or rel-eng) need to do that part. -- Peter From sgrubb at redhat.com Wed Jun 20 15:35:48 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 20 Jun 2007 11:35:48 -0400 Subject: ACL removal day?! In-Reply-To: <46793B82.7000607@redhat.com> References: <4677EAFB.50000@hhs.nl> <46781381.8030707@leemhuis.info> <46793B82.7000607@redhat.com> Message-ID: <200706201135.48390.sgrubb@redhat.com> On Wednesday 20 June 2007 10:36, Peter Jones wrote: > >> Please keep the ACLs by default so that there is not a window where a > >> package is left unguarded if it needed to be. > > > > I'd say we should work towards a middle ground -- ACLs by default, but > > create some kind of "trusted contributers group (say sponsors, FESCo > > members and packagers with more then 25 packages) that get access > > everywhere. > > I'm just playing devil's advocate here, but I don't think Steve is > worried about what I might do to your precious, precious packages. Exactly. Maintainers OK, bad guy impersonating maintainer is not. -Steve From sgrubb at redhat.com Wed Jun 20 15:47:24 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 20 Jun 2007 11:47:24 -0400 Subject: ACL removal day?! In-Reply-To: <1182353226.6271.30.camel@mccallum.corsepiu.local> References: <4677EAFB.50000@hhs.nl> <1182352709.3016.214.camel@shinybook.infradead.org> <1182353226.6271.30.camel@mccallum.corsepiu.local> Message-ID: <200706201147.24619.sgrubb@redhat.com> On Wednesday 20 June 2007 11:27, Ralf Corsepius wrote: > On Wed, 2007-06-20 at 23:18 +0800, David Woodhouse wrote: > > On Wed, 2007-06-20 at 16:56 +0200, Ralf Corsepius wrote: > > > Without ACLs in effect he will be able to > > > compromise other packages than yours. > > > > We don't need an ACL on _commits_. We can have one on _builds_. > > Absolutely. IMO, this would be a reasonable compromise. The problem is that you will see a patch from someone that appears to be a maintainer. You might look it over or might not. If you looked it over, you might not realize it opens a hole in that package. The attacker has planted the problem and is waiting for you to do the build and distribute it to the world. When we take packages from upstream, there are a lot of eyes watching the package. If they are compromised, it will affect us, Debian, Suse, Mandriva, Ubuntu...iow there are a lot of people that might catch the problem. When it comes to a distribution, there are less people affected and malicious code could live longer before being detected. SE Linux can help a lot in being able to see sudden behavior changes, but there are only 200 or so domains that are confined. > > Or preferably just on _pushes_ to the repository -- people other than the > > maintainer can build an untagged package and the maintainer (or someone > > in the ACL) would have to tag it for the intended collection. > > Don't get me wrong, I am vehemently opposed to the current ACLs. IMO, > all they do is to close out "people who are following the rules of the > game" and are unlikely to help in cases of real attacks. All we are talking about is the default setting. You can remove it later if you want to take that risk. Its going to be a lot harder to re-establish trust if Fedora code base gets hacked than it was to have some preventive measures in the first place. -Steve From Jochen at herr-schmitt.de Wed Jun 20 15:59:49 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 20 Jun 2007 17:59:49 +0200 Subject: Wrong tagging on cvs-import.sh Message-ID: <46794EF5.2060300@herr-schmitt.de> Hello, I have tried to import a source rpm in the devel branch with $ ../common/cvs-import.sh /home/s4504kr/redhat/SRPMS/subcommander-1.2.2-4.fc7.src.rpm But I was wondering, that cvs-import.sh has create a subcommander-1_2_2-4_fc7 tag. The full log you can find at http://www.herr-schmitt.de/pub/cvs_issue.txt So I want to ask, how can I avoid this situation. Best Regards: Jochen Schmitt From jkeating at redhat.com Wed Jun 20 16:03:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Jun 2007 12:03:47 -0400 Subject: Wrong tagging on cvs-import.sh In-Reply-To: <46794EF5.2060300@herr-schmitt.de> References: <46794EF5.2060300@herr-schmitt.de> Message-ID: <200706201203.47109.jkeating@redhat.com> On Wednesday 20 June 2007 11:59:49 Jochen Schmitt wrote: > Hello, > > I have tried to import a source rpm in the devel branch with > > $ ../common/cvs-import.sh > /home/s4504kr/redhat/SRPMS/subcommander-1.2.2-4.fc7.src.rpm > > But I was wondering, that cvs-import.sh has create a > > subcommander-1_2_2-4_fc7 > > tag. > > The full log you can find at > > http://www.herr-schmitt.de/pub/cvs_issue.txt > When was the last time you updated that common directory? We made some changes to cvs-import so that it just called 'make tag' from the newly imported directory, and by default it would import to the branch you may be running cvs-import from. The output you posted looks like the old cvs-import before these changes a few weeks ago. Can you update your common/ and try again? -- 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 bnocera at redhat.com Wed Jun 20 16:08:01 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 20 Jun 2007 17:08:01 +0100 Subject: [Fwd: [Fedora Update] [comment] evince-0.8.0-6.fc7] Message-ID: <1182355681.2904.96.camel@cookie.hadess.net> Why am I receiving things like that? It's a rethorical question. Somebody added a comment on the update at: https://admin.fedoraproject.org/updates/testing/F7/evince-0.8.0-6.fc7 I would just like to know why I would need to go to yet another place to see what should rightfully be filed as a bug. -------------- next part -------------- An embedded message was scrubbed... From: updates at fedoraproject.org Subject: [Fedora Update] [comment] evince-0.8.0-6.fc7 Date: Wed, 20 Jun 2007 08:19:20 -0700 Size: 1841 URL: From Jochen at herr-schmitt.de Wed Jun 20 16:16:18 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 20 Jun 2007 18:16:18 +0200 Subject: Wrong tagging on cvs-import.sh In-Reply-To: <200706201203.47109.jkeating@redhat.com> References: <46794EF5.2060300@herr-schmitt.de> <200706201203.47109.jkeating@redhat.com> Message-ID: <467952D2.7060208@herr-schmitt.de> Jesse Keating schrieb: > When was the last time you updated that common directory? We made some > changes to cvs-import so that it just called 'make tag' from the newly > imported directory, and by default it would import to the branch you may be > running cvs-import from. The output you posted looks like the old cvs-import > before these changes a few weeks ago. Can you update your common/ and try > again? > I have got a look in the cvs-import.sh script. you are right, that the script call 'make tag' at the end. But it look like, that the value of the TAG variable will created from the name of the imported package. The Name of the imported package was subcommander-1.2.2-4.fc7.src.rpm, so this will run it into trouble. Best Regards: Jochen Schmitt From tibbs at math.uh.edu Wed Jun 20 16:26:30 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Jun 2007 11:26:30 -0500 Subject: Summary of the 2007-06-19 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-06-19 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070619 (Actually, they should be online soon; the wiki is behaving badly at the moment.) Executive summary: The following drafts are now official guidelines, having been accepted by FESCO last week: * Corrections to the scriptlets: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippetsFixes * OCaml guidelines: http://fedoraproject.org/wiki/PackagingDrafts/OCaml * Revisions to the rule on directory ownership: http://fedoraproject.org/wiki/PackagingDrafts/ These should be written into the guidelines soon if this hasn't already been done by the time you read this. Issues pending FESCO ratification: * Blanket exception for linking against libraries that are only available as static, and initialCC requirement. * http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges * Accepted (6 - 0) Misc business: * Allowing SCM commit ID information into the release tag: * http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs * The draft is being modified significantly to remove pointless stricture. - J< From rdieter at math.unl.edu Wed Jun 20 16:49:44 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Jun 2007 11:49:44 -0500 Subject: [Fwd: [Fedora Update] [comment] evince-0.8.0-6.fc7] In-Reply-To: <1182355681.2904.96.camel@cookie.hadess.net> References: <1182355681.2904.96.camel@cookie.hadess.net> Message-ID: <46795AA8.6010306@math.unl.edu> Bastien Nocera wrote: > Why am I receiving things like that? > > It's a rethorical question. Somebody added a comment on the update at: > https://admin.fedoraproject.org/updates/testing/F7/evince-0.8.0-6.fc7 > > I would just like to know why I would need to go to yet another place to > see what should rightfully be filed as a bug. No good reason... mostly laziness, I suppose. Sorry. I'll go rectify that... -- Rex From jwboyer at jdub.homelinux.org Wed Jun 20 16:54:33 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 11:54:33 -0500 Subject: [Fwd: [Fedora Update] [comment] evince-0.8.0-6.fc7] In-Reply-To: <46795AA8.6010306@math.unl.edu> References: <1182355681.2904.96.camel@cookie.hadess.net> <46795AA8.6010306@math.unl.edu> Message-ID: <1182358473.14977.49.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 11:49 -0500, Rex Dieter wrote: > Bastien Nocera wrote: > > Why am I receiving things like that? > > > > It's a rethorical question. Somebody added a comment on the update at: > > https://admin.fedoraproject.org/updates/testing/F7/evince-0.8.0-6.fc7 > > > > I would just like to know why I would need to go to yet another place to > > see what should rightfully be filed as a bug. > > No good reason... mostly laziness, I suppose. Sorry. I'll go rectify > that... But you should post a link to that bug in the comment. rel-eng looks at those to determine if the update is worth pushing to the stable updates. josh From nicolas.mailhot at laposte.net Wed Jun 20 16:59:48 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 20 Jun 2007 18:59:48 +0200 Subject: [Fwd: [Fedora Update] [comment] evince-0.8.0-6.fc7] In-Reply-To: <1182358473.14977.49.camel@weaponx.rchland.ibm.com> References: <1182355681.2904.96.camel@cookie.hadess.net> <46795AA8.6010306@math.unl.edu> <1182358473.14977.49.camel@weaponx.rchland.ibm.com> Message-ID: <1182358789.15482.1.camel@rousalka.dyndns.org> Le mercredi 20 juin 2007 ? 11:54 -0500, Josh Boyer a ?crit : > On Wed, 2007-06-20 at 11:49 -0500, Rex Dieter wrote: > > Bastien Nocera wrote: > > > Why am I receiving things like that? > > > > > > It's a rethorical question. Somebody added a comment on the update at: > > > https://admin.fedoraproject.org/updates/testing/F7/evince-0.8.0-6.fc7 > > > > > > I would just like to know why I would need to go to yet another place to > > > see what should rightfully be filed as a bug. > > > > No good reason... mostly laziness, I suppose. Sorry. I'll go rectify > > that... > > But you should post a link to that bug in the comment. rel-eng looks at > those to determine if the update is worth pushing to the stable updates. Actually bodhi should just create a bugzilla entry with the right context when someone wants to comment on an update (and link it on the bodhi page) -- 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 jwboyer at jdub.homelinux.org Wed Jun 20 17:01:10 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 20 Jun 2007 12:01:10 -0500 Subject: [Fwd: [Fedora Update] [comment] evince-0.8.0-6.fc7] In-Reply-To: <1182358789.15482.1.camel@rousalka.dyndns.org> References: <1182355681.2904.96.camel@cookie.hadess.net> <46795AA8.6010306@math.unl.edu> <1182358473.14977.49.camel@weaponx.rchland.ibm.com> <1182358789.15482.1.camel@rousalka.dyndns.org> Message-ID: <1182358870.14977.54.camel@weaponx.rchland.ibm.com> On Wed, 2007-06-20 at 18:59 +0200, Nicolas Mailhot wrote: > Le mercredi 20 juin 2007 ? 11:54 -0500, Josh Boyer a ?crit : > > On Wed, 2007-06-20 at 11:49 -0500, Rex Dieter wrote: > > > Bastien Nocera wrote: > > > > Why am I receiving things like that? > > > > > > > > It's a rethorical question. Somebody added a comment on the update at: > > > > https://admin.fedoraproject.org/updates/testing/F7/evince-0.8.0-6.fc7 > > > > > > > > I would just like to know why I would need to go to yet another place to > > > > see what should rightfully be filed as a bug. > > > > > > No good reason... mostly laziness, I suppose. Sorry. I'll go rectify > > > that... > > > > But you should post a link to that bug in the comment. rel-eng looks at > > those to determine if the update is worth pushing to the stable updates. > > Actually bodhi should just create a bugzilla entry with the right > context when someone wants to comment on an update (and link it on the > bodhi page) Maybe have a button for that, yeah. But we want to see good comments too, e.g. "This works great!". Those don't need a bug :). josh From jkeating at redhat.com Wed Jun 20 17:04:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 20 Jun 2007 13:04:40 -0400 Subject: [Fwd: [Fedora Update] [comment] evince-0.8.0-6.fc7] In-Reply-To: <1182358789.15482.1.camel@rousalka.dyndns.org> References: <1182355681.2904.96.camel@cookie.hadess.net> <1182358473.14977.49.camel@weaponx.rchland.ibm.com> <1182358789.15482.1.camel@rousalka.dyndns.org> Message-ID: <200706201304.46360.jkeating@redhat.com> On Wednesday 20 June 2007 12:59:48 Nicolas Mailhot wrote: > Actually bodhi should just create a bugzilla entry with the right > context when someone wants to comment on an update (and link it on the > bodhi page) Mapping the commenter to a valid bugzilla ID is hard, mapping it to bodhi guarantees you get no feedback from bug comments. I think the idea of comments was to allow commentary on the update coming from those without bugzilla accounts or without the overhead of bugzilla. Things like "this solved my problem" or "this update works great for me" aren't really suitable for bugzilla. But capturing those in the update entry rather than a mailing list seems ideal. -- 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 rdieter at math.unl.edu Wed Jun 20 17:20:18 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Jun 2007 12:20:18 -0500 Subject: [Fwd: [Fedora Update] [comment] evince-0.8.0-6.fc7] In-Reply-To: <1182358473.14977.49.camel@weaponx.rchland.ibm.com> References: <1182355681.2904.96.camel@cookie.hadess.net> <46795AA8.6010306@math.unl.edu> <1182358473.14977.49.camel@weaponx.rchland.ibm.com> Message-ID: <467961D2.1050003@math.unl.edu> Josh Boyer wrote: > On Wed, 2007-06-20 at 11:49 -0500, Rex Dieter wrote: >> Bastien Nocera wrote: >>> It's a rethorical question. Somebody added a comment on the update at: >>> https://admin.fedoraproject.org/updates/testing/F7/evince-0.8.0-6.fc7 >>> I would just like to know why I would need to go to yet another place to >>> see what should rightfully be filed as a bug. >> No good reason... mostly laziness, I suppose. Sorry. I'll go rectify >> that... > But you should post a link to that bug in the comment. rel-eng looks at > those to determine if the update is worth pushing to the stable updates. done. -- Rex From lightsolphoenix at gmail.com Wed Jun 20 17:42:42 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Wed, 20 Jun 2007 13:42:42 -0400 Subject: Missing Dependency in rhgb package? Message-ID: <200706201342.43008.lightsolphoenix@gmail.com> I believe there's a missing dependency on the Redhat Graphical Boot package. I installed off of the KDE Live CD and then installed RHGB manually, but it errored out because I didn't have VTE installed. Shouldn't VTE be a dependency of RHGB if RHGB won't start without it? -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From skvidal at linux.duke.edu Wed Jun 20 17:50:32 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Jun 2007 13:50:32 -0400 Subject: Missing Dependency in rhgb package? In-Reply-To: <200706201342.43008.lightsolphoenix@gmail.com> References: <200706201342.43008.lightsolphoenix@gmail.com> Message-ID: <1182361832.4102.11.camel@hodge> On Wed, 2007-06-20 at 13:42 -0400, Kelly wrote: > I believe there's a missing dependency on the Redhat Graphical Boot package. > I installed off of the KDE Live CD and then installed RHGB manually, but it > errored out because I didn't have VTE installed. Shouldn't VTE be a > dependency of RHGB if RHGB won't start without it? it does require libvte.so.0.9 which is provided by vte. run: rpm -Va --nofiles --nomd5 and see what it outputs, you may some other unresolved deps to be worried about -sv From jeff at ocjtech.us Wed Jun 20 19:52:01 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 20 Jun 2007 14:52:01 -0500 Subject: [Fwd: [Fedora Update] [comment] evince-0.8.0-6.fc7] In-Reply-To: <200706201304.46360.jkeating@redhat.com> References: <1182355681.2904.96.camel@cookie.hadess.net> <1182358473.14977.49.camel@weaponx.rchland.ibm.com> <1182358789.15482.1.camel@rousalka.dyndns.org> <200706201304.46360.jkeating@redhat.com> Message-ID: <1182369121.3946.9.camel@lt21223.campus.dmacc.edu> On Wed, 2007-06-20 at 13:04 -0400, Jesse Keating wrote: > On Wednesday 20 June 2007 12:59:48 Nicolas Mailhot wrote: > > Actually bodhi should just create a bugzilla entry with the right > > context when someone wants to comment on an update (and link it on the > > bodhi page) > > Mapping the commenter to a valid bugzilla ID is hard, mapping it to bodhi > guarantees you get no feedback from bug comments. > > I think the idea of comments was to allow commentary on the update coming from > those without bugzilla accounts or without the overhead of bugzilla. Things > like "this solved my problem" or "this update works great for me" aren't > really suitable for bugzilla. But capturing those in the update entry rather > than a mailing list seems ideal. What if bodhi put a link to a bugzilla query that would pull up all the recent bug activity for the package? https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Fedora&version=devel&component=kernel&component_text=&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&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=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=14&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number+Ascending&field0-0-0=noop&type0-0-0=noop&value0-0-0= (BTW, is there a way to specify in the URL what columns are displayed? I was able to change my display to include the changed/opened date but bugzilla seems to handle that through cookies or something like that). 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 Christian.Iseli at licr.org Wed Jun 20 21:42:29 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 20 Jun 2007 23:42:29 +0200 Subject: [Fwd: [Fedora Update] [comment] evince-0.8.0-6.fc7] In-Reply-To: <1182369121.3946.9.camel@lt21223.campus.dmacc.edu> References: <1182355681.2904.96.camel@cookie.hadess.net> <1182358473.14977.49.camel@weaponx.rchland.ibm.com> <1182358789.15482.1.camel@rousalka.dyndns.org> <200706201304.46360.jkeating@redhat.com> <1182369121.3946.9.camel@lt21223.campus.dmacc.edu> Message-ID: <20070620234229.368163a3@ludwig-alpha.unil.ch> On Wed, 20 Jun 2007 14:52:01 -0500, Jeffrey C. Ollie wrote: > (BTW, is there a way to specify in the URL what columns are displayed? > I was able to change my display to include the changed/opened date > but bugzilla seems to handle that through cookies or something like > that). You need a cooky for that (AFAIK). You create a file which contains something like: # HTTP Cookie File bugzilla.redhat.com FALSE /bugzilla FALSE 2145917104 COLUMNLIST opendate%20changeddate%20bug_severity%20assigned_to%20reporter%20bug_status%20resolution%20component%20blockedby%20short_desc (the first line is a comment and is not necessary, the second is one long line) then you can use: wget --load-cookies -nv -O - "" HTH. Cheers, C From jeff at ocjtech.us Thu Jun 21 02:54:55 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 20 Jun 2007 21:54:55 -0500 Subject: [Fwd: [Fedora Update] [comment] evince-0.8.0-6.fc7] In-Reply-To: <20070620234229.368163a3@ludwig-alpha.unil.ch> References: <1182355681.2904.96.camel@cookie.hadess.net> <1182358473.14977.49.camel@weaponx.rchland.ibm.com> <1182358789.15482.1.camel@rousalka.dyndns.org> <200706201304.46360.jkeating@redhat.com> <1182369121.3946.9.camel@lt21223.campus.dmacc.edu> <20070620234229.368163a3@ludwig-alpha.unil.ch> Message-ID: <1182394495.3677.4.camel@lt21223.campus.dmacc.edu> On Wed, 2007-06-20 at 23:42 +0200, Christian Iseli wrote: > On Wed, 20 Jun 2007 14:52:01 -0500, Jeffrey C. Ollie wrote: > > (BTW, is there a way to specify in the URL what columns are displayed? > > I was able to change my display to include the changed/opened date > > but bugzilla seems to handle that through cookies or something like > > that). > > You need a cooky for that (AFAIK). > > You create a file which contains something like: > # HTTP Cookie File > bugzilla.redhat.com FALSE /bugzilla FALSE 2145917104 COLUMNLIST opendate%20changeddate%20bug_severity%20assigned_to%20reporter%20bug_status%20resolution%20component%20blockedby%20short_desc Thanks for the tip! 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 dwmw2 at infradead.org Thu Jun 21 06:31:43 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 21 Jun 2007 14:31:43 +0800 Subject: ACL removal day?! In-Reply-To: <46794960.9000806@redhat.com> References: <4677EAFB.50000@hhs.nl> <1182267088.30663.174.camel@localhost.localdomain> <4677F978.3090806@fedoraproject.org> <4677FBD3.6080602@RedHat.com> <467801B8.6070505@fedoraproject.org> <4678058F.9010807@RedHat.com> <46780864.8020609@fedoraproject.org> <1182305731.3016.124.camel@shinybook.infradead.org> <46794960.9000806@redhat.com> Message-ID: <1182407503.2782.25.camel@shinybook.infradead.org> On Wed, 2007-06-20 at 11:36 -0400, Peter Jones wrote: > David Woodhouse wrote: > > It may make sense to say that only the package owner(s) can push updates > > to the public, but just committing and building should be unrestricted. > > I think this is another case where too much regulation hurts us. The > policy shouldn't be "other people can't do it". It should be "act > responsibly." Every once in a while, some package maintainer might have > good cause to modify somebody else's package and push it. Usually, it > won't be the case. If there's a good reason. Indeed. > I also think your (later) comment on irc was more correct than your > comment here -- if you're not the maintainer, you should be able to > change things and even build. But you shouldn't be able to push to > repos. The maintainer (or rel-eng) need to do that part. Perhaps not 'more correct', but just 'more coherent'. I think that's actually what I was trying to say. -- dwmw2 From lightsolphoenix at gmail.com Thu Jun 21 07:17:00 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Thu, 21 Jun 2007 03:17:00 -0400 Subject: Missing Dependency in rhgb package? In-Reply-To: <1182361832.4102.11.camel@hodge> References: <200706201342.43008.lightsolphoenix@gmail.com> <1182361832.4102.11.camel@hodge> Message-ID: <200706210317.01386.lightsolphoenix@gmail.com> On Wednesday, June 20, 2007 1:50 pm seth vidal wrote: > it does require libvte.so.0.9 which is provided by vte. > > run: > > rpm -Va --nofiles --nomd5 > > and see what it outputs, you may some other unresolved deps to be > worried about It's fine now; what I'm trying to get at is, shouldn't rhgb have a dependency on vte so that this doesn't happen? After all, if rhgb errors out without vte, I'd consider vte a major dependency. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From jspaleta at gmail.com Thu Jun 21 07:25:17 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 20 Jun 2007 23:25:17 -0800 Subject: Missing Dependency in rhgb package? In-Reply-To: <200706210317.01386.lightsolphoenix@gmail.com> References: <200706201342.43008.lightsolphoenix@gmail.com> <1182361832.4102.11.camel@hodge> <200706210317.01386.lightsolphoenix@gmail.com> Message-ID: <604aa7910706210025m276b0ff9udc02cd663dc1a469@mail.gmail.com> On 6/20/07, Kelly wrote: > It's fine now; what I'm trying to get at is, shouldn't rhgb have a dependency > on vte so that this doesn't happen? It does have a dependency....as seth just explained. you can see the dependency another way.. on a F7 system do: rpm -e --test vte outputs to stderr: error: Failed dependencies: libvte.so.9 is needed by (installed) rhgb-0.17.6-1.fc7.i386 libvte.so.9 is needed by (installed) gnome-terminal-2.18.0-1.fc7.i386 there IS a dependency, there's absolutely no question about that. The question is what's going wrong on your system that allowed rhgb to be installed without vte. As seth suggests, you make have more missing dependencies than you realize. -jef From lightsolphoenix at gmail.com Thu Jun 21 08:10:36 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Thu, 21 Jun 2007 04:10:36 -0400 Subject: Missing Dependency in rhgb package? In-Reply-To: <604aa7910706210025m276b0ff9udc02cd663dc1a469@mail.gmail.com> References: <200706201342.43008.lightsolphoenix@gmail.com> <200706210317.01386.lightsolphoenix@gmail.com> <604aa7910706210025m276b0ff9udc02cd663dc1a469@mail.gmail.com> Message-ID: <200706210410.37004.lightsolphoenix@gmail.com> On Thursday, June 21, 2007 3:25 am Jeff Spaleta wrote: > there IS a dependency, there's absolutely no question about that. The > question is what's going wrong on your system that allowed rhgb to be > installed without vte. I dunno. I installed off the KDE Live CD, which doesn't have rhgb on it. What I don't understand is how I could select to install it without getting any of it's dependencies. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From k.georgiou at imperial.ac.uk Thu Jun 21 08:36:59 2007 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Thu, 21 Jun 2007 09:36:59 +0100 Subject: Missing Dependency in rhgb package? In-Reply-To: <200706210410.37004.lightsolphoenix@gmail.com> References: <200706201342.43008.lightsolphoenix@gmail.com> <200706210317.01386.lightsolphoenix@gmail.com> <604aa7910706210025m276b0ff9udc02cd663dc1a469@mail.gmail.com> <200706210410.37004.lightsolphoenix@gmail.com> Message-ID: <20070621083659.GA21184@imperial.ac.uk> On Thu, Jun 21, 2007 at 04:10:36AM -0400, Kelly wrote: > On Thursday, June 21, 2007 3:25 am Jeff Spaleta wrote: > > there IS a dependency, there's absolutely no question about that. The > > question is what's going wrong on your system that allowed rhgb to be > > installed without vte. > > I dunno. I installed off the KDE Live CD, which doesn't have rhgb on it. > What I don't understand is how I could select to install it without getting > any of it's dependencies. I would guess https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244077 Kostas From caillon at redhat.com Thu Jun 21 14:00:17 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 21 Jun 2007 10:00:17 -0400 Subject: [Fwd: [Fedora Update] [comment] evince-0.8.0-6.fc7] In-Reply-To: <1182369121.3946.9.camel@lt21223.campus.dmacc.edu> References: <1182355681.2904.96.camel@cookie.hadess.net> <1182358473.14977.49.camel@weaponx.rchland.ibm.com> <1182358789.15482.1.camel@rousalka.dyndns.org> <200706201304.46360.jkeating@redhat.com> <1182369121.3946.9.camel@lt21223.campus.dmacc.edu> Message-ID: <467A8471.5000505@redhat.com> Jeffrey C. Ollie wrote: > On Wed, 2007-06-20 at 13:04 -0400, Jesse Keating wrote: >> On Wednesday 20 June 2007 12:59:48 Nicolas Mailhot wrote: >> > Actually bodhi should just create a bugzilla entry with the right >> > context when someone wants to comment on an update (and link it on the >> > bodhi page) >> >> Mapping the commenter to a valid bugzilla ID is hard, mapping it to bodhi >> guarantees you get no feedback from bug comments. >> >> I think the idea of comments was to allow commentary on the update coming from >> those without bugzilla accounts or without the overhead of bugzilla. Things >> like "this solved my problem" or "this update works great for me" aren't >> really suitable for bugzilla. But capturing those in the update entry rather >> than a mailing list seems ideal. > > What if bodhi put a link to a bugzilla query that would pull up all the > recent bug activity for the package? > > https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Fedora&version=devel&component=kernel&component_text=&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&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=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=14&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number+Ascending&field0-0-0=noop&type0-0-0=noop&value0-0-0= > > (BTW, is there a way to specify in the URL what columns are displayed? > I was able to change my display to include the changed/opened date > but bugzilla seems to handle that through cookies or something like > that). I also highly recommend that if you're going to be doing automated stuff with bugzilla that you use the xml interface where possible to make parsing easier and more importantly, save load on an already stressed bugzilla. &ctype=xml From Jochen at herr-schmitt.de Thu Jun 21 19:10:56 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 21 Jun 2007 21:10:56 +0200 Subject: License issue with iText and releated packages Message-ID: <467ACD40.90900@herr-schmitt.de> Hello, I have a special license issue with iText and related packages like pdftk, which I want to discuss. For further information please look a BZ #236310, BZ #245222, BZ #236309 You should be aware, that the plain iText package offers in Fedora have the same issue like the packages with bundled iText implementations. Best Regards: Jochen Schmitt From Jochen at herr-schmitt.de Thu Jun 21 20:52:04 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 21 Jun 2007 22:52:04 +0200 Subject: Handling of unversioned upstream sources Message-ID: <467AE4F4.6080901@herr-schmitt.de> Hello, unfortunately, I have found some review request, where the upstream only offers unversion sources. The issue of this sources is, that you will not be able to access to the upstream code in the future, if the upstream has changed the content of this unversioned. So I want to ask, if there any guidelines about this topic? Best Regards: Jochen Schmitt From jwboyer at jdub.homelinux.org Thu Jun 21 21:11:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 21 Jun 2007 16:11:58 -0500 Subject: Handling of unversioned upstream sources In-Reply-To: <467AE4F4.6080901@herr-schmitt.de> References: <467AE4F4.6080901@herr-schmitt.de> Message-ID: <1182460318.11700.3.camel@weaponx.rchland.ibm.com> On Thu, 2007-06-21 at 22:52 +0200, Jochen Schmitt wrote: > Hello, > > unfortunately, I have found some review request, where the upstream only > offers > unversion sources. > > The issue of this sources is, that you will not be able to access to the > upstream code in the > future, if the upstream has changed the content of this unversioned. > > So I want to ask, if there any guidelines about this topic? http://fedoraproject.org/wiki/Packaging/SourceURL See the Revision Control section. If they don't even have an SCM like cvs or svn, then the best you can do is basically create a dated tarball. josh From limb at jcomserv.net Thu Jun 21 21:56:36 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 21 Jun 2007 16:56:36 -0500 (CDT) Subject: [Fwd: Broken dependencies in Fedora 7 + Test Updates - 2007-06-21] Message-ID: <4108.192.168.0.1.1182462996.squirrel@mail.jcomserv.net> This package's corresponding -data package is not disttagged, and needs to be linked from the version in rawhide. Who do I ask for help with this? Will I have to repeat the process once it goes to f-7 stable, and again for FC-6? ---------------------------- Original Message ---------------------------- Subject: Broken dependencies in Fedora 7 + Test Updates - 2007-06-21 From: "Fedora Extras repoclosure" Date: Thu, June 21, 2007 4:45 pm To: limb at jcomserv.net -------------------------------------------------------------------------- This is an automated mail created by an experimental script. Your following packages in the repository contain broken dependencies: ====================================================================== The results in this report consider Test Updates! ====================================================================== package: nexuiz - 2.3-1.fc7.i386 from fedora-updates-testing-7-i386 unresolved deps: nexuiz-data = 0:2.3 package: nexuiz - 2.3-1.fc7.ppc from fedora-updates-testing-7-ppc unresolved deps: nexuiz-data = 0:2.3 package: nexuiz - 2.3-1.fc7.x86_64 from fedora-updates-testing-7-x86_64 unresolved deps: nexuiz-data = 0:2.3 package: nexuiz-server - 2.3-1.fc7.i386 from fedora-updates-testing-7-i386 unresolved deps: nexuiz-data = 0:2.3 package: nexuiz-server - 2.3-1.fc7.ppc from fedora-updates-testing-7-ppc unresolved deps: nexuiz-data = 0:2.3 package: nexuiz-server - 2.3-1.fc7.x86_64 from fedora-updates-testing-7-x86_64 unresolved deps: nexuiz-data = 0:2.3 -- novus ordo absurdum From notting at redhat.com Thu Jun 21 22:06:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Jun 2007 18:06:43 -0400 Subject: [Fwd: Broken dependencies in Fedora 7 + Test Updates - 2007-06-21] In-Reply-To: <4108.192.168.0.1.1182462996.squirrel@mail.jcomserv.net> References: <4108.192.168.0.1.1182462996.squirrel@mail.jcomserv.net> Message-ID: <20070621220643.GA7725@nostromo.devel.redhat.com> Jon Ciesla (limb at jcomserv.net) said: > This package's corresponding -data package is not disttagged, and needs to > be linked from the version in rawhide. Who do I ask for help with this? > Will I have to repeat the process once it goes to f-7 stable, and again > for FC-6? Surely the data package exists in the F7 release? Bill From ajackson at redhat.com Thu Jun 21 22:12:32 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 21 Jun 2007 18:12:32 -0400 Subject: Handling of unversioned upstream sources In-Reply-To: <1182460318.11700.3.camel@weaponx.rchland.ibm.com> References: <467AE4F4.6080901@herr-schmitt.de> <1182460318.11700.3.camel@weaponx.rchland.ibm.com> Message-ID: <1182463952.30663.228.camel@localhost.localdomain> On Thu, 2007-06-21 at 16:11 -0500, Josh Boyer wrote: > On Thu, 2007-06-21 at 22:52 +0200, Jochen Schmitt wrote: > > Hello, > > > > unfortunately, I have found some review request, where the upstream only > > offers > > unversion sources. > > > > The issue of this sources is, that you will not be able to access to the > > upstream code in the > > future, if the upstream has changed the content of this unversioned. > > > > So I want to ask, if there any guidelines about this topic? > > http://fedoraproject.org/wiki/Packaging/SourceURL > > See the Revision Control section. If they don't even have an SCM like > cvs or svn, then the best you can do is basically create a dated > tarball. If you do so, use the Revision field for the date, and start the Version at 0. - ajax From jeff at ocjtech.us Fri Jun 22 02:44:10 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 21 Jun 2007 21:44:10 -0500 Subject: [Fwd: [Fedora Update] [comment] evince-0.8.0-6.fc7] In-Reply-To: <467A8471.5000505@redhat.com> References: <1182355681.2904.96.camel@cookie.hadess.net> <1182358473.14977.49.camel@weaponx.rchland.ibm.com> <1182358789.15482.1.camel@rousalka.dyndns.org> <200706201304.46360.jkeating@redhat.com> <1182369121.3946.9.camel@lt21223.campus.dmacc.edu> <467A8471.5000505@redhat.com> Message-ID: <1182480250.4088.8.camel@lt21223.campus.dmacc.edu> On Thu, 2007-06-21 at 10:00 -0400, Christopher Aillon wrote: > Jeffrey C. Ollie wrote: > > > > What if bodhi put a link to a bugzilla query that would pull up all the > > recent bug activity for the package? > > > > https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Fedora&version=devel&component=kernel&component_text=&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&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=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=14&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number+Ascending&field0-0-0=noop&type0-0-0=noop&value0-0-0= > > > > (BTW, is there a way to specify in the URL what columns are displayed? > > I was able to change my display to include the changed/opened date > > but bugzilla seems to handle that through cookies or something like > > that). > > I also highly recommend that if you're going to be doing automated stuff > with bugzilla that you use the xml interface where possible to make > parsing easier and more importantly, save load on an already stressed > bugzilla. > > &ctype=xml I wasn't thinking of doing anything "automatically" with this link. It would be there for rel-eng folks to click on so that they could quickly see recent bug activity on a package. 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 Fri Jun 22 08:45:49 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Jun 2007 10:45:49 +0200 Subject: [Fwd: Broken dependencies in Fedora 7 + Test Updates - 2007-06-21] In-Reply-To: <20070621220643.GA7725@nostromo.devel.redhat.com> References: <4108.192.168.0.1.1182462996.squirrel@mail.jcomserv.net> <20070621220643.GA7725@nostromo.devel.redhat.com> Message-ID: <20070622104549.d57fe3cd.bugs.michael@gmx.net> On Thu, 21 Jun 2007 18:06:43 -0400, Bill Nottingham wrote: > Jon Ciesla (limb at jcomserv.net) said: > > This package's corresponding -data package is not disttagged, and needs to > > be linked from the version in rawhide. Who do I ask for help with this? > > Will I have to repeat the process once it goes to f-7 stable, and again > > for FC-6? > > Surely the data package exists in the F7 release? Surely not. From Axel.Thimm at ATrpms.net Fri Jun 22 11:33:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Jun 2007 13:33:24 +0200 Subject: Handling of unversioned upstream sources In-Reply-To: <467AE4F4.6080901@herr-schmitt.de> References: <467AE4F4.6080901@herr-schmitt.de> Message-ID: <20070622113324.GD3087@puariko.nirvana> On Thu, Jun 21, 2007 at 10:52:04PM +0200, Jochen Schmitt wrote: > Hello, > > unfortunately, I have found some review request, where the upstream only > offers > unversion sources. > > The issue of this sources is, that you will not be able to access to the > upstream code in the > future, if the upstream has changed the content of this unversioned. > > So I want to ask, if there any guidelines about this topic? It is a soft topic, but if you do rename the sources, please try to keep the proper timestamps, and don't repackage a tarball, e.g. if you rename foo.tar.gz to foo-1.2.3.tar.gz and ar tempted to fix the directories inside as well, please don't. :) > Best Regards: > > Jochen Schmitt > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Fri Jun 22 15:02:09 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Jun 2007 17:02:09 +0200 Subject: Caution! Bad SONAME Provides Message-ID: <20070622170209.b5442bc3.bugs.michael@gmx.net> Broken dependencies are one thing, broken "Provides" another. The distribution includes an increasing number of packages, which don't filter their SONAME Provides when they include shared libraries in private paths. This can have devastating effects in conjunction with yum's "shortest package name wins" during depsolving. For example: libfoo provides libfoo.so.1 for %{_libdir}/libfoo.so.1 bar provides libfoo.so.1 for %{_libdir}/bar/plugins/libfoo.so.1.0.0 Only for libfoo the automatic "Provides: libfoo.so.1" is sane. And even if "bar" extended the ld.so configuration, it would conflict with libfoo in what it provides. I've reported a few such cases. All the others look like packages provide sonames for plugin libraries without actually conflicting with any library package in the Fedora Collection. Still it's dangerous if multiple packages provide "libfoo.so" (versioned or not), but neither one puts the library into run-time linker's search path. Sooner or later such dependencies might explode at run-time. Reviewers ought to examine "Provides" carefully and require packagers to filter the Provides if necessary. From jkeating at redhat.com Fri Jun 22 14:59:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Jun 2007 10:59:05 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <20070622170209.b5442bc3.bugs.michael@gmx.net> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> Message-ID: <200706221059.05454.jkeating@redhat.com> On Friday 22 June 2007 11:02:09 Michael Schwendt wrote: > The distribution includes an increasing number of packages, which don't > filter their SONAME Provides when they include shared libraries in private > paths. Do you have a useful tool for examining these, maybe at a repo level? This is something we'd want to have fixed up during the week before the freezes when we (rel-eng) start attacking the broken deps/upgradepaths with a vengeance. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Fri Jun 22 15:09:39 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 22 Jun 2007 11:09:39 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <20070622170209.b5442bc3.bugs.michael@gmx.net> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> Message-ID: <1182524979.30663.246.camel@localhost.localdomain> On Fri, 2007-06-22 at 17:02 +0200, Michael Schwendt wrote: > Broken dependencies are one thing, broken "Provides" another. > > The distribution includes an increasing number of packages, which don't > filter their SONAME Provides when they include shared libraries in private > paths. > > This can have devastating effects in conjunction with yum's "shortest > package name wins" during depsolving. For example: > > libfoo provides libfoo.so.1 for %{_libdir}/libfoo.so.1 > bar provides libfoo.so.1 for %{_libdir}/bar/plugins/libfoo.so.1.0.0 > > Only for libfoo the automatic "Provides: libfoo.so.1" is sane. And even if > "bar" extended the ld.so configuration, it would conflict with libfoo in > what it provides. > > I've reported a few such cases. All the others look like packages provide > sonames for plugin libraries without actually conflicting with any library > package in the Fedora Collection. Still it's dangerous if multiple packages > provide "libfoo.so" (versioned or not), but neither one puts the library > into run-time linker's search path. Sooner or later such dependencies > might explode at run-time. > > Reviewers ought to examine "Provides" carefully and require packagers to > filter the Provides if necessary. How should I filter these, short of AutoReqProv: 0 ? - ajax From jkeating at redhat.com Fri Jun 22 15:16:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Jun 2007 11:16:38 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <1182524979.30663.246.camel@localhost.localdomain> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> Message-ID: <200706221116.38840.jkeating@redhat.com> On Friday 22 June 2007 11:09:39 Adam Jackson wrote: > How should I filter these, short of AutoReqProv: 0 ? One "way" would be to not mark these libraries as executable. IIRC rpm autoprov/req scripts will only consider libraries that are marked as executable. Of course, that may kill /both/ provides and requires, and you may want those requires to happen... -- 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 dan at danny.cz Fri Jun 22 15:31:48 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 22 Jun 2007 17:31:48 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <20070622170209.b5442bc3.bugs.michael@gmx.net> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> Message-ID: <1182526308.4158.4.camel@eagle.danny.cz> Michael Schwendt p??e v P? 22. 06. 2007 v 17:02 +0200: > Broken dependencies are one thing, broken "Provides" another. > > The distribution includes an increasing number of packages, which don't > filter their SONAME Provides when they include shared libraries in private > paths. > Or they could use "libtool -module" to link the plugins, they are called only libfoo.so then and this name is also in "Provides". > This can have devastating effects in conjunction with yum's "shortest > package name wins" during depsolving. For example: > > libfoo provides libfoo.so.1 for %{_libdir}/libfoo.so.1 > bar provides libfoo.so.1 for %{_libdir}/bar/plugins/libfoo.so.1.0.0 > > Only for libfoo the automatic "Provides: libfoo.so.1" is sane. And even if > "bar" extended the ld.so configuration, it would conflict with libfoo in > what it provides. > > I've reported a few such cases. All the others look like packages provide > sonames for plugin libraries without actually conflicting with any library > package in the Fedora Collection. Still it's dangerous if multiple packages > provide "libfoo.so" (versioned or not), but neither one puts the library > into run-time linker's search path. Sooner or later such dependencies > might explode at run-time. > > Reviewers ought to examine "Provides" carefully and require packagers to > filter the Provides if necessary. Dan From tibbs at math.uh.edu Fri Jun 22 15:32:28 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Jun 2007 10:32:28 -0500 Subject: Caution! Bad SONAME Provides In-Reply-To: <20070622170209.b5442bc3.bugs.michael@gmx.net> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Broken dependencies are one thing, broken "Provides" another. The MS> distribution includes an increasing number of packages, which MS> don't filter their SONAME Provides when they include shared MS> libraries in private paths. I recall past discussions about whether these were problematic but I never recall seeing any mandate that they be filtered. Frankly, these are so incredibly common that I really think it's completely counterproductive to require packagers to go out of their way to fix broken dependency generation. Why not fix the dependency generator instead? All it needs to do to fix up most of the issues is not look outside the standard library paths. For those rather few packages which add to the regular ldconfig search path, they can either add dependencies manually or can be provided with some way to add directories that the dependency generator will search. It could even look for files contained in the package which will be placed in /etc/ld.so.conf.d and automatically generate dependencies for them. - J< From dan at danny.cz Fri Jun 22 15:31:48 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 22 Jun 2007 17:31:48 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <20070622170209.b5442bc3.bugs.michael@gmx.net> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> Message-ID: <1182526308.4158.4.camel@eagle.danny.cz> Michael Schwendt p??e v P? 22. 06. 2007 v 17:02 +0200: > Broken dependencies are one thing, broken "Provides" another. > > The distribution includes an increasing number of packages, which don't > filter their SONAME Provides when they include shared libraries in private > paths. > Or they could use "libtool -module" to link the plugins, they are called only libfoo.so then and this name is also in "Provides". > This can have devastating effects in conjunction with yum's "shortest > package name wins" during depsolving. For example: > > libfoo provides libfoo.so.1 for %{_libdir}/libfoo.so.1 > bar provides libfoo.so.1 for %{_libdir}/bar/plugins/libfoo.so.1.0.0 > > Only for libfoo the automatic "Provides: libfoo.so.1" is sane. And even if > "bar" extended the ld.so configuration, it would conflict with libfoo in > what it provides. > > I've reported a few such cases. All the others look like packages provide > sonames for plugin libraries without actually conflicting with any library > package in the Fedora Collection. Still it's dangerous if multiple packages > provide "libfoo.so" (versioned or not), but neither one puts the library > into run-time linker's search path. Sooner or later such dependencies > might explode at run-time. > > Reviewers ought to examine "Provides" carefully and require packagers to > filter the Provides if necessary. Dan From bugs.michael at gmx.net Fri Jun 22 17:04:22 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Jun 2007 19:04:22 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <1182524979.30663.246.camel@localhost.localdomain> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> Message-ID: <20070622190422.fea358ce.bugs.michael@gmx.net> On Fri, 22 Jun 2007 11:09:39 -0400, Adam Jackson wrote: > > Reviewers ought to examine "Provides" carefully and require packagers to > > filter the Provides if necessary. > > How should I filter these, short of AutoReqProv: 0 ? No, that would disable too much. One recipe: http://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencies?highlight=%28find_provides%29#head-4c30232b398f85bec95f72bc6bb66b5bbf524be3 http://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencies Another recipe uses a patch against /usr/lib/rpm/redhat/find-provides (the packager needs to create the patch and run "sed" in the right place to drop sonames): %define _use_internal_dependency_generator 0 cp -a /usr/lib/rpm/redhat/find-provides %{_tmppath}/find-provides.%{name} patch %{_tmppath}/find-provides.%{name} %{PATCH0} %define __find_provides %{_tmppath}/find-provides.%{name} From ajackson at redhat.com Fri Jun 22 17:00:39 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 22 Jun 2007 13:00:39 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: References: <20070622170209.b5442bc3.bugs.michael@gmx.net> Message-ID: <1182531639.30663.264.camel@localhost.localdomain> On Fri, 2007-06-22 at 10:32 -0500, Jason L Tibbitts III wrote: > >>>>> "MS" == Michael Schwendt writes: > > MS> Broken dependencies are one thing, broken "Provides" another. The > MS> distribution includes an increasing number of packages, which > MS> don't filter their SONAME Provides when they include shared > MS> libraries in private paths. > > I recall past discussions about whether these were problematic but I > never recall seeing any mandate that they be filtered. > > Frankly, these are so incredibly common that I really think it's > completely counterproductive to require packagers to go out of their > way to fix broken dependency generation. Why not fix the dependency > generator instead? > > All it needs to do to fix up most of the issues is not look outside > the standard library paths. ... and any rpaths specified in any binaries in that package. Oh, and any rpaths specified in _any_ binary in _any_ other package. Maybe not. - ajax From jkeating at redhat.com Fri Jun 22 17:03:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Jun 2007 13:03:53 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <20070622190422.fea358ce.bugs.michael@gmx.net> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <20070622190422.fea358ce.bugs.michael@gmx.net> Message-ID: <200706221303.57571.jkeating@redhat.com> On Friday 22 June 2007 13:04:22 Michael Schwendt wrote: > On Fri, 22 Jun 2007 11:09:39 -0400, Adam Jackson wrote: > > > Reviewers ought to examine "Provides" carefully and require packagers > > > to filter the Provides if necessary. > > > > How should I filter these, short of AutoReqProv: 0 ? > > No, that would disable too much. > > > One recipe: > > http://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencie >s?highlight=%28find_provides%29#head-4c30232b398f85bec95f72bc6bb66b5bbf524be >3 > > http://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencie >s > > > Another recipe uses a patch against /usr/lib/rpm/redhat/find-provides > (the packager needs to create the patch and run "sed" in the right > place to drop sonames): > > %define _use_internal_dependency_generator 0 > cp -a /usr/lib/rpm/redhat/find-provides %{_tmppath}/find-provides.%{name} > patch %{_tmppath}/find-provides.%{name} %{PATCH0} > %define __find_provides %{_tmppath}/find-provides.%{name} The question I have is why can't we teach the provides finder to be smarter about things that are outside the standard path? Why fix this in N* packages instead of the source? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Fri Jun 22 17:11:47 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 22 Jun 2007 13:11:47 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <200706221116.38840.jkeating@redhat.com> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <200706221116.38840.jkeating@redhat.com> Message-ID: <1182532307.30663.272.camel@localhost.localdomain> On Fri, 2007-06-22 at 11:16 -0400, Jesse Keating wrote: > On Friday 22 June 2007 11:09:39 Adam Jackson wrote: > > How should I filter these, short of AutoReqProv: 0 ? > > One "way" would be to not mark these libraries as executable. IIRC rpm > autoprov/req scripts will only consider libraries that are marked as > executable. Of course, that may kill /both/ provides and requires, and you > may want those requires to happen... I thought dlopen would carp about non-executable files, but I appear to be mistaken. Another way, I suppose, would be to rip the soname field out of the DSO. There doesn't seem to be a standard utility to do that though. - ajax From fedora at camperquake.de Fri Jun 22 17:21:20 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 22 Jun 2007 19:21:20 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <200706221303.57571.jkeating@redhat.com> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <20070622190422.fea358ce.bugs.michael@gmx.net> <200706221303.57571.jkeating@redhat.com> Message-ID: <20070622192120.449f0652@lain.camperquake.de> Hi. On Fri, 22 Jun 2007 13:03:53 -0400, Jesse Keating wrote > The question I have is why can't we teach the provides finder to be > smarter about things that are outside the standard path? Why fix > this in N* packages instead of the source? Could we define a variable in the spec file containing paths that are not to be searched? I know I could use that for audacious (audacious-plugins Provides: all the plugin .so files, and noone really cares about them). From bugs.michael at gmx.net Fri Jun 22 17:27:47 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Jun 2007 19:27:47 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <200706221303.57571.jkeating@redhat.com> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <20070622190422.fea358ce.bugs.michael@gmx.net> <200706221303.57571.jkeating@redhat.com> Message-ID: <20070622192747.21521c02.bugs.michael@gmx.net> On Fri, 22 Jun 2007 13:03:53 -0400, Jesse Keating wrote: > The question I have is why can't we teach the provides finder to be smarter > about things that are outside the standard path? Why fix this in N* packages > instead of the source? Good question. ;) How many packages benefit from automatic Prov/Req for libraries they store outside default run-time linker's search path? Is it just a few huge application suites, which alter the linker's search path at run-time to point it to many private libs? How many packages use LD_LIBRARY_PATH, RPATH, or ld.so.conf.d files? Are there inter-package dependencies for library sonames in private paths? [...] Two example bugs of where the "Provides" cause a real conflict: https://bugzilla.redhat.com/245323 (libmd5.so.0) https://bugzilla.redhat.com/245326 (libsqlite.so.0) From rc040203 at freenet.de Fri Jun 22 17:32:10 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 22 Jun 2007 19:32:10 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <1182532307.30663.272.camel@localhost.localdomain> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <200706221116.38840.jkeating@redhat.com> <1182532307.30663.272.camel@localhost.localdomain> Message-ID: <1182533530.6710.262.camel@mccallum.corsepiu.local> On Fri, 2007-06-22 at 13:11 -0400, Adam Jackson wrote: > On Fri, 2007-06-22 at 11:16 -0400, Jesse Keating wrote: > > On Friday 22 June 2007 11:09:39 Adam Jackson wrote: > > > How should I filter these, short of AutoReqProv: 0 ? > > > > One "way" would be to not mark these libraries as executable. IIRC rpm > > autoprov/req scripts will only consider libraries that are marked as > > executable. Of course, that may kill /both/ provides and requires, and you > > may want those requires to happen... > > I thought dlopen would carp about non-executable files, but I appear to > be mistaken. > > Another way, I suppose, would be to rip the soname field out of the DSO. Are you serious? IMO, this is the worst imaginable approach, directly leading into Windowish DLL hell. The bugs related to SONAME handling are in rpm and the package managers. The SONAMEs are just the trigger, not cause. Ralf From ajackson at redhat.com Fri Jun 22 17:27:22 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 22 Jun 2007 13:27:22 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <1182533530.6710.262.camel@mccallum.corsepiu.local> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <200706221116.38840.jkeating@redhat.com> <1182532307.30663.272.camel@localhost.localdomain> <1182533530.6710.262.camel@mccallum.corsepiu.local> Message-ID: <1182533242.30663.275.camel@localhost.localdomain> On Fri, 2007-06-22 at 19:32 +0200, Ralf Corsepius wrote: > On Fri, 2007-06-22 at 13:11 -0400, Adam Jackson wrote: > > On Fri, 2007-06-22 at 11:16 -0400, Jesse Keating wrote: > > > On Friday 22 June 2007 11:09:39 Adam Jackson wrote: > > > > How should I filter these, short of AutoReqProv: 0 ? > > > > > > One "way" would be to not mark these libraries as executable. IIRC rpm > > > autoprov/req scripts will only consider libraries that are marked as > > > executable. Of course, that may kill /both/ provides and requires, and you > > > may want those requires to happen... > > > > I thought dlopen would carp about non-executable files, but I appear to > > be mistaken. > > > > Another way, I suppose, would be to rip the soname field out of the DSO. > Are you serious? IMO, this is the worst imaginable approach, directly > leading into Windowish DLL hell. > > The bugs related to SONAME handling are in rpm and the package managers. > The SONAMEs are just the trigger, not cause. Yes, I am serious. I have lots of modules that you're never supposed to link against. They're called X drivers, they're dlopen-only. The soname is completely superfluous, and is only there because libtool is such a flaming pile of crap. - ajax From laurent.rineau__fedora at normalesup.org Fri Jun 22 17:36:46 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Fri, 22 Jun 2007 19:36:46 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <1182533530.6710.262.camel@mccallum.corsepiu.local> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182532307.30663.272.camel@localhost.localdomain> <1182533530.6710.262.camel@mccallum.corsepiu.local> Message-ID: <200706221936.46475@rineau.tsetse> On Friday 22 June 2007 07:32:10 pm Ralf Corsepius wrote: > > Another way, I suppose, would be to rip the soname field out of the DSO. > > Are you serious? IMO, this is the worst imaginable approach, directly > leading into Windowish DLL hell. > > The bugs related to SONAME handling are in rpm and the package managers. > The SONAMEs are just the trigger, not cause. dlopen can use soname fields? In what way? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From katzj at redhat.com Fri Jun 22 17:45:36 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 22 Jun 2007 13:45:36 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <20070622192120.449f0652@lain.camperquake.de> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <20070622190422.fea358ce.bugs.michael@gmx.net> <200706221303.57571.jkeating@redhat.com> <20070622192120.449f0652@lain.camperquake.de> Message-ID: <1182534336.2720.6.camel@aglarond.local> On Fri, 2007-06-22 at 19:21 +0200, Ralf Ertzinger wrote: > On Fri, 22 Jun 2007 13:03:53 -0400, Jesse Keating wrote > > The question I have is why can't we teach the provides finder to be > > smarter about things that are outside the standard path? Why fix > > this in N* packages instead of the source? > > Could we define a variable in the spec file containing paths that > are not to be searched? This isn't that hard to do if we think it would be useful. And thinking about it, I'm pretty sure it would be -- a lot of the cases that people disable the internal dep generator are to be able to do something like this. And disabling the internal dep generator has other downsides like not ensuring files are marked with the proper file color. The big question is do we just define paths not to be searched or a blacklist of things not to include or the like. Jeremy From notting at redhat.com Fri Jun 22 18:18:37 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 Jun 2007 14:18:37 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <1182534336.2720.6.camel@aglarond.local> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <20070622190422.fea358ce.bugs.michael@gmx.net> <200706221303.57571.jkeating@redhat.com> <20070622192120.449f0652@lain.camperquake.de> <1182534336.2720.6.camel@aglarond.local> Message-ID: <20070622181837.GB7155@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > > Could we define a variable in the spec file containing paths that > > are not to be searched? > > This isn't that hard to do if we think it would be useful. And thinking > about it, I'm pretty sure it would be -- a lot of the cases that people > disable the internal dep generator are to be able to do something like > this. And disabling the internal dep generator has other downsides like > not ensuring files are marked with the proper file color. > > The big question is do we just define paths not to be searched or a > blacklist of things not to include or the like. For Provides:, I'd just do standard library dirs + ld.so.conf.d. However, if you do this, you'll need/want to also add a patch that filters Requires: on things Provided: in the same package, otherwise you'll get Requires: you can't fill. Then, do a mass rebuild and see what breaks. Bill From ivazqueznet at gmail.com Fri Jun 22 18:41:20 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 22 Jun 2007 14:41:20 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <20070622181837.GB7155@nostromo.devel.redhat.com> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <20070622190422.fea358ce.bugs.michael@gmx.net> <200706221303.57571.jkeating@redhat.com> <20070622192120.449f0652@lain.camperquake.de> <1182534336.2720.6.camel@aglarond.local> <20070622181837.GB7155@nostromo.devel.redhat.com> Message-ID: <1182537680.15485.1.camel@ignacio.lan> On Fri, 2007-06-22 at 14:18 -0400, Bill Nottingham wrote: > For Provides:, I'd just do standard library dirs + ld.so.conf.d. Here's a script I wrote a while back that finds those dirs. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: parseldconfig Type: application/x-shellscript Size: 460 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Fri Jun 22 18:45:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 Jun 2007 14:45:46 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <1182531639.30663.264.camel@localhost.localdomain> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182531639.30663.264.camel@localhost.localdomain> Message-ID: <20070622184546.GA8037@nostromo.devel.redhat.com> Adam Jackson (ajackson at redhat.com) said: > ... and any rpaths specified in any binaries in that package. Oh, and > any rpaths specified in _any_ binary in _any_ other package. For example, anything that uses firefox. Yeah, I can see how this could get problematic real fast. Bill From pjones at redhat.com Fri Jun 22 19:24:12 2007 From: pjones at redhat.com (Peter Jones) Date: Fri, 22 Jun 2007 15:24:12 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <200706221303.57571.jkeating@redhat.com> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <20070622190422.fea358ce.bugs.michael@gmx.net> <200706221303.57571.jkeating@redhat.com> Message-ID: <467C21DC.3070901@redhat.com> Jesse Keating wrote: > The question I have is why can't we teach the provides finder to be smarter > about things that are outside the standard path? Why fix this in N* packages > instead of the source? There is effectively no standard path. find-provides can't know if some other package is Required: but not BuildRequired: and drops a file in /etc/ld.so.conf.d/ . -- Peter From pjones at redhat.com Fri Jun 22 19:27:28 2007 From: pjones at redhat.com (Peter Jones) Date: Fri, 22 Jun 2007 15:27:28 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <1182531639.30663.264.camel@localhost.localdomain> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182531639.30663.264.camel@localhost.localdomain> Message-ID: <467C22A0.30404@redhat.com> Adam Jackson wrote: > On Fri, 2007-06-22 at 10:32 -0500, Jason L Tibbitts III wrote: >>>>>>> "MS" == Michael Schwendt writes: >> MS> Broken dependencies are one thing, broken "Provides" another. The >> MS> distribution includes an increasing number of packages, which >> MS> don't filter their SONAME Provides when they include shared >> MS> libraries in private paths. >> >> I recall past discussions about whether these were problematic but I >> never recall seeing any mandate that they be filtered. >> >> Frankly, these are so incredibly common that I really think it's >> completely counterproductive to require packagers to go out of their >> way to fix broken dependency generation. Why not fix the dependency >> generator instead? >> >> All it needs to do to fix up most of the issues is not look outside >> the standard library paths. > > ... and any rpaths specified in any binaries in that package. Oh, and > any rpaths specified in _any_ binary in _any_ other package. I don't think we /really/ care about the "rpath's in other packages" case. If the other packages need firefox's copy of zlib, they should require firefox (or at least the library directory it's dropping in?) -- Peter From notting at redhat.com Fri Jun 22 19:30:47 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 Jun 2007 15:30:47 -0400 Subject: Caution! Bad SONAME Provides In-Reply-To: <467C22A0.30404@redhat.com> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182531639.30663.264.camel@localhost.localdomain> <467C22A0.30404@redhat.com> Message-ID: <20070622193047.GA9019@nostromo.devel.redhat.com> Peter Jones (pjones at redhat.com) said: > I don't think we /really/ care about the "rpath's in other packages" > case. If the other packages need firefox's copy of zlib, they should > require firefox (or at least the library directory it's dropping in?) Nah, just expand the symbol-versioning meta-markup to handle paths too, and use that when resolving deps if things actually have RPATHs. Bill From ruben at rubenkerkhof.com Fri Jun 22 19:49:20 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Fri, 22 Jun 2007 21:49:20 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <20070622170209.b5442bc3.bugs.michael@gmx.net> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> Message-ID: On 22-jun-2007, at 17:02, Michael Schwendt wrote: > Broken dependencies are one thing, broken "Provides" another. > > The distribution includes an increasing number of packages, which > don't > filter their SONAME Provides when they include shared libraries in > private > paths. > > This can have devastating effects in conjunction with yum's "shortest > package name wins" during depsolving. For example: > > libfoo provides libfoo.so.1 for %{_libdir}/libfoo.so.1 > bar provides libfoo.so.1 for %{_libdir}/bar/plugins/ > libfoo.so.1.0.0 > > Only for libfoo the automatic "Provides: libfoo.so.1" is sane. And > even if > "bar" extended the ld.so configuration, it would conflict with > libfoo in > what it provides. > > I've reported a few such cases. All the others look like packages > provide > sonames for plugin libraries without actually conflicting with any > library > package in the Fedora Collection. Still it's dangerous if multiple > packages > provide "libfoo.so" (versioned or not), but neither one puts the > library > into run-time linker's search path. Sooner or later such dependencies > might explode at run-time. Funny, a user of one of my packages, csync2, reported upstream that he had a problem with my package on F-7. He got "unresolved symbol" errors. It turns out that somehow csync2 got linked to sqlite3, while it has a BuildRequires on sqlite2-devel Until reading this thread, I had no idea how this happened, so I installed F-7 on a new box, and did a yum install csync2. Yum wanted to pull in dbmail as a dependency, but that's strange, since csync2 shouldn't use dbmail. Turns out dbmail provides libsqlite.so.0 (it's in /usr/lib/dbmail/ libsqlite.so.0), which is a sqlite3 library. I'm glad I've found this, but it would be great if we could somehow prevent things like this happening. Ruben From ruben at rubenkerkhof.com Fri Jun 22 19:49:20 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Fri, 22 Jun 2007 21:49:20 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <20070622170209.b5442bc3.bugs.michael@gmx.net> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> Message-ID: On 22-jun-2007, at 17:02, Michael Schwendt wrote: > Broken dependencies are one thing, broken "Provides" another. > > The distribution includes an increasing number of packages, which > don't > filter their SONAME Provides when they include shared libraries in > private > paths. > > This can have devastating effects in conjunction with yum's "shortest > package name wins" during depsolving. For example: > > libfoo provides libfoo.so.1 for %{_libdir}/libfoo.so.1 > bar provides libfoo.so.1 for %{_libdir}/bar/plugins/ > libfoo.so.1.0.0 > > Only for libfoo the automatic "Provides: libfoo.so.1" is sane. And > even if > "bar" extended the ld.so configuration, it would conflict with > libfoo in > what it provides. > > I've reported a few such cases. All the others look like packages > provide > sonames for plugin libraries without actually conflicting with any > library > package in the Fedora Collection. Still it's dangerous if multiple > packages > provide "libfoo.so" (versioned or not), but neither one puts the > library > into run-time linker's search path. Sooner or later such dependencies > might explode at run-time. Funny, a user of one of my packages, csync2, reported upstream that he had a problem with my package on F-7. He got "unresolved symbol" errors. It turns out that somehow csync2 got linked to sqlite3, while it has a BuildRequires on sqlite2-devel Until reading this thread, I had no idea how this happened, so I installed F-7 on a new box, and did a yum install csync2. Yum wanted to pull in dbmail as a dependency, but that's strange, since csync2 shouldn't use dbmail. Turns out dbmail provides libsqlite.so.0 (it's in /usr/lib/dbmail/ libsqlite.so.0), which is a sqlite3 library. I'm glad I've found this, but it would be great if we could somehow prevent things like this happening. Ruben From bugs.michael at gmx.net Fri Jun 22 20:22:28 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Jun 2007 22:22:28 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: References: <20070622170209.b5442bc3.bugs.michael@gmx.net> Message-ID: <20070622222228.cd61d193.bugs.michael@gmx.net> On Fri, 22 Jun 2007 21:49:20 +0200, Ruben Kerkhof wrote: > Funny, a user of one of my packages, csync2, reported upstream that > he had a problem with my package on F-7. > He got "unresolved symbol" errors. It turns out that somehow csync2 > got linked to sqlite3, while it has a BuildRequires on sqlite2-devel > > Until reading this thread, I had no idea how this happened, so I > installed F-7 on a new box, and did a yum install csync2. > Yum wanted to pull in dbmail as a dependency, but that's strange, > since csync2 shouldn't use dbmail. > > Turns out dbmail provides libsqlite.so.0 (it's in /usr/lib/dbmail/ > libsqlite.so.0), which is a sqlite3 library. Yeah, that's bug 245326 From mszpak at wp.pl Fri Jun 22 20:47:22 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Fri, 22 Jun 2007 22:47:22 +0200 Subject: Update policy in F7 (Was: Re: Package EVR problems in Fedora 2007-06-22) In-Reply-To: <20070622090032.0855C152134@buildsys.fedoraproject.org> References: <20070622090032.0855C152134@buildsys.fedoraproject.org> Message-ID: <467C355A.40902@wp.pl> Hi, Today I received following email: > isomaster > FE5 > F7 (0:1.0-1.fc5 > 0:0.8.1-1.fc7) > FE6 > F7 (0:1.0-1.fc6 > 0:0.8.1-1.fc7) I'm not surprised, because in in FC5, FC6 and devel there are updated versions. Package for F7 is tagged as "dist-fc7-updates-candidate". I saw a thread about update policy in F7 some time ago (that users are overwhelmed by tons of actualizations and not every updated package should be pushes to F7 main repository as well as need to have better info about "what's new"), but I don't remember conclusion about that. So, I have a few questions. 1. Is there some wiki page with update policy in F7 (especially for those former FE)? 2. Who decides which packages will be pushed to "tests stage"? 3. Should a packager suggest (somehow) if (s)he thinks that specified package version should be worth pushing to the end user? Regards Marcin From bugs.michael at gmx.net Fri Jun 22 21:15:36 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Jun 2007 23:15:36 +0200 Subject: More fun with SONAME Provides In-Reply-To: <20070622170209.b5442bc3.bugs.michael@gmx.net> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> Message-ID: <20070622231536.85df21e2.bugs.michael@gmx.net> Second run, trying to eliminate some harmless positives automatically... Trouble ahead: lam-libs provides libmpi.so.0 required by: ScientificPython - 2.6-8.fc7.i386 required by: R-RScaLAPACK - 0.5.1-9.fc7.i386 required by: blacs - 1.1-24.fc7.1.i386 required by: lam - 2:7.1.2-10.fc7.i386 required by: lam-devel - 2:7.1.2-10.fc7.i386 required by: openmpi - 1.1-8.fc7.i386 required by: openmpi-devel - 1.1-8.fc7.i386 required by: openmpi-libs - 1.1-8.fc7.i386 required by: scalapack - 1.7.5-1.fc7.i386 required by: tachyon-lam - 0.97-4.fc7.i386 required by: tachyon-lam-gl - 0.97-4.fc7.i386 openmpi-libs provides libmpi.so.0 required by: ScientificPython - 2.6-8.fc7.i386 required by: R-RScaLAPACK - 0.5.1-9.fc7.i386 required by: blacs - 1.1-24.fc7.1.i386 required by: lam - 2:7.1.2-10.fc7.i386 required by: lam-devel - 2:7.1.2-10.fc7.i386 required by: lam-libs - 2:7.1.2-10.fc7.i386 required by: openmpi - 1.1-8.fc7.i386 required by: openmpi-devel - 1.1-8.fc7.i386 required by: scalapack - 1.7.5-1.fc7.i386 required by: tachyon-lam - 0.97-4.fc7.i386 required by: tachyon-lam-gl - 0.97-4.fc7.i386 Both packages store libmpi.so.0 in a private path, /usr/lib/lam/ and /usr/lib/openmpi/ respectively. Still there are other packages which require libmpi.so.0 => there are bad dependencies here. qt-qsa provides libqsa.so.1 required by: qt4-qsa - 1.2.2-4.fc7.i386 required by: qt4-qsa-devel - 1.2.2-4.fc7.i386 required by: LabPlot - 1.5.1.5-7.fc7.i386 required by: museek+ - 0.1.12-5.fc7.i386 required by: qt-qsa-devel - 1.1.4-3.fc7.i386 qt4-qsa provides libqsa.so.1 required by: qt4-qsa-devel - 1.2.2-4.fc7.i386 required by: LabPlot - 1.5.1.5-7.fc7.i386 required by: museek+ - 0.1.12-5.fc7.i386 required by: qt-qsa - 1.1.4-3.fc7.i386 required by: qt-qsa-devel - 1.1.4-3.fc7.i386 Both are Qt plugins in a private path. That other packages depend on the soname is a bug, because they don't get what the depend on (Qt3 vs. Qt4) From Axel.Thimm at ATrpms.net Fri Jun 22 21:54:58 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Jun 2007 23:54:58 +0200 Subject: More fun with SONAME Provides In-Reply-To: <20070622231536.85df21e2.bugs.michael@gmx.net> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <20070622231536.85df21e2.bugs.michael@gmx.net> Message-ID: <20070622215458.GA18986@puariko.nirvana> On Fri, Jun 22, 2007 at 11:15:36PM +0200, Michael Schwendt wrote: > Second run, trying to eliminate some harmless positives automatically... > > Trouble ahead: > > lam-libs provides libmpi.so.0 > required by: ScientificPython - 2.6-8.fc7.i386 > required by: R-RScaLAPACK - 0.5.1-9.fc7.i386 > required by: blacs - 1.1-24.fc7.1.i386 > required by: lam - 2:7.1.2-10.fc7.i386 > required by: lam-devel - 2:7.1.2-10.fc7.i386 > required by: openmpi - 1.1-8.fc7.i386 > required by: openmpi-devel - 1.1-8.fc7.i386 > required by: openmpi-libs - 1.1-8.fc7.i386 > required by: scalapack - 1.7.5-1.fc7.i386 > required by: tachyon-lam - 0.97-4.fc7.i386 > required by: tachyon-lam-gl - 0.97-4.fc7.i386 > openmpi-libs provides libmpi.so.0 > required by: ScientificPython - 2.6-8.fc7.i386 > required by: R-RScaLAPACK - 0.5.1-9.fc7.i386 > required by: blacs - 1.1-24.fc7.1.i386 > required by: lam - 2:7.1.2-10.fc7.i386 > required by: lam-devel - 2:7.1.2-10.fc7.i386 > required by: lam-libs - 2:7.1.2-10.fc7.i386 > required by: openmpi - 1.1-8.fc7.i386 > required by: openmpi-devel - 1.1-8.fc7.i386 > required by: scalapack - 1.7.5-1.fc7.i386 > required by: tachyon-lam - 0.97-4.fc7.i386 > required by: tachyon-lam-gl - 0.97-4.fc7.i386 > > Both packages store libmpi.so.0 in a private path, /usr/lib/lam/ and > /usr/lib/openmpi/ respectively. Still there are other packages which > require libmpi.so.0 => there are bad dependencies here. Can you explain what are bad dependencies here? > qt-qsa provides libqsa.so.1 > required by: qt4-qsa - 1.2.2-4.fc7.i386 > required by: qt4-qsa-devel - 1.2.2-4.fc7.i386 > required by: LabPlot - 1.5.1.5-7.fc7.i386 > required by: museek+ - 0.1.12-5.fc7.i386 > required by: qt-qsa-devel - 1.1.4-3.fc7.i386 > qt4-qsa provides libqsa.so.1 > required by: qt4-qsa-devel - 1.2.2-4.fc7.i386 > required by: LabPlot - 1.5.1.5-7.fc7.i386 > required by: museek+ - 0.1.12-5.fc7.i386 > required by: qt-qsa - 1.1.4-3.fc7.i386 > required by: qt-qsa-devel - 1.1.4-3.fc7.i386 > > Both are Qt plugins in a private path. That other packages depend on the > soname is a bug, because they don't get what the depend on (Qt3 vs. Qt4) > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Jun 22 21:59:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 22 Jun 2007 23:59:37 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <1182534336.2720.6.camel@aglarond.local> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <20070622190422.fea358ce.bugs.michael@gmx.net> <200706221303.57571.jkeating@redhat.com> <20070622192120.449f0652@lain.camperquake.de> <1182534336.2720.6.camel@aglarond.local> Message-ID: <20070622215937.GB18986@puariko.nirvana> On Fri, Jun 22, 2007 at 01:45:36PM -0400, Jeremy Katz wrote: > On Fri, 2007-06-22 at 19:21 +0200, Ralf Ertzinger wrote: > > On Fri, 22 Jun 2007 13:03:53 -0400, Jesse Keating wrote > > > The question I have is why can't we teach the provides finder to be > > > smarter about things that are outside the standard path? Why fix > > > this in N* packages instead of the source? > > > > Could we define a variable in the spec file containing paths that > > are not to be searched? > > This isn't that hard to do if we think it would be useful. And thinking > about it, I'm pretty sure it would be -- a lot of the cases that people > disable the internal dep generator are to be able to do something like > this. And disabling the internal dep generator has other downsides like > not ensuring files are marked with the proper file color. > > The big question is do we just define paths not to be searched or a > blacklist of things not to include or the like. Allow a blacklist method per package. This is a problem that cannot be globally solved. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Fri Jun 22 22:07:21 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 23 Jun 2007 00:07:21 +0200 Subject: More fun with SONAME Provides In-Reply-To: <20070622215458.GA18986@puariko.nirvana> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <20070622231536.85df21e2.bugs.michael@gmx.net> <20070622215458.GA18986@puariko.nirvana> Message-ID: <20070623000721.7bf9ee81.bugs.michael@gmx.net> On Fri, 22 Jun 2007 23:54:58 +0200, Axel Thimm wrote: > On Fri, Jun 22, 2007 at 11:15:36PM +0200, Michael Schwendt wrote: > > Second run, trying to eliminate some harmless positives automatically... > > > > Trouble ahead: > > > > lam-libs provides libmpi.so.0 > > required by: ScientificPython - 2.6-8.fc7.i386 > > required by: R-RScaLAPACK - 0.5.1-9.fc7.i386 > > required by: blacs - 1.1-24.fc7.1.i386 > > required by: lam - 2:7.1.2-10.fc7.i386 > > required by: lam-devel - 2:7.1.2-10.fc7.i386 > > required by: openmpi - 1.1-8.fc7.i386 > > required by: openmpi-devel - 1.1-8.fc7.i386 > > required by: openmpi-libs - 1.1-8.fc7.i386 > > required by: scalapack - 1.7.5-1.fc7.i386 > > required by: tachyon-lam - 0.97-4.fc7.i386 > > required by: tachyon-lam-gl - 0.97-4.fc7.i386 > > openmpi-libs provides libmpi.so.0 > > required by: ScientificPython - 2.6-8.fc7.i386 > > required by: R-RScaLAPACK - 0.5.1-9.fc7.i386 > > required by: blacs - 1.1-24.fc7.1.i386 > > required by: lam - 2:7.1.2-10.fc7.i386 > > required by: lam-devel - 2:7.1.2-10.fc7.i386 > > required by: lam-libs - 2:7.1.2-10.fc7.i386 > > required by: openmpi - 1.1-8.fc7.i386 > > required by: openmpi-devel - 1.1-8.fc7.i386 > > required by: scalapack - 1.7.5-1.fc7.i386 > > required by: tachyon-lam - 0.97-4.fc7.i386 > > required by: tachyon-lam-gl - 0.97-4.fc7.i386 > > > > Both packages store libmpi.so.0 in a private path, /usr/lib/lam/ and > > /usr/lib/openmpi/ respectively. Still there are other packages which > > require libmpi.so.0 => there are bad dependencies here. > > Can you explain what are bad dependencies here? No, because both packages install ld.so conf via %post scriptlets and the alternatives system. That is not something a first version of a checker-script would detect. ;) From pertusus at free.fr Fri Jun 22 22:36:18 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 23 Jun 2007 00:36:18 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <200706221116.38840.jkeating@redhat.com> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <200706221116.38840.jkeating@redhat.com> Message-ID: <20070622223618.GA3138@free.fr> On Fri, Jun 22, 2007 at 11:16:38AM -0400, Jesse Keating wrote: > On Friday 22 June 2007 11:09:39 Adam Jackson wrote: > > How should I filter these, short of AutoReqProv: 0 ? > > One "way" would be to not mark these libraries as executable. IIRC rpm > autoprov/req scripts will only consider libraries that are marked as > executable. Of course, that may kill /both/ provides and requires, and you > may want those requires to happen... Debuginfo will no be generated if the object is not executable. Maybe this could be changed, though. -- Pat From pertusus at free.fr Fri Jun 22 22:47:10 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 23 Jun 2007 00:47:10 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: References: <20070622170209.b5442bc3.bugs.michael@gmx.net> Message-ID: <20070622224710.GB3138@free.fr> On Fri, Jun 22, 2007 at 10:32:28AM -0500, Jason L Tibbitts III wrote: > >>>>> "MS" == Michael Schwendt writes: > > MS> Broken dependencies are one thing, broken "Provides" another. The > MS> distribution includes an increasing number of packages, which > MS> don't filter their SONAME Provides when they include shared > MS> libraries in private paths. > > I recall past discussions about whether these were problematic but I > never recall seeing any mandate that they be filtered. > > Frankly, these are so incredibly common that I really think it's > completely counterproductive to require packagers to go out of their > way to fix broken dependency generation. Why not fix the dependency > generator instead? > > All it needs to do to fix up most of the issues is not look outside > the standard library paths. For those rather few packages which add > to the regular ldconfig search path, they can either add dependencies > manually or can be provided with some way to add directories that the > dependency generator will search. It could even look for files > contained in the package which will be placed in /etc/ld.so.conf.d and > automatically generate dependencies for them. I filled a bug report related to that issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224544 -- Pat From jeremy at hinegardner.org Sat Jun 23 06:10:37 2007 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Sat, 23 Jun 2007 00:10:37 -0600 Subject: willing to take over darcs packaging Message-ID: <20070623061037.GW13095@hinegardner.org> Hi all, I see that darcs is listed in the "Potentially unmaintained packages" and I am willing to take over the packaging of darcs if that is still the case. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From Axel.Thimm at ATrpms.net Sat Jun 23 06:59:57 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 23 Jun 2007 08:59:57 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <200706221116.38840.jkeating@redhat.com> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <200706221116.38840.jkeating@redhat.com> Message-ID: <20070623065957.GB9160@puariko.nirvana> On Fri, Jun 22, 2007 at 11:16:38AM -0400, Jesse Keating wrote: > On Friday 22 June 2007 11:09:39 Adam Jackson wrote: > > How should I filter these, short of AutoReqProv: 0 ? > > One "way" would be to not mark these libraries as executable. IIRC rpm > autoprov/req scripts will only consider libraries that are marked as > executable. Are you sure this works for the *internal* filtering? -- 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 Sat Jun 23 07:05:00 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 23 Jun 2007 09:05:00 +0200 Subject: Caution! Bad SONAME Provides In-Reply-To: <20070623065957.GB9160@puariko.nirvana> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> <1182524979.30663.246.camel@localhost.localdomain> <200706221116.38840.jkeating@redhat.com> <20070623065957.GB9160@puariko.nirvana> Message-ID: <20070623070500.GC9160@puariko.nirvana> On Sat, Jun 23, 2007 at 08:59:57AM +0200, Axel Thimm wrote: > On Fri, Jun 22, 2007 at 11:16:38AM -0400, Jesse Keating wrote: > > On Friday 22 June 2007 11:09:39 Adam Jackson wrote: > > > How should I filter these, short of AutoReqProv: 0 ? > > > > One "way" would be to not mark these libraries as executable. IIRC rpm > > autoprov/req scripts will only consider libraries that are marked as > > executable. > > Are you sure this works for the *internal* filtering? I thought that external chmod -x works, and internal not. Testing shows that external does not work either, and looking at the code, only scripts and exececutables are probed on executable permission bits. libs are always provided unless they are not even readable. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sat Jun 23 08:22:29 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 23 Jun 2007 10:22:29 +0200 Subject: libpq.so - Re: Caution! Bad SONAME Provides In-Reply-To: <20070622170209.b5442bc3.bugs.michael@gmx.net> References: <20070622170209.b5442bc3.bugs.michael@gmx.net> Message-ID: <20070623102229.0ccc4a5d.bugs.michael@gmx.net> From all non-versioned sonames which are provided by multiple packages, only "libpq.so" is required by other packages: gnokii-smsd-pgsql provides libpq.so postgresql-libs provides libpq.so required by: postgresql-python - 8.2.4-1.fc7.i386 required by: postgresql-server - 8.2.4-1.fc7.i386 required by: postgresql-tcl - 8.2.4-1.fc7.i386 required by: postgresql-python - 8.2.4-1.fc7.i386 required by: postgresql-server - 8.2.4-1.fc7.i386 required by: postgresql-tcl - 8.2.4-1.fc7.i386 At first sight it looked suspicious that postgresql packages required libpq.so (why do they anyway?), but they also require libpq.so.5, so this case is harmless (the gnokii pkg name is longer, too, btw). From ville.skytta at iki.fi Sun Jun 24 10:24:14 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-2?q?Skytt=E4?=) Date: Sun, 24 Jun 2007 13:24:14 +0300 Subject: Update policy in F7 (Was: Re: Package EVR problems in Fedora 2007-06-22) In-Reply-To: <467C355A.40902@wp.pl> References: <20070622090032.0855C152134@buildsys.fedoraproject.org> <467C355A.40902@wp.pl> Message-ID: <200706241324.15196.ville.skytta@iki.fi> On Friday 22 June 2007, Marcin Zaj?czkowski wrote: > So, I have a few questions. > 1. Is there some wiki page with update policy in F7 (especially for > those former FE)? > 2. Who decides which packages will be pushed to "tests stage"? > 3. Should a packager suggest (somehow) if (s)he thinks that specified > package version should be worth pushing to the end user? There's at least http://fedoraproject.org/wiki/JeremyKatz/DraftHowToUpdateYourFedoraPackage From bugs.michael at gmx.net Sun Jun 24 11:29:53 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 24 Jun 2007 13:29:53 +0200 Subject: Update policy in F7 (Was: Re: Package EVR problems in Fedora 2007-06-22) In-Reply-To: <467C355A.40902@wp.pl> References: <20070622090032.0855C152134@buildsys.fedoraproject.org> <467C355A.40902@wp.pl> Message-ID: <20070624132953.5b46fb92.bugs.michael@gmx.net> On Fri, 22 Jun 2007 22:47:22 +0200, Marcin Zaj?czkowski wrote: > Hi, > > > Today I received following email: > > > isomaster > > FE5 > F7 (0:1.0-1.fc5 > 0:0.8.1-1.fc7) > > FE6 > F7 (0:1.0-1.fc6 > 0:0.8.1-1.fc7) > > I'm not surprised, because in in FC5, FC6 and devel there are updated > versions. Package for F7 is tagged as "dist-fc7-updates-candidate". > > I saw a thread about update policy in F7 some time ago (that users are > overwhelmed by tons of actualizations and not every updated package > should be pushes to F7 main repository as well as need to have better > info about "what's new"), but I don't remember conclusion about that. > > So, I have a few questions. > 1. Is there some wiki page with update policy in F7 (especially for > those former FE)? > 2. Who decides which packages will be pushed to "tests stage"? > 3. Should a packager suggest (somehow) if (s)he thinks that specified > package version should be worth pushing to the end user? With regard to point "3" and the FE6/FE5 release process, you would simply publish your updates for F7 first, and when released build them for FE6/FE5. From mszpak at wp.pl Sun Jun 24 11:46:49 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Sun, 24 Jun 2007 13:46:49 +0200 Subject: Update policy in F7 (Was: Re: Package EVR problems in Fedora 2007-06-22) In-Reply-To: <200706241324.15196.ville.skytta@iki.fi> References: <20070622090032.0855C152134@buildsys.fedoraproject.org> <467C355A.40902@wp.pl> <200706241324.15196.ville.skytta@iki.fi> Message-ID: <467E59A9.3090708@wp.pl> On 2007-06-24 12:24:14 +0200, Ville Skytt? wrote: > On Friday 22 June 2007, Marcin Zaj?czkowski wrote: > >> So, I have a few questions. >> 1. Is there some wiki page with update policy in F7 (especially for >> those former FE)? >> 2. Who decides which packages will be pushed to "tests stage"? >> 3. Should a packager suggest (somehow) if (s)he thinks that specified >> package version should be worth pushing to the end user? > > There's at least > http://fedoraproject.org/wiki/JeremyKatz/DraftHowToUpdateYourFedoraPackage Thanks. I didn't see any link to that page in PackageMaintainers section [1]. I think it should be added (despite of it is a draft). [1] - http://fedoraproject.org/wiki/PackageMaintainers Are there any suggestions how should "notes section" look like? Points, full sentences? In available updates I saw different conventions. There could be info what were fixed bugs (from bugzilla) all about, but what if it's an update to the next version (with bug fixes, improvements and e.g. new translations). Should I copy a changelog provided by an author or only select a few key issues? Regards Marcin From katzj at redhat.com Sun Jun 24 11:45:28 2007 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 24 Jun 2007 07:45:28 -0400 Subject: Update policy in F7 (Was: Re: Package EVR problems in Fedora 2007-06-22) In-Reply-To: <200706241324.15196.ville.skytta@iki.fi> References: <20070622090032.0855C152134@buildsys.fedoraproject.org> <467C355A.40902@wp.pl> <200706241324.15196.ville.skytta@iki.fi> Message-ID: <1182685528.2720.24.camel@aglarond.local> On Sun, 2007-06-24 at 13:24 +0300, Ville Skytt? wrote: > On Friday 22 June 2007, Marcin Zaj?czkowski wrote: > > So, I have a few questions. > > 1. Is there some wiki page with update policy in F7 (especially for > > those former FE)? > > 2. Who decides which packages will be pushed to "tests stage"? > > 3. Should a packager suggest (somehow) if (s)he thinks that specified > > package version should be worth pushing to the end user? > > There's at least > http://fedoraproject.org/wiki/JeremyKatz/DraftHowToUpdateYourFedoraPackage Yep -- should hopefully be getting finalized, edited up, etc this week too. Jeremy From petersen at redhat.com Mon Jun 25 01:24:02 2007 From: petersen at redhat.com (Jens Petersen) Date: Mon, 25 Jun 2007 11:24:02 +1000 Subject: willing to take over darcs packaging In-Reply-To: <20070623061037.GW13095@hinegardner.org> References: <20070623061037.GW13095@hinegardner.org> Message-ID: <467F1932.5070906@redhat.com> Hi Jeremy, Jeremy Hinegardner writes: > I see that darcs is listed in the "Potentially unmaintained packages" > and I am willing to take over the packaging of darcs if that is still > the case. Yes, thanks, that sounds good. :) Shall we transition it gradually? I have added you as comaintainer now and please feel free to update darcs/devel to 1.0.9. We should backport it to F-7 too. (No, I hadn't noticed the final release yet...) Jens From buc at odusz.so-cdu.ru Mon Jun 25 12:24:51 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 25 Jun 2007 16:24:51 +0400 Subject: Missing PAGE_MASK macro on PPC arches Message-ID: <467FB413.1070605@odu.neva.ru> The macro "PAGE_MASK" is normally defined in the "asm/page.h" header, provided by the "kernel-headers" package. This header is auto-generated from the correspond "include/asm-powerpc/page.h", with removing of all "__KERNEL__" ifdefs. Unlike in x86, the "PAGE_MASK" definition in "include/asm-powerpc/page.h" is kernel-private (i.e. sits under the "__KERNEL__" ifdef), hence after the stripping we have an empty "asm/page.h" for ppc and ppc64 arches. Because of this some programs are not compiled properly. Is it an upstream kernel bug or something else? Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From jwboyer at jdub.homelinux.org Mon Jun 25 12:45:16 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 25 Jun 2007 07:45:16 -0500 Subject: Missing PAGE_MASK macro on PPC arches In-Reply-To: <467FB413.1070605@odu.neva.ru> References: <467FB413.1070605@odu.neva.ru> Message-ID: <1182775516.23775.2.camel@weaponx.rchland.ibm.com> On Mon, 2007-06-25 at 16:24 +0400, Dmitry Butskoy wrote: > The macro "PAGE_MASK" is normally defined in the "asm/page.h" header, > provided by the "kernel-headers" package. This header is auto-generated > from the correspond "include/asm-powerpc/page.h", with removing of all > "__KERNEL__" ifdefs. > > Unlike in x86, the "PAGE_MASK" definition in > "include/asm-powerpc/page.h" is kernel-private (i.e. sits under the > "__KERNEL__" ifdef), hence after the stripping we have an empty > "asm/page.h" for ppc and ppc64 arches. > > Because of this some programs are not compiled properly. Which programs? Why do they care about the page size? > Is it an upstream kernel bug or something else? It's likely not a bug. PowerPC can have 4KiB or 64KiB pages, and PAGE_MASK is dependent upon the kernel config option being set one way or another since it's derived from PAGE_SHIFT. josh From Axel.Thimm at ATrpms.net Mon Jun 25 12:46:50 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 25 Jun 2007 14:46:50 +0200 Subject: Missing PAGE_MASK macro on PPC arches In-Reply-To: <467FB413.1070605@odu.neva.ru> References: <467FB413.1070605@odu.neva.ru> Message-ID: <20070625124650.GE3011@puariko.nirvana> On Mon, Jun 25, 2007 at 04:24:51PM +0400, Dmitry Butskoy wrote: > The macro "PAGE_MASK" is normally defined in the "asm/page.h" header, > provided by the "kernel-headers" package. This header is auto-generated > from the correspond "include/asm-powerpc/page.h", with removing of all > "__KERNEL__" ifdefs. > > Unlike in x86, the "PAGE_MASK" definition in > "include/asm-powerpc/page.h" is kernel-private (i.e. sits under the > "__KERNEL__" ifdef), hence after the stripping we have an empty > "asm/page.h" for ppc and ppc64 arches. > > Because of this some programs are not compiled properly. > > Is it an upstream kernel bug or something else? It also happens on RHEL5/x86_64: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229559 -- 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 buc at odusz.so-cdu.ru Mon Jun 25 13:06:17 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 25 Jun 2007 17:06:17 +0400 Subject: Missing PAGE_MASK macro on PPC arches In-Reply-To: <1182775516.23775.2.camel@weaponx.rchland.ibm.com> References: <467FB413.1070605@odu.neva.ru> <1182775516.23775.2.camel@weaponx.rchland.ibm.com> Message-ID: <467FBDC9.5090303@odu.neva.ru> Josh Boyer wrote: > On Mon, 2007-06-25 at 16:24 +0400, Dmitry Butskoy wrote: > >> The macro "PAGE_MASK" is normally defined in the "asm/page.h" header, >> provided by the "kernel-headers" package. This header is auto-generated >> from the correspond "include/asm-powerpc/page.h", with removing of all >> "__KERNEL__" ifdefs. >> >> Unlike in x86, the "PAGE_MASK" definition in >> "include/asm-powerpc/page.h" is kernel-private (i.e. sits under the >> "__KERNEL__" ifdef), hence after the stripping we have an empty >> "asm/page.h" for ppc and ppc64 arches. >> >> Because of this some programs are not compiled properly. >> > > Which programs? Why do they care about the page size? > fbtv (Frame Buffer TV) from xawtv package. > It's likely not a bug. PowerPC can have 4KiB or 64KiB pages, and > PAGE_MASK is dependent upon the kernel config option being set one way > or another since it's derived from PAGE_SHIFT. > Yep, we just should use getpagesize() for now. Axel Thimm wrote: > It also happens on RHEL5/x86_64: > > It seems such programs should be patched to calculate masks from the getpagesize() returned value. ~buc From dwmw2 at infradead.org Mon Jun 25 14:01:45 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 25 Jun 2007 15:01:45 +0100 Subject: Missing PAGE_MASK macro on PPC arches In-Reply-To: <467FB413.1070605@odu.neva.ru> References: <467FB413.1070605@odu.neva.ru> Message-ID: <1182780105.12109.98.camel@pmac.infradead.org> On Mon, 2007-06-25 at 16:24 +0400, Dmitry Butskoy wrote: > The macro "PAGE_MASK" is normally defined in the "asm/page.h" header, > provided by the "kernel-headers" package. This header is auto-generated > from the correspond "include/asm-powerpc/page.h", with removing of all > "__KERNEL__" ifdefs. > > Unlike in x86, the "PAGE_MASK" definition in > "include/asm-powerpc/page.h" is kernel-private (i.e. sits under the > "__KERNEL__" ifdef), hence after the stripping we have an empty > "asm/page.h" for ppc and ppc64 arches. > Because of this some programs are not compiled properly. Anything relying on PAGE_SIZE or PAGE_MASK in is broken. Userspace should be using getpagesize() instead. > Is it an upstream kernel bug or something else? It could be considered a kernel bug that we do actually expose our private parts on i386. We should probably fix that. -- dwmw2 From cbalint at redhat.com Mon Jun 25 14:03:12 2007 From: cbalint at redhat.com (Balint Cristian) Date: Mon, 25 Jun 2007 16:03:12 +0200 Subject: Missing PAGE_MASK macro on PPC arches In-Reply-To: <467FBDC9.5090303@odu.neva.ru> References: <467FB413.1070605@odu.neva.ru> <1182775516.23775.2.camel@weaponx.rchland.ibm.com> <467FBDC9.5090303@odu.neva.ru> Message-ID: <200706251603.12448.cbalint@redhat.com> > fbtv (Frame Buffer TV) from xawtv package. > > It's likely not a bug. PowerPC can have 4KiB or 64KiB pages, and > > PAGE_MASK is dependent upon the kernel config option being set one way > > or another since it's derived from PAGE_SHIFT. > > > > Yep, we just should use getpagesize() for now. I agree. But what about binutils than ? ../../bfd/trad-core.c:117: error: 'PAGE_SIZE' undeclared (first use in this function) ^^^ this seems that binutils rely on all arches on page.h exported PAGE_SIZE ? I have same problem on alpha, only one arch (till now) wich page.h doesnt export PAGE_SIZE, so i used to move PAGE_SIZE out of kernel pragma space like: cat ../SOURCES/linux-2.6.21-alpha_pagesize.patch --- linux/include/asm-alpha/page.h.orig 2007-06-25 00:19:41.000000000 +0200 +++ linux/include/asm-alpha/page.h 2007-06-25 00:21:46.000000000 +0200 @@ -1,15 +1,15 @@ #ifndef _ALPHA_PAGE_H #define _ALPHA_PAGE_H -#ifdef __KERNEL__ - -#include - /* PAGE_SHIFT determines the page size */ #define PAGE_SHIFT 13 #define PAGE_SIZE (1UL << PAGE_SHIFT) #define PAGE_MASK (~(PAGE_SIZE-1)) +#ifdef __KERNEL__ + +#include + #ifndef __ASSEMBLY__ #define STRICT_MM_TYPECHECKS /chris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cbalint at redhat.com Mon Jun 25 14:10:21 2007 From: cbalint at redhat.com (Balint Cristian) Date: Mon, 25 Jun 2007 16:10:21 +0200 Subject: Missing PAGE_MASK macro on PPC arches In-Reply-To: <200706251603.12448.cbalint@redhat.com> References: <467FB413.1070605@odu.neva.ru> <467FBDC9.5090303@odu.neva.ru> <200706251603.12448.cbalint@redhat.com> Message-ID: <200706251610.21327.cbalint@redhat.com> > > Yep, we just should use getpagesize() for now. > > > I agree. But what about binutils than ? second concern: Oh yes, and what if binutils is used in cross-compiler ? Than getpagesize() what will return ? host one instead of target one ? > ../../bfd/trad-core.c:117: error: 'PAGE_SIZE' undeclared (first use in this function) > ^^^ > this seems that binutils rely on all arches on page.h exported PAGE_SIZE ? > > I have same problem on alpha, only one arch (till now) wich page.h doesnt export > PAGE_SIZE, so i used to move PAGE_SIZE out of kernel pragma space like: > > > cat ../SOURCES/linux-2.6.21-alpha_pagesize.patch > --- linux/include/asm-alpha/page.h.orig 2007-06-25 00:19:41.000000000 +0200 > +++ linux/include/asm-alpha/page.h 2007-06-25 00:21:46.000000000 +0200 > @@ -1,15 +1,15 @@ > #ifndef _ALPHA_PAGE_H > #define _ALPHA_PAGE_H > > -#ifdef __KERNEL__ > - > -#include > - > /* PAGE_SHIFT determines the page size */ > #define PAGE_SHIFT 13 > #define PAGE_SIZE (1UL << PAGE_SHIFT) > #define PAGE_MASK (~(PAGE_SIZE-1)) > > +#ifdef __KERNEL__ > + > +#include > + > #ifndef __ASSEMBLY__ > > #define STRICT_MM_TYPECHECKS > > > /chris > -- Balint Cristian (Red Hat Release Engineering Team) -------------- 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 Jun 25 14:17:26 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 25 Jun 2007 09:17:26 -0500 Subject: Missing PAGE_MASK macro on PPC arches In-Reply-To: <1182780105.12109.98.camel@pmac.infradead.org> References: <467FB413.1070605@odu.neva.ru> <1182780105.12109.98.camel@pmac.infradead.org> Message-ID: <1182781046.23775.35.camel@weaponx.rchland.ibm.com> On Mon, 2007-06-25 at 15:01 +0100, David Woodhouse wrote: > On Mon, 2007-06-25 at 16:24 +0400, Dmitry Butskoy wrote: > > The macro "PAGE_MASK" is normally defined in the "asm/page.h" header, > > provided by the "kernel-headers" package. This header is auto-generated > > from the correspond "include/asm-powerpc/page.h", with removing of all > > "__KERNEL__" ifdefs. > > > > Unlike in x86, the "PAGE_MASK" definition in > > "include/asm-powerpc/page.h" is kernel-private (i.e. sits under the > > "__KERNEL__" ifdef), hence after the stripping we have an empty > > "asm/page.h" for ppc and ppc64 arches. > > > Because of this some programs are not compiled properly. > > Anything relying on PAGE_SIZE or PAGE_MASK in is broken. > Userspace should be using getpagesize() instead. Or if you want to be all POSIX-y, sysconf(_SC_PAGESIZE). I think getpagesize is deprecated. josh From dwmw2 at infradead.org Mon Jun 25 14:21:23 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 25 Jun 2007 15:21:23 +0100 Subject: Missing PAGE_MASK macro on PPC arches In-Reply-To: <200706251603.12448.cbalint@redhat.com> References: <467FB413.1070605@odu.neva.ru> <1182775516.23775.2.camel@weaponx.rchland.ibm.com> <467FBDC9.5090303@odu.neva.ru> <200706251603.12448.cbalint@redhat.com> Message-ID: <1182781283.12109.109.camel@pmac.infradead.org> On Mon, 2007-06-25 at 16:03 +0200, Balint Cristian wrote: > > Yep, we just should use getpagesize() for now. > I agree. But what about binutils than ? > ../../bfd/trad-core.c:117: error: 'PAGE_SIZE' undeclared (first use in this function) > ^^^ Fedora's binutils seems to work fine. And I don't even see any patches correcting the error you quote. > I have same problem on alpha, only one arch (till now) wich page.h doesnt export > PAGE_SIZE, so i used to move PAGE_SIZE out of kernel pragma space like: That is the wrong approach. If there are programs which still rely on PAGE_SIZE, then _fix_ them. At some point I plan to remove page.h _completely_ from the upstream kernel's exports, like I did atomic.h. -- dwmw2 From cbalint at redhat.com Mon Jun 25 14:27:34 2007 From: cbalint at redhat.com (Balint Cristian) Date: Mon, 25 Jun 2007 16:27:34 +0200 Subject: Missing PAGE_MASK macro on PPC arches In-Reply-To: <1182781283.12109.109.camel@pmac.infradead.org> References: <467FB413.1070605@odu.neva.ru> <200706251603.12448.cbalint@redhat.com> <1182781283.12109.109.camel@pmac.infradead.org> Message-ID: <200706251627.35029.cbalint@redhat.com> > > I agree. But what about binutils than ? > > ../../bfd/trad-core.c:117: error: 'PAGE_SIZE' undeclared (first use in this function) > > ^^^ > > Fedora's binutils seems to work fine. And I don't even see any patches > correcting the error you quote. It was log from fedora binutils. However i need than track down from where this PAGE_SIZE is requested than, looks like through some oddity of non binutils headers. /chris -------------- 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 Jun 25 15:28:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 11:28:35 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting Message-ID: <200706251128.35333.jkeating@redhat.com> Below you will find a list of topics that we'd like to go over in the next RelEng meeting that is scheduled for Today, Monday at 1700 UTC in #fedora-meeting on irc.freenode.org: /topic RELENG-Meeting - Fedora 5 shutdown - JesseKeating /topic RELENG-Meeting - Automatic promotion of updates - JesseKeating /topic RELENG-Meeting - Open Discussion 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 "Open Discussion" phase. If your name/nick is on above list please update the status on the ReleaseEngineering/Meetings/Agenda page in the wiki ahead of the meeting. That way all the other RelEng members and interested contributors know whats 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... -- 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 Jochen at herr-schmitt.de Mon Jun 25 15:44:07 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 25 Jun 2007 17:44:07 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <200706251128.35333.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> Message-ID: <467FE2C7.8020501@herr-schmitt.de> Jesse Keating schrieb: > /topic RELENG-Meeting - Automatic promotion of updates - JesseKeatin > I'm again autopromotion, because is contains the danger, that unstable package will going in the update stage. Instead it may be helpful, if you may send a nag mail, if an update will stay too long in the update_testing stage. From my point of view two other topic may be important: 1.) Handling of update chains in koji and bodhi. I have several updates, where one package which I have updated is depend on an other package which was submitted by another maintainer into the update-testing The current state is, that you have to contact rel-eng for assistents in this cases. 2.) There was request for a seperate security_updates repository for F-7. Best Regards: Jochen Schmitt From jkeating at redhat.com Mon Jun 25 16:52:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 12:52:02 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <467FE2C7.8020501@herr-schmitt.de> References: <200706251128.35333.jkeating@redhat.com> <467FE2C7.8020501@herr-schmitt.de> Message-ID: <200706251252.02499.jkeating@redhat.com> On Monday 25 June 2007 11:44:07 Jochen Schmitt wrote: > I'm again autopromotion, because is contains the danger, that unstable > package will going > in the update stage. Instead it may be helpful, if you may send a nag > mail, if an update will > stay too long in the update_testing stage. Right now just the idea is approved. Along with that idea would come reasonable mechanics to make it work, such as any user being able to block autopromotion if they find a problem with the package. It's up to releng and QA to come up with reasonable mechanics and boundaries to autopromotion. > ?From my point of view two other topic may be important: > > 1.) Handling of update chains in koji and bodhi. I have several updates, > where one package > which I have updated is depend on an other package which was submitted > by another > maintainer into the update-testing ?The current state is, that you have > to contact rel-eng for > assistents in this cases. We've already discussed this. We want buildroots to autoupdate in principle, however we require some sanity checking in bodhi to not allow updates to go out that were built with packages that aren't tagged to go out or out already. > > 2.) There was request for a seperate security_updates repository for F-7. This can be accomplished by the yum-security plugin, once bodhi is capable of generating the extra update metadata. I'm sure Luke would love a hand in getting some of this accomplished. -- 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 Jochen at herr-schmitt.de Mon Jun 25 17:01:59 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 25 Jun 2007 19:01:59 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <200706251252.02499.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> <467FE2C7.8020501@herr-schmitt.de> <200706251252.02499.jkeating@redhat.com> Message-ID: <467FF507.90904@herr-schmitt.de> Jesse Keating schrieb: > Right now just the idea is approved. Along with that idea would come > reasonable mechanics to make it work, such as any user being able to block > autopromotion if they find a problem with the package. It's up to releng and > QA to come up with reasonable mechanics and boundaries to autopromotion. > > If you implement any mechanism to block an update, that is ok from my side. but I think is not good, if an update will promote to a higher stage without the explicit permission of the maintainer which is responsible for it. > We've already discussed this. We want buildroots to autoupdate in principle, > however we require some sanity checking in bodhi to not allow updates to go > out that were built with packages that aren't tagged to go out or out > already. > > I will agree with you, if package A will depends on B, A can be only on a stage lower or equal then package b. If you break this rule the user will running into the broken dependencies issue that is very annoying for users. Best Regards: Jochen Schmitt From jkeating at redhat.com Mon Jun 25 17:02:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 13:02:39 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <467FF507.90904@herr-schmitt.de> References: <200706251128.35333.jkeating@redhat.com> <200706251252.02499.jkeating@redhat.com> <467FF507.90904@herr-schmitt.de> Message-ID: <200706251302.40101.jkeating@redhat.com> On Monday 25 June 2007 13:01:59 Jochen Schmitt wrote: > If you implement any mechanism to block an update, that is ok from my > side. but I think > is not good, if an update will promote to a higher stage without the > explicit permission > of the maintainer which is responsible for it. I think the gameplan is that the maintainer would have to manually request the autotimeout at update submission time. It wouldn't be pre-set. But again, that's a detail to work out. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon Jun 25 17:10:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 25 Jun 2007 22:40:17 +0530 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <200706251128.35333.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> Message-ID: <467FF6F9.2030507@fedoraproject.org> Jesse Keating wrote: > Below you will find a list of topics that we'd like to go over in the next > RelEng meeting that is scheduled for Today, Monday at 1700 UTC in > #fedora-meeting on irc.freenode.org: > > /topic RELENG-Meeting - Fedora 5 shutdown - JesseKeating > > /topic RELENG-Meeting - Automatic promotion of updates - JesseKeating > > /topic RELENG-Meeting - Open Discussion > > 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 "Open > Discussion" phase. > > If your name/nick is on above list please update the status on the > ReleaseEngineering/Meetings/Agenda page in the wiki ahead of the meeting. That > way all the other RelEng members and interested contributors know whats 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... > Is Rel Eng evaluating Jidgo integration for Fedora 8 or is that part of infrastructure team? What about enabling presto in rawhide? Rahul From Jochen at herr-schmitt.de Mon Jun 25 17:14:57 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 25 Jun 2007 19:14:57 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <200706251302.40101.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> <200706251252.02499.jkeating@redhat.com> <467FF507.90904@herr-schmitt.de> <200706251302.40101.jkeating@redhat.com> Message-ID: <467FF811.3040406@herr-schmitt.de> Jesse Keating schrieb: > I think the gameplan is that the maintainer would have to manually request the > autotimeout at update submission time. It wouldn't be pre-set. But again, > that's a detail to work out. > Autotimeout means, that the maintainer main configure a time period after this the package may be submitted into updates if not blocks exist. At first, I think that is not a good Idea to make such a push automatically. The second issue may, that a maintainer make configure a very shout timeout period, so the testers or QA may have no chance to do there work and blocks broken updates. Best Regards: Jochen Schmitt From Axel.Thimm at ATrpms.net Mon Jun 25 17:15:22 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 25 Jun 2007 19:15:22 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <200706251252.02499.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> <467FE2C7.8020501@herr-schmitt.de> <200706251252.02499.jkeating@redhat.com> Message-ID: <20070625171522.GA11289@puariko.nirvana> On Mon, Jun 25, 2007 at 12:52:02PM -0400, Jesse Keating wrote: > > 2.) There was request for a seperate security_updates repository for F-7. > > This can be accomplished by the yum-security plugin, once bodhi is capable of > generating the extra update metadata. I'm sure Luke would love a hand in > getting some of this accomplished. If instead the repo is split you get it for free for smart and apt and any other depsolver as well w/o imposing to the devloper of the said tools to also write a plugin. Keep updates-released as is and just add another repo "security-updates" based on the bodhi metadata. "security-updates"'s contents should be hardlinked against updates-released. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jun 25 17:14:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 13:14:10 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <467FF6F9.2030507@fedoraproject.org> References: <200706251128.35333.jkeating@redhat.com> <467FF6F9.2030507@fedoraproject.org> Message-ID: <200706251314.10539.jkeating@redhat.com> On Monday 25 June 2007 13:10:17 Rahul Sundaram wrote: > Is Rel Eng evaluating Jidgo integration for Fedora 8 or is that part of > infrastructure team? A little of both. Now that rawhide may actually have signed packages instead of all unsigned, jigdo starts to make more sense. It's going to take some thought to get it integrated into the compose time tools, best to start with an RFE for perhaps pungi. > What about enabling presto in rawhide? Jeremy started some discussion about this on buildsys-list. It may require some changes to the buildsystem to reliably produce/store deltas and to get them during composes. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon Jun 25 17:17:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 25 Jun 2007 22:47:16 +0530 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <467FF811.3040406@herr-schmitt.de> References: <200706251128.35333.jkeating@redhat.com> <200706251252.02499.jkeating@redhat.com> <467FF507.90904@herr-schmitt.de> <200706251302.40101.jkeating@redhat.com> <467FF811.3040406@herr-schmitt.de> Message-ID: <467FF89C.5020908@fedoraproject.org> Jochen Schmitt wrote: > Jesse Keating schrieb: >> I think the gameplan is that the maintainer would have to manually >> request the autotimeout at update submission time. It wouldn't be >> pre-set. But again, that's a detail to work out. >> > Autotimeout means, that the maintainer main configure a time period > after this the package > may be submitted into updates if not blocks exist. > > At first, I think that is not a good Idea to make such a push > automatically. The second > issue may, that a maintainer make configure a very shout timeout period, > so the testers or QA > may have no chance to do there work and blocks broken updates. That's also the case when the maintainer decides to skip updates-testing completely which is possible in the current setup. Rahul From sundaram at fedoraproject.org Mon Jun 25 17:33:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 25 Jun 2007 23:03:20 +0530 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <200706251314.10539.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> <467FF6F9.2030507@fedoraproject.org> <200706251314.10539.jkeating@redhat.com> Message-ID: <467FFC60.7040504@fedoraproject.org> Jesse Keating wrote: > On Monday 25 June 2007 13:10:17 Rahul Sundaram wrote: >> Is Rel Eng evaluating Jidgo integration for Fedora 8 or is that part of >> infrastructure team? > > A little of both. Now that rawhide may actually have signed packages instead > of all unsigned, jigdo starts to make more sense. It's going to take some > thought to get it integrated into the compose time tools, best to start with > an RFE for perhaps pungi. Done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245601 >> What about enabling presto in rawhide? > > Jeremy started some discussion about this on buildsys-list. It may require > some changes to the buildsystem to reliably produce/store deltas and to get > them during composes. Came across http://fedoraproject.org/wiki/Releases/FeaturePresto. Looks good. Rahul From katzj at redhat.com Mon Jun 25 17:42:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 25 Jun 2007 13:42:45 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <20070625171522.GA11289@puariko.nirvana> References: <200706251128.35333.jkeating@redhat.com> <467FE2C7.8020501@herr-schmitt.de> <200706251252.02499.jkeating@redhat.com> <20070625171522.GA11289@puariko.nirvana> Message-ID: <1182793365.31081.53.camel@erebor.boston.redhat.com> On Mon, 2007-06-25 at 19:15 +0200, Axel Thimm wrote: > On Mon, Jun 25, 2007 at 12:52:02PM -0400, Jesse Keating wrote: > > > 2.) There was request for a seperate security_updates repository for F-7. > > > > This can be accomplished by the yum-security plugin, once bodhi is capable of > > generating the extra update metadata. I'm sure Luke would love a hand in > > getting some of this accomplished. > > If instead the repo is split you get it for free for smart and apt and > any other depsolver as well w/o imposing to the devloper of the said > tools to also write a plugin. > > Keep updates-released as is and just add another repo > "security-updates" based on the bodhi metadata. "security-updates"'s > contents should be hardlinked against updates-released. And what if a security update depends on a non-security update? Do we only build security updates against a buildroot containing only security updates? This gets complicated pretty quickly.... Jeremy From notting at redhat.com Mon Jun 25 19:18:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 25 Jun 2007 15:18:03 -0400 Subject: orphan/retire package: g-wrap Message-ID: <20070625191803.GB14914@nostromo.devel.redhat.com> What is g-wrap? --------------- g-wrap is a tool for generating guile wrappers for C functions. Why is it being orphaned/retired? --------------------------------- Number of packages in the history of Red Hat Linux/Fedora that have used and required g-wrap: 1 Number of packages, as of tomorrow, in the Fedora development tree that use or require g-wrap: 0 Seriously, if someone wants to maintain a library that nothing at all uses just for fun, go for it. (I'll still maintain it for legacy releases). But I'd suggest just removing it from devel and marking it dead. Bill From Axel.Thimm at ATrpms.net Mon Jun 25 22:40:54 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 00:40:54 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <1182793365.31081.53.camel@erebor.boston.redhat.com> References: <200706251128.35333.jkeating@redhat.com> <467FE2C7.8020501@herr-schmitt.de> <200706251252.02499.jkeating@redhat.com> <20070625171522.GA11289@puariko.nirvana> <1182793365.31081.53.camel@erebor.boston.redhat.com> Message-ID: <20070625224054.GD17277@puariko.nirvana> On Mon, Jun 25, 2007 at 01:42:45PM -0400, Jeremy Katz wrote: > On Mon, 2007-06-25 at 19:15 +0200, Axel Thimm wrote: > > On Mon, Jun 25, 2007 at 12:52:02PM -0400, Jesse Keating wrote: > > > > 2.) There was request for a seperate security_updates repository for F-7. > > > > > > This can be accomplished by the yum-security plugin, once bodhi is capable of > > > generating the extra update metadata. I'm sure Luke would love a hand in > > > getting some of this accomplished. > > > > If instead the repo is split you get it for free for smart and apt and > > any other depsolver as well w/o imposing to the devloper of the said > > tools to also write a plugin. > > > > Keep updates-released as is and just add another repo > > "security-updates" based on the bodhi metadata. "security-updates"'s > > contents should be hardlinked against updates-released. > > And what if a security update depends on a non-security update? Do we > only build security updates against a buildroot containing only security > updates? > > This gets complicated pretty quickly.... Actually you have a very good point there. If there will be a concept offering only security updates, then the security updates *must* be built on release + security-updates only, and koji needs to know in *advance* that this is a security build, and not only at bodhi time. The reason is that if you build a security update against F7 & updates-released in 12 months and this requires a library that has been updated since F7's release (but not due to security), you will end up with a broken security update on a system following only security updates. So you're left with the following options: o forget about a security updates only mechanism, whether this is a yum-plugin or a separate repo o Elevate all dependencies of a security update to become part of the virtual or real security-update repo o Build security updates only against F7 & security updates, not all the updates (and only elevate non-security updates to security status to fulfill otherwise missing dependencies. At first the yum-plugin sounds like the easy way out, but it will generate more issues than it will solve especially the more F7 will be aging. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 26 00:09:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 20:09:44 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <20070625224054.GD17277@puariko.nirvana> References: <200706251128.35333.jkeating@redhat.com> <1182793365.31081.53.camel@erebor.boston.redhat.com> <20070625224054.GD17277@puariko.nirvana> Message-ID: <200706252009.49142.jkeating@redhat.com> On Monday 25 June 2007 18:40:54 Axel Thimm wrote: > The reason is that if you build a security update against F7 & > updates-released in 12 months and this requires a library that has > been updated since F7's release (but not due to security), you will > end up with a broken security update on a system following only > security updates. So you're left with the following options: > > o forget about a security updates only mechanism, whether this is a > ? yum-plugin or a separate repo > o Elevate all dependencies of a security update to become part of the > ? virtual or real security-update repo > o Build security updates only against F7 & security updates, not all > ? the updates (and only elevate non-security updates to security > ? status to fulfill otherwise missing dependencies. > > At first the yum-plugin sounds like the easy way out, but it will > generate more issues than it will solve especially the more F7 will be > aging. Or simply design the yum-plugin to consider security updates only for upgrades, then depsolve from there. It would be akin to just running 'yum update '. It wouldn't look at your entire package set for potential updates, just what you give it, and what it needs to depsolve from there. In fact, I think that's the way the current plugin works. -- 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 Jun 26 00:31:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 02:31:51 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <200706252009.49142.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> <1182793365.31081.53.camel@erebor.boston.redhat.com> <20070625224054.GD17277@puariko.nirvana> <200706252009.49142.jkeating@redhat.com> Message-ID: <20070626003151.GC27093@puariko.nirvana> On Mon, Jun 25, 2007 at 08:09:44PM -0400, Jesse Keating wrote: > On Monday 25 June 2007 18:40:54 Axel Thimm wrote: > > The reason is that if you build a security update against F7 & > > updates-released in 12 months and this requires a library that has > > been updated since F7's release (but not due to security), you will > > end up with a broken security update on a system following only > > security updates. So you're left with the following options: > > > > o forget about a security updates only mechanism, whether this is a > > ? yum-plugin or a separate repo > > o Elevate all dependencies of a security update to become part of the > > ? virtual or real security-update repo > > o Build security updates only against F7 & security updates, not all > > ? the updates (and only elevate non-security updates to security > > ? status to fulfill otherwise missing dependencies. > > > > At first the yum-plugin sounds like the easy way out, but it will > > generate more issues than it will solve especially the more F7 will be > > aging. > > Or simply design the yum-plugin to consider security updates only for > upgrades, then depsolve from there. It would be akin to just running 'yum > update '. It wouldn't look at your entire package set for > potential updates, just what you give it, and what it needs to depsolve from > there. In fact, I think that's the way the current plugin works. If for example glibc has been updated yum update foo will not pull it in. Try it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 26 00:36:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 20:36:00 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <20070626003151.GC27093@puariko.nirvana> References: <200706251128.35333.jkeating@redhat.com> <200706252009.49142.jkeating@redhat.com> <20070626003151.GC27093@puariko.nirvana> Message-ID: <200706252036.00551.jkeating@redhat.com> On Monday 25 June 2007 20:31:51 Axel Thimm wrote: > If for example glibc has been updated yum update foo will not pull it > in. Try it. If it has been updated and the new update of foo will not run without the newer glibc and there are no rpm requirements on said newer glibc libraries, we've got much bigger issues. -- 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 Jun 26 01:00:45 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 03:00:45 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <200706252036.00551.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> <200706252009.49142.jkeating@redhat.com> <20070626003151.GC27093@puariko.nirvana> <200706252036.00551.jkeating@redhat.com> Message-ID: <20070626010045.GF27093@puariko.nirvana> On Mon, Jun 25, 2007 at 08:36:00PM -0400, Jesse Keating wrote: > On Monday 25 June 2007 20:31:51 Axel Thimm wrote: > > If for example glibc has been updated yum update foo will not pull it > > in. Try it. > > If it has been updated and the new update of foo will not run > without the newer glibc and there are no rpm requirements on said > newer glibc libraries, we've got much bigger issues. True, but that's everyday's packaging business and is called "lack of forward compatibiliy in libraries". Actually that was the reason for having to build against only securty updates onstead of the whole update repo given in the trimmed away quote of mine. Now to get to real example: Replace glibc with glib/gtk and friends, that keep the same soname since Moses' birth and add symbols on the row. You can build something on F7's glib and from a packaging POV it will still fit into FC5 or FC4, but when the app runs it will break with missing g* calls. Unfortunately someone set up the myth ages ago that adding new symbols to a library is not reason enough to change to soname, since backwards compatibility is retained. But the problem here is forward compatibility which is broken, and almost every library follows this scheme, there is none to very few that are forward-compatible. So broken forward compatibility in libraries is "normal" and an application built on the same soname in the future and being brought back to the past will be missing symbols. And that's exactly the security-updates model with building security updates against the whole released-updates use case. So you are really only left with the three alternatives I wrote in a previous mail in this thread. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 26 01:05:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 21:05:11 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <20070626010045.GF27093@puariko.nirvana> References: <200706251128.35333.jkeating@redhat.com> <200706252036.00551.jkeating@redhat.com> <20070626010045.GF27093@puariko.nirvana> Message-ID: <200706252105.11607.jkeating@redhat.com> On Monday 25 June 2007 21:00:45 Axel Thimm wrote: > So you are really only left with the three alternatives I wrote in a > previous mail in this thread. If that's truly the case, then we should do away with the idea of security only updates. -- 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 Jun 26 01:15:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 03:15:49 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <200706252105.11607.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> <200706252036.00551.jkeating@redhat.com> <20070626010045.GF27093@puariko.nirvana> <200706252105.11607.jkeating@redhat.com> Message-ID: <20070626011549.GG27093@puariko.nirvana> On Mon, Jun 25, 2007 at 09:05:11PM -0400, Jesse Keating wrote: > On Monday 25 June 2007 21:00:45 Axel Thimm wrote: > > So you are really only left with the three alternatives I wrote in a > > previous mail in this thread. > > If that's truly the case, then we should do away with the idea of security > only updates. That was one of the three options ;) I think a security-updates would not be bad, but maybe not in this cycle, there's lot to do in short time and having a Fedora enterprise-like stable branch with security updates isn't Fedora's typical usage scenario. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jun 26 01:20:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 21:20:16 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <20070626011549.GG27093@puariko.nirvana> References: <200706251128.35333.jkeating@redhat.com> <200706252105.11607.jkeating@redhat.com> <20070626011549.GG27093@puariko.nirvana> Message-ID: <200706252120.16645.jkeating@redhat.com> On Monday 25 June 2007 21:15:49 Axel Thimm wrote: > That was one of the three options ;) > > I think a security-updates would not be bad, but maybe not in this > cycle, there's lot to do in short time and having a Fedora > enterprise-like stable branch with security updates isn't Fedora's > typical usage scenario. It's a tough thing to provide, and it would require anybody building a security update to build in two collections, potentially having multiple branches per release, one for "head" and one for "security", etc.. I think it's totally outside the scope of the Fedora project. -- 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 Jun 26 01:49:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 03:49:48 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <200706252120.16645.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> <200706252105.11607.jkeating@redhat.com> <20070626011549.GG27093@puariko.nirvana> <200706252120.16645.jkeating@redhat.com> Message-ID: <20070626014948.GI27093@puariko.nirvana> On Mon, Jun 25, 2007 at 09:20:16PM -0400, Jesse Keating wrote: > On Monday 25 June 2007 21:15:49 Axel Thimm wrote: > > That was one of the three options ;) > > > > I think a security-updates would not be bad, but maybe not in this > > cycle, there's lot to do in short time and having a Fedora > > enterprise-like stable branch with security updates isn't Fedora's > > typical usage scenario. > > It's a tough thing to provide, and it would require anybody building a > security update to build in two collections, potentially having multiple > branches per release, one for "head" and one for "security", etc.. I think > it's totally outside the scope of the Fedora project. I don't think it would require to build twice or open up several branches, though, once against release & other security updates would be enough. This assumes of course that FX at the end of its life is still (mostly) *backwards* (!) compatible to FX at release time. Fedora's pace and release cycle are balanced to not allow this to happen. For example for F7 we even dropped mass-rebuilds, because we assumed that not only FC6+updates is compatible to FC6 w/o, but even to F7. While dropping mass-rebuilds was a mistake, this at least demonstrates that the Fedora model is not supposed to become backwards incompatble with itself within a release. So the implementaion would be just another tag in koji. The maintainer would have to fire a `make build-security' to have koji shove the build into the proper tag which would inherit only release and not updates. updates-candiates etc. would inherit from security. In fact it looks like koji's model has already been planned to allow for this :) Still let's make it an F9 feature to properly investigate in a 6 month cycle, and even on F9 I wouldn't make it a high-priority item. -- 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 katzj at redhat.com Tue Jun 26 02:36:25 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 25 Jun 2007 22:36:25 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <20070626014948.GI27093@puariko.nirvana> References: <200706251128.35333.jkeating@redhat.com> <200706252105.11607.jkeating@redhat.com> <20070626011549.GG27093@puariko.nirvana> <200706252120.16645.jkeating@redhat.com> <20070626014948.GI27093@puariko.nirvana> Message-ID: <1182825385.4014.1.camel@aglarond.local> On Tue, 2007-06-26 at 03:49 +0200, Axel Thimm wrote: > On Mon, Jun 25, 2007 at 09:20:16PM -0400, Jesse Keating wrote: > > On Monday 25 June 2007 21:15:49 Axel Thimm wrote: > > > That was one of the three options ;) > > > > > > I think a security-updates would not be bad, but maybe not in this > > > cycle, there's lot to do in short time and having a Fedora > > > enterprise-like stable branch with security updates isn't Fedora's > > > typical usage scenario. > > > > It's a tough thing to provide, and it would require anybody building a > > security update to build in two collections, potentially having multiple > > branches per release, one for "head" and one for "security", etc.. I think > > it's totally outside the scope of the Fedora project. > > I don't think it would require to build twice or open up several > branches, though, once against release & other security updates would > be enough. > > This assumes of course that FX at the end of its life is still > (mostly) *backwards* (!) compatible to FX at release time. Fedora's > pace and release cycle are balanced to not allow this to happen. For > example for F7 we even dropped mass-rebuilds, because we assumed that > not only FC6+updates is compatible to FC6 w/o, but even to F7. > > While dropping mass-rebuilds was a mistake, this at least demonstrates > that the Fedora model is not supposed to become backwards incompatble > with itself within a release. > > So the implementaion would be just another tag in koji. The maintainer > would have to fire a `make build-security' to have koji shove the > build into the proper tag which would inherit only release and not > updates. updates-candiates etc. would inherit from security. In fact > it looks like koji's model has already been planned to allow for this :) So, what happens when I have a package which I've previously updated and now need to do a security update for. The security problem applies to the original release. Either I have to a) Build twice b) Just push the newer security+otherstuffupdate. Which may depend on other non-security things. *This* is why the security plugin makes sense. Although it doesn't guarantee that you only get security changes, it lets you get just security changes + anything they depend on. At basically no cost to maintainers, testing, etc Jeremy From sundaram at fedoraproject.org Tue Jun 26 02:47:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 26 Jun 2007 08:17:24 +0530 Subject: Mass rebuilds and FESCO In-Reply-To: <20070626014948.GI27093@puariko.nirvana> References: <200706251128.35333.jkeating@redhat.com> <200706252105.11607.jkeating@redhat.com> <20070626011549.GG27093@puariko.nirvana> <200706252120.16645.jkeating@redhat.com> <20070626014948.GI27093@puariko.nirvana> Message-ID: <46807E3C.60005@fedoraproject.org> Axel Thimm wrote: > > While dropping mass-rebuilds was a mistake, this at least demonstrates > that the Fedora model is not supposed to become backwards incompatble > with itself within a release. Last I remember, FESCo was going to make a decision on whether mass rebuilds are going to be done after Fedora 7 release ( the decision before Fedora 7 was just for that particular release). Was that ever discussed and a decision made? Rahul From jkeating at redhat.com Tue Jun 26 02:50:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Jun 2007 22:50:54 -0400 Subject: Mass rebuilds and FESCO In-Reply-To: <46807E3C.60005@fedoraproject.org> References: <200706251128.35333.jkeating@redhat.com> <20070626014948.GI27093@puariko.nirvana> <46807E3C.60005@fedoraproject.org> Message-ID: <200706252250.57865.jkeating@redhat.com> On Monday 25 June 2007 22:47:24 Rahul Sundaram wrote: > Last I remember, FESCo was going to make a decision on whether mass > rebuilds are going to be done after Fedora 7 release ( the decision > before Fedora 7 was just for that particular release). Was that ever > discussed and a decision made? I don't think it's happened yet, and if it did it /really/ should be coordinated with the tools folks (glibc/gcc/etc...) to see if they have anything coming down the pike that would require or could take advantage of a coordinated rebuild effort. -- 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 tgl at redhat.com Tue Jun 26 04:38:58 2007 From: tgl at redhat.com (Tom Lane) Date: Tue, 26 Jun 2007 00:38:58 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <1182825385.4014.1.camel@aglarond.local> References: <200706251128.35333.jkeating@redhat.com> <200706252105.11607.jkeating@redhat.com> <20070626011549.GG27093@puariko.nirvana> <200706252120.16645.jkeating@redhat.com> <20070626014948.GI27093@puariko.nirvana> <1182825385.4014.1.camel@aglarond.local> Message-ID: <11152.1182832738@sss.pgh.pa.us> Jeremy Katz writes: > So, what happens when I have a package which I've previously updated and > now need to do a security update for. I was about to complain about that, but I see Jeremy beat me to it. There is no way that a "security only" update stream isn't going to be an entirely separate branch, costing fully as much maintenance effort as any other separate branch (except maybe that there would be fewer updates involved). You could not expect to piggyback the same released sources in both that branch and the "regular" one. I don't actually see the point of attaching such a concept to Fedora, which has a short update lifespan by design. It makes sense for long-lived platforms such as RHEL. But we already saw Fedora Legacy die on the vine, so where's the manpower going to come from to support a "Fedora-security-update-only" branch? regards, tom lane From mclasen at redhat.com Tue Jun 26 04:44:42 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 26 Jun 2007 00:44:42 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <20070626010045.GF27093@puariko.nirvana> References: <200706251128.35333.jkeating@redhat.com> <200706252009.49142.jkeating@redhat.com> <20070626003151.GC27093@puariko.nirvana> <200706252036.00551.jkeating@redhat.com> <20070626010045.GF27093@puariko.nirvana> Message-ID: <1182833082.3427.14.camel@localhost.localdomain> On Tue, 2007-06-26 at 03:00 +0200, Axel Thimm wrote: > On Mon, Jun 25, 2007 at 08:36:00PM -0400, Jesse Keating wrote: > > On Monday 25 June 2007 20:31:51 Axel Thimm wrote: > > > If for example glibc has been updated yum update foo will not pull it > > > in. Try it. > > > > If it has been updated and the new update of foo will not run > > without the newer glibc and there are no rpm requirements on said > > newer glibc libraries, we've got much bigger issues. > > True, but that's everyday's packaging business and is called "lack of > forward compatibiliy in libraries". Actually that was the reason for > having to build against only securty updates onstead of the whole > update repo given in the trimmed away quote of mine. > > Now to get to real example: Replace glibc with glib/gtk and friends, > that keep the same soname since Moses' birth and add symbols on the > row. You can build something on F7's glib and from a packaging POV it > will still fit into FC5 or FC4, but when the app runs it will break > with missing g* calls. As far as "glib, gtk and friends" are concerned, these do not at any symbols in a stable branch, and Fedora release stay on a stable branch, so your snide remarks are uncalled for, as far as these are concerned. And talking about F7 packages on FC5 or FC4 is really detracting from the topic here, which is security updates within a single Fedora release. From dwmw2 at infradead.org Tue Jun 26 07:29:41 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 26 Jun 2007 08:29:41 +0100 Subject: Mass rebuilds and FESCO In-Reply-To: <200706252250.57865.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> <20070626014948.GI27093@puariko.nirvana> <46807E3C.60005@fedoraproject.org> <200706252250.57865.jkeating@redhat.com> Message-ID: <1182842981.12109.159.camel@pmac.infradead.org> On Mon, 2007-06-25 at 22:50 -0400, Jesse Keating wrote: > I don't think it's happened yet, and if it did it /really/ should be > coordinated with the tools folks (glibc/gcc/etc...) to see if they > have anything coming down the pike that would require or could take > advantage of a coordinated rebuild effort. If we're going to bring a secondary architecture in before F8, it would probably be sane to do so before the mass rebuild. How close are we to being able to merge Alpha or SPARC? -- dwmw2 From cbalint at redhat.com Tue Jun 26 08:22:18 2007 From: cbalint at redhat.com (Balint Cristian) Date: Tue, 26 Jun 2007 10:22:18 +0200 Subject: Mass rebuilds and FESCO In-Reply-To: <1182842981.12109.159.camel@pmac.infradead.org> References: <200706251128.35333.jkeating@redhat.com> <200706252250.57865.jkeating@redhat.com> <1182842981.12109.159.camel@pmac.infradead.org> Message-ID: <200706261022.19025.cbalint@redhat.com> On Tuesday 26 June 2007, David Woodhouse wrote: > On Mon, 2007-06-25 at 22:50 -0400, Jesse Keating wrote: > > I don't think it's happened yet, and if it did it /really/ should be > > coordinated with the tools folks (glibc/gcc/etc...) to see if they > > have anything coming down the pike that would require or could take > > advantage of a coordinated rebuild effort. > > If we're going to bring a secondary architecture in before F8, it would > probably be sane to do so before the mass rebuild. How close are we to > being able to merge Alpha or SPARC? Alpha team status update: We setted up a koji enviroment and struggle to come in sync with latest F8 packages. http://buildsys.zero42.at/koji/index is the HUB. However we work on extend to other builders for more CPU cycles, but right now we have 2 online ones. Actualy we work on feed from fp.o koji succesfull builds in our koji, and fix eventual alpha related issues as much as possible on the fly, Oliver Falk is working on this. Olso we have some blacklisted packages like kernel/glibc since we havent got chance to merge .spec files adjustments and alpha specific patches into fedora ones. We are looking forward for any help/guidance regarding merger, we olso discuss a bit with Dennis Gilmore over IRC, he updated us with the idea of fetch back/forth packages between fp.o <--> alpha.o but this need to have some fp.o side support wich is quite not ready yet. /cristian -------------- 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 Jun 26 08:47:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 10:47:52 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <1182833082.3427.14.camel@localhost.localdomain> References: <200706251128.35333.jkeating@redhat.com> <200706252009.49142.jkeating@redhat.com> <20070626003151.GC27093@puariko.nirvana> <200706252036.00551.jkeating@redhat.com> <20070626010045.GF27093@puariko.nirvana> <1182833082.3427.14.camel@localhost.localdomain> Message-ID: <20070626084752.GE3345@puariko.nirvana> On Tue, Jun 26, 2007 at 12:44:42AM -0400, Matthias Clasen wrote: > On Tue, 2007-06-26 at 03:00 +0200, Axel Thimm wrote: > > On Mon, Jun 25, 2007 at 08:36:00PM -0400, Jesse Keating wrote: > > > On Monday 25 June 2007 20:31:51 Axel Thimm wrote: > > > > If for example glibc has been updated yum update foo will not pull it > > > > in. Try it. > > > > > > If it has been updated and the new update of foo will not run > > > without the newer glibc and there are no rpm requirements on said > > > newer glibc libraries, we've got much bigger issues. > > > > True, but that's everyday's packaging business and is called "lack of > > forward compatibiliy in libraries". Actually that was the reason for > > having to build against only securty updates onstead of the whole > > update repo given in the trimmed away quote of mine. > > > > Now to get to real example: Replace glibc with glib/gtk and friends, > > that keep the same soname since Moses' birth and add symbols on the > > row. You can build something on F7's glib and from a packaging POV it > > will still fit into FC5 or FC4, but when the app runs it will break > > with missing g* calls. > > As far as "glib, gtk and friends" are concerned, these do not at > any symbols in a stable branch, and Fedora release stay on a stable > branch, so your snide remarks are uncalled for, as far as these are > concerned. I'm sorry, but history says otherwise. Symbols have been added to *stable* releases, and many application were breaking when used on a previous *stable* release. I know that because I had been offering newer *stable* glib/gtk/atk/pango bits at ATrpms at about FC4 for an application that needed a fresher set, and users horrified by the "core updates bad" myth only used the applications, which would agree to install rpm-wise, but would spit the errors on the users' faces. I think one of the apps that was dying that way was synaptic. So that would had exactly happened if say synaptic had a security update built against a later "stable" glib/gtk/... set of packages and users trying to install the security update of synaptic on a non-updated (or updated only for security updates) system. So this is far from being an academic example. > And talking about F7 packages on FC5 or FC4 is really detracting > from the topic here, which is security updates within a single > Fedora release. You missed the point: I was just illustrating that rpm's checking is not that tight (it would had to go down to the symbol table, something that has often been considered but due to blowing up the database always abandoned) and will allow you to do lots of crazy things if the library decides to never bump its soname. I'm not suggesting to actually do that in any sense ... -- 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 Tue Jun 26 09:05:20 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 11:05:20 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <1182825385.4014.1.camel@aglarond.local> References: <200706251128.35333.jkeating@redhat.com> <200706252105.11607.jkeating@redhat.com> <20070626011549.GG27093@puariko.nirvana> <200706252120.16645.jkeating@redhat.com> <20070626014948.GI27093@puariko.nirvana> <1182825385.4014.1.camel@aglarond.local> Message-ID: <20070626090520.GF3345@puariko.nirvana> On Mon, Jun 25, 2007 at 10:36:25PM -0400, Jeremy Katz wrote: > On Tue, 2007-06-26 at 03:49 +0200, Axel Thimm wrote: > > On Mon, Jun 25, 2007 at 09:20:16PM -0400, Jesse Keating wrote: > > > On Monday 25 June 2007 21:15:49 Axel Thimm wrote: > > > > That was one of the three options ;) > > > > > > > > I think a security-updates would not be bad, but maybe not in this > > > > cycle, there's lot to do in short time and having a Fedora > > > > enterprise-like stable branch with security updates isn't Fedora's > > > > typical usage scenario. > > > > > > It's a tough thing to provide, and it would require anybody building a > > > security update to build in two collections, potentially having multiple > > > branches per release, one for "head" and one for "security", etc.. I think > > > it's totally outside the scope of the Fedora project. > > > > I don't think it would require to build twice or open up several > > branches, though, once against release & other security updates would > > be enough. > > > > This assumes of course that FX at the end of its life is still > > (mostly) *backwards* (!) compatible to FX at release time. Fedora's > > pace and release cycle are balanced to not allow this to happen. For > > example for F7 we even dropped mass-rebuilds, because we assumed that > > not only FC6+updates is compatible to FC6 w/o, but even to F7. > > > > While dropping mass-rebuilds was a mistake, this at least demonstrates > > that the Fedora model is not supposed to become backwards incompatble > > with itself within a release. > > > > So the implementaion would be just another tag in koji. The maintainer > > would have to fire a `make build-security' to have koji shove the > > build into the proper tag which would inherit only release and not > > updates. updates-candiates etc. would inherit from security. In fact > > it looks like koji's model has already been planned to allow for this :) > > So, what happens when I have a package which I've previously updated and > now need to do a security update for. The security problem applies to > the original release. Either I have to > a) Build twice > b) Just push the newer security+otherstuffupdate. Which may depend on > other non-security things. No, there are two cases you need to distinguish: a) the previous update of foo picked a new update from say glib and friends which wasn't really required for updating foo. The security update of foo would build just the same under the non-updated glib from the beginning of the cycle. No harm done, as we assume that glib and friend continue to be *backwards* compatible. b) The security update really needs the newer glib or some other entity. In this case it doesn't matter if foo has been updated already before or not. Any required depednency needs to be elevated to be included in the security updates repo (e.g. simply tagged as such). So in fact whether foo has already been updated or not, doesn' really matter, what matter is whether the current security update of foo needs to pull in BR/R of other packages as well. Missing BRs would be noticed at once, since the build would not complete. Missing runtime depdencies would be caught by repoclosure/mash whatever tool will check that "release" is sane, as well as "release + *-updates" is sane as well. > *This* is why the security plugin makes sense. Although it doesn't > guarantee that you only get security changes, it lets you get just > security changes + anything they depend on. At basically no cost to > maintainers, testing, etc There is no such thing as circumventing testing :) The plugin would be able to only do two modes, which you can do also by manually splitting the repo (in fact whether we talk about an actual repo or a virtual repo as seen by a plugin is irrelevant for the arguments above, the negative side of the plugin is that it only works with yum, the positive is that you have a marketing and a placebo effect that it should work) a) only pull in the security updates and the really neccessary dependent packages (like foo requiring glib >= version). This leads to the missing symbol syndrome due to moving packages from the future to the past. b) pull everything the security updates depend on thus a firefox security update would probably pull in the whole updates repo. So no plugin, no matter how intelligent, or even a complete yum rewrite will really save you from keeping security updates in their own (virtual) repo and the most importnat part: pull BR's *only* from release + security-updates repo. The only question that is open is whether the rest of the updates-released can rely on these packages or would need a rebuild, and again: as long as Fedora remains backwards compatible to itself within a maintenance cycle this is not a problem. -- 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 eric.tanguy at univ-nantes.fr Tue Jun 26 10:21:01 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Tue, 26 Jun 2007 12:21:01 +0200 Subject: libupnp ABI breakage Message-ID: <1182853262.2888.9.camel@bureau.maison> I just try to upgrade libupnp from 1.4.6 to 1.6.0. This lib is required by gmediaserver and vlc from livna. The 1.6.0 version is already in devel. For F-7, it's in updates-testing and for extras 5 and 6 it's blacklisted. What do you think about this upgrade ? Thanks Eric From mclasen at redhat.com Tue Jun 26 12:49:50 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 26 Jun 2007 08:49:50 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <20070626084752.GE3345@puariko.nirvana> References: <200706251128.35333.jkeating@redhat.com> <200706252009.49142.jkeating@redhat.com> <20070626003151.GC27093@puariko.nirvana> <200706252036.00551.jkeating@redhat.com> <20070626010045.GF27093@puariko.nirvana> <1182833082.3427.14.camel@localhost.localdomain> <20070626084752.GE3345@puariko.nirvana> Message-ID: <1182862190.3711.4.camel@localhost.localdomain> On Tue, 2007-06-26 at 10:47 +0200, Axel Thimm wrote: > On Tue, Jun 26, 2007 at 12:44:42AM -0400, Matthias Clasen wrote: > > On Tue, 2007-06-26 at 03:00 +0200, Axel Thimm wrote: > > > On Mon, Jun 25, 2007 at 08:36:00PM -0400, Jesse Keating wrote: > > > > On Monday 25 June 2007 20:31:51 Axel Thimm wrote: > > > > > If for example glibc has been updated yum update foo will not pull it > > > > > in. Try it. > > > > > > > > If it has been updated and the new update of foo will not run > > > > without the newer glibc and there are no rpm requirements on said > > > > newer glibc libraries, we've got much bigger issues. > > > > > > True, but that's everyday's packaging business and is called "lack of > > > forward compatibiliy in libraries". Actually that was the reason for > > > having to build against only securty updates onstead of the whole > > > update repo given in the trimmed away quote of mine. > > > > > > Now to get to real example: Replace glibc with glib/gtk and friends, > > > that keep the same soname since Moses' birth and add symbols on the > > > row. You can build something on F7's glib and from a packaging POV it > > > will still fit into FC5 or FC4, but when the app runs it will break > > > with missing g* calls. > > > > As far as "glib, gtk and friends" are concerned, these do not at > > any symbols in a stable branch, and Fedora release stay on a stable > > branch, so your snide remarks are uncalled for, as far as these are > > concerned. > > I'm sorry, but history says otherwise. Symbols have been added to > *stable* releases, and many application were breaking when used on a > previous *stable* release. Care to provide a concrete example of a symbol that has been added in a stable series, breaking applications ? I can't think of any. From Axel.Thimm at ATrpms.net Tue Jun 26 13:26:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 15:26:47 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <1182862190.3711.4.camel@localhost.localdomain> References: <200706251128.35333.jkeating@redhat.com> <200706252009.49142.jkeating@redhat.com> <20070626003151.GC27093@puariko.nirvana> <200706252036.00551.jkeating@redhat.com> <20070626010045.GF27093@puariko.nirvana> <1182833082.3427.14.camel@localhost.localdomain> <20070626084752.GE3345@puariko.nirvana> <1182862190.3711.4.camel@localhost.localdomain> Message-ID: <20070626132647.GJ3345@puariko.nirvana> On Tue, Jun 26, 2007 at 08:49:50AM -0400, Matthias Clasen wrote: > On Tue, 2007-06-26 at 10:47 +0200, Axel Thimm wrote: > > On Tue, Jun 26, 2007 at 12:44:42AM -0400, Matthias Clasen wrote: > > > On Tue, 2007-06-26 at 03:00 +0200, Axel Thimm wrote: > > > > On Mon, Jun 25, 2007 at 08:36:00PM -0400, Jesse Keating wrote: > > > > > On Monday 25 June 2007 20:31:51 Axel Thimm wrote: > > > > > > If for example glibc has been updated yum update foo will not pull it > > > > > > in. Try it. > > > > > > > > > > If it has been updated and the new update of foo will not run > > > > > without the newer glibc and there are no rpm requirements on said > > > > > newer glibc libraries, we've got much bigger issues. > > > > > > > > True, but that's everyday's packaging business and is called "lack of > > > > forward compatibiliy in libraries". Actually that was the reason for > > > > having to build against only securty updates onstead of the whole > > > > update repo given in the trimmed away quote of mine. > > > > > > > > Now to get to real example: Replace glibc with glib/gtk and friends, > > > > that keep the same soname since Moses' birth and add symbols on the > > > > row. You can build something on F7's glib and from a packaging POV it > > > > will still fit into FC5 or FC4, but when the app runs it will break > > > > with missing g* calls. > > > > > > As far as "glib, gtk and friends" are concerned, these do not at > > > any symbols in a stable branch, and Fedora release stay on a stable > > > branch, so your snide remarks are uncalled for, as far as these are > > > concerned. > > > > I'm sorry, but history says otherwise. Symbols have been added to > > *stable* releases, and many application were breaking when used on a > > previous *stable* release. > > Care to provide a concrete example of a symbol that has been added in a > stable series, breaking applications ? I can't think of any. http://www.google.com/search?q=g_assert_warning (2,460 which all seem to discuss the missing symbol in various higher stack packages) And according to the changelog you should be aware of that: 2004-09-29 Matthias Clasen * glib/glib.symbols: Add g_assert_warning. But I'm not here o blame you for not keeping forward compatibility of glib and co, it's about taking this fact as granted and planing this into any security-updates (virtual) repo or similar application. There just is no forward compatibility in 99% of all libs, because any change of the ABI, even just adding new symbols requires an soname change for forward compatibility. The usual practice is to not bump sonames if the API/ABI remains backward compatible, that's what you do, it's OK, but it still breaks forward compatibility. And even if you would now reconsider and keep the ABI constant during an soname to ensure both-way compatibility, there are tons of other libs that do the same, glib was just a real example with a proven pain track in google. So it remains: A security update intended to not be used with updates-released will have to be built against the pure release's environment w/o any updates in the BRs. There is nothing magical rpm [1] or a yum-plugin can do to alleviate this. [1] unless rpm would start to record dependencies on symbol level (!) -- 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 mclasen at redhat.com Tue Jun 26 13:25:45 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 26 Jun 2007 09:25:45 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <20070626132647.GJ3345@puariko.nirvana> References: <200706251128.35333.jkeating@redhat.com> <200706252009.49142.jkeating@redhat.com> <20070626003151.GC27093@puariko.nirvana> <200706252036.00551.jkeating@redhat.com> <20070626010045.GF27093@puariko.nirvana> <1182833082.3427.14.camel@localhost.localdomain> <20070626084752.GE3345@puariko.nirvana> <1182862190.3711.4.camel@localhost.localdomain> <20070626132647.GJ3345@puariko.nirvana> Message-ID: <1182864345.3711.23.camel@localhost.localdomain> On Tue, 2007-06-26 at 15:26 +0200, Axel Thimm wrote: > > > > Care to provide a concrete example of a symbol that has been added in a > > stable series, breaking applications ? I can't think of any. > > http://www.google.com/search?q=g_assert_warning > (2,460 which all seem to discuss the missing symbol in various higher > stack packages) > > And according to the changelog you should be aware of that: Oh, I am aware of g_assert_warning. But it is not the example I asked you for, since it was added in 2.5.3, in the middle of a development series. That is not something that you will see in a released Fedora, unless something unforeseen happens. From Axel.Thimm at ATrpms.net Tue Jun 26 13:46:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Jun 2007 15:46:10 +0200 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <1182864345.3711.23.camel@localhost.localdomain> References: <200706251128.35333.jkeating@redhat.com> <200706252009.49142.jkeating@redhat.com> <20070626003151.GC27093@puariko.nirvana> <200706252036.00551.jkeating@redhat.com> <20070626010045.GF27093@puariko.nirvana> <1182833082.3427.14.camel@localhost.localdomain> <20070626084752.GE3345@puariko.nirvana> <1182862190.3711.4.camel@localhost.localdomain> <20070626132647.GJ3345@puariko.nirvana> <1182864345.3711.23.camel@localhost.localdomain> Message-ID: <20070626134610.GK3345@puariko.nirvana> On Tue, Jun 26, 2007 at 09:25:45AM -0400, Matthias Clasen wrote: > On Tue, 2007-06-26 at 15:26 +0200, Axel Thimm wrote: > > > > > > > Care to provide a concrete example of a symbol that has been added in a > > > stable series, breaking applications ? I can't think of any. > > > > http://www.google.com/search?q=g_assert_warning > > (2,460 which all seem to discuss the missing symbol in various higher > > stack packages) > > > > And according to the changelog you should be aware of that: > > Oh, I am aware of g_assert_warning. But it is not the example I asked > you for, since it was added in 2.5.3, in the middle of a development > series. That is not something that you will see in a released Fedora, > unless something unforeseen happens. But it made its way into the stable release nonetheless (there are very few references to odd versions in the google results above, and I know for sure I never used a development release when I encounterd this at ATrpms), so whether there was historically a development cycle doesn't matter, comparing the stable releases matters and the fact remains that: o Two different stable releases had a different set of symbols o These two stable releases had the same soname o One stable release (the younger one) was ABI-wise a superset of the older one So all these together give: There is backward compatibility in this project (OK), but certainly no forward compatibility (also OK, nobody and his cat even less care about forward compatibility, so why should you). And that brings up back to: o no ensured forward compatibility in libraries o still same soname o rpm and anything higher can't detect any lack of forward compatibility to force pulling in later versions of libraries Leading utlimatively again to o A security-updates repo can only be built against itself (itself = release + itself). -- 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 poelstra at redhat.com Tue Jun 26 14:54:20 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 26 Jun 2007 07:54:20 -0700 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <200706251128.35333.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> Message-ID: <4681289C.3080900@redhat.com> Jesse Keating wrote: > Below you will find a list of topics that we'd like to go over in the next > RelEng meeting that is scheduled for Today, Monday at 1700 UTC in > #fedora-meeting on irc.freenode.org: > > /topic RELENG-Meeting - Fedora 5 shutdown - JesseKeating > > /topic RELENG-Meeting - Automatic promotion of updates - JesseKeating > > /topic RELENG-Meeting - Open Discussion > Shouldn't these announcement be sent to fedora-devel considering that is where we decided to send the meeting minutes? John From oliver at linux-kernel.at Tue Jun 26 15:05:20 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 26 Jun 2007 17:05:20 +0200 Subject: Mass rebuilds and FESCO In-Reply-To: <200706261022.19025.cbalint@redhat.com> References: <200706251128.35333.jkeating@redhat.com> <200706252250.57865.jkeating@redhat.com> <1182842981.12109.159.camel@pmac.infradead.org> <200706261022.19025.cbalint@redhat.com> Message-ID: <46812B30.8080209@linux-kernel.at> Hi! On 06/26/2007 10:22 AM, Balint Cristian wrote: > On Tuesday 26 June 2007, David Woodhouse wrote: >> On Mon, 2007-06-25 at 22:50 -0400, Jesse Keating wrote: >>> I don't think it's happened yet, and if it did it /really/ should be >>> coordinated with the tools folks (glibc/gcc/etc...) to see if they >>> have anything coming down the pike that would require or could take >>> advantage of a coordinated rebuild effort. >> If we're going to bring a secondary architecture in before F8, it would >> probably be sane to do so before the mass rebuild. How close are we to >> being able to merge Alpha or SPARC? > > > Alpha team status update: > > We setted up a koji enviroment and struggle to come in sync with > latest F8 packages. > > http://buildsys.zero42.at/koji/index is the HUB. > > However we work on extend to other builders for more CPU cycles, but right > now we have 2 online ones. > > Actualy we work on feed from fp.o koji succesfull builds in our koji, and fix eventual > alpha related issues as much as possible on the fly, Oliver Falk is working on this. > Olso we have some blacklisted packages like kernel/glibc since we havent got chance > to merge .spec files adjustments and alpha specific patches into fedora ones. Just a short note. glibc is no longer b/l. glibc-2.6-1 compiled fine and has been imported in our alpha-koji-buildsys. I do see only a few big issues at the moment: * kernel - need to bring in patches to fp.o and try to not overuse ifarch's * eclipse - my biggest pain - need it for gcc and all java stuff. * openoffice - never tried on alpha, but don't want to think what will come... > We are looking forward for any help/guidance regarding merger, we olso discuss a bit > with Dennis Gilmore over IRC, he updated us with the idea of fetch back/forth packages > between fp.o <--> alpha.o but this need to have some fp.o side support wich is quite > not ready yet. Any help to bring fp.o and alpha.o in sync is appreciated! Spare-Alpha-CPU-Cycles. Devels who can fix alpha-related issues... And so on.... -of From jkeating at redhat.com Tue Jun 26 15:04:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 26 Jun 2007 11:04:04 -0400 Subject: Plan for Today's (20070625) Release Engineering meeting In-Reply-To: <4681289C.3080900@redhat.com> References: <200706251128.35333.jkeating@redhat.com> <4681289C.3080900@redhat.com> Message-ID: <200706261104.10460.jkeating@redhat.com> On Tuesday 26 June 2007 10:54:20 John Poelstra wrote: > Shouldn't these announcement be sent to fedora-devel considering that is > where we decided to send the meeting minutes? Perhaps. Eventually this list in general should go away. -- 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 cbalint at redhat.com Tue Jun 26 15:10:34 2007 From: cbalint at redhat.com (Balint Cristian) Date: Tue, 26 Jun 2007 17:10:34 +0200 Subject: Mass rebuilds and FESCO In-Reply-To: <46812B30.8080209@linux-kernel.at> References: <200706251128.35333.jkeating@redhat.com> <200706261022.19025.cbalint@redhat.com> <46812B30.8080209@linux-kernel.at> Message-ID: <200706261710.34350.cbalint@redhat.com> > * openoffice - never tried on alpha, but don't want to think what will need UNO bridge to be written, however we dont really have now time for this, maybe after settle down a bit. /cris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caolanm at redhat.com Tue Jun 26 15:15:03 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Tue, 26 Jun 2007 16:15:03 +0100 Subject: Mass rebuilds and FESCO In-Reply-To: <46812B30.8080209@linux-kernel.at> References: <200706251128.35333.jkeating@redhat.com> <200706252250.57865.jkeating@redhat.com> <1182842981.12109.159.camel@pmac.infradead.org> <200706261022.19025.cbalint@redhat.com> <46812B30.8080209@linux-kernel.at> Message-ID: <1182870903.25654.16.camel@localhost.localdomain> On Tue, 2007-06-26 at 17:05 +0200, Oliver Falk wrote: > * openoffice - never tried on alpha, but don't want to think what will > come... You'll need a ported uno bridge to make this work, see bridges/source/cpp_uno. It's the same sort of thing as the libffi stuff in gcc. http://porting.openoffice.org/ says that "alpha is stalled", looking at workspace.ppc64one.patch in the OOo .src.rpm may help you get one written. C. From fedora at leemhuis.info Tue Jun 26 15:36:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 26 Jun 2007 17:36:49 +0200 Subject: mailing list reorganization (was Re: Plan for Today's (20070625) Release Engineering meeting) In-Reply-To: <200706261104.10460.jkeating@redhat.com> References: <200706251128.35333.jkeating@redhat.com> <4681289C.3080900@redhat.com> <200706261104.10460.jkeating@redhat.com> Message-ID: <46813291.3010901@leemhuis.info> On 26.06.2007 17:04, Jesse Keating wrote: > On Tuesday 26 June 2007 10:54:20 John Poelstra wrote: >> Shouldn't these announcement be sent to fedora-devel considering that is >> where we decided to send the meeting minutes? > Perhaps. Eventually this list in general should go away. FYI: I'm actually working on the mailing list reorganization now again after F7 is out and I'm back from vacation. Getting rid of that list is part of my plan. CU thl From chitlesh at fedoraproject.org Tue Jun 26 16:07:56 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 26 Jun 2007 18:07:56 +0200 Subject: Mass rebuilds and FESCO In-Reply-To: <46812B30.8080209@linux-kernel.at> References: <200706251128.35333.jkeating@redhat.com> <200706252250.57865.jkeating@redhat.com> <1182842981.12109.159.camel@pmac.infradead.org> <200706261022.19025.cbalint@redhat.com> <46812B30.8080209@linux-kernel.at> Message-ID: <13dbfe4f0706260907w214ab70bjf1c26d3ddffd3467@mail.gmail.com> On 6/26/07, Oliver Falk wrote: > Any help to bring fp.o and alpha.o in sync is appreciated! > Spare-Alpha-CPU-Cycles. Devels who can fix alpha-related issues... And > so on.... What can be done or possibly one can do, if someone(example me) want to test his packages on alpha machines? Eventually find fixes for the broken packages if any. Chitlesh -- http://clunixchit.blogspot.com From fedora at leemhuis.info Tue Jun 26 18:14:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 26 Jun 2007 20:14:33 +0200 Subject: EPEL report week 25, 2007 Message-ID: <46815789.3000009@leemhuis.info> (sorry, a bit late this week) http://fedoraproject.org/wiki/EPEL/Reports/Week25 = Weekly EPEL Summary = Week 25/2007 == Most important happenings == We'll likely fill the Vacant Steering Committee Seat over the next week; so if you are interested let knurd know! == EPEL SIG Meeting == === Attending === >From the Steering Committee: * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * dgilmore (DennisGilmore) * stahnma (MichaelStahnke) * quiad (KarstenWade) (had fun at the dentist) Missing from the Steering Committee: * knurd (ThorstenLeemhuis) (partly) Others that participated the meeting: rdieter, _blah_, === Summary === * Finish the wiki -- quaid * quaid > I think all of you have done a good job of making the content ... full and rich ; so it's a few hours of edits left ; I'll be able to do an hour today, for sure, so again ... should be done by the end of the week :) * Repo-layout * looks like Fedora will keep lmacken and mbonnet busy for a while; so we should might towards a solution to annouce epel, but use plague and the old extras push-scripts for the near future; or go without testing for nowdiscuss further on the list * some discussion if we want stable and rolling releases * Make sure the repo is in good shape * we maybe should run the dependency checker script regularly; mmcgrath will look into this * Announce EPEL officially * mmcgrath> so we're blocking on the wiki as well as the build stuff. So thats the end of the big picture tasks really. * Vacant seat in the steering committee * will get discussed on the list * Free Discussion: * some discussion around RHX and if EPEL can package stuff that's part of it; see full log for details === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-June/msg00056.html == Stats == === General === Number of EPEL Contributors 98 We welcome 8 new contributors: alex_AT_dalloz.de, i_AT_stingr.net, jjohnstn_AT_redhat.com, john_AT_ncphotography.com, jonathansteffan_AT_gmail.com, lists_AT_forevermore.net, otaylor_AT_redhat.com, overholt_AT_redhat.com, robert_AT_marcanoonline.com, than_AT_redhat.com === EPEL 5 === Number of source packages: 393 Number of binary packages: 641 There are 34 new Packages: * aqbanking | A library for online banking functions and financial data import/export * asciidoc | Text based document generation * babel | Tools for internationalizing Python applications * bash-completion | Programmable completion for Bash * checkstyle | Java source code checker * ctapi-cyberjack | CT-API 1.1 driver for REINER SCT cyberjack USB chipcard reader * cvsplot | Collect statistics from CVS controlled files * eclipse-cdt | Eclipse C/C++ Development Tools (CDT) plugin * eclipse-checkstyle | Checkstyle plugin for Eclipse * fortune-mod | A program which will display a fortune * ganymed-ssh2 | SSH-2 protocol implementation in pure Java * git | Git core and tools * gnucash-docs | Help files and documentation for the GnuCash personal finanace manager * gnucash | GnuCash is an application to keep track of your finances * gwenhywfar | A multi-platform helper library for other libraries * g-wrap | A tool for creating Scheme interfaces to C libraries * jakarta-commons-cli | Command Line Interface Library for Java * kmymoney2 | Personal finance * libofx | A library for supporting Open Financial Exchange (OFX) * mercurial | A fast, lightweight distributed source control management system * mksh | MirBSD enhanced version of the Korn Shell * mod_security | Security module for the Apache HTTP Server * muParser | A fast math parser library * perl-Finance-Quote | A Perl module that retrieves stock and mutual fund quotes * perl-HTML-TableExtract | A Perl module for extracting content in HTML tables * pfqueue | Queue manager for the Postfix/Exim Mail Transport Agents * postgresql-table_log | Log data changes in a PostgreSQL table * reciteword | Recite Word Easily * recode | Conversion between character sets and surfaces * rsnapshot | Local and remote filesystem snapshot utility * rzip | A large-file compression program * sec | SEC (simple event correlator) * slib | Platform independent library for scheme * svnkit | Pure Java Subversion client library * tcptraceroute | A traceroute implementation using TCP packets === EPEL 4 === Number of source packages: 248 Number of binary packages: 460 There are 18 new Packages: * aqbanking | A library for online banking functions and financial data import/export * bash-completion | Programmable completion for Bash * ctapi-cyberjack | CT-API 1.1 driver for REINER SCT cyberjack USB chipcard reader * cvsplot | Collect statistics from CVS controlled files * fortune-mod | A program which will display a fortune * git | Git core and tools * gnucash-docs | Help files and documentation for the GnuCash personal finanace manager * gnucash | GnuCash is an application to keep track of your finances * gwenhywfar | A multi-platform helper library for other libraries * g-wrap | A tool for creating Scheme interfaces to C libraries * libofx | A library for supporting Open Financial Exchange (OFX) * mercurial | A fast, lightweight distributed source control management system * mksh | MirBSD enhanced version of the Korn Shell * muParser | A fast math parser library * perl-Finance-Quote | A Perl module that retrieves stock and mutual fund quotes * perl-HTML-TableExtract | A Perl module for extracting content in HTML tables * pfqueue | Queue manager for the Postfix/Exim Mail Transport Agents * recode | Conversion between character sets and surfaces * rzip | A large-file compression program ---- ["CategoryEPELReports"] From oliver at linux-kernel.at Tue Jun 26 18:30:38 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 26 Jun 2007 20:30:38 +0200 Subject: Mass rebuilds and FESCO In-Reply-To: <13dbfe4f0706260907w214ab70bjf1c26d3ddffd3467@mail.gmail.com> References: <200706251128.35333.jkeating@redhat.com> <200706252250.57865.jkeating@redhat.com> <1182842981.12109.159.camel@pmac.infradead.org> <200706261022.19025.cbalint@redhat.com> <46812B30.8080209@linux-kernel.at> <13dbfe4f0706260907w214ab70bjf1c26d3ddffd3467@mail.gmail.com> Message-ID: <46815B4E.8070600@linux-kernel.at> Chitlesh GOORAH schrieb: > On 6/26/07, Oliver Falk wrote: >> Any help to bring fp.o and alpha.o in sync is appreciated! >> Spare-Alpha-CPU-Cycles. Devels who can fix alpha-related issues... And >> so on.... > > What can be done or possibly one can do, if someone(example me) want > to test his packages on alpha machines? > > Eventually find fixes for the broken packages if any. Do exactly what you just did for example. Ask! You can request a user for our buildsystem and I'll create one. Or you just tell me what package I should try to build (prefered at the moment) and I'll do so. Please note, that we haven't all packages done yet. That means, that some pkgs that have longer dep lists will take longer, as we first have to build the deps... Best, Oliver From chitlesh at fedoraproject.org Tue Jun 26 19:08:03 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 26 Jun 2007 21:08:03 +0200 Subject: Mass rebuilds and FESCO In-Reply-To: <46815B4E.8070600@linux-kernel.at> References: <200706251128.35333.jkeating@redhat.com> <200706252250.57865.jkeating@redhat.com> <1182842981.12109.159.camel@pmac.infradead.org> <200706261022.19025.cbalint@redhat.com> <46812B30.8080209@linux-kernel.at> <13dbfe4f0706260907w214ab70bjf1c26d3ddffd3467@mail.gmail.com> <46815B4E.8070600@linux-kernel.at> Message-ID: <13dbfe4f0706261208v4768f00cpecd9db668db8a833@mail.gmail.com> On 6/26/07, Oliver Falk wrote: > Do exactly what you just did for example. Ask! Good :) > You can request a user for our buildsystem and I'll create one. Yup, I want one :) > Please note, that we haven't all packages done yet. That > means, that some pkgs that have longer dep lists will take longer, as we > first have to build the deps... I can wait, knowing I got a lots of things to do. However I would like to test one by one my packages which I have for fedora. Chitlesh -- http://clunixchit.blogspot.com From oliver at linux-kernel.at Tue Jun 26 19:06:24 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 26 Jun 2007 21:06:24 +0200 Subject: Mass rebuilds and FESCO In-Reply-To: <13dbfe4f0706261208v4768f00cpecd9db668db8a833@mail.gmail.com> References: <200706251128.35333.jkeating@redhat.com> <200706252250.57865.jkeating@redhat.com> <1182842981.12109.159.camel@pmac.infradead.org> <200706261022.19025.cbalint@redhat.com> <46812B30.8080209@linux-kernel.at> <13dbfe4f0706260907w214ab70bjf1c26d3ddffd3467@mail.gmail.com> <46815B4E.8070600@linux-kernel.at> <13dbfe4f0706261208v4768f00cpecd9db668db8a833@mail.gmail.com> Message-ID: <468163B0.1000205@linux-kernel.at> Chitlesh GOORAH schrieb: > On 6/26/07, Oliver Falk wrote: >> Do exactly what you just did for example. Ask! > > Good :) > >> You can request a user for our buildsystem and I'll create one. > > Yup, I want one :) > >> Please note, that we haven't all packages done yet. That >> means, that some pkgs that have longer dep lists will take longer, as we >> first have to build the deps... > > I can wait, knowing I got a lots of things to do. However I would like > to test one by one my packages which I have for fedora. OK. I'll create one for you tomorrow. I'm already at home and suddenly want to spend some time with family :-) Just let me know you prefered username... David, if you like you can join #AlphaCore on freenode; cbalint is usually logged in there and /me as well (ofalk; Between 9:00 - 18:00 GMT+1 from work-desk). Well, all that should be mentioned on my Wiki, but .... -of From notting at redhat.com Tue Jun 26 19:21:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 26 Jun 2007 15:21:18 -0400 Subject: orphan package: gtkhtml38 Message-ID: <20070626192118.GA4970@nostromo.devel.redhat.com> I don't have a particular need for gtkhtml38 in the devel tree any more, so I figured I'd offer it up for others that may want it. Better yet, if the users could get ported to current gtkhtml3 (with the associated printing/abi issues), all the better. Current users: gnomesword-0:2.2.3-3.fc8 gnotime-0:2.2.2-7.fc6 Bill From a.badger at gmail.com Tue Jun 26 19:34:49 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 26 Jun 2007 12:34:49 -0700 Subject: orphan package: gtkhtml38 In-Reply-To: <20070626192118.GA4970@nostromo.devel.redhat.com> References: <20070626192118.GA4970@nostromo.devel.redhat.com> Message-ID: <1182886489.4173.131.camel@localhost.localdomain> On Tue, 2007-06-26 at 15:21 -0400, Bill Nottingham wrote: > I don't have a particular need for gtkhtml38 in the devel tree > any more, so I figured I'd offer it up for others that may want > it. Better yet, if the users could get ported to current gtkhtml3 > (with the associated printing/abi issues), all the better. > > Current users: gnomesword-0:2.2.3-3.fc8 gnotime-0:2.2.2-7.fc6 > I'll be looking into porting gnotime rather than hanging onto gtkhtml38 indefinitely. -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 dakingun at gmail.com Tue Jun 26 20:06:34 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Tue, 26 Jun 2007 16:06:34 -0400 Subject: orphan package: gtkhtml38 In-Reply-To: <20070626192118.GA4970@nostromo.devel.redhat.com> References: <20070626192118.GA4970@nostromo.devel.redhat.com> Message-ID: On 6/26/07, Bill Nottingham wrote: > I don't have a particular need for gtkhtml38 in the devel tree > any more, so I figured I'd offer it up for others that may want > it. Better yet, if the users could get ported to current gtkhtml3 > (with the associated printing/abi issues), all the better. > > Current users: gnomesword-0:2.2.3-3.fc8 gnotime-0:2.2.2-7.fc6 > A new version of gnomesword will 'soon' be released with support for newer gtkhtml3, so gnomesword will be OK with no gtkhtml38. Deji From tibbs at math.uh.edu Tue Jun 26 20:45:12 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Jun 2007 15:45:12 -0500 Subject: Summary of the 2007-06-26 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-06-26 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070626 Executive summary: The following drafts are now official guidelines, having been accepted by FESCO last week: * http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges These should be written into the guidelines soon if this hasn't already been done by the time you read this. Issues pending FESCO ratification: * Allowing freeform use of version control system data in the release field of snapshot packages. * http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs * Accepted (7 - 0) Misc business: * What files should be allowed to be placed in /srv/ ? * Some packages explicitly place things in /srv * Tabled until next week in order to get thimm's opinion. - J< From chitlesh at fedoraproject.org Wed Jun 27 10:44:29 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 27 Jun 2007 12:44:29 +0200 Subject: koji and dependency management Message-ID: <13dbfe4f0706270344t5a6c8fd3jbf00e67ae887122d@mail.gmail.com> Hello there on koji, if several packages depend on a particular package, and the latter has already been built by me, * what should be done so that the rest can built upon it ? I have this problem only on f7, on F8-devel those packages have successfully pulled their recently built dependency Example: geda-gschem-20070626 needs libgeda-20070626 as BR. libgeda-20070626 for f7 has already been built. But however geda-gschem-20070626 is unable to find libgeda-20070626. Hence it fails to build. Chitlesh -- http://clunixchit.blogspot.com From jwboyer at jdub.homelinux.org Wed Jun 27 12:00:30 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 27 Jun 2007 07:00:30 -0500 Subject: koji and dependency management In-Reply-To: <13dbfe4f0706270344t5a6c8fd3jbf00e67ae887122d@mail.gmail.com> References: <13dbfe4f0706270344t5a6c8fd3jbf00e67ae887122d@mail.gmail.com> Message-ID: <1182945630.23154.5.camel@vader.jdub.homelinux.org> On Wed, 2007-06-27 at 12:44 +0200, Chitlesh GOORAH wrote: > Hello there > on koji, if several packages depend on a particular package, and the > latter has already been built by me, > * what should be done so that the rest can built upon it ? > > I have this problem only on f7, on F8-devel those packages have > successfully pulled their recently built dependency > > Example: geda-gschem-20070626 needs libgeda-20070626 as BR. > libgeda-20070626 for f7 has already been built. But however > geda-gschem-20070626 is unable to find libgeda-20070626. Hence it > fails to build. You need to email rel-eng to get it pulled into the f-7 build root temporarily. The buildroot is only updated from F-7 + updates. josh From Axel.Thimm at ATrpms.net Wed Jun 27 14:34:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Jun 2007 16:34:56 +0200 Subject: koji and dependency management In-Reply-To: <1182945630.23154.5.camel@vader.jdub.homelinux.org> References: <13dbfe4f0706270344t5a6c8fd3jbf00e67ae887122d@mail.gmail.com> <1182945630.23154.5.camel@vader.jdub.homelinux.org> Message-ID: <20070627143456.GB18276@puariko.nirvana> On Wed, Jun 27, 2007 at 07:00:30AM -0500, Josh Boyer wrote: > On Wed, 2007-06-27 at 12:44 +0200, Chitlesh GOORAH wrote: > > Hello there > > on koji, if several packages depend on a particular package, and the > > latter has already been built by me, > > * what should be done so that the rest can built upon it ? > > > > I have this problem only on f7, on F8-devel those packages have > > successfully pulled their recently built dependency > > > > Example: geda-gschem-20070626 needs libgeda-20070626 as BR. > > libgeda-20070626 for f7 has already been built. But however > > geda-gschem-20070626 is unable to find libgeda-20070626. Hence it > > fails to build. > > You need to email rel-eng to get it pulled into the f-7 build root > temporarily. The buildroot is only updated from F-7 + updates. Wasn't this going to change? Or was in discussion at least? There was some concern about buildroot poisoning, but that rarely happens (although it has happened to me once with nx ...), and if it happens it isn't really detected anyway until it gets higher visibility. The problem is that some packages need to be built and pushed together, even for updates-testing. -- 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 Jun 27 14:46:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Jun 2007 10:46:55 -0400 Subject: koji and dependency management In-Reply-To: <20070627143456.GB18276@puariko.nirvana> References: <13dbfe4f0706270344t5a6c8fd3jbf00e67ae887122d@mail.gmail.com> <1182945630.23154.5.camel@vader.jdub.homelinux.org> <20070627143456.GB18276@puariko.nirvana> Message-ID: <200706271046.55531.jkeating@redhat.com> On Wednesday 27 June 2007 10:34:56 Axel Thimm wrote: > Wasn't this going to change? Or was in discussion at least? There was > some concern about buildroot poisoning, but that rarely happens > (although it has happened to me once with nx ...), and if it happens > it isn't really detected anyway until it gets higher visibility. > > The problem is that some packages need to be built and pushed > together, even for updates-testing. Rel-Eng would like to experiment with letting potential updates populate the buildroot, but we require bodhi not allow updates to be pushed out if they were built against something that is also not already pushed out or being pushed out. -- 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 j.w.r.degoede at hhs.nl Wed Jun 27 15:07:04 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 27 Jun 2007 17:07:04 +0200 Subject: [Fwd: Broken dependencies in Fedora 7 + Test Updates - 2007-06-21] In-Reply-To: <20070622104549.d57fe3cd.bugs.michael@gmx.net> References: <4108.192.168.0.1.1182462996.squirrel@mail.jcomserv.net> <20070621220643.GA7725@nostromo.devel.redhat.com> <20070622104549.d57fe3cd.bugs.michael@gmx.net> Message-ID: <46827D18.90502@hhs.nl> Michael Schwendt wrote: > On Thu, 21 Jun 2007 18:06:43 -0400, Bill Nottingham wrote: > >> Jon Ciesla (limb at jcomserv.net) said: >>> This package's corresponding -data package is not disttagged, and needs to >>> be linked from the version in rawhide. Who do I ask for help with this? >>> Will I have to repeat the process once it goes to f-7 stable, and again >>> for FC-6? >> Surely the data package exists in the F7 release? > > Surely not. > Jon, With F-7 due to all the changes surrounding the merge, it is no longer possible (AFAIK) for repo admins to go in and copy over packages. So the proper way todo is, is to add a dist-tag and then rebuild for devel and also build for F-7, just like you would do with a normal package. Regards, Hans From jkeating at redhat.com Wed Jun 27 15:17:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Jun 2007 11:17:08 -0400 Subject: [Fwd: Broken dependencies in Fedora 7 + Test Updates - 2007-06-21] In-Reply-To: <46827D18.90502@hhs.nl> References: <4108.192.168.0.1.1182462996.squirrel@mail.jcomserv.net> <20070622104549.d57fe3cd.bugs.michael@gmx.net> <46827D18.90502@hhs.nl> Message-ID: <200706271117.12052.jkeating@redhat.com> On Wednesday 27 June 2007 11:07:04 Hans de Goede wrote: > Jon, > > With F-7 due to all the changes surrounding the merge, it is no longer > possible (AFAIK) for repo admins to go in and copy over packages. So the > proper way todo is, is to add a dist-tag and then rebuild for devel and > also build for F-7, just like you would do with a normal package. Or alternatively you build for the oldest release first, and let inheritance happen for the other collections. So long as you haven't built it already for say devel, if you build it in FC-7 and push it out as an update, once stable rawhide will inherit the 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 ville.skytta at iki.fi Wed Jun 27 16:03:52 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 27 Jun 2007 19:03:52 +0300 Subject: libupnp ABI breakage In-Reply-To: <1182853262.2888.9.camel@bureau.maison> References: <1182853262.2888.9.camel@bureau.maison> Message-ID: <200706271903.52525.ville.skytta@iki.fi> On Tuesday 26 June 2007, Tanguy Eric wrote: > I just try to upgrade libupnp from 1.4.6 to 1.6.0. This > lib is required by gmediaserver and vlc from livna. The 1.6.0 version is > already in devel. For F-7, it's in updates-testing and for extras 5 and > 6 it's blacklisted. What do you think about this upgrade ? Hard to tell - was the rationale for inflicting the soname compatibility pain and special repo arrangements explained somewhere? If it was, I missed it. From Axel.Thimm at ATrpms.net Wed Jun 27 16:22:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Jun 2007 18:22:11 +0200 Subject: koji and dependency management In-Reply-To: <200706271046.55531.jkeating@redhat.com> References: <13dbfe4f0706270344t5a6c8fd3jbf00e67ae887122d@mail.gmail.com> <1182945630.23154.5.camel@vader.jdub.homelinux.org> <20070627143456.GB18276@puariko.nirvana> <200706271046.55531.jkeating@redhat.com> Message-ID: <20070627162211.GD5078@puariko.nirvana> On Wed, Jun 27, 2007 at 10:46:55AM -0400, Jesse Keating wrote: > On Wednesday 27 June 2007 10:34:56 Axel Thimm wrote: > > Wasn't this going to change? Or was in discussion at least? There was > > some concern about buildroot poisoning, but that rarely happens > > (although it has happened to me once with nx ...), and if it happens > > it isn't really detected anyway until it gets higher visibility. > > > > The problem is that some packages need to be built and pushed > > together, even for updates-testing. > > Rel-Eng would like to experiment with letting potential updates populate the > buildroot, but we require bodhi not allow updates to be pushed out if they > were built against something that is also not already pushed out or being > pushed out. That would be great, thanks! Probably something to watch fedora-devel-announce for news :) -- 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 chitlesh at fedoraproject.org Wed Jun 27 19:11:53 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 27 Jun 2007 21:11:53 +0200 Subject: koji and dependency management In-Reply-To: <200706271046.55531.jkeating@redhat.com> References: <13dbfe4f0706270344t5a6c8fd3jbf00e67ae887122d@mail.gmail.com> <1182945630.23154.5.camel@vader.jdub.homelinux.org> <20070627143456.GB18276@puariko.nirvana> <200706271046.55531.jkeating@redhat.com> Message-ID: <13dbfe4f0706271211o17fd8607uabdcd3940007b359@mail.gmail.com> On 6/27/07, Jesse Keating wrote: > Rel-Eng would like to experiment with letting potential updates populate the > buildroot, but we require bodhi not allow updates to be pushed out if they > were built against something that is also not already pushed out or being > pushed out. So Jesse, in my case, what can I do to continue building my other packages ? You are on the Rel-Eng, right ? can you help me get libgeda-20070626 pulled out when building my other geda packages please. Chitlesh -- http://clunixchit.blogspot.com From jkeating at redhat.com Wed Jun 27 19:12:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Jun 2007 15:12:30 -0400 Subject: koji and dependency management In-Reply-To: <13dbfe4f0706271211o17fd8607uabdcd3940007b359@mail.gmail.com> References: <13dbfe4f0706270344t5a6c8fd3jbf00e67ae887122d@mail.gmail.com> <200706271046.55531.jkeating@redhat.com> <13dbfe4f0706271211o17fd8607uabdcd3940007b359@mail.gmail.com> Message-ID: <200706271512.30889.jkeating@redhat.com> On Wednesday 27 June 2007 15:11:53 Chitlesh GOORAH wrote: > So Jesse, in my case, what can I do to continue building my other packages > ? > > You are on the Rel-Eng, right ? can you help me get libgeda-20070626 > pulled out when building my other geda packages please. It has been tagged. I'd love for somebody to help me decide /where/ in our wide world of wiki this should be documented (IE how to recognize the issue and request the override). -- 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 aoliva at redhat.com Wed Jun 27 21:12:08 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Wed, 27 Jun 2007 18:12:08 -0300 Subject: koji and dependency management In-Reply-To: <1182945630.23154.5.camel@vader.jdub.homelinux.org> (Josh Boyer's message of "Wed\, 27 Jun 2007 07\:00\:30 -0500") References: <13dbfe4f0706270344t5a6c8fd3jbf00e67ae887122d@mail.gmail.com> <1182945630.23154.5.camel@vader.jdub.homelinux.org> Message-ID: On Jun 27, 2007, Josh Boyer wrote: > You need to email rel-eng to get it pulled into the f-7 build root > temporarily. The buildroot is only updated from F-7 + updates. Is there any reason that makes it impossible for koji to accept say a list of additional packages to be installed in the buildroot along with any other build dependencies? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From roland at redhat.com Wed Jun 27 21:36:39 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 27 Jun 2007 14:36:39 -0700 (PDT) Subject: koji and dependency management In-Reply-To: Alexandre Oliva's message of Wednesday, 27 June 2007 18:12:08 -0300 Message-ID: <20070627213639.A3B654D05E6@magilla.localdomain> > On Jun 27, 2007, Josh Boyer wrote: > > > You need to email rel-eng to get it pulled into the f-7 build root > > temporarily. The buildroot is only updated from F-7 + updates. > > Is there any reason that makes it impossible for koji to accept say a > list of additional packages to be installed in the buildroot along > with any other build dependencies? That's not really different from picking your own private build tag, adding your chosen packages to it, and building against that instead of the standard tag. It's not really a technical issue, it's a policy one. rel-eng involvement makes sure there is some positive administrative knowledge (not just silent koji db build records) of what goes into update builds. If policy wants to permit it for all-in-the-same-update cases, then it seems like a feature to make a temporary build tag built into something similar to chain-build would not be too hard. From jkeating at redhat.com Thu Jun 28 00:40:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Jun 2007 20:40:56 -0400 Subject: koji and dependency management In-Reply-To: References: <13dbfe4f0706270344t5a6c8fd3jbf00e67ae887122d@mail.gmail.com> <1182945630.23154.5.camel@vader.jdub.homelinux.org> Message-ID: <200706272040.56277.jkeating@redhat.com> On Wednesday 27 June 2007 17:12:08 Alexandre Oliva wrote: > Is there any reason that makes it impossible for koji to accept say a > list of additional packages to be installed in the buildroot along > with any other build dependencies? Currently Koji does not have the concept of per-build repodata + chroots. The repodata is generated at a tag level, and thus buildroots for that tag are all the same. That said, it may be worth the work to add the concept of per build repodata, especially once some of the other createrepo things land and we start perhaps having repodata generated in the packages///// dirs right after each build. It's a time and priority thing. Patches happily reviewed (: -- 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 mszpak at wp.pl Thu Jun 28 18:45:31 2007 From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=) Date: Thu, 28 Jun 2007 20:45:31 +0200 Subject: Update policy in F7 (Was: Re: Package EVR problems in Fedora 2007-06-22) In-Reply-To: <1182685528.2720.24.camel@aglarond.local> References: <20070622090032.0855C152134@buildsys.fedoraproject.org> <467C355A.40902@wp.pl> <200706241324.15196.ville.skytta@iki.fi> <1182685528.2720.24.camel@aglarond.local> Message-ID: <468401CB.1010600@wp.pl> On 2007-06-24 13:45:28 +0200, Jeremy Katz wrote: > On Sun, 2007-06-24 at 13:24 +0300, Ville Skytt? wrote: >> On Friday 22 June 2007, Marcin Zaj?czkowski wrote: >>> So, I have a few questions. >>> 1. Is there some wiki page with update policy in F7 (especially for >>> those former FE)? >>> 2. Who decides which packages will be pushed to "tests stage"? >>> 3. Should a packager suggest (somehow) if (s)he thinks that specified >>> package version should be worth pushing to the end user? >> There's at least >> http://fedoraproject.org/wiki/JeremyKatz/DraftHowToUpdateYourFedoraPackage > > Yep -- should hopefully be getting finalized, edited up, etc this week > too. I saw an announce. Thanks. http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo Marcin From opensource at till.name Thu Jun 28 21:45:20 2007 From: opensource at till.name (Till Maas) Date: Thu, 28 Jun 2007 23:45:20 +0200 Subject: cvs configuration filename change Message-ID: <200706282345.22232.opensource@till.name> Hiyas, after using "make i386" after a long time, I noticed that the config file for the Fedora Makefiles has beed renamed from .cvsextrasrc to .cvspkgsrc. Was this announced anywhere? Was this documented anywhere? I cannot find anything about it in the wiki. Why did not only be the new config file (.cvspkgsrc) and the old one still be used but an warning be printed when one uses it? Please document and announce major changes like this. Regards, Till From qspencer at ieee.org Fri Jun 29 02:26:36 2007 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 28 Jun 2007 21:26:36 -0500 Subject: Package name change Message-ID: <46846DDC.5040709@ieee.org> I know this has been asked before, but given all of the recent changes in procedures I thought I should ask again. What is the appropriate procedure for dealing with package name changes? I think there's something in the wiki about labeling the old CVS as dead, but what about the procedure for creating a new CVS? Quentin From tibbs at math.uh.edu Fri Jun 29 02:30:46 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Jun 2007 21:30:46 -0500 Subject: Package name change In-Reply-To: <46846DDC.5040709@ieee.org> References: <46846DDC.5040709@ieee.org> Message-ID: >>>>> "QS" == Quentin Spencer writes: QS> I think there's something in the wiki about labeling the old CVS QS> as dead, but what about the procedure for creating a new CVS? As for all CVS requests, you should follow http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure - J< From opensource at till.name Fri Jun 29 13:53:49 2007 From: opensource at till.name (Till Maas) Date: Fri, 29 Jun 2007 15:53:49 +0200 Subject: Bodhi internal server error Message-ID: <200706291553.51393.opensource@till.name> Aloas, when I try to create a new update for aircrack-ng, there is only an internal server error. Maybe someone can fix this. Regards, Till From mmcgrath at redhat.com Fri Jun 29 15:02:22 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 29 Jun 2007 10:02:22 -0500 Subject: Bodhi internal server error In-Reply-To: <200706291553.51393.opensource@till.name> References: <200706291553.51393.opensource@till.name> Message-ID: <46851EFE.60902@redhat.com> Till Maas wrote: > Aloas, > > when I try to create a new update for aircrack-ng, there is only an internal > server error. Maybe someone can fix this. > When you guys get errors like this (anything thats on a web page) can you include a URL? -Mike From opensource at till.name Fri Jun 29 15:13:09 2007 From: opensource at till.name (Till Maas) Date: Fri, 29 Jun 2007 17:13:09 +0200 Subject: Bodhi internal server error In-Reply-To: <46851EFE.60902@redhat.com> References: <200706291553.51393.opensource@till.name> <46851EFE.60902@redhat.com> Message-ID: <200706291713.10978.opensource@till.name> On Fr Juni 29 2007, Mike McGrath wrote: > When you guys get errors like this (anything thats on a web page) can > you include a URL? The URL is: https://admin.fedoraproject.org/updates/save From lmacken at redhat.com Fri Jun 29 16:01:08 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 29 Jun 2007 12:01:08 -0400 Subject: Bodhi internal server error In-Reply-To: <200706291553.51393.opensource@till.name> References: <200706291553.51393.opensource@till.name> Message-ID: <20070629160108.GG2703@tomservo.rochester.rr.com> On Fri, Jun 29, 2007 at 03:53:49PM +0200, Till Maas wrote: > Aloas, > > when I try to create a new update for aircrack-ng, there is only an internal > server error. Maybe someone can fix this. Yay, another UnicodeDecodeError :) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 231: ordinal not in range(128) So it looks like it is choking on a character in the notes [bodhi.controllers] DEBUG 2007-06-29 08:12:47,343 save(Fedora 7, , , None, {'notes': u'Update to a new version with several bugfixes.\r\n\r\nUpstream changelog:\r\nairodump-ng: wlan-ng driver now works again.\r\nairodump-ng: Fixed IP address when writing to CSV file\r\nairodump-ng: Fixed debian bug #417388: it doesn\u2019t restore terminal after error\r\naircrack-ng: Fixed WPA cracking on SMP computers\r\naircrack-ng: Fixed bug in calc_pmk() function causes wrong PMK to be computed\r\nairmon-ng: Fixed madwifi-ng wifiX detection (due to translation in ifconfig)\r\npatches: Added ACX injection patch\r\npatches: Updated rtl8187 patch for 2.6.21\r\n', 'type': u'bugfix', 'nvr': {'text': u'aircrack-ng-0.9.1-1.fc7', 'hidden': u'aircrack-ng-0.9.1-1.fc7'}}) I'd guess that this is causing it: bug #417388: it doesn\u2019t restore terminal after error For now, try changing that line and see what happens. I'll look into it further. Thanks, luke (ps, thanks for the patches btw :) From opensource at till.name Fri Jun 29 18:45:34 2007 From: opensource at till.name (Till Maas) Date: Fri, 29 Jun 2007 20:45:34 +0200 Subject: Bodhi internal server error In-Reply-To: <20070629160108.GG2703@tomservo.rochester.rr.com> References: <200706291553.51393.opensource@till.name> <20070629160108.GG2703@tomservo.rochester.rr.com> Message-ID: <200706292045.35527.opensource@till.name> On Fr Juni 29 2007, Luke Macken wrote: > I'd guess that this is causing it: > > bug #417388: it doesn\u2019t restore terminal after error > > For now, try changing that line and see what happens. I'll look into > it further. I changed the unicode character to a normal apostroph and this worked, thanks, Till From packages at amiga-hardware.com Sat Jun 30 18:24:30 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Sat, 30 Jun 2007 19:24:30 +0100 Subject: Koji failed build Message-ID: <46869FDE.1080908@amiga-hardware.com> Hi, I've queued a package in koji for building (cegui) but it fails almost immediately with the error "cannot build SRPM". I'm probably being stupid but how I do view the buildlogs to find out why? -- Ian Chapman. From jkeating at redhat.com Sat Jun 30 18:51:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 30 Jun 2007 14:51:28 -0400 Subject: Koji failed build In-Reply-To: <46869FDE.1080908@amiga-hardware.com> References: <46869FDE.1080908@amiga-hardware.com> Message-ID: <200706301451.28951.jkeating@redhat.com> On Saturday 30 June 2007 14:24:30 Ian Chapman wrote: > I've queued a package in koji for building (cegui) but it fails almost > immediately with the error "cannot build SRPM". I'm probably being > stupid but how I do view the buildlogs to find out why? Lets start with posting the output you get on the cli and work from 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 Jun 30 19:36:43 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 30 Jun 2007 21:36:43 +0200 Subject: Koji failed build In-Reply-To: <46869FDE.1080908@amiga-hardware.com> References: <46869FDE.1080908@amiga-hardware.com> Message-ID: <20070630213643.695abb21.bugs.michael@gmx.net> On Sat, 30 Jun 2007 19:24:30 +0100, Ian Chapman wrote: > Hi, > > I've queued a package in koji for building (cegui) but it fails almost > immediately with the error "cannot build SRPM". I'm probably being > stupid but how I do view the buildlogs to find out why? Traverse your build job results via the koji web page: http://koji.fedoraproject.org/koji/getfile?taskID=52981&name=srpm.log From packages at amiga-hardware.com Sat Jun 30 21:20:36 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Sat, 30 Jun 2007 22:20:36 +0100 Subject: Koji failed build In-Reply-To: <20070630213643.695abb21.bugs.michael@gmx.net> References: <46869FDE.1080908@amiga-hardware.com> <20070630213643.695abb21.bugs.michael@gmx.net> Message-ID: <4686C924.5090309@amiga-hardware.com> Michael Schwendt wrote: > > Traverse your build job results via the koji web page: > http://koji.fedoraproject.org/koji/getfile?taskID=52981&name=srpm.log Thanks for that. I'd stupidly forgotten to cvs add a patch file :) -- Ian Chapman.