From seg at haxxed.com Sun Jul 1 03:12:39 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 30 Jun 2007 22:12:39 -0500 Subject: No liblrdf-devel on ppc64 Message-ID: <1183259559.22027.6.camel@localhost> So rosegarden4 is failing to build because there's no liblrdf-devel on ppc64. I'm a bit lost with all this new fangled Koji stuff. Is there a reason its not available? Can someone build it for ppc64 please? Is there some way I can do it? http://koji.fedoraproject.org/koji/getfile?taskID=53173&name=root.log -------------- 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 Sun Jul 1 12:14:36 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 01 Jul 2007 13:14:36 +0100 Subject: No liblrdf-devel on ppc64 In-Reply-To: <1183259559.22027.6.camel@localhost> References: <1183259559.22027.6.camel@localhost> Message-ID: <1183292078.2828.20.camel@shinybook.infradead.org> On Sat, 2007-06-30 at 22:12 -0500, Callum Lerwick wrote: > So rosegarden4 is failing to build because there's no liblrdf-devel on > ppc64. I'm a bit lost with all this new fangled Koji stuff. Is there a > reason its not available? If a package is ever absent on any architecture, there should be a bug filed and blocking the corresponding FE-ExcludeArch-$ARCH bug. https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-ExcludeArch-ppc64&hide_resolved=1 If you don't find it in there, LART the maintainer. -- dwmw2 From fedora at leemhuis.info Sun Jul 1 15:15:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Jul 2007 17:15:24 +0200 Subject: EPEL report week 26, 2007 Message-ID: <4687C50C.8040902@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week26 = Weekly EPEL Summary = Week 26/2007 == Most important happenings == * Jeff Sheltren is new Steering Committee member (he replaces Axel Thimm, who left some weeks ago). Welcome Jeff! * wiki docs will be ready and reviewed soon; @everyone: everything fine with the docs? anything missing? * things that need do be done before EPEL announcement: fix broken deps, final repo layout, check if everything is okay == EPEL SIG Meeting == === Attending === >From the Steering Committee: * Jeff_S (Jeff Sheltren) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * quiad (KarstenWade) Missing from the Steering Committee: * dgilmore (DennisGilmore) * stahnma (MichaelStahnke) Others that participated the meeting: notting, rdieter, f13, _blah_ === Summary === * bodhi/testing repo/final repo layout ? nirik/lmacken * the plan is to move on using plague and the extras push scripts for the near future; koji plus bodhi later (hopefully soon; needs koji improvements that need to be written) * we move the current repo down one level (hardlinking the files, to make mirrors happy) into a subdirectory "stable" to leave room on the server for other EPEL in the future (that might happen or not). * we freeze the current repo and make the testing repo the default target for now and hand-move packages over to the stable repo when needed manually (information flow: via wiki) ? e.g. new packages that were in testing for some days as well as important bugfixes (security, hard crashers, ...) * finish the wiki docs and remove the warnings by end of may ? quaid * quaid and Jess_S are working on it; seems to be in the final stages * unresolved deps / packages missing in owners.epel.list * we should solve the broken deps soon (needed before announcement); * nirik will poke maintainers (help from SIG members would likely be appreciated); * mmcgrath will try to set up the broken deps checker script somewhere that spmas maintainers and the list in case of broken deps * should we try to bug c4chris, so he runs his package status script for epel as well? * vacant seat in the steering committee * Jeff_S was elected by the Steering Committee members to fill Axel's seat * Free discussion around EPEL * _blah_> "i've requested a few packages from fedora maintainers that have not gotten back to me... what is the next step in getting those packages into epel?"; knurd mailed the Fedora list about this; see https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02614.html; revisit next week * notting> "do we want a separate excludearch tracker for epel, or piggyback on the fedora one?" -> moved to the list, revisit next week * f13> "has there been any progress on the RHX issue?" - quaid is supposed to do some looking into it IIRC === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-July/msg00000.html == Stats == === General === Number of EPEL Contributors 101 We welcome 3 new contributors: mcepl_AT_redhat.com, qspencer_AT_ieee.org, skvidal_AT_linux.duke.edu === EPEL 5 === Number of source packages: 405 Number of binary packages: 736 There are 12 new Packages: * bzr | Friendly distributed version control system * cvs2svn | CVS to Subversion Repository Converter * glpk | GNU Linear Programming Kit * itcl | Object oriented extensions to Tcl and Tk * python-dateutil | Powerful extensions to the standard datetime module * python-feedparser | Parse RSS and Atom feeds in Python * python-matplotlib | Python plotting library * python-memcached | A Python memcached client library * python-paramiko | A SSH2 protocol library for python * pytz | World Timezone Definitions for Python * re2c | Tool for generating C-based recognizers from regular expressions * yum-utils | Utilities based around the yum package manager === EPEL 4 === Number of source packages: 252 Number of binary packages: 529 There are 4 new Packages: * cvs2svn | CVS to Subversion Repository Converter * itcl | Object oriented extensions to Tcl and Tk * python-feedparser | Parse RSS and Atom feeds in Python * re2c | Tool for generating C-based recognizers from regular expressions ---- ["CategoryEPELReports"] From skvidal at fedoraproject.org Mon Jul 2 06:09:36 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 02 Jul 2007 02:09:36 -0400 Subject: patch for makefile.common Message-ID: <1183356576.15032.21.camel@cutter> in make mockbuild right now we are automatically appending a -core to the mock root string even though we don't have that for 7 anymore. The attached patch fixes it - I'm not sure who can apply it, though :) -sv -------------- next part -------------- A non-text attachment was scrubbed... Name: makefile.common-no-core-mockbuild.patch Type: text/x-patch Size: 983 bytes Desc: not available URL: From dennis at ausil.us Mon Jul 2 13:01:59 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 2 Jul 2007 08:01:59 -0500 Subject: patch for makefile.common In-Reply-To: <1183356576.15032.21.camel@cutter> References: <1183356576.15032.21.camel@cutter> Message-ID: <200707020802.04694.dennis@ausil.us> Once upon a time Monday 02 July 2007, seth vidal wrote: > in make mockbuild right now we are automatically appending a -core to > the mock root string even though we don't have that for 7 anymore. > > The attached patch fixes it - I'm not sure who can apply it, though :) > > -sv Looks sane to me, i applied it. i also enabled doing make builds for all the archs we have listed and adding niagara archs Dennis -------------- 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 gilboad at gmail.com Mon Jul 2 15:44:59 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 02 Jul 2007 18:44:59 +0300 Subject: Gash stuck @update-testing? Message-ID: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> Hello all, Does anyone have any idea why gnash/0.8 is stuck in updates-testing instead of being pushed down-stream? Bodhi problem or sleepy maintainer? - Gilboa From gilboad at gmail.com Mon Jul 2 15:49:44 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 02 Jul 2007 18:49:44 +0300 Subject: update-testing? [WAS: Gnash stuck @update-testing?] In-Reply-To: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> Message-ID: <1183391384.16578.30.camel@gilboa-work-dev.localdomain> On Mon, 2007-07-02 at 18:45 +0300, Gilboa Davara wrote: > Hello all, > > Does anyone have any idea why gnash/0.8 is stuck in updates-testing > instead of being pushed down-stream? > Bodhi problem or sleepy maintainer? > > - Gilboa ... OK, there is a large number of >= two weeks old packages sitting in updates-testing. I assume that the powers-to-be are aware of this problem, right? - Gilboa From jkeating at redhat.com Mon Jul 2 15:49:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 11:49:08 -0400 Subject: update-testing? [WAS: Gnash stuck @update-testing?] In-Reply-To: <1183391384.16578.30.camel@gilboa-work-dev.localdomain> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <1183391384.16578.30.camel@gilboa-work-dev.localdomain> Message-ID: <200707021149.09152.jkeating@redhat.com> On Monday 02 July 2007 11:49:44 Gilboa Davara wrote: > ... OK, there is a large number of >= two weeks old packages sitting in > updates-testing. > I assume that the powers-to-be are aware of this problem, right? As of yet there is no auto-promotion of updates. It's up to the maintainer who requested the updates go back and mark said potential updates as stable to be pushed out to the final 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 rc040203 at freenet.de Mon Jul 2 15:54:03 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 02 Jul 2007 17:54:03 +0200 Subject: update-testing? [WAS: Gnash stuck @update-testing?] In-Reply-To: <200707021149.09152.jkeating@redhat.com> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <1183391384.16578.30.camel@gilboa-work-dev.localdomain> <200707021149.09152.jkeating@redhat.com> Message-ID: <1183391643.23976.307.camel@mccallum.corsepiu.local> On Mon, 2007-07-02 at 11:49 -0400, Jesse Keating wrote: > On Monday 02 July 2007 11:49:44 Gilboa Davara wrote: > > ... OK, there is a large number of >= two weeks old packages sitting in > > updates-testing. > > I assume that the powers-to-be are aware of this problem, right? > > As of yet there is no auto-promotion of updates. It's up to the maintainer > who requested the updates go back and mark said potential updates as stable > to be pushed out to the final updates. Where to find a howto documenting this? Ralf From coldwell at redhat.com Mon Jul 2 15:56:30 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Mon, 2 Jul 2007 11:56:30 -0400 (EDT) Subject: update-testing? [WAS: Gnash stuck @update-testing?] In-Reply-To: <1183391643.23976.307.camel@mccallum.corsepiu.local> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <1183391384.16578.30.camel@gilboa-work-dev.localdomain> <200707021149.09152.jkeating@redhat.com> <1183391643.23976.307.camel@mccallum.corsepiu.local> Message-ID: On Mon, 2 Jul 2007, Ralf Corsepius wrote: > On Mon, 2007-07-02 at 11:49 -0400, Jesse Keating wrote: > > On Monday 02 July 2007 11:49:44 Gilboa Davara wrote: > > > ... OK, there is a large number of >= two weeks old packages sitting in > > > updates-testing. > > > I assume that the powers-to-be are aware of this problem, right? > > > > As of yet there is no auto-promotion of updates. It's up to the maintainer > > who requested the updates go back and mark said potential updates as stable > > to be pushed out to the final updates. > > Where to find a howto documenting this? http://fedoraproject.org/wiki/JeremyKatz/DraftHowToUpdateYourFedoraPackage Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From jkeating at redhat.com Mon Jul 2 15:59:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 11:59:09 -0400 Subject: update-testing? [WAS: Gnash stuck @update-testing?] In-Reply-To: <1183391643.23976.307.camel@mccallum.corsepiu.local> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <200707021149.09152.jkeating@redhat.com> <1183391643.23976.307.camel@mccallum.corsepiu.local> Message-ID: <200707021159.09474.jkeating@redhat.com> On Monday 02 July 2007 11:54:03 Ralf Corsepius wrote: > Where to find a howto documenting this? http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo As announced on fedora-devel-announce June 26th -- 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 Mon Jul 2 16:23:03 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 02 Jul 2007 18:23:03 +0200 Subject: update-testing? [WAS: Gnash stuck @update-testing?] In-Reply-To: References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <1183391384.16578.30.camel@gilboa-work-dev.localdomain> <200707021149.09152.jkeating@redhat.com> <1183391643.23976.307.camel@mccallum.corsepiu.local> Message-ID: <1183393383.23976.312.camel@mccallum.corsepiu.local> On Mon, 2007-07-02 at 11:56 -0400, Chip Coldwell wrote: > On Mon, 2 Jul 2007, Ralf Corsepius wrote: > > > On Mon, 2007-07-02 at 11:49 -0400, Jesse Keating wrote: > > > On Monday 02 July 2007 11:49:44 Gilboa Davara wrote: > > > > ... OK, there is a large number of >= two weeks old packages sitting in > > > > updates-testing. > > > > I assume that the powers-to-be are aware of this problem, right? > > > > > > As of yet there is no auto-promotion of updates. It's up to the maintainer > > > who requested the updates go back and mark said potential updates as stable > > > to be pushed out to the final updates. > > > > Where to find a howto documenting this? > > http://fedoraproject.org/wiki/JeremyKatz/DraftHowToUpdateYourFedoraPackage Returns: Diese Seite gibt es noch nicht. ... [This page doesn't exist yet.] Ralf From grenier at cgsecurity.org Mon Jul 2 16:30:33 2007 From: grenier at cgsecurity.org (Christophe GRENIER) Date: Mon, 2 Jul 2007 18:30:33 +0200 (CEST) Subject: update-testing? [WAS: Gnash stuck @update-testing?] In-Reply-To: <1183393383.23976.312.camel@mccallum.corsepiu.local> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <1183391384.16578.30.camel@gilboa-work-dev.localdomain> <200707021149.09152.jkeating@redhat.com> <1183391643.23976.307.camel@mccallum.corsepiu.local> <1183393383.23976.312.camel@mccallum.corsepiu.local> Message-ID: On Mon, 2 Jul 2007, Ralf Corsepius wrote: > ... >>>> As of yet there is no auto-promotion of updates. It's up to the maintainer >>>> who requested the updates go back and mark said potential updates as stable >>>> to be pushed out to the final updates. >>> >>> Where to find a howto documenting this? >> >> http://fedoraproject.org/wiki/JeremyKatz/DraftHowToUpdateYourFedoraPackage > > Returns: > ... > [This page doesn't exist yet.] This draft has been adopted, use this link instead http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo Regards, Christophe -- ,-~~-.___. ._. / | ' \ | |"""""""""| Christophe GRENIER ( ) 0 | | | grenier at cgsecurity.org \_/-, ,----' | | | ==== !_!--v---v--" / \-'~; |""""""""| TestDisk & PhotoRec / __/~| ._-""|| | Data Recovery =( _____|_|____||________| http://www.cgsecurity.org From limb at jcomserv.net Mon Jul 2 17:23:21 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 2 Jul 2007 12:23:21 -0500 (CDT) Subject: [Fwd: Broken dependencies in Fedora 7 + Test Updates - 2007-06-21] In-Reply-To: <200706271117.12052.jkeating@redhat.com> References: <4108.192.168.0.1.1182462996.squirrel@mail.jcomserv.net> <20070622104549.d57fe3cd.bugs.michael@gmx.net> <46827D18.90502@hhs.nl> <200706271117.12052.jkeating@redhat.com> Message-ID: <36126.65.192.24.164.1183397001.squirrel@mail.jcomserv.net> > 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. Well, since I have, I'll probably take Hans's suggestion, since it allows me to build for devel, then current, then current-1, etc, the Way God Intended(tm). :) For future reference, if I wanted to do this the disttagless way in the future, how does inheritance "work"? Let's say I build for F-7 and it has no disttag. What do I do to get it into F-8? This still doesn't solve the FC-6 problem, either, though I imagine that goes away when FC-6 moves to Koji. Thanks all! > -- > Jesse Keating > Release Engineer: Fedora > -- > 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 Mon Jul 2 17:45:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 13:45:38 -0400 Subject: [Fwd: Broken dependencies in Fedora 7 + Test Updates - 2007-06-21] In-Reply-To: <36126.65.192.24.164.1183397001.squirrel@mail.jcomserv.net> References: <4108.192.168.0.1.1182462996.squirrel@mail.jcomserv.net> <200706271117.12052.jkeating@redhat.com> <36126.65.192.24.164.1183397001.squirrel@mail.jcomserv.net> Message-ID: <200707021345.38943.jkeating@redhat.com> On Monday 02 July 2007 13:23:21 Jon Ciesla wrote: > For future reference, if I wanted to do this the disttagless way in the > future, how does inheritance "work"? ?Let's say I build for F-7 and it has > no disttag. ?What do I do to get it into F-8? ?This still doesn't solve > the FC-6 problem, either, though I imagine that goes away when FC-6 moves > to Koji. > > Thanks all! "disttag" has nothing to do with it. Basically koji has the concept of inheritance. When we create a new distribution tag, say dist-f8, we configure it to inherit from the previous distro's updates, ie dist-fc7-updates. dist-fc7-updates inherits from dist-fc7, which in theory inherits from dist-fc6-updates, and so on. If you did an update and it was pushed stable (and thus tagged for dist-fc7-updates), then getting a listing of what's "in" dist-f8 would show that build, provided that no builds of said package were tagged for dist-f8. This is how we "bootstrap" new collections and take advantage of already done QA work. Our compose tools will ask koji for all the 'latest' packages that can be seen via a given tag. Inheritance is followed. How "latest" is determined is: Look at the tag, are there any builds of that are specifically tagged for dist-f8, if so, use the one that most recently got the tag. If not, look at priority 1 inheritance and ask the same question, go until you find a 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 limb at jcomserv.net Mon Jul 2 17:57:33 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 2 Jul 2007 12:57:33 -0500 (CDT) Subject: [Fwd: Broken dependencies in Fedora 7 + Test Updates - 2007-06-21] In-Reply-To: <200707021345.38943.jkeating@redhat.com> References: <4108.192.168.0.1.1182462996.squirrel@mail.jcomserv.net> <200706271117.12052.jkeating@redhat.com> <36126.65.192.24.164.1183397001.squirrel@mail.jcomserv.net> <200707021345.38943.jkeating@redhat.com> Message-ID: <3206.65.192.24.164.1183399053.squirrel@mail.jcomserv.net> > > "disttag" has nothing to do with it. Basically koji has the concept of > inheritance. When we create a new distribution tag, say dist-f8, we > configure it to inherit from the previous distro's updates, ie > dist-fc7-updates. dist-fc7-updates inherits from dist-fc7, which in > theory > inherits from dist-fc6-updates, and so on. > > If you did an update and it was pushed stable (and thus tagged for > dist-fc7-updates), then getting a listing of what's "in" dist-f8 would > show > that build, provided that no builds of said package were tagged for > dist-f8. > This is how we "bootstrap" new collections and take advantage of already > done > QA work. > > Our compose tools will ask koji for all the 'latest' packages that can be > seen > via a given tag. Inheritance is followed. How "latest" is determined is: > > Look at the tag, are there any builds of that are specifically > tagged > for dist-f8, if so, use the one that most recently got the tag. If not, > look > at priority 1 inheritance and ask the same question, go until you find a > build. So IIUTC, if I build for F-7, it will be included in the F-8 yum repos as well, if nothing with that EVR exists there already? > -- > Jesse Keating > Release Engineer: Fedora > -- > 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 Mon Jul 2 18:09:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 14:09:21 -0400 Subject: [Fwd: Broken dependencies in Fedora 7 + Test Updates - 2007-06-21] In-Reply-To: <3206.65.192.24.164.1183399053.squirrel@mail.jcomserv.net> References: <4108.192.168.0.1.1182462996.squirrel@mail.jcomserv.net> <200707021345.38943.jkeating@redhat.com> <3206.65.192.24.164.1183399053.squirrel@mail.jcomserv.net> Message-ID: <200707021409.21940.jkeating@redhat.com> On Monday 02 July 2007 13:57:33 Jon Ciesla wrote: > So IIUTC, if I build for F-7, it will be included in the F-8 yum repos as > well, if nothing with that EVR exists there already? If no build of that package has been specifically tagged with dist-f8 (which would happen if you built from the devel/ branch), yes, inheritance would pick up the build tagged with dist-fc7-updates and it would show up in the next rawhide compose (which asks for the newest builds of every package that exists). -- 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 limb at jcomserv.net Mon Jul 2 18:06:03 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 2 Jul 2007 13:06:03 -0500 (CDT) Subject: [Fwd: Broken dependencies in Fedora 7 + Test Updates - 2007-06-21] In-Reply-To: <200707021409.21940.jkeating@redhat.com> References: <4108.192.168.0.1.1182462996.squirrel@mail.jcomserv.net> <200707021345.38943.jkeating@redhat.com> <3206.65.192.24.164.1183399053.squirrel@mail.jcomserv.net> <200707021409.21940.jkeating@redhat.com> Message-ID: <11643.65.192.24.164.1183399563.squirrel@mail.jcomserv.net> > On Monday 02 July 2007 13:57:33 Jon Ciesla wrote: >> So IIUTC, if I build for F-7, it will be included in the F-8 yum repos >> as >> well, if nothing with that EVR exists there already? > > If no build of that package has been specifically tagged with dist-f8 > (which > would happen if you built from the devel/ branch), yes, inheritance would > pick up the build tagged with dist-fc7-updates and it would show up in the > next rawhide compose (which asks for the newest builds of every package > that > exists). And this would apply between non-rahwide releases N and N-1, where both are on koji, i.e. F-7 and F-8 before F-7 EOLs and after F-8 is released? > -- > Jesse Keating > Release Engineer: Fedora > -- > 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 Mon Jul 2 18:15:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 14:15:34 -0400 Subject: [Fwd: Broken dependencies in Fedora 7 + Test Updates - 2007-06-21] In-Reply-To: <11643.65.192.24.164.1183399563.squirrel@mail.jcomserv.net> References: <4108.192.168.0.1.1182462996.squirrel@mail.jcomserv.net> <200707021409.21940.jkeating@redhat.com> <11643.65.192.24.164.1183399563.squirrel@mail.jcomserv.net> Message-ID: <200707021415.34856.jkeating@redhat.com> On Monday 02 July 2007 14:06:03 Jon Ciesla wrote: > And this would apply between non-rahwide releases N and N-1, where both > are on koji, i.e. F-7 and F-8 before F-7 EOLs and after F-8 is released? They would be available to request as updates. If you pushed an update for Fedora 7, it would be available to request as an update for Fedora 8 as well. The same physical package would be used, but a separate mail would go out and it would be placed in the repodata for Fedora 8 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 notting at redhat.com Mon Jul 2 21:14:48 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 2 Jul 2007 17:14:48 -0400 Subject: orphan/retire package: g-wrap In-Reply-To: <20070625191803.GB14914@nostromo.devel.redhat.com> References: <20070625191803.GB14914@nostromo.devel.redhat.com> Message-ID: <20070702211448.GB27174@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > I'd suggest just removing it from devel and marking it dead. ... now done. Bill From davej at redhat.com Tue Jul 3 04:32:09 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 00:32:09 -0400 Subject: Fedora Core 5 Retirement In-Reply-To: <468938DB.5080103@redhat.com> References: <468938DB.5080103@redhat.com> Message-ID: <20070703043209.GA15866@redhat.com> On Mon, Jul 02, 2007 at 01:41:47PM -0400, Warren Togami wrote: > As of Monday, July 2nd 2007, Fedora Core 5 has gone into retirement. No > further updates will be issued for FC5 or FE5 as we refocus our > developer attention to development of F8 and maintenance of our most > recent stable Fedora 7. > > The Fedora Project now runs on a N+2 + 1 month support schedule. This > means the supported lifetime of FC5 was scheduled to end one month after > the release of F7. FC5 was supported from March 20th 2006 through July > 2nd 2007, or a good ~15.5 months. > > http://fedoraproject.org/wiki/Releases/8/Schedule > By the current Fedora 8 development schedule, the supported lifetime of > FC6 is to continue to a minimum of early December 2007. In the past, what happens to the still-open bugs against an EOL'd release has been decided by the individual package owner. I've seen.. * Move all bugs to currently open release * Move all bugs to rawhide * Close bugs WONTFIX * "please upgrade" msg, NEEDINFO, wait a while, ->WONTFIX * Nothing, bugs left open, users left unaware that no fix is coming. all used as potential strategies for dealing with this, but it would be good to have a unified message. It would also probably be much faster for bugzilla admins to run some SQL query than each developer doing this by hand (last time I did it for the kernel, it took several hours for the 'change multiple bugs' thing to finish, with firefox actually timing out a few times). Dave -- http://www.codemonkey.org.uk From poelstra at redhat.com Tue Jul 3 05:40:05 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 02 Jul 2007 22:40:05 -0700 Subject: Fedora Core 5 Retirement In-Reply-To: <20070703043209.GA15866@redhat.com> References: <468938DB.5080103@redhat.com> <20070703043209.GA15866@redhat.com> Message-ID: <4689E135.9050300@redhat.com> Dave Jones said the following on 07/02/2007 09:32 PM Pacific Time: > On Mon, Jul 02, 2007 at 01:41:47PM -0400, Warren Togami wrote: > > As of Monday, July 2nd 2007, Fedora Core 5 has gone into retirement. No > > further updates will be issued for FC5 or FE5 as we refocus our > > developer attention to development of F8 and maintenance of our most > > recent stable Fedora 7. > > > > The Fedora Project now runs on a N+2 + 1 month support schedule. This > > means the supported lifetime of FC5 was scheduled to end one month after > > the release of F7. FC5 was supported from March 20th 2006 through July > > 2nd 2007, or a good ~15.5 months. > > > > http://fedoraproject.org/wiki/Releases/8/Schedule > > By the current Fedora 8 development schedule, the supported lifetime of > > FC6 is to continue to a minimum of early December 2007. > > In the past, what happens to the still-open bugs against an EOL'd > release has been decided by the individual package owner. > I've seen.. > > * Move all bugs to currently open release > * Move all bugs to rawhide > * Close bugs WONTFIX > * "please upgrade" msg, NEEDINFO, wait a while, ->WONTFIX > * Nothing, bugs left open, users left unaware that no fix is coming. > > all used as potential strategies for dealing with this, but it > would be good to have a unified message. It would also probably > be much faster for bugzilla admins to run some SQL query than > each developer doing this by hand (last time I did it for the > kernel, it took several hours for the 'change multiple bugs' > thing to finish, with firefox actually timing out a few times). > > Dave > I would very strongly vote in favor of: "WONTFIX; please reopen this bug against F7 if it still exists there." >From one of the QA meetings a month or so back I took the action item to create a proposal for how to deal with bugzillas like this. I'll try to have something proposed on the wiki by the start of next week. John From fedora at leemhuis.info Tue Jul 3 06:08:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 03 Jul 2007 08:08:56 +0200 Subject: Fedora Core 5 Retirement In-Reply-To: <4689E135.9050300@redhat.com> References: <468938DB.5080103@redhat.com> <20070703043209.GA15866@redhat.com> <4689E135.9050300@redhat.com> Message-ID: <4689E7F8.2020901@leemhuis.info> On 03.07.2007 07:40, John Poelstra wrote: > I would very strongly vote in favor of: "WONTFIX; please reopen this > bug against F7 if it still exists there." > >> From one of the QA meetings a month or so back I took the action >> item to create a proposal for how to deal with bugzillas like this. >> I'll try to have something proposed on the wiki by the start of >> next week. John and FESCo/QA, when this has been decided can we please write that down properly somewhere in the wiki and make that a policy until there is a strong reasons to rediscuss the topic? My memory might fool me, but I think this discussion came up multiple times already in the past each time we retired a release. I tend to say that's wasted energy (?) as long as there is no good reason to rediscuss. CU thl (?) -- I think that is a general problem we more and more face; a issue get discussed and a solution is found to solve the issue now; with a bit of luck it gets documented properly in the wiki, but often it gets buried in meeting logs and forgotten. Some months later the same thing pops up again and gets discussed endlessly again.... From pertusus at free.fr Tue Jul 3 07:03:29 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 3 Jul 2007 09:03:29 +0200 Subject: Gash stuck @update-testing? In-Reply-To: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> Message-ID: <20070703070329.GC3206@free.fr> On Mon, Jul 02, 2007 at 06:44:59PM +0300, Gilboa Davara wrote: > Hello all, > > Does anyone have any idea why gnash/0.8 is stuck in updates-testing > instead of being pushed down-stream? > Bodhi problem or sleepy maintainer? Documentation problem. First I thought that gnash was already pushed since I remember receiving a mail that seemed to say so. Then I noticed that the package wasn't pushed. I read http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo and tried to do the last 2 points. I found the point 1. (return to bohdi) to be useless, since it leads to a page with Welcome, Patrice Dumas Bodhi workflow and Q&A draft BugsFile a bug or feature request Fedora Infrastructure Mugshot GroupJoin the Fedora Infrastructure Mugshot group but nothing about updates to be pushed. Even though the documentation was lacking I thought that I could search by myself the 'Push to final', but I never found out something like that. So I thought that I would wait to a more useful documentation before trying to push my packages. -- Pat From gilboad at gmail.com Tue Jul 3 09:51:39 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 03 Jul 2007 12:51:39 +0300 Subject: update-testing? [WAS: Gnash stuck @update-testing?] In-Reply-To: <200707021149.09152.jkeating@redhat.com> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <1183391384.16578.30.camel@gilboa-work-dev.localdomain> <200707021149.09152.jkeating@redhat.com> Message-ID: <1183456299.16241.8.camel@gilboa-work-dev.localdomain> On Mon, 2007-07-02 at 11:49 -0400, Jesse Keating wrote: > On Monday 02 July 2007 11:49:44 Gilboa Davara wrote: > > ... OK, there is a large number of >= two weeks old packages sitting in > > updates-testing. > > I assume that the powers-to-be are aware of this problem, right? > > As of yet there is no auto-promotion of updates. It's up to the maintainer > who requested the updates go back and mark said potential updates as stable > to be pushed out to the final updates. I don't like the idea of auto-promotion - but that's debatable. Sometimes packagers have a valid reason for not pushing their packages into mass circulation. ... But how about nagging the maintainer after ~7-14 days to push the package into testing? - Gilboa From buildsys at fedoraproject.org Tue Jul 3 09:52:41 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 3 Jul 2007 05:52:41 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-07-03 Message-ID: <20070703095241.E011D152131@buildsys.fedoraproject.org> andreas.bierfert AT lowlatency.de: koffice FE5 > FE6 (0:1.6.3-6.fc5.1 > 0:1.6.2-3.fc6.1) 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: libqalculate FE5 > FE6 (0:0.9.6-1.fc5 > 0:0.9.5-1.fc6) qalculate-gtk FE5 > FE6 (0:0.9.6-1.fc5 > 0:0.9.5-1.fc6) FE5 > F7 (0:0.9.6-1.fc5 > 0:0.9.5-1.fc7) ed AT eh3.com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE5 > FE6 (0:0.88.7-3.fc5 > 0:0.88.7-2.fc6) fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) 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) jakub AT redhat.com: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jeff AT ocjtech.us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) jjohnstn AT redhat.com: eclipse-cdt FC6-updates > F7 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) 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) luya_tfz AT thefinalzone.com: gdesklets FE6 > F7-updates (0:0.35.4-6.1.fc6 > 0:0.35.4-6.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) mfleming+rpm AT enlartenment.com: mod_security FE5 > F7 (0:2.1.1-1.fc5 > 0:2.1.0-3.fc7) FE6 > F7 (0:2.1.1-1.fc6 > 0:2.1.0-3.fc7) 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: smolt FE6 > F7 (0:0.9.8.3-1.fc6 > 0:0.9.8.1-1.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) 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) pmachata AT redhat.com: tzdata FC5-updates > F7 (0:2007f-1.fc5 > 0:2007e-1.fc7) FC6-updates > F7 (0:2007f-1.fc6 > 0:2007e-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) rdieter AT math.unl.edu: maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) rmeggins AT redhat.com: mozldap FE5 > F7 (0:6.0.4-1.fc5 > 0:6.0.3-1.fc7) FE6 > F7 (0:6.0.4-1.fc6 > 0:6.0.3-1.fc7) perl-Mozilla-LDAP FE5 > F7 (0:1.5.1-1.fc5 > 0:1.5-9.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.5-9.fc7) robert AT marcanoonline.com: eclipse-subclipse FE6 > F7 (0:1.2.2-2.fc6 > 0:1.1.9-2.fc7) rpm AT greysector.net: ekg FE5 > FE6 (0:1.7-1.fc5 > 0:1.7-0.3.rc2.fc6) 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: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) than AT redhat.com: kdemultimedia FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) ---------------------------------------------------------------------- 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) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE6 (0:0.88.7-3.fc5 > 0:0.88.7-2.fc6) eclipse-cdt: jjohnstn AT redhat.com FC6-updates > F7 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) eclipse-subclipse: robert AT marcanoonline.com FE6 > F7 (0:1.2.2-2.fc6 > 0:1.1.9-2.fc7) ekg: rpm AT greysector.net FE5 > FE6 (0:1.7-1.fc5 > 0:1.7-0.3.rc2.fc6) fedora-usermgmt: enrico.scholz AT informatik.tu-chemnitz.de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.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) 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) gcc: jakub AT redhat.com FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) gdesklets: luya_tfz AT thefinalzone.com FE6 > F7-updates (0:0.35.4-6.1.fc6 > 0:0.35.4-6.fc7) gtranslator: foolish AT guezz.net FE6 > F7 (0:1.1.7-3.fc6 > 0:1.1.7-2.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) jrtplib: jeff AT ocjtech.us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kdemultimedia: than AT redhat.com FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) koffice: andreas.bierfert AT lowlatency.de FE5 > FE6 (0:1.6.3-6.fc5.1 > 0:1.6.2-3.fc6.1) libqalculate: dakingun AT gmail.com FE5 > FE6 (0:0.9.6-1.fc5 > 0:0.9.5-1.fc6) 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) lostirc: splinux AT fedoraproject.org FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) maxima: rdieter AT math.unl.edu FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) 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) mod_security: mfleming+rpm AT enlartenment.com FE5 > F7 (0:2.1.1-1.fc5 > 0:2.1.0-3.fc7) FE6 > F7 (0:2.1.1-1.fc6 > 0:2.1.0-3.fc7) mozldap: rmeggins AT redhat.com FE5 > F7 (0:6.0.4-1.fc5 > 0:6.0.3-1.fc7) FE6 > F7 (0:6.0.4-1.fc6 > 0:6.0.3-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-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-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-Mozilla-LDAP: rmeggins AT redhat.com FE5 > F7 (0:1.5.1-1.fc5 > 0:1.5-9.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.5-9.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) python-cheetah: mikeb AT redhat.com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) qalculate-gtk: dakingun AT gmail.com FE5 > FE6 (0:0.9.6-1.fc5 > 0:0.9.5-1.fc6) FE5 > F7 (0:0.9.6-1.fc5 > 0:0.9.5-1.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) scrip: ed AT eh3.com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) smolt: mmcgrath AT redhat.com FE6 > F7 (0:0.9.8.3-1.fc6 > 0:0.9.8.1-1.fc7) tzdata: pmachata AT redhat.com FC5-updates > F7 (0:2007f-1.fc5 > 0:2007e-1.fc7) FC6-updates > F7 (0:2007f-1.fc6 > 0:2007e-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) 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 jkeating at redhat.com Tue Jul 3 10:55:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Jul 2007 06:55:39 -0400 Subject: update-testing? [WAS: Gnash stuck @update-testing?] In-Reply-To: <1183456299.16241.8.camel@gilboa-work-dev.localdomain> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <200707021149.09152.jkeating@redhat.com> <1183456299.16241.8.camel@gilboa-work-dev.localdomain> Message-ID: <200707030655.42559.jkeating@redhat.com> On Tuesday 03 July 2007 05:51:39 Gilboa Davara wrote: > ... But how about nagging the maintainer after ~7-14 days to push the > package into testing? That's on the feature request list. Luke may even already have it done in his development code. -- 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 Jul 3 10:57:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Jul 2007 06:57:24 -0400 Subject: Gash stuck @update-testing? In-Reply-To: <20070703070329.GC3206@free.fr> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <20070703070329.GC3206@free.fr> Message-ID: <200707030657.25053.jkeating@redhat.com> On Tuesday 03 July 2007 03:03:29 Patrice Dumas wrote: > On Mon, Jul 02, 2007 at 06:44:59PM +0300, Gilboa Davara wrote: > > Hello all, > > > > Does anyone have any idea why gnash/0.8 is stuck in updates-testing > > instead of being pushed down-stream? > > Bodhi problem or sleepy maintainer? > > Documentation problem. First I thought that gnash was already pushed > since I remember receiving a mail that seemed to say so. Then I noticed > that the package wasn't pushed. I read > http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo > and tried to do the last 2 points. > > I found the point 1. (return to bohdi) to be useless, since it leads to > a page with > > Welcome, Patrice Dumas > > Bodhi workflow and Q&A draft > BugsFile a bug or feature request > Fedora Infrastructure > Mugshot GroupJoin the Fedora Infrastructure Mugshot group > > but nothing about updates to be pushed. > > > Even though the documentation was lacking I thought that I could search > by myself the 'Push to final', but I never found out something like > that. > > So I thought that I would wait to a more useful documentation before > trying to push my packages. > Is this the first time you've given feedback on the documentation? If so, how were you expecting things to change if you didn't tell anybody you weren't happy? Would it make it more clear if you were directed to look to your left and click on the "My Updates" link, then the update in question you wish to manage? -- 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 Tue Jul 3 14:06:32 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 3 Jul 2007 16:06:32 +0200 Subject: Gash stuck @update-testing? In-Reply-To: <200707030657.25053.jkeating@redhat.com> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <20070703070329.GC3206@free.fr> <200707030657.25053.jkeating@redhat.com> Message-ID: <20070703140632.GB3057@free.fr> On Tue, Jul 03, 2007 at 06:57:24AM -0400, Jesse Keating wrote: > > Is this the first time you've given feedback on the documentation? If so, how > were you expecting things to change if you didn't tell anybody you weren't > happy? I am not expecting it to change, I was hoping that others would do the report, since I am not very familiar with web based interface and I don't know what should be left to the user to search or what should be specified. > Would it make it more clear if you were directed to look to your left > and click on the "My Updates" link, then the update in question you wish to > manage? Yes, it would be clearer to me. -- Pat From pertusus at free.fr Tue Jul 3 14:10:41 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 3 Jul 2007 16:10:41 +0200 Subject: Gash stuck @update-testing? In-Reply-To: <200707030657.25053.jkeating@redhat.com> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <20070703070329.GC3206@free.fr> <200707030657.25053.jkeating@redhat.com> Message-ID: <20070703141041.GC3057@free.fr> On Tue, Jul 03, 2007 at 06:57:24AM -0400, Jesse Keating wrote: > > Is this the first time you've given feedback on the documentation? If so, how > were you expecting things to change if you didn't tell anybody you weren't > happy? Also I am not unhappy, I am currently waiting for tools that are more easy for me to appear, and trying to interfere as less as possible with the web-based interface, but I don't blame anybody else if I cannot do something, what I did in the previous mail was reporting. And yes, I may not be reporting enough. -- Pat From pertusus at free.fr Tue Jul 3 14:13:53 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 3 Jul 2007 16:13:53 +0200 Subject: Gash stuck @update-testing? In-Reply-To: <200707030657.25053.jkeating@redhat.com> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <20070703070329.GC3206@free.fr> <200707030657.25053.jkeating@redhat.com> Message-ID: <20070703141353.GD3057@free.fr> On Tue, Jul 03, 2007 at 06:57:24AM -0400, Jesse Keating wrote: > > Is this the first time you've given feedback on the documentation? If so, how > were you expecting things to change if you didn't tell anybody you weren't > happy? Would it make it more clear if you were directed to look to your left > and click on the "My Updates" link, then the update in question you wish to > manage? Maybe in the point 2. it should be 'Mark as Stable' instead of 'Push to final'? I can make the change in the wiki (on point 1. and 2.) if you confirm it is 'Mark as Stable'. -- Pat From jkeating at redhat.com Tue Jul 3 14:24:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Jul 2007 10:24:53 -0400 Subject: Gash stuck @update-testing? In-Reply-To: <20070703141353.GD3057@free.fr> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <200707030657.25053.jkeating@redhat.com> <20070703141353.GD3057@free.fr> Message-ID: <200707031024.54210.jkeating@redhat.com> On Tuesday 03 July 2007 10:13:53 Patrice Dumas wrote: > Maybe in the point 2. it should be 'Mark as Stable' instead of > 'Push to final'? > > I can make the change in the wiki (on point 1. and 2.) if you confirm > it is 'Mark as Stable'. Yes, it is 'Mark as Stable'. Please feel free to update. -- 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 poelstra at redhat.com Tue Jul 3 17:15:32 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 03 Jul 2007 10:15:32 -0700 Subject: Fedora Core 5 Retirement In-Reply-To: <4689E7F8.2020901@leemhuis.info> References: <468938DB.5080103@redhat.com> <20070703043209.GA15866@redhat.com> <4689E135.9050300@redhat.com> <4689E7F8.2020901@leemhuis.info> Message-ID: <468A8434.7030006@redhat.com> Thorsten Leemhuis said the following on 07/02/2007 11:08 PM Pacific Time: > (?) -- I think that is a general problem we more and more face; a issue > get discussed and a solution is found to solve the issue now; with a bit > of luck it gets documented properly in the wiki, but often it gets > buried in meeting logs and forgotten. Some months later the same thing > pops up again and gets discussed endlessly again.... > You are completely correct! I've found that as we've been working on the Feature process proposal that adding feedback to the wiki page works better than discussing on the mail lists... and you have have history if you want to see earlier revisions. http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft John From pertusus at free.fr Tue Jul 3 19:48:24 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 3 Jul 2007 21:48:24 +0200 Subject: Gash stuck @update-testing? In-Reply-To: <200707031024.54210.jkeating@redhat.com> References: <1183391099.16578.26.camel@gilboa-work-dev.localdomain> <200707030657.25053.jkeating@redhat.com> <20070703141353.GD3057@free.fr> <200707031024.54210.jkeating@redhat.com> Message-ID: <20070703194824.GC3398@free.fr> On Tue, Jul 03, 2007 at 10:24:53AM -0400, Jesse Keating wrote: > On Tuesday 03 July 2007 10:13:53 Patrice Dumas wrote: > > Maybe in the point 2. it should be 'Mark as Stable' instead of > > 'Push to final'? > > > > I can make the change in the wiki (on point 1. and 2.) if you confirm > > it is 'Mark as Stable'. > > Yes, it is 'Mark as Stable'. Please feel free to update. Done. -- Pat From lemenkov at gmail.com Tue Jul 3 19:52:51 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 3 Jul 2007 23:52:51 +0400 Subject: How to change --exec-prefix in %configure? Message-ID: Hello All! Subj. I faced some difficulties. For some reason I need to add --exec-prefix=/ to %configure. Firstly, I did it in he trivial way: %configure --exec-prefix=/ but failed - default exec-prefix (which explicitly defines in that macro) used instead of mine. So far I've got simple question - how can I pass my custom exec-prefix w/o copypasting whole %configure macro into my spec and fixing it a little? -- With best regards! From lemenkov at gmail.com Tue Jul 3 20:01:00 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Wed, 4 Jul 2007 00:01:00 +0400 Subject: Where is my sipp? Message-ID: Hello All. Looks like I am a victim of Koji. I've got a mails from Koji about successful builds for F7 and devel (good old plague emailed me about FC6 too), but I can't find sipp nor in updates-testing neither in updates (only in devel and FC-6). Did I miss something koji-related? -- With best regards! From roland at redhat.com Tue Jul 3 20:00:59 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 3 Jul 2007 13:00:59 -0700 (PDT) Subject: How to change --exec-prefix in %configure? In-Reply-To: Peter Lemenkov's message of Tuesday, 3 July 2007 23:52:51 +0400 Message-ID: <20070703200059.0610F4D0435@magilla.localdomain> > I faced some difficulties. For some reason I need to add > --exec-prefix=/ to %configure. Firstly, I did it in he trivial way: Sure that should be --exec-prefix= instead. You can try redefining the _exec_prefix macro in the spec: %define _exec_prefix %{nil} %configure From pertusus at free.fr Tue Jul 3 20:03:50 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 3 Jul 2007 22:03:50 +0200 Subject: Where is my sipp? In-Reply-To: References: Message-ID: <20070703200350.GD3398@free.fr> On Wed, Jul 04, 2007 at 12:01:00AM +0400, Peter Lemenkov wrote: > Hello All. > Looks like I am a victim of Koji. > I've got a mails from Koji about successful builds for F7 and devel > (good old plague emailed me about FC6 too), but I can't find sipp nor > in updates-testing neither in updates (only in devel and FC-6). > > Did I miss something koji-related? Maybe you miss something bodhi related ;-) http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo -- Pat From devrim at CommandPrompt.com Tue Jul 3 20:05:33 2007 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Tue, 03 Jul 2007 23:05:33 +0300 Subject: Where is my sipp? In-Reply-To: References: Message-ID: <1183493133.5757.4.camel@laptop.gunduz.org> Hello, On Wed, 2007-07-04 at 00:01 +0400, Peter Lemenkov wrote: > Did I miss something koji-related? AFAIK, you need to push it manually: https://admin.fedoraproject.org/updates/new/ Regards, -- Devrim G?ND?Z PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jdennis at redhat.com Tue Jul 3 20:36:01 2007 From: jdennis at redhat.com (John Dennis) Date: Tue, 03 Jul 2007 16:36:01 -0400 Subject: How to change --exec-prefix in %configure? In-Reply-To: References: Message-ID: <1183494961.11988.26.camel@finch.boston.redhat.com> On Tue, 2007-07-03 at 23:52 +0400, Peter Lemenkov wrote: > Hello All! > Subj. > I faced some difficulties. For some reason I need to add > --exec-prefix=/ to %configure. Firstly, I did it in he trivial way: > > %configure --exec-prefix=/ > > but failed - default exec-prefix (which explicitly defines in that > macro) used instead of mine. > > So far I've got simple question - how can I pass my custom exec-prefix > w/o copypasting whole %configure macro into my spec and fixing it a > little? Don't use %configure, IMHO it's evil. Why? You just found out. I think it's better to know exactly where things are going placed when your spec file is evaluated so its better to obvious and explicit in the spec file and pass the parameters explicitly so there is no confusion due to silent obfuscation. Not all configure scripts are the same. It's your job as a packager to know exactly what your package's configure script is doing. Perhaps others disagree, but I've seen too many people burned by %configure defying expectation. YMMV. -- John Dennis From bugs.michael at gmx.net Wed Jul 4 07:48:57 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 4 Jul 2007 09:48:57 +0200 Subject: Package EVR problems in Fedora 2007-07-03 In-Reply-To: <20070703095241.E011D152131@buildsys.fedoraproject.org> References: <20070703095241.E011D152131@buildsys.fedoraproject.org> Message-ID: <20070704094857.1b76df30.bugs.michael@gmx.net> Just to clarify, these reports (also sent by private mail) include F7 Test Updates. So, for many of the EVR issues, the F7 Test Updates or stable Updates are still missing. From Axel.Thimm at ATrpms.net Wed Jul 4 12:59:00 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 4 Jul 2007 14:59:00 +0200 Subject: Policy for retiring packages? Message-ID: <20070704125900.GA25570@puariko.nirvana> Hi, do we have such a thing? How do old packages get recycled? Any way to predict packages being deleted from the repo? (this is important for 3rd party repo yum support, especially in the kernel and kmdl area) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available URL: From a.badger at gmail.com Wed Jul 4 15:11:06 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 04 Jul 2007 08:11:06 -0700 Subject: Policy for retiring packages? In-Reply-To: <20070704125900.GA25570@puariko.nirvana> References: <20070704125900.GA25570@puariko.nirvana> Message-ID: <1183561867.3628.12.camel@localhost.localdomain> On Wed, 2007-07-04 at 14:59 +0200, Axel Thimm wrote: > Hi, > > do we have such a thing? How do old packages get recycled? Any way to > predict packages being deleted from the repo? > > (this is important for 3rd party repo yum support, especially in the > kernel and kmdl area) AFAIK we have policy for what to do but not a policy on when it can happen. I think the policy is spread out on these three pages:: http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife http://fedoraproject.org/wiki/PackageMaintainers/RetiredPackages http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages -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 tibbs at math.uh.edu Wed Jul 4 16:22:26 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Jul 2007 11:22:26 -0500 Subject: Summary of the 2007-07-03 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-07-03 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070703 Executive summary: The following draft is now an official guideline, having been accepted by FESCO last week: * http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs These should be written into the guidelines soon if this hasn't already been done by the time you read this. No issues pending FESCO ratification this week. There was one vote: * Stop recommending the use of %{?_smp_mflags} * See thread beginning at https://www.redhat.com/archives/fedora-packaging/2007-July/msg00000.html * Rejected (1 - 5) Misc business: * Relaxing restrictions on compat- package naming. * https://www.redhat.com/archives/fedora-packaging/2007-June/msg00182.html - J< From Axel.Thimm at ATrpms.net Wed Jul 4 16:41:22 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 4 Jul 2007 18:41:22 +0200 Subject: Policy for retiring packages? In-Reply-To: <1183561867.3628.12.camel@localhost.localdomain> References: <20070704125900.GA25570@puariko.nirvana> <1183561867.3628.12.camel@localhost.localdomain> Message-ID: <20070704164122.GB600@puariko.nirvana> On Wed, Jul 04, 2007 at 08:11:06AM -0700, Toshio Kuratomi wrote: > On Wed, 2007-07-04 at 14:59 +0200, Axel Thimm wrote: > > do we have such a thing? How do old packages get recycled? Any way > > to predict packages being deleted from the repo? > > > > (this is important for 3rd party repo yum support, especially in the > > kernel and kmdl area) > > AFAIK we have policy for what to do but not a policy on when it can > happen. I think the policy is spread out on these three pages:: > > http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife > http://fedoraproject.org/wiki/PackageMaintainers/RetiredPackages > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages > > -Toshio OK, so there are some policies to be consolidated. But whop is currently enforcing them? E.g. who decides when the kernel package is retired? And more to the point of interest: Would there be a way to be notified that a package was retired? The background is that ATrpms and other repos support Fedora kernels by providing kernel module packages. These are depending on the kernel they were built for. While for non-kernel packages one could always just support the latest found in the repo, for kernels one needs to support at least the last two, sometimes even more (for example when 2.6.19 went 2.6.20 the last 2.6.19 was for some time the only kernel some users could use). So ATrpms decided to support *all* kernels in updates-released, but this leads to yum breakage when such a kernel is removed and yum detects packages that require a not-anymore existing package. Therefore I need to know when the kernels are retired, best by a notfiying mail, so I can purge the old kmdls from the repo before yum barfs on users' machines. Alternatively someone could give yum some love to not do that (apt and smart don't FWIW, but they aren't the default depsolver 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 a.badger at gmail.com Wed Jul 4 17:12:33 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 04 Jul 2007 10:12:33 -0700 Subject: When are kernels removed from the download repository? (was Re: Policy for retiring packages?) In-Reply-To: <20070704164122.GB600@puariko.nirvana> References: <20070704125900.GA25570@puariko.nirvana> <1183561867.3628.12.camel@localhost.localdomain> <20070704164122.GB600@puariko.nirvana> Message-ID: <1183569153.3628.27.camel@localhost.localdomain> On Wed, 2007-07-04 at 18:41 +0200, Axel Thimm wrote: > On Wed, Jul 04, 2007 at 08:11:06AM -0700, Toshio Kuratomi wrote: > > On Wed, 2007-07-04 at 14:59 +0200, Axel Thimm wrote: > > > do we have such a thing? How do old packages get recycled? Any way > > > to predict packages being deleted from the repo? > > > > > > (this is important for 3rd party repo yum support, especially in the > > > kernel and kmdl area) > > > > AFAIK we have policy for what to do but not a policy on when it can > > happen. I think the policy is spread out on these three pages:: > > > > http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife > > http://fedoraproject.org/wiki/PackageMaintainers/RetiredPackages > > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages > > > > -Toshio > > OK, so there are some policies to be consolidated. But whop is > currently enforcing them? E.g. who decides when the kernel package is > retired? And more to the point of interest: Would there be a way to be > notified that a package was retired? > > The background is that ATrpms and other repos support Fedora kernels > by providing kernel module packages. These are depending on the kernel > they were built for. > So those policies aren't going to help you since you need to find out when a built kernel rpm is being dropped from the download repository. The policy only addresses when a package is being dropped from the cvs repository. Jesse, Michael Schwendt, or one of the relengs might know the answer to this but there's currently no written policy that I'm aware of. -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 j.w.r.degoede at hhs.nl Wed Jul 4 20:28:27 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 04 Jul 2007 22:28:27 +0200 Subject: Florian La Roche please stop mass filing bugs Message-ID: <468C02EB.20207@hhs.nl> Hi all, Can someone please stop Florian La Roche from mass filing bugs, for packages which follow: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda To the letter and teach him to instead discuss stuff like this on the list, see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246771 Thanks & Regards, Hans From jkeating at redhat.com Thu Jul 5 02:16:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 4 Jul 2007 22:16:37 -0400 Subject: When are kernels removed from the download repository? (was Re: Policy for retiring packages?) In-Reply-To: <1183569153.3628.27.camel@localhost.localdomain> References: <20070704125900.GA25570@puariko.nirvana> <20070704164122.GB600@puariko.nirvana> <1183569153.3628.27.camel@localhost.localdomain> Message-ID: <200707042216.37679.jkeating@redhat.com> On Wednesday 04 July 2007 13:12:33 Toshio Kuratomi wrote: > So those policies aren't going to help you since you need to find out > when a built kernel rpm is being dropped from the download repository. > The policy only addresses when a package is being dropped from the cvs > repository. > > Jesse, Michael Schwendt, or one of the relengs might know the answer to > this but there's currently no written policy that I'm aware of. In the new merged world, only the latest updates are in the repo at any time. This is just due to how mash is used in conjunction with Koji. We ask koji for all the latest packages in the dist-fc7-updates and dist-fc7-updates-testing tags and create repos from scratch. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Thu Jul 5 06:45:15 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 5 Jul 2007 08:45:15 +0200 Subject: Florian La Roche please stop mass filing bugs In-Reply-To: <468C02EB.20207@hhs.nl> References: <468C02EB.20207@hhs.nl> Message-ID: <20070705064515.GA13830@dudweiler.stuttgart.redhat.com> On Wed, Jul 04, 2007 at 10:28:27PM +0200, Hans de Goede wrote: > Hi all, > > Can someone please stop Florian La Roche from mass filing bugs, for > packages which follow: > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda > > To the letter and teach him to instead discuss stuff like this on the list, > see: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246771 Hello Hans, looking into spec files many rpms have already corrected their scripts to not show this error. Most by checking if the app is installed before calling it, some by redirecting the error output to /dev/null. So it is a known issue where most maintainers have already fixed their packaging. The error output is a real bug, so just closing this is not very good. I understand you are not interested in pursuing this, then you should keep such bugs open until the discussion about this is over. It is good you explicitely allow others to change things in your packages. regards, Florian La Roche From j.w.r.degoede at hhs.nl Thu Jul 5 06:52:25 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 05 Jul 2007 08:52:25 +0200 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <20070705064515.GA13830@dudweiler.stuttgart.redhat.com> References: <468C02EB.20207@hhs.nl> <20070705064515.GA13830@dudweiler.stuttgart.redhat.com> Message-ID: <468C9529.9060706@hhs.nl> Florian La Roche wrote: > On Wed, Jul 04, 2007 at 10:28:27PM +0200, Hans de Goede wrote: >> Hi all, >> >> Can someone please stop Florian La Roche from mass filing bugs, for >> packages which follow: >> http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda >> >> To the letter and teach him to instead discuss stuff like this on the list, >> see: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246771 > > > > Hello Hans, > > looking into spec files many rpms have already corrected their > scripts to not show this error. Most by checking if the app is installed > before calling it, Actually, the checking first is the old recipe from the scriplets page, so those packages haven't been fixed, they have not been updated to match the latest scriptlets page. > So it is a known issue where most maintainers have already fixed > their packaging. > No its not a known issue, otherwise people like Tibbs, who has reviewed somewhere near 300 packages and I who maintain 130+ packages would have known about it. > The error output is a real bug, so just closing this is not very > good. I agree that its a bug. However as said the scriptlet recipe was changed from checking to not checking, I'm sure this was discussed and there were reasons. So lets first discuss this with the people who made this change. > I understand you are not interested in pursuing this, then > you should keep such bugs open until the discussion about this is > over. This is something that should get discussed first and then start opening bugs, if that is whats agreed upon as result of the discussion. You did it in the wrong order. Also this is so minor that I personally don't think it warrents filing bugs, people installing graphical applications without having gtk on there system? The chances of that happening are very small. I say lets update the recipe page and ask maintainer to fix the scripts as they roll out updates for other (better) reasons. That what I've been doing with checking if gtk-update-icon-cahce exists before running -> not checking (as that is what the recipe was changed to). > It is good you explicitely allow others to change things in > your packages. > Yes, thus as said once this is discussed, if you think this is worth the time filing a bug over, please just go in and fix it instead. Regards, Hans From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jul 5 07:45:20 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 05 Jul 2007 16:45:20 +0900 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <468C9529.9060706@hhs.nl> References: <468C02EB.20207@hhs.nl> <20070705064515.GA13830@dudweiler.stuttgart.redhat.com> <468C9529.9060706@hhs.nl> Message-ID: <468CA190.2080005@ioa.s.u-tokyo.ac.jp> Hans de Goede wrote, at 07/05/2007 03:52 PM +9:00: > Florian La Roche wrote: >> The error output is a real bug, so just closing this is not very >> good. > > I agree that its a bug. However as said the scriptlet recipe was changed > from checking to not checking, I'm sure this was discussed and there > were reasons. So lets first discuss this with the people who made this > change. If we must consider this as a bug, then the scriptlets for texinfo treatment should also be fixed. If admin installs rpms with --excludedocs: --------------------------------------------------------------- [root at localhost i386]# LANG=C rpm -ivh units-1.86-5.fc7.i386.rpm --excludedocs Preparing... ########################################### [100%] 1:units ########################################### [100%] install-info: No such file or directory for /usr/share/info/units.info.gz --------------------------------------------------------------- > >> I understand you are not interested in pursuing this, then >> you should keep such bugs open until the discussion about this is >> over. > > This is something that should get discussed first and then start opening > bugs, if that is whats agreed upon as result of the discussion. You did > it in the wrong order. I agree. This must be discussed first. Regards, Mamoru From laroche at redhat.com Thu Jul 5 08:09:17 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 5 Jul 2007 10:09:17 +0200 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <468C9529.9060706@hhs.nl> References: <468C02EB.20207@hhs.nl> <20070705064515.GA13830@dudweiler.stuttgart.redhat.com> <468C9529.9060706@hhs.nl> Message-ID: <20070705080916.GA2606@dudweiler.stuttgart.redhat.com> Hello Hans, > This is something that should get discussed first and then start opening > bugs, if that is whats agreed upon as result of the discussion. You did it > in the wrong order. Also this is so minor that I personally don't think it > warrents filing bugs, people installing graphical applications without > having gtk on there system? The chances of that happening are very small. That's probably why it is fixed for packages that are normally installed e.g. via kickstart, but not for ones that can get installed later on. > Yes, thus as said once this is discussed, if you think this is worth the > time filing a bug over, please just go in and fix it instead. I'll see if the packaging discussion will bring something up. regards, Florian La Roche From laroche at redhat.com Thu Jul 5 08:15:35 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 5 Jul 2007 10:15:35 +0200 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <468CA190.2080005@ioa.s.u-tokyo.ac.jp> References: <468C02EB.20207@hhs.nl> <20070705064515.GA13830@dudweiler.stuttgart.redhat.com> <468C9529.9060706@hhs.nl> <468CA190.2080005@ioa.s.u-tokyo.ac.jp> Message-ID: <20070705081535.GB2606@dudweiler.stuttgart.redhat.com> On Thu, Jul 05, 2007 at 04:45:20PM +0900, Mamoru Tasaka wrote: > Hans de Goede wrote, at 07/05/2007 03:52 PM +9:00: > >Florian La Roche wrote: > >>The error output is a real bug, so just closing this is not very > >>good. > > > >I agree that its a bug. However as said the scriptlet recipe was changed > >from checking to not checking, I'm sure this was discussed and there > >were reasons. So lets first discuss this with the people who made this > >change. > > If we must consider this as a bug, then the scriptlets for > texinfo treatment should also be fixed. If admin installs rpms > with --excludedocs: I've never seen a decision if we want to support excluding docs and adapt scripts for that. regards, Florian La Roche From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jul 5 08:41:07 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 05 Jul 2007 17:41:07 +0900 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <20070705081535.GB2606@dudweiler.stuttgart.redhat.com> References: <468C02EB.20207@hhs.nl> <20070705064515.GA13830@dudweiler.stuttgart.redhat.com> <468C9529.9060706@hhs.nl> <468CA190.2080005@ioa.s.u-tokyo.ac.jp> <20070705081535.GB2606@dudweiler.stuttgart.redhat.com> Message-ID: <468CAEA3.3020705@ioa.s.u-tokyo.ac.jp> Florian La Roche wrote, at 07/05/2007 05:15 PM +9:00: > On Thu, Jul 05, 2007 at 04:45:20PM +0900, Mamoru Tasaka wrote: >> Hans de Goede wrote, at 07/05/2007 03:52 PM +9:00: >>> Florian La Roche wrote: >>>> The error output is a real bug, so just closing this is not very >>>> good. >>> I agree that its a bug. However as said the scriptlet recipe was changed >> >from checking to not checking, I'm sure this was discussed and there >>> were reasons. So lets first discuss this with the people who made this >>> change. >> If we must consider this as a bug, then the scriptlets for >> texinfo treatment should also be fixed. If admin installs rpms >> with --excludedocs: > > > I've never seen a decision if we want to support excluding docs and > adapt scripts for that. Please check: http://www.redhat.com/archives/fedora-maintainers/2007-January/msg00017.html For example: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223718 Mamoru From laroche at redhat.com Thu Jul 5 09:56:50 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 5 Jul 2007 11:56:50 +0200 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <468CAEA3.3020705@ioa.s.u-tokyo.ac.jp> References: <468C02EB.20207@hhs.nl> <20070705064515.GA13830@dudweiler.stuttgart.redhat.com> <468C9529.9060706@hhs.nl> <468CA190.2080005@ioa.s.u-tokyo.ac.jp> <20070705081535.GB2606@dudweiler.stuttgart.redhat.com> <468CAEA3.3020705@ioa.s.u-tokyo.ac.jp> Message-ID: <20070705095650.GA6051@dudweiler.stuttgart.redhat.com> On Thu, Jul 05, 2007 at 05:41:07PM +0900, Mamoru Tasaka wrote: > Florian La Roche wrote, at 07/05/2007 05:15 PM +9:00: > >On Thu, Jul 05, 2007 at 04:45:20PM +0900, Mamoru Tasaka wrote: > >>Hans de Goede wrote, at 07/05/2007 03:52 PM +9:00: > >>>Florian La Roche wrote: > >>>>The error output is a real bug, so just closing this is not very > >>>>good. > >>>I agree that its a bug. However as said the scriptlet recipe was changed > >>>from checking to not checking, I'm sure this was discussed and there > >>>were reasons. So lets first discuss this with the people who made this > >>>change. > >>If we must consider this as a bug, then the scriptlets for > >>texinfo treatment should also be fixed. If admin installs rpms > >>with --excludedocs: > > > > > >I've never seen a decision if we want to support excluding docs and > >adapt scripts for that. > > Please check: > http://www.redhat.com/archives/fedora-maintainers/2007-January/msg00017.html > For example: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223718 Hello Mamoru, so this would make sure the scripts don't fail, but then just not care if the install-info would output errors. At least some half-way to get systems installed and working and maybe something that makes sense for at least the core packages as this is used for especially very small systems. regards, Florian La Roche From ville.skytta at iki.fi Thu Jul 5 19:04:52 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 5 Jul 2007 22:04:52 +0300 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <20070705081535.GB2606@dudweiler.stuttgart.redhat.com> References: <468C02EB.20207@hhs.nl> <468CA190.2080005@ioa.s.u-tokyo.ac.jp> <20070705081535.GB2606@dudweiler.stuttgart.redhat.com> Message-ID: <200707052204.53207.ville.skytta@iki.fi> On Thursday 05 July 2007, Florian La Roche wrote: > I've never seen a decision if we want to support excluding docs and > adapt scripts for that. http://fedoraproject.org/wiki/Packaging/ReviewGuidelines - MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. Even though this talks about runtime only, in my opinion it covers also taking it into account in scriptlets (but it wouldn't hurt to mention that explicitly). See also http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-47896da5fb2662d75deefeb9ba75145a398515db From ville.skytta at iki.fi Thu Jul 5 19:11:35 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 5 Jul 2007 22:11:35 +0300 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <468C9529.9060706@hhs.nl> References: <468C02EB.20207@hhs.nl> <20070705064515.GA13830@dudweiler.stuttgart.redhat.com> <468C9529.9060706@hhs.nl> Message-ID: <200707052211.36037.ville.skytta@iki.fi> On Thursday 05 July 2007, Hans de Goede wrote: > Florian La Roche wrote: > > > The error output is a real bug, so just closing this is not very > > good. > > I agree that its a bug. However as said the scriptlet recipe was changed > from checking to not checking, I'm sure this was discussed and there were > reasons. So lets first discuss this with the people who made this change. Well, I don't remember if I was involved in that, but if we don't want the scriptlet to fail and don't want to display the error output (no matter whether it's because of a missing executable or some other error running it), dunno if checking first adds any value. Not adding the dependency is there because it'd pull in GTK to non-GTK setups for no gain. This is fine and should be preserved, but actually, I think the snippet/guideline should be changed so that the Requires(post) and Requires(postun) dependencies *should* be added in cases where the packaged app requires GTK itself anyway, and left out just like currently if it doesn't. Opinions? From nicolas.mailhot at laposte.net Thu Jul 5 20:03:51 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 05 Jul 2007 22:03:51 +0200 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <200707052211.36037.ville.skytta@iki.fi> References: <468C02EB.20207@hhs.nl> <20070705064515.GA13830@dudweiler.stuttgart.redhat.com> <468C9529.9060706@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> Message-ID: <1183665831.13226.2.camel@rousalka.dyndns.org> Le jeudi 05 juillet 2007 ? 22:11 +0300, Ville Skytt? a ?crit : > Not adding the dependency is there because it'd pull in GTK to non-GTK setups > for no gain. This is fine and should be preserved, but actually, I think the > snippet/guideline should be changed so that the Requires(post) and > Requires(postun) dependencies *should* be added in cases where the packaged > app requires GTK itself anyway, and left out just like currently if it > doesn't. Opinions ? I'd rather avoid any special casing. Use a single good enough rule in all cases and keep guidelines short. -- 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 wart at kobold.org Thu Jul 5 20:15:02 2007 From: wart at kobold.org (Michael Thomas) Date: Thu, 05 Jul 2007 13:15:02 -0700 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <200707052211.36037.ville.skytta@iki.fi> References: <468C02EB.20207@hhs.nl> <20070705064515.GA13830@dudweiler.stuttgart.redhat.com> <468C9529.9060706@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> Message-ID: <468D5146.9000300@kobold.org> Ville Skytt? wrote: > On Thursday 05 July 2007, Hans de Goede wrote: >> Florian La Roche wrote: >> >>> The error output is a real bug, so just closing this is not very >>> good. >> I agree that its a bug. However as said the scriptlet recipe was changed >> from checking to not checking, I'm sure this was discussed and there were >> reasons. So lets first discuss this with the people who made this change. > > Well, I don't remember if I was involved in that, but if we don't want the > scriptlet to fail and don't want to display the error output (no matter > whether it's because of a missing executable or some other error running it), > dunno if checking first adds any value. > > Not adding the dependency is there because it'd pull in GTK to non-GTK setups > for no gain. This is fine and should be preserved, but actually, I think the > snippet/guideline should be changed so that the Requires(post) and > Requires(postun) dependencies *should* be added in cases where the packaged > app requires GTK itself anyway, and left out just like currently if it > doesn't. Opinions? What about adding 'Requires(post): coreutils' to bring in 'touch' for the gtk+ icon cache scriptlet: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246770 It seems excessive to me, because I can't imagine a situation where coreutils would not get installed. But I also haven't looked that closely at the dependency tree either. --Wart From jkeating at redhat.com Thu Jul 5 20:13:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Jul 2007 16:13:59 -0400 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <468D5146.9000300@kobold.org> References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> Message-ID: <200707051613.59371.jkeating@redhat.com> On Thursday 05 July 2007 16:15:02 Michael Thomas wrote: > What about adding 'Requires(post): coreutils' to bring in 'touch' for > the gtk+ icon cache scriptlet: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246770 > > It seems excessive to me, because I can't imagine a situation where > coreutils would not get installed. ?But I also haven't looked that > closely at the dependency tree either. Often it's not about whether it will be installed or not, but rather it's about whether it will be installed /before/ your %pre/%post script is ran if the packages are in the same transaction (IE installer or big upgrades). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Thu Jul 5 20:15:33 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 05 Jul 2007 16:15:33 -0400 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <200707051613.59371.jkeating@redhat.com> References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> <200707051613.59371.jkeating@redhat.com> Message-ID: <1183666533.3234.1.camel@localhost.localdomain> On Thu, 2007-07-05 at 16:13 -0400, Jesse Keating wrote: > On Thursday 05 July 2007 16:15:02 Michael Thomas wrote: > > What about adding 'Requires(post): coreutils' to bring in 'touch' for > > the gtk+ icon cache scriptlet: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246770 > > > > It seems excessive to me, because I can't imagine a situation where > > coreutils would not get installed. But I also haven't looked that > > closely at the dependency tree either. > > Often it's not about whether it will be installed or not, but rather it's > about whether it will be installed /before/ your %pre/%post script is ran if > the packages are in the same transaction (IE installer or big upgrades). > Now that we are discussing this again, I'd like to point out that the recent ldconfig/%posttrans discussion is somewhat related to this. If we can make %posttrans useful for ldconfig, we can use it for icon cache updates too. That would be a big win. From a.badger at gmail.com Thu Jul 5 22:25:41 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 05 Jul 2007 15:25:41 -0700 Subject: gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts) In-Reply-To: <1183666533.3234.1.camel@localhost.localdomain> References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> <200707051613.59371.jkeating@redhat.com> <1183666533.3234.1.camel@localhost.localdomain> Message-ID: <1183674341.883.10.camel@localhost.localdomain> On Thu, 2007-07-05 at 16:15 -0400, Matthias Clasen wrote: > On Thu, 2007-07-05 at 16:13 -0400, Jesse Keating wrote: > > On Thursday 05 July 2007 16:15:02 Michael Thomas wrote: > > > What about adding 'Requires(post): coreutils' to bring in 'touch' for > > > the gtk+ icon cache scriptlet: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246770 > > > > > > It seems excessive to me, because I can't imagine a situation where > > > coreutils would not get installed. But I also haven't looked that > > > closely at the dependency tree either. > > > > Often it's not about whether it will be installed or not, but rather it's > > about whether it will be installed /before/ your %pre/%post script is ran if > > the packages are in the same transaction (IE installer or big upgrades). > > > > Now that we are discussing this again, I'd like to point out that the > recent ldconfig/%posttrans discussion is somewhat related to this. If > we can make %posttrans useful for ldconfig, we can use it for icon cache > updates too. That would be a big win. > That would be great. Unfortunately, %posttrans doesn't work in the ldconfig case because it doesn't run when only erasing packages. Will that make a difference for gtk-update-icon-cache as well? BTW, what happened to your --delay patch to gtk-update-icon-cache? That also sounded promising for the performance aspect of calling it multiple times from scriptlets. -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 pmatilai at laiskiainen.org Fri Jul 6 07:06:42 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 6 Jul 2007 10:06:42 +0300 (EEST) Subject: gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts) In-Reply-To: <1183674341.883.10.camel@localhost.localdomain> References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> <200707051613.59371.jkeating@redhat.com> <1183666533.3234.1.camel@localhost.localdomain> <1183674341.883.10.camel@localhost.localdomain> Message-ID: On Thu, 5 Jul 2007, Toshio Kuratomi wrote: > On Thu, 2007-07-05 at 16:15 -0400, Matthias Clasen wrote: >> On Thu, 2007-07-05 at 16:13 -0400, Jesse Keating wrote: >>> On Thursday 05 July 2007 16:15:02 Michael Thomas wrote: >>>> What about adding 'Requires(post): coreutils' to bring in 'touch' for >>>> the gtk+ icon cache scriptlet: >>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246770 >>>> >>>> It seems excessive to me, because I can't imagine a situation where >>>> coreutils would not get installed. But I also haven't looked that >>>> closely at the dependency tree either. >>> >>> Often it's not about whether it will be installed or not, but rather it's >>> about whether it will be installed /before/ your %pre/%post script is ran if >>> the packages are in the same transaction (IE installer or big upgrades). >>> >> >> Now that we are discussing this again, I'd like to point out that the >> recent ldconfig/%posttrans discussion is somewhat related to this. If >> we can make %posttrans useful for ldconfig, we can use it for icon cache >> updates too. That would be a big win. >> > That would be great. Unfortunately, %posttrans doesn't work in the > ldconfig case because it doesn't run when only erasing packages. Will > that make a difference for gtk-update-icon-cache as well? Well, the cache wouldn't be updated when packages are removed so it would cache nonexistent icons. Dunno how bad that is in reality. What both ldconfig and gtk-update-icon-cache really beg for is a system, not package-level scripts that do stuff after the transaction completes. Yum and apt both have such a mechanism, what's missing is one on plain rpm level. Of course it would be possible to add some tracking mechanism ("touch need-ldconfig" style) but is it actually needed... I think not. It could be dirt simple like: -- #!/bin/sh /sbin/ldconfig [ -x /usr/bin/gtk-update-icon-cache ] && /usr/bin/gtk-update-icon-cache # any other similar stuff -- That completes fast enough not to be noticeable *at all* when run just once at end of any transaction (the vast majority of the time spent will be in the transaction in all cases really), regardless of whether libraries or gtk-icon containing packages were installed or removed. - Panu - From laroche at redhat.com Fri Jul 6 07:08:35 2007 From: laroche at redhat.com (Florian La Roche) Date: Fri, 6 Jul 2007 09:08:35 +0200 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <200707052211.36037.ville.skytta@iki.fi> References: <468C02EB.20207@hhs.nl> <20070705064515.GA13830@dudweiler.stuttgart.redhat.com> <468C9529.9060706@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> Message-ID: <20070706070835.GA12761@dudweiler.stuttgart.redhat.com> > Well, I don't remember if I was involved in that, but if we don't want the > scriptlet to fail and don't want to display the error output (no matter > whether it's because of a missing executable or some other error running it), > dunno if checking first adds any value. Hello Ville, what's wrong with "if test -x app; then app; fi" for this? Shouldn't this fix all problems? regards, Florian La Roche From rdieter at math.unl.edu Fri Jul 6 12:27:28 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 06 Jul 2007 07:27:28 -0500 Subject: gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts) References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> <200707051613.59371.jkeating@redhat.com> <1183666533.3234.1.camel@localhost.localdomain> <1183674341.883.10.camel@localhost.localdomain> Message-ID: Toshio Kuratomi wrote: > On Thu, 2007-07-05 at 16:15 -0400, Matthias Clasen wrote: >> Now that we are discussing this again, I'd like to point out that the >> recent ldconfig/%posttrans discussion is somewhat related to this. If >> we can make %posttrans useful for ldconfig, we can use it for icon cache >> updates too. That would be a big win. >> > That would be great. Unfortunately, %posttrans doesn't work in the > ldconfig case because it doesn't run when only erasing packages. Will > that make a difference for gtk-update-icon-cache as well? use %postun to handle the uninstall case (at least until when/if rpm %posttrans behaves better here): %posttrans touch --no-create %{_datadir}/icons/hicolor ||: gtk-update-icon-cache -q %{_datadir}/icons/hicolor 2> /dev/null ||: %postun if [ $1 -eq 0 ]; then touch --no-create %{_datadir}/icons/hicolor ||: gtk-update-icon-cache -q %{_datadir}/icons/hicolor 2> /dev/null ||: fi From mclasen at redhat.com Fri Jul 6 13:33:00 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 06 Jul 2007 09:33:00 -0400 Subject: gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts) In-Reply-To: References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> <200707051613.59371.jkeating@redhat.com> <1183666533.3234.1.camel@localhost.localdomain> <1183674341.883.10.camel@localhost.localdomain> Message-ID: <1183728780.4267.4.camel@dhcp83-186.boston.redhat.com> On Fri, 2007-07-06 at 07:27 -0500, Rex Dieter wrote: > Toshio Kuratomi wrote: > > > On Thu, 2007-07-05 at 16:15 -0400, Matthias Clasen wrote: > > >> Now that we are discussing this again, I'd like to point out that the > >> recent ldconfig/%posttrans discussion is somewhat related to this. If > >> we can make %posttrans useful for ldconfig, we can use it for icon cache > >> updates too. That would be a big win. > >> > > That would be great. Unfortunately, %posttrans doesn't work in the > > ldconfig case because it doesn't run when only erasing packages. Will > > that make a difference for gtk-update-icon-cache as well? > > use %postun to handle the uninstall case (at least until when/if > rpm %posttrans behaves better here): > > %posttrans > touch --no-create %{_datadir}/icons/hicolor ||: > gtk-update-icon-cache -q %{_datadir}/icons/hicolor 2> /dev/null ||: > > %postun > if [ $1 -eq 0 ]; then > touch --no-create %{_datadir}/icons/hicolor ||: > gtk-update-icon-cache -q %{_datadir}/icons/hicolor 2> /dev/null ||: > fi > That would work, but do we really want to change all the affected specs again, when a fixed %posttrans/%postuntrans becomes available ? Has there been any response from rpm maintainers as to the feasibility and time-frame for a fixed %posttrans/%postuntrans ? Note that even when pushing things to %posttrans, you get a ton of invokations, so %posttrans only helps for tools which are "idempotent". Thankfully, gtk-update-icon-cache is. From pknirsch at redhat.com Fri Jul 6 14:28:35 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 06 Jul 2007 16:28:35 +0200 Subject: gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts) In-Reply-To: References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> <200707051613.59371.jkeating@redhat.com> <1183666533.3234.1.camel@localhost.localdomain> <1183674341.883.10.camel@localhost.localdomain> Message-ID: <468E5193.40206@redhat.com> Panu Matilainen wrote: > On Thu, 5 Jul 2007, Toshio Kuratomi wrote: > >> On Thu, 2007-07-05 at 16:15 -0400, Matthias Clasen wrote: >>> On Thu, 2007-07-05 at 16:13 -0400, Jesse Keating wrote: >>>> On Thursday 05 July 2007 16:15:02 Michael Thomas wrote: >>>>> What about adding 'Requires(post): coreutils' to bring in 'touch' for >>>>> the gtk+ icon cache scriptlet: >>>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246770 >>>>> >>>>> It seems excessive to me, because I can't imagine a situation where >>>>> coreutils would not get installed. But I also haven't looked that >>>>> closely at the dependency tree either. >>>> >>>> Often it's not about whether it will be installed or not, but rather >>>> it's >>>> about whether it will be installed /before/ your %pre/%post script >>>> is ran if >>>> the packages are in the same transaction (IE installer or big >>>> upgrades). >>>> >>> >>> Now that we are discussing this again, I'd like to point out that the >>> recent ldconfig/%posttrans discussion is somewhat related to this. If >>> we can make %posttrans useful for ldconfig, we can use it for icon cache >>> updates too. That would be a big win. >>> >> That would be great. Unfortunately, %posttrans doesn't work in the >> ldconfig case because it doesn't run when only erasing packages. Will >> that make a difference for gtk-update-icon-cache as well? > > Well, the cache wouldn't be updated when packages are removed so it > would cache nonexistent icons. Dunno how bad that is in reality. > > What both ldconfig and gtk-update-icon-cache really beg for is a system, > not package-level scripts that do stuff after the transaction completes. > Yum and apt both have such a mechanism, what's missing is one on plain > rpm level. > > Of course it would be possible to add some tracking mechanism ("touch > need-ldconfig" style) but is it actually needed... I think not. It could > be dirt simple like: > > -- > #!/bin/sh > /sbin/ldconfig > [ -x /usr/bin/gtk-update-icon-cache ] && /usr/bin/gtk-update-icon-cache > > # any other similar stuff > -- > > That completes fast enough not to be noticeable *at all* when run just > once at end of any transaction (the vast majority of the time spent will > be in the transaction in all cases really), regardless of whether > libraries or gtk-icon containing packages were installed or removed. > > - Panu - > I really like that solution to be honest. It avoids lots of unnecessary gtk-update-icon-cache calls during the update and only does it once at the end. Could something similar be done for the scrollkeeper-update calls as well btw? Or do they need to be done after each package install? Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From a.badger at gmail.com Fri Jul 6 15:09:23 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 06 Jul 2007 08:09:23 -0700 Subject: gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts) In-Reply-To: <468E5193.40206@redhat.com> References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> <200707051613.59371.jkeating@redhat.com> <1183666533.3234.1.camel@localhost.localdomain> <1183674341.883.10.camel@localhost.localdomain> <468E5193.40206@redhat.com> Message-ID: <1183734563.883.51.camel@localhost.localdomain> On Fri, 2007-07-06 at 16:28 +0200, Phil Knirsch wrote: > > I really like that solution to be honest. It avoids lots of unnecessary > gtk-update-icon-cache calls during the update and only does it once at > the end. Could something similar be done for the scrollkeeper-update > calls as well btw? Or do they need to be done after each package install? > scrollkeeper is a little different. On package install it calls: scrollkeeper-update -q -o /usr/share/omf/NAME || : to process the just-installed omf file whereas ldconfig and gtk-update-icon-cache rescan all libraries or icons in a hierarchy. -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 mclasen at redhat.com Fri Jul 6 15:06:24 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 06 Jul 2007 11:06:24 -0400 Subject: gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts) In-Reply-To: <1183734563.883.51.camel@localhost.localdomain> References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> <200707051613.59371.jkeating@redhat.com> <1183666533.3234.1.camel@localhost.localdomain> <1183674341.883.10.camel@localhost.localdomain> <468E5193.40206@redhat.com> <1183734563.883.51.camel@localhost.localdomain> Message-ID: <1183734384.4267.18.camel@dhcp83-186.boston.redhat.com> On Fri, 2007-07-06 at 08:09 -0700, Toshio Kuratomi wrote: > On Fri, 2007-07-06 at 16:28 +0200, Phil Knirsch wrote: > > > > I really like that solution to be honest. It avoids lots of unnecessary > > gtk-update-icon-cache calls during the update and only does it once at > > the end. Could something similar be done for the scrollkeeper-update > > calls as well btw? Or do they need to be done after each package install? > > > scrollkeeper is a little different. On package install it calls: > scrollkeeper-update -q -o /usr/share/omf/NAME || : > > to process the just-installed omf file whereas ldconfig and > gtk-update-icon-cache rescan all libraries or icons in a hierarchy. gtk-update-icon-cache needs to be given the theme directory (or directories) to update as well, so the situation is very similar. One salient feature of gtk-update-icon-cache is that you can just run it on /usr/share/icons/* and if will silently (and quickly) skip the ones that are uptodate. From ville.skytta at iki.fi Fri Jul 6 16:29:49 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 6 Jul 2007 19:29:49 +0300 Subject: Error output from rpm pre/post scripts (was Re: Florian La Roche please stop mass filing bugs) In-Reply-To: <20070706070835.GA12761@dudweiler.stuttgart.redhat.com> References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <20070706070835.GA12761@dudweiler.stuttgart.redhat.com> Message-ID: <200707061929.50184.ville.skytta@iki.fi> On Friday 06 July 2007, Florian La Roche wrote: > > Well, I don't remember if I was involved in that, but if we don't want > > the scriptlet to fail and don't want to display the error output (no > > matter whether it's because of a missing executable or some other error > > running it), dunno if checking first adds any value. > > Hello Ville, > > what's wrong with "if test -x app; then app; fi" for this? > Shouldn't this fix all problems? What I was talking about in the above the difference between these two: app >/dev/null 2>&1 || : if test -x /usr/bin/app ; then /usr/bin/app >/dev/null 2>&1 || : ; fi *But* if we want to let stderr of "app" through (or to let it cause a nonzero exit status, which we almost certainly don't want), then testing first is obviously needed. From Christian.Iseli at licr.org Fri Jul 6 17:54:07 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 6 Jul 2007 19:54:07 +0200 Subject: Fedora Core 5 Retirement In-Reply-To: <4689E135.9050300@redhat.com> References: <468938DB.5080103@redhat.com> <20070703043209.GA15866@redhat.com> <4689E135.9050300@redhat.com> Message-ID: <20070706195407.62ce6060@ludwig-alpha.unil.ch> On Mon, 02 Jul 2007 22:40:05 -0700, John Poelstra wrote: > I would very strongly vote in favor of: "WONTFIX; please reopen this bug against F7 if it still exists there." > > >From one of the QA meetings a month or so back I took the action item to create a proposal for how to deal with bugzillas like this. I'll try to have something proposed on the wiki by the start of next week. FWIW, when FC4 was EOL'd, I mass updated the fc4 targeted BZ tickets into NEEDINFO state with the following comment: ---- This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks. ---- 470 fc4-targeted tickets are still in this state (which I think I'll just WONTFIX close soon). I seem to remember some folks did as asked, and a few sent me hate mails about not fixing the problem... :-) I can do a mass update to NEEDINFO for the fc5 blocking bugs if we decide that's the best way to go. Cheers, C From packages at amiga-hardware.com Sat Jul 7 19:55:35 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Sat, 07 Jul 2007 20:55:35 +0100 Subject: Koji questions Message-ID: <468FEFB7.1090308@amiga-hardware.com> Hi, Does koji build against packages tagged as 'dist-fc7-updates-candidate'? If so, what's the recommended time period for setting off a build so that it will compile against a new dependancy in dist-fc7-updates-candidate? -- Ian Chapman. From jwboyer at jdub.homelinux.org Sat Jul 7 20:08:44 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 07 Jul 2007 15:08:44 -0500 Subject: Koji questions In-Reply-To: <468FEFB7.1090308@amiga-hardware.com> References: <468FEFB7.1090308@amiga-hardware.com> Message-ID: <1183838924.10797.2.camel@vader.jdub.homelinux.org> On Sat, 2007-07-07 at 20:55 +0100, Ian Chapman wrote: > Hi, > > Does koji build against packages tagged as 'dist-fc7-updates-candidate'? No. > If so, what's the recommended time period for setting off a build so > that it will compile against a new dependancy in dist-fc7-updates-candidate? You need to email rel-eng and ask that the temporarily update the buildroot with those packages. Alternatively, you need to get the package(s) pushed into the stable update repo and then you can build against it. josh From pmatilai at laiskiainen.org Sun Jul 8 08:29:02 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sun, 8 Jul 2007 11:29:02 +0300 (EEST) Subject: gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts) In-Reply-To: <1183734563.883.51.camel@localhost.localdomain> References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> <200707051613.59371.jkeating@redhat.com> <1183666533.3234.1.camel@localhost.localdomain> <1183674341.883.10.camel@localhost.localdomain> <468E5193.40206@redhat.com> <1183734563.883.51.camel@localhost.localdomain> Message-ID: On Fri, 6 Jul 2007, Toshio Kuratomi wrote: > On Fri, 2007-07-06 at 16:28 +0200, Phil Knirsch wrote: >> >> I really like that solution to be honest. It avoids lots of unnecessary >> gtk-update-icon-cache calls during the update and only does it once at >> the end. Could something similar be done for the scrollkeeper-update >> calls as well btw? Or do they need to be done after each package install? >> > scrollkeeper is a little different. On package install it calls: > scrollkeeper-update -q -o /usr/share/omf/NAME || : > > to process the just-installed omf file whereas ldconfig and > gtk-update-icon-cache rescan all libraries or icons in a hierarchy. Well, that's how packages currently call it to avoid processing other entries. But check 'scrollkeeper-update -v' - it actually processes all the omf entries there by default, unless told otherwise. So this would apply to scrollkeeper just as well. - Panu - From j.w.r.degoede at hhs.nl Sun Jul 8 09:51:32 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 08 Jul 2007 11:51:32 +0200 Subject: Looking for contact with Aaron Kurtz (AWOL?) Message-ID: <4690B3A4.2040300@hhs.nl> Hi All, As discussed already some time ago on fedora-maintainers list, Aaron Kurtz is not responding to inquiries / bugs about his gnome-applet-sensors package: https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00986.html https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 I'm interested in picking up this package. Since I'm now a co-maintainer of the lm-sensors package and active in lm-sensors upstream I would like to move forward with this. The reporter of the bug in question has already done a first contact attempt as required by the AWOL-policy: http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers I've just added a second contact attempt to the bug in question, and as required by the AWOL policy I'm now sending a mail to the maintainers-list about this. Does anyone know howto contact Aaron and / or whats up with Aaron? Thanks & Regards, Hans From fedora at leemhuis.info Sun Jul 8 13:01:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 Jul 2007 15:01:26 +0200 Subject: EPEL report week 27, 2007 Message-ID: <4690E026.7010906@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week27 = Weekly EPEL Summary = Week 27/2007 == Most important happenings == * Policy for "Branching for EPEL if Fedora maintainer does not react" was approved * target date for for official EPEL announcement: July 19; we need to fix all broken deps beforehand (and make sure any new ones hit the repo) == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * Jeff_S (Jeff Sheltren) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * quiad (KarstenWade) * stahnma (MichaelStahnke) === Summary === * EPEL Meeting ? broken deps ? nirik: * Jeff_S will be responsible for this topic; nirik will try to help * we need to poke people; they likely don't even know that there are broken dep * running a repoclosure before push would be ideal, but not easy; we should get that with bodhi sooner or later, so we don't look deeper into this issue * spam o magic script (broken deps) ? mmcgrath * mmcgrath is looking at it; he committed to have it ready by the next meeting * Move epel dirs on servers down below stable ? knurd * last week decided, this week reverted. * Branch for EPEL if Fedora maintainer does not react ? knurd, _blah_ * https://www.redhat.com/archives/epel-devel-list/2007-July/msg00016.html got approved, knurd added it to the wiki. We likely need to adjust a small detail; see https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00332.html * signers group ? dgilmore * dgilmore and mmcgrath can push and sign; that is considered enough for now * finish the wiki docs and remove the warnings by end of may ? quaid * round about ready; quaid has some changes pending, but nothing major * warning on the top EPEL-page in the wiki will get removed shortly before announcement * EPEL announcement -- quaid * early announce draft to epel-devel-l soon; shortly after that early announce to f-maintainers ; followed by first draft of real announcement to e-d-l ; finally announce on Jul 19 * RHX and EPEL ? quaid * seems some people still don't really know that RHX actually is * general agreement to "we should try to work it so that Free and open source software in RHX is available in EPEL with community support"; quaid> "I doubt we'll have any problem with that idea . I think the RHX folks feel the same; they have no need to duplicate what we do for no reason, and lose the gain of the community . It's going to be a few weeks until we can get a formal set of guidelines between the two groups . Mainly it's about the messaging, making sure that it's easy to know the difference between a package from EPEL and one from RHX . I made the point that ISVs can control that best if the ... actually own the package in Fedora :) " === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-July/msg00019.html == Stats == === General === Number of EPEL Contributors 107 We welcome 6 new contributors: gemi_AT_bluewin.ch, ghenry_AT_suretecsystems.com, mdehaan_AT_redhat.com, mszpak_AT_wp.pl, rich_AT_phekda.gotadsl.co.uk, rpm_AT_greysector.net === EPEL 5 === Number of source packages: 439 Number of binary packages: 799 There are 34 new Packages: * alsamixergui | GUI mixer for ALSA sound devices * artwiz-aleczapka-fonts | Set of (improved) artwiz fonts * blacs | Basic Linear Algebra Communication Subprograms * c-ares | A library that performs asynchronous DNS operations * cobbler | Boot server configurator * cronolog | Web log rotation program for Apache * dar | Software for making/restoring incremental CD/DVD backups * dx | Open source version of IBM's Visualization Data Explorer * eclipse-subclipse | Subversion Eclipse plugin * evolution-bogofilter | A plugin for bogofilter support in evolution * ftplib | Library of FTP routines * gxemul | Instruction-level machine emulator * itk | Object oriented extensions to Tk * jam | Program construction tool, similar to make * JSDoc | Produces javadoc-style documentation from JavaScript sourcefiles * koan | Network provisioning tool for Xen and Bare Metal Machines * lapack | The LAPACK libraries for numerical linear algebra. * libcgi | CGI easy as C * perl-Lingua-EN-Inflect | Convert singular to plural, select "a" or "an" * perl-Lingua-EN-Inflect-Number | Force number of words to singular or plural * perl-version | Perl extension for Version Objects * php-pear-Phlickr | Phlickr is a PHP5 based api kit used with the Flickr API * php-spyc | A simple php yaml class * planet | Flexible RDF/RSS/Atom feed aggregator * python-isprelink | Python module to determine if a file has been prelinked * R | A language for data analysis and graphics * R-RScaLAPACK | An interface to perform parallel computation on linear algebra problems using ScaLAPACK * scalapack | A subset of LAPACK routines redesigned for heterogenous computing * uread | Utilities for unformatted fortran files === EPEL 4 === Number of source packages: 271 Number of binary packages: 560 There are 19 new Packages: * alsamixergui | GUI mixer for ALSA sound devices * artwiz-aleczapka-fonts | Set of (improved) artwiz fonts * c-ares | A library that performs asynchronous DNS operations * cobbler | Boot server configurator * ftplib | Library of FTP routines * gxemul | Instruction-level machine emulator * jam | Program construction tool, similar to make * JSDoc | Produces javadoc-style documentation from JavaScript sourcefiles * koan | Network provisioning tool for Xen and Bare Metal Machines * libcgi | CGI easy as C * perl-Lingua-EN-Inflect | Convert singular to plural, select "a" or "an" * perl-Lingua-EN-Inflect-Number | Force number of words to singular or plural * perl-version | Perl extension for Version Objects * php-spyc | A simple php yaml class * python-isprelink | Python module to determine if a file has been prelinked * R | A language for data analysis and graphics * uread | Utilities for unformatted fortran files ---- ["CategoryEPELReports"] From a.badger at gmail.com Sun Jul 8 18:00:57 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 08 Jul 2007 11:00:57 -0700 Subject: gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts) In-Reply-To: References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> <200707051613.59371.jkeating@redhat.com> <1183666533.3234.1.camel@localhost.localdomain> <1183674341.883.10.camel@localhost.localdomain> <468E5193.40206@redhat.com> <1183734563.883.51.camel@localhost.localdomain> Message-ID: <1183917657.9437.20.camel@localhost.localdomain> On Sun, 2007-07-08 at 11:29 +0300, Panu Matilainen wrote: > On Fri, 6 Jul 2007, Toshio Kuratomi wrote: > > > On Fri, 2007-07-06 at 16:28 +0200, Phil Knirsch wrote: > >> > >> I really like that solution to be honest. It avoids lots of unnecessary > >> gtk-update-icon-cache calls during the update and only does it once at > >> the end. Could something similar be done for the scrollkeeper-update > >> calls as well btw? Or do they need to be done after each package install? > >> > > scrollkeeper is a little different. On package install it calls: > > scrollkeeper-update -q -o /usr/share/omf/NAME || : > > > > to process the just-installed omf file whereas ldconfig and > > gtk-update-icon-cache rescan all libraries or icons in a hierarchy. > > Well, that's how packages currently call it to avoid processing other > entries. But check 'scrollkeeper-update -v' - it actually processes all > the omf entries there by default, unless told otherwise. So this would > apply to scrollkeeper just as well. > I thought the cost of running scrollkeeper-update over all the omf files was higher. A quick test shows that it is comparable to ldconfig and gtk-update-icon-cache so you're right, we could call it at the end of all transactions. -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 gemi at bluewin.ch Sun Jul 8 18:10:54 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sun, 08 Jul 2007 20:10:54 +0200 Subject: Orphaning graveman Message-ID: <1183918254.2627.1.camel@localhost.localdomain> Hi, I would like to orphan graveman, a CD burning application. It seems to be abandoned, see also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=427064 Regards -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From nicolas.mailhot at laposte.net Mon Jul 9 07:33:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 9 Jul 2007 09:33:32 +0200 (CEST) Subject: gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts) In-Reply-To: <1183917657.9437.20.camel@localhost.localdomain> References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> <200707051613.59371.jkeating@redhat.com> <1183666533.3234.1.camel@localhost.localdomain> <1183674341.883.10.camel@localhost.localdomain> <468E5193.40206@redhat.com> <1183734563.883.51.camel@localhost.localdomain> <1183917657.9437.20.camel@localhost.localdomain> Message-ID: <37713.192.54.193.51.1183966412.squirrel@rousalka.dyndns.org> Le Dim 8 juillet 2007 20:00, Toshio Kuratomi a ?crit : > I thought the cost of running scrollkeeper-update over all the omf > files > was higher. A quick test shows that it is comparable to ldconfig and > gtk-update-icon-cache so you're right, we could call it at the end of > all transactions. Is the new end-of-transaction-hook per-package or per-transaction? We have a ton of caching & indexing scriptlets that really want to be run once regardless of the number of packages that ask for them. -- Nicolas Mailhot From pmatilai at laiskiainen.org Mon Jul 9 11:01:04 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 9 Jul 2007 14:01:04 +0300 (EEST) Subject: gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts) In-Reply-To: <37713.192.54.193.51.1183966412.squirrel@rousalka.dyndns.org> References: <468C02EB.20207@hhs.nl> <200707052211.36037.ville.skytta@iki.fi> <468D5146.9000300@kobold.org> <200707051613.59371.jkeating@redhat.com> <1183666533.3234.1.camel@localhost.localdomain> <1183674341.883.10.camel@localhost.localdomain> <468E5193.40206@redhat.com> <1183734563.883.51.camel@localhost.localdomain> <1183917657.9437.20.camel@localhost.localdomain> <37713.192.54.193.51.1183966412.squirrel@rousalka.dyndns.org> Message-ID: On Mon, 9 Jul 2007, Nicolas Mailhot wrote: > > Le Dim 8 juillet 2007 20:00, Toshio Kuratomi a ?crit : > >> I thought the cost of running scrollkeeper-update over all the omf >> files >> was higher. A quick test shows that it is comparable to ldconfig and >> gtk-update-icon-cache so you're right, we could call it at the end of >> all transactions. > > Is the new end-of-transaction-hook per-package or per-transaction? We > have a ton of caching & indexing scriptlets that really want to be > run once regardless of the number of packages that ask for them. Per transaction is what at least I am talking about :) - Panu - From mr.ecik at gmail.com Mon Jul 9 15:04:54 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Mon, 9 Jul 2007 17:04:54 +0200 Subject: Fever available for all packages Message-ID: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> Hi! Some of Extras developers probably know FEver - a simple way to check upstream version changes. Formerly it was available only for Extras, but now, thanks for Koji, it can be used against all Fedora packages. I hope this will be useful for a lot of packagers. Any opinions, suggestion are welcome :) -- Micha? Bentkowski mr.ecik at gmail.com From sundaram at fedoraproject.org Mon Jul 9 15:07:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 09 Jul 2007 20:37:50 +0530 Subject: Fever available for all packages In-Reply-To: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> References: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> Message-ID: <46924F46.1000301@fedoraproject.org> Micha? Bentkowski wrote: > Hi! > Some of Extras developers probably know FEver - a simple way to check > upstream version changes. Formerly it was available only for Extras, > but now, thanks for Koji, it can be used against all Fedora packages. > I hope this will be useful for a lot of packagers. > Any opinions, suggestion are welcome :) I would suggest adding a short description and pointer to FEver and sending a mail to fedora-devel-announce list. Rahul From mr.ecik at gmail.com Mon Jul 9 15:11:34 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Mon, 9 Jul 2007 17:11:34 +0200 Subject: Fever available for all packages In-Reply-To: <46924F46.1000301@fedoraproject.org> References: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> <46924F46.1000301@fedoraproject.org> Message-ID: <668bb39a0707090811o71de3fe5g6a46c6614de8c99c@mail.gmail.com> 2007/7/9, Rahul Sundaram : > I would suggest adding a short description and pointer to FEver and > sending a mail to fedora-devel-announce list. Yes, I forgot to add that: http://fedoraproject.org/wiki/Micha%C5%82Bentkowski/FEver is Fever site, where packages can be added. I'll prepare a message for fedora-devel-announce list soon. -- Micha? Bentkowski mr.ecik at gmail.com From sundaram at fedoraproject.org Mon Jul 9 15:18:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 09 Jul 2007 20:48:27 +0530 Subject: Fever available for all packages In-Reply-To: <668bb39a0707090811o71de3fe5g6a46c6614de8c99c@mail.gmail.com> References: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> <46924F46.1000301@fedoraproject.org> <668bb39a0707090811o71de3fe5g6a46c6614de8c99c@mail.gmail.com> Message-ID: <469251C3.2070904@fedoraproject.org> Micha? Bentkowski wrote: > 2007/7/9, Rahul Sundaram : >> I would suggest adding a short description and pointer to FEver and >> sending a mail to fedora-devel-announce list. > > Yes, I forgot to add that: > http://fedoraproject.org/wiki/Micha%C5%82Bentkowski/FEver > is Fever site, where packages can be added. Can you move that to a more central location and link to it from the Fedora package maintainers page at http://fedoraproject.org/wiki/PackageMaintainers? Rahul From mr.ecik at gmail.com Mon Jul 9 15:34:35 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Mon, 9 Jul 2007 17:34:35 +0200 Subject: Fever available for all packages In-Reply-To: <469251C3.2070904@fedoraproject.org> References: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> <46924F46.1000301@fedoraproject.org> <668bb39a0707090811o71de3fe5g6a46c6614de8c99c@mail.gmail.com> <469251C3.2070904@fedoraproject.org> Message-ID: <668bb39a0707090834h4a1f0170n687d0c70a5654cc1@mail.gmail.com> 2007/7/9, Rahul Sundaram : > Can you move that to a more central location and link to it from the > Fedora package maintainers page at > http://fedoraproject.org/wiki/PackageMaintainers? I moved it under PackageMaintainers tree [1] and I don't think there's a need to link to it at PackageMaintainers site as it's already linked in Package/Maintainers/TrackingUpstream. 1: http://fedoraproject.org/wiki/PackageMaintainers/FEver -- Micha? Bentkowski mr.ecik at gmail.com From opensource at till.name Mon Jul 9 15:39:44 2007 From: opensource at till.name (Till Maas) Date: Mon, 09 Jul 2007 17:39:44 +0200 Subject: Fever available for all packages In-Reply-To: <668bb39a0707090811o71de3fe5g6a46c6614de8c99c@mail.gmail.com> References: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> <46924F46.1000301@fedoraproject.org> <668bb39a0707090811o71de3fe5g6a46c6614de8c99c@mail.gmail.com> Message-ID: <200707091739.47341.opensource@till.name> On Mo Juli 9 2007, Micha? Bentkowski wrote: > I'll prepare a message for fedora-devel-announce list soon. Before you do this, have you considered to use a location to collect the Regexs other than the wiki? A better place imho would be the CVS, e.g. in pkgs/rpms//fever.txt Regards, Till From mr.ecik at gmail.com Mon Jul 9 15:54:45 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Mon, 9 Jul 2007 17:54:45 +0200 Subject: Fever available for all packages In-Reply-To: <200707091739.47341.opensource@till.name> References: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> <46924F46.1000301@fedoraproject.org> <668bb39a0707090811o71de3fe5g6a46c6614de8c99c@mail.gmail.com> <200707091739.47341.opensource@till.name> Message-ID: <668bb39a0707090854x102bca57i92784eb0584ceea3@mail.gmail.com> 2007/7/9, Till Maas : > Before you do this, have you considered to use a location to collect the > Regexs other than the wiki? I have, but imo it would only make sense if fever were very popular and there were a lot of packages added. Wiki is simple to edit and (for the present) enough. -- Micha? Bentkowski mr.ecik at gmail.com From opensource at till.name Mon Jul 9 17:05:56 2007 From: opensource at till.name (Till Maas) Date: Mon, 09 Jul 2007 19:05:56 +0200 Subject: Fever available for all packages In-Reply-To: <668bb39a0707090854x102bca57i92784eb0584ceea3@mail.gmail.com> References: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> <200707091739.47341.opensource@till.name> <668bb39a0707090854x102bca57i92784eb0584ceea3@mail.gmail.com> Message-ID: <200707091905.58838.opensource@till.name> On Mo Juli 9 2007, Micha? Bentkowski wrote: > I have, but imo it would only make sense if fever were very popular > and there were a lot of packages added. Wiki is simple to edit and > (for the present) enough. If it is popular enough, it is already to late, imho, because then a lot people already suffered the pain to edit the long list in the wiki. Currently it takes around 30 seconds to save a edited page and with a lot of people wanting to add their packages soon after the annoncement, there may also be a lot of conflicts, like there is already. Regards, Till From packages at amiga-hardware.com Mon Jul 9 17:43:34 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Mon, 09 Jul 2007 18:43:34 +0100 Subject: debuginfo dependancy problems Message-ID: <469273C6.9090108@amiga-hardware.com> Hi, The debuginfo RPM pulls in dependancies from the perl files used to build the source, but those perl files make use of a private perl module as part of the build process. This perl module is of no use elsewhere but of course RPM picks this up as a dependancy, which shows its ugly head when you try to install the debuginfo RPM. The package in question is fuse-emulator-0.8.0.1. It asks for perl(Fuse). I have few ideas on how to work around it, but I'm not particularly happy with any of them. I'm wondering if there's a tried and tested method for situations like this? -- Ian Chapman. From tibbs at math.uh.edu Mon Jul 9 17:50:46 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Jul 2007 12:50:46 -0500 Subject: debuginfo dependancy problems In-Reply-To: <469273C6.9090108@amiga-hardware.com> References: <469273C6.9090108@amiga-hardware.com> Message-ID: >>>>> "IC" == Ian Chapman writes: IC> I have few ideas on how to work around it, but I'm not IC> particularly happy with any of them. I'm wondering if there's a IC> tried and tested method for situations like this? Filtering errant Perl dependencies is commonly done; I don't see that there would be anything special about filtering dependencies from the debuginfo package. - J< From packages at amiga-hardware.com Mon Jul 9 18:06:30 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Mon, 09 Jul 2007 19:06:30 +0100 Subject: debuginfo dependancy problems In-Reply-To: References: <469273C6.9090108@amiga-hardware.com> Message-ID: <46927926.4040603@amiga-hardware.com> Jason L Tibbitts III wrote: > Filtering errant Perl dependencies is commonly done; I don't see that > there would be anything special about filtering dependencies from the > debuginfo package. I should probably have phrased the question differently. In the past I'd simply patch the file to remove an errant dependency, for example perl(win32)... but that wouldn't work in this case anyway I've dug up something on the wiki which was exactly what I was looking for. :-) -- Ian Chapman. From tibbs at math.uh.edu Mon Jul 9 18:08:30 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Jul 2007 13:08:30 -0500 Subject: debuginfo dependancy problems In-Reply-To: <46927926.4040603@amiga-hardware.com> References: <469273C6.9090108@amiga-hardware.com> <46927926.4040603@amiga-hardware.com> Message-ID: >>>>> "IC" == Ian Chapman writes: IC> In the past I'd simply patch the file to remove an errant IC> dependency, for example perl(win32)... but that wouldn't work in IC> this case anyway I've dug up something on the wiki which was IC> exactly what I was looking for. :-) See http://fedoraproject.org/wiki/Packaging/Perl for information on filtering things from the generated dependency lists. - J< From mr.ecik at gmail.com Mon Jul 9 20:11:52 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Mon, 9 Jul 2007 22:11:52 +0200 Subject: Fever available for all packages In-Reply-To: <200707091905.58838.opensource@till.name> References: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> <200707091739.47341.opensource@till.name> <668bb39a0707090854x102bca57i92784eb0584ceea3@mail.gmail.com> <200707091905.58838.opensource@till.name> Message-ID: <668bb39a0707091311p41f436ecrfc1a6b99b54dd326@mail.gmail.com> 2007/7/9, Till Maas : > If it is popular enough, it is already to late, imho, because then a lot > people already suffered the pain to edit the long list in the wiki. Currently > it takes around 30 seconds to save a edited page and with a lot of people > wanting to add their packages soon after the annoncement, there may also be a > lot of conflicts, like there is already. You may be right. However, I think that it would be better to have fever directory in cvs with everybody permitted to edit this (like owners some time ago). What do you think? -- Micha? Bentkowski mr.ecik at gmail.com From opensource at till.name Mon Jul 9 20:37:09 2007 From: opensource at till.name (Till Maas) Date: Mon, 09 Jul 2007 22:37:09 +0200 Subject: Fever available for all packages In-Reply-To: <668bb39a0707091311p41f436ecrfc1a6b99b54dd326@mail.gmail.com> References: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> <200707091905.58838.opensource@till.name> <668bb39a0707091311p41f436ecrfc1a6b99b54dd326@mail.gmail.com> Message-ID: <200707092237.10911.opensource@till.name> On Mo Juli 9 2007, Micha? Bentkowski wrote: > You may be right. However, I think that it would be better to have > fever directory in cvs with everybody permitted to edit this (like > owners some time ago). What do you think? Where do you see the advantages of this approach? The only one I see, is that it is easier (i.e. it is faster and need less network traffic, unless you already have a complete up-to-date cvs tree) to collect all regular expressions. But the disadvantages are, that it is much easier to create a conflict (at least there is a warning in the comps howto, that one should update before and after one edited the file, but I do not know, whether or not CVS detects conflicts), every maintainer needs to monitor this file to make sure, that the regular expressions of his packages are not (accidently) destroyed. Regards, Till From laroche at redhat.com Tue Jul 10 08:31:11 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 10 Jul 2007 10:31:11 +0200 Subject: rpm installation tests / script tests Message-ID: <20070710083111.GA3194@dudweiler.stuttgart.redhat.com> We have run rpm install tests where each rpm in Fedora-development is resolved to its minimal required dependencies and then installed and also deinstalled completely within an otherwise empty chroot-environment. The Fedora tree used is from July 4th. Complete output from the test is at http://people.redhat.com/laroche/installtest.gz Most problems are not found in core packages part of a default Fedora install and most are only minor things overall, but we could still use this list of refine the proposed scripts as part of the packaging guidelines and also use this as package sanity check. Many packaging problems found by this test have been already corrected before the core/extras merge, so this is also more about regressions than a completely new test. Also some problems found in the below test are already corrected in todays rawhide release. regards, Florian La Roche ERROR: Output running post install script for package FlightGear-0:0.9.11-0.1.pre1.fc8.i386 ERROR: Output running post install script for package Glide3-0:20050815-5.fc6.i386 ERROR: Output running post install script for package HelixPlayer-1:1.0.7-6.fc8.i386 ERROR: Output running post install script for package KoboDeluxe-0:0.4-0.3.pre10.fc7.i386 ERROR: Output running post install script for package Maelstrom-0:3.0.6-13.i386 ERROR: Output running post install script for package MegaMek-0:0.30.11-1.fc7.i386 ERROR: Output running post install script for package NetworkManager-openvpn-0:0.3.2-7.fc6.i386 ERROR: Output running post install script for package NetworkManager-vpnc-1:0.6.4-3.fc7.i386 ERROR: Output running post install script for package abuse-0:0.7.0-4.fc8.i386 ERROR: Output running post install script for package adaptx-0:0.9.13-4jpp.1.fc7.i386 ERROR: Output running post install script for package agistudio-0:1.2.3-3.fc8.i386 ERROR: Output running post install script for package alex4-0:1.0-3.fc7.i386 ERROR: Output running post install script for package allegro-0:4.2.1-2.fc7.i386 ERROR: Output running post install script for package ant-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-antlr-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-apache-bcel-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-apache-bsf-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-apache-log4j-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-apache-oro-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-apache-regexp-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-apache-resolver-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-commons-logging-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-contrib-0:1.0-0.4.b2.fc6.i386 ERROR: Output running post install script for package ant-javamail-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-jdepend-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-jmf-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-jsch-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-junit-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-nodeps-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-swing-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package ant-trax-0:1.6.5-4jpp.2.fc7.i386 ERROR: Output running post install script for package antlr-0:2.7.7-1jpp.4.fc8.i386 ERROR: Output running post install script for package ants-0:1.4-2.fc8.i386 ERROR: Output running post install script for package apg-0:2.3.0b-4.fc6.i386 ERROR: Output running post install script for package asc-0:1.16.4.0-1.fc7.i386 ERROR: Output running post install script for package atomorun-0:1.1-0.3.pre2.fc7.i386 ERROR: Output running post install script for package avalon-framework-0:4.1.4-2jpp.14.fc7.i386 ERROR: Output running post install script for package avalon-logkit-0:1.2-4jpp.5.fc7.i386 ERROR: Output running post install script for package awstats-0:6.6-1.fc7.noarch ERROR: Output running post install script for package axis-0:1.2.1-2jpp.7.fc7.i386 ERROR: Output running post install script for package azureus-0:2.5.0.4-2.fc7.i386 ERROR: Output running post install script for package ballz-0:1.0-1.fc7.i386 ERROR: Output running post install script for package bcel-0:5.1-10jpp.1.fc7.i386 ERROR: Output running post install script for package bea-stax-0:1.2.0-0.1.rc1.2jpp.1.fc7.i386 ERROR: Output running post install script for package bea-stax-api-0:1.2.0-0.1.rc1.2jpp.1.fc7.i386 ERROR: Output running post install script for package berusky-0:1.1-5.fc8.i386 ERROR: Output running post install script for package bibletime-0:1.6.4-2.fc8.i386 ERROR: Output running post install script for package bigboard-0:0.4.9-1.fc8.i386 ERROR: Output running post install script for package bitmap-0:1.0.3-2.fc7.i386 ERROR: Output running post install script for package blobAndConquer-0:0.91-1.fc8.i386 ERROR: Output running post install script for package blobby-0:0.6-0.4.a.fc7.i386 ERROR: Output running post install script for package blobwars-0:1.06-1.fc7.i386 ERROR: Output running post install script for package bluez-gnome-0:0.8-1.fc8.i386 ERROR: Output running post install script for package boa-0:0.94.14-0.5.rc21.fc6.i386 ERROR: Output running post install script for package bouncycastle-0:1.34-3.fc7.i386 ERROR: Output running post install script for package bsf-0:2.3.0-11jpp.1.i386 ERROR: Output running post install script for package bsh-0:1.3.0-9jpp.2.i386 ERROR: Output running post install script for package byzanz-0:0.1.1-4.fc6.i386 ERROR: Output running post install script for package castor-0:0.9.5-1jpp.7.i386 ERROR: Output running post install script for package castor-demo-0:0.9.5-1jpp.7.i386 ERROR: Output running post install script for package castor-test-0:0.9.5-1jpp.7.i386 ERROR: Output running post install script for package castor-xml-0:0.9.5-1jpp.7.i386 ERROR: Output running post install script for package cfengine-0:2.2.1-3.fc8.i386 ERROR: Output running post install script for package chemical-mime-data-0:0.1.94-2.fc7.noarch ERROR: Output running post install script for package childsplay-0:0.85.1-2.fc8.noarch ERROR: Output running post install script for package chmsee-0:1.0.0-0.19.beta2.fc8.i386 ERROR: Output running post install script for package clanbomber-0:1.05-4.fc7.i386 ERROR: Output running post install script for package classpathx-jaf-0:1.0-9jpp.1.i386 ERROR: Output running post install script for package classpathx-mail-0:1.1.1-4jpp.3.i386 ERROR: Output running post install script for package comix-0:3.6.4-1.fc8.noarch ERROR: Output running post install script for package compat-flex-0:2.5.4a-1.fc7.i386 ERROR: Output running post install script for package concurrent-0:1.3.4-5jpp.1.fc7.i386 ERROR: Output running post install script for package crossfire-selinux-0:1.10.0-1.fc8.i386 ERROR: Output running post install script for package cryptix-0:3.2.0-9jpp.1.i386 ERROR: Output running post install script for package cryptix-asn1-0:20011119-7jpp.2.i386 ERROR: Output running post install script for package csound-java-0:5.03.0-13.fc7.i386 ERROR: Output running post install script for package ctapi-cyberjack-pcsc-0:3.0.0-2.fc8.i386 ERROR: Output running post install script for package cups-pdf-0:2.4.6-1.fc7.i386 ERROR: Output running post install script for package cyphesis-selinux-0:0.5.12-1.fc7.i386 ERROR: Output running post install script for package cyrus-imapd-0:2.3.8-3.fc7.i386 ERROR: Output running post install script for package ddd-0:3.3.11-15.fc7.i386 ERROR: Output running post install script for package deskbar-applet-0:2.19.3-3.fc8.i386 ERROR: Output running post install script for package dgae-0:1.1-3.fc8.noarch ERROR: Output running post install script for package dircproxy-0:1.2.0-0.5.beta2.fc7.i386 ERROR: Output running post install script for package djvulibre-0:3.5.19-2.fc8.i386 ERROR: Output running post install script for package dolphin-0:0.8.2-2.fc7.i386 ERROR: Output running post install script for package dtdparser-0:1.21-3jpp.2.fc7.i386 ERROR: Output running post install script for package duel3-0:0.1-0.3.20060225.fc7.i386 ERROR: Output running post install script for package eblook-0:1.6.1-2.fc7.i386 ERROR: Output running post install script for package eclipse-ecj-1:3.2.2-15.fc8.i386 ERROR: Output running post install script for package eclipse-rcp-1:3.2.2-15.fc8.i386 ERROR: Output running post install script for package eclipse-rcp-sdk-1:3.2.2-15.fc8.i386 ERROR: Output running post install script for package ed2k_hash-gui-0:0.4.0-3.fc6.i386 ERROR: Output running post install script for package escape-0:200704130-3.fc7.i386 ERROR: Output running post install script for package fedora-logos-0:6.0.98-4.fc8.noarch ERROR: Output running post install script for package fillets-ng-0:0.7.4-1.fc8.i386 ERROR: Output running post install script for package fish-0:1.21.12-1.fc6.i386 ERROR: Output running post install script for package fpc-0:2.0.4-2.fc6.i386 ERROR: Output running post install script for package freenx-0:0.6.0-12.fc7.i386 ERROR: Output running post install script for package frozen-bubble-server-0:2.1.0-3.fc8.i386 ERROR: Output running post install script for package galeon-0:2.0.3-9.fc7.i386 ERROR: Output running post install script for package gallery2-0:2.2-0.6.svn20070506.fc8.noarch ERROR: Output running post install script for package games-menus-0:0.2-3.fc7.noarch ERROR: Output running post install script for package ganymed-ssh2-0:210-2.fc6.i386 ERROR: Output running post install script for package gauche-0:0.8.10-1.fc7.i386 ERROR: Output running post install script for package gchempaint-0:0.6.9-1.fc7.i386 ERROR: Output running post install script for package gcombust-1:0.1.55-10.i386 ERROR: Output running post install script for package gemdropx-0:0.9-2.fc7.i386 ERROR: Output running post install script for package geronimo-specs-0:1.0-0.M2.2jpp.12.i386 ERROR: Output running post install script for package gimmie-0:0.2.7-1.fc8.i386 ERROR: Output running post install script for package glob2-0:0.8.21-2.fc8.i386 ERROR: Output running post install script for package gnochm-0:0.9.10-1.fc8.noarch ERROR: Output running post install script for package gnomeradio-0:1.6-3.fc6.i386 ERROR: Output running post install script for package gnu-getopt-0:1.0.12-3jpp.1.i386 ERROR: Output running post install script for package gutenprint-cups-0:5.0.1-2.fc8.i386 ERROR: Output running post install script for package gutenprint-foomatic-0:5.0.1-2.fc8.i386 ERROR: Output running post install script for package hatari-0:0.95-1.fc8.i386 ERROR: Output running post install script for package hsqldb-1:1.8.0.7-2jpp.2.i386 ERROR: Output running post install script for package hugin-0:0.6.1-6.fc7.i386 ERROR: Output running post install script for package icu4j-0:3.6.1-1jpp.1.fc8.i386 ERROR: Output running post install script for package ifplugd-0:0.28-6.fc7.i386 ERROR: Output running post install script for package iksemel-devel-0:1.2-13.fc7.i386 ERROR: Output running post install script for package jakarta-commons-beanutils-0:1.7.0-5jpp.1.i386 ERROR: Output running post install script for package jakarta-commons-cli-0:1.0-6jpp_10.fc6.i386 ERROR: Output running post install script for package jakarta-commons-codec-0:1.3-7jpp.2.i386 ERROR: Output running post install script for package jakarta-commons-collections-0:3.1-9jpp.2.fc7.1.i386 ERROR: Output running post install script for package jakarta-commons-collections-testframework-0:3.1-9jpp.2.fc7.1.i386 ERROR: Output running post install script for package jakarta-commons-collections-tomcat5-0:3.1-9jpp.2.fc7.1.i386 ERROR: Output running post install script for package jakarta-commons-daemon-1:1.0.1-6jpp.2.fc7.i386 ERROR: Output running post install script for package jakarta-commons-dbcp-0:1.2.1-10jpp.1.fc7.i386 ERROR: Output running post install script for package jakarta-commons-dbcp-tomcat5-0:1.2.1-10jpp.1.fc7.i386 ERROR: Output running post install script for package jakarta-commons-digester-0:1.7-6jpp.1.i386 ERROR: Output running post install script for package jakarta-commons-discovery-1:0.3-4jpp.1.i386 ERROR: Output running post install script for package jakarta-commons-el-0:1.0-7jpp.1.fc7.i386 ERROR: Output running post install script for package jakarta-commons-fileupload-1:1.0-6jpp.1.i386 ERROR: Output running post install script for package jakarta-commons-httpclient-1:3.0.1-1jpp.1.fc7.i386 ERROR: Output running post install script for package jakarta-commons-lang-0:2.1-6jpp.1.fc7.i386 ERROR: Output running post install script for package jakarta-commons-launcher-0:1.1-1jpp.2.fc7.i386 ERROR: Output running post install script for package jakarta-commons-logging-0:1.0.4-6jpp.1.i386 ERROR: Output running post install script for package jakarta-commons-modeler-0:2.0-3jpp.1.fc7.i386 ERROR: Output running post install script for package jakarta-commons-pool-0:1.3-9jpp.2.fc7.1.i386 ERROR: Output running post install script for package jakarta-commons-validator-0:1.1.4-5jpp.1.i386 ERROR: Output running post install script for package jakarta-oro-0:2.0.8-3jpp.1.i386 ERROR: Output running post install script for package jakarta-taglibs-standard-0:1.1.1-7jpp.1.i386 ERROR: Output running post install script for package java-1.5.0-gcj-0:1.5.0.0-14.fc7.i386 ERROR: Output running post install script for package java_cup-1:0.10-0.k.6jpp.1.i386 ERROR: Output running post install script for package javacc-0:4.0-3jpp.3.i386 ERROR: Output running post install script for package javasvn-0:1.1.0-0.3.beta4.fc6.i386 ERROR: Output running post install script for package jdepend-0:2.6-6jpp.1.i386 ERROR: Output running post install script for package jdepend-javadoc-0:2.6-6jpp.1.i386 ERROR: Output running post install script for package jdom-0:1.0-4jpp.1.i386 ERROR: Output running post install script for package jgroups-0:2.2.9.2-3jpp.2.i386 ERROR: Output running post install script for package jlex-0:1.2.6-5jpp.1.i386 ERROR: Output running post install script for package jline-0:0.9.9-1jpp.1.fc7.i386 ERROR: Output running post install script for package jogl-1:1.0.0-5.7.beta5.fc6.i386 ERROR: Output running post install script for package jrefactory-0:2.8.9-6jpp.3.i386 ERROR: Output running post install script for package jsch-0:0.1.31-1jpp.1.i386 ERROR: Output running post install script for package jtidy-2:1.0-0.1.r7dev.1jpp.2.fc7.i386 ERROR: Output running post install script for package junit-0:3.8.2-3jpp.1.fc7.i386 ERROR: Output running post install script for package jython-0:2.2-0.3.Release_2_2beta1.1jpp.3.fc7.i386 ERROR: Output running post install script for package jython-demo-0:2.2-0.3.Release_2_2beta1.1jpp.3.fc7.i386 ERROR: Output running post install script for package jzlib-0:1.0.7-4jpp.1.i386 ERROR: Output running post install script for package kalgebra-0:0.5-3.fc7.i386 ERROR: Output running post install script for package katapult-0:0.3.2.1-1.fc8.i386 ERROR: Output running post install script for package kawa-1:1.9.0-2.fc7.i386 ERROR: Output running post install script for package kbackup-0:0.5.1-2.fc6.i386 ERROR: Output running post install script for package kbilliards-0:0.8.7b-2.fc7.i386 ERROR: Output running post install script for package kchmviewer-0:3.0-2.fc7.i386 ERROR: Output running post install script for package kdiff3-0:0.9.90-7.fc6.i386 ERROR: Output running post install script for package kdirstat-0:2.5.3-5.fc6.i386 ERROR: Output running post install script for package kio_sword-0:0.3-3.fc7.i386 ERROR: Output running post install script for package kita-0:0.177.3-10.fc7.1.i386 ERROR: Output running post install script for package klamav-0:0.41-2.fc7.i386 ERROR: Output running post install script for package knetstats-0:1.6.1-3.fc7.i386 ERROR: Output running post install script for package koverartist-0:0.5-7.fc7.i386 ERROR: Output running post install script for package kpolynome-0:0.1.2-9.fc7.i386 ERROR: Output running post install script for package krename-0:3.0.14-1.fc7.i386 ERROR: Output running post install script for package krusader-0:1.80.0-0.1.beta2.fc7.i386 ERROR: Output running post install script for package ksudoku-0:0.3-2.fc7.i386 ERROR: Output running post install script for package ldapjdk-0:4.17-1jpp.7.i386 ERROR: Output running post install script for package libannodex-0:0.7.3-7.fc7.i386 ERROR: Output running post install script for package libreadline-java-0:0.8.0-17.fc7.i386 ERROR: Output running post install script for package librx-devel-0:1.5-8.fc6.i386 ERROR: Output running post install script for package libswt3-gtk2-1:3.2.2-15.fc8.i386 ERROR: Output running post install script for package libvirt-0:0.2.3-1.fc8.i386 ERROR: Output running post install script for package liquidwar-0:5.6.3-3.fc7.i386 ERROR: Output running post install script for package log4j-0:1.2.14-3jpp.1.fc8.i386 ERROR: Output running post install script for package lucene-0:1.4.3-1jpp.18.i386 ERROR: Output running post install script for package machineball-0:1.0-2.fc7.i386 ERROR: Output running post install script for package magic-0:7.4.35-2.fc8.i386 ERROR: Output running post install script for package manaworld-0:0.0.22.2-1.fc7.i386 ERROR: Output running post install script for package manedit-0:0.8.1-1.fc7.1.i386 ERROR: Output running post install script for package maven-jxr-0:1.0-2jpp.2.fc7.i386 ERROR: Output running post install script for package maven-scm-0:1.0-0.1.b3.2jpp.1.fc7.i386 ERROR: Output running post install script for package maven-scm-test-0:1.0-0.1.b3.2jpp.1.fc7.i386 ERROR: Output running post install script for package maven-shared-0:1.0-4jpp.2.fc7.i386 ERROR: Output running post install script for package maven-shared-file-management-0:1.0-4jpp.2.fc7.i386 ERROR: Output running post install script for package maven-shared-plugin-testing-harness-0:1.0-4jpp.2.fc7.i386 ERROR: Output running post install script for package maven-surefire-0:1.5.3-2jpp.2.fc7.i386 ERROR: Output running post install script for package maven-surefire-booter-0:1.5.3-2jpp.2.fc7.i386 ERROR: Output running post install script for package maven2-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-ant-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-antlr-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-antrun-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-assembly-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-checkstyle-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-clean-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-compiler-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-dependency-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-deploy-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-ear-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-eclipse-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-ejb-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-help-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-idea-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-install-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-jar-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-javadoc-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-jxr-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-one-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-plugin-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-pmd-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-project-info-reports-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-rar-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-release-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-repository-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-resources-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-site-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-source-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-surefire-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-surefire-report-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package maven2-plugin-verifier-0:2.0.4-10jpp.6.fc7.i386 ERROR: Output running post install script for package mecab-ipadic-0:2.7.0.20070610-1.fc8.i386 ERROR: Output running post install script for package mecab-ipadic-EUCJP-0:2.7.0.20070610-1.fc8.i386 ERROR: Output running post install script for package mecab-jumandic-0:5.1.20070304-1.fc7.1.i386 ERROR: Output running post install script for package mecab-jumandic-EUCJP-0:5.1.20070304-1.fc7.1.i386 ERROR: Output running post install script for package mirrormagic-0:2.0.2-3.fc7.i386 ERROR: Output running post install script for package mod_nss-0:1.0.7-1.fc8.i386 ERROR: Output running post install script for package modello-0:1.0-0.1.a8.4jpp.3.fc7.noarch ERROR: Output running post install script for package monotone-server-0:0.35-3.fc7.i386 ERROR: Output running post install script for package mx4j-1:3.0.1-6jpp.4.i386 ERROR: Output running post install script for package mysql-connector-java-1:3.1.12-3.fc6.i386 ERROR: Output running post install script for package nethack-0:3.4.3-12.fc6.i386 ERROR: Output running post install script for package ngspice-doc-0:17-11.fc7.i386 ERROR: Output running post install script for package oki4linux-0:2.1gst-1.fc6.i386 ERROR: Output running post install script for package online-desktop-flickr-0:0.2.5-1.fc8.noarch ERROR: Output running post install script for package openlierox-0:0.57-0.4.beta2.fc8.i386 ERROR: Output running post install script for package openmpi-libs-0:1.2.3-2.fc8.i386 ERROR: Output running post install script for package paw-0:2006-15.fc8.i386 ERROR: Output running post install script for package pdns-0:2.9.21-1.fc7.i386 ERROR: Output running post install script for package pengupop-0:2.2.2-1.fc7.i386 ERROR: Output running post install script for package piccolo-0:1.04-2jpp.2.fc7.i386 ERROR: Output running post install script for package piklab-0:0.14.2-2.fc7.i386 ERROR: Output running post install script for package pikloops-0:0.2.1-6.fc6.i386 ERROR: Output running post install script for package pinball-0:0.3.1-7.fc7.i386 ERROR: Output running post install script for package pipenightdreams-0:0.10.0-5.fc6.i386 ERROR: Output running post install script for package pipepanic-0:0.1.3-2.fc7.i386 ERROR: Output running post install script for package plexus-ant-factory-0:1.0-0.1.a1.2jpp.2.fc7.i386 ERROR: Output running post install script for package plexus-appserver-0:1.0-0.1.a5.3jpp.2.fc7.i386 ERROR: Output running post install script for package plexus-archiver-0:1.0-0.1.a6.1jpp.1.fc7.i386 ERROR: Output running post install script for package plexus-bsh-factory-0:1.0-0.1.a7s.2jpp.2.fc7.i386 ERROR: Output running post install script for package plexus-cdc-0:1.0-0.1.a4.2jpp.2.fc7.i386 ERROR: Output running post install script for package plexus-maven-plugin-0:1.2-2jpp.1.fc7.i386 ERROR: Output running post install script for package plexus-runtime-builder-0:1.0-0.1.a9.2jpp.1.fc7.i386 ERROR: Output running post install script for package plexus-velocity-0:1.1.2-2jpp.1.fc7.i386 ERROR: Output running post install script for package plexus-xmlrpc-0:1.0-0.1.b4.3jpp.5.fc7.i386 ERROR: Output running post install script for package pop-before-smtp-0:1.41-2.fc6.noarch ERROR: Output running post install script for package postgresql-jdbc-0:8.2.504-1jpp.fc7.i386 ERROR: Output running post install script for package powerman-0:1.0.25-2.fc7.i386 ERROR: Output running post install script for package powermanga-0:0.80-4.fc8.i386 ERROR: Output running post install script for package professor-is-missing-0:0.1-3.fc8.noarch ERROR: Output running post install script for package pure-ftpd-selinux-0:1.0.21-12.fc7.i386 ERROR: Output running post install script for package puretls-0:0.9-0.b5.4jpp.1.i386 ERROR: Output running post install script for package puretls-demo-0:0.9-0.b5.4jpp.1.i386 ERROR: Output running post install script for package pypar2-0:1.4-1.fc8.noarch ERROR: Output running post install script for package qa-assistant-0:0.4.90.5-2.fc6.noarch ERROR: Output running post install script for package qalculate-kde-0:0.9.6-1.fc8.i386 ERROR: Output running post install script for package redet-0:8.22-4.fc8.noarch ERROR: Output running post install script for package regexp-0:1.4-3jpp.1.fc7.i386 ERROR: Output running post install script for package rogue-0:5.4.2-8.fc7.i386 ERROR: Output running post install script for package schismtracker-0:0.5-0.4.rc1.fc7.i386 ERROR: Output running post install script for package scorchwentbonkers-0:1.1-2.fc7.i386 ERROR: Output running post install script for package seahorse-adventures-0:1.0-1.fc7.noarch ERROR: Output running post install script for package sergueis-destiny-0:1.1-4.fc8.noarch ERROR: Output running post install script for package sinjdoc-0:0.5-4.fc7.i386 ERROR: Output running post install script for package six-0:0.5.3-4.fc7.i386 ERROR: Output running post install script for package snort-0:2.6.1.3-1.fc7.i386 ERROR: Output running post install script for package snort-plain+flexresp-0:2.6.1.3-1.fc7.i386 ERROR: Output running post install script for package snort-snmp+flexresp-0:2.6.1.3-1.fc7.i386 ERROR: Output running post install script for package snort-snmp-0:2.6.1.3-1.fc7.i386 ERROR: Output running post install script for package speedcrunch-0:0.7-1.fc7.i386 ERROR: Output running post install script for package spicctrl-0:1.9-5.fc7.i386 ERROR: Output running post install script for package squidGuard-0:1.2.0-15.fc7.i386 ERROR: Output running post install script for package struts-0:1.2.9-4jpp.6.i386 ERROR: Output running post install script for package sturmbahnfahrer-0:1.4-1.fc8.i386 ERROR: Output running post install script for package svnkit-0:1.1.2-2.fc8.i386 ERROR: Output running post install script for package t1lib-0:5.1.1-1.fc8.i386 ERROR: Output running post install script for package tagsoup-0:1.0.1-1jpp.1.fc7.i386 ERROR: Output running post install script for package tanukiwrapper-0:3.2.1-2jpp.3.i386 ERROR: Output running post install script for package taskjuggler-0:2.4.0-2.fc8.i386 ERROR: Output running post install script for package tecnoballz-0:0.91-5.fc7.i386 ERROR: Output running post install script for package tn5250-0:0.17.3-14.fc7.i386 ERROR: Output running post install script for package tomcat5-jsp-2.0-api-0:5.5.23-9jpp.2.fc7.i386 ERROR: Output running post install script for package tomcat5-servlet-2.4-api-0:5.5.23-9jpp.2.fc7.i386 ERROR: Output running post install script for package trackballs-0:1.1.4-1.fc8.i386 ERROR: Output running post install script for package tremulous-0:1.1.0-2.fc6.i386 ERROR: Output running post install script for package tuxpuck-0:0.8.2-3.fc7.i386 ERROR: Output running post install script for package ularn-0:1.5p4-8.fc7.i386 ERROR: Output running post install script for package util-vserver-0:0.30.213-1.fc8.i386 ERROR: Output running post install script for package util-vserver-build-0:0.30.213-1.fc8.i386 ERROR: Output running post install script for package velocity-0:1.4-6jpp.1.i386 ERROR: Output running post install script for package velocity-demo-0:1.4-6jpp.1.i386 ERROR: Output running post install script for package werken-xpath-0:0.9.4-0.beta.12jpp.2.i386 ERROR: Output running post install script for package widelands-0:0-0.4.build10.fc7.i386 ERROR: Output running post install script for package ws-commons-util-0:1.0.1-1.fc7.i386 ERROR: Output running post install script for package wsdl4j-0:1.5.2-4jpp.1.i386 ERROR: Output running post install script for package xalan-j2-0:2.7.0-6jpp.1.i386 ERROR: Output running post install script for package xalan-j2-demo-0:2.7.0-6jpp.1.i386 ERROR: Output running post install script for package xalan-j2-xsltc-0:2.7.0-6jpp.1.i386 ERROR: Output running post install script for package xblast-common-0:2.10.4-3.fc8.i386 ERROR: Output running post install script for package xcircuit-0:3.4.26-20.fc7.i386 ERROR: Output running post install script for package xdoclet-0:1.2.3-7jpp.3.i386 ERROR: Output running post install script for package xemacs-nox-0:21.5.28-4.fc8.i386 ERROR: Output running post install script for package xerces-j2-0:2.7.1-7jpp.2.i386 ERROR: Output running post install script for package xerces-j2-demo-0:2.7.1-7jpp.2.i386 ERROR: Output running post install script for package xeuphoric-0:0.18.2-7.fc8.i386 ERROR: Output running post install script for package xjavadoc-0:1.1-4jpp.2.i386 ERROR: Output running post install script for package xml-commons-apis-0:1.3.03-0jpp.1.fc7.i386 ERROR: Output running post install script for package xml-commons-apis12-0:1.2.04-0jpp.4.fc8.i386 ERROR: Output running post install script for package xml-commons-resolver-0:1.1-1jpp.12.i386 ERROR: Output running post install script for package xml-commons-which-1:1.0-0.b2.0jpp.2.i386 ERROR: Output running post install script for package xmldb-api-1:0.1-0.1.20011111cvs.1jpp.2.fc7.i386 ERROR: Output running post install script for package xmlrpc-0:2.0.1-3jpp.2.i386 ERROR: Output running post install script for package xorg-x11-fonts-misc-0:7.2-1.fc8.noarch ERROR: Output running post install script for package xpilot-ng-selinux-0:4.7.2-12.fc7.i386 ERROR: Output running post install script for package xtide-0:2.9.3-3.fc8.i386 ERROR: Output running post install script for package zile-0:2.2.19-1.fc6.i386 From aportal at univ-montp2.fr Tue Jul 10 08:57:42 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Tue, 10 Jul 2007 10:57:42 +0200 Subject: rpm installation tests / script tests In-Reply-To: <20070710083111.GA3194@dudweiler.stuttgart.redhat.com> References: <20070710083111.GA3194@dudweiler.stuttgart.redhat.com> Message-ID: <200707101057.42461.aportal@univ-montp2.fr> Le Tuesday 10 July 2007 10:31:11 Florian La Roche, vous avez ?crit?: > We have run rpm install tests where each rpm in > Fedora-development is resolved to its minimal > required dependencies and then installed and also > deinstalled completely within an otherwise empty > chroot-environment. > > The Fedora tree used is from July 4th. Complete output > from the test is at http://people.redhat.com/laroche/installtest.gz > Most problems are not found in core packages part of a > default Fedora install and most are only minor things > overall, but we could still use this list of refine the > proposed scripts as part of the packaging guidelines and > also use this as package sanity check. > > Many packaging problems found by this test have been already > corrected before the core/extras merge, so this is also more > about regressions than a completely new test. Also some problems > found in the below test are already corrected in todays rawhide > release. > ERROR: Output running post install script for package > kbackup-0:0.5.1-2.fc6.i386 > ERROR: Output running post install script for package > piklab-0:0.14.2-2.fc7.i386 > ERROR: Output running post install script for > package pikloops-0:0.2.1-6.fc6.i386 This is the same error for the 3 packages ERROR: Output running post uninstall script for package piklab-0:0.14.2-2.fc7.i386 /var/tmp/rpm-tmp.TpqGGv: line 2: /usr/bin/gtk-update-icon-cache: No such file or directory but http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda said "Note that no dependencies should be added for this." So, what we have to do? Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr -------------- 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 Tue Jul 10 11:26:41 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 10 Jul 2007 06:26:41 -0500 Subject: rpm installation tests / script tests References: <20070710083111.GA3194@dudweiler.stuttgart.redhat.com> <200707101057.42461.aportal@univ-montp2.fr> Message-ID: <200707101126.l6ABQfbm025246@mathstat.unl.edu> Alain PORTAL wrote: > This is the same error for the 3 packages > ERROR: Output running post uninstall script for package > piklab-0:0.14.2-2.fc7.i386 > /var/tmp/rpm-tmp.TpqGGv: line 2: /usr/bin/gtk-update-icon-cache: No such > file or directory > > but > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda > said "Note that no dependencies should be added for this." > > So, what we have to do? Hrm, looks like an oversight in the guidelines... should probably wrap the call in something like: 1. if [ -x /usr/bin/gtk-update-icon-cache ]; then ... or 2. redirect output (using something like >& /dev/null (I use the latter mostly). -- Rex From jima at beer.tclug.org Tue Jul 10 13:24:41 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 10 Jul 2007 08:24:41 -0500 (CDT) Subject: Fever available for all packages In-Reply-To: <200707092237.10911.opensource@till.name> References: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> <200707091905.58838.opensource@till.name> <668bb39a0707091311p41f436ecrfc1a6b99b54dd326@mail.gmail.com> <200707092237.10911.opensource@till.name> Message-ID: On Mon, 9 Jul 2007, Till Maas wrote: > On Mo Juli 9 2007, Micha? Bentkowski wrote: >> You may be right. However, I think that it would be better to have >> fever directory in cvs with everybody permitted to edit this (like >> owners some time ago). What do you think? > > Where do you see the advantages of this approach? The only one I see, is that > it is easier (i.e. it is faster and need less network traffic, unless you > already have a complete up-to-date cvs tree) to collect all regular > expressions. Agreed. > But the disadvantages are, that it is much easier to create a conflict > (at least there is a warning in the comps howto, that one should update > before and after one edited the file, but I do not know, whether or not > CVS detects conflicts), every maintainer needs to monitor this file to > make sure, that the regular expressions of his packages are not > (accidently) destroyed. As I recall, CVS has a little bit better conflict detection than the wiki. Each file has a revision ID. When you check out a file, edit it, and commit it, CVS creates a log with the current and new revision numbers. If your interpretation of the current revision number isn't the same as the one in the CVS repository, it errors out telling you as much. I specifically recall this happening while editing owners.list during a busy period. :-) If we were going with the one-CVS-module approach, I'd at least keep each package's regexp in their own file (fever/package.txt instead of package/fever.txt or whatnot). That would reduce conflicts to almost nothing. Jima From lxtnow at gmail.com Tue Jul 10 15:03:42 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Tue, 10 Jul 2007 11:03:42 -0400 Subject: koji failed to build srpm file [missing file] Message-ID: <62bc09df0707100803k72fb37cdkfe22a820a3dedcf2@mail.gmail.com> Hi folks, After updated the spec files and added a new patch (cvs add patch_file) and then cvs commit'ed. koji fails to build the srpm file: the error is that its doesn't find the patch i just added. After done an cvs checkout, this patch file has been well imported. ---------------------------------------------------------------------------------------------------- ]$ cvs co gnome-sharp cvs checkout: Updating gnome-sharp U gnome-sharp/Makefile U gnome-sharp/import.log U gnome-sharp/pkg.acl cvs checkout: Updating gnome-sharp/F-7 U gnome-sharp/F-7/.cvsignore U gnome-sharp/F-7/Makefile U gnome-sharp/F-7/branch U gnome-sharp/F-7/gnome-sharp-2.15.0-libdir.patch U gnome-sharp/F-7/gnome-sharp-2.16.0-automake-1.10.patch U gnome-sharp/F-7/gnome-sharp.spec U gnome-sharp/F-7/sources cvs checkout: Updating gnome-sharp/devel U gnome-sharp/devel/.cvsignore U gnome-sharp/devel/Makefile U gnome-sharp/devel/gnome-sharp-2.15.0-libdir.patch U gnome-sharp/devel/gnome-sharp-2.16.0-automake-1.10.patch U gnome-sharp/devel/gnome-sharp.spec U gnome-sharp/devel/sources cvs checkout: Updating common U common/Makefile U common/Makefile.common U common/branches U common/cvs-import.sh -------------------------------------------------------------------------------------------------------------- -- 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 mikeb at redhat.com Tue Jul 10 15:08:25 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 10 Jul 2007 11:08:25 -0400 Subject: koji failed to build srpm file [missing file] In-Reply-To: <62bc09df0707100803k72fb37cdkfe22a820a3dedcf2@mail.gmail.com> References: <62bc09df0707100803k72fb37cdkfe22a820a3dedcf2@mail.gmail.com> Message-ID: <1184080105.7724.12.camel@liffey.home> On Tue, 2007-07-10 at 11:03 -0400, SmootherFrOgZ wrote: > Hi folks, > > After updated the spec files and added a new patch (cvs add > patch_file) and then cvs commit'ed. > koji fails to build the srpm file: > the error is that its doesn't find the patch i just added. Did you bump the revision in the spec file and run "make tag" after you added the file? From lxtnow at gmail.com Tue Jul 10 15:13:30 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Tue, 10 Jul 2007 11:13:30 -0400 Subject: koji failed to build srpm file [missing file] In-Reply-To: <1184080105.7724.12.camel@liffey.home> References: <62bc09df0707100803k72fb37cdkfe22a820a3dedcf2@mail.gmail.com> <1184080105.7724.12.camel@liffey.home> Message-ID: <62bc09df0707100813y5b939e8an8443949fc929bf45@mail.gmail.com> 2007/7/10, Mike Bonnet : > > On Tue, 2007-07-10 at 11:03 -0400, SmootherFrOgZ wrote: > > Hi folks, > > > > After updated the spec files and added a new patch (cvs add > > patch_file) and then cvs commit'ed. > > koji fails to build the srpm file: > > the error is that its doesn't find the patch i just added. > > Did you bump the revision in the spec file and run "make tag" after you > added the file? yep, it has been tagged to *-2 before run make build. -- > 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 dennis at ausil.us Tue Jul 10 15:18:06 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 10 Jul 2007 10:18:06 -0500 Subject: koji failed to build srpm file [missing file] In-Reply-To: <62bc09df0707100813y5b939e8an8443949fc929bf45@mail.gmail.com> References: <62bc09df0707100803k72fb37cdkfe22a820a3dedcf2@mail.gmail.com> <1184080105.7724.12.camel@liffey.home> <62bc09df0707100813y5b939e8an8443949fc929bf45@mail.gmail.com> Message-ID: <200707101018.07116.dennis@ausil.us> On Tuesday 10 July 2007 10:13:30 am SmootherFrOgZ wrote: > 2007/7/10, Mike Bonnet : > > On Tue, 2007-07-10 at 11:03 -0400, SmootherFrOgZ wrote: > > > Hi folks, > > > > > > After updated the spec files and added a new patch (cvs add > > > patch_file) and then cvs commit'ed. > > > koji fails to build the srpm file: > > > the error is that its doesn't find the patch i just added. > > > > Did you bump the revision in the spec file and run "make tag" after you > > added the file? > > yep, it has been tagged to *-2 before run make build. > > -- > > > Fedora-maintainers mailing list > > Fedora-maintainers at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-maintainers http://cvs.fedora.redhat.com/viewcvs/rpms/gnome-sharp/devel/?root=extras shows that your patch is not tagged bump, tag and try again Dennis From david at lovesunix.net Tue Jul 10 15:58:40 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 10 Jul 2007 17:58:40 +0200 Subject: Orphaning ndesk-dbus and empathy Message-ID: <1184083120.11501.18.camel@dawkins.stavtrup-st.dk> I'm orphaning ndesk-dbus (managed C# DBUs implementation) and empathy (Telepathy IM client). - 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 tibbs at math.uh.edu Tue Jul 10 16:09:32 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 10 Jul 2007 11:09:32 -0500 Subject: Orphaning ndesk-dbus and empathy In-Reply-To: <1184083120.11501.18.camel@dawkins.stavtrup-st.dk> References: <1184083120.11501.18.camel@dawkins.stavtrup-st.dk> Message-ID: >>>>> "DN" == David Nielsen writes: DN> I'm orphaning ndesk-dbus (managed C# DBUs implementation) and DN> empathy (Telepathy IM client). I don't quite understand the point of getting a package in the distro and then orphaning it less than a week later. Could we at least have an explanation of what's happened with this package? - J< From david at lovesunix.net Tue Jul 10 17:21:19 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 10 Jul 2007 19:21:19 +0200 Subject: Orphaning ndesk-dbus and empathy In-Reply-To: References: <1184083120.11501.18.camel@dawkins.stavtrup-st.dk> Message-ID: <1184088079.11501.37.camel@dawkins.stavtrup-st.dk> tir, 10 07 2007 kl. 11:09 -0500, skrev Jason L Tibbitts III: > >>>>> "DN" == David Nielsen writes: > > DN> I'm orphaning ndesk-dbus (managed C# DBUs implementation) and > DN> empathy (Telepathy IM client). > > I don't quite understand the point of getting a package in the distro > and then orphaning it less than a week later. Could we at least have > an explanation of what's happened with this package? Nothing has happened with the package as such, I however had a significant setback healthwise over the weekend which will require me to restructure my life a bit and overall scale back my computer time. It thus seems better to me that the packages go to someone who will give them the love they deserve when I'm not able to. I apologize for the timing, I figured it would not be prudent to fill an orphaning message with personal information in the first place. - David -------------- 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 bpepple at fedoraproject.org Tue Jul 10 17:41:49 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 10 Jul 2007 13:41:49 -0400 Subject: Orphaning ndesk-dbus and empathy In-Reply-To: <1184088079.11501.37.camel@dawkins.stavtrup-st.dk> References: <1184083120.11501.18.camel@dawkins.stavtrup-st.dk> <1184088079.11501.37.camel@dawkins.stavtrup-st.dk> Message-ID: <1184089309.6118.10.camel@kennedy> On Tue, 2007-07-10 at 19:21 +0200, David Nielsen wrote: > Nothing has happened with the package as such, I however had a > significant setback healthwise over the weekend which will require me to > restructure my life a bit and overall scale back my computer time. It > thus seems better to me that the packages go to someone who will give > them the love they deserve when I'm not able to. > > I apologize for the timing, I figured it would not be prudent to fill an > orphaning message with personal information in the first place. David, totally understandable. Take care of yourself. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 jspaleta at gmail.com Tue Jul 10 17:43:20 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 10 Jul 2007 09:43:20 -0800 Subject: Orphaning ndesk-dbus and empathy In-Reply-To: <1184088079.11501.37.camel@dawkins.stavtrup-st.dk> References: <1184083120.11501.18.camel@dawkins.stavtrup-st.dk> <1184088079.11501.37.camel@dawkins.stavtrup-st.dk> Message-ID: <604aa7910707101043g4a626c4bxf37de4b80db28213@mail.gmail.com> On 7/10/07, David Nielsen wrote: > I apologize for the timing, I figured it would not be prudent to fill an > orphaning message with personal information in the first place. Thanks for the explanation and for taking the time to let us know these are being orphaned. Unplanned life changes, especially healthwise, are never comfortable to talk about in public. Give me a couple of days to get up to speed on empathy, and I'll see if I can take it over, if someone else more...empathetic...to the program doesn't step up first. -jef From dennis at ausil.us Tue Jul 10 20:39:09 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 10 Jul 2007 15:39:09 -0500 Subject: spam-o-matic Message-ID: <200707101539.10087.dennis@ausil.us> Hey All, when testing the spam-o-matic script that sends out notifications for broken dependencies it was accidentally run without the --nomail flag in addition to not being pointed at a RHEL tree. which resulted in messages sent that should not have been. We are terribly sorry for the noise and will try to never ever do it again. Thank you for your patience and understanding Dennis From mr.ecik at gmail.com Tue Jul 10 21:15:18 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Tue, 10 Jul 2007 23:15:18 +0200 Subject: Fever available for all packages In-Reply-To: References: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> <200707091905.58838.opensource@till.name> <668bb39a0707091311p41f436ecrfc1a6b99b54dd326@mail.gmail.com> <200707092237.10911.opensource@till.name> Message-ID: <668bb39a0707101415o4c550deaj72593b5eaa05b273@mail.gmail.com> 2007/7/10, Jima : > If we were going with the one-CVS-module approach, I'd at least keep each > package's regexp in their own file (fever/package.txt instead of > package/fever.txt or whatnot). That would reduce conflicts to almost > nothing. > > Jima This seems to be the best way for me. -- Micha? Bentkowski mr.ecik at gmail.com From limb at jcomserv.net Tue Jul 10 21:33:34 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 10 Jul 2007 16:33:34 -0500 (CDT) Subject: [Fwd: Broken dependencies: roundcubemail] Message-ID: <36748.216.9.250.109.1184103214.squirrel@mail.jcomserv.net> Anyone have any idea what this might be about? I built roundcubemail on the assumption RHEL5 had httpd, php, and sh. :) Sorry for top posting, I'm on a PDA. . . ---------------------------- Original Message ---------------------------- Subject: Broken dependencies: roundcubemail From: "root" Date: Tue, July 10, 2007 2:59 pm To: limb at fedoraproject.org Cc: jorton at fedoraproject.org -------------------------------------------------------------------------- roundcubemail has broken dependencies in the development tree: On ppc: roundcubemail - 0.1-0.6rc1.1.el5.noarch requires php roundcubemail - 0.1-0.6rc1.1.el5.noarch requires /bin/sh roundcubemail - 0.1-0.6rc1.1.el5.noarch requires httpd On x86_64: roundcubemail - 0.1-0.6rc1.1.el5.noarch requires php roundcubemail - 0.1-0.6rc1.1.el5.noarch requires /bin/sh roundcubemail - 0.1-0.6rc1.1.el5.noarch requires httpd On i386: roundcubemail - 0.1-0.6rc1.1.el5.noarch requires php roundcubemail - 0.1-0.6rc1.1.el5.noarch requires /bin/sh roundcubemail - 0.1-0.6rc1.1.el5.noarch requires httpd Please resolve this as soon as possible. -- novus ordo absurdum From mmcgrath at redhat.com Tue Jul 10 21:47:16 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 10 Jul 2007 16:47:16 -0500 Subject: [Fwd: Broken dependencies: roundcubemail] In-Reply-To: <36748.216.9.250.109.1184103214.squirrel@mail.jcomserv.net> References: <36748.216.9.250.109.1184103214.squirrel@mail.jcomserv.net> Message-ID: <4693FE64.1070100@redhat.com> Jon Ciesla wrote: > Anyone have any idea what this might be about? I built roundcubemail on > the assumption RHEL5 had httpd, php, and sh. :) > Yep, blame that one on me. Sorry, please forgive :) -Mike From laroche at redhat.com Wed Jul 11 08:53:07 2007 From: laroche at redhat.com (Florian La Roche) Date: Wed, 11 Jul 2007 10:53:07 +0200 Subject: [rdieter@math.unl.edu: Re: rpm installation tests / script tests] Message-ID: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> Hello all, anything holding back an update of the default snippets we propose for Fedora until a more permanent solution in rpm/tools is available? regards, Florian La Roche ----- Forwarded message from Rex Dieter ----- From: Rex Dieter Subject: Re: rpm installation tests / script tests To: fedora-maintainers at redhat.com Date: Tue, 10 Jul 2007 06:26:41 -0500 Alain PORTAL wrote: > This is the same error for the 3 packages > ERROR: Output running post uninstall script for package > piklab-0:0.14.2-2.fc7.i386 > /var/tmp/rpm-tmp.TpqGGv: line 2: /usr/bin/gtk-update-icon-cache: No such > file or directory > > but > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda > said "Note that no dependencies should be added for this." > > So, what we have to do? Hrm, looks like an oversight in the guidelines... should probably wrap the call in something like: 1. if [ -x /usr/bin/gtk-update-icon-cache ]; then ... or 2. redirect output (using something like >& /dev/null (I use the latter mostly). -- Rex -- Fedora-maintainers mailing list Fedora-maintainers at redhat.com https://www.redhat.com/mailman/listinfo/fedora-maintainers ----- End forwarded message ----- From rdieter at math.unl.edu Wed Jul 11 12:41:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 11 Jul 2007 07:41:55 -0500 Subject: rpm installation tests / script tests References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> Message-ID: Florian La Roche wrote: > anything holding back an update of the default snippets we > propose for Fedora until a more permanent solution in > rpm/tools is available? The Snippets wiki has been updated, after getting feedback on the fedora-desktop list. -- Rex > ----- Forwarded message from Rex Dieter ----- > > From: Rex Dieter > Subject: Re: rpm installation tests / script tests > To: fedora-maintainers at redhat.com > Date: Tue, 10 Jul 2007 06:26:41 -0500 > > Alain PORTAL wrote: > > >> This is the same error for the 3 packages >> ERROR: Output running post uninstall script for package >> piklab-0:0.14.2-2.fc7.i386 >> /var/tmp/rpm-tmp.TpqGGv: line 2: /usr/bin/gtk-update-icon-cache: No such >> file or directory >> >> but >> > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda >> said "Note that no dependencies should be added for this." >> >> So, what we have to do? > > Hrm, looks like an oversight in the guidelines... should probably wrap the > call in something like: > 1. if [ -x /usr/bin/gtk-update-icon-cache ]; then ... > or > 2. redirect output (using something like >& /dev/null > (I use the latter mostly). > > -- Rex From laroche at redhat.com Wed Jul 11 12:51:40 2007 From: laroche at redhat.com (Florian La Roche) Date: Wed, 11 Jul 2007 14:51:40 +0200 Subject: rpm installation tests / script tests In-Reply-To: References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> Message-ID: <20070711125140.GA9625@dudweiler.stuttgart.redhat.com> On Wed, Jul 11, 2007 at 07:41:55AM -0500, Rex Dieter wrote: > Florian La Roche wrote: > > > anything holding back an update of the default snippets we > > propose for Fedora until a more permanent solution in > > rpm/tools is available? > > The Snippets wiki has been updated, after getting feedback on the > fedora-desktop list. Hello Rex, great news, very good. Thanks, Florian La Roche From fedora at leemhuis.info Wed Jul 11 13:10:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 11 Jul 2007 15:10:45 +0200 Subject: rpm installation tests / script tests In-Reply-To: <20070711125140.GA9625@dudweiler.stuttgart.redhat.com> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711125140.GA9625@dudweiler.stuttgart.redhat.com> Message-ID: <4694D6D5.1000707@leemhuis.info> On 11.07.2007 14:51, Florian La Roche wrote: > On Wed, Jul 11, 2007 at 07:41:55AM -0500, Rex Dieter wrote: >> Florian La Roche wrote: >> >>> anything holding back an update of the default snippets we >>> propose for Fedora until a more permanent solution in >>> rpm/tools is available? >> The Snippets wiki has been updated, after getting feedback on the >> fedora-desktop list. > great news, very good. +1, but will somebody kind of "enforce" this? Sure, it's no big problems, but nevertheless would be nice to get fixed. How about a (script based?) change directly in cvs for all packages that follow exactly what was in the "Snippets wiki" until now or was similar to it? That would be just a bit of work for one person (yes, I'm volunteering to do that if FESCo backs the idea; no, I'm not willing to write a proposal for FESCo to discuss that, as that often is way more work then actually doing the change), no boring work for packagers and the problem will actually vanish then soon (?). Alternative would be to sun a spam-o-magic script that pokes people regularly until they fix stuff is getting fixed. CU thl P.S.: The problem is a general one. I tend to say adjustments to the guidelines that can be adjusted by a script in all the packages should be done scripted after a warning period where people can adjust it manually if they want. (?) -- I now and then stumbled over packages where parts were not adjusted to the latest guidelines even months or a years after the guidelines were changed (yes, sometimes that were my own packages...) From mcepl at redhat.com Tue Jul 10 20:30:40 2007 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 10 Jul 2007 22:30:40 +0200 Subject: [Fwd: Broken dependencies: JSDoc] Message-ID: <1184099440.7860.4.camel@chelcicky.vysocina> Could anybody explain me, what I am supposed to do with this? Thanks, Mat?j -- http://www.ceplovi.cz/matej/blog/, Jabber: ceplmajabber.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC America is the only country that has gone from barbarism to decadence without civilization in between. -- Oscar Wilde -------- P?eposlan? zpr?va -------- Od: root Komu: mcepl at fedoraproject.org Kopie: rnorwood at fedoraproject.org P?edm?t: Broken dependencies: JSDoc Datum: Tue, 10 Jul 2007 12:59:45 -0700 JSDoc has broken dependencies in the development tree: On ppc: JSDoc - 1.10.2-3.el5.noarch requires perl(vars) JSDoc - 1.10.2-3.el5.noarch requires perl(Getopt::Long) JSDoc - 1.10.2-3.el5.noarch requires /usr/bin/perl JSDoc - 1.10.2-3.el5.noarch requires perl(HTML::Template) JSDoc - 1.10.2-3.el5.noarch requires perl(Data::Dumper) JSDoc - 1.10.2-3.el5.noarch requires perl(constant) JSDoc - 1.10.2-3.el5.noarch requires perl >= 0:5.000 JSDoc - 1.10.2-3.el5.noarch requires perl(File::Find) JSDoc - 1.10.2-3.el5.noarch requires perl(warnings) JSDoc - 1.10.2-3.el5.noarch requires perl(strict) JSDoc - 1.10.2-3.el5.noarch requires perl(File::Path) JSDoc - 1.10.2-3.el5.noarch requires perl(lib) JSDoc - 1.10.2-3.el5.noarch requires perl(File::Copy) JSDoc - 1.10.2-3.el5.noarch requires perl(Exporter) JSDoc - 1.10.2-3.el5.noarch requires perl(File::Basename) On x86_64: JSDoc - 1.10.2-3.el5.noarch requires perl(vars) JSDoc - 1.10.2-3.el5.noarch requires perl(Getopt::Long) JSDoc - 1.10.2-3.el5.noarch requires /usr/bin/perl JSDoc - 1.10.2-3.el5.noarch requires perl(HTML::Template) JSDoc - 1.10.2-3.el5.noarch requires perl(Data::Dumper) JSDoc - 1.10.2-3.el5.noarch requires perl(constant) JSDoc - 1.10.2-3.el5.noarch requires perl >= 0:5.000 JSDoc - 1.10.2-3.el5.noarch requires perl(File::Find) JSDoc - 1.10.2-3.el5.noarch requires perl(warnings) JSDoc - 1.10.2-3.el5.noarch requires perl(strict) JSDoc - 1.10.2-3.el5.noarch requires perl(File::Path) JSDoc - 1.10.2-3.el5.noarch requires perl(lib) JSDoc - 1.10.2-3.el5.noarch requires perl(File::Copy) JSDoc - 1.10.2-3.el5.noarch requires perl(Exporter) JSDoc - 1.10.2-3.el5.noarch requires perl(File::Basename) On i386: JSDoc - 1.10.2-3.el5.noarch requires perl(vars) JSDoc - 1.10.2-3.el5.noarch requires perl(Getopt::Long) JSDoc - 1.10.2-3.el5.noarch requires /usr/bin/perl JSDoc - 1.10.2-3.el5.noarch requires perl(HTML::Template) JSDoc - 1.10.2-3.el5.noarch requires perl(Data::Dumper) JSDoc - 1.10.2-3.el5.noarch requires perl(constant) JSDoc - 1.10.2-3.el5.noarch requires perl >= 0:5.000 JSDoc - 1.10.2-3.el5.noarch requires perl(File::Find) JSDoc - 1.10.2-3.el5.noarch requires perl(warnings) JSDoc - 1.10.2-3.el5.noarch requires perl(strict) JSDoc - 1.10.2-3.el5.noarch requires perl(File::Path) JSDoc - 1.10.2-3.el5.noarch requires perl(lib) JSDoc - 1.10.2-3.el5.noarch requires perl(File::Copy) JSDoc - 1.10.2-3.el5.noarch requires perl(Exporter) JSDoc - 1.10.2-3.el5.noarch requires perl(File::Basename) Please resolve this as soon as possible. From jkeating at redhat.com Wed Jul 11 13:07:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Jul 2007 09:07:16 -0400 Subject: [Fwd: Broken dependencies: JSDoc] In-Reply-To: <1184099440.7860.4.camel@chelcicky.vysocina> References: <1184099440.7860.4.camel@chelcicky.vysocina> Message-ID: <200707110907.19086.jkeating@redhat.com> On Tuesday 10 July 2007 16:30:40 Matej Cepl wrote: > Could anybody explain me, what I am supposed to do with this? It was a misfire that Dennis Gilmore posted about 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 mcepl at redhat.com Wed Jul 11 13:45:36 2007 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 11 Jul 2007 15:45:36 +0200 Subject: multiple .po files in one package -- how to do it in SPEC file? bug 230316 Message-ID: <1184161536.12944.16.camel@localhost6.localdomain6> Hi, I am in the process of my package for jbrout (quite interesting photo collection manager) being reviewed and both me and apparently reviewer got totally lost in handling .po files. The package has multiple .po files and I haven't figured out easy way how to compile them all into one .po file which should be compiled into .mo file and then installed, but all that for multiple languages, and ... so I see three ways out of this mess: 1) to play with with find/bash/msgcat/msgattr/etc. with result being probably steaming heap of bash scripts horrible to maintain and incomprehensible to anybody 2) to do the same with Python -- probably much more elegant solution, but more work 3) somebody has already done 2) (or with other scripting language) Could somebody more knowledgeable with packaging RPMs help me to find out way to the light? Thanks a lot, Mat?j Cepl -- http://www.ceplovi.cz/matej/blog/, Jabber: ceplmajabber.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC In political activity men sail a boundless and bottomless sea; there is neither harbor for shelter nor floor for anchorage, neither starting point nor appointed destination. -- Michael Oakeshott: Rationalism in Politics From belegdol at gmail.com Wed Jul 11 13:48:13 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Wed, 11 Jul 2007 14:48:13 +0100 Subject: multiple .po files in one package -- how to do it in SPEC file? bug 230316 In-Reply-To: <1184161536.12944.16.camel@localhost6.localdomain6> References: <1184161536.12944.16.camel@localhost6.localdomain6> Message-ID: <9b1b20e70707110648g495e37a8pbc181e412511d698@mail.gmail.com> 2007/7/11, Matej Cepl : > Hi, > > I am in the process of my package for jbrout (quite interesting > photo collection manager) being reviewed and both me and apparently > reviewer got totally lost in handling .po files. The package has > multiple .po files and I haven't figured out easy way how to compile > them all into one .po file which should be compiled into .mo file and > then installed, but all that for multiple languages, and ... so I see > three ways out of this mess: > > 1) to play with with find/bash/msgcat/msgattr/etc. with result being > probably steaming heap of bash scripts horrible to maintain and > incomprehensible to anybody > 2) to do the same with Python -- probably much more elegant solution, > but more work > 3) somebody has already done 2) (or with other scripting language) > > Could somebody more knowledgeable with packaging RPMs help me to find > out way to the light? > > Thanks a lot, > > Mat?j Cepl > > -- > http://www.ceplovi.cz/matej/blog/, Jabber: ceplmajabber.cz > GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC > > In political activity men sail a boundless and bottomless sea; > there is neither harbor for shelter nor floor for anchorage, > neither starting point nor appointed destination. > -- Michael Oakeshott: Rationalism in Politics > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Why do you want to merge the files? Just installing all of them should be fine. From opensource at till.name Wed Jul 11 13:19:19 2007 From: opensource at till.name (Till Maas) Date: Wed, 11 Jul 2007 15:19:19 +0200 Subject: Fever available for all packages In-Reply-To: <668bb39a0707101415o4c550deaj72593b5eaa05b273@mail.gmail.com> References: <668bb39a0707090804s6ee7f7b1xf34106bce62a842a@mail.gmail.com> <668bb39a0707101415o4c550deaj72593b5eaa05b273@mail.gmail.com> Message-ID: <200707111519.20351.opensource@till.name> On Di Juli 10 2007, Micha? Bentkowski wrote: > 2007/7/10, Jima : > > If we were going with the one-CVS-module approach, I'd at least keep > > each package's regexp in their own file (fever/package.txt instead of > > package/fever.txt or whatnot). That would reduce conflicts to almost > > nothing. > > > > Jima > > This seems to be the best way for me. How about using package/fever.txt as the interface to the packager and creating a fever/package.txt file somewhere with a post-commit hook, that checks whether or not there was a change to package/fever.txt and when there was copies the file to fever.package.txt? Imho the fever regex belongs to the package and not to the repository. And with a package/fever.txt it would be possible to create a makefile target that shows whether or not the latest version is already in the spec, which may be useful, too. Regards, Till From P at draigBrady.com Wed Jul 11 14:05:05 2007 From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=) Date: Wed, 11 Jul 2007 15:05:05 +0100 Subject: multiple .po files in one package -- how to do it in SPEC file? bug 230316 In-Reply-To: <1184161536.12944.16.camel@localhost6.localdomain6> References: <1184161536.12944.16.camel@localhost6.localdomain6> Message-ID: <4694E391.6030208@draigBrady.com> multiple pot files you mean? How about `msgcomm --more-than=0 *.po` ? P?draig. From mcepl at redhat.com Wed Jul 11 14:11:13 2007 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 11 Jul 2007 16:11:13 +0200 Subject: multiple .po files in one package -- how to do it in SPEC file? bug 230316 In-Reply-To: <4694E391.6030208@draigBrady.com> References: <1184161536.12944.16.camel@localhost6.localdomain6> <4694E391.6030208@draigBrady.com> Message-ID: <1184163073.12944.22.camel@localhost6.localdomain6> P?draig Brady p??e v St 11. 07. 2007 v 15:05 +0100: > multiple pot files you mean? > How about `msgcomm --more-than=0 *.po` ? No, jbrout has some plugins which have their own separate .po files: [matej at hubmaier jbrout]$ find . -name \*.po\* ./plugins/multiexport/po/plugin.pot ./plugins/multiexport/po/fr/LC_MESSAGES/plugin.po ./plugins/openExplorer/po/plugin.pot ./plugins/openExplorer/po/fr/LC_MESSAGES/plugin.po ./plugins/redate/po/plugin.pot ./plugins/redate/po/fr/LC_MESSAGES/plugin.po ./plugins/foldersByDates/po/plugin.pot ./plugins/foldersByDates/po/fr/LC_MESSAGES/plugin.po ./plugins/rotate/po/plugin.pot ./plugins/rotate/po/fr/LC_MESSAGES/plugin.po ./plugins/instantWeb/po/plugin.pot ./plugins/instantWeb/po/fr/LC_MESSAGES/plugin.po ./plugins/comment/po/plugin.pot ./plugins/comment/po/fr/LC_MESSAGES/plugin.po ./po/jbrout.pot ./po/fr/LC_MESSAGES/jbrout.po [matej at hubmaier jbrout]$ What's the difference between msgcomm and msgcat for me? Thanks for reply, Mat?j -- http://www.ceplovi.cz/matej/blog/, Jabber: ceplmajabber.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC It would be very good idea. -- Gandhi, when asked what he thinks about Western civilization? From laroche at redhat.com Wed Jul 11 14:40:31 2007 From: laroche at redhat.com (Florian La Roche) Date: Wed, 11 Jul 2007 16:40:31 +0200 Subject: rpm installation tests / script tests In-Reply-To: <4694D6D5.1000707@leemhuis.info> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711125140.GA9625@dudweiler.stuttgart.redhat.com> <4694D6D5.1000707@leemhuis.info> Message-ID: <20070711144031.GA11209@dudweiler.stuttgart.redhat.com> On Wed, Jul 11, 2007 at 03:10:45PM +0200, Thorsten Leemhuis wrote: > > > On 11.07.2007 14:51, Florian La Roche wrote: > > On Wed, Jul 11, 2007 at 07:41:55AM -0500, Rex Dieter wrote: > >> Florian La Roche wrote: > >> > >>> anything holding back an update of the default snippets we > >>> propose for Fedora until a more permanent solution in > >>> rpm/tools is available? > >> The Snippets wiki has been updated, after getting feedback on the > >> fedora-desktop list. > > great news, very good. > > +1, but will somebody kind of "enforce" this? Sure, it's no big > problems, but nevertheless would be nice to get fixed. > > How about a (script based?) change directly in cvs for all packages that > follow exactly what was in the "Snippets wiki" until now or was similar > to it? > > That would be just a bit of work for one person (yes, I'm volunteering > to do that if FESCo backs the idea; no, I'm not willing to write a > proposal for FESCo to discuss that, as that often is way more work then > actually doing the change), no boring work for packagers and the problem > will actually vanish then soon (?). Hello Thorsten, +1 to get such things very fast into cvs and new packages built. Usually most package owners are ok with such "packaging changes", but there is no official process for this until now. > > Alternative would be to sun a spam-o-magic script that pokes people > regularly until they fix stuff is getting fixed. We all enjoy nag mails and huge amounts of new bugzilla requests. Maybe we'll also find smart ways with cvs commits across all packages at some point. regards, Florian La Roche > > CU > thl > > P.S.: The problem is a general one. I tend to say adjustments to the > guidelines that can be adjusted by a script in all the packages should > be done scripted after a warning period where people can adjust it > manually if they want. > > (?) -- I now and then stumbled over packages where parts were not > adjusted to the latest guidelines even months or a years after the > guidelines were changed (yes, sometimes that were my own packages...) > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From tibbs at math.uh.edu Wed Jul 11 15:01:47 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 11 Jul 2007 10:01:47 -0500 Subject: rpm installation tests / script tests In-Reply-To: <20070711144031.GA11209@dudweiler.stuttgart.redhat.com> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711125140.GA9625@dudweiler.stuttgart.redhat.com> <4694D6D5.1000707@leemhuis.info> <20070711144031.GA11209@dudweiler.stuttgart.redhat.com> Message-ID: >>>>> "FLR" == Florian La Roche writes: FLR> +1 to get such things very fast into cvs and new packages FLR> built. I don't have any specific issues with auto-fixing this after sending a courtesy message to maintainers, but I object to doing automatic builds. This is a fleetingly minor issue that I don't see what the fuss is about in any case, but we certainly don't need to push updates for all of these packages just to fix a potential line of output that nobody even sees. - J< From wart at kobold.org Wed Jul 11 15:05:50 2007 From: wart at kobold.org (Wart) Date: Wed, 11 Jul 2007 08:05:50 -0700 Subject: rpm installation tests / script tests In-Reply-To: References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> Message-ID: <4694F1CE.90506@kobold.org> Rex Dieter wrote: > Florian La Roche wrote: > >> anything holding back an update of the default snippets we >> propose for Fedora until a more permanent solution in >> rpm/tools is available? > > The Snippets wiki has been updated, after getting feedback on the > fedora-desktop list. What about adding 'Requires(post): coreutils' to ensure that the 'touch' executable is present[1]? Or adding "|| :" at the end of the touch command to avoid errors from being printed if it is not? --Wart [1]https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246770 >> ----- Forwarded message from Rex Dieter ----- >> >> From: Rex Dieter >> Subject: Re: rpm installation tests / script tests >> To: fedora-maintainers at redhat.com >> Date: Tue, 10 Jul 2007 06:26:41 -0500 >> >> Alain PORTAL wrote: >> >> >>> This is the same error for the 3 packages >>> ERROR: Output running post uninstall script for package >>> piklab-0:0.14.2-2.fc7.i386 >>> /var/tmp/rpm-tmp.TpqGGv: line 2: /usr/bin/gtk-update-icon-cache: No such >>> file or directory >>> >>> but >>> > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-7103f6c38d1b5735e8477bdd569ad73ea2c49bda >>> said "Note that no dependencies should be added for this." >>> >>> So, what we have to do? >> Hrm, looks like an oversight in the guidelines... should probably wrap the >> call in something like: >> 1. if [ -x /usr/bin/gtk-update-icon-cache ]; then ... >> or >> 2. redirect output (using something like >& /dev/null >> (I use the latter mostly). >> >> -- Rex > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From martin.sourada at seznam.cz Wed Jul 11 15:13:33 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Wed, 11 Jul 2007 17:13:33 +0200 Subject: multiple .po files in one package -- how to do it in SPEC file? bug 230316 In-Reply-To: <1184161536.12944.16.camel@localhost6.localdomain6> References: <1184161536.12944.16.camel@localhost6.localdomain6> Message-ID: <1184166814.6497.5.camel@pc-notebook> On Wed, 2007-07-11 at 15:45 +0200, Matej Cepl wrote: > Hi, > > I am in the process of my package for jbrout (quite interesting > photo collection manager) being reviewed and both me and apparently > reviewer got totally lost in handling .po files. The package has > multiple .po files and I haven't figured out easy way how to compile > them all into one .po file which should be compiled into .mo file and > then installed, but all that for multiple languages, and ... so I see > three ways out of this mess: > > 1) to play with with find/bash/msgcat/msgattr/etc. with result being > probably steaming heap of bash scripts horrible to maintain and > incomprehensible to anybody > 2) to do the same with Python -- probably much more elegant solution, > but more work > 3) somebody has already done 2) (or with other scripting language) > > Could somebody more knowledgeable with packaging RPMs help me to find > out way to the light? > > Thanks a lot, > > Mat?j Cepl > Hi, I don't know if I understood you right, but you have more than one .pot files there? So find-lang will find only one? If so, I had the same problem with gxine. Here's the solution: # Not supported yet - check bz #213041 # %find_lang %{name} --all-name /usr/lib/rpm/find-lang.sh %{buildroot} %{name} --all-name But it seems that the bug was already resolved in RAWHIDE, I'll try it... Martin -------------- 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 P at draigBrady.com Wed Jul 11 14:20:14 2007 From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=) Date: Wed, 11 Jul 2007 15:20:14 +0100 Subject: multiple .po files in one package -- how to do it in SPEC file? bug 230316 In-Reply-To: <1184163073.12944.22.camel@localhost6.localdomain6> References: <1184161536.12944.16.camel@localhost6.localdomain6> <4694E391.6030208@draigBrady.com> <1184163073.12944.22.camel@localhost6.localdomain6> Message-ID: <4694E71E.4030105@draigBrady.com> Matej Cepl wrote: > P?draig Brady p??e v St 11. 07. 2007 v 15:05 +0100: >> multiple pot files you mean? >> How about `msgcomm --more-than=0 *.po` ? > > No, jbrout has some plugins which have their own separate .po files: and necessarily their own sepatate .pot files like you showed. > What's the difference between msgcomm and msgcat for me? Hah. Not much, only that I hadn't known about either until now :) `msgcomm --more-than=0` seems to be equivalent to `msgcat` P?draig. From tibbs at math.uh.edu Wed Jul 11 17:10:28 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 11 Jul 2007 12:10:28 -0500 Subject: Summary of the 2007-07-10 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-07-10 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070710 Executive summary: No new guidelines this week. Issues pending FESCO ratification: * R packaging guidelines * http://fedoraproject.org/wiki/PackagingDrafts/R * Accepted (6 - 1) * The dissenting vote was from scop: my -1 for the record unless it's changed to honor $RPM_OPT_FLAGS * In a method similar to Perl modules, R modules build with the optflags that R was built with. In contrast to Perl modules, R modules do not allow this to be overridden. It is not currently known whether it is possible without modifications to R itself, but spot is looking into this. Misc business: * http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups * Silencing errors from the icon cache update scriptlet * Guidelines for LSB-compliant init scripts. - J< From ville.skytta at iki.fi Wed Jul 11 19:01:42 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 11 Jul 2007 22:01:42 +0300 Subject: rpm installation tests / script tests In-Reply-To: <4694F1CE.90506@kobold.org> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <4694F1CE.90506@kobold.org> Message-ID: <200707112201.42814.ville.skytta@iki.fi> On Wednesday 11 July 2007, Wart wrote: > Rex Dieter wrote: > > Florian La Roche wrote: > >> anything holding back an update of the default snippets we > >> propose for Fedora until a more permanent solution in > >> rpm/tools is available? > > > > The Snippets wiki has been updated, after getting feedback on the > > fedora-desktop list. > > What about adding 'Requires(post): coreutils' to ensure that the 'touch' > executable is present[1]? Or adding "|| :" at the end of the touch > command to avoid errors from being printed if it is not? What's the benefit of that "touch" over using the -f/--force argument to gtk-update-icon-cache? Couldn't the scriptlet be reduced to: if [ -x %{_bindir}/gtk-update-icon-cache ] ; then %{_bindir}/gtk-update-icon-cache -qf %{_datadir}/icons/hicolor || : fi From rdieter at math.unl.edu Wed Jul 11 19:11:37 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 11 Jul 2007 14:11:37 -0500 Subject: rpm installation tests / script tests References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <4694F1CE.90506@kobold.org> <200707112201.42814.ville.skytta@iki.fi> Message-ID: Ville Skytt? wrote: > On Wednesday 11 July 2007, Wart wrote: > What's the benefit of that "touch" over using the -f/--force argument to > gtk-update-icon-cache? Couldn't the scriptlet be reduced to: > > if [ -x %{_bindir}/gtk-update-icon-cache ] ; then > %{_bindir}/gtk-update-icon-cache -qf %{_datadir}/icons/hicolor || : > fi if gtk-update-icon-cache is not present, the toplevel timestamp isn't updated, as required by the icon-spec. So, you have either touch ... conditional gtk-update-icon-cache or Requires(post,postun): gtk2 unconditional gtk-update-icon-cache --force pick your poison. -- Rex From ville.skytta at iki.fi Wed Jul 11 20:03:43 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 11 Jul 2007 23:03:43 +0300 Subject: rpm installation tests / script tests In-Reply-To: References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <200707112201.42814.ville.skytta@iki.fi> Message-ID: <200707112303.44506.ville.skytta@iki.fi> On Wednesday 11 July 2007, Rex Dieter wrote: > Ville Skytt? wrote: > > On Wednesday 11 July 2007, Wart wrote: > > > > What's the benefit of that "touch" over using the -f/--force argument to > > gtk-update-icon-cache? Couldn't the scriptlet be reduced to: > > > > if [ -x %{_bindir}/gtk-update-icon-cache ] ; then > > %{_bindir}/gtk-update-icon-cache -qf %{_datadir}/icons/hicolor || : > > fi > > if gtk-update-icon-cache is not present, the toplevel timestamp isn't > updated, as required by the icon-spec. Ah, I see. In that case, I think it would be better to rename the snippet in Wiki to something more generic as the "touch" serves non-GNOME/GTK desktops as well, and add a pointer to the icon theme spec. From aportal at univ-montp2.fr Thu Jul 12 08:38:27 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Thu, 12 Jul 2007 10:38:27 +0200 Subject: Builds failed randomly Message-ID: <200707121038.27430.aportal@univ-montp2.fr> Hi, I get a lot of problems to rebuild kbackup: sometime a build succeeded, sometime the build failed. F-8 Same spec file: http://koji.fedoraproject.org/koji/taskinfo?taskID=63073 http://koji.fedoraproject.org/koji/taskinfo?taskID=63220 http://koji.fedoraproject.org/koji/taskinfo?taskID=63490 Really minor change in spec file http://koji.fedoraproject.org/koji/taskinfo?taskID=64491 Another minor change in spec file http://koji.fedoraproject.org/koji/taskinfo?taskID=64541 F-7 Same spec file: http://koji.fedoraproject.org/koji/taskinfo?taskID=63079 http://koji.fedoraproject.org/koji/taskinfo?taskID=63543 Really minor change in spec file http://koji.fedoraproject.org/koji/taskinfo?taskID=64498 Another minor change in spec file http://koji.fedoraproject.org/koji/taskinfo?taskID=64554 Can somebody explain me where is the problem? Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jul 12 08:47:43 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 12 Jul 2007 17:47:43 +0900 Subject: Builds failed randomly In-Reply-To: <200707121038.27430.aportal@univ-montp2.fr> References: <200707121038.27430.aportal@univ-montp2.fr> Message-ID: <4695EAAF.40104@ioa.s.u-tokyo.ac.jp> Alain PORTAL wrote, at 07/12/2007 05:38 PM +9:00: > Hi, > > I get a lot of problems to rebuild kbackup: sometime a build succeeded, > sometime the build failed. > > F-7 > Same spec file: > http://koji.fedoraproject.org/koji/taskinfo?taskID=63079 > http://koji.fedoraproject.org/koji/taskinfo?taskID=63543 Well, I have not checked your spec file in detail, however what happens if you disable parallel make support? Mamoru From aportal at univ-montp2.fr Thu Jul 12 09:36:24 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Thu, 12 Jul 2007 11:36:24 +0200 Subject: Builds failed randomly In-Reply-To: <4695EAAF.40104@ioa.s.u-tokyo.ac.jp> References: <200707121038.27430.aportal@univ-montp2.fr> <4695EAAF.40104@ioa.s.u-tokyo.ac.jp> Message-ID: <200707121136.24463.aportal@univ-montp2.fr> Le Thursday 12 July 2007 10:47:43 Mamoru Tasaka, vous avez ?crit?: > Alain PORTAL wrote, at 07/12/2007 05:38 PM +9:00: > > Hi, > > > > I get a lot of problems to rebuild kbackup: sometime a build succeeded, > > sometime the build failed. > > > > > > F-7 > > Same spec file: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=63079 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=63543 > > Well, I have not checked your spec file in detail, however > what happens if you disable parallel make support? Build successful.... http://koji.fedoraproject.org/koji/taskinfo?taskID=64573 same for F8 http://koji.fedoraproject.org/koji/taskinfo?taskID=64581 So, should I have to disable parallel make support? Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jul 12 10:14:46 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 12 Jul 2007 19:14:46 +0900 Subject: Builds failed randomly In-Reply-To: <200707121136.24463.aportal@univ-montp2.fr> References: <200707121038.27430.aportal@univ-montp2.fr> <4695EAAF.40104@ioa.s.u-tokyo.ac.jp> <200707121136.24463.aportal@univ-montp2.fr> Message-ID: <4695FF16.8080700@ioa.s.u-tokyo.ac.jp> Alain PORTAL wrote, at 07/12/2007 06:36 PM +9:00: > Le Thursday 12 July 2007 10:47:43 Mamoru Tasaka, vous avez ?crit : >> Alain PORTAL wrote, at 07/12/2007 05:38 PM +9:00: >>> Hi, >>> >>> I get a lot of problems to rebuild kbackup: sometime a build succeeded, >>> sometime the build failed. >> Well, I have not checked your spec file in detail, however >> what happens if you disable parallel make support? > > Build successful.... > http://koji.fedoraproject.org/koji/taskinfo?taskID=64573 > same for F8 > http://koji.fedoraproject.org/koji/taskinfo?taskID=64581 > > So, should I have to disable parallel make support? Perhaps yes. Regards, Mamoru From jkeating at redhat.com Thu Jul 12 11:03:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Jul 2007 07:03:24 -0400 Subject: Builds failed randomly In-Reply-To: <200707121136.24463.aportal@univ-montp2.fr> References: <200707121038.27430.aportal@univ-montp2.fr> <4695EAAF.40104@ioa.s.u-tokyo.ac.jp> <200707121136.24463.aportal@univ-montp2.fr> Message-ID: <200707120703.28303.jkeating@redhat.com> On Thursday 12 July 2007 05:36:24 Alain PORTAL wrote: > So, should I have to disable parallel make support? And you should file a bug with upstream that their build process fails for parallel building. And comment in the spec file why you're disabling parallel building and what the upstream bug is so that it can be re-enabled once fixed upstream. -- 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 aportal at univ-montp2.fr Thu Jul 12 12:11:57 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Thu, 12 Jul 2007 14:11:57 +0200 Subject: Builds failed randomly In-Reply-To: <200707120703.28303.jkeating@redhat.com> References: <200707121038.27430.aportal@univ-montp2.fr> <200707121136.24463.aportal@univ-montp2.fr> <200707120703.28303.jkeating@redhat.com> Message-ID: <200707121411.57393.aportal@univ-montp2.fr> Le Thursday 12 July 2007 13:03:24 Jesse Keating, vous avez ?crit?: > On Thursday 12 July 2007 05:36:24 Alain PORTAL wrote: > > So, should I have to disable parallel make support? > > And you should file a bug with upstream that their build process fails for > parallel building. Unfortunately, upstream have no infrastructure: http://www.kde-apps.org/content/show.php?content=44998 But I mailed him. > And comment in the spec file why you're disabling > parallel building and what the upstream bug is so that it can be re-enabled > once fixed upstream. OK Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From fedora at leemhuis.info Thu Jul 12 15:08:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 Jul 2007 17:08:24 +0200 Subject: rpm installation tests / script tests In-Reply-To: <20070711144031.GA11209@dudweiler.stuttgart.redhat.com> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711125140.GA9625@dudweiler.stuttgart.redhat.com> <4694D6D5.1000707@leemhuis.info> <20070711144031.GA11209@dudweiler.stuttgart.redhat.com> Message-ID: <469643E8.6010307@leemhuis.info> On 11.07.2007 16:40, Florian La Roche wrote: > On Wed, Jul 11, 2007 at 03:10:45PM +0200, Thorsten Leemhuis wrote: >> On 11.07.2007 14:51, Florian La Roche wrote: >>> On Wed, Jul 11, 2007 at 07:41:55AM -0500, Rex Dieter wrote: >>>> Florian La Roche wrote: >>>>> anything holding back an update of the default snippets we >>>>> propose for Fedora until a more permanent solution in >>>>> rpm/tools is available? >>>> The Snippets wiki has been updated, after getting feedback on the >>>> fedora-desktop list. >>> great news, very good. >> +1, but will somebody kind of "enforce" this? Sure, it's no big >> problems, but nevertheless would be nice to get fixed. >> >> How about a (script based?) change directly in cvs for all packages that >> follow exactly what was in the "Snippets wiki" until now or was similar >> to it? >> >> That would be just a bit of work for one person (yes, I'm volunteering >> to do that if FESCo backs the idea; no, I'm not willing to write a >> proposal for FESCo to discuss that, as that often is way more work then >> actually doing the change), no boring work for packagers and the problem >> will actually vanish then soon (?). > > +1 to get such things very fast into cvs and new packages built. Well, it seems some people like tibbs dislike the idea with the "getting packages built". I'm unsure myself what the proper way is to build or not to build in devel -- normally I'd say "build", but for an issue like this it might be acceptable to not build. BTW, related question: should we commit the change not only to devel but to the F-7 tree as well? Surely we should not build the packages afterwards there, but if the packages get build sooner or later then the fix will simply get it. And it avoids that people start to update a package from the F-7 branch and copy the updated spec file to devel afterwards and delete the change that was done in between. > Usually > most package owners are ok with such "packaging changes", but there is > no official process for this until now. I tend to agree with "most", but those that are not ok with such "packaging changes" will yell loudly. So this for sure is something where FESCo needs to come into the game. >> Alternative would be to sun a spam-o-magic script that pokes people >> regularly until they fix stuff is getting fixed. > We all enjoy nag mails and huge amounts of new bugzilla requests. > Maybe we'll also find smart ways with cvs commits across all packages > at some point. +1 -- we don't need a wiki style approach, but we IMHO should get a bit more into the "wiki style" direction in the devel tree (as long as the release is still some weeks away). CU knurd From laroche at redhat.com Thu Jul 12 15:25:24 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 12 Jul 2007 17:25:24 +0200 Subject: rpm installation tests / script tests In-Reply-To: <469643E8.6010307@leemhuis.info> References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> <20070711125140.GA9625@dudweiler.stuttgart.redhat.com> <4694D6D5.1000707@leemhuis.info> <20070711144031.GA11209@dudweiler.stuttgart.redhat.com> <469643E8.6010307@leemhuis.info> Message-ID: <20070712152524.GA3778@dudweiler.stuttgart.redhat.com> > Well, it seems some people like tibbs dislike the idea with the "getting > packages built". I'm unsure myself what the proper way is to build or > not to build in devel -- normally I'd say "build", but for an issue like > this it might be acceptable to not build. Not building it allows more review from the maintaianer and is probably the right thing todo. > BTW, related question: should we commit the change not only to devel but > to the F-7 tree as well? Surely we should not build the packages > afterwards there, but if the packages get build sooner or later then the > fix will simply get it. And it avoids that people start to update a > package from the F-7 branch and copy the updated spec file to devel > afterwards and delete the change that was done in between. No real opinion, but life is often too short to get everything also pushed out for older Fedora releases. (Well, sometimes looking at the volumne of Fedora updates suggests otherwise.) > > Usually > > most package owners are ok with such "packaging changes", but there is > > no official process for this until now. > > I tend to agree with "most", but those that are not ok with such > "packaging changes" will yell loudly. So this for sure is something > where FESCo needs to come into the game. Right, this needs process at some point. Seems with growing Fedora we also slowly move from 1 person per rpm-package to bigger groups and need this working. regards, Florian La Roche From laroche at redhat.com Thu Jul 12 15:33:28 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 12 Jul 2007 17:33:28 +0200 Subject: rpm installation tests / script tests In-Reply-To: References: <20070711085307.GA4827@dudweiler.stuttgart.redhat.com> Message-ID: <20070712153328.GA3857@dudweiler.stuttgart.redhat.com> On Wed, Jul 11, 2007 at 07:41:55AM -0500, Rex Dieter wrote: > Florian La Roche wrote: > > > anything holding back an update of the default snippets we > > propose for Fedora until a more permanent solution in > > rpm/tools is available? > > The Snippets wiki has been updated, after getting feedback on the > fedora-desktop list. Hello Rex, it still says that no deps are needed, but should list a dependency for touch/coreutils in there. regards, Florian La Roche From belegdol at gmail.com Thu Jul 12 16:23:30 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Thu, 12 Jul 2007 17:23:30 +0100 Subject: Looking for contact with Aaron Kurtz (AWOL?) In-Reply-To: <4690B3A4.2040300@hhs.nl> References: <4690B3A4.2040300@hhs.nl> Message-ID: <9b1b20e70707120923k68439086x961c55286c259add@mail.gmail.com> 2007/7/8, Hans de Goede : > Hi All, > > As discussed already some time ago on fedora-maintainers list, Aaron Kurtz is > not responding to inquiries / bugs about his gnome-applet-sensors package: > https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00986.html > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 > > I'm interested in picking up this package. Since I'm now a co-maintainer of the > lm-sensors package and active in lm-sensors upstream I would like to move > forward with this. > > The reporter of the bug in question has already done a first contact attempt as > required by the AWOL-policy: > http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers > > I've just added a second contact attempt to the bug in question, and as > required by the AWOL policy I'm now sending a mail to the maintainers-list > about this. Does anyone know howto contact Aaron and / or whats up with Aaron? > > Thanks & Regards, > > Hans > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > I could take over gnome-applet-netspeed if there are no objections. Keep in mind though, that if upstream turns out to be dead, as it seems now, I'll retire it. From fedora at leemhuis.info Thu Jul 12 16:35:01 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 Jul 2007 18:35:01 +0200 Subject: EPEL announcement planed for 20070726 Message-ID: <46965835.9030705@leemhuis.info> Hi, just a heads up; the current plan is to officially announce EPEL on Thursday, 26th 2007. Yes, that's one week later that estimated last week, as we need a bit more time to fix all broken deps before the announcement. While at it: Note that new and updated packages for EPEL will go to into EPEL-testing repo after the announcement (?) and get moved to the proper repo at a later point of time. The plan is to do the move from testing to the proper repo in parallel with the "quarterly" EL-releases like RHEL 5.1. CU knurd (?) -- except security updates and critical bugfixes of course From bnocera at redhat.com Thu Jul 12 18:44:50 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 12 Jul 2007 19:44:50 +0100 Subject: taking libbtctl and gnome-bluetooth Message-ID: <1184265890.4117.195.camel@cookie.hadess.net> Heya, Harald seems to have orphaned libbtctl and gnome-bluetooth, but didn't get them added to the orphans page. In all cases, I'm upstream for those packages, and hoping to deprecate them in the long-term (hopefully before Fedora 9, although it looks unlikely for Fedora 8 right now). The only package depending on those is gnome-phone-manager (which is due an upstream release as well). Anyone against me taking those? Cheers From opensource at till.name Thu Jul 12 19:12:23 2007 From: opensource at till.name (Till Maas) Date: Thu, 12 Jul 2007 21:12:23 +0200 Subject: taking libbtctl and gnome-bluetooth In-Reply-To: <1184265890.4117.195.camel@cookie.hadess.net> References: <1184265890.4117.195.camel@cookie.hadess.net> Message-ID: <200707122112.25306.opensource@till.name> On Do Juli 12 2007, Bastien Nocera wrote: > Harald seems to have orphaned libbtctl and gnome-bluetooth, but didn't > get them added to the orphans page. > Anyone against me taking those? Imho you should ask Harald, whether this is ok with him and if he does not respond please follow: http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers Regards, Till From j.w.r.degoede at hhs.nl Wed Jul 11 20:40:27 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 11 Jul 2007 22:40:27 +0200 Subject: Looking for contact with Aaron Kurtz (AWOL?) In-Reply-To: <9b1b20e70707120923k68439086x961c55286c259add@mail.gmail.com> References: <4690B3A4.2040300@hhs.nl> <9b1b20e70707120923k68439086x961c55286c259add@mail.gmail.com> Message-ID: <4695403B.5060805@hhs.nl> Julian Sikorski wrote: > 2007/7/8, Hans de Goede : >> Hi All, >> >> As discussed already some time ago on fedora-maintainers list, Aaron >> Kurtz is >> not responding to inquiries / bugs about his gnome-applet-sensors >> package: >> https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00986.html >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 >> >> I'm interested in picking up this package. Since I'm now a >> co-maintainer of the >> lm-sensors package and active in lm-sensors upstream I would like to move >> forward with this. >> >> The reporter of the bug in question has already done a first contact >> attempt as >> required by the AWOL-policy: >> http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers >> >> I've just added a second contact attempt to the bug in question, and as >> required by the AWOL policy I'm now sending a mail to the >> maintainers-list >> about this. Does anyone know howto contact Aaron and / or whats up >> with Aaron? >> >> Thanks & Regards, >> >> Hans >> >> -- >> Fedora-maintainers mailing list >> Fedora-maintainers at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-maintainers >> > I could take over gnome-applet-netspeed if there are no objections. > Keep in mind though, that if upstream turns out to be dead, as it > seems now, I'll retire it. > I've only begun the awol procedure for gnome-applet-sensors, but if aaron has other packages that are being neglected too, you can request them to be orphaned by FESco, riding along on this awol procedure. About gnome-applet-netspeed, of it becomes available, go ahead and take it, however I must say I don't like you writing: "if upstream turns out to be dead, as it seems now, I'll retire it.", that seems like a bad policy to me. I maintain many packages where upstream is dead. As long as users find them usefull and they don't break left and right because of dependency changes, why abandon them? Regards, Hans From braden at endoframe.com Thu Jul 12 22:12:21 2007 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 12 Jul 2007 18:12:21 -0400 Subject: Build failure on ppc (in glib headers) Message-ID: <4696A745.9080102@endoframe.com> I have a devel build that's failed apparently in glib headers: > g++ -DHAVE_CONFIG_H -I. -I../.. -I../../lib/gtkglext -I../../lib/gtkglext -I../../lib/gtkglext/gdk -I../../src/libopenvrml -I../../src/libopenvrml -I../../src/libopenvrml-gl -I../../src/libopenvrml-gl -I -DGTK_DISABLE_DEPRECATED -DNDEBUG -pthread -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -MT gtkvrmlbrowser.o -MD -MP -MF $depbase.Tpo -c -o gtkvrmlbrowser.o gtkvrmlbrowser.cpp &&\ > mv -f $depbase.Tpo $depbase.Po > /usr/include/glib-2.0/glib/gthread.h: In function 'gboolean g_once_init_enter(volatile gsize*)': > /usr/include/glib-2.0/glib/gthread.h:335: error: cannot convert 'volatile gsize*' to 'void* volatile*' for argument '1' to 'void* g_atomic_pointer_get(void* volatile*)' > /usr/include/glib-2.0/glib/gthread.h: In function 'gboolean g_once_init_enter(volatile gsize*)': > /usr/include/glib-2.0/glib/gthread.h:335: error: cannot convert 'volatile gsize*' to 'void* volatile*' for argument '1' to 'void* g_atomic_pointer_get(void* volatile*)' > make[3]: *** [plugin_streambuf.o] Error 1 Complete log at . What do I do here? Braden From opensource at till.name Thu Jul 12 22:24:46 2007 From: opensource at till.name (Till Maas) Date: Fri, 13 Jul 2007 00:24:46 +0200 Subject: Build failure on ppc (in glib headers) In-Reply-To: <4696A745.9080102@endoframe.com> References: <4696A745.9080102@endoframe.com> Message-ID: <200707130024.47720.opensource@till.name> On Fr Juli 13 2007, Braden McDaniel wrote: > What do I do here? Maybe removing %{?_smp_mflags} in the spec helps, this seems to cause several failing builds, recently. Maybe the builders have more cpus/cores, now. If it helps, report it upstream and add to comment above the make invocation. Regards, Till From mclasen at redhat.com Thu Jul 12 22:20:30 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 12 Jul 2007 18:20:30 -0400 Subject: Build failure on ppc (in glib headers) In-Reply-To: <4696A745.9080102@endoframe.com> References: <4696A745.9080102@endoframe.com> Message-ID: <1184278830.3098.0.camel@localhost.localdomain> On Thu, 2007-07-12 at 18:12 -0400, Braden McDaniel wrote: > I have a devel build that's failed apparently in glib headers: > > > g++ -DHAVE_CONFIG_H -I. -I../.. -I../../lib/gtkglext -I../../lib/gtkglext -I../../lib/gtkglext/gdk -I../../src/libopenvrml -I../../src/libopenvrml -I../../src/libopenvrml-gl -I../../src/libopenvrml-gl -I -DGTK_DISABLE_DEPRECATED -DNDEBUG -pthread -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -MT gtkvrmlbrowser.o -MD -MP -MF $depbase.Tpo -c -o gtkvrmlbrowser.o gtkvrmlbrowser.cpp &&\ > > mv -f $depbase.Tpo $depbase.Po > > /usr/include/glib-2.0/glib/gthread.h: In function 'gboolean g_once_init_enter(volatile gsize*)': > > /usr/include/glib-2.0/glib/gthread.h:335: error: cannot convert 'volatile gsize*' to 'void* volatile*' for argument '1' to 'void* g_atomic_pointer_get(void* volatile*)' > > /usr/include/glib-2.0/glib/gthread.h: In function 'gboolean g_once_init_enter(volatile gsize*)': > > /usr/include/glib-2.0/glib/gthread.h:335: error: cannot convert 'volatile gsize*' to 'void* volatile*' for argument '1' to 'void* g_atomic_pointer_get(void* volatile*)' > > make[3]: *** [plugin_streambuf.o] Error 1 > > Complete log at > . > > What do I do here? > Please file an upstream bug at bugzilla.gnome.org Thanks, Matthias From braden at endoframe.com Thu Jul 12 22:36:28 2007 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 12 Jul 2007 18:36:28 -0400 Subject: Build failure on ppc (in glib headers) In-Reply-To: <1184278830.3098.0.camel@localhost.localdomain> References: <4696A745.9080102@endoframe.com> <1184278830.3098.0.camel@localhost.localdomain> Message-ID: <4696ACEC.10004@endoframe.com> Matthias Clasen wrote: > On Thu, 2007-07-12 at 18:12 -0400, Braden McDaniel wrote: >> I have a devel build that's failed apparently in glib headers: >> >>> g++ -DHAVE_CONFIG_H -I. -I../.. -I../../lib/gtkglext -I../../lib/gtkglext -I../../lib/gtkglext/gdk -I../../src/libopenvrml -I../../src/libopenvrml -I../../src/libopenvrml-gl -I../../src/libopenvrml-gl -I -DGTK_DISABLE_DEPRECATED -DNDEBUG -pthread -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -MT gtkvrmlbrowser.o -MD -MP -MF $depbase.Tpo -c -o gtkvrmlbrowser.o gtkvrmlbrowser.cpp &&\ >>> mv -f $depbase.Tpo $depbase.Po >>> /usr/include/glib-2.0/glib/gthread.h: In function 'gboolean g_once_init_enter(volatile gsize*)': >>> /usr/include/glib-2.0/glib/gthread.h:335: error: cannot convert 'volatile gsize*' to 'void* volatile*' for argument '1' to 'void* g_atomic_pointer_get(void* volatile*)' >>> /usr/include/glib-2.0/glib/gthread.h: In function 'gboolean g_once_init_enter(volatile gsize*)': >>> /usr/include/glib-2.0/glib/gthread.h:335: error: cannot convert 'volatile gsize*' to 'void* volatile*' for argument '1' to 'void* g_atomic_pointer_get(void* volatile*)' >>> make[3]: *** [plugin_streambuf.o] Error 1 >> Complete log at >> . >> >> What do I do here? >> > > Please file an upstream bug at bugzilla.gnome.org Okay. And in the meantime disable building for ppc[64] in my package? (How do I do that?) Braden From mclasen at redhat.com Thu Jul 12 22:47:37 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 12 Jul 2007 18:47:37 -0400 Subject: Build failure on ppc (in glib headers) In-Reply-To: <4696ACEC.10004@endoframe.com> References: <4696A745.9080102@endoframe.com> <1184278830.3098.0.camel@localhost.localdomain> <4696ACEC.10004@endoframe.com> Message-ID: <1184280457.3098.5.camel@localhost.localdomain> On Thu, 2007-07-12 at 18:36 -0400, Braden McDaniel wrote: > Matthias Clasen wrote: > > On Thu, 2007-07-12 at 18:12 -0400, Braden McDaniel wrote: > >> I have a devel build that's failed apparently in glib headers: > >> > >>> g++ -DHAVE_CONFIG_H -I. -I../.. -I../../lib/gtkglext -I../../lib/gtkglext -I../../lib/gtkglext/gdk -I../../src/libopenvrml -I../../src/libopenvrml -I../../src/libopenvrml-gl -I../../src/libopenvrml-gl -I -DGTK_DISABLE_DEPRECATED -DNDEBUG -pthread -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -MT gtkvrmlbrowser.o -MD -MP -MF $depbase.Tpo -c -o gtkvrmlbrowser.o gtkvrmlbrowser.cpp &&\ > >>> mv -f $depbase.Tpo $depbase.Po > >>> /usr/include/glib-2.0/glib/gthread.h: In function 'gboolean g_once_init_enter(volatile gsize*)': > >>> /usr/include/glib-2.0/glib/gthread.h:335: error: cannot convert 'volatile gsize*' to 'void* volatile*' for argument '1' to 'void* g_atomic_pointer_get(void* volatile*)' > >>> /usr/include/glib-2.0/glib/gthread.h: In function 'gboolean g_once_init_enter(volatile gsize*)': > >>> /usr/include/glib-2.0/glib/gthread.h:335: error: cannot convert 'volatile gsize*' to 'void* volatile*' for argument '1' to 'void* g_atomic_pointer_get(void* volatile*)' > >>> make[3]: *** [plugin_streambuf.o] Error 1 > >> Complete log at > >> . > >> > >> What do I do here? > >> > > > > Please file an upstream bug at bugzilla.gnome.org > > Okay. And in the meantime disable building for ppc[64] in my package? > (How do I do that?) A possible fix for this is just appeared in upstream svn; I'll put that in rawhide later tonight, gotta run now. From bnocera at redhat.com Thu Jul 12 22:59:39 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 12 Jul 2007 23:59:39 +0100 Subject: taking libbtctl and gnome-bluetooth In-Reply-To: <200707122112.25306.opensource@till.name> References: <1184265890.4117.195.camel@cookie.hadess.net> <200707122112.25306.opensource@till.name> Message-ID: <1184281179.4117.237.camel@cookie.hadess.net> On Thu, 2007-07-12 at 21:12 +0200, Till Maas wrote: > On Do Juli 12 2007, Bastien Nocera wrote: > > > Harald seems to have orphaned libbtctl and gnome-bluetooth, but didn't > > get them added to the orphans page. > > > Anyone against me taking those? > > Imho you should ask Harald, whether this is ok with him and if he does not > respond please follow: > > http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers Harald was CC:'ed on the original mail... And I don't think he's AWOL either, he just dropped the packages as orphans. He asked some months ago if I wanted to take the packages, but didn't fancy being upstream and packaging it. I thought he'd carry on taking care of them though. From dwmw2 at infradead.org Fri Jul 13 00:08:35 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 13 Jul 2007 01:08:35 +0100 Subject: Build failure on ppc (in glib headers) In-Reply-To: <4696A745.9080102@endoframe.com> References: <4696A745.9080102@endoframe.com> Message-ID: <1184285315.2785.9.camel@shinybook.infradead.org> On Thu, 2007-07-12 at 18:12 -0400, Braden McDaniel wrote: > Complete log at > . > > What do I do here? Normally the answer would be to file a bug against glib indicating the failure, then either just wait for it to be fixed, or if you'd prefer to ship the updated openvrml sooner than that then also open a bug against openvrml and put it on the FE-ExcludeArch-ppc tracker. Then you can add a temporary 'ExcludeArch: ppc' and build it. In this case, though, I'd just wait for the fixed glib to hit rawhide later tonight. -- dwmw2 From braden at endoframe.com Fri Jul 13 02:10:24 2007 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 12 Jul 2007 22:10:24 -0400 Subject: Build failure on ppc (in glib headers) In-Reply-To: <1184285315.2785.9.camel@shinybook.infradead.org> References: <4696A745.9080102@endoframe.com> <1184285315.2785.9.camel@shinybook.infradead.org> Message-ID: <1184292624.20279.9.camel@hinge.endoframe.net> On Fri, 2007-07-13 at 01:08 +0100, David Woodhouse wrote: > In this case, though, I'd just wait for the fixed glib to hit rawhide > later tonight. Thank you. That's what I'll do. -- Braden McDaniel e-mail: Jabber: From mclasen at redhat.com Fri Jul 13 03:11:40 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 12 Jul 2007 23:11:40 -0400 Subject: Build failure on ppc (in glib headers) In-Reply-To: <1184292624.20279.9.camel@hinge.endoframe.net> References: <4696A745.9080102@endoframe.com> <1184285315.2785.9.camel@shinybook.infradead.org> <1184292624.20279.9.camel@hinge.endoframe.net> Message-ID: <1184296300.3098.7.camel@localhost.localdomain> On Thu, 2007-07-12 at 22:10 -0400, Braden McDaniel wrote: > On Fri, 2007-07-13 at 01:08 +0100, David Woodhouse wrote: > > > In this case, though, I'd just wait for the fixed glib to hit rawhide > > later tonight. > > Thank you. That's what I'll do. > Can you try with the glib-2.13.7-2.fc8 that I built a while ago ? From belegdol at gmail.com Fri Jul 13 04:04:45 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Fri, 13 Jul 2007 05:04:45 +0100 Subject: Looking for contact with Aaron Kurtz (AWOL?) In-Reply-To: <4695403B.5060805@hhs.nl> References: <4690B3A4.2040300@hhs.nl> <9b1b20e70707120923k68439086x961c55286c259add@mail.gmail.com> <4695403B.5060805@hhs.nl> Message-ID: <9b1b20e70707122104q4f17c7e5la037d4c093243e22@mail.gmail.com> 2007/7/11, Hans de Goede : > Julian Sikorski wrote: > > 2007/7/8, Hans de Goede : > >> Hi All, > >> > >> As discussed already some time ago on fedora-maintainers list, Aaron > >> Kurtz is > >> not responding to inquiries / bugs about his gnome-applet-sensors > >> package: > >> https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00986.html > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 > >> > >> I'm interested in picking up this package. Since I'm now a > >> co-maintainer of the > >> lm-sensors package and active in lm-sensors upstream I would like to move > >> forward with this. > >> > >> The reporter of the bug in question has already done a first contact > >> attempt as > >> required by the AWOL-policy: > >> http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers > >> > >> I've just added a second contact attempt to the bug in question, and as > >> required by the AWOL policy I'm now sending a mail to the > >> maintainers-list > >> about this. Does anyone know howto contact Aaron and / or whats up > >> with Aaron? > >> > >> Thanks & Regards, > >> > >> Hans > >> > >> -- > >> Fedora-maintainers mailing list > >> Fedora-maintainers at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-maintainers > >> > > I could take over gnome-applet-netspeed if there are no objections. > > Keep in mind though, that if upstream turns out to be dead, as it > > seems now, I'll retire it. > > > > I've only begun the awol procedure for gnome-applet-sensors, but if aaron has > other packages that are being neglected too, you can request them to be > orphaned by FESco, riding along on this awol procedure. > > About gnome-applet-netspeed, of it becomes available, go ahead and take it, > however I must say I don't like you writing: "if upstream turns out to be dead, > as it seems now, I'll retire it.", that seems like a bad policy to me. I > maintain many packages where upstream is dead. As long as users find them > usefull and they don't break left and right because of dependency changes, why > abandon them? > > Regards, > > Hans > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Well, sorry, I did not express myself clearly. I only mean that I have next to none programming skills, so if some serious bugs appear in the applet, I won't be able to fix it. Hopefully it is more clear now. Cheers, Julian From braden at endoframe.com Fri Jul 13 04:25:43 2007 From: braden at endoframe.com (Braden McDaniel) Date: Fri, 13 Jul 2007 00:25:43 -0400 Subject: Build failure on ppc (in glib headers) In-Reply-To: <1184296300.3098.7.camel@localhost.localdomain> References: <4696A745.9080102@endoframe.com> <1184285315.2785.9.camel@shinybook.infradead.org> <1184292624.20279.9.camel@hinge.endoframe.net> <1184296300.3098.7.camel@localhost.localdomain> Message-ID: <1184300743.20279.14.camel@hinge.endoframe.net> On Thu, 2007-07-12 at 23:11 -0400, Matthias Clasen wrote: > On Thu, 2007-07-12 at 22:10 -0400, Braden McDaniel wrote: > > On Fri, 2007-07-13 at 01:08 +0100, David Woodhouse wrote: > > > > > In this case, though, I'd just wait for the fixed glib to hit rawhide > > > later tonight. > > > > Thank you. That's what I'll do. > > > > Can you try with the glib-2.13.7-2.fc8 that I built a while ago ? I think it probably worked. But now my ppc builds are failing due, I think, to some problem in koji: openvrml-0.16.6-1.fc7 (11081) failed on ppc3.fedora.redhat.com (ppc64), ppc3.fedora.redhat.com (noarch): Traceback (most recent call last): File "/usr/sbin/kojid", line 1109, in runTask response = (handler.run(),) File "/usr/sbin/kojid", line 1185, in run return self.handler(*self.params,**self.opts) File "/usr/sbin/kojid", line 1711, in handler broot.build(fn,arch) File "/usr/sbin/kojid", line 465, in build rv = self.mock(args) File "/usr/sbin/kojid", line 393, in mock incrementalUpload(fname, fd, uploadpath, self.logger) File "/usr/sbin/kojid", line 229, in incrementalUpload if session.uploadFile(path, fname, size, digest, offset, data): File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1075, in __call__ return self.__func(self.__name,args,opts) File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1300, in _callMethod return proxy.__getattr__(name)(*args) File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__ return self.__send(self.__name, args) File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request verbose=self.__verbose File "/usr/lib/python2.4/xmlrpclib.py", line 1129, in request self.send_content(h, request_body) File "/usr/lib/python2.4/xmlrpclib.py", line 1243, in send_content connection.endheaders() File "/usr/lib/python2.4/httplib.py", line 798, in endheaders self._send_output() File "/usr/lib/python2.4/httplib.py", line 679, in _send_output self.send(msg) File "/usr/lib/python2.4/httplib.py", line 658, in send self.sock.sendall(str) File "/usr/lib/python2.4/site-packages/koji/ssl/SSLConnection.py", line 110, in sendall sent = con.send(data, flags) Error: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] SRPMS: openvrml-0.16.6-1.fc7.src.rpm That's from F-7; but I'm seeing something very similar in devel. -- Braden McDaniel e-mail: Jabber: From jkeating at redhat.com Fri Jul 13 04:29:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Jul 2007 00:29:11 -0400 Subject: Build failure on ppc (in glib headers) In-Reply-To: <1184300743.20279.14.camel@hinge.endoframe.net> References: <4696A745.9080102@endoframe.com> <1184296300.3098.7.camel@localhost.localdomain> <1184300743.20279.14.camel@hinge.endoframe.net> Message-ID: <200707130029.11638.jkeating@redhat.com> On Friday 13 July 2007 00:25:43 Braden McDaniel wrote: > That's from F-7; but I'm seeing something very similar in devel. Koji had a brief database outage. Are you still seeing these messages? -- 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 Fri Jul 13 04:32:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Jul 2007 00:32:44 -0400 Subject: Build failure on ppc (in glib headers) In-Reply-To: <200707130029.11638.jkeating@redhat.com> References: <4696A745.9080102@endoframe.com> <1184300743.20279.14.camel@hinge.endoframe.net> <200707130029.11638.jkeating@redhat.com> Message-ID: <200707130032.45165.jkeating@redhat.com> On Friday 13 July 2007 00:29:11 Jesse Keating wrote: > Koji had a brief database outage. ?Are you still seeing these messages? Whoops, looks like a koji admin restarted your build for you and it succeeded. -- 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 braden at endoframe.com Fri Jul 13 06:26:11 2007 From: braden at endoframe.com (Braden McDaniel) Date: Fri, 13 Jul 2007 02:26:11 -0400 Subject: Build failure on ppc (in glib headers) In-Reply-To: <200707130032.45165.jkeating@redhat.com> References: <4696A745.9080102@endoframe.com> <1184300743.20279.14.camel@hinge.endoframe.net> <200707130029.11638.jkeating@redhat.com> <200707130032.45165.jkeating@redhat.com> Message-ID: <1184307971.20279.17.camel@hinge.endoframe.net> On Fri, 2007-07-13 at 00:32 -0400, Jesse Keating wrote: > On Friday 13 July 2007 00:29:11 Jesse Keating wrote: > > Koji had a brief database outage. Are you still seeing these messages? > > Whoops, looks like a koji admin restarted your build for you and it succeeded. Indeed. Yea. Thanks, mikeb. -- Braden McDaniel e-mail: Jabber: From debarshi.ray at gmail.com Fri Jul 13 07:11:15 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 13 Jul 2007 12:41:15 +0530 Subject: Looking for contact with Aaron Kurtz (AWOL?) In-Reply-To: <9b1b20e70707120923k68439086x961c55286c259add@mail.gmail.com> References: <4690B3A4.2040300@hhs.nl> <9b1b20e70707120923k68439086x961c55286c259add@mail.gmail.com> Message-ID: <3170f42f0707130011t3d8c1c0cn6304ab53bc013bd1@mail.gmail.com> > I could take over gnome-applet-netspeed if there are no objections. > Keep in mind though, that if upstream turns out to be dead, as it > seems now, I'll retire it. You could always write to them saying that there is sufficent interest in the program. That may bring them back to life. Very recently I wrote to the developer of cfgparse (http://pages.cs.wisc.edu/~param/software/cfgparse/), since we needed the code to parse the configuration files in YUM. Since then upstream has come back to life with a new public repository at http://code.google.com/p/iniparse/ There is no guarantee that this will always happen, but one can always try. :-) Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From belegdol at gmail.com Fri Jul 13 12:59:01 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Fri, 13 Jul 2007 13:59:01 +0100 Subject: Looking for contact with Aaron Kurtz (AWOL?) In-Reply-To: <3170f42f0707130011t3d8c1c0cn6304ab53bc013bd1@mail.gmail.com> References: <4690B3A4.2040300@hhs.nl> <9b1b20e70707120923k68439086x961c55286c259add@mail.gmail.com> <3170f42f0707130011t3d8c1c0cn6304ab53bc013bd1@mail.gmail.com> Message-ID: <9b1b20e70707130559n58e2437co6a6cfe8e30fa4337@mail.gmail.com> 2007/7/13, Debarshi 'Rishi' Ray : > > I could take over gnome-applet-netspeed if there are no objections. > > Keep in mind though, that if upstream turns out to be dead, as it > > seems now, I'll retire it. > > You could always write to them saying that there is sufficent interest > in the program. That may bring them back to life. > > Very recently I wrote to the developer of cfgparse > (http://pages.cs.wisc.edu/~param/software/cfgparse/), since we needed > the code to parse the configuration files in YUM. Since then upstream > has come back to life with a new public repository at > http://code.google.com/p/iniparse/ > > There is no guarantee that this will always happen, but one can always try. :-) > > Happy hacking, > Debarshi > -- > GPG key ID: 63D4A5A7 > Key server: pgp.mit.edu > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Sure, seems to be a good idea. As for now, the updated spec I posted @ bugzilla works fine for me, so there is no need for retirement of any kind. Regards, Julian From jgranado at redhat.com Fri Jul 13 13:21:06 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Fri, 13 Jul 2007 15:21:06 +0200 Subject: building python-imaging1.1.5 on top of python-imaging1.1.6 Message-ID: <46977C42.3010400@redhat.com> hi all: I may need to build a previous version of the source on top of a build that has the newest version. Been asking around the office and the general conclusion is that I must use epoch to deal with this issue. Does anybody have any other suggestion that might lead to some different solution? FYI: BZ #246444 Regards. -- Joel Andres Granados From dennis at ausil.us Fri Jul 13 13:27:58 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 13 Jul 2007 08:27:58 -0500 Subject: building python-imaging1.1.5 on top of python-imaging1.1.6 In-Reply-To: <46977C42.3010400@redhat.com> References: <46977C42.3010400@redhat.com> Message-ID: <200707130828.03743.dennis@ausil.us> Once upon a time Friday 13 July 2007, Joel Andres Granados wrote: > hi all: > > I may need to build a previous version of the source on top of a build > that has the newest version. Been asking around the office and the > general conclusion is that I must use epoch to deal with this issue. > Does anybody have any other suggestion that might lead to some different > solution? > > FYI: BZ #246444 > > Regards. the only way would be an epoch in the RHEL5 package. I have removed python-imaging from the epel repository. Dennis -------------- 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 jgranado at redhat.com Fri Jul 13 14:01:25 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Fri, 13 Jul 2007 16:01:25 +0200 Subject: building python-imaging1.1.5 on top of python-imaging1.1.6 In-Reply-To: <200707130828.03743.dennis@ausil.us> References: <46977C42.3010400@redhat.com> <200707130828.03743.dennis@ausil.us> Message-ID: <469785B5.9000402@redhat.com> Dennis Gilmore wrote: > Once upon a time Friday 13 July 2007, Joel Andres Granados wrote: > >> hi all: >> >> I may need to build a previous version of the source on top of a build >> that has the newest version. Been asking around the office and the >> general conclusion is that I must use epoch to deal with this issue. >> Does anybody have any other suggestion that might lead to some different >> solution? >> >> FYI: BZ #246444 >> >> Regards. >> > > the only way would be an epoch in the RHEL5 package. I have removed > python-imaging from the epel repository. > > Dennis > > ------------------------------------------------------------------------ > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Thx for the info. I still see the pkg in the cvs. Will it disappear in the future, or will it be there for me to ignore for all its existence? Or do I have to follow another process to get the branch removed? Regards -- Joel Andres Granados From dennis at ausil.us Fri Jul 13 14:05:57 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 13 Jul 2007 09:05:57 -0500 Subject: building python-imaging1.1.5 on top of python-imaging1.1.6 In-Reply-To: <469785B5.9000402@redhat.com> References: <46977C42.3010400@redhat.com> <200707130828.03743.dennis@ausil.us> <469785B5.9000402@redhat.com> Message-ID: <200707130905.58755.dennis@ausil.us> Once upon a time Friday 13 July 2007, Joel Andres Granados wrote: > > Thx for the info. > I still see the pkg in the cvs. Will it disappear in the future, or > will it be there for me to ignore for all its existence? Or do I have > to follow another process to get the branch removed? I will remove it today. Dennis -------------- 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 Jul 13 14:11:02 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 13 Jul 2007 16:11:02 +0200 Subject: Looking for people to trade reviews with. Message-ID: <469787F6.4000404@hhs.nl> Hi All, I've got a number of packager for which its close to impossible to find a reviewer. I'm looking for people todo a 100% "technical" review of this, iow just check if it matches the guidelines. I'm afraid that there is no-one with the expertise to also check if things like the used configure flags etc are sane. However I've poured a ton of time in to this. For researching how to best do this amongst other things, so I'm pretty sure everything is ok. You will just have to trust me on my blue ^H^H^H^H brown eyes for that. I've tested these packages to compile a variety of software for the involved hardware and the resulting binaries worked fine. Here is the list: * avr-libc C library for use with GCC on Atmel AVR microcontrollers https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241279 * arm-gp2x-linux-binutils Cross Compiling GNU binutils targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234749 * arm-gp2x-linux-kernel-headers Kernel headers for Cross Compiling to arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242203 * arm-gp2x-linux-gcc Cross Compiling GNU GCC targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242206 * arm-gp2x-linux-glibc Cross Compiled GNU C Library targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242207 * arm-gp2x-linux-SDL Cross Compiled SDL Library targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243147 * arm-gp2x-linux-zlib Cross Compiled zlib Library targeted at avr https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243254 I'm more then willing to review a package of yours in return. Thanks & Regards, Hans p.s. The list of libraries is not complete yet, I've got more libs packaged up, I need to polish the specfiles a bit before submitting them, but first lets tackle the above list. From dwmw2 at infradead.org Fri Jul 13 14:50:38 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 13 Jul 2007 15:50:38 +0100 Subject: Looking for people to trade reviews with. In-Reply-To: <469787F6.4000404@hhs.nl> References: <469787F6.4000404@hhs.nl> Message-ID: <1184338238.8809.13.camel@hades.cambridge.redhat.com> On Fri, 2007-07-13 at 16:11 +0200, Hans de Goede wrote: > > * arm-gp2x-linux-kernel-headers > Kernel headers for Cross Compiling to arm-gp2x-linux > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242203 All the linux-libc-headers projects are obsolete now; don't use them. Use headers generated by running 'make headers_install' in a kernel tree. -- dwmw2 From jgranado at redhat.com Fri Jul 13 15:00:58 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Fri, 13 Jul 2007 17:00:58 +0200 Subject: building python-imaging1.1.5 on top of python-imaging1.1.6 In-Reply-To: <200707130905.58755.dennis@ausil.us> References: <46977C42.3010400@redhat.com> <200707130828.03743.dennis@ausil.us> <469785B5.9000402@redhat.com> <200707130905.58755.dennis@ausil.us> Message-ID: <469793AA.6050808@redhat.com> Dennis Gilmore wrote: > Once upon a time Friday 13 July 2007, Joel Andres Granados wrote: > > >> Thx for the info. >> I still see the pkg in the cvs. Will it disappear in the future, or >> will it be there for me to ignore for all its existence? Or do I have >> to follow another process to get the branch removed? >> > > I will remove it today. > hey Dennis: It was just a question, I didn't mean it as a request. I would like to hold on to the CVS branch for a while because I don't have clear what I'm going to do with the package in EPEL. Hope its not to late! Thx. > Dennis > > ------------------------------------------------------------------------ > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- Joel Andres Granados From j.w.r.degoede at hhs.nl Fri Jul 13 14:52:50 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 13 Jul 2007 16:52:50 +0200 Subject: Looking for people to trade reviews with. In-Reply-To: <1184338238.8809.13.camel@hades.cambridge.redhat.com> References: <469787F6.4000404@hhs.nl> <1184338238.8809.13.camel@hades.cambridge.redhat.com> Message-ID: <469791C2.8020000@hhs.nl> David Woodhouse wrote: > On Fri, 2007-07-13 at 16:11 +0200, Hans de Goede wrote: >> * arm-gp2x-linux-kernel-headers >> Kernel headers for Cross Compiling to arm-gp2x-linux >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242203 > > All the linux-libc-headers projects are obsolete now; don't use them. > Use headers generated by running 'make headers_install' in a kernel > tree. > Well, this is what the upstream / manufacturer provided SDK uses, and I would rather not deviate from that. Also I haven't tested cross compiling the kernel with the toolchain yet. Can I just take a kernel run "make menuconfig" and then "make headers_install" ? Do you know what config I should use for the gp2x handheld? (arm based handheld console) Regards, Hans From dwmw2 at infradead.org Fri Jul 13 15:31:44 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 13 Jul 2007 16:31:44 +0100 Subject: Looking for people to trade reviews with. In-Reply-To: <469791C2.8020000@hhs.nl> References: <469787F6.4000404@hhs.nl> <1184338238.8809.13.camel@hades.cambridge.redhat.com> <469791C2.8020000@hhs.nl> Message-ID: <1184340704.8809.26.camel@hades.cambridge.redhat.com> On Fri, 2007-07-13 at 16:52 +0200, Hans de Goede wrote: > Well, this is what the upstream / manufacturer provided SDK uses, and I would > rather not deviate from that. Also I haven't tested cross compiling the kernel > with the toolchain yet. OTOH 'make headers_install' is what the upstream kernel does, and I would rather we didn't deviate from that :) > Can I just take a kernel run "make menuconfig" and then > "make headers_install" ? Do you know what config I should use for the gp2x > handheld? (arm based handheld console) You can do 'make ARCH=arm headers_install'. You don't need to do any configuration. (Please stop for a moment and then think about what the world would be like if the kernel's configuration made a difference to the kernel<->user ABI -- other than just meaning that some features are unavailable and return -ENOSYS etc. :) -- dwmw2 From martin.sourada at seznam.cz Fri Jul 13 15:38:04 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 13 Jul 2007 17:38:04 +0200 Subject: Nodoka theme engine In-Reply-To: <1184334393.3152.9.camel@localhost.localdomain> References: <103033.97067.qm@web45213.mail.sp1.yahoo.com> <1184232195.11085.14.camel@pc-notebook> <1184245203.21639.6.camel@pc-notebook> <1184304318.3098.23.camel@localhost.localdomain> <1184312524.29481.25.camel@pc-notebook> <1184334393.3152.9.camel@localhost.localdomain> Message-ID: <1184341084.3615.5.camel@pc-notebook> On Fri, 2007-07-13 at 15:46 +0200, Matthias Clasen wrote: > Sure, if you are willing to maintain it long-term, that is fine. > In that case, we should also get it into rawhide soon, so that we don't > have to push it through package review at the last minute after deciding > on the artwork. > > Matthias > > _______________________________________________ > Fedora-art-list mailing list > Fedora-art-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-art-list I've submitted a package review for the gtk-nodoka-engine package (includes the engine, the gtk theme, the metacity theme and the metatheme [/usr/share/themes/Nodoka/index.theme]). CC-ing maintainers list. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Fri Jul 13 15:34:48 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 13 Jul 2007 11:34:48 -0400 Subject: Nodoka theme engine In-Reply-To: <1184341084.3615.5.camel@pc-notebook> References: <103033.97067.qm@web45213.mail.sp1.yahoo.com> <1184232195.11085.14.camel@pc-notebook> <1184245203.21639.6.camel@pc-notebook> <1184304318.3098.23.camel@localhost.localdomain> <1184312524.29481.25.camel@pc-notebook> <1184334393.3152.9.camel@localhost.localdomain> <1184341084.3615.5.camel@pc-notebook> Message-ID: <1184340888.3152.18.camel@localhost.localdomain> On Fri, 2007-07-13 at 17:38 +0200, Martin Sourada wrote: > I've submitted a package review for the gtk-nodoka-engine package > (includes the engine, the gtk theme, the metacity theme and the > metatheme [/usr/share/themes/Nodoka/index.theme]). CC-ing maintainers > list. Gah, I should have mentioned before; here is the usual split for packaging themes: - engine goes in a separate package, together with the default theme for that engine - the metacity and metatheme go in another package, I don't care too much if you split that up further Ray is supposed to write an email about the artwork repackaging he has been doing on redhat-artwork recently, I don't know if he ended up doing separate packages for metacity themes. In any case, I'll poke Ray to send that mail, and then it would be good to follow the same pattern. Splitting the engine part off is important, because the rest can be noarch (and is often large, think icon themes) Matthias From martin.sourada at seznam.cz Fri Jul 13 16:10:44 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 13 Jul 2007 18:10:44 +0200 Subject: Nodoka theme engine In-Reply-To: <1184340888.3152.18.camel@localhost.localdomain> References: <103033.97067.qm@web45213.mail.sp1.yahoo.com> <1184232195.11085.14.camel@pc-notebook> <1184245203.21639.6.camel@pc-notebook> <1184304318.3098.23.camel@localhost.localdomain> <1184312524.29481.25.camel@pc-notebook> <1184334393.3152.9.camel@localhost.localdomain> <1184341084.3615.5.camel@pc-notebook> <1184340888.3152.18.camel@localhost.localdomain> Message-ID: <1184343044.3615.9.camel@pc-notebook> On Fri, 2007-07-13 at 17:34 +0200, Matthias Clasen wrote: > Gah, I should have mentioned before; here is the usual split for > packaging themes: > > - engine goes in a separate package, together with the default theme > for that engine > > - the metacity and metatheme go in another package, I don't care > too much if you split that up further > > Ray is supposed to write an email about the artwork repackaging he has > been doing on redhat-artwork recently, I don't know if he ended up doing > separate packages for metacity themes. In any case, I'll poke Ray to > send that mail, and then it would be good to follow the same pattern. > > Splitting the engine part off is important, because the rest can be > noarch (and is often large, think icon themes) > > > Matthias > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers Hm... I see the point... I wonder, if I split the metacity and metatheme into subpackages, can the engine package be arch specific, and subpackages noarch? -------------- 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 mattdm at mattdm.org Fri Jul 13 16:53:45 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 13 Jul 2007 12:53:45 -0400 Subject: updating two interdependent packages in new build system Message-ID: <20070713165345.GA20378@jadzia.bu.edu> Okay, clearly I'm being dense here, but I can't find documentation on how to do this. I'm building wxPython 2.8.4.0 for F-7. It requires wxGTK 2.8.4, which I built yesterday. With the old build system, after waiting a short time, the new package was automagically there for me to build against (possibly release engineer elves are doing something in the background -- it was transparent to me). And that happened with the new system for Rawhide, too. But it doesn't seem to be happening for F-7. Do I need to do something? Putting out the wxGTK update before the wxPython update will probably break the existing wxPython. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From belegdol at gmail.com Fri Jul 13 16:56:54 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Fri, 13 Jul 2007 17:56:54 +0100 Subject: updating two interdependent packages in new build system In-Reply-To: <20070713165345.GA20378@jadzia.bu.edu> References: <20070713165345.GA20378@jadzia.bu.edu> Message-ID: <9b1b20e70707130956h68df0c08nfcffcc786d57f6b1@mail.gmail.com> 2007/7/13, Matthew Miller : > Okay, clearly I'm being dense here, but I can't find documentation on how to > do this. I'm building wxPython 2.8.4.0 for F-7. It requires wxGTK 2.8.4, > which I built yesterday. With the old build system, after waiting a short > time, the new package was automagically there for me to build against > (possibly release engineer elves are doing something in the background -- it > was transparent to me). And that happened with the new system for Rawhide, > too. But it doesn't seem to be happening for F-7. Do I need to do something? > Putting out the wxGTK update before the wxPython update will probably break > the existing wxPython. > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > IIRC you need to email rel-eng to temporarily put wxGTK into the build system repo. From limb at jcomserv.net Fri Jul 13 16:46:21 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 13 Jul 2007 11:46:21 -0500 (CDT) Subject: updating two interdependent packages in new build system In-Reply-To: <20070713165345.GA20378@jadzia.bu.edu> References: <20070713165345.GA20378@jadzia.bu.edu> Message-ID: <20826.65.192.24.164.1184345181.squirrel@mail.jcomserv.net> Do an update and push it to testing or stable in bodhi. http://admin.fedoraproject.org/updates > Okay, clearly I'm being dense here, but I can't find documentation on how > to > do this. I'm building wxPython 2.8.4.0 for F-7. It requires wxGTK 2.8.4, > which I built yesterday. With the old build system, after waiting a short > time, the new package was automagically there for me to build against > (possibly release engineer elves are doing something in the background -- > it > was transparent to me). And that happened with the new system for Rawhide, > too. But it doesn't seem to be happening for F-7. Do I need to do > something? > Putting out the wxGTK update before the wxPython update will probably > break > the existing wxPython. > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > -- > 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 Jul 12 17:13:38 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 12 Jul 2007 19:13:38 +0200 Subject: Looking for people to trade reviews with. In-Reply-To: <1184340704.8809.26.camel@hades.cambridge.redhat.com> References: <469787F6.4000404@hhs.nl> <1184338238.8809.13.camel@hades.cambridge.redhat.com> <469791C2.8020000@hhs.nl> <1184340704.8809.26.camel@hades.cambridge.redhat.com> Message-ID: <46966142.30503@hhs.nl> David Woodhouse wrote: > On Fri, 2007-07-13 at 16:52 +0200, Hans de Goede wrote: >> Well, this is what the upstream / manufacturer provided SDK uses, and I would >> rather not deviate from that. Also I haven't tested cross compiling the kernel >> with the toolchain yet. > > OTOH 'make headers_install' is what the upstream kernel does, and I > would rather we didn't deviate from that :) > Well, did it support that with 2.6.9 too, because thats what the gp2x firmware has. Don't get me wrong I'm fine with switching if: -the chance for regressions is close to 0 -we solve the 40 mb srpm for a few headers issue >> Can I just take a kernel run "make menuconfig" and then >> "make headers_install" ? Do you know what config I should use for the gp2x >> handheld? (arm based handheld console) > > You can do 'make ARCH=arm headers_install'. You don't need to do any > configuration. > > (Please stop for a moment and then think about what the world would be > like if the kernel's configuration made a difference to the > kernel<->user ABI -- other than just meaning that some features are > unavailable and return -ENOSYS etc. :) > Good point! Regards, Hans From mattdm at mattdm.org Fri Jul 13 17:28:42 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 13 Jul 2007 13:28:42 -0400 Subject: updating two interdependent packages in new build system In-Reply-To: <20826.65.192.24.164.1184345181.squirrel@mail.jcomserv.net> References: <20070713165345.GA20378@jadzia.bu.edu> <20826.65.192.24.164.1184345181.squirrel@mail.jcomserv.net> Message-ID: <20070713172842.GA24951@jadzia.bu.edu> On Fri, Jul 13, 2007 at 11:46:21AM -0500, Jon Ciesla wrote: > Do an update and push it to testing or stable in bodhi. > http://admin.fedoraproject.org/updates Err, yes, but as noted in the message below (I'd quote the relevant part, but it's a pain because you've top-posted), that could break stable or testing, so I don't want to do that. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Fri Jul 13 17:29:33 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 13 Jul 2007 13:29:33 -0400 Subject: updating two interdependent packages in new build system In-Reply-To: <9b1b20e70707130956h68df0c08nfcffcc786d57f6b1@mail.gmail.com> References: <20070713165345.GA20378@jadzia.bu.edu> <9b1b20e70707130956h68df0c08nfcffcc786d57f6b1@mail.gmail.com> Message-ID: <20070713172933.GB24951@jadzia.bu.edu> On Fri, Jul 13, 2007 at 05:56:54PM +0100, Julian Sikorski wrote: > >Putting out the wxGTK update before the wxPython update will probably > >break the existing wxPython. > IIRC you need to email rel-eng to temporarily put wxGTK into the build > system repo. Really? Well, presumably that'll become enough of an annoying chore for the rel-eng people that they're fix it. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tmz at pobox.com Fri Jul 13 18:06:26 2007 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 13 Jul 2007 14:06:26 -0400 Subject: updating two interdependent packages in new build system In-Reply-To: <20070713165345.GA20378@jadzia.bu.edu> References: <20070713165345.GA20378@jadzia.bu.edu> Message-ID: <20070713180626.GA13357@psilocybe.teonanacatl.org> Matthew Miller wrote: > Okay, clearly I'm being dense here, but I can't find documentation > on how to do this. I'm building wxPython 2.8.4.0 for F-7. It > requires wxGTK 2.8.4, which I built yesterday. With the old build > system, after waiting a short time, the new package was > automagically there for me to build against (possibly release > engineer elves are doing something in the background -- it was > transparent to me). And that happened with the new system for > Rawhide, too. But it doesn't seem to be happening for F-7. Do I need > to do something? Putting out the wxGTK update before the wxPython > update will probably break the existing wxPython. I thought this was what "make chain-build" was supposed to do? I haven't used it, so I could be completely wrong about its purpose or suitability here. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The world keeps ending but new people too dumb to know it keep showing up as if the fun's just started. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jima at beer.tclug.org Fri Jul 13 18:10:56 2007 From: jima at beer.tclug.org (Jima) Date: Fri, 13 Jul 2007 13:10:56 -0500 (CDT) Subject: updating two interdependent packages in new build system In-Reply-To: <20070713180626.GA13357@psilocybe.teonanacatl.org> References: <20070713165345.GA20378@jadzia.bu.edu> <20070713180626.GA13357@psilocybe.teonanacatl.org> Message-ID: On Fri, 13 Jul 2007, Todd Zullinger wrote: > I thought this was what "make chain-build" was supposed to do? I > haven't used it, so I could be completely wrong about its purpose or > suitability here. If you were, so was I, and this needs to be better explained. Jima From mattdm at mattdm.org Fri Jul 13 18:49:18 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 13 Jul 2007 14:49:18 -0400 Subject: updating two interdependent packages in new build system In-Reply-To: <20070713180626.GA13357@psilocybe.teonanacatl.org> References: <20070713165345.GA20378@jadzia.bu.edu> <20070713180626.GA13357@psilocybe.teonanacatl.org> Message-ID: <20070713184918.GA3355@jadzia.bu.edu> On Fri, Jul 13, 2007 at 02:06:26PM -0400, Todd Zullinger wrote: > > to do something? Putting out the wxGTK update before the wxPython > > update will probably break the existing wxPython. > I thought this was what "make chain-build" was supposed to do? I > haven't used it, so I could be completely wrong about its purpose or > suitability here. wxPython/F-7$ make chain-build CHAIN="wxGTK" Packages in destination tag dist-fc7-updates-candidate are not inherited by build tag dist-fc7-build Target dist-fc7-updates-candidate is not usable for a chain-build Which I'm sure is a very meaningful error message to someone.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From triad at df.lth.se Fri Jul 13 18:58:15 2007 From: triad at df.lth.se (Linus Walleij) Date: Fri, 13 Jul 2007 20:58:15 +0200 (CEST) Subject: taking libbtctl and gnome-bluetooth In-Reply-To: <1184265890.4117.195.camel@cookie.hadess.net> References: <1184265890.4117.195.camel@cookie.hadess.net> Message-ID: On Thu, 12 Jul 2007, Bastien Nocera wrote: > In all cases, I'm upstream for those packages, and hoping to deprecate > them in the long-term (hopefully before Fedora 9, although it looks > unlikely for Fedora 8 right now). Just out of curiosity: what's gonna happen to them? > The only package depending on those is gnome-phone-manager (which is due > an upstream release as well). > Anyone against me taking those? Do you want gnome-phone-manager as well? Else, I'm very happy if you want to co-maintain it, so you can sync release of all three programs and roll in a single Bodhi release. Linus From martin.sourada at seznam.cz Fri Jul 13 19:01:02 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 13 Jul 2007 21:01:02 +0200 Subject: Nodoka theme engine In-Reply-To: <1184341743.3615.8.camel@pc-notebook> References: <103033.97067.qm@web45213.mail.sp1.yahoo.com> <1184232195.11085.14.camel@pc-notebook> <1184245203.21639.6.camel@pc-notebook> <1184304318.3098.23.camel@localhost.localdomain> <1184312524.29481.25.camel@pc-notebook> <1184334393.3152.9.camel@localhost.localdomain> <1184341084.3615.5.camel@pc-notebook> <1184340888.3152.18.camel@localhost.localdomain> <1184341743.3615.8.camel@pc-notebook> Message-ID: <1184353262.3615.22.camel@pc-notebook> On Fri, 2007-07-13 at 17:49 +0200, Martin Sourada wrote: > Hm... I see the point... I wonder, if I split the metacity and metatheme > into subpackages, can the engine package be arch specific, and > subpackages noarch? > _______________________________________________ > Fedora-art-list mailing list > Fedora-art-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-art-list Ok, I prepared new packages and put them on the wiki [1]. For submission to the Package Review I will wait for your consideration. So, the changes to the upstream are that I splitted the package in two: the first contains gtk engine and theme, the second one contains metacity theme and metatheme. So I made one archspecific rpm containing the content of the first package and two noarch rpms containing the second package - one for metacity and one for the metatheme. The metacity theme package is subpackage of the metatheme package. I decided to rename the upstream packages to gtk-nodoka-engine-%{version} and nodoka-theme-gnome-%{version}. For rpms the names are same and the metacity theme package is named nodoka-metacity-theme (same scheme as in echo-icon-theme). I didn't bothered much this time with obsoletes/provides (and will drop the older ones in future as well) to keep the spec files as clean as possible. So if you want to update, I recommend to reinstall the packages rather than update them (however if you update/install them all at once it will work). If you are OK with these changes I will submit the new version on the package review and make new package review for the second one. Thanks, Martin References: [1] http://fedoraproject.org/wiki/Artwork/NodokaTheme -------------- 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 Michael_E_Brown at dell.com Fri Jul 13 19:54:18 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 13 Jul 2007 14:54:18 -0500 Subject: Looking for people to trade reviews with. In-Reply-To: <469787F6.4000404@hhs.nl> References: <469787F6.4000404@hhs.nl> Message-ID: <20070713195417.GB21352@humbolt.us.dell.com> On Fri, Jul 13, 2007 at 04:11:02PM +0200, Hans de Goede wrote: > Hi All, > > I've got a number of packager for which its close to impossible to find a > reviewer. I'm looking for people todo a 100% "technical" review of this, > iow just check if it matches the guidelines. I'm afraid that there is > no-one with the expertise to also check if things like the used configure > flags etc are sane. However I've poured a ton of time in to this. For > researching how to best do this amongst other things, so I'm pretty sure > everything is ok. You will just have to trust me on my blue ^H^H^H^H brown > eyes for that. I've tested these packages to compile a variety of software > for the involved hardware and the resulting binaries worked fine. > > Here is the list: > * avr-libc > C library for use with GCC on Atmel AVR microcontrollers > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241279 Since I have been patiently waiting for this, I will be happy to do a review on it. I dont have any packages that I need reviewed in turn, but if something comes up, I'll let you know. :) -- Michael -just discovered how cool it is to program for 8-bit processors with 1k flash- Brown From Michael_E_Brown at dell.com Fri Jul 13 21:11:21 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 13 Jul 2007 16:11:21 -0500 Subject: Looking for people to trade reviews with. In-Reply-To: <20070713195417.GB21352@humbolt.us.dell.com> References: <469787F6.4000404@hhs.nl> <20070713195417.GB21352@humbolt.us.dell.com> Message-ID: <20070713211120.GC21352@humbolt.us.dell.com> On Fri, Jul 13, 2007 at 02:54:18PM -0500, Michael E Brown wrote: > On Fri, Jul 13, 2007 at 04:11:02PM +0200, Hans de Goede wrote: > > Hi All, > > > > I've got a number of packager for which its close to impossible to find a > > reviewer. I'm looking for people todo a 100% "technical" review of this, > > iow just check if it matches the guidelines. I'm afraid that there is > > no-one with the expertise to also check if things like the used configure > > flags etc are sane. However I've poured a ton of time in to this. For > > researching how to best do this amongst other things, so I'm pretty sure > > everything is ok. You will just have to trust me on my blue ^H^H^H^H brown > > eyes for that. I've tested these packages to compile a variety of software > > for the involved hardware and the resulting binaries worked fine. > > > > Here is the list: > > * avr-libc > > C library for use with GCC on Atmel AVR microcontrollers > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241279 > > Since I have been patiently waiting for this, I will be happy to do a > review on it. > > I dont have any packages that I need reviewed in turn, but if something > comes up, I'll let you know. :) Hans, There were a couple of MUST items in the review guidelines that merit discussion: - MUST: Header files must be in a -devel package. --> rpmlint also complains about this - MUST: Static libraries must be in a -static package. --> rpmlint also complains about this This package is a cross-compiled libc. Does it fall under these guidelines? I dont see any specific guidance for cross-building tools. There were two other items I found that should be easily fixable. Havent quite finished the review yet, though (only got through review guidelines for today). Still need to run through the naming guidelines and packaging guidelines. -- Michael From j.w.r.degoede at hhs.nl Fri Jul 13 21:22:21 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 13 Jul 2007 23:22:21 +0200 Subject: Looking for people to trade reviews with. In-Reply-To: <20070713211120.GC21352@humbolt.us.dell.com> References: <469787F6.4000404@hhs.nl> <20070713195417.GB21352@humbolt.us.dell.com> <20070713211120.GC21352@humbolt.us.dell.com> Message-ID: <4697ED0D.1010105@hhs.nl> Michael E Brown wrote: > Hans, > > There were a couple of MUST items in the review guidelines that merit > discussion: > > - MUST: Header files must be in a -devel package. > --> rpmlint also complains about this > - MUST: Static libraries must be in a -static package. > --> rpmlint also complains about this > These 2 are definitively not relevant for this package, see for example also gcc, it includes .obj and .h files too, without putting them in a seperate -devel package. If the packages sole purpose is to compile other programs, putting bits of it in a -devel package is nonsense. > This package is a cross-compiled libc. Does it fall under these > guidelines? I dont see any specific guidance for cross-building tools. > Notice that there are some WIP cross compiler packaging guidelines here: http://fedoraproject.org/wiki/Extras/SIGs/Embedded/CrossCompiling But these badly need updating. And as already said above, clearly it doesn't, because these guidelines do not make any sense in the case of this package. > There were two other items I found that should be easily fixable. Havent > quite finished the review yet, though (only got through review > guidelines for today). Still need to run through the naming guidelines > and packaging guidelines. Regards, Hans From Michael_E_Brown at dell.com Fri Jul 13 21:39:41 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 13 Jul 2007 16:39:41 -0500 Subject: Looking for people to trade reviews with. In-Reply-To: <4697ED0D.1010105@hhs.nl> References: <469787F6.4000404@hhs.nl> <20070713195417.GB21352@humbolt.us.dell.com> <20070713211120.GC21352@humbolt.us.dell.com> <4697ED0D.1010105@hhs.nl> Message-ID: <20070713213940.GD21352@humbolt.us.dell.com> On Fri, Jul 13, 2007 at 11:22:21PM +0200, Hans de Goede wrote: > Michael E Brown wrote: > >Hans, > > > >There were a couple of MUST items in the review guidelines that merit > >discussion: > > > >- MUST: Header files must be in a -devel package. > > --> rpmlint also complains about this > >- MUST: Static libraries must be in a -static package. > > --> rpmlint also complains about this > > > > These 2 are definitively not relevant for this package, see for example > also gcc, it includes .obj and .h files too, without putting them in a > seperate -devel package. If the packages sole purpose is to compile other > programs, putting bits of it in a -devel package is nonsense. > > > >This package is a cross-compiled libc. Does it fall under these > >guidelines? I dont see any specific guidance for cross-building tools. > > > > Notice that there are some WIP cross compiler packaging guidelines here: > http://fedoraproject.org/wiki/Extras/SIGs/Embedded/CrossCompiling > > But these badly need updating. > > And as already said above, clearly it doesn't, because these guidelines do > not make any sense in the case of this package. Ok. That is what I thought, too, but I thought it worth discussing. I'll try to finish the review this weekend. Looking forward to seeing this in the distro. -- Michael From dwmw2 at infradead.org Sat Jul 14 00:06:38 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 14 Jul 2007 01:06:38 +0100 Subject: Looking for people to trade reviews with. In-Reply-To: <46966142.30503@hhs.nl> References: <469787F6.4000404@hhs.nl> <1184338238.8809.13.camel@hades.cambridge.redhat.com> <469791C2.8020000@hhs.nl> <1184340704.8809.26.camel@hades.cambridge.redhat.com> <46966142.30503@hhs.nl> Message-ID: <1184371598.2785.86.camel@shinybook.infradead.org> On Thu, 2007-07-12 at 19:13 +0200, Hans de Goede wrote: > David Woodhouse wrote: > > On Fri, 2007-07-13 at 16:52 +0200, Hans de Goede wrote: > >> Well, this is what the upstream / manufacturer provided SDK uses, and I would > >> rather not deviate from that. Also I haven't tested cross compiling the kernel > >> with the toolchain yet. > > > > OTOH 'make headers_install' is what the upstream kernel does, and I > > would rather we didn't deviate from that :) > > > > Well, did it support that with 2.6.9 too, because thats what the gp2x firmware > has. No, the kernel didn't support it till 2.6.18, iirc. But you're already using something newer than 2.6.9, aren't you? > Don't get me wrong I'm fine with switching if: > -the chance for regressions is close to 0 Since we don't have the package yet, a regression would be hard :) > -we solve the 40 mb srpm for a few headers issue 40 millibits? :) http://git.kernel.org/?p=linux/kernel/git/dwmw2/kernel-headers.git;a=summary Once upon a time I was vaguely intending to make tarball releases of that, coinciding with Linus' own releases. Mostly I've just been ignoring it and leaving the script to its own devices though. It's not _quite_ the same because I think it lacks version.h. You'd do better to actually run 'make headers_install'. -- dwmw2 From jkeating at redhat.com Sat Jul 14 01:09:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Jul 2007 21:09:25 -0400 Subject: updating two interdependent packages in new build system In-Reply-To: <20070713184918.GA3355@jadzia.bu.edu> References: <20070713165345.GA20378@jadzia.bu.edu> <20070713180626.GA13357@psilocybe.teonanacatl.org> <20070713184918.GA3355@jadzia.bu.edu> Message-ID: <20070713210925.6ea033bb@ender> On Fri, 13 Jul 2007 14:49:18 -0400 Matthew Miller wrote: > wxPython/F-7$ make chain-build CHAIN="wxGTK" > > Packages in destination tag dist-fc7-updates-candidate are not > inherited by build tag dist-fc7-build > Target dist-fc7-updates-candidate is not usable for a chain-build > > Which I'm sure is a very meaningful error message to someone.... http://fedoraproject.org/wiki/Koji/CurrentKojiTags With koji, we have collections and inheritance. A build tag is a collection of packages that are available in the buildroot. This is the package collection that createrepo is ran on. Multiple build targets can use a single build tag to save time/space on running createrepo. Since allowing the build tag to self update with potentially bad updates can lead to things being shipped that are built against packages that are pulled we don't self update the updates buildroot. We have to do a manual override when you need to update a chain of packages. That said, we are willing to experiment with self updating, once bodhi gains the ability to prevent an update from being pushed that was built against another package that either isn't released yet, or isn't marked for release. Once that support is in, we'll open the buildroot to be self updating and chain-build will work once again. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Sat Jul 14 02:57:33 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 13 Jul 2007 22:57:33 -0400 Subject: updating two interdependent packages in new build system In-Reply-To: <20070713210925.6ea033bb@ender> References: <20070713165345.GA20378@jadzia.bu.edu> <20070713180626.GA13357@psilocybe.teonanacatl.org> <20070713184918.GA3355@jadzia.bu.edu> <20070713210925.6ea033bb@ender> Message-ID: <20070714025733.GA16480@jadzia.bu.edu> On Fri, Jul 13, 2007 at 09:09:25PM -0400, Jesse Keating wrote: > > Packages in destination tag dist-fc7-updates-candidate are not > > inherited by build tag dist-fc7-build > > Target dist-fc7-updates-candidate is not usable for a chain-build > > Which I'm sure is a very meaningful error message to someone.... > http://fedoraproject.org/wiki/Koji/CurrentKojiTags Okay, thanks. It actually does make perfect sense, but maybe it'd be nice to include a "translated" error message as well. > We have to do a manual override when you need to update a chain of > packages. Could you go ahead and do that for the wxGTK-2.8.4-3.fc7 packages? > That said, we are willing to experiment with self updating, once bodhi > gains the ability to prevent an update from being pushed that was built > against another package that either isn't released yet, or isn't marked > for release. Once that support is in, we'll open the buildroot to be > self updating and chain-build will work once again. I understand the concern, but doesn't this basically fill your days? I mean, it basically applies to any update that requires rebuilt dependencies.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From j.w.r.degoede at hhs.nl Sat Jul 14 07:47:25 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 14 Jul 2007 09:47:25 +0200 Subject: Looking for people to trade reviews with. In-Reply-To: <1184371598.2785.86.camel@shinybook.infradead.org> References: <469787F6.4000404@hhs.nl> <1184338238.8809.13.camel@hades.cambridge.redhat.com> <469791C2.8020000@hhs.nl> <1184340704.8809.26.camel@hades.cambridge.redhat.com> <46966142.30503@hhs.nl> <1184371598.2785.86.camel@shinybook.infradead.org> Message-ID: <46987F8D.9040505@hhs.nl> David Woodhouse wrote: > On Thu, 2007-07-12 at 19:13 +0200, Hans de Goede wrote: >> David Woodhouse wrote: >>> On Fri, 2007-07-13 at 16:52 +0200, Hans de Goede wrote: >>>> Well, this is what the upstream / manufacturer provided SDK uses, and I would >>>> rather not deviate from that. Also I haven't tested cross compiling the kernel >>>> with the toolchain yet. >>> OTOH 'make headers_install' is what the upstream kernel does, and I >>> would rather we didn't deviate from that :) >>> >> Well, did it support that with 2.6.9 too, because thats what the gp2x firmware >> has. > > No, the kernel didn't support it till 2.6.18, iirc. But you're already > using something newer than 2.6.9, aren't you? > Yes I'm using 2.6.12.0 as that is what the upstream provided SDK uses. >> Don't get me wrong I'm fine with switching if: >> -the chance for regressions is close to 0 > > Since we don't have the package yet, a regression would be hard :) > I mean regressions compared to the current unreleased package set / upstream's SDK. Regards, Hans From jkeating at redhat.com Sat Jul 14 10:16:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 14 Jul 2007 06:16:03 -0400 Subject: updating two interdependent packages in new build system In-Reply-To: <20070714025733.GA16480@jadzia.bu.edu> References: <20070713165345.GA20378@jadzia.bu.edu> <20070713180626.GA13357@psilocybe.teonanacatl.org> <20070713184918.GA3355@jadzia.bu.edu> <20070713210925.6ea033bb@ender> <20070714025733.GA16480@jadzia.bu.edu> Message-ID: <20070714061603.10a9247a@ender> On Fri, 13 Jul 2007 22:57:33 -0400 Matthew Miller wrote: > Could you go ahead and do that for the wxGTK-2.8.4-3.fc7 packages? > Done, give it 20 minutes. > > That said, we are willing to experiment with self updating, once > > bodhi gains the ability to prevent an update from being pushed that > > was built against another package that either isn't released yet, > > or isn't marked for release. Once that support is in, we'll open > > the buildroot to be self updating and chain-build will work once > > again. > > > I understand the concern, but doesn't this basically fill your days? > I mean, it basically applies to any update that requires rebuilt > dependencies.... Nah, more like once every 3 days or so. It's a very quick action too, and any of the people currently in fedora rel-eng have the koji privs to do it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chitlesh at fedoraproject.org Sat Jul 14 12:00:43 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 14 Jul 2007 14:00:43 +0200 Subject: updating two interdependent packages in new build system In-Reply-To: <20070713210925.6ea033bb@ender> References: <20070713165345.GA20378@jadzia.bu.edu> <20070713180626.GA13357@psilocybe.teonanacatl.org> <20070713184918.GA3355@jadzia.bu.edu> <20070713210925.6ea033bb@ender> Message-ID: <13dbfe4f0707140500t55ce5503yc4ebf553a0dd29da@mail.gmail.com> On 7/14/07, Jesse Keating wrote: > We have to do a manual override when you need to update a chain of > packages. Can you do the same for libgeda-20070708, please? Chitlesh -- http://clunixchit.blogspot.com From mattdm at mattdm.org Sat Jul 14 12:40:09 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 14 Jul 2007 08:40:09 -0400 Subject: updating two interdependent packages in new build system In-Reply-To: <20070714061603.10a9247a@ender> References: <20070713165345.GA20378@jadzia.bu.edu> <20070713180626.GA13357@psilocybe.teonanacatl.org> <20070713184918.GA3355@jadzia.bu.edu> <20070713210925.6ea033bb@ender> <20070714025733.GA16480@jadzia.bu.edu> <20070714061603.10a9247a@ender> Message-ID: <20070714124009.GA24659@jadzia.bu.edu> On Sat, Jul 14, 2007 at 06:16:03AM -0400, Jesse Keating wrote: > > Could you go ahead and do that for the wxGTK-2.8.4-3.fc7 packages? > Done, give it 20 minutes. Thanks! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Sat Jul 14 12:41:00 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 14 Jul 2007 08:41:00 -0400 Subject: updating two interdependent packages in new build system In-Reply-To: <20070714061603.10a9247a@ender> References: <20070713165345.GA20378@jadzia.bu.edu> <20070713180626.GA13357@psilocybe.teonanacatl.org> <20070713184918.GA3355@jadzia.bu.edu> <20070713210925.6ea033bb@ender> <20070714025733.GA16480@jadzia.bu.edu> <20070714061603.10a9247a@ender> Message-ID: <20070714124100.GB24659@jadzia.bu.edu> On Sat, Jul 14, 2007 at 06:16:03AM -0400, Jesse Keating wrote: > Nah, more like once every 3 days or so. It's a very quick action too, > and any of the people currently in fedora rel-eng have the koji privs > to do it. Maybe there could be a way in the koji web interface to make the request? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Sat Jul 14 13:02:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 14 Jul 2007 09:02:59 -0400 Subject: updating two interdependent packages in new build system In-Reply-To: <20070714124100.GB24659@jadzia.bu.edu> References: <20070713165345.GA20378@jadzia.bu.edu> <20070713180626.GA13357@psilocybe.teonanacatl.org> <20070713184918.GA3355@jadzia.bu.edu> <20070713210925.6ea033bb@ender> <20070714025733.GA16480@jadzia.bu.edu> <20070714061603.10a9247a@ender> <20070714124100.GB24659@jadzia.bu.edu> Message-ID: <20070714090259.17ceb522@ender> On Sat, 14 Jul 2007 08:41:00 -0400 Matthew Miller wrote: > Maybe there could be a way in the koji web interface to make the > request? Well, I'd rather see effort put into bodhi so that we can do away with the -override tagging. -- Jesse Keating Release Engineer: Fedora -------------- 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 Sat Jul 14 13:04:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 14 Jul 2007 09:04:22 -0400 Subject: updating two interdependent packages in new build system In-Reply-To: <13dbfe4f0707140500t55ce5503yc4ebf553a0dd29da@mail.gmail.com> References: <20070713165345.GA20378@jadzia.bu.edu> <20070713180626.GA13357@psilocybe.teonanacatl.org> <20070713184918.GA3355@jadzia.bu.edu> <20070713210925.6ea033bb@ender> <13dbfe4f0707140500t55ce5503yc4ebf553a0dd29da@mail.gmail.com> Message-ID: <20070714090422.7790be11@ender> On Sat, 14 Jul 2007 14:00:43 +0200 "Chitlesh GOORAH" wrote: > Can you do the same for libgeda-20070708, please? Done. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chitlesh at fedoraproject.org Sat Jul 14 14:46:18 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sat, 14 Jul 2007 16:46:18 +0200 Subject: updating two interdependent packages in new build system In-Reply-To: <20070714090422.7790be11@ender> References: <20070713165345.GA20378@jadzia.bu.edu> <20070713180626.GA13357@psilocybe.teonanacatl.org> <20070713184918.GA3355@jadzia.bu.edu> <20070713210925.6ea033bb@ender> <13dbfe4f0707140500t55ce5503yc4ebf553a0dd29da@mail.gmail.com> <20070714090422.7790be11@ender> Message-ID: <13dbfe4f0707140746k446fcaf1jf0d5989e7c68a99e@mail.gmail.com> On 7/14/07, Jesse Keating wrote: > On Sat, 14 Jul 2007 14:00:43 +0200 > "Chitlesh GOORAH" wrote: > > > Can you do the same for libgeda-20070708, please? > > Done. thanks Chitlesh -- http://clunixchit.blogspot.com From j.w.r.degoede at hhs.nl Sun Jul 15 05:40:43 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 15 Jul 2007 07:40:43 +0200 Subject: Formal package takeover request because of AWOL maintainer Message-ID: <4699B35B.9020107@hhs.nl> Hi all, I would like to take over gnome-applet-sensors from Aaron Kurtz (a.kurtz at hardsun.net) because he is AWOL. Several contact attempts have been made and 2 mails have been sent to this list about it, one on the 30th of may this year: https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00986.html And one more one week ago. Also he has been pinged several times through bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 Thus I hereby ask formal permission from FESco to take gnome-applet-sensors over from him, as required by: http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers Aaron also maintains: cfv feh gnome-applet-netspeed Julian Sikorski has stated that he is willing to take over gnome-applet-netspeed. Since I maintain imlib2 I'll take over feh as it will be good to maintain atleast one application using it. I've no interest in cfv, so I propose to orphan it. Thanks & Regards, Hans From dominik at greysector.net Sun Jul 15 09:33:13 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 15 Jul 2007 11:33:13 +0200 Subject: Formal package takeover request because of AWOL maintainer In-Reply-To: <4699B35B.9020107@hhs.nl> References: <4699B35B.9020107@hhs.nl> Message-ID: <20070715093312.GA4531@ryvius.pekin.waw.pl> On Sunday, 15 July 2007 at 07:40, Hans de Goede wrote: > Hi all, > > I would like to take over gnome-applet-sensors from Aaron Kurtz > (a.kurtz at hardsun.net) because he is AWOL. Several contact attempts have > been made and 2 mails have been sent to this list about it, one on the 30th > of may this year: > https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00986.html > > And one more one week ago. Also he has been pinged several times through > bugzilla: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 > > Thus I hereby ask formal permission from FESco to take gnome-applet-sensors > over from him, as required by: > http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers > > Aaron also maintains: > cfv > feh > gnome-applet-netspeed > > Julian Sikorski has stated that he is willing to take over > gnome-applet-netspeed. Since I maintain imlib2 I'll take over feh as it > will be good to maintain atleast one application using it. I've no interest > in cfv, so I propose to orphan it. I'd like to take cfv, I use it frequently and I need it for EL-5, too. I was just going to request a branch from the maintainer. 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 dominik at greysector.net Sun Jul 15 09:39:23 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 15 Jul 2007 11:39:23 +0200 Subject: Formal package takeover request because of AWOL maintainer In-Reply-To: <20070715093312.GA4531@ryvius.pekin.waw.pl> References: <4699B35B.9020107@hhs.nl> <20070715093312.GA4531@ryvius.pekin.waw.pl> Message-ID: <20070715093923.GA5017@ryvius.pekin.waw.pl> On Sunday, 15 July 2007 at 11:33, Dominik 'Rathann' Mierzejewski wrote: [...] > > Aaron also maintains: > > cfv > > feh > > gnome-applet-netspeed > > > > Julian Sikorski has stated that he is willing to take over > > gnome-applet-netspeed. Since I maintain imlib2 I'll take over feh as it > > will be good to maintain atleast one application using it. I've no interest > > in cfv, so I propose to orphan it. > > I'd like to take cfv, I use it frequently and I need it for EL-5, too. > I was just going to request a branch from the maintainer. Sorry, scratch that. I mistook cfv with cksfv. Sorry again for the noise. 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sun Jul 15 11:08:33 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sun, 15 Jul 2007 13:08:33 +0200 Subject: Unable to login to bodhi Message-ID: <20070715130833.7cdcab0e@python3.es.egwn.lan> Hi, I currently can't log into bodhi at : https://admin.fedoraproject.org/updates/ I've tried the same login/pass for the voting interface, changing my account details, and it works fine. I've been mostly away for the last 2 weeks, so maybe I've missed some change, in which case I apologize... 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.45 0.54 0.74 From packages at amiga-hardware.com Sun Jul 15 12:49:35 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Sun, 15 Jul 2007 13:49:35 +0100 Subject: Packages not in repo Message-ID: <469A17DF.10109@amiga-hardware.com> Hi, I guess I might have missed something here, but I built some packages for FC-6 and they haven't appeared in the repo, despite devel and F7 appearing almost two weeks ago. For example: fuse-emulator-0.8.0.1 Any ideas? -- Ian Chapman. From jonathan.underwood at gmail.com Sun Jul 15 12:52:03 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 15 Jul 2007 13:52:03 +0100 Subject: updating two interdependent packages in new build system In-Reply-To: <20070714061603.10a9247a@ender> References: <20070713165345.GA20378@jadzia.bu.edu> <20070713180626.GA13357@psilocybe.teonanacatl.org> <20070713184918.GA3355@jadzia.bu.edu> <20070713210925.6ea033bb@ender> <20070714025733.GA16480@jadzia.bu.edu> <20070714061603.10a9247a@ender> Message-ID: <645d17210707150552ga8b370by97e7be321e84a8ab@mail.gmail.com> On 14/07/07, Jesse Keating wrote: > Nah, more like once every 3 days or so. It's a very quick action too, > and any of the people currently in fedora rel-eng have the koji privs > to do it. As an aside, in cases like this, where there's a circular BuildRequires dependency between two (or more) packages A and B, what you'd ideally like in many situation is that the built packages for A have a Requires: B >= %{version}-%{release} , where the version and release are the ones actually built against. Is there any way to do set version and release for this requires at package build time? The only way I can see of doing it is by querying rpm during building. That always seems to make people jump up and down though.:) Is there another, less fragile way? J From fedora at leemhuis.info Sun Jul 15 13:58:34 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 15 Jul 2007 15:58:34 +0200 Subject: EPEL report week 28, 2007 Message-ID: <469A280A.3050706@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week28 = Weekly EPEL Summary = Week 28/2007 == Most important happenings == * target date for for official EPEL announcement was set back by one week onto July the 26th. We need more time to fix all broken deps beforehand (and make sure any new ones hit the repo). Volunteers that help with that would be greatly appreciated. * discussions on the mailing list how to handle python-imaging -- it's in EL5Client, but not in EL5Server; thus if we don't ship it users will run into broken deps on EL5Server == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * Jeff_S (Jeff Sheltren) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * quiad (KarstenWade) Missing from the Steering Committee: * stahnma (MichaelStahnke) Others that participated the meeting: daMaestro === Summary === * broken deps/spam-o-magic ? Jeff_S/mmcgrath * not much progress * mmcgrath still fighting with the script (the latest version seems to depend on koji) he'll talk to mschwendt to find one for EPEL/get help * EPEL announcement ? quiad * we push the estimated announce-date back by one week to 20070726 -- we need more time to fix deps (aka: "release early, but only when it's not broken") * push new packages to testing after EPEL annoucement ? dgilmore * we discussed how to handle new and updated packages in the near future. We proceed as planed earlier: push everything to testing/ (which will become stable with the next quarterly update) and hand-move important updates over to stable; knurd and nirik are willing to help with that job, as that's a manual process. We need a wiki page and/or a e-mail alias for that. The problem will be solved with switching to bodhi in the long term * new meeting time? ? all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) * no new meeting time wound yet; looks a bit like everyone who edited the page likes the current time * ExcludeArch TrackerBugs for EPEL ? notting/knurd * some discussions, no agreement; discuss issue on the list again * free discussions * some derogatory comments about EPEL on another mailing list and some discussions how to improve our docs to avoid make clear what EPEL wants/what EPEL is about === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-July/msg00086.html == Stats == === General === Number of EPEL Contributors 110 We welcome 3 new contributors: jgranado_AT_redhat.com, lindner_AT_inuus.com, roland_AT_redhat.com === EPEL 5 === Number of source packages: 462 Number of binary packages: 834 There are 23 new Packages: * archivemail | A tool for archiving and compressing old email in mailboxes * colordiff | Color terminal highlighter for diff files * cvsps | Patchset tool for CVS * fftw | Fast Fourier Transform library * fwrestart | A way to more safely re-load firewall rules remotely * geomview | Interactive 3D viewing program * glibmm24 | C++ interface for GTK2 (a GUI library for X) * gshutdown | GShutDown is an advanced shut down utility for GNOME * libpaper | Library and tools for handling papersize * libsigc++20 | Typesafe signal framework for C++ * limph | A PHP5-compatible network host/service poller with web interface * mod_evasive | Denial of Service evasion module for Apache * mussh | Multihost SSH wrapper * mysql-proxy | A proxy for the MySQL Client/Server protocol * ntfsprogs | NTFS filesystem libraries and utilities * perl-MogileFS-Client | Client library for the MogileFS distributed file system * pylibacl | POSIX.1e ACLs library wrapper for python * pyxattr | Extended attributes library wrapper for Python * roundcubemail | Round Cube Webmail is a browser-based multilingual IMAP client * scrub | Disk scrubbing program * sub2srt | Convert files in .sub format to .srt * tiquit | A PHP5-compatible help desk incident tracking/knowledgebase system === EPEL 4 === Number of source packages: 284 Number of binary packages: 583 There are 13 new Packages: * archivemail | A tool for archiving and compressing old email in mailboxes * fftw | Fast Fourier Transform library * geomview | Interactive 3D viewing program * itk | Object oriented extensions to Tk * libpaper | Library and tools for handling papersize * limph | A PHP5-compatible network host/service poller with web interface * perl-MogileFS-Client | Client library for the MogileFS distributed file system * pylibacl | POSIX.1e ACLs library wrapper for python * pyxattr | Extended attributes library wrapper for Python * scrub | Disk scrubbing program * sub2srt | Convert files in .sub format to .srt * tiquit | A PHP5-compatible help desk incident tracking/knowledgebase system ---- ["CategoryEPELReports"] From jkeating at redhat.com Sun Jul 15 15:50:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 15 Jul 2007 11:50:23 -0400 Subject: Unable to login to bodhi In-Reply-To: <20070715130833.7cdcab0e@python3.es.egwn.lan> References: <20070715130833.7cdcab0e@python3.es.egwn.lan> Message-ID: <20070715115023.44eb983c@ender> On Sun, 15 Jul 2007 13:08:33 +0200 Matthias Saou wrote: > I currently can't log into bodhi at : > https://admin.fedoraproject.org/updates/ > > I've tried the same login/pass for the voting interface, changing my > account details, and it works fine. I've been mostly away for the last > 2 weeks, so maybe I've missed some change, in which case I > apologize... Are you using full user at foo.bar username when authing to the voting system and to change your details? I heard this actually works for some people, but it does not work with things like bodhi, nor the hosted.fedoraproject.org set, where you want just the username for your FAS account. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc 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 Sun Jul 15 16:33:18 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sun, 15 Jul 2007 18:33:18 +0200 Subject: Unable to login to bodhi In-Reply-To: <20070715115023.44eb983c@ender> References: <20070715130833.7cdcab0e@python3.es.egwn.lan> <20070715115023.44eb983c@ender> Message-ID: <20070715183318.75f5b39a@python3.es.egwn.lan> Jesse Keating wrote : > > I currently can't log into bodhi at : > > https://admin.fedoraproject.org/updates/ > > > > I've tried the same login/pass for the voting interface, changing my > > account details, and it works fine. I've been mostly away for the last > > 2 weeks, so maybe I've missed some change, in which case I > > apologize... > > > > Are you using full user at foo.bar username when authing to the voting > system and to change your details? I heard this actually works for > some people, but it does not work with things like bodhi, nor the > hosted.fedoraproject.org set, where you want just the username for your > FAS account. > > Nope. Using "Thias" everywhere. But I got it : It needs to be all lowercase with bodhi, whereas I've always put the capital "T" everywhere else. Possibly something minor to fix for consistency's sake ;-) 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.06 2.24 2.01 From bugs.michael at gmx.net Sun Jul 15 22:02:19 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 16 Jul 2007 00:02:19 +0200 Subject: Packages not in repo In-Reply-To: <469A17DF.10109@amiga-hardware.com> References: <469A17DF.10109@amiga-hardware.com> Message-ID: <20070716000219.4d2f8e2a.bugs.michael@gmx.net> On Sun, 15 Jul 2007 13:49:35 +0100, Ian Chapman wrote: > Hi, > > I guess I might have missed something here, but I built some packages > for FC-6 and they haven't appeared in the repo, despite devel and F7 > appearing almost two weeks ago. > > For example: fuse-emulator-0.8.0.1 > > Any ideas? Take a look at the broken deps mails you've received. The latest one reports an unresolved dep on 'perl(Fuse)'. From jkeating at redhat.com Mon Jul 16 02:31:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 15 Jul 2007 22:31:19 -0400 Subject: Unable to login to bodhi In-Reply-To: <20070715183318.75f5b39a@python3.es.egwn.lan> References: <20070715130833.7cdcab0e@python3.es.egwn.lan> <20070715115023.44eb983c@ender> <20070715183318.75f5b39a@python3.es.egwn.lan> Message-ID: <20070715223119.6120bf91@ender> On Sun, 15 Jul 2007 18:33:18 +0200 Matthias Saou wrote: > Nope. Using "Thias" everywhere. But I got it : It needs to be all > lowercase with bodhi, whereas I've always put the capital "T" > everywhere else. Possibly something minor to fix for consistency's > sake ;-) Indeed, everything should force lower case only (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Jul 16 07:28:26 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Jul 2007 09:28:26 +0200 (CEST) Subject: Unable to login to bodhi In-Reply-To: <20070715223119.6120bf91@ender> References: <20070715130833.7cdcab0e@python3.es.egwn.lan> <20070715115023.44eb983c@ender> <20070715183318.75f5b39a@python3.es.egwn.lan> <20070715223119.6120bf91@ender> Message-ID: <30845.192.54.193.51.1184570906.squirrel@rousalka.dyndns.org> Le Lun 16 juillet 2007 04:31, Jesse Keating a ?crit : > On Sun, 15 Jul 2007 18:33:18 +0200 > Matthias Saou > > wrote: > >> Nope. Using "Thias" everywhere. But I got it : It needs to be all >> lowercase with bodhi, whereas I've always put the capital "T" >> everywhere else. Possibly something minor to fix for consistency's >> sake ;-) > > Indeed, everything should force lower case only (: You mean, like Fedora bugzilla? -- Nicolas Mailhot From j.w.r.degoede at hhs.nl Mon Jul 16 07:55:33 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 16 Jul 2007 09:55:33 +0200 Subject: Requesting FESco member permission for package takeover because of AWOL maintainer Message-ID: <469B2475.1000501@hhs.nl> Hi all, I would like to take over gnome-applet-sensors from Aaron Kurtz (a.kurtz at hardsun.net) because he is AWOL. Several contact attempts have been made and 2 mails have been sent to this list about it, one on the 30th of may this year: https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00986.html And one more one week ago. Also he has been pinged several times through bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 Thus I hereby ask formal permission from FESco to take gnome-applet-sensors over from him, as required by: http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers Aaron also maintains: cfv feh gnome-applet-netspeed Julian Sikorski has stated that he is willing to take over gnome-applet-netspeed. Since I maintain imlib2 I'll take over feh as it will be good to maintain atleast one application using it. I've no interest in cfv, so I propose to orphan it. Thanks & Regards, Hans From dennis at ausil.us Mon Jul 16 08:58:45 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 16 Jul 2007 03:58:45 -0500 Subject: Requesting FESco member permission for package takeover because of AWOL maintainer In-Reply-To: <469B2475.1000501@hhs.nl> References: <469B2475.1000501@hhs.nl> Message-ID: <200707160358.50810.dennis@ausil.us> Once upon a time Monday 16 July 2007, Hans de Goede wrote: > Notice that according to the policy this does not need to be voted on at > the next Fesco meeting, I just need permission from a single FESco member, > Thanks!> > > Hi all, > > I would like to take over gnome-applet-sensors from Aaron Kurtz > (a.kurtz at hardsun.net) because he is AWOL. Several contact attempts have > been made and 2 mails have been sent to this list about it, one on the 30th > of may this year: > https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00986.html > > And one more one week ago. Also he has been pinged several times through > bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 > > Thus I hereby ask formal permission from FESco to take gnome-applet-sensors > over from him, as required by: > http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers Hans, Im ok with you taking over gnome-applet-sensors > Aaron also maintains: > cfv > feh > gnome-applet-netspeed > > Julian Sikorski has stated that he is willing to take over > gnome-applet-netspeed. Since I maintain imlib2 I'll take over feh as it > will be good to maintain atleast one application using it. I've no interest > in cfv, so I propose to orphan it. Sounds ok to me also. its there anyone who wants to maintain cfv? Dennis -------------- 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 Mon Jul 16 10:06:24 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 16 Jul 2007 12:06:24 +0200 Subject: Requesting FESco member permission for package takeover because of AWOL maintainer In-Reply-To: <200707160358.50810.dennis@ausil.us> References: <469B2475.1000501@hhs.nl> <200707160358.50810.dennis@ausil.us> Message-ID: <469B4320.7000608@hhs.nl> Dennis Gilmore wrote: > Once upon a time Monday 16 July 2007, Hans de Goede wrote: >> > Notice that according to the policy this does not need to be voted on at >> the next Fesco meeting, I just need permission from a single FESco member, >> Thanks!> >> >> Hi all, >> >> I would like to take over gnome-applet-sensors from Aaron Kurtz >> (a.kurtz at hardsun.net) because he is AWOL. Several contact attempts have >> been made and 2 mails have been sent to this list about it, one on the 30th >> of may this year: >> https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00986.html >> >> And one more one week ago. Also he has been pinged several times through >> bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 >> >> Thus I hereby ask formal permission from FESco to take gnome-applet-sensors >> over from him, as required by: >> http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers > > Hans, > Im ok with you taking over gnome-applet-sensors > >> Aaron also maintains: >> cfv >> feh >> gnome-applet-netspeed >> >> Julian Sikorski has stated that he is willing to take over >> gnome-applet-netspeed. Since I maintain imlib2 I'll take over feh as it >> will be good to maintain atleast one application using it. I've no interest >> in cfv, so I propose to orphan it. > > Sounds ok to me also. its there anyone who wants to maintain cfv? > > Dennis > Thanks. I've filed CVS admin requests for gnome-applet-sensors, gnome-applet-netspeed and feh. I'll wait a bit for a new owner to step up before orphaning cfv. I'll do a new gnome-applet-sensors fixing several bugs today. Regards, Hans From wolfy at nobugconsulting.ro Mon Jul 16 10:16:57 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 16 Jul 2007 13:16:57 +0300 Subject: Requesting FESco member permission for package takeover because of AWOL maintainer In-Reply-To: <469B4320.7000608@hhs.nl> References: <469B2475.1000501@hhs.nl> <200707160358.50810.dennis@ausil.us> <469B4320.7000608@hhs.nl> Message-ID: <469B4599.2090500@nobugconsulting.ro> Hans de Goede wrote: > Dennis Gilmore wrote: >> Once upon a time Monday 16 July 2007, Hans de Goede wrote: >>> >> Notice that according to the policy this does not need to be voted >>> on at >>> the next Fesco meeting, I just need permission from a single FESco >>> member, >>> Thanks!> >>> >>> Hi all, >>> >>> I would like to take over gnome-applet-sensors from Aaron Kurtz >>> (a.kurtz at hardsun.net) because he is AWOL. Several contact attempts have >>> been made and 2 mails have been sent to this list about it, one on >>> the 30th >>> of may this year: >>> https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00986.html >>> >>> >>> And one more one week ago. Also he has been pinged several times >>> through >>> bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 >>> >>> Thus I hereby ask formal permission from FESco to take >>> gnome-applet-sensors >>> over from him, as required by: >>> http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers >> >> Hans, Im ok with you taking over gnome-applet-sensors >> >>> Aaron also maintains: >>> cfv >>> feh >>> gnome-applet-netspeed >>> >>> Julian Sikorski has stated that he is willing to take over >>> gnome-applet-netspeed. Since I maintain imlib2 I'll take over feh as it >>> will be good to maintain atleast one application using it. I've no >>> interest >>> in cfv, so I propose to orphan it. >> >> Sounds ok to me also. its there anyone who wants to maintain cfv? >> >> Dennis >> > > Thanks. > > I've filed CVS admin requests for gnome-applet-sensors, > gnome-applet-netspeed and feh. I'll wait a bit for a new owner to step > up before orphaning cfv. I'll take cfv if no one actually using it wishes to. Manuel From z.kota at gmx.net Mon Jul 16 10:41:21 2007 From: z.kota at gmx.net (Zoltan Kota) Date: Mon, 16 Jul 2007 12:41:21 +0200 (CEST) Subject: python-elementree & F7? Message-ID: Hi, It seems python-elementtree is missing from F7 (and devel)! What is the reason? Maybe I missed something? Koji says: 271 python-elementtree dist-fc7 icon no Zoltan From j.w.r.degoede at hhs.nl Mon Jul 16 10:54:23 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 16 Jul 2007 12:54:23 +0200 Subject: Requesting FESco member permission for package takeover because of AWOL maintainer In-Reply-To: <469B4599.2090500@nobugconsulting.ro> References: <469B2475.1000501@hhs.nl> <200707160358.50810.dennis@ausil.us> <469B4320.7000608@hhs.nl> <469B4599.2090500@nobugconsulting.ro> Message-ID: <469B4E5F.5000804@hhs.nl> Manuel Wolfshant wrote: > Hans de Goede wrote: >> Dennis Gilmore wrote: >>> Once upon a time Monday 16 July 2007, Hans de Goede wrote: >>>> >>> Notice that according to the policy this does not need to be voted >>>> on at >>>> the next Fesco meeting, I just need permission from a single FESco >>>> member, >>>> Thanks!> >>>> >>>> Hi all, >>>> >>>> I would like to take over gnome-applet-sensors from Aaron Kurtz >>>> (a.kurtz at hardsun.net) because he is AWOL. Several contact attempts have >>>> been made and 2 mails have been sent to this list about it, one on >>>> the 30th >>>> of may this year: >>>> https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00986.html >>>> >>>> >>>> And one more one week ago. Also he has been pinged several times >>>> through >>>> bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 >>>> >>>> Thus I hereby ask formal permission from FESco to take >>>> gnome-applet-sensors >>>> over from him, as required by: >>>> http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers >>> >>> Hans, Im ok with you taking over gnome-applet-sensors >>> >>>> Aaron also maintains: >>>> cfv >>>> feh >>>> gnome-applet-netspeed >>>> >>>> Julian Sikorski has stated that he is willing to take over >>>> gnome-applet-netspeed. Since I maintain imlib2 I'll take over feh as it >>>> will be good to maintain atleast one application using it. I've no >>>> interest >>>> in cfv, so I propose to orphan it. >>> >>> Sounds ok to me also. its there anyone who wants to maintain cfv? >>> >>> Dennis >>> >> >> Thanks. >> >> I've filed CVS admin requests for gnome-applet-sensors, >> gnome-applet-netspeed and feh. I'll wait a bit for a new owner to step >> up before orphaning cfv. > I'll take cfv if no one actually using it wishes to. > Okay, If no one else responds, please file a CVS admin request to make you the new owner. Thnaks & Regards, Hans From z.kota at gmx.net Mon Jul 16 10:56:46 2007 From: z.kota at gmx.net (Zoltan Kota) Date: Mon, 16 Jul 2007 12:56:46 +0200 (CEST) Subject: python-elementree & F7? In-Reply-To: References: Message-ID: On Mon, 16 Jul 2007, Zoltan Kota wrote: > It seems python-elementtree is missing from F7 (and devel)! What is the > reason? Maybe I missed something? Ooops. In the meantime I found that it is included in python-2.5. Zoltan From bpeck at redhat.com Mon Jul 16 12:23:33 2007 From: bpeck at redhat.com (Bill Peck) Date: Mon, 16 Jul 2007 08:23:33 -0400 Subject: Unable to login to bodhi In-Reply-To: <20070715130833.7cdcab0e@python3.es.egwn.lan> References: <20070715130833.7cdcab0e@python3.es.egwn.lan> Message-ID: <469B6345.4060601@redhat.com> Matthias Saou wrote: > Hi, > > I currently can't log into bodhi at : > https://admin.fedoraproject.org/updates/ > > I've tried the same login/pass for the voting interface, changing my > account details, and it works fine. I've been mostly away for the last > 2 weeks, so maybe I've missed some change, in which case I apologize... > > Matthias > > I can't log in either. I don't have any updates to push yet, but figured I should get this straightened out now. I tried my cvs account/password. Would be helpful to have a link on the bodhi login page that tells you where to go to reset your password. From wolfy at nobugconsulting.ro Mon Jul 16 12:25:44 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 16 Jul 2007 15:25:44 +0300 Subject: Requesting FESco member permission for package takeover because of AWOL maintainer In-Reply-To: <469B4E5F.5000804@hhs.nl> References: <469B2475.1000501@hhs.nl> <200707160358.50810.dennis@ausil.us> <469B4320.7000608@hhs.nl> <469B4599.2090500@nobugconsulting.ro> <469B4E5F.5000804@hhs.nl> Message-ID: <469B63C8.3000708@nobugconsulting.ro> Hans de Goede wrote: >>>>> Aaron also maintains: >>>>> cfv >>>>> feh >>>>> gnome-applet-netspeed >>>>> >>>>> Julian Sikorski has stated that he is willing to take over >>>>> gnome-applet-netspeed. Since I maintain imlib2 I'll take over feh >>>>> as it >>>>> will be good to maintain atleast one application using it. I've no >>>>> interest >>>>> in cfv, so I propose to orphan it. >>>> >>>> Sounds ok to me also. its there anyone who wants to maintain cfv? >>>> >>>> Dennis >>>> >>> >>> Thanks. >>> >>> I've filed CVS admin requests for gnome-applet-sensors, >>> gnome-applet-netspeed and feh. I'll wait a bit for a new owner to >>> step up before orphaning cfv. >> I'll take cfv if no one actually using it wishes to. >> > > Okay, > > If no one else responds, please file a CVS admin request to make you > the new owner. I'll do it tomorrow if no one steps in manuel -- Manuel Wolfshant linux registered user #131416 IT manager NoBug Consulting Romania http://www.brainbench.com/transcript.jsp?pid=40317 From christoph.wickert at nurfuerspam.de Mon Jul 16 12:32:44 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Mon, 16 Jul 2007 14:32:44 +0200 Subject: python-elementree & F7? In-Reply-To: References: Message-ID: <1184589165.3424.2.camel@wicktop.localdomain> Am Montag, den 16.07.2007, 12:56 +0200 schrieb Zoltan Kota: > On Mon, 16 Jul 2007, Zoltan Kota wrote: > > > It seems python-elementtree is missing from F7 (and devel)! What is the > > reason? Maybe I missed something? > > Ooops. In the meantime I found that it is included in python-2.5. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232590 Christoph From jgranado at redhat.com Mon Jul 16 13:39:52 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Mon, 16 Jul 2007 15:39:52 +0200 Subject: resolution for python-imaging in EPEL Message-ID: <469B7528.3070800@redhat.com> Hi all: reference : BZ#246444 I have 1 of 2 choices: 1) upload the 1.1.5 source to EPEL cvs and build against EPEL/el5. AFAIK, the python-imaging package is out of repositories and EPEL/el5 has not gone public yet (it has been bumped to July 26). But I'm still unsure if this has nasty side effects (regarding the nvr comparison) with the user doing an upgrade. I really don't want to do this, because if some user has python-imaging from EPEL/el4 and wants to upgrade to EPEL/el5, the upgrade will not see the python-imaging from EPEL/el5. OTOH, I could be mistaken and thats why I ask. :) 2)The only two packages that use python-imaging are Plone and python-docutils. They make use of the standard library Image in the package and I'm pretty sure that that specific library, and the whole python-imaging library is backward compatible with the previous version (waiting for confirmation from upstream). So I would leave it as it is. It doesn't really break anything and the nvr is left alone. IMO 2 is the way to go. Comments greatly appreciated. Regards -- Joel Andres Granados From ville.skytta at iki.fi Mon Jul 16 18:48:56 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 16 Jul 2007 21:48:56 +0300 Subject: Rawhide debuginfo package problems 2007-07-16 Message-ID: <200707162148.57545.ville.skytta@iki.fi> Hello, Here are the results of debuginfocheck.py for current x86_64 Rawhide (run without -j). Many of these are "false positives" in the sense that as far as I know, rpmbuild does not create good -debuginfo packages for static lib only ones nor mono packages so there's not much packagers can do about them, but there are quite a few entries in the list that maintainers should take a look into, and some have related bugs open in Bugzilla already for a while. Debuginfo related docs for packagers: http://fedoraproject.org/wiki/Packaging/Debuginfo debuginfocheck.py is available at: http://koti.welho.com/vskytta/misc/debuginfocheck.py ---- Empty debuginfo packages: boo-debuginfo-0.7.6.2237-12.fc7.x86_64 check-debuginfo-0.9.3-5.fc6.x86_64 daap-sharp-debuginfo-0.3.3-4.fc6.x86_64 dbus-sharp-debuginfo-0.63-6.fc6.x86_64 dev86-debuginfo-0.16.17-4.fc7.x86_64 factory-debuginfo-2.0.5-11.fc7.x86_64 firmware-addon-dell-debuginfo-1.2.13-1.fc7.x86_64 gecko-sharp2-debuginfo-0.12-1.x86_64 gtksourceview-sharp-debuginfo-2.0-25.fc7.x86_64 intltool-debuginfo-0.35.5-3.fc7.x86_64 ipod-sharp-debuginfo-0.6.3-1.fc7.x86_64 ipvsadm-debuginfo-1.24-8.1.x86_64 iscsi-initiator-utils-debuginfo-6.2.0.865-0.1.fc7.x86_64 isicom-debuginfo-3.05-18.2.2.x86_64 libassuan-debuginfo-1.0.2-1.fc8.x86_64 libfac-debuginfo-2.0.5-8.fc7.x86_64 libmimedir-debuginfo-0.4-3.fc7.x86_64 libnet-debuginfo-1.1.2.1-10.fc7.x86_64 libnet10-debuginfo-1.0.2a-12.fc7.x86_64 libresample-debuginfo-0.1.3-3.fc6.x86_64 monodevelop-debuginfo-0.13.1-1.fc7.x86_64 plib16-debuginfo-1.6.0-6.fc6.x86_64 rdesktop-debuginfo-1.5.0-2.fc7.x86_64 syslinux-debuginfo-3.36-4.fc7.x86_64 timidity++-debuginfo-2.13.2-1.2.2.x86_64 traceroute-debuginfo-2.0.3-1.1.fc7.x86_64 vconfig-debuginfo-1.9-3.fc7.x86_64 wpa_supplicant-debuginfo-0.5.7-3.fc8.x86_64 yp-tools-debuginfo-2.9-0.1.x86_64 Debuginfo packages without sources: atlas-debuginfo-3.6.0-12.fc8.x86_64 beecrypt-debuginfo-4.1.2-12.x86_64 blender-debuginfo-2.44-4.fc8.x86_64 byaccj-debuginfo-1.11-2jpp.2.fc7.x86_64 cjet-debuginfo-0.8.9-1.fc8.x86_64 clisp-debuginfo-2.41-3.fc7.x86_64 csound-debuginfo-5.03.0-13.fc7.x86_64 curry-debuginfo-0.9.11-2.fc8.x86_64 eclipse-cdt-debuginfo-3.1.2-3.fc7.x86_64 esc-debuginfo-1.0.1-2.fc7.x86_64 freetennis-debuginfo-0.4.8-6.fc7.x86_64 happy-debuginfo-1.16-2.fc7.x86_64 hardlink-debuginfo-1.0-2.fc7.x86_64 hdf5-debuginfo-1.6.5-7.fc7.x86_64 hevea-debuginfo-1.08-6.fc6.x86_64 hfsplusutils-debuginfo-1.0.4-8.fc6.x86_64 jogl-debuginfo-1.0.0-5.7.beta5.fc6.x86_64 kanatest-debuginfo-0.4.2-2.fc8.x86_64 libdbi-debuginfo-0.8.1-2.1.x86_64 libdbi-drivers-debuginfo-0.8.1a-2.fc7.x86_64 libtomoe-gtk-debuginfo-0.6.0-1.fc8.x86_64 mediawiki-debuginfo-1.9.2-33.fc7.x86_64 mozplugger-debuginfo-1.7.3-3.1.x86_64 nhpf-debuginfo-1.42-9.2.2.x86_64 oddjob-debuginfo-0.27-9.x86_64 ogdi-debuginfo-3.2.0-0.5.beta1.fc7.x86_64 pgadmin3-debuginfo-1.6.3-1.fc7.x86_64 php-pecl-xdebug-debuginfo-2.0.0-0.5.RC2.fc7.x86_64 pvm-debuginfo-3.4.5-7.fc6.1.x86_64 rp-pppoe-debuginfo-3.8-1.fc7.x86_64 star-debuginfo-1.5a76-3.fc8.x86_64 synaptics-debuginfo-0.14.4-8.fc6.x86_64 transfig-debuginfo-3.2.5-1.fc7.x86_64 wings-debuginfo-0.98.36-1.fc7.x86_64 xfig-debuginfo-3.2.5-1.fc7.x86_64 xorg-x11-drv-jamstudio-debuginfo-1.1.0-3.fc8.x86_64 yap-debuginfo-5.1.1-5.fc8.x86_64 From nicolas.mailhot at laposte.net Mon Jul 16 19:01:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Jul 2007 21:01:32 +0200 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <200707162148.57545.ville.skytta@iki.fi> References: <200707162148.57545.ville.skytta@iki.fi> Message-ID: <1184612492.17096.2.camel@rousalka.dyndns.org> Le lundi 16 juillet 2007 ? 21:48 +0300, Ville Skytt? a ?crit : > Here are the results of debuginfocheck.py for current x86_64 Rawhide (run > without -j). BTW it would be nice if our debuginfo macro made debuginfo packages depend on the exact version of the package they've been created from. All too often debuginfo repositories are not in sync with the main repositories so users get debuginfo packages installed for the wrong version of the on-system packages. -- 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 notting at redhat.com Mon Jul 16 19:00:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 16 Jul 2007 15:00:42 -0400 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <1184612492.17096.2.camel@rousalka.dyndns.org> References: <200707162148.57545.ville.skytta@iki.fi> <1184612492.17096.2.camel@rousalka.dyndns.org> Message-ID: <20070716190042.GA29413@nostromo.devel.redhat.com> (redirecting to fedora-devel-list) Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > BTW it would be nice if our debuginfo macro made debuginfo packages > depend on the exact version of the package they've been created from. > > All too often debuginfo repositories are not in sync with the main > repositories so users get debuginfo packages installed for the wrong > version of the on-system packages. The problem with that is that someone who runs 'debuginfo-install', even once, is left with an un-upgradeable system, without manual intervention. Bill From nicolas.mailhot at laposte.net Mon Jul 16 19:12:43 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Jul 2007 21:12:43 +0200 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <20070716190042.GA29413@nostromo.devel.redhat.com> References: <200707162148.57545.ville.skytta@iki.fi> <1184612492.17096.2.camel@rousalka.dyndns.org> <20070716190042.GA29413@nostromo.devel.redhat.com> Message-ID: <1184613163.17096.7.camel@rousalka.dyndns.org> Le lundi 16 juillet 2007 ? 15:00 -0400, Bill Nottingham a ?crit : > (redirecting to fedora-devel-list) > > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > BTW it would be nice if our debuginfo macro made debuginfo packages > > depend on the exact version of the package they've been created from. > > > > All too often debuginfo repositories are not in sync with the main > > repositories so users get debuginfo packages installed for the wrong > > version of the on-system packages. > > The problem with that is that someone who runs 'debuginfo-install', even > once, is left with an un-upgradeable system, without manual intervention. well presumably someone who installed debuginfo packages wants them to be useful and not updated separately from the rest of the distro It's very annoying to install debuginfo packages with the aim to produce a nice stack for upstream, and find out when you actually manage to trigger the bug debuginfo packages are out of sync and yum happily updated the rest of the system without taking them into account -- 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 jjohnstn at redhat.com Mon Jul 16 19:56:46 2007 From: jjohnstn at redhat.com (Jeff Johnston) Date: Mon, 16 Jul 2007 15:56:46 -0400 Subject: Unable to login to bodhi In-Reply-To: <469B6345.4060601@redhat.com> References: <20070715130833.7cdcab0e@python3.es.egwn.lan> <469B6345.4060601@redhat.com> Message-ID: <469BCD7E.3090200@redhat.com> Bill Peck wrote: > Matthias Saou wrote: >> Hi, >> >> I currently can't log into bodhi at : >> https://admin.fedoraproject.org/updates/ >> >> I've tried the same login/pass for the voting interface, changing my >> account details, and it works fine. I've been mostly away for the last >> 2 weeks, so maybe I've missed some change, in which case I apologize... >> >> Matthias >> >> > > I can't log in either. I don't have any updates to push yet, but > figured I should get this straightened out now. I tried my cvs > account/password. Would be helpful to have a link on the bodhi login > page that tells you where to go to reset your password. > I can't login either. I have F7 eclipse-cdt updates to push. I have tried my Fedora name, Fedora name lower-case only, Fedora name with space between first and last name, my email name and my full email address. None work. FWIW, I can login successfully to change my Fedora preferences but I cannot log into bodhi. No such problems when pushing updates for FC-6. -- Jeff J. From jkeating at redhat.com Mon Jul 16 20:04:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 16 Jul 2007 16:04:13 -0400 Subject: Unable to login to bodhi In-Reply-To: <469BCD7E.3090200@redhat.com> References: <20070715130833.7cdcab0e@python3.es.egwn.lan> <469B6345.4060601@redhat.com> <469BCD7E.3090200@redhat.com> Message-ID: <20070716160413.7bcac3ce@localhost.localdomain> On Mon, 16 Jul 2007 15:56:46 -0400 Jeff Johnston wrote: > I can't login either. I have F7 eclipse-cdt updates to push. I have > tried my Fedora name, Fedora name lower-case only, Fedora name with > space between first and last name, my email name and my full email > address. None work. FWIW, I can login successfully to change my > Fedora preferences but I cannot log into bodhi. No such problems > when pushing updates for FC-6. 'change my preferences', are you referencing the wiki? Bodhi uses your FAS account, the one that is used at https://admin.fedoraproject.org/accounts -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jjohnstn at redhat.com Mon Jul 16 20:41:01 2007 From: jjohnstn at redhat.com (Jeff Johnston) Date: Mon, 16 Jul 2007 16:41:01 -0400 Subject: Unable to login to bodhi In-Reply-To: <20070716160413.7bcac3ce@localhost.localdomain> References: <20070715130833.7cdcab0e@python3.es.egwn.lan> <469B6345.4060601@redhat.com> <469BCD7E.3090200@redhat.com> <20070716160413.7bcac3ce@localhost.localdomain> Message-ID: <469BD7DD.2040206@redhat.com> Jesse Keating wrote: > On Mon, 16 Jul 2007 15:56:46 -0400 > Jeff Johnston wrote: > > >> I can't login either. I have F7 eclipse-cdt updates to push. I have >> tried my Fedora name, Fedora name lower-case only, Fedora name with >> space between first and last name, my email name and my full email >> address. None work. FWIW, I can login successfully to change my >> Fedora preferences but I cannot log into bodhi. No such problems >> when pushing updates for FC-6. >> > > 'change my preferences', are you referencing the wiki? Bodhi uses your > FAS account, the one that is used at > https://admin.fedoraproject.org/accounts > > Ok, my bad. I had also tried my bugzilla password with all the above. It would be nice if the login page had a link to the page you quoted. From it, I was able to request a new password and that got me in. Thanks, -- Jeff J. > ------------------------------------------------------------------------ > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From notting at redhat.com Mon Jul 16 20:42:41 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 16 Jul 2007 16:42:41 -0400 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <1184613163.17096.7.camel@rousalka.dyndns.org> References: <200707162148.57545.ville.skytta@iki.fi> <1184612492.17096.2.camel@rousalka.dyndns.org> <20070716190042.GA29413@nostromo.devel.redhat.com> <1184613163.17096.7.camel@rousalka.dyndns.org> Message-ID: <20070716204241.GB30896@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > The problem with that is that someone who runs 'debuginfo-install', even > > once, is left with an un-upgradeable system, without manual intervention. > > well presumably someone who installed debuginfo packages wants them to > be useful and not updated separately from the rest of the distro Sure, but debuginfo-install works *without* changing the repo definition. So your upgrade will fail, as the newer version of XYZ won't upgrade because the debuginfo repo isn't active. Bill From roland at redhat.com Mon Jul 16 20:53:48 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 16 Jul 2007 13:53:48 -0700 (PDT) Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: Bill Nottingham's message of Monday, 16 July 2007 16:42:41 -0400 <20070716204241.GB30896@nostromo.devel.redhat.com> Message-ID: <20070716205348.5138F4D05BE@magilla.localdomain> > Sure, but debuginfo-install works *without* changing the repo definition. > So your upgrade will fail, as the newer version of XYZ won't upgrade because > the debuginfo repo isn't active. It would be kewl if yum told you "unhappy rpm comes from no repo in use". I suppose you can't really tell now that if the sometimes the installed version of an updates rpm is no longer in the updates repo. The second suggestion is that yum et al store in some yum cache info somewhere which repo each install rpm came from. Then in various things it tells you about that rpm, it can mention which repo it came from and draw your attention to it being a disabled one if it is. Thanks, Roland From katzj at redhat.com Mon Jul 16 20:54:18 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 16 Jul 2007 16:54:18 -0400 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <20070716205348.5138F4D05BE@magilla.localdomain> References: <20070716205348.5138F4D05BE@magilla.localdomain> Message-ID: <1184619258.9154.70.camel@localhost.localdomain> On Mon, 2007-07-16 at 13:53 -0700, Roland McGrath wrote: > > Sure, but debuginfo-install works *without* changing the repo definition. > > So your upgrade will fail, as the newer version of XYZ won't upgrade because > > the debuginfo repo isn't active. > > It would be kewl if yum told you "unhappy rpm comes from no repo in use". > I suppose you can't really tell now that if the sometimes the installed > version of an updates rpm is no longer in the updates repo. The second > suggestion is that yum et al store in some yum cache info somewhere which > repo each install rpm came from. Then in various things it tells you about > that rpm, it can mention which repo it came from and draw your attention to > it being a disabled one if it is. And when someone installs using rpm by hand? Sorry, keeping a separate database of this sort of information with yum is the path to misery. Jeremy From roland at redhat.com Mon Jul 16 21:03:22 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 16 Jul 2007 14:03:22 -0700 (PDT) Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: Jeremy Katz's message of Monday, 16 July 2007 16:54:18 -0400 <1184619258.9154.70.camel@localhost.localdomain> Message-ID: <20070716210322.879FD4D05BE@magilla.localdomain> > And when someone installs using rpm by hand? Sorry, keeping a separate > database of this sort of information with yum is the path to misery. Ahem. Path? Where exactly is it you think we are now, sir? ;-) It's a strawman implementation idea, goodness knows I don't care about the details. But the user experience needs to improve. What's your plan? Thanks, Roland From nicolas.mailhot at laposte.net Mon Jul 16 21:06:27 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Jul 2007 23:06:27 +0200 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <20070716204241.GB30896@nostromo.devel.redhat.com> References: <200707162148.57545.ville.skytta@iki.fi> <1184612492.17096.2.camel@rousalka.dyndns.org> <20070716190042.GA29413@nostromo.devel.redhat.com> <1184613163.17096.7.camel@rousalka.dyndns.org> <20070716204241.GB30896@nostromo.devel.redhat.com> Message-ID: <1184619987.19754.3.camel@rousalka.dyndns.org> Le lundi 16 juillet 2007 ? 16:42 -0400, Bill Nottingham a ?crit : > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > > The problem with that is that someone who runs 'debuginfo-install', even > > > once, is left with an un-upgradeable system, without manual intervention. > > > > well presumably someone who installed debuginfo packages wants them to > > be useful and not updated separately from the rest of the distro > > Sure, but debuginfo-install works *without* changing the repo definition. > So your upgrade will fail, as the newer version of XYZ won't upgrade because > the debuginfo repo isn't active. The usual problem is not debuginfo is not active but it's mirrored several hours after the main repo so without version-lock debuginfo packages are not in sync with main packages even though it's active IMHO if you don't want debuginfo packages to block a debuginfo-uninstall utility should be provided, letting packages rot this way strikes me as a particularly bad compromise. (btw I don't see how debuginfo-install would have worked in the first place if the debug repo was not active) -- 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 skvidal at linux.duke.edu Mon Jul 16 21:15:31 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 16 Jul 2007 17:15:31 -0400 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <1184619987.19754.3.camel@rousalka.dyndns.org> References: <200707162148.57545.ville.skytta@iki.fi> <1184612492.17096.2.camel@rousalka.dyndns.org> <20070716190042.GA29413@nostromo.devel.redhat.com> <1184613163.17096.7.camel@rousalka.dyndns.org> <20070716204241.GB30896@nostromo.devel.redhat.com> <1184619987.19754.3.camel@rousalka.dyndns.org> Message-ID: <1184620531.606.15.camel@cutter> On Mon, 2007-07-16 at 23:06 +0200, Nicolas Mailhot wrote: > Le lundi 16 juillet 2007 ? 16:42 -0400, Bill Nottingham a ?crit : > > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > > > The problem with that is that someone who runs 'debuginfo-install', even > > > > once, is left with an un-upgradeable system, without manual intervention. > > > > > > well presumably someone who installed debuginfo packages wants them to > > > be useful and not updated separately from the rest of the distro > > > > Sure, but debuginfo-install works *without* changing the repo definition. > > So your upgrade will fail, as the newer version of XYZ won't upgrade because > > the debuginfo repo isn't active. > > The usual problem is not debuginfo is not active but it's mirrored > several hours after the main repo so without version-lock debuginfo > packages are not in sync with main packages even though it's active > > IMHO if you don't want debuginfo packages to block a debuginfo-uninstall > utility should be provided, letting packages rot this way strikes me as > a particularly bad compromise. > > (btw I don't see how debuginfo-install would have worked in the first > place if the debug repo was not active) debuginfo-install activates the debug repos as it goes. -sv From fedora at leemhuis.info Tue Jul 17 04:59:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 06:59:55 +0200 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <1184619258.9154.70.camel@localhost.localdomain> References: <20070716205348.5138F4D05BE@magilla.localdomain> <1184619258.9154.70.camel@localhost.localdomain> Message-ID: <469C4CCB.7050902@leemhuis.info> On 16.07.2007 22:54, Jeremy Katz wrote: > On Mon, 2007-07-16 at 13:53 -0700, Roland McGrath wrote: >>> Sure, but debuginfo-install works *without* changing the repo definition. >>> So your upgrade will fail, as the newer version of XYZ won't upgrade because >>> the debuginfo repo isn't active. >> It would be kewl if yum told you "unhappy rpm comes from no repo in use". +1 -- or better: for all conflicts/problems which lead yum to error out name the packages involved, where they come from (by key used for signing and/or %vendor, %distribution and %packager") and which are in the available in the currently enabled repos. > And when someone installs using rpm by hand? Sorry, keeping a separate > database of this sort of information with yum is the path to misery. Why is a separate database needed? Yum should have all the requires informations already ("package-cleanup --orphans" at least is able to show them and "yum list extras" as well IIRC) CU thl From fedora at leemhuis.info Tue Jul 17 05:05:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 07:05:00 +0200 Subject: resolution for python-imaging in EPEL In-Reply-To: <469B7528.3070800@redhat.com> References: <469B7528.3070800@redhat.com> Message-ID: <469C4DFC.2050408@leemhuis.info> On 16.07.2007 15:39, Joel Andres Granados wrote: > > reference : BZ#246444 > > I have 1 of 2 choices: > [...] > Comments greatly appreciated. The better place for this questions is epel-devel-list (CCed and reply to set), where this has been discussed already in the past days and likely will get discussed further. It's also a topic for tomorrows EPEL SIG meeting (20070718, #fedora-meeting, 17:00 UTC). Join us ;-) BTW, I'd currently prefer to take the python-imaging from RHEL, lower the EVR (by using a "0." at the start of Release), and ship it in EPEL, so users of EL5Server have it available as well, and users of EL5Client or CentOS will get their normal package. Not ideal, but KISS and should work if nobody does stupid things. CU knurd P.S.: /me wonders if mailman will eat the follow-up to epel-devel-list at redhat.com P.P.S.:/me bets it will From jgranado at redhat.com Tue Jul 17 08:53:01 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Jul 2007 10:53:01 +0200 Subject: resolution for python-imaging in EPEL In-Reply-To: <469C4DFC.2050408@leemhuis.info> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> Message-ID: <469C836D.9030203@redhat.com> Thorsten Leemhuis wrote: > On 16.07.2007 15:39, Joel Andres Granados wrote: > >> reference : BZ#246444 >> >> I have 1 of 2 choices: >> [...] >> Comments greatly appreciated. >> > > The better place for this questions is epel-devel-list (CCed and reply > to set), thx, Ill additionally subscribe to the list. ;) > where this has been discussed already in the past days and > likely will get discussed further. It's also a topic for tomorrows EPEL > SIG meeting (20070718, #fedora-meeting, 17:00 UTC). Join us ;-) > I most likely will join you. > BTW, I'd currently prefer to take the python-imaging from RHEL, lower > the EVR (by using a "0." at the start of Release), So if I understand you correctly you want to ship the 1.1.5 source with a 1.1.6-0.3 versioned rpm? IMHO, since this does not really break anything (1.1.6 being in RHEL5 Server) it would be much better to go with the policy of having source version and rpm version consistency than having the EPEL/el5 and RHEL5 consistency. I also consider this being a matter of opinion as both approaches would work in theory :) > and ship it in EPEL, > so users of EL5Server have it available as well, and users of EL5Client > or CentOS will get their normal package. Not ideal, but KISS and should > work if nobody does stupid things. > FWIW, I think that shipping the 1.1.6 version to EPEL/el5 is more KISS than modifying the release bit. > CU > knurd > > P.S.: /me wonders if mailman will eat the follow-up to > epel-devel-list at redhat.com > > P.P.S.:/me bets it will > I'll check this out and see if mailman did something funny. > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- Joel Andres Granados From martin.sourada at seznam.cz Tue Jul 17 09:19:52 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 17 Jul 2007 11:19:52 +0200 Subject: [New Feature Proposition]: Nodoka Theme Message-ID: <1184663992.21133.15.camel@pc-notebook> Hi, following advice from Rahul [1] I propose a new Feature for Fedora 8 - Nodoka Theme. The Nodoka theme is currently targeted on Gnome and contains metacity theme, gtk engine, gtk theme and gnome metatheme. It is supposed to work with echo-icon-theme therefore the metatheme package requires echo icons as well. I've submitted review requests for inclusion in rawhide [2][3] and created a feature wiki page [4]. If you'd like to test it, rpms for i386 (and older ones for x86_64) and noarch are available on the NodokaTheme wiki [5]. Also I'd like to ask for hosting the sources on fedorahosted. Could someone point me as to how/where can I ask for it? Comments, feedback, patches, etc. welcome. Thanks, Martin [1] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00120.html [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248163 [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248516 [4] http://fedoraproject.org/wiki/Releases/Features/NodokaTheme [5] http://fedoraproject.org/wiki/Artwork/NodokaTheme -------------- 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 martin.sourada at seznam.cz Tue Jul 17 12:56:11 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 17 Jul 2007 14:56:11 +0200 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <469CA198.8060401@gmail.com> References: <1184663992.21133.15.camel@pc-notebook> <469CA198.8060401@gmail.com> Message-ID: <1184676971.21133.20.camel@pc-notebook> On Tue, 2007-07-17 at 13:01 +0200, dragoran wrote: > is this a gtk2 only theme or does it work for gtk apps too? > > _______________________________________________ > Fedora-art-list mailing list > Fedora-art-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-art-list GTK2 and Metacity. GTK1 theme is neither included nor planned. There are still gtk1 apps out there? :-O AFAIK, the current default, Clearlooks, don't support it either... -------------- 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 mattdm at mattdm.org Tue Jul 17 14:30:22 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 17 Jul 2007 10:30:22 -0400 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <1184663992.21133.15.camel@pc-notebook> References: <1184663992.21133.15.camel@pc-notebook> Message-ID: <20070717143022.GA16499@jadzia.bu.edu> On Tue, Jul 17, 2007 at 11:19:52AM +0200, Martin Sourada wrote: > Comments, feedback, patches, etc. welcome. I'd really love to see a grey version of the theme (a la Mac OS X). Bright color elements are distracting to me. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From buildsys at fedoraproject.org Tue Jul 17 20:41:59 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 17 Jul 2007 16:41:59 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-07-17 Message-ID: <20070717204159.17CF1152131@buildsys.fedoraproject.org> aportal AT univ-montp2.fr: fcron FE6 > F7 (0:3.0.3-1.fc6 > 0:3.0.2-2.fc7) kbackup FE6 > F7 (0:0.5.1-7.fc6 > 0:0.5.1-2.fc6) pikloops FE6 > F7 (0:0.2.2-5.fc6 > 0:0.2.1-6.fc6) 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) ed AT eh3.com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico.scholz AT informatik.tu-chemnitz.de: fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) 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) jakub AT redhat.com: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jeff AT ocjtech.us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) sofia-sip FE6 > F7-updates (0:1.12.6-8.fc6 > 0:1.12.6-6.fc7) jjohnstn AT redhat.com: eclipse-cdt FC6-updates > F7 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) 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) 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-4.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) 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) pawsa AT theochem.kth.se: balsa FE5 > F7 (0:2.3.16-3.fc5 > 0:2.3.14-1.fc7) FE6 > F7 (0:2.3.17-1.fc6 > 0:2.3.14-1.fc7) pmachata AT redhat.com: tzdata FC5-updates > F7 (0:2007f-1.fc5 > 0:2007e-1.fc7) FC6-updates > F7 (0:2007f-1.fc6 > 0:2007e-1.fc7) rc040203 AT freenet.de: perl-DBIx-DBSchema FE6 > F7 (0:0.33-1.fc6 > 0:0.32-1.fc7) perl-File-Remove FE6 > F7 (0:0.37-1.fc6 > 0:0.34-1.fc7) 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: kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) rmeggins AT redhat.com: mozldap FE5 > F7 (0:6.0.4-1.fc5 > 0:6.0.3-1.fc7) FE6 > F7 (0:6.0.4-1.fc6 > 0:6.0.3-1.fc7) perl-Mozilla-LDAP FE5 > F7 (0:1.5.1-1.fc5 > 0:1.5-9.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.5-9.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: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) tcallawa AT redhat.com: perl-version FE6 > F7 (1:0.7203-1.fc6 > 1:0.69-1.fc7) than AT redhat.com: kdemultimedia FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) ---------------------------------------------------------------------- balsa: pawsa AT theochem.kth.se FE5 > F7 (0:2.3.16-3.fc5 > 0:2.3.14-1.fc7) FE6 > F7 (0:2.3.17-1.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) eclipse-cdt: jjohnstn AT redhat.com FC6-updates > F7 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) fcron: aportal AT univ-montp2.fr FE6 > F7 (0:3.0.3-1.fc6 > 0:3.0.2-2.fc7) fedora-usermgmt: enrico.scholz AT informatik.tu-chemnitz.de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.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-4.fc6 > 0:2.1.1-2.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) gcc: jakub AT redhat.com FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) gtranslator: foolish AT guezz.net FE6 > F7 (0:1.1.7-3.fc6 > 0:1.1.7-2.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) jrtplib: jeff AT ocjtech.us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kbackup: aportal AT univ-montp2.fr FE6 > F7 (0:0.5.1-7.fc6 > 0:0.5.1-2.fc6) kdeartwork-extras: rdieter AT math.unl.edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdemultimedia: than AT redhat.com FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.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) lostirc: splinux AT fedoraproject.org FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) maxima: rdieter AT math.unl.edu FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) 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) mozldap: rmeggins AT redhat.com FE5 > F7 (0:6.0.4-1.fc5 > 0:6.0.3-1.fc7) FE6 > F7 (0:6.0.4-1.fc6 > 0:6.0.3-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-DBIx-DBSchema: rc040203 AT freenet.de FE6 > F7 (0:0.33-1.fc6 > 0:0.32-1.fc7) perl-Event: cweyl AT alumni.drew.edu FE6 > F7 (0:1.09-1.fc6 > 0:1.08-1.fc7) perl-File-Remove: rc040203 AT freenet.de FE6 > F7 (0:0.37-1.fc6 > 0:0.34-1.fc7) 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-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-Mozilla-LDAP: rmeggins AT redhat.com FE5 > F7 (0:1.5.1-1.fc5 > 0:1.5-9.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.5-9.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-version: tcallawa AT redhat.com FE6 > F7 (1:0.7203-1.fc6 > 1:0.69-1.fc7) pikloops: aportal AT univ-montp2.fr FE6 > F7 (0:0.2.2-5.fc6 > 0:0.2.1-6.fc6) python-cheetah: mikeb AT redhat.com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.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) scrip: ed AT eh3.com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) sofia-sip: jeff AT ocjtech.us FE6 > F7-updates (0:1.12.6-8.fc6 > 0:1.12.6-6.fc7) tzdata: pmachata AT redhat.com FC5-updates > F7 (0:2007f-1.fc5 > 0:2007e-1.fc7) FC6-updates > F7 (0:2007f-1.fc6 > 0:2007e-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) 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 aportal at univ-montp2.fr Wed Jul 18 07:33:36 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Wed, 18 Jul 2007 09:33:36 +0200 Subject: Package EVR problems in Fedora 2007-07-17 In-Reply-To: <20070717204159.17CF1152131@buildsys.fedoraproject.org> References: <20070717204159.17CF1152131@buildsys.fedoraproject.org> Message-ID: <200707180933.36383.aportal@univ-montp2.fr> Hi, I don't understand this report, there is no package EVR problems in the following packages: Le Tuesday 17 July 2007 22:41:59 buildsys at fedoraproject.org, vous avez ?crit?: > aportal AT univ-montp2.fr: > fcron > FE6 > F7 (0:3.0.3-1.fc6 > 0:3.0.2-2.fc7) F7 is 3.0.3-1.fc7 and not 3.0.2-2.fc7, see http://koji.fedoraproject.org/koji/buildinfo?buildID=10517 > kbackup > FE6 > F7 (0:0.5.1-7.fc6 > 0:0.5.1-2.fc6) F7 is 0.5.1-7.fc7 and not 0.5.1-2.fc6, see http://koji.fedoraproject.org/koji/buildinfo?buildID=11004 > pikloops > FE6 > F7 (0:0.2.2-5.fc6 > 0:0.2.1-6.fc6) F7 is 0.2.2-5.fc7 and not 0.2.1-6.fc6, see http://koji.fedoraproject.org/koji/buildinfo?buildID=11017 Where is the problem? Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr -------------- 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 wolfy at nobugconsulting.ro Wed Jul 18 08:18:36 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 18 Jul 2007 11:18:36 +0300 Subject: Package EVR problems in Fedora 2007-07-17 In-Reply-To: <200707180933.36383.aportal@univ-montp2.fr> References: <20070717204159.17CF1152131@buildsys.fedoraproject.org> <200707180933.36383.aportal@univ-montp2.fr> Message-ID: <469DCCDC.4050903@nobugconsulting.ro> Alain PORTAL wrote: > Hi, > > I don't understand this report, there is no package EVR problems in the > following packages: > > Le Tuesday 17 July 2007 22:41:59 buildsys at fedoraproject.org, vous avez ?crit : > >> aportal AT univ-montp2.fr: >> fcron >> FE6 > F7 (0:3.0.3-1.fc6 > 0:3.0.2-2.fc7) >> > > F7 is 3.0.3-1.fc7 and not 3.0.2-2.fc7, see > http://koji.fedoraproject.org/koji/buildinfo?buildID=10517 > > >> kbackup >> FE6 > F7 (0:0.5.1-7.fc6 > 0:0.5.1-2.fc6) >> > > F7 is 0.5.1-7.fc7 and not 0.5.1-2.fc6, see > http://koji.fedoraproject.org/koji/buildinfo?buildID=11004 > > >> pikloops >> FE6 > F7 (0:0.2.2-5.fc6 > 0:0.2.1-6.fc6) >> > > F7 is 0.2.2-5.fc7 and not 0.2.1-6.fc6, see > http://koji.fedoraproject.org/koji/buildinfo?buildID=11017 > > Where is the problem? > did you push those packages via bodhi ? I cannot find any of them in https://admin.fedoraproject.org/updates. But my bodhi-fu skills need lots of improvement, so I might be in error From aportal at univ-montp2.fr Wed Jul 18 08:34:34 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Wed, 18 Jul 2007 10:34:34 +0200 Subject: Package EVR problems in Fedora 2007-07-17 In-Reply-To: <469DCCDC.4050903@nobugconsulting.ro> References: <20070717204159.17CF1152131@buildsys.fedoraproject.org> <200707180933.36383.aportal@univ-montp2.fr> <469DCCDC.4050903@nobugconsulting.ro> Message-ID: <200707181034.34975.aportal@univ-montp2.fr> Le Wednesday 18 July 2007 10:18:36 Manuel Wolfshant, vous avez ?crit?: > > Where is the problem? > > did you push those packages via bodhi ? I cannot find any of them in > https://admin.fedoraproject.org/updates. But my bodhi-fu skills need > lots of improvement, so I might be in error No, I didn't. I didn't know this procedure :-( , sorry ... Now it's done. Thanks, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr -------------- 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 skvidal at fedoraproject.org Wed Jul 18 15:30:31 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 18 Jul 2007 11:30:31 -0400 Subject: fedorapeople.org is now available Message-ID: <1184772631.606.150.camel@cutter> Hi Everyone, fedorapeople.org is now available for general use. What is fedorapeople.org?: It is a site where fedora contributors can upload files for sharing out with the world. It is perfect for uploading specfiles, srpms, patches, etc, etc. Each fedora contributor has 150M of quota-controlled space. Users can upload using scp, sftp or rsync. Once uploaded into the users public_html directory the files are available via http at: http://your_username.fedorapeople.org/. To connect to fedorapeople.org just use the ssh key you uploaded to your fedora account and then you can login via ssh to: fedorapeople.org What fedorapeople.org is NOT: - it is not a place for you to upload confidential or copyright-violating files. - it is not a shell for you to login and stay logged into - it is not a place for you to run your favorite proxy of whatever kind - it is not a database server - it is not a mail server - it is not a run-my-favorite-cgi-server - it is not a blog server We've tried our best to minimize and secure the services. Don't make a lot of unreasonable requests asking for us to undo that. :) For reasonable requests please file put them in the fedora infrastructure ticketing system: http://fedoraproject.org/wiki/Infrastructure/Tickets Let us know what breaks, -sv From dwalsh at redhat.com Wed Jul 18 15:41:58 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 18 Jul 2007 11:41:58 -0400 Subject: fedorapeople.org is now available In-Reply-To: <1184772631.606.150.camel@cutter> References: <1184772631.606.150.camel@cutter> Message-ID: <469E34C6.5010107@redhat.com> seth vidal wrote: > Hi Everyone, > fedorapeople.org is now available for general use. > > What is fedorapeople.org?: > It is a site where fedora contributors can upload files for sharing > out with the world. It is perfect for uploading specfiles, srpms, > patches, etc, etc. Each fedora contributor has 150M of quota-controlled > space. Users can upload using scp, sftp or rsync. Once uploaded into the > users public_html directory the files are available via http at: > http://your_username.fedorapeople.org/. To connect to fedorapeople.org > just use the ssh key you uploaded to your fedora account and then you > can login via ssh to: fedorapeople.org > > > What fedorapeople.org is NOT: > - it is not a place for you to upload confidential or > copyright-violating files. > - it is not a shell for you to login and stay logged into > - it is not a place for you to run your favorite proxy of whatever kind > - it is not a database server > - it is not a mail server > - it is not a run-my-favorite-cgi-server > - it is not a blog server > > We've tried our best to minimize and secure the services. Don't make a > lot of unreasonable requests asking for us to undo that. :) > > For reasonable requests please file put them in the fedora > infrastructure ticketing system: > http://fedoraproject.org/wiki/Infrastructure/Tickets > > > Let us know what breaks, > -sv > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Seth did you get a chance to play with SELinux controlled users on this machine? What Fedora Version is it running? From rcritten at redhat.com Wed Jul 18 15:46:17 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Jul 2007 11:46:17 -0400 Subject: fedorapeople.org is now available In-Reply-To: <469E34C6.5010107@redhat.com> References: <1184772631.606.150.camel@cutter> <469E34C6.5010107@redhat.com> Message-ID: <469E35C9.4040301@redhat.com> Daniel J Walsh wrote: > seth vidal wrote: >> Hi Everyone, >> fedorapeople.org is now available for general use. >> >> What is fedorapeople.org?: >> It is a site where fedora contributors can upload files for sharing >> out with the world. It is perfect for uploading specfiles, srpms, >> patches, etc, etc. Each fedora contributor has 150M of quota-controlled >> space. Users can upload using scp, sftp or rsync. Once uploaded into the >> users public_html directory the files are available via http at: >> http://your_username.fedorapeople.org/. To connect to fedorapeople.org >> just use the ssh key you uploaded to your fedora account and then you >> can login via ssh to: fedorapeople.org >> >> >> What fedorapeople.org is NOT: >> - it is not a place for you to upload confidential or >> copyright-violating files. >> - it is not a shell for you to login and stay logged into >> - it is not a place for you to run your favorite proxy of whatever kind >> - it is not a database server >> - it is not a mail server >> - it is not a run-my-favorite-cgi-server >> - it is not a blog server >> >> We've tried our best to minimize and secure the services. Don't make a >> lot of unreasonable requests asking for us to undo that. :) >> For reasonable requests please file put them in the fedora >> infrastructure ticketing system: >> http://fedoraproject.org/wiki/Infrastructure/Tickets >> >> Let us know what breaks, >> -sv >> >> >> -- >> Fedora-maintainers mailing list >> Fedora-maintainers at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-maintainers >> > Seth did you get a chance to play with SELinux controlled users on this > machine? [rcritten at people1 ~]$ /usr/sbin/selinuxenabled [rcritten at people1 ~]$ echo $? 1 I guess not. > > What Fedora Version is it running? [rcritten at people1 ~]$ cat /etc/redhat-release CentOS release 5 (Final) [rcritten at people1 ~]$ uname -a Linux people1.fedoraproject.org 2.6.18-8.1.8.el5xen #1 SMP Tue Jul 10 07:06:45 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From skvidal at linux.duke.edu Wed Jul 18 15:44:10 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 18 Jul 2007 11:44:10 -0400 Subject: fedorapeople.org is now available In-Reply-To: <469E34C6.5010107@redhat.com> References: <1184772631.606.150.camel@cutter> <469E34C6.5010107@redhat.com> Message-ID: <1184773450.606.153.camel@cutter> On Wed, 2007-07-18 at 11:41 -0400, Daniel J Walsh wrote: > Seth did you get a chance to play with SELinux controlled users on this > machine? I enabled the poly-instantiated tmpdirs but I did not enable > What Fedora Version is it running? centos 5 - it's a server we expect to have up for a while and don't want to upgrade it every year. we don't have access to rhel from the outside for installs so I used centos. -sv From dwalsh at redhat.com Wed Jul 18 15:56:53 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 18 Jul 2007 11:56:53 -0400 Subject: fedorapeople.org is now available In-Reply-To: <1184773450.606.153.camel@cutter> References: <1184772631.606.150.camel@cutter> <469E34C6.5010107@redhat.com> <1184773450.606.153.camel@cutter> Message-ID: <469E3845.1000807@redhat.com> seth vidal wrote: > On Wed, 2007-07-18 at 11:41 -0400, Daniel J Walsh wrote: > >> Seth did you get a chance to play with SELinux controlled users on this >> machine? >> > > I enabled the poly-instantiated tmpdirs but I did not enable > > > >> What Fedora Version is it running? >> > > centos 5 - it's a server we expect to have up for a while and don't want > to upgrade it every year. > > we don't have access to rhel from the outside for installs so I used > centos. > > -sv > > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Seems a little strange to have fedorapeople on a non-fedora OS :^( Would have been a good showcase of the power of SELinux. From skvidal at linux.duke.edu Wed Jul 18 15:55:05 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 18 Jul 2007 11:55:05 -0400 Subject: fedorapeople.org is now available In-Reply-To: <469E3845.1000807@redhat.com> References: <1184772631.606.150.camel@cutter> <469E34C6.5010107@redhat.com> <1184773450.606.153.camel@cutter> <469E3845.1000807@redhat.com> Message-ID: <1184774105.606.158.camel@cutter> On Wed, 2007-07-18 at 11:56 -0400, Daniel J Walsh wrote: > seth vidal wrote: > > On Wed, 2007-07-18 at 11:41 -0400, Daniel J Walsh wrote: > > > >> Seth did you get a chance to play with SELinux controlled users on this > >> machine? > >> > > > > I enabled the poly-instantiated tmpdirs but I did not enable > > > > > > > >> What Fedora Version is it running? > >> > > > > centos 5 - it's a server we expect to have up for a while and don't want > > to upgrade it every year. > > > > we don't have access to rhel from the outside for installs so I used > > centos. > > > > -sv > > > > > > > > -- > > Fedora-maintainers mailing list > > Fedora-maintainers at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-maintainers > > > Seems a little strange to have fedorapeople on a non-fedora OS :^( > Would have been a good showcase of the power of SELinux. a lot of fedora infrastructure runs on rhel. It just means that the sysadmins maintaining the machines don't have to jump through hoops every year to update them all. Especially when the box doesn't have any special requirements. -sv From buc at odusz.so-cdu.ru Wed Jul 18 16:05:42 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 18 Jul 2007 20:05:42 +0400 Subject: fedorapeople.org is now available In-Reply-To: <1184773450.606.153.camel@cutter> References: <1184772631.606.150.camel@cutter> <469E34C6.5010107@redhat.com> <1184773450.606.153.camel@cutter> Message-ID: <469E3A56.9040106@odu.neva.ru> seth vidal wrote: >> What Fedora Version is it running? >> > > centos 5 - it's a server we expect to have up for a while and don't want > to upgrade it every year. > IMHO, questionable ideology. People can say: "You promote Fedora for us, but you yourself do not use it". I use Fedora in strong production environment for years (including every year upgrade), and I am confused why you do not use it as well... Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From mmcgrath at redhat.com Wed Jul 18 16:09:04 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 18 Jul 2007 11:09:04 -0500 Subject: fedorapeople.org is now available In-Reply-To: <469E3A56.9040106@odu.neva.ru> References: <1184772631.606.150.camel@cutter> <469E34C6.5010107@redhat.com> <1184773450.606.153.camel@cutter> <469E3A56.9040106@odu.neva.ru> Message-ID: <469E3B20.2050007@redhat.com> Dmitry Butskoy wrote: > > IMHO, questionable ideology. > > People can say: "You promote Fedora for us, but you yourself do not > use it". > > I use Fedora in strong production environment for years (including > every year upgrade), and I am confused why you do not use it as well... All, this has been discussed over and over on the Infrastructure list. Please read the archives before you comment. We use both Fedora and RHEL in the environment, its all about the right tool for the job. The above quote might as well say. "You promote hammers, but you yourself use screwdrivers" /me seems to have to explain this to developers a lot. -Mike From jkeating at redhat.com Wed Jul 18 16:08:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 18 Jul 2007 12:08:50 -0400 Subject: fedorapeople.org is now available In-Reply-To: <1184774105.606.158.camel@cutter> References: <1184772631.606.150.camel@cutter> <469E34C6.5010107@redhat.com> <1184773450.606.153.camel@cutter> <469E3845.1000807@redhat.com> <1184774105.606.158.camel@cutter> Message-ID: <20070718120850.0f98d135@ender> On Wed, 18 Jul 2007 11:55:05 -0400 seth vidal wrote: > a lot of fedora infrastructure runs on rhel. It just means that the > sysadmins maintaining the machines don't have to jump through hoops > every year to update them all. Especially when the box doesn't have > any special requirements. And in a lot of reality, RHEL (and it's clones) are the "Fedora with long term support", which would be silly of Fedora to do on their own. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From limb at jcomserv.net Wed Jul 18 15:57:28 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 18 Jul 2007 10:57:28 -0500 (CDT) Subject: fedorapeople.org is now available In-Reply-To: <469E3A56.9040106@odu.neva.ru> References: <1184772631.606.150.camel@cutter> <469E34C6.5010107@redhat.com> <1184773450.606.153.camel@cutter> <469E3A56.9040106@odu.neva.ru> Message-ID: <57136.65.192.24.164.1184774248.squirrel@mail.jcomserv.net> > seth vidal wrote: >>> What Fedora Version is it running? >>> >> >> centos 5 - it's a server we expect to have up for a while and don't want >> to upgrade it every year. >> > > IMHO, questionable ideology. > > People can say: "You promote Fedora for us, but you yourself do not use > it". > > I use Fedora in strong production environment for years (including every > year upgrade), and I am confused why you do not use it as well... > As do I. > Dmitry Butskoy > http://www.fedoraproject.org/wiki/DmitryButskoy > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From jwboyer at jdub.homelinux.org Wed Jul 18 16:14:22 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 18 Jul 2007 11:14:22 -0500 Subject: fedorapeople.org is now available In-Reply-To: <469E3A56.9040106@odu.neva.ru> References: <1184772631.606.150.camel@cutter> <469E34C6.5010107@redhat.com> <1184773450.606.153.camel@cutter> <469E3A56.9040106@odu.neva.ru> Message-ID: <1184775262.16299.18.camel@weaponx.rchland.ibm.com> On Wed, 2007-07-18 at 20:05 +0400, Dmitry Butskoy wrote: > seth vidal wrote: > >> What Fedora Version is it running? > >> > > > > centos 5 - it's a server we expect to have up for a while and don't want > > to upgrade it every year. > > > > IMHO, questionable ideology. > > People can say: "You promote Fedora for us, but you yourself do not use it". > > I use Fedora in strong production environment for years (including every > year upgrade), and I am confused why you do not use it as well... Dear people, You just got a free hosting service, without having asked for it. It uses free software on the server to do it. Please stop whining. kthxbye. josh From limb at jcomserv.net Wed Jul 18 16:05:13 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 18 Jul 2007 11:05:13 -0500 (CDT) Subject: fedorapeople.org is now available In-Reply-To: <1184775262.16299.18.camel@weaponx.rchland.ibm.com> References: <1184772631.606.150.camel@cutter> <469E34C6.5010107@redhat.com> <1184773450.606.153.camel@cutter> <469E3A56.9040106@odu.neva.ru> <1184775262.16299.18.camel@weaponx.rchland.ibm.com> Message-ID: <1550.65.192.24.164.1184774713.squirrel@mail.jcomserv.net> > On Wed, 2007-07-18 at 20:05 +0400, Dmitry Butskoy wrote: >> seth vidal wrote: >> >> What Fedora Version is it running? >> >> >> > >> > centos 5 - it's a server we expect to have up for a while and don't >> want >> > to upgrade it every year. >> > >> >> IMHO, questionable ideology. >> >> People can say: "You promote Fedora for us, but you yourself do not use >> it". >> >> I use Fedora in strong production environment for years (including every >> year upgrade), and I am confused why you do not use it as well... > > Dear people, > > You just got a free hosting service, without having asked for it. It > uses free software on the server to do it. Please stop whining. > > kthxbye. +5 :) > josh > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From bpepple at fedoraproject.org Wed Jul 18 16:20:56 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 18 Jul 2007 12:20:56 -0400 Subject: fedorapeople.org is now available In-Reply-To: <1184772631.606.150.camel@cutter> References: <1184772631.606.150.camel@cutter> Message-ID: <1184775656.2790.4.camel@kennedy> On Wed, 2007-07-18 at 11:30 -0400, seth vidal wrote: > fedorapeople.org is now available for general use. Cool. Thanks, seth & the rest of the infrastructure team! /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 denis at poolshark.org Wed Jul 18 16:40:03 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 18 Jul 2007 18:40:03 +0200 Subject: fedorapeople.org is now available In-Reply-To: <1184772631.606.150.camel@cutter> References: <1184772631.606.150.camel@cutter> Message-ID: <469E4263.2030601@poolshark.org> seth vidal wrote: > Hi Everyone, > fedorapeople.org is now available for general use. > > What is fedorapeople.org?: > It is a site where fedora contributors can upload files for sharing > out with the world. It is perfect for uploading specfiles, srpms, > patches, etc, etc. Each fedora contributor has 150M of quota-controlled > space. Users can upload using scp, sftp or rsync. Once uploaded into the > users public_html directory the files are available via http at: > http://your_username.fedorapeople.org/. To connect to fedorapeople.org > just use the ssh key you uploaded to your fedora account and then you > can login via ssh to: fedorapeople.org This is awesome. Thanks! From skvidal at fedoraproject.org Wed Jul 18 16:15:26 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 18 Jul 2007 18:15:26 +0200 Subject: fedorapeople.org is now available Message-ID: <000b01c7c956$d9c204d0$ba00000a@grecom.local> Hi Everyone, fedorapeople.org is now available for general use. What is fedorapeople.org?: It is a site where fedora contributors can upload files for sharing out with the world. It is perfect for uploading specfiles, srpms, patches, etc, etc. Each fedora contributor has 150M of quota-controlled space. Users can upload using scp, sftp or rsync. Once uploaded into the users public_html directory the files are available via http at: http://your_username.fedorapeople.org/. To connect to fedorapeople.org just use the ssh key you uploaded to your fedora account and then you can login via ssh to: fedorapeople.org What fedorapeople.org is NOT: - it is not a place for you to upload confidential or copyright-violating files. - it is not a shell for you to login and stay logged into - it is not a place for you to run your favorite proxy of whatever kind - it is not a database server - it is not a mail server - it is not a run-my-favorite-cgi-server - it is not a blog server We've tried our best to minimize and secure the services. Don't make a lot of unreasonable requests asking for us to undo that. :) For reasonable requests please file put them in the fedora infrastructure ticketing system: http://fedoraproject.org/wiki/Infrastructure/Tickets Let us know what breaks, -sv -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From skvidal at fedoraproject.org Wed Jul 18 16:15:26 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 18 Jul 2007 18:15:26 +0200 Subject: fedorapeople.org is now available Message-ID: <001201c7c956$d9cdebb0$ba00000a@grecom.local> Hi Everyone, fedorapeople.org is now available for general use. What is fedorapeople.org?: It is a site where fedora contributors can upload files for sharing out with the world. It is perfect for uploading specfiles, srpms, patches, etc, etc. Each fedora contributor has 150M of quota-controlled space. Users can upload using scp, sftp or rsync. Once uploaded into the users public_html directory the files are available via http at: http://your_username.fedorapeople.org/. To connect to fedorapeople.org just use the ssh key you uploaded to your fedora account and then you can login via ssh to: fedorapeople.org What fedorapeople.org is NOT: - it is not a place for you to upload confidential or copyright-violating files. - it is not a shell for you to login and stay logged into - it is not a place for you to run your favorite proxy of whatever kind - it is not a database server - it is not a mail server - it is not a run-my-favorite-cgi-server - it is not a blog server We've tried our best to minimize and secure the services. Don't make a lot of unreasonable requests asking for us to undo that. :) For reasonable requests please file put them in the fedora infrastructure ticketing system: http://fedoraproject.org/wiki/Infrastructure/Tickets Let us know what breaks, -sv -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From kushaldas at gmail.com Wed Jul 18 18:01:16 2007 From: kushaldas at gmail.com (Kushal Das) Date: Wed, 18 Jul 2007 23:31:16 +0530 Subject: fedorapeople.org is now available In-Reply-To: <001201c7c956$d9cdebb0$ba00000a@grecom.local> References: <001201c7c956$d9cdebb0$ba00000a@grecom.local> Message-ID: <200707182331.16312.kushaldas@gmail.com> On Wednesday 18 July 2007 09:45:26 pm seth vidal wrote: > Hi Everyone, > fedorapeople.org is now available for general use. > > What is fedorapeople.org?: > It is a site where fedora contributors can upload files for sharing > out with the world. It is perfect for uploading specfiles, srpms, > patches, etc, etc. Each fedora contributor has 150M of quota-controlled > space. Users can upload using scp, sftp or rsync. Once uploaded into the > users public_html directory the files are available via http at: > http://your_username.fedorapeople.org/. To connect to fedorapeople.org > just use the ssh key you uploaded to your fedora account and then you > can login via ssh to: fedorapeople.org > > > What fedorapeople.org is NOT: > - it is not a place for you to upload confidential or > copyright-violating files. > - it is not a shell for you to login and stay logged into > - it is not a place for you to run your favorite proxy of whatever kind > - it is not a database server > - it is not a mail server > - it is not a run-my-favorite-cgi-server > - it is not a blog server > > We've tried our best to minimize and secure the services. Don't make a > lot of unreasonable requests asking for us to undo that. :) Great work !! Thanks :) Kushal -- Fedora Ambassador, India http://kushaldas.in From fnasser at redhat.com Wed Jul 18 18:09:20 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 18 Jul 2007 14:09:20 -0400 Subject: fedorapeople.org is now available In-Reply-To: <001201c7c956$d9cdebb0$ba00000a@grecom.local> References: <001201c7c956$d9cdebb0$ba00000a@grecom.local> Message-ID: <469E5750.2080707@redhat.com> Hi, How does one get his directory set up? Thanks. Fernando seth vidal wrote: > Hi Everyone, > fedorapeople.org is now available for general use. > > What is fedorapeople.org?: > It is a site where fedora contributors can upload files for sharing > out with the world. It is perfect for uploading specfiles, srpms, > patches, etc, etc. Each fedora contributor has 150M of quota-controlled > space. Users can upload using scp, sftp or rsync. Once uploaded into the > users public_html directory the files are available via http at: > http://your_username.fedorapeople.org/. To connect to fedorapeople.org > just use the ssh key you uploaded to your fedora account and then you > can login via ssh to: fedorapeople.org > > > What fedorapeople.org is NOT: > - it is not a place for you to upload confidential or > copyright-violating files. > - it is not a shell for you to login and stay logged into > - it is not a place for you to run your favorite proxy of whatever kind > - it is not a database server > - it is not a mail server > - it is not a run-my-favorite-cgi-server > - it is not a blog server > > We've tried our best to minimize and secure the services. Don't make a > lot of unreasonable requests asking for us to undo that. :) > > For reasonable requests please file put them in the fedora > infrastructure ticketing system: > http://fedoraproject.org/wiki/Infrastructure/Tickets > > > Let us know what breaks, > -sv > > From skvidal at linux.duke.edu Wed Jul 18 18:06:47 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 18 Jul 2007 14:06:47 -0400 Subject: fedorapeople.org is now available In-Reply-To: <469E5750.2080707@redhat.com> References: <001201c7c956$d9cdebb0$ba00000a@grecom.local> <469E5750.2080707@redhat.com> Message-ID: <1184782007.606.172.camel@cutter> On Wed, 2007-07-18 at 14:09 -0400, Fernando Nasser wrote: > Hi, > > How does one get his directory set up? > If you are a fedora contributor[1] then you just need to login using your fedora account and ssh key and you can run: mkdir public_html -sv [1]. A fedora contributor is someone who is a member of the cla_done group in the accounts system and is a member of any one other group other than those starting with cla_ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jul 18 18:51:07 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 18 Jul 2007 20:51:07 +0200 Subject: fedorapeople.org is now available In-Reply-To: <001201c7c956$d9cdebb0$ba00000a@grecom.local> References: <001201c7c956$d9cdebb0$ba00000a@grecom.local> Message-ID: <20070718205107.72c1e42c@python3.es.egwn.lan> seth vidal wrote : > Hi Everyone, > fedorapeople.org is now available for general use. Neat. Big thanks to the infra team! :-) Right now, http://fedorapeople.org/ is so much fun! I've never seen so many "test pages" on the same server ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3255.fc7 Load : 0.11 0.14 0.14 From debarshi.ray at gmail.com Wed Jul 18 19:39:24 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 19 Jul 2007 01:09:24 +0530 Subject: fedorapeople.org is now available In-Reply-To: <1184772631.606.150.camel@cutter> References: <1184772631.606.150.camel@cutter> Message-ID: <3170f42f0707181239if77e191ife9b765f0bb32331@mail.gmail.com> > fedorapeople.org is now available for general use. > > What is fedorapeople.org?: > It is a site where fedora contributors can upload files for sharing > out with the world. It is perfect for uploading specfiles, srpms, > patches, etc, etc. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Thanks a lot. I was looking for such a thing for a long time. One question though: Is it allowed to run some SCM, say Git, to host a project? I know hosted.fedoraproject..org is there for such purposes, but can someone host it here if she is refused space on hosted.fedoraproject..org ? Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From skvidal at linux.duke.edu Wed Jul 18 19:37:33 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 18 Jul 2007 15:37:33 -0400 Subject: fedorapeople.org is now available In-Reply-To: <3170f42f0707181239if77e191ife9b765f0bb32331@mail.gmail.com> References: <1184772631.606.150.camel@cutter> <3170f42f0707181239if77e191ife9b765f0bb32331@mail.gmail.com> Message-ID: <1184787453.606.183.camel@cutter> On Thu, 2007-07-19 at 01:09 +0530, Debarshi 'Rishi' Ray wrote: > > fedorapeople.org is now available for general use. > > > > What is fedorapeople.org?: > > It is a site where fedora contributors can upload files for sharing > > out with the world. It is perfect for uploading specfiles, srpms, > > patches, etc, etc. > > > > -- > > Fedora-maintainers mailing list > > Fedora-maintainers at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-maintainers > > > > Thanks a lot. I was looking for such a thing for a long time. > > One question though: Is it allowed to run some SCM, say Git, to host a > project? I know hosted.fedoraproject..org is there for such purposes, > but can someone host it here if she is refused space on > hosted.fedoraproject..org ? there is no support for SCMs locally at this time. however, git only needs an http server to be hosted so there is nothing stopping you from putting a repository up. -sv From jkeating at redhat.com Wed Jul 18 19:55:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 18 Jul 2007 15:55:33 -0400 Subject: fedorapeople.org is now available In-Reply-To: <1184787453.606.183.camel@cutter> References: <1184772631.606.150.camel@cutter> <3170f42f0707181239if77e191ife9b765f0bb32331@mail.gmail.com> <1184787453.606.183.camel@cutter> Message-ID: <20070718155533.25e043d4@localhost.localdomain> On Wed, 18 Jul 2007 15:37:33 -0400 seth vidal wrote: > however, git only needs an http server to be hosted so there is > nothing stopping you from putting a repository up. Same for hg with relatively recent hg clients. The http-static clone method should just work. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Wed Jul 18 20:26:38 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 18 Jul 2007 12:26:38 -0800 Subject: fedorapeople.org is now available In-Reply-To: <3170f42f0707181239if77e191ife9b765f0bb32331@mail.gmail.com> References: <1184772631.606.150.camel@cutter> <3170f42f0707181239if77e191ife9b765f0bb32331@mail.gmail.com> Message-ID: <604aa7910707181326h46b6ce12p4df37b2116488631@mail.gmail.com> On 7/18/07, Debarshi 'Rishi' Ray wrote: > One question though: Is it allowed to run some SCM, say Git, to host a > project? I know hosted.fedoraproject..org is there for such purposes, > but can someone host it here if she is refused space on > hosted.fedoraproject..org ? And to put a finer point on it. When individuals decide to host material in the fedorapeople space.. don't be an ass and attempt to host things that would otherwise not be allowed into Fedora as a distribution. If you are at all unsure as to whether or not its allowable, ask on the maintainers list for clarification from peers before you start doing it. I'm sure there will situations concerning some items which have yet to go through review which may have some sticky points concerning licensing clarification. But if you think you are in that sort of situation, drop a note to the list and ask for some feedback first. -jef"be kind, rewind"spaleta From debarshi.ray at gmail.com Wed Jul 18 20:29:16 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 19 Jul 2007 01:59:16 +0530 Subject: fedorapeople.org is now available In-Reply-To: <604aa7910707181326h46b6ce12p4df37b2116488631@mail.gmail.com> References: <1184772631.606.150.camel@cutter> <3170f42f0707181239if77e191ife9b765f0bb32331@mail.gmail.com> <604aa7910707181326h46b6ce12p4df37b2116488631@mail.gmail.com> Message-ID: <3170f42f0707181329j3d4143f4tb534532eb768dc6e@mail.gmail.com> > And to put a finer point on it. When individuals decide to host > material in the fedorapeople space.. don't be an ass and attempt to > host things that would otherwise not be allowed into Fedora as a > distribution. If you are at all unsure as to whether or not its > allowable, ask on the maintainers list for clarification from peers > before you start doing it. Sure. I was actually referring to ad-hoc Free Software projects one may undertake, which may not be concrete enough to be hosted on hosted.fedoraproject.org. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From laxathom at fedoraproject.org Wed Jul 18 23:46:51 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Wed, 18 Jul 2007 19:46:51 -0400 Subject: Orphaned Package Message-ID: <62bc09df0707181646p2a5dffa3gfe7da5a68d7ef3f5@mail.gmail.com> Hello Folks, i'd take over g-wrap package. i'm currently working on few packages (for fedora repo) which require an updated release of g-wrap over 1.9.6 (actual release). Regards, -- 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 chitlesh at fedoraproject.org Thu Jul 19 09:48:03 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 19 Jul 2007 11:48:03 +0200 Subject: Orphaned Package In-Reply-To: <62bc09df0707181646p2a5dffa3gfe7da5a68d7ef3f5@mail.gmail.com> References: <62bc09df0707181646p2a5dffa3gfe7da5a68d7ef3f5@mail.gmail.com> Message-ID: <13dbfe4f0707190248gff40530y34923bba696b0796@mail.gmail.com> On 7/19/07, Xavier Lamien wrote: > Hello Folks, > > i'd take over g-wrap package. > i'm currently working on few packages (for fedora repo) which require an > updated release of g-wrap over 1.9.6 (actual release). > > Regards, Bill Nottingham has retired g-wrap on 17 July. In accordance to the cvs logs, the branch was deleted. I'll advise you to file a NEW package review request for g-wrap. More Info: http://www.redhat.com/archives/fedora-maintainers/2007-June/msg00752.html chitlesh -- http://clunixchit.blogspot.com From SteveD at redhat.com Thu Jul 19 12:12:55 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 19 Jul 2007 08:12:55 -0400 Subject: Messy Update.... Message-ID: <469F5547.8060008@RedHat.com> I'm looking for a little help with a potential messy update. Basically, a configuration file is been moved from one package to another, dependent, package. So if the package that contains the old config file is not completely removed when the package with the new config file is installed, there will be file conflict.... Now here is the context nfs-utils-lib-1.0.8-9 moving to nfs-utils-lib-1.0.8-10 nfs-utils-1.0.10-7 moving to nfs-utils-1.1.0-1 nfs-utils depends on nfs-utils-lib nfs-utils-1.0.10-7 contains the obsolete config file nfs-utils-lib-1.0.8-9 contains the new config file So when nfs-utils-lib upgraded there a file confliction because the file already exists in nfs-utils-1.0.10-7. Now if you force install nfs-utils-lib-1.0.8-10 or remove nfs-utils then install nfs-utils-lib-1.0.8-10 then things work... So is there some rpm spec file magic I can to make this work? Is there a way to remove a package for another one is installed? Are force upgrades an option? tia, steved. From atkac at redhat.com Thu Jul 19 12:38:37 2007 From: atkac at redhat.com (Adam Tkac) Date: Thu, 19 Jul 2007 14:38:37 +0200 Subject: Messy Update.... In-Reply-To: <469F5547.8060008@RedHat.com> References: <469F5547.8060008@RedHat.com> Message-ID: <469F5B4D.8080104@redhat.com> Steve Dickson napsal(a): > I'm looking for a little help with a potential messy update. > > Basically, a configuration file is been moved from one package > to another, dependent, package. So if the package that contains > the old config file is not completely removed when the package > with the new config file is installed, there will be file > conflict.... > > Now here is the context > > nfs-utils-lib-1.0.8-9 moving to nfs-utils-lib-1.0.8-10 > nfs-utils-1.0.10-7 moving to nfs-utils-1.1.0-1 > > nfs-utils depends on nfs-utils-lib > > nfs-utils-1.0.10-7 contains the obsolete config file > nfs-utils-lib-1.0.8-9 contains the new config file > > So when nfs-utils-lib upgraded there a file confliction > because the file already exists in nfs-utils-1.0.10-7. > > Now if you force install nfs-utils-lib-1.0.8-10 or > remove nfs-utils then install nfs-utils-lib-1.0.8-10 > then things work... > > So is there some rpm spec file magic I can to make > this work? Is there a way to remove a package for > another one is installed? Are force upgrades an option? > > tia, > > steved. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers I believe that rpm triggers should help you (http://archive.rpm.org/support/RPM-Changes-6.html). You could try something like this in new version of nfs-utils-lib: %triggerin -- nfs-utils <= 1.0.10-7 rm -f _configfile_ But I recommend you test improved script before you make final build :) Adam From laxathom at fedoraproject.org Thu Jul 19 12:40:31 2007 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Thu, 19 Jul 2007 08:40:31 -0400 Subject: Orphaned Package In-Reply-To: <13dbfe4f0707190248gff40530y34923bba696b0796@mail.gmail.com> References: <62bc09df0707181646p2a5dffa3gfe7da5a68d7ef3f5@mail.gmail.com> <13dbfe4f0707190248gff40530y34923bba696b0796@mail.gmail.com> Message-ID: <62bc09df0707190540l25457017hc917c4f7b7313292@mail.gmail.com> 2007/7/19, Chitlesh GOORAH : > > On 7/19/07, Xavier Lamien wrote: > > Hello Folks, > > > > i'd take over g-wrap package. > > i'm currently working on few packages (for fedora repo) which require an > > updated release of g-wrap over 1.9.6 (actual release). > > > > Regards, > > Bill Nottingham has retired g-wrap on 17 July. > > In accordance to the cvs logs, the branch was deleted. I'll advise you > to file a NEW package review request for g-wrap. > > More Info: > http://www.redhat.com/archives/fedora-maintainers/2007-June/msg00752.html thanks, i missed this file chitlesh > > -- > http://clunixchit.blogspot.com > > -- > 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 SteveD at redhat.com Thu Jul 19 12:44:27 2007 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 19 Jul 2007 08:44:27 -0400 Subject: Messy Update.... In-Reply-To: <469F5B4D.8080104@redhat.com> References: <469F5547.8060008@RedHat.com> <469F5B4D.8080104@redhat.com> Message-ID: <469F5CAB.6050502@RedHat.com> Adam Tkac wrote: > Steve Dickson napsal(a): >> I'm looking for a little help with a potential messy update. >> >> Basically, a configuration file is been moved from one package >> to another, dependent, package. So if the package that contains >> the old config file is not completely removed when the package >> with the new config file is installed, there will be file >> conflict.... >> >> Now here is the context >> >> nfs-utils-lib-1.0.8-9 moving to nfs-utils-lib-1.0.8-10 >> nfs-utils-1.0.10-7 moving to nfs-utils-1.1.0-1 >> >> nfs-utils depends on nfs-utils-lib >> >> nfs-utils-1.0.10-7 contains the obsolete config file >> nfs-utils-lib-1.0.8-9 contains the new config file >> >> So when nfs-utils-lib upgraded there a file confliction >> because the file already exists in nfs-utils-1.0.10-7. >> >> Now if you force install nfs-utils-lib-1.0.8-10 or >> remove nfs-utils then install nfs-utils-lib-1.0.8-10 >> then things work... >> >> So is there some rpm spec file magic I can to make >> this work? Is there a way to remove a package for >> another one is installed? Are force upgrades an option? >> >> tia, >> >> steved. >> >> -- >> Fedora-maintainers mailing list >> Fedora-maintainers at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-maintainers > I believe that rpm triggers should help you > (http://archive.rpm.org/support/RPM-Changes-6.html). You could try > something like this in new version of nfs-utils-lib: > > %triggerin -- nfs-utils <= 1.0.10-7 > rm -f _configfile_ Good idea... but.. if I remove/rename the config file, by hand, before the nfs-utils upgrade, it still complains about the file confliction. I guess RPM has some time of file registry for each package. > > But I recommend you test improved script before you make final build :) Is there such an thing as a "final" build?? 8-) steved. From atkac at redhat.com Thu Jul 19 13:03:00 2007 From: atkac at redhat.com (Adam Tkac) Date: Thu, 19 Jul 2007 15:03:00 +0200 Subject: Messy Update.... In-Reply-To: <469F5CAB.6050502@RedHat.com> References: <469F5547.8060008@RedHat.com> <469F5B4D.8080104@redhat.com> <469F5CAB.6050502@RedHat.com> Message-ID: <469F6104.4070301@redhat.com> Steve Dickson napsal(a): > Adam Tkac wrote: >> Steve Dickson napsal(a): >>> I'm looking for a little help with a potential messy update. >>> >>> Basically, a configuration file is been moved from one package >>> to another, dependent, package. So if the package that contains >>> the old config file is not completely removed when the package >>> with the new config file is installed, there will be file >>> conflict.... >>> >>> Now here is the context >>> >>> nfs-utils-lib-1.0.8-9 moving to nfs-utils-lib-1.0.8-10 >>> nfs-utils-1.0.10-7 moving to nfs-utils-1.1.0-1 >>> >>> nfs-utils depends on nfs-utils-lib >>> >>> nfs-utils-1.0.10-7 contains the obsolete config file >>> nfs-utils-lib-1.0.8-9 contains the new config file >>> >>> So when nfs-utils-lib upgraded there a file confliction >>> because the file already exists in nfs-utils-1.0.10-7. >>> >>> Now if you force install nfs-utils-lib-1.0.8-10 or >>> remove nfs-utils then install nfs-utils-lib-1.0.8-10 >>> then things work... >>> >>> So is there some rpm spec file magic I can to make >>> this work? Is there a way to remove a package for >>> another one is installed? Are force upgrades an option? >>> >>> tia, >>> >>> steved. >>> >>> -- >>> Fedora-maintainers mailing list >>> Fedora-maintainers at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-maintainers >> I believe that rpm triggers should help you >> (http://archive.rpm.org/support/RPM-Changes-6.html). You could try >> something like this in new version of nfs-utils-lib: >> >> %triggerin -- nfs-utils <= 1.0.10-7 >> rm -f _configfile_ > Good idea... but.. if I remove/rename the config file, by hand, > before the nfs-utils upgrade, it still complains about the > file confliction. I guess RPM has some time of file registry > for each package. So looks like you have to use Conflicts directive in specfile (same as Requires, in nfs-utils use for example Conflicts: nfs-utils-lib < 1.0.8-9 in nfs-utils-lib use Conflicts: nfs-utils < 1.1.0-1) This cause that packages have to be updated simulateously. If this still doesn't help I don't have any next ideas :( > >> >> But I recommend you test improved script before you make final build :) > Is there such an thing as a "final" build?? 8-) I call version which is generally avaliable as "final" :) Adam From katzj at redhat.com Thu Jul 19 13:25:00 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 19 Jul 2007 09:25:00 -0400 Subject: Messy Update.... In-Reply-To: <469F5547.8060008@RedHat.com> References: <469F5547.8060008@RedHat.com> Message-ID: <1184851500.22262.5.camel@localhost.localdomain> On Thu, 2007-07-19 at 08:12 -0400, Steve Dickson wrote: > I'm looking for a little help with a potential messy update. Ummm, this isn't messy. This is perfectly normal. > Basically, a configuration file is been moved from one package > to another, dependent, package. So if the package that contains > the old config file is not completely removed when the package > with the new config file is installed, there will be file > conflict.... As long as both packages are being upgraded in the same transaction set, you're fine. Which is what will normally happen. Looking at the spec file, though, nfs-utils should have Requires: nfs-utils-libs = %{version}-%{release} just generally. This will also help to ensure that the right thing happens Jeremy From loganjerry at gmail.com Thu Jul 19 05:18:09 2007 From: loganjerry at gmail.com (Jerry James) Date: Wed, 18 Jul 2007 23:18:09 -0600 Subject: Orphaning moodle Message-ID: <870180fe0707182218x39ae0a79kf532811001679037@mail.gmail.com> I have changed jobs and moved. In my new job, I will not be using moodle for any purpose. I intend to orphan moodle, and possibly perl-Text-Aspell, which I created for moodle's benefit. If anyone is interested in picking up moodle, be aware that there are open bugs that I haven't been able to get to during the move: 182999, 245750, 246986, and 247528. Well, okay, that first one is old... Regards, -- Jerry James -------------- next part -------------- An HTML attachment was scrubbed... URL: From limb at jcomserv.net Thu Jul 19 13:52:43 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 19 Jul 2007 08:52:43 -0500 (CDT) Subject: Orphaning moodle In-Reply-To: <870180fe0707182218x39ae0a79kf532811001679037@mail.gmail.com> References: <870180fe0707182218x39ae0a79kf532811001679037@mail.gmail.com> Message-ID: <63193.65.192.24.164.1184853163.squirrel@mail.jcomserv.net> > I have changed jobs and moved. In my new job, I will not be using moodle > for any purpose. I intend to orphan moodle, and possibly > perl-Text-Aspell, > which I created for moodle's benefit. If anyone is interested in picking > up > moodle, be aware that there are open bugs that I haven't been able to get > to > during the move: 182999, 245750, 246986, and 247528. Well, okay, that > first > one is old... I'll preliminarily put my hat in the ring, look and the bugs, and be ready to step aside for anyone who uses Moodle more often than I do. > Regards, > -- > Jerry James > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From buc at odusz.so-cdu.ru Thu Jul 19 16:57:10 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 19 Jul 2007 20:57:10 +0400 Subject: [SECURITY] Fedora 7 Update: clamav-0.90.3-1.fc7 Message-ID: <469F97E6.1060109@odu.neva.ru> Enrico Scholz wrote: > Can't reach the maintainer, so pushing this myself, given it's a security related update. ... > clamav-milter-sysv-0.90.3-1.fc7.i386.rpm ... > clamav-server-sysv-0.90.3-1.fc7.i386.rpm Good time to ask what I wanted: Are the "*-sysv" subpackages actually needed as SUB-packages? Why to not just include init scripts into correspond "clamav-server", "clamav-milter" etc. ? Are there any other precedents where init scripts go to separate sub-package? Regads, Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From rdieter at math.unl.edu Thu Jul 19 17:00:40 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 19 Jul 2007 12:00:40 -0500 Subject: kde4 Message-ID: <469F98B8.7000801@math.unl.edu> Just a heads-up that the KDE SIG will be working to import kde4 into rawhide *real soon now*. If you are a maintainer of an existing kde(3) application, in short, you should 1. ping your upstream to see if they have any kde4 port yet. or 2. update your existing kde3 app, changing BuildRequires: kdelibs-devel to BuildRequires: kdelibs3-devel kdelibs-3.5.7-7 and newer (F-7 updates-testing atm) includes Provides: kdelibs3, so this construct is recommended/safe to use there too. For more details, keep an eye on: http://fedoraproject.org/wiki/Releases/FeatureKDE4 (compat)kde3 reviews: kdelibs3: http://bugzilla.redhat.com/248899 kdegames3: http://bugzilla.redhat.com/248647 kdeaddons3: http://bugzilla.redhat.com/248648 coming soon, kdebase3 -- Rex From jkeating at redhat.com Thu Jul 19 17:05:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 19 Jul 2007 13:05:05 -0400 Subject: kde4 In-Reply-To: <469F98B8.7000801@math.unl.edu> References: <469F98B8.7000801@math.unl.edu> Message-ID: <20070719130505.49349511@localhost.localdomain> On Thu, 19 Jul 2007 12:00:40 -0500 Rex Dieter wrote: > Just a heads-up that the KDE SIG will be working to import kde4 into > rawhide *real soon now*. Does 'real soon now' mean before the Test1 freeze (which is in 5 days)? If so, what kind of fallout can we expect for landing this thing right before the freeze? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Thu Jul 19 17:22:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Jul 2007 22:52:56 +0530 Subject: [SECURITY] Fedora 7 Update: clamav-0.90.3-1.fc7 In-Reply-To: <469F97E6.1060109@odu.neva.ru> References: <469F97E6.1060109@odu.neva.ru> Message-ID: <469F9DF0.4000801@fedoraproject.org> Dmitry Butskoy wrote: > Enrico Scholz wrote: >> Can't reach the maintainer, so pushing this myself, given it's a >> security related update. > ... >> clamav-milter-sysv-0.90.3-1.fc7.i386.rpm > ... >> clamav-server-sysv-0.90.3-1.fc7.i386.rpm > > > Good time to ask what I wanted: > > Are the "*-sysv" subpackages actually needed as SUB-packages? Why to not > just include init scripts into correspond "clamav-server", > "clamav-milter" etc. ? Are there any other precedents where init scripts > go to separate sub-package? This is likely because the maintainer is using some other init system for his own use and prefers to keep the sysv init scripts separate so that he can uninstall them. I don't think that the scripts should be separate as long as the default init system is sysv in Fedora. Rahul From rdieter at math.unl.edu Thu Jul 19 17:30:51 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 19 Jul 2007 12:30:51 -0500 Subject: kde4 References: <469F98B8.7000801@math.unl.edu> <20070719130505.49349511@localhost.localdomain> Message-ID: <200707191730.l6JHUpTs020348@mathstat.unl.edu> Jesse Keating wrote: > On Thu, 19 Jul 2007 12:00:40 -0500 > Rex Dieter wrote: > >> Just a heads-up that the KDE SIG will be working to import kde4 into >> rawhide *real soon now*. > > Does 'real soon now' mean before the Test1 freeze (which is in 5 > days)? Yes, that's what we are aiming for. > If so, what kind of fallout can we expect for landing this > thing right before the freeze? distro fallout (broken deps, etc) should be managable. runtime stability will regress a bunch, it is only an alpha release at this point. -- Rex From jonathan.underwood at gmail.com Thu Jul 19 20:50:37 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 19 Jul 2007 21:50:37 +0100 Subject: Bugzilla quick search broken? Message-ID: <645d17210707191350j750b4aaci148e995bdcbbae08@mail.gmail.com> Hello, i tend to use the quick search on bugzilla a lot (i.e. the search you see on the front page). Recently, when entering a word, I get the message 'fish' is not a valid bug number. It is neither a bug number nor an alias to a bug number. If you are trying to use QuickSearch, you need to enable JavaScript in your browser. a lot, despite having javascript enabled in firefox. No doubt I am doing somethign stupid. Anyone care to enlighten me? Cheers, Jonathan From j.w.r.degoede at hhs.nl Thu Jul 19 20:53:03 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 19 Jul 2007 22:53:03 +0200 Subject: Cannot create new updates with bodhi Message-ID: <469FCF2F.5030108@hhs.nl> Hi all, I'm trying to create a new update with bodhi, but despite repeated attempts I keep getting: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /updates/save. Reason: Error reading from remote server Apache/2.2.3 (Red Hat) Server at admin.fedoraproject.org Port 443 Regards, Hans From tmz at pobox.com Thu Jul 19 21:03:07 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 19 Jul 2007 17:03:07 -0400 Subject: Bugzilla quick search broken? In-Reply-To: <645d17210707191350j750b4aaci148e995bdcbbae08@mail.gmail.com> References: <645d17210707191350j750b4aaci148e995bdcbbae08@mail.gmail.com> Message-ID: <20070719210307.GB22182@psilocybe.teonanacatl.org> Jonathan Underwood wrote: > i tend to use the quick search on bugzilla a lot (i.e. the search > you see on the front page). Recently, when entering a word, I get > the message > > 'fish' is not a valid bug number. It is neither a bug number nor an > alias to a bug number. If you are trying to use QuickSearch, you > need to enable JavaScript in your browser. > > a lot, despite having javascript enabled in firefox. No doubt I am > doing somethign stupid. Anyone care to enlighten me? I'm with stupid then. ;) I've been getting this as well. I have only tried it with Firefox on F7. I haven't gotten around to testing with any other browser or OS to see if that affected things. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It is dangerous to be sincere unless you are also stupid. -- George Bernard Shaw (1856-1950) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From mmcgrath at redhat.com Thu Jul 19 21:10:23 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 19 Jul 2007 16:10:23 -0500 Subject: Cannot create new updates with bodhi In-Reply-To: <469FCF2F.5030108@hhs.nl> References: <469FCF2F.5030108@hhs.nl> Message-ID: <469FD33F.9060105@redhat.com> Hans de Goede wrote: > Hi all, > > I'm trying to create a new update with bodhi, but despite repeated > attempts I keep getting: > > Proxy Error > > The proxy server received an invalid response from an upstream server. > The proxy server could not handle the request POST /updates/save. > > Reason: Error reading from remote server > > Apache/2.2.3 (Red Hat) Server at admin.fedoraproject.org Port 443 Try this again, we had a koji outage just a bit ago that may have triggered this. -Mike From j.w.r.degoede at hhs.nl Thu Jul 19 21:19:49 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 19 Jul 2007 23:19:49 +0200 Subject: Cannot create new updates with bodhi In-Reply-To: <469FD33F.9060105@redhat.com> References: <469FCF2F.5030108@hhs.nl> <469FD33F.9060105@redhat.com> Message-ID: <469FD575.2010402@hhs.nl> Mike McGrath wrote: > Hans de Goede wrote: >> Hi all, >> >> I'm trying to create a new update with bodhi, but despite repeated >> attempts I keep getting: >> >> Proxy Error >> >> The proxy server received an invalid response from an upstream server. >> The proxy server could not handle the request POST /updates/save. >> >> Reason: Error reading from remote server >> >> Apache/2.2.3 (Red Hat) Server at admin.fedoraproject.org Port 443 > > Try this again, we had a koji outage just a bit ago that may have > triggered this. > Ah, yes works fine now, Thanks, Hans 7 From denis at poolshark.org Thu Jul 19 22:51:55 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 20 Jul 2007 00:51:55 +0200 Subject: [SECURITY] Fedora 7 Update: clamav-0.90.3-1.fc7 In-Reply-To: <469F97E6.1060109@odu.neva.ru> References: <469F97E6.1060109@odu.neva.ru> Message-ID: <469FEB0B.5030506@poolshark.org> Dmitry Butskoy wrote: > Enrico Scholz wrote: >> Can't reach the maintainer, so pushing this myself, given it's a >> security related update. > ... >> clamav-milter-sysv-0.90.3-1.fc7.i386.rpm > ... >> clamav-server-sysv-0.90.3-1.fc7.i386.rpm > > > Good time to ask what I wanted: > > Are the "*-sysv" subpackages actually needed as SUB-packages? Why to not > just include init scripts into correspond "clamav-server", > "clamav-milter" etc. ? Are there any other precedents where init scripts > go to separate sub-package? It's been a steady source of complaints over time and nobody thinks it's a good idea besides the maintainer, but nobody ever bothered to bring this to Fesco... From icon at fedoraproject.org Fri Jul 20 00:07:29 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 19 Jul 2007 20:07:29 -0400 Subject: Repoview-0.6.0 Message-ID: Hello, everyone: Repoview version 0.6.0 is available and should make life much easier -- this version introduces state tracking, so now repoview is aware of changes between runs. This means that it only generates and writes the files that have actually changed, which makes it extremely fast for small changes and also makes it rsync-friendly. This came at a sacrifice of a couple of things -- notably, the code is messier and not as elegant, which is why refactoring is slated for 0.7. Also, the left-side bar is now mostly unused, in order to simplify state-tracking. Most importantly, repoview now requires .sqlite databases in repodata directory, which means that it only supports repositories generated with createrepo -d. Special thanks to Michael Schwendt who gave me lots of ideas. You can get the tarball here: http://mricon.com/trac/wiki/Repoview I will update the devel branch of the fedora tree soon. Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From jkeating at redhat.com Fri Jul 20 02:46:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 19 Jul 2007 22:46:00 -0400 Subject: Building firefox-2.0.0.5 for rawhide Message-ID: <20070719224600.0d299186@ender> This was previously just built on Fedora 7, but it needs to be built on devel/ as well for rawhide. It's building now, might hit before the rawhide composes starts. Not sure. Just a heads up that once it does land, you all that build against firefox will need to rebuild your packages against it, preferably before the Test1 freeze. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Jul 20 07:40:03 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 20 Jul 2007 09:40:03 +0200 Subject: [SECURITY] Fedora 7 Update: clamav-0.90.3-1.fc7 In-Reply-To: <469F97E6.1060109@odu.neva.ru> (Dmitry Butskoy's message of "Thu, 19 Jul 2007 20:57:10 +0400") References: <469F97E6.1060109@odu.neva.ru> Message-ID: <873azjed64.fsf@kosh.bigo.ensc.de> Dmitry Butskoy writes: > Are the "*-sysv" subpackages actually needed as SUB-packages? Why > to not just include init scripts into correspond "clamav-server", > "clamav-milter" etc. ? When you show me that the daemons really require e2fsprogs, ethtool, mingetty, mount, net-tool, udev, ... for their core functionality, then I will add the bloaty 'initscripts' dependency. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From mtasaka at ioa.s.u-tokyo.ac.jp Fri Jul 20 08:24:51 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 20 Jul 2007 17:24:51 +0900 Subject: Building firefox-2.0.0.5 for rawhide In-Reply-To: <20070719224600.0d299186@ender> References: <20070719224600.0d299186@ender> Message-ID: <46A07153.9090700@ioa.s.u-tokyo.ac.jp> Jesse Keating wrote, at 07/20/2007 11:46 AM +9:00: > This was previously just built on Fedora 7, but it needs to be built on > devel/ as well for rawhide. It's building now, might hit before the > rawhide composes starts. Not sure. Just a heads up that once it does > land, you all that build against firefox will need to rebuild your > packages against it, preferably before the Test1 freeze. > Well, my package kazehakase has to be rebuilt against newer gecko (firefox 2.0.0.5), but currently I cannot do because firefox requires libgnomeui, libgnomeui pulls yelp (*on rawhide*), and current yelp requires gecko 1.8.1.4 (i.e. firefox 2.0.0.4) http://koji.fedoraproject.org/koji/buildinfo?buildID=11492 This change is due to: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243478 Mamoru From kengert at redhat.com Fri Jul 20 08:36:10 2007 From: kengert at redhat.com (Kai Engert) Date: Fri, 20 Jul 2007 10:36:10 +0200 Subject: Building firefox-2.0.0.5 for rawhide In-Reply-To: <20070719224600.0d299186@ender> References: <20070719224600.0d299186@ender> Message-ID: <46A073FA.4080500@redhat.com> Jesse Keating schrieb: > This was previously just built on Fedora 7, but it needs to be built on > devel/ as well for rawhide. It's building now, might hit before the > rawhide composes starts. Not sure. Just a heads up that once it does > land, you all that build against firefox will need to rebuild your > packages against it, preferably before the Test1 freeze. > I tried to rebuild yelp and devhelp. They both fail with an error that surprises me and I don't understand. When attempting to build yelp, it fails complaining "Error: Missing Dependency: gecko-libs = 1.8.1.4 is needed by package yelp" (1.8.1.4 is the old one). The new yelp.spec is set to require gecko-libs 1.8.1.5. The build log indicates that it's pulling in (new) gecko-libs 1.8.1.5, and there is no error, so I conclude that works. Why this attempt to pull in the old yelp and the old gecko-libs? Thanks in advance for your help, Kai From mtasaka at ioa.s.u-tokyo.ac.jp Fri Jul 20 08:46:16 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 20 Jul 2007 17:46:16 +0900 Subject: Building firefox-2.0.0.5 for rawhide In-Reply-To: <46A073FA.4080500@redhat.com> References: <20070719224600.0d299186@ender> <46A073FA.4080500@redhat.com> Message-ID: <46A07658.3000901@ioa.s.u-tokyo.ac.jp> Kai Engert wrote, at 07/20/2007 05:36 PM +9:00: > Jesse Keating schrieb: >> This was previously just built on Fedora 7, but it needs to be built on >> devel/ as well for rawhide. It's building now, might hit before the >> rawhide composes starts. Not sure. Just a heads up that once it does >> land, you all that build against firefox will need to rebuild your >> packages against it, preferably before the Test1 freeze. >> > > I tried to rebuild yelp and devhelp. > They both fail with an error that surprises me and I don't understand. > > When attempting to build yelp, it fails complaining "Error: Missing > Dependency: gecko-libs = 1.8.1.4 is needed by package yelp" (1.8.1.4 is > the old one). I wrote the reason for this just ten minutes before you wrote this :) https://www.redhat.com/archives/fedora-maintainers/2007-July/msg00294.html Mamoru From kengert at redhat.com Fri Jul 20 09:10:19 2007 From: kengert at redhat.com (Kai Engert) Date: Fri, 20 Jul 2007 11:10:19 +0200 Subject: Building firefox-2.0.0.5 for rawhide In-Reply-To: <46A07658.3000901@ioa.s.u-tokyo.ac.jp> References: <20070719224600.0d299186@ender> <46A073FA.4080500@redhat.com> <46A07658.3000901@ioa.s.u-tokyo.ac.jp> Message-ID: <46A07BFB.7030704@redhat.com> Mamoru Tasaka schrieb: > Kai Engert wrote, at 07/20/2007 05:36 PM +9:00: >> Jesse Keating schrieb: >>> This was previously just built on Fedora 7, but it needs to be built on >>> devel/ as well for rawhide. It's building now, might hit before the >>> rawhide composes starts. Not sure. Just a heads up that once it does >>> land, you all that build against firefox will need to rebuild your >>> packages against it, preferably before the Test1 freeze. >>> >> >> I tried to rebuild yelp and devhelp. >> They both fail with an error that surprises me and I don't understand. >> >> When attempting to build yelp, it fails complaining "Error: Missing >> Dependency: gecko-libs = 1.8.1.4 is needed by package yelp" (1.8.1.4 >> is the old one). > > I wrote the reason for this just ten minutes before you wrote this :) > https://www.redhat.com/archives/fedora-maintainers/2007-July/msg00294.html > > > Mamoru Mamoru, thanks a lot for your analysis of the cause. I filed bug 249000. Kai From buc at odusz.so-cdu.ru Fri Jul 20 12:24:17 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 20 Jul 2007 16:24:17 +0400 Subject: [SECURITY] Fedora 7 Update: clamav-0.90.3-1.fc7 In-Reply-To: <873azjed64.fsf@kosh.bigo.ensc.de> References: <469F97E6.1060109@odu.neva.ru> <873azjed64.fsf@kosh.bigo.ensc.de> Message-ID: <46A0A971.1020803@odu.neva.ru> Enrico Scholz wrote: > Dmitry Butskoy writes: > > >> Are the "*-sysv" subpackages actually needed as SUB-packages? Why >> to not just include init scripts into correspond "clamav-server", >> "clamav-milter" etc. ? >> > > When you show me that the daemons really require e2fsprogs, ethtool, > mingetty, mount, net-tool, udev, ... for their core functionality, then > I will add the bloaty 'initscripts' dependency. > Well, I guess you mean you want to provide some "general" rpms, useful for another distros, not for Fedora only. But Fedora uses initscripts. Moreover, all Clamav potential "friends" (postfix, sendmail, samba etc.) use initscript when packaged for Fedora. Hence such a separating just looks strange here. Maybe a compromise is to use some "%define" switch in .spec file? I.e.. "%define separate_sysv 0" for Fedora, and "1" for initscript-less environment. If you agree, I could provide a correct patch for this. By the way, whether you actually use Fedora without initscripts package? What another daemons without init scripts are used, from what repository its packages come? I just curious... Regards, Dmitry Butskoy From wolters.liste at gmx.net Fri Jul 20 13:43:28 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Fri, 20 Jul 2007 15:43:28 +0200 Subject: Repoview-0.6.0 In-Reply-To: References: Message-ID: <200707201543.35587.wolters.liste@gmx.net> Once upon a time Konstantin Ryabitsev wrote: > Repoview version 0.6.0 is available and should make life much easier > -- this version introduces state tracking, so now repoview is aware of > changes between runs. This means that it only generates and writes the > files that have actually changed, which makes it extremely fast for > small changes and also makes it rsync-friendly. > Sounds nice. Will we see this repoview version used in the official repositories anytime soon? The extras repository of FC6 had it, but in the main repository of F7 there is no useful repoview - not even in the updates! Roland -- "In der Wissenschaft versucht man etwas, das niemand wusste, auf eine Weise zu sagen, die jeder versteht. In der Dichtung verh?lt es sich gerade umgekehrt." -- Paul Dirac -------------- 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 Jul 20 14:07:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 20 Jul 2007 10:07:13 -0400 Subject: Repoview-0.6.0 In-Reply-To: <200707201543.35587.wolters.liste@gmx.net> References: <200707201543.35587.wolters.liste@gmx.net> Message-ID: <20070720100713.0f9cfa6c@localhost.localdomain> On Fri, 20 Jul 2007 15:43:28 +0200 Roland Wolters wrote: > Sounds nice. Will we see this repoview version used in the official > repositories anytime soon? > The extras repository of FC6 had it, but in the main repository of F7 > there is no useful repoview - not even in the updates! Yes, I'll be looking at re-integrating it back into the various compose processes. Maybe not until after Test1 though as we'll be slightly busy for that. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Jul 20 15:48:16 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 20 Jul 2007 17:48:16 +0200 Subject: [SECURITY] Fedora 7 Update: clamav-0.90.3-1.fc7 In-Reply-To: <46A0A971.1020803@odu.neva.ru> (Dmitry Butskoy's message of "Fri, 20 Jul 2007 16:24:17 +0400") References: <469F97E6.1060109@odu.neva.ru> <873azjed64.fsf@kosh.bigo.ensc.de> <46A0A971.1020803@odu.neva.ru> Message-ID: <87zm1r6pq7.fsf@fc5.bigo.ensc.de> Dmitry Butskoy writes: > Maybe a compromise is to use some "%define" switch in .spec file? This would need a rebuild of the package. I do not see the problem with the current version: 'yum install ...' on default installations installs the -sysv initscripts but I have the option to override it by adding a small package (which stays constant across different version of the main package) in my local repository. > By the way, whether you actually use Fedora without initscripts > package? Yes; almost none of my 40-50 servers uses 'initscripts'. > What another daemons without init scripts are used, The initsystem is minit (http://www.fefe.de/minit/); I created initscripts for daemons used by me (see http://ensc.de/fedora/minit-scripts.spec for a list). Enrico From buc at odusz.so-cdu.ru Fri Jul 20 17:09:22 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 20 Jul 2007 21:09:22 +0400 Subject: [SECURITY] Fedora 7 Update: clamav-0.90.3-1.fc7 In-Reply-To: <87zm1r6pq7.fsf@fc5.bigo.ensc.de> References: <469F97E6.1060109@odu.neva.ru> <873azjed64.fsf@kosh.bigo.ensc.de> <46A0A971.1020803@odu.neva.ru> <87zm1r6pq7.fsf@fc5.bigo.ensc.de> Message-ID: <46A0EC42.4000102@odu.neva.ru> Enrico Scholz wrote: > The initsystem is minit (http://www.fefe.de/minit/); I created initscripts > for daemons used by me (see http://ensc.de/fedora/minit-scripts.spec for a > list). > Well, Why not to add Clamav to your minit-scripts.spec as well? Why this way of packaging (separate -sysv) should be seen for all Fedora people now? Certainly it could be a hint for community to do similar sub-packages for all the init scripts, but it seems that that way was not accepted... > > This would need a rebuild of the package. I do not see the problem with > the current version: 'yum install ...' on default installations installs > the -sysv initscripts Sure! But the problem is something like "reputation". Recently we chose antivirus for some wide-enough network, comparing all pro and contra. On of a little contra for Fedora's Clamav is that it is "strange packaged", and actually it has moved a bowl of weights, and some proprietary antivirus had been chosen. :( I think not because of "sysv" subpackages exactly, but because of some "suspicions/fears" inspired by it. ~buc From jkeating at redhat.com Fri Jul 20 17:09:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 20 Jul 2007 13:09:31 -0400 Subject: Building firefox-2.0.0.5 for rawhide In-Reply-To: <46A07153.9090700@ioa.s.u-tokyo.ac.jp> References: <20070719224600.0d299186@ender> <46A07153.9090700@ioa.s.u-tokyo.ac.jp> Message-ID: <20070720130931.5012811b@localhost.localdomain> On Fri, 20 Jul 2007 17:24:51 +0900 Mamoru Tasaka wrote: > Well, my package kazehakase has to be rebuilt against newer gecko > (firefox 2.0.0.5), but currently I cannot do because firefox requires > libgnomeui, libgnomeui pulls yelp (*on rawhide*), and current yelp > requires gecko 1.8.1.4 (i.e. firefox 2.0.0.4) > http://koji.fedoraproject.org/koji/buildinfo?buildID=11492 The way is paved for your package, however you've got syntax errors in your spec file. And by, what a fun spec file.... http://koji.fedoraproject.org/koji/getfile?taskID=71689&name=build.log -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri Jul 20 17:15:34 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 20 Jul 2007 19:15:34 +0200 Subject: lm_sensors now available on ppc, please remove ExcludeArch's because of lm_sensors Message-ID: <46A0EDB6.7080404@hhs.nl> Hi all, Yesterday I've build lm_sensors-2.10.4 for devel and F-7 testing-updates, this version of lm_sensors no longer contains an ExclusiveArch to certain archs. This was wrong since for example ppc and arm machines can have lm_sensors supported sensors too. The ExclusiveArch: .... was replaced by: ExcludeArch: s390 s390x If you maintain a package which had an ExclusiveArch because of lm_sensors, please do the same and rebuild it, so that it will be available on PPC too. Notice that rel-eng has tagged the version in F-7 updates-testing for F-7 buildroot inclusion, thus you can do the rebuild for F-7 too and put the resulting package in updates-testing. I've already taken care of this for gnome-applet-sensors and gkrellm. I've also filed a bug for this for ksensors. Regards, Hans From mtasaka at ioa.s.u-tokyo.ac.jp Fri Jul 20 17:31:10 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 21 Jul 2007 02:31:10 +0900 Subject: Building firefox-2.0.0.5 for rawhide In-Reply-To: <20070720130931.5012811b@localhost.localdomain> References: <20070719224600.0d299186@ender> <46A07153.9090700@ioa.s.u-tokyo.ac.jp> <20070720130931.5012811b@localhost.localdomain> Message-ID: <46A0F15E.6090405@ioa.s.u-tokyo.ac.jp> Jesse Keating wrote, at 07/21/2007 02:09 AM +9:00: > On Fri, 20 Jul 2007 17:24:51 +0900 > Mamoru Tasaka wrote: > >> Well, my package kazehakase has to be rebuilt against newer gecko >> (firefox 2.0.0.5), but currently I cannot do because firefox requires >> libgnomeui, libgnomeui pulls yelp (*on rawhide*), and current yelp >> requires gecko 1.8.1.4 (i.e. firefox 2.0.0.4) >> http://koji.fedoraproject.org/koji/buildinfo?buildID=11492 > > The way is paved for your package, however you've got syntax errors in > your spec file. And by, what a fun spec file.... Okay, now I've fixed my spec file and the new build should succeed. Thanks. Mamoru From opensource at till.name Fri Jul 20 18:02:53 2007 From: opensource at till.name (Till Maas) Date: Fri, 20 Jul 2007 20:02:53 +0200 Subject: [SECURITY] Fedora 7 Update: clamav-0.90.3-1.fc7 In-Reply-To: <46A0EC42.4000102@odu.neva.ru> References: <469F97E6.1060109@odu.neva.ru> <87zm1r6pq7.fsf@fc5.bigo.ensc.de> <46A0EC42.4000102@odu.neva.ru> Message-ID: <200707202002.55770.opensource@till.name> On Friday 20 July 2007 19:09:22 Dmitry Butskoy wrote: > Why not to add Clamav to your minit-scripts.spec as well? Why this way > of packaging (separate -sysv) should be seen for all Fedora people now? The answer is already in this thread, without the subpackage the package would a require a lot of packages, that are not needed for the package to work. > Certainly it could be a hint for community to do similar sub-packages > for all the init scripts, but it seems that that way was not accepted... The package passed review, so it was accepted. Imho it is good to reduce the amount of packages that have to be installed without really needing them and for me it is pretty obvious, why there is an extra -sysv subpackage. There are often also X11 subpackages, when one programm has an X and a textmode interface, e.g. vim. Regards, Till From enrico.scholz at informatik.tu-chemnitz.de Fri Jul 20 18:13:37 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 20 Jul 2007 20:13:37 +0200 Subject: [SECURITY] Fedora 7 Update: clamav-0.90.3-1.fc7 In-Reply-To: <46A0EC42.4000102@odu.neva.ru> (Dmitry Butskoy's message of "Fri, 20 Jul 2007 21:09:22 +0400") References: <469F97E6.1060109@odu.neva.ru> <873azjed64.fsf@kosh.bigo.ensc.de> <46A0A971.1020803@odu.neva.ru> <87zm1r6pq7.fsf@fc5.bigo.ensc.de> <46A0EC42.4000102@odu.neva.ru> Message-ID: <87zm1rt032.fsf@kosh.bigo.ensc.de> Dmitry Butskoy writes: >> The initsystem is minit (http://www.fefe.de/minit/); I created initscripts >> for daemons used by me (see http://ensc.de/fedora/minit-scripts.spec for a >> list). >> > > Well, > Why not to add Clamav to your minit-scripts.spec as well? Did you missed the | %minit_pkgdef clamav-milter -x reqdaemontools line? It creates the | http://ensc.de/fedora/clamav-milter-minit-0.7-9.fc5x.noarch.rpm package. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From christoph.wickert at nurfuerspam.de Sat Jul 21 02:15:19 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 21 Jul 2007 04:15:19 +0200 Subject: foo vs. foo+ Message-ID: <1184984119.5493.15.camel@wicktop.localdomain> Imagine there are two projects: foo and foo+. foo+ is a fork, a different flavor of foo, but both offer the same functionality and are compatible for other apps that sit on top of foo(+). Now both projects want to be included in fedora. First of all, both packages need a Conflicts: foo conflicts foo+ and foo+ conflicts foo. Ok so far, but foo+ also needs a "Provides: foo", and I wonder if is Provides: foo Conflicts: foo really is a good idea. And can/should we use versioned Provides: here? As foo+ is usually slightly ahead of foo, I'm afraid that yum would replace foo with foo+. Ideas, Comments? Christoph available From pertusus at free.fr Sat Jul 21 07:42:19 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 21 Jul 2007 09:42:19 +0200 Subject: foo vs. foo+ In-Reply-To: <1184984119.5493.15.camel@wicktop.localdomain> References: <1184984119.5493.15.camel@wicktop.localdomain> Message-ID: <20070721074219.GB25755@free.fr> On Sat, Jul 21, 2007 at 04:15:19AM +0200, Christoph Wickert wrote: > Imagine there are two projects: foo and foo+. foo+ is a fork, a > different flavor of foo, but both offer the same functionality and are > compatible for other apps that sit on top of foo(+). > > Now both projects want to be included in fedora. First of all, both > packages need a Conflicts: foo conflicts foo+ and foo+ conflicts foo. > > Ok so far, but foo+ also needs a "Provides: foo", and I wonder if is > Provides: foo > Conflicts: foo > really is a good idea. And can/should we use versioned Provides: here? Unless I am wrong, yum (rpm) won't care about versioned Provides:, and replace foo+ with foo (I had such issues with libnet10/libnet). > As foo+ is usually slightly ahead of foo, I'm afraid that yum would > replace foo with foo+. > > Ideas, Comments? Maybe use the alternatives system instead of a conflict? And a virtual provides (maybe versionned) for the foo capability? -- Pat From opensource at till.name Sat Jul 21 07:47:50 2007 From: opensource at till.name (Till Maas) Date: Sat, 21 Jul 2007 09:47:50 +0200 Subject: foo vs. foo+ In-Reply-To: <1184984119.5493.15.camel@wicktop.localdomain> References: <1184984119.5493.15.camel@wicktop.localdomain> Message-ID: <200707210947.54072.opensource@till.name> On Saturday 21 July 2007 04:15:19 Christoph Wickert wrote: > Imagine there are two projects: foo and foo+. foo+ is a fork, a > different flavor of foo, but both offer the same functionality and are > compatible for other apps that sit on top of foo(+). > > Now both projects want to be included in fedora. First of all, both > packages need a Conflicts: foo conflicts foo+ and foo+ conflicts foo. Why do they need to conflict each other? Maybe using "alternatives" is enough. Regards, Till From ville.skytta at iki.fi Sat Jul 21 09:50:35 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 21 Jul 2007 12:50:35 +0300 Subject: foo vs. foo+ In-Reply-To: <20070721074219.GB25755@free.fr> References: <1184984119.5493.15.camel@wicktop.localdomain> <20070721074219.GB25755@free.fr> Message-ID: <200707211250.36494.ville.skytta@iki.fi> On Saturday 21 July 2007, Patrice Dumas wrote: > On Sat, Jul 21, 2007 at 04:15:19AM +0200, Christoph Wickert wrote: > > Ok so far, but foo+ also needs a "Provides: foo", and I wonder if is > > Provides: foo > > Conflicts: foo > > really is a good idea. And can/should we use versioned Provides: here? > > Unless I am wrong, yum (rpm) won't care about versioned Provides:, and > replace foo+ with foo (I had such issues with libnet10/libnet). Do you have a test case available where rpm/yum ignores the version? From laroche at redhat.com Sat Jul 21 10:07:34 2007 From: laroche at redhat.com (Florian La Roche) Date: Sat, 21 Jul 2007 12:07:34 +0200 Subject: foo vs. foo+ In-Reply-To: <200707211250.36494.ville.skytta@iki.fi> References: <1184984119.5493.15.camel@wicktop.localdomain> <20070721074219.GB25755@free.fr> <200707211250.36494.ville.skytta@iki.fi> Message-ID: <20070721100734.GA7452@dudweiler.stuttgart.redhat.com> On Sat, Jul 21, 2007 at 12:50:35PM +0300, Ville Skytt? wrote: > On Saturday 21 July 2007, Patrice Dumas wrote: > > On Sat, Jul 21, 2007 at 04:15:19AM +0200, Christoph Wickert wrote: > > > Ok so far, but foo+ also needs a "Provides: foo", and I wonder if is > > > Provides: foo > > > Conflicts: foo > > > really is a good idea. And can/should we use versioned Provides: here? > > > > Unless I am wrong, yum (rpm) won't care about versioned Provides:, and > > replace foo+ with foo (I had such issues with libnet10/libnet). > > Do you have a test case available where rpm/yum ignores the version? For "Provides: foo" and "Requires: foo >= 1.0" the version information is just ignored and this always matches. I've written a small test, so that all such cases can be listed and they can get screened for real problem cases. Output for the current Fedora-devel tree looks like: jakarta-commons-codec-1.3-7jpp.2.i386.rpm should have a flag/version added for the provides (commons-codec >= 1.3) initng-ifiles-0.1.3-1.fc8.i386.rpm should have a flag/version added for the provides (initng(ifiles) >= 0.1.2) paraview-mpi-3.0.2-1.fc8.i386.rpm should have a flag/version added for the provides (paraview = 3.0.2-1.fc8) perl-5.8.8-19.fc8.i386.rpm should have a flag/version added for the provides (perl(CGI) >= 2.81) perl-Cairo-1.041-1.fc8.i386.rpm should have a flag/version added for the provides (perl(Cairo) >= 1.00) perl-Class-Accessor-0.30-1.fc7.noarch.rpm should have a flag/version added for the provides (perl(Class::Accessor::Fast) >= 0.19) perl-Class-DBI-3.0.16-1.fc7.noarch.rpm should have a flag/version added for the provides (perl(Class::DBI) >= 0.90) perl-Compress-Raw-Bzip2-2.005-2.fc8.i386.rpm should have a flag/version added for the provides (perl(Compress::Raw::Bzip2) >= 2.005) perl-Config-General-2.33-1.fc7.noarch.rpm should have a flag/version added for the provides (perl(Config::General) >= 1.18) perl-Config-General-2.33-1.fc7.noarch.rpm should have a flag/version added for the provides (perl(Config::General) >= 2.19) perl-DateManip-5.44-3.fc7.noarch.rpm should have a flag/version added for the provides (perl(Date::Manip) >= 5.00) perl-Email-Simple-1.999-1.fc7.noarch.rpm should have a flag/version added for the provides (perl(Email::Simple) >= 1.91) perl-5.8.8-19.fc8.i386.rpm should have a flag/version added for the provides (perl(Getopt::Long) >= 2.01) perl-5.8.8-19.fc8.i386.rpm should have a flag/version added for the provides (perl(Getopt::Long) >= 2.17) perl-5.8.8-19.fc8.i386.rpm should have a flag/version added for the provides (perl(Getopt::Long) >= 2.25) perl-Glib-1.144-1.fc7.i386.rpm should have a flag/version added for the provides (perl(Glib) >= 1.140) perl-HTML-Template-2.9-1.fc7.noarch.rpm should have a flag/version added for the provides (perl(HTML::Template) >= 2.4) perl-HTML-Template-2.9-1.fc7.noarch.rpm should have a flag/version added for the provides (perl(HTML::Template) >= 2.6) perl-IO-Compress-Base-2.005-2.fc8.noarch.rpm should have a flag/version added for the provides (perl(IO::Compress::Base::Common) >= 2.005) perl-IO-Compress-Base-2.005-2.fc8.noarch.rpm should have a flag/version added for the provides (perl(IO::Uncompress::Base) >= 2.005) perl-Kwiki-Revisions-0.15-5.fc7.noarch.rpm should have a flag/version added for the provides (perl(Kwiki::Revisions) >= 0.12) perl-Locale-Maketext-Lexicon-0.64-1.fc8.noarch.rpm should have a flag/version added for the provides (perl(Locale::Maketext::Lexicon) >= 0.20) perl-Locale-Maketext-Lexicon-0.64-1.fc8.noarch.rpm should have a flag/version added for the provides (perl(Locale::Maketext::Lexicon) >= 0.25) perl-Params-Validate-0.88-1.fc7.i386.rpm should have a flag/version added for the provides (perl(Params::Validate) >= 0.23) perl-Params-Validate-0.88-1.fc7.i386.rpm should have a flag/version added for the provides (perl(Params::Validate) >= 0.7) perl-Params-Validate-0.88-1.fc7.i386.rpm should have a flag/version added for the provides (perl(Params::Validate) >= 0.76) perl-Readonly-1.03-6.fc6.noarch.rpm should have a flag/version added for the provides (perl(Readonly) >= 1.02) subversion-perl-1.4.3-4.i386.rpm should have a flag/version added for the provides (perl(SVN::Core) >= 1.0.7) perl-Spiffy-0.30-7.fc7.noarch.rpm should have a flag/version added for the provides (perl(Spiffy) >= 0.21) perl-Spiffy-0.30-7.fc7.noarch.rpm should have a flag/version added for the provides (perl(Spiffy) >= 0.22) perl-Time-Piece-MySQL-0.05-3.fc6.noarch.rpm should have a flag/version added for the provides (perl(Time::Piece) >= 1.03) perl-Tk-804.027-11.fc7.i386.rpm should have a flag/version added for the provides (perl(Tk) >= 800.005) perl-Tk-804.027-11.fc7.i386.rpm should have a flag/version added for the provides (perl(Tk) >= 800.015) perl-Tk-804.027-11.fc7.i386.rpm should have a flag/version added for the provides (perl(Tk) >= 800.021) perl-Tk-804.027-11.fc7.i386.rpm should have a flag/version added for the provides (perl(Tk) >= 800.022) perl-Tk-804.027-11.fc7.i386.rpm should have a flag/version added for the provides (perl(Tk) >= 804.000) maxima-runtime-sbcl-5.12.0-3.fc8.i386.rpm did not find a package for: (sbcl = 1.0.6) tomcat5-servlet-2.4-api-5.5.23-9jpp.2.fc7.i386.rpm should have a flag/version added for the provides (servletapi5 >= 0:5.0.16) So this is mostly hit by perl rpms and then a few others. Shouldn't be a big thing to clean up overall. regards, Florian La Roche From ville.skytta at iki.fi Sat Jul 21 10:33:06 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 21 Jul 2007 13:33:06 +0300 Subject: foo vs. foo+ In-Reply-To: <20070721100734.GA7452@dudweiler.stuttgart.redhat.com> References: <1184984119.5493.15.camel@wicktop.localdomain> <200707211250.36494.ville.skytta@iki.fi> <20070721100734.GA7452@dudweiler.stuttgart.redhat.com> Message-ID: <200707211333.07138.ville.skytta@iki.fi> On Saturday 21 July 2007, Florian La Roche wrote: > On Sat, Jul 21, 2007 at 12:50:35PM +0300, Ville Skytt? wrote: > > On Saturday 21 July 2007, Patrice Dumas wrote: > > > On Sat, Jul 21, 2007 at 04:15:19AM +0200, Christoph Wickert wrote: > > > > Ok so far, but foo+ also needs a "Provides: foo", and I wonder if is > > > > Provides: foo > > > > Conflicts: foo > > > > really is a good idea. And can/should we use versioned Provides: > > > > here? > > > > > > Unless I am wrong, yum (rpm) won't care about versioned Provides:, and > > > replace foo+ with foo (I had such issues with libnet10/libnet). > > > > Do you have a test case available where rpm/yum ignores the version? > > For "Provides: foo" and "Requires: foo >= 1.0" the version information > is just ignored and this always matches. I wouldn't say anything is ignored there; I tend to think of Provides: foo as "Provides foo, all versions of it". But perhaps that's just playing with words. Anyway it does demonstrate problems with unversioned Provides and friends. > I've written a small test, so that all such cases can be listed and they > can get screened for real problem cases. Output for the current > Fedora-devel tree looks like: [...] > So this is mostly hit by perl rpms and then a few others. Shouldn't be a > big thing to clean up overall. I suspect the majority of the perl ones are affected because something in the module's contents outsmarts rpmbuild's automagic Provides extraction and should ideally be fixed there to the extent possible instead of patching the packages. For example General.pm in perl-Config-General has: package Config::General; [...] $Config::General::VERSION = 2.33; rpmbuild doesn't extract the version from a fully qualified notation like this one. I submitted a patch for that and some other cases a long time ago (#61797), maybe it or parts of it should be resurrected. From ville.skytta at iki.fi Sat Jul 21 11:11:47 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 21 Jul 2007 14:11:47 +0300 Subject: foo vs. foo+ In-Reply-To: <200707211333.07138.ville.skytta@iki.fi> References: <1184984119.5493.15.camel@wicktop.localdomain> <20070721100734.GA7452@dudweiler.stuttgart.redhat.com> <200707211333.07138.ville.skytta@iki.fi> Message-ID: <200707211411.47804.ville.skytta@iki.fi> On Saturday 21 July 2007, Ville Skytt? wrote: > > rpmbuild doesn't extract the version from a fully qualified notation like > this one. I submitted a patch for that and some other cases a long time > ago (#61797), maybe it or parts of it should be resurrected. First bits done: https://bugzilla.redhat.com/249135 From Axel.Thimm at ATrpms.net Sat Jul 21 12:05:58 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 21 Jul 2007 14:05:58 +0200 Subject: foo vs. foo+ In-Reply-To: <200707211333.07138.ville.skytta@iki.fi> References: <1184984119.5493.15.camel@wicktop.localdomain> <200707211250.36494.ville.skytta@iki.fi> <20070721100734.GA7452@dudweiler.stuttgart.redhat.com> <200707211333.07138.ville.skytta@iki.fi> Message-ID: <20070721120558.GE25326@puariko.nirvana> On Sat, Jul 21, 2007 at 01:33:06PM +0300, Ville Skytt? wrote: > On Saturday 21 July 2007, Florian La Roche wrote: > > On Sat, Jul 21, 2007 at 12:50:35PM +0300, Ville Skytt? wrote: > > > On Saturday 21 July 2007, Patrice Dumas wrote: > > > > On Sat, Jul 21, 2007 at 04:15:19AM +0200, Christoph Wickert wrote: > > > > > Ok so far, but foo+ also needs a "Provides: foo", and I wonder if is > > > > > Provides: foo > > > > > Conflicts: foo > > > > > really is a good idea. And can/should we use versioned Provides: > > > > > here? > > > > > > > > Unless I am wrong, yum (rpm) won't care about versioned Provides:, and > > > > replace foo+ with foo (I had such issues with libnet10/libnet). No, that's a different bug probably. If one of the virtual provides was a real entity then you trigger another rpm bug that was tagged a feature (check bugzilla for concurrent python of some sound libs from ccrma for details, I don't have the bz# handy): It automatically introduces silent Obsoletes ... > > > Do you have a test case available where rpm/yum ignores the version? > > > > For "Provides: foo" and "Requires: foo >= 1.0" the version information > > is just ignored and this always matches. > > I wouldn't say anything is ignored there; I tend to think of Provides: foo > as "Provides foo, all versions of it". But perhaps that's just playing with > words. That were the semantics that were applied to rpm and the versionless syntax above, Ville's wording strike the specification back then quite accurately. This was the ancient painful Provides: kernel issue. E.g. Florian's example is exactly what should not be done. -- 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 pmatilai at laiskiainen.org Sat Jul 21 12:41:37 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 21 Jul 2007 15:41:37 +0300 (EEST) Subject: foo vs. foo+ In-Reply-To: <20070721120558.GE25326@puariko.nirvana> References: <1184984119.5493.15.camel@wicktop.localdomain> <200707211250.36494.ville.skytta@iki.fi> <20070721100734.GA7452@dudweiler.stuttgart.redhat.com> <200707211333.07138.ville.skytta@iki.fi> <20070721120558.GE25326@puariko.nirvana> Message-ID: On Sat, 21 Jul 2007, Axel Thimm wrote: > On Sat, Jul 21, 2007 at 01:33:06PM +0300, Ville Skytt? wrote: >> On Saturday 21 July 2007, Florian La Roche wrote: >>> On Sat, Jul 21, 2007 at 12:50:35PM +0300, Ville Skytt? wrote: >>>> On Saturday 21 July 2007, Patrice Dumas wrote: >>>>> On Sat, Jul 21, 2007 at 04:15:19AM +0200, Christoph Wickert wrote: >>>>>> Ok so far, but foo+ also needs a "Provides: foo", and I wonder if is >>>>>> Provides: foo >>>>>> Conflicts: foo >>>>>> really is a good idea. And can/should we use versioned Provides: >>>>>> here? >>>>> >>>>> Unless I am wrong, yum (rpm) won't care about versioned Provides:, and >>>>> replace foo+ with foo (I had such issues with libnet10/libnet). > > No, that's a different bug probably. If one of the virtual provides > was a real entity then you trigger another rpm bug that was tagged a > feature (check bugzilla for concurrent python of some sound libs from > ccrma for details, I don't have the bz# handy): It automatically > introduces silent Obsoletes ... FWIW, that particular "feature" is gone in rpm 4.4.2.1. - Panu - From bugs.michael at gmx.net Sat Jul 21 13:49:11 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 21 Jul 2007 15:49:11 +0200 Subject: foo vs. foo+ In-Reply-To: References: <1184984119.5493.15.camel@wicktop.localdomain> <200707211250.36494.ville.skytta@iki.fi> <20070721100734.GA7452@dudweiler.stuttgart.redhat.com> <200707211333.07138.ville.skytta@iki.fi> <20070721120558.GE25326@puariko.nirvana> Message-ID: <20070721154911.15d15aed.bugs.michael@gmx.net> On Sat, 21 Jul 2007 15:41:37 +0300 (EEST), Panu Matilainen wrote: > On Sat, 21 Jul 2007, Axel Thimm wrote: > > > On Sat, Jul 21, 2007 at 01:33:06PM +0300, Ville Skytt? wrote: > >> On Saturday 21 July 2007, Florian La Roche wrote: > >>> On Sat, Jul 21, 2007 at 12:50:35PM +0300, Ville Skytt? wrote: > >>>> On Saturday 21 July 2007, Patrice Dumas wrote: > >>>>> On Sat, Jul 21, 2007 at 04:15:19AM +0200, Christoph Wickert wrote: > >>>>>> Ok so far, but foo+ also needs a "Provides: foo", and I wonder if is > >>>>>> Provides: foo > >>>>>> Conflicts: foo > >>>>>> really is a good idea. And can/should we use versioned Provides: > >>>>>> here? > >>>>> > >>>>> Unless I am wrong, yum (rpm) won't care about versioned Provides:, and > >>>>> replace foo+ with foo (I had such issues with libnet10/libnet). > > > > No, that's a different bug probably. If one of the virtual provides > > was a real entity then you trigger another rpm bug that was tagged a > > feature (check bugzilla for concurrent python of some sound libs from > > ccrma for details, I don't have the bz# handy): It automatically > > introduces silent Obsoletes ... > > FWIW, that particular "feature" is gone in rpm 4.4.2.1. And packagers should still be very careful not to bring back "Provides: foo = %version-%release" for compat-packages and alternatives. It would only be a matter of time till the typical %{dist} mass-updates would reintroduce problems for the old branches. From christoph.wickert at nurfuerspam.de Sat Jul 21 14:07:17 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 21 Jul 2007 16:07:17 +0200 Subject: foo vs. foo+ In-Reply-To: <200707210947.54072.opensource@till.name> References: <1184984119.5493.15.camel@wicktop.localdomain> <200707210947.54072.opensource@till.name> Message-ID: <1185026837.3513.0.camel@wicktop.localdomain> Am Samstag, den 21.07.2007, 09:47 +0200 schrieb Till Maas: > On Saturday 21 July 2007 04:15:19 Christoph Wickert wrote: > > Imagine there are two projects: foo and foo+. foo+ is a fork, a > > different flavor of foo, but both offer the same functionality and are > > compatible for other apps that sit on top of foo(+). > > > > Now both projects want to be included in fedora. First of all, both > > packages need a Conflicts: foo conflicts foo+ and foo+ conflicts foo. > > Why do they need to conflict each other? Because their files are conflicting. They are installing to the same directories. Christoph From pmatilai at laiskiainen.org Sat Jul 21 14:18:02 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 21 Jul 2007 17:18:02 +0300 (EEST) Subject: foo vs. foo+ In-Reply-To: <20070721154911.15d15aed.bugs.michael@gmx.net> References: <1184984119.5493.15.camel@wicktop.localdomain> <200707211250.36494.ville.skytta@iki.fi> <20070721100734.GA7452@dudweiler.stuttgart.redhat.com> <200707211333.07138.ville.skytta@iki.fi> <20070721120558.GE25326@puariko.nirvana> <20070721154911.15d15aed.bugs.michael@gmx.net> Message-ID: On Sat, 21 Jul 2007, Michael Schwendt wrote: > On Sat, 21 Jul 2007 15:41:37 +0300 (EEST), Panu Matilainen wrote: > >> On Sat, 21 Jul 2007, Axel Thimm wrote: >> >>> On Sat, Jul 21, 2007 at 01:33:06PM +0300, Ville Skytt? wrote: >>>> On Saturday 21 July 2007, Florian La Roche wrote: >>>>> On Sat, Jul 21, 2007 at 12:50:35PM +0300, Ville Skytt? wrote: >>>>>> On Saturday 21 July 2007, Patrice Dumas wrote: >>>>>>> On Sat, Jul 21, 2007 at 04:15:19AM +0200, Christoph Wickert wrote: >>>>>>>> Ok so far, but foo+ also needs a "Provides: foo", and I wonder if is >>>>>>>> Provides: foo >>>>>>>> Conflicts: foo >>>>>>>> really is a good idea. And can/should we use versioned Provides: >>>>>>>> here? >>>>>>> >>>>>>> Unless I am wrong, yum (rpm) won't care about versioned Provides:, and >>>>>>> replace foo+ with foo (I had such issues with libnet10/libnet). >>> >>> No, that's a different bug probably. If one of the virtual provides >>> was a real entity then you trigger another rpm bug that was tagged a >>> feature (check bugzilla for concurrent python of some sound libs from >>> ccrma for details, I don't have the bz# handy): It automatically >>> introduces silent Obsoletes ... >> >> FWIW, that particular "feature" is gone in rpm 4.4.2.1. > > And packagers should still be very careful not to bring back "Provides: > foo = %version-%release" for compat-packages and alternatives. It would > only be a matter of time till the typical %{dist} mass-updates would > reintroduce problems for the old branches. Yup. We can easily fix F7 and FC6 rpm but EPEL is another story altogether. - Panu - From laroche at redhat.com Sat Jul 21 17:38:15 2007 From: laroche at redhat.com (Florian La Roche) Date: Sat, 21 Jul 2007 19:38:15 +0200 Subject: foo vs. foo+ In-Reply-To: <200707211411.47804.ville.skytta@iki.fi> References: <1184984119.5493.15.camel@wicktop.localdomain> <20070721100734.GA7452@dudweiler.stuttgart.redhat.com> <200707211333.07138.ville.skytta@iki.fi> <200707211411.47804.ville.skytta@iki.fi> Message-ID: <20070721173811.GA3741@dudweiler.stuttgart.redhat.com> On Sat, Jul 21, 2007 at 02:11:47PM +0300, Ville Skytt? wrote: > On Saturday 21 July 2007, Ville Skytt? wrote: > > > > rpmbuild doesn't extract the version from a fully qualified notation like > > this one. I submitted a patch for that and some other cases a long time > > ago (#61797), maybe it or parts of it should be resurrected. > > First bits done: https://bugzilla.redhat.com/249135 And already commited to rpm by Panu. Great, Florian La Roche From nphilipp at redhat.com Sat Jul 21 20:24:54 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 21 Jul 2007 22:24:54 +0200 Subject: foo vs. foo+ In-Reply-To: <1185026837.3513.0.camel@wicktop.localdomain> References: <1184984119.5493.15.camel@wicktop.localdomain> <200707210947.54072.opensource@till.name> <1185026837.3513.0.camel@wicktop.localdomain> Message-ID: <1185049494.4340.36.camel@gibraltar.stuttgart.redhat.com> On Sat, 2007-07-21 at 16:07 +0200, Christoph Wickert wrote: > Am Samstag, den 21.07.2007, 09:47 +0200 schrieb Till Maas: > > On Saturday 21 July 2007 04:15:19 Christoph Wickert wrote: > > > Imagine there are two projects: foo and foo+. foo+ is a fork, a > > > different flavor of foo, but both offer the same functionality and are > > > compatible for other apps that sit on top of foo(+). > > > > > > Now both projects want to be included in fedora. First of all, both > > > packages need a Conflicts: foo conflicts foo+ and foo+ conflicts foo. > > > > Why do they need to conflict each other? > > Because their files are conflicting. They are installing to the same > directories. They should use alternatives. 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 martin.sourada at seznam.cz Sat Jul 21 22:04:15 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 22 Jul 2007 00:04:15 +0200 Subject: Vacation Message-ID: <1185055455.8695.40.camel@pc-notebook> Hi, I am going on a vacation for a week. I'll return at next Sunday or sooner. I'll have no internet access there. I maintain gxine a xine-plugin packages, both without ACL, so if any problem arise, feel free to fix it. As for the Nodoka theme[1], Daniel Geiger wrote he's going to do some work on it; and I have submitted two package reviews [2][3] for that, so if there is someone interested in reviewing them I'll reply to your questions as soon as I'm back. Thanks, Martin References: [1] http://fedoraproject.org/wiki/Releases/Features/NodokaTheme [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248163 [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248516 -------------- 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 wolfy at nobugconsulting.ro Sat Jul 21 22:42:12 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sun, 22 Jul 2007 01:42:12 +0300 Subject: foo vs. foo+ In-Reply-To: <1185026837.3513.0.camel@wicktop.localdomain> References: <1184984119.5493.15.camel@wicktop.localdomain> <200707210947.54072.opensource@till.name> <1185026837.3513.0.camel@wicktop.localdomain> Message-ID: <46A28BC4.8050704@nobugconsulting.ro> On 07/21/2007 05:07 PM, Christoph Wickert wrote: > Am Samstag, den 21.07.2007, 09:47 +0200 schrieb Till Maas: > >> On Saturday 21 July 2007 04:15:19 Christoph Wickert wrote: >> >>> Imagine there are two projects: foo and foo+. foo+ is a fork, a >>> different flavor of foo, but both offer the same functionality and are >>> compatible for other apps that sit on top of foo(+). >>> >>> Now both projects want to be included in fedora. First of all, both >>> packages need a Conflicts: foo conflicts foo+ and foo+ conflicts foo. >>> >> Why do they need to conflict each other? >> > > Because their files are conflicting. They are installing to the same > directories. > have each one of them install in say /usr/share/foo_number1 and /usr/share/foo_number2 and create via alternatives a symlink named /usr/share/foo pointing to the one you want to activate at any given time. Handle any /etc/foo/config files similarly. Make sure you do not step on the other application's logfile either. Et voila, no more conflicts. From lemenkov at gmail.com Sun Jul 22 06:38:06 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sun, 22 Jul 2007 10:38:06 +0400 Subject: FUSE package changed its _exec_prefix Message-ID: Hello All! A little note - subj due to very popular demand from users of NTFS-3G. If someone used full paths to fusermount he should change it from /usr/bin/fusermount to /bin/fusermount Looks like its a trivial and harmless change. -- With best regards! From Axel.Thimm at ATrpms.net Sun Jul 22 11:55:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 22 Jul 2007 13:55:55 +0200 Subject: foo vs. foo+ In-Reply-To: References: <1184984119.5493.15.camel@wicktop.localdomain> <200707211250.36494.ville.skytta@iki.fi> <20070721100734.GA7452@dudweiler.stuttgart.redhat.com> <200707211333.07138.ville.skytta@iki.fi> <20070721120558.GE25326@puariko.nirvana> Message-ID: <20070722115555.GJ5244@puariko.nirvana> On Sat, Jul 21, 2007 at 03:41:37PM +0300, Panu Matilainen wrote: > On Sat, 21 Jul 2007, Axel Thimm wrote: > >No, that's a different bug probably. If one of the virtual provides > >was a real entity then you trigger another rpm bug that was tagged a > >feature (check bugzilla for concurrent python of some sound libs from > >ccrma for details, I don't have the bz# handy): It automatically > >introduces silent Obsoletes ... > > FWIW, that particular "feature" is gone in rpm 4.4.2.1. Now that's what I call good news! :) Wonder if this mis-feature removal could ever make it into RHEL. After all it did break many sane assumptions of a couple ISVs 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 Axel.Thimm at ATrpms.net Sun Jul 22 11:57:33 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 22 Jul 2007 13:57:33 +0200 Subject: FUSE package changed its _exec_prefix In-Reply-To: References: Message-ID: <20070722115733.GK5244@puariko.nirvana> On Sun, Jul 22, 2007 at 10:38:06AM +0400, Peter Lemenkov wrote: > Hello All! > A little note - subj due to very popular demand from users of NTFS-3G. > If someone used full paths to fusermount he should change it from > /usr/bin/fusermount to /bin/fusermount > > Looks like its a trivial and harmless change. How about creating compatibility symlinks in %{_bindir} to not break user scripts? -- 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 Sun Jul 22 12:37:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 22 Jul 2007 14:37:13 +0200 Subject: EPEL report week 29 2007 Message-ID: <46A34F79.2030000@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week29 = Weekly EPEL Summary = Week 29/2007 == Most important happenings == * RH will plans to add stuff that is part of the EL5Client (like python-imaging) to the Channels for EL5Server; that should solve most of our problem on that topic == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * Jeff_S (Jeff Sheltren) (had to leave after half the meeting) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) (had to leave early) * quiad (KarstenWade) * stahnma (MichaelStahnke) Missing from the Steering Committee: * knurd (ThorstenLeemhuis) Others that participated the meeting: === Summary === * broken Deps - Jeff_S * still lots of broken deps * nirik> I've found that if you mail maintainers direct with a solution, most of them will do something... I can try and do that some in the next few days. * more on the list * branch for EPEL if Fedora Maintainer does not react * https://www.redhat.com/archives/epel-devel-list/2007-July/msg00104.html not yet ratified as tehre were not enough people to vote * early end of meeting due to the latter fact === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-July/msg00164.html == Stats == === General === Number of EPEL Contributors 112 We welcome 2 new contributors: kwizart_AT_gmail.com, mattdm_AT_mattdm.org === EPEL 5 === Number of source packages: 469 Number of binary packages: 853 There are 7 new Packages: * cacti | An rrd based graphing tool * ctapi-common | Common files and packaging infrastructure for CT-API modules * ftgl | OpenGL frontend to Freetype 2 * goffice | Goffice support libraries * iksemel | An XML parser library designed for Jabber applications * logserial | Package for logging incoming bytes on asynchronous serial ports * rdiff-backup | Convenient and transparent local/remote incremental mirror/backup * tachyon | Parallel / Multiprocessor Ray Tracing System === EPEL 4 === Number of source packages: 289 Number of binary packages: 596 There are 5 new Packages: * ctapi-common | Common files and packaging infrastructure for CT-API modules * iksemel | An XML parser library designed for Jabber applications * logserial | Package for logging incoming bytes on asynchronous serial ports * rdiff-backup | Convenient and transparent local/remote incremental mirror/backup * tachyon | Parallel / Multiprocessor Ray Tracing System ---- ["CategoryEPELReports"] From Axel.Thimm at ATrpms.net Sun Jul 22 13:39:54 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 22 Jul 2007 15:39:54 +0200 Subject: Procedure for verbatim takeover from FN to FN+1? Message-ID: <20070722133954.GA18042@puariko.nirvana> We have this somewhere in the wiki, but it is not easy to be found, so admitting my failure in searching, who is as kind as to point me to it? Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From christoph.wickert at nurfuerspam.de Sun Jul 22 13:40:54 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sun, 22 Jul 2007 15:40:54 +0200 Subject: foo vs. foo+ In-Reply-To: <1185049494.4340.36.camel@gibraltar.stuttgart.redhat.com> References: <1184984119.5493.15.camel@wicktop.localdomain> <200707210947.54072.opensource@till.name> <1185026837.3513.0.camel@wicktop.localdomain> <1185049494.4340.36.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1185111654.3687.10.camel@wicktop.localdomain> Am Samstag, den 21.07.2007, 22:24 +0200 schrieb Nils Philippsen: > On Sat, 2007-07-21 at 16:07 +0200, Christoph Wickert wrote: > > Am Samstag, den 21.07.2007, 09:47 +0200 schrieb Till Maas: > > > On Saturday 21 July 2007 04:15:19 Christoph Wickert wrote: > > > > Imagine there are two projects: foo and foo+. foo+ is a fork, a > > > > different flavor of foo, but both offer the same functionality and are > > > > compatible for other apps that sit on top of foo(+). > > > > > > > > Now both projects want to be included in fedora. First of all, both > > > > packages need a Conflicts: foo conflicts foo+ and foo+ conflicts foo. > > > > > > Why do they need to conflict each other? > > > > Because their files are conflicting. They are installing to the same > > directories. > > They should use alternatives. This would require major changes to the codebase, because nearly _everything_ (libs, man pages etc) is conflicting. Also I'm not sure if any of the developers is willing to mke the required changes as foo+ is kind of foo's upstream. This is not a theoretical example, this is real live: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188542 especially comments #32,33, 35 and 38 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188542#c32 Chris From j.w.r.degoede at hhs.nl Sun Jul 22 14:14:42 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 22 Jul 2007 16:14:42 +0200 Subject: headsup: rawhide gkrellm updated to 2.3.0 Message-ID: <46A36652.9010806@hhs.nl> Hi all, In 1 or 2 days gkrellm-2.3.0 should show up rawhide. This is a headsup for any gkrellm plugin maintainers. From 2.2.x > 2.3.0 the plugin API has not changed so a rebuild is _not_ necessary. Except that in 2.2.x the private variable gkrellm_monitor_list was accidentally exported to plugins, and that is fixed now. I checked all plugins currently in Fedora and as expected none use this variable, so that is not a problem. Regards, Hans From j.w.r.degoede at hhs.nl Sun Jul 22 14:19:17 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 22 Jul 2007 16:19:17 +0200 Subject: Procedure for verbatim takeover from FN to FN+1? In-Reply-To: <20070722133954.GA18042@puariko.nirvana> References: <20070722133954.GA18042@puariko.nirvana> Message-ID: <46A36765.5030700@hhs.nl> Axel Thimm wrote: > We have this somewhere in the wiki, but it is not easy to be found, so > admitting my failure in searching, who is as kind as to point me to > it? Thanks! > I would love yo help you, but I do not understand what you mean with "Procedure for verbatim takeover from FN to FN+1", can you be a bit more verbose? Regards, Hans From lightsolphoenix at gmail.com Sun Jul 22 15:04:59 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sun, 22 Jul 2007 11:04:59 -0400 Subject: foo vs. foo+ In-Reply-To: <1184984119.5493.15.camel@wicktop.localdomain> References: <1184984119.5493.15.camel@wicktop.localdomain> Message-ID: <200707221104.59426.lightsolphoenix@gmail.com> On Friday, July 20, 2007 10:15 pm Christoph Wickert wrote: > Provides: foo > Conflicts: foo I was under the impression that Provides: implies Conflicts:... -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From Axel.Thimm at ATrpms.net Sun Jul 22 15:39:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 22 Jul 2007 17:39:59 +0200 Subject: Procedure for verbatim takeover from FN to FN+1? In-Reply-To: <46A36765.5030700@hhs.nl> References: <20070722133954.GA18042@puariko.nirvana> <46A36765.5030700@hhs.nl> Message-ID: <20070722153959.GA18458@puariko.nirvana> On Sun, Jul 22, 2007 at 04:19:17PM +0200, Hans de Goede wrote: > Axel Thimm wrote: > >We have this somewhere in the wiki, but it is not easy to be found, so > >admitting my failure in searching, who is as kind as to point me to > >it? Thanks! > > > > I would love yo help you, but I do not understand what you mean with > "Procedure for verbatim takeover from FN to FN+1", can you be a bit more > verbose? Inherit a package from FC6 into F7 (and later) w/o having to rebuild it, e.g. no waste of dist/mirror space for large data-only packages. I know it has been done before for a couple of packages (texmf trees for example?). Anything that is a firmware or pure data (e.g. dist-agnostic) is a candidate for this, but currently being a manual procedure it is only worth while for bulkier bits. -- 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 luya at fedoraproject.org Sun Jul 22 17:38:15 2007 From: luya at fedoraproject.org (Luya Tshimbalanga) Date: Sun, 22 Jul 2007 10:38:15 -0700 Subject: Moving Echo icons to a better host? hosted.fedoraproject.org? In-Reply-To: <46A2FE8A.5090809@fedoraproject.org> References: <1185085634.46a2f8c2ce852@ssl.mecca.ca> <46A2FE8A.5090809@fedoraproject.org> Message-ID: <46A39607.7040002@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rahul Sundaram a ?crit : > > Yes. IMO hosted is a much better place for the icons. > > Rahul > I initially planned to host echo-icons on luya.fedorapeople.org but I realize allowing uploading from other contributors will be more difficult. What I am looking for is a host that supports the existing fedoraproject.org account which leads to hosted.fedoraproject.org on Infrastructure wiki. Unfortunately, I could not find any details about requesting a host on Fedora Infrastructure. Could anyone provide assistance? Luya -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGo5YFa10Jb0NOz+ERAtlSAJ94Z/YYyNL9N2gSs22Brc0nDhHUqQCfcY8c uLq2bJJq8I08UdGs9UMeIpk= =IYya -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Sun Jul 22 18:00:39 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 22 Jul 2007 20:00:39 +0200 Subject: gkrellm license change notificaition Message-ID: <46A39B47.6040009@hhs.nl> Hi all, For those who want to know, gkrellm has moved to GPL v3, coming from GPL v2 Regards, Hans From mmcgrath at redhat.com Sun Jul 22 18:17:02 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 22 Jul 2007 13:17:02 -0500 Subject: Moving Echo icons to a better host? hosted.fedoraproject.org? In-Reply-To: <46A39607.7040002@fedoraproject.org> References: <1185085634.46a2f8c2ce852@ssl.mecca.ca> <46A2FE8A.5090809@fedoraproject.org> <46A39607.7040002@fedoraproject.org> Message-ID: <46A39F1E.4070807@redhat.com> Luya Tshimbalanga wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rahul Sundaram a ?crit : > >> Yes. IMO hosted is a much better place for the icons. >> >> Rahul >> >> > I initially planned to host echo-icons on luya.fedorapeople.org but I > realize allowing uploading from other contributors will be more > difficult. What I am looking for is a host that supports the existing > fedoraproject.org account which leads to hosted.fedoraproject.org on > Infrastructure wiki. > > Unfortunately, I could not find any details about requesting a host on > Fedora Infrastructure. Could anyone provide assistance? > Technically hosted is still in beta. Though that should be changing very soon. On a side note, you should be able to chgrp +w art on fedorapeople.org. This will allow you to give write access to whatever you want to the art group. All groups in the fedora account system are created and populated on fedorapeople.org -Mike From ville.skytta at iki.fi Sun Jul 22 18:24:24 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 22 Jul 2007 21:24:24 +0300 Subject: gkrellm license change notificaition In-Reply-To: <46A39B47.6040009@hhs.nl> References: <46A39B47.6040009@hhs.nl> Message-ID: <200707222124.24902.ville.skytta@iki.fi> On Sunday 22 July 2007, Hans de Goede wrote: > For those who want to know, gkrellm has moved to GPL v3, coming from GPL v2 What implications does this have on gkrellm plugins, most of which I think are currently "GPL v2 or later"? From j.w.r.degoede at hhs.nl Sun Jul 22 18:41:30 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 22 Jul 2007 20:41:30 +0200 Subject: gkrellm license change notificaition In-Reply-To: <200707222124.24902.ville.skytta@iki.fi> References: <46A39B47.6040009@hhs.nl> <200707222124.24902.ville.skytta@iki.fi> Message-ID: <46A3A4DA.90503@hhs.nl> Ville Skytt? wrote: > On Sunday 22 July 2007, Hans de Goede wrote: > >> For those who want to know, gkrellm has moved to GPL v3, coming from GPL v2 > > What implications does this have on gkrellm plugins, most of which I think are > currently "GPL v2 or later"? > IANAL, but I guess that when used with the latest gkrellm they have just become GPL v3 or later. Regards, Hans From ville.skytta at iki.fi Sun Jul 22 18:46:38 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 22 Jul 2007 21:46:38 +0300 Subject: gkrellm license change notificaition In-Reply-To: <46A3A4DA.90503@hhs.nl> References: <46A39B47.6040009@hhs.nl> <200707222124.24902.ville.skytta@iki.fi> <46A3A4DA.90503@hhs.nl> Message-ID: <200707222146.39061.ville.skytta@iki.fi> On Sunday 22 July 2007, Hans de Goede wrote: > Ville Skytt? wrote: > > On Sunday 22 July 2007, Hans de Goede wrote: > >> For those who want to know, gkrellm has moved to GPL v3, coming from GPL > >> v2 > > > > What implications does this have on gkrellm plugins, most of which I > > think are currently "GPL v2 or later"? > > IANAL, but I guess that when used with the latest gkrellm they have just > become GPL v3 or later. In that case, do packagers need to do something about the v2+ copyright notices included in the plugin packages or embedded in their code? From j.w.r.degoede at hhs.nl Sun Jul 22 18:51:13 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 22 Jul 2007 20:51:13 +0200 Subject: gkrellm license change notificaition In-Reply-To: <200707222146.39061.ville.skytta@iki.fi> References: <46A39B47.6040009@hhs.nl> <200707222124.24902.ville.skytta@iki.fi> <46A3A4DA.90503@hhs.nl> <200707222146.39061.ville.skytta@iki.fi> Message-ID: <46A3A721.2040803@hhs.nl> Ville Skytt? wrote: > On Sunday 22 July 2007, Hans de Goede wrote: >> Ville Skytt? wrote: >>> On Sunday 22 July 2007, Hans de Goede wrote: >>>> For those who want to know, gkrellm has moved to GPL v3, coming from GPL >>>> v2 >>> What implications does this have on gkrellm plugins, most of which I >>> think are currently "GPL v2 or later"? >> IANAL, but I guess that when used with the latest gkrellm they have just >> become GPL v3 or later. > > In that case, do packagers need to do something about the v2+ copyright > notices included in the plugin packages or embedded in their code? > That I really don't know, let the baord / fesco figure this out and tell us all what todo. Regards, Hans From tmz at pobox.com Sun Jul 22 19:04:18 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 22 Jul 2007 15:04:18 -0400 Subject: gkrellm license change notificaition In-Reply-To: <200707222146.39061.ville.skytta@iki.fi> References: <46A39B47.6040009@hhs.nl> <200707222124.24902.ville.skytta@iki.fi> <46A3A4DA.90503@hhs.nl> <200707222146.39061.ville.skytta@iki.fi> Message-ID: <20070722190418.GB24858@psilocybe.teonanacatl.org> Ville Skytt? wrote: > On Sunday 22 July 2007, Hans de Goede wrote: >> Ville Skytt? wrote: >>> On Sunday 22 July 2007, Hans de Goede wrote: >>>> For those who want to know, gkrellm has moved to GPL v3, coming >>>> from GPL v2 >>> >>> What implications does this have on gkrellm plugins, most of which >>> I think are currently "GPL v2 or later"? >> >> IANAL, but I guess that when used with the latest gkrellm they have >> just become GPL v3 or later. > > In that case, do packagers need to do something about the v2+ > copyright notices included in the plugin packages or embedded in > their code? If the copyright notice includes the text (or something similar): "This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version." Then wouldn't it already be covered? Changing it to something like "version 3 of the License, or (at your option) any later version" would seem wrong to me, as it would place a limitation on the end-user that wasn't intended by the copyright holder (and a limitation that AFAIK isn't needed by Fedora in order to distribute the package). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Left to Her own devices, nature cures stupidity. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From ville.skytta at iki.fi Sun Jul 22 19:12:22 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 22 Jul 2007 22:12:22 +0300 Subject: gkrellm license change notificaition In-Reply-To: <20070722190418.GB24858@psilocybe.teonanacatl.org> References: <46A39B47.6040009@hhs.nl> <200707222146.39061.ville.skytta@iki.fi> <20070722190418.GB24858@psilocybe.teonanacatl.org> Message-ID: <200707222212.22699.ville.skytta@iki.fi> On Sunday 22 July 2007, Todd Zullinger wrote: > Ville Skytt? wrote: > > On Sunday 22 July 2007, Hans de Goede wrote: > >> Ville Skytt? wrote: > >>> On Sunday 22 July 2007, Hans de Goede wrote: > >>>> For those who want to know, gkrellm has moved to GPL v3, coming > >>>> from GPL v2 > >>> > >>> What implications does this have on gkrellm plugins, most of which > >>> I think are currently "GPL v2 or later"? > >> > >> IANAL, but I guess that when used with the latest gkrellm they have > >> just become GPL v3 or later. > > > > In that case, do packagers need to do something about the v2+ > > copyright notices included in the plugin packages or embedded in > > their code? > > If the copyright notice includes the text (or something similar): > > "This program is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 2 of the License, or (at > your option) any later version." > > Then wouldn't it already be covered? Dunno. When combined with v3 work (which I gather is what happens when one compiles a gkrellm plugin against the new v3 gkrellm), it would seem to me that the result is no longer distributable as v2. If that's the case, saying "v2 or later" in the copyright notices bundled with the distributable doesn't sound right to me. From tmz at pobox.com Sun Jul 22 19:25:27 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 22 Jul 2007 15:25:27 -0400 Subject: gkrellm license change notificaition In-Reply-To: <200707222212.22699.ville.skytta@iki.fi> References: <46A39B47.6040009@hhs.nl> <200707222146.39061.ville.skytta@iki.fi> <20070722190418.GB24858@psilocybe.teonanacatl.org> <200707222212.22699.ville.skytta@iki.fi> Message-ID: <20070722192527.GC24858@psilocybe.teonanacatl.org> Ville Skytt? wrote: > Dunno. When combined with v3 work (which I gather is what happens > when one compiles a gkrellm plugin against the new v3 gkrellm), it > would seem to me that the result is no longer distributable as v2. > If that's the case, saying "v2 or later" in the copyright notices > bundled with the distributable doesn't sound right to me. Why not? I think it seems reasonable. The author of the plugin has expressed in the copyright notice that their code may be used under the terms of v2 or later. If Fedora ships this for use with a v3 gkrellm, the "or later version" covers that distribution. If, for some reason, an end user wants to take the code from that plugin and put it to use with some v2 code, that isn't something that Fedora should be preventing by changing the copyright notices that the author has put in place. (I suppose I should make it clear that IANAL and these are just my opinions. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Bureaucracy is the enemy of innovation. -- Mark Shepherd, former President and CEO of Texas Instruments -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From ville.skytta at iki.fi Sun Jul 22 19:30:02 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 22 Jul 2007 22:30:02 +0300 Subject: gkrellm license change notificaition In-Reply-To: <20070722192527.GC24858@psilocybe.teonanacatl.org> References: <46A39B47.6040009@hhs.nl> <200707222212.22699.ville.skytta@iki.fi> <20070722192527.GC24858@psilocybe.teonanacatl.org> Message-ID: <200707222230.03149.ville.skytta@iki.fi> On Sunday 22 July 2007, Todd Zullinger wrote: > Ville Skytt? wrote: > > Dunno. When combined with v3 work (which I gather is what happens > > when one compiles a gkrellm plugin against the new v3 gkrellm), it > > would seem to me that the result is no longer distributable as v2. > > If that's the case, saying "v2 or later" in the copyright notices > > bundled with the distributable doesn't sound right to me. > > Why not? I think it seems reasonable. If the result is not distributable as v2 it is reasonable for us to say "v2 or later"? Note that "v2 or later" includes v2. Well, enough noise, let's just see what the board/legal/FESCO has to say about this. From Axel.Thimm at ATrpms.net Sun Jul 22 19:39:16 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 22 Jul 2007 21:39:16 +0200 Subject: gkrellm license change notificaition In-Reply-To: <46A3A4DA.90503@hhs.nl> References: <46A39B47.6040009@hhs.nl> <200707222124.24902.ville.skytta@iki.fi> <46A3A4DA.90503@hhs.nl> Message-ID: <20070722193916.GD11686@puariko.nirvana> On Sun, Jul 22, 2007 at 08:41:30PM +0200, Hans de Goede wrote: > Ville Skytt? wrote: > >On Sunday 22 July 2007, Hans de Goede wrote: > > > >>For those who want to know, gkrellm has moved to GPL v3, coming from GPL > >>v2 > > > >What implications does this have on gkrellm plugins, most of which I think > >are currently "GPL v2 or later"? > > > > IANAL, but I guess that when used with the latest gkrellm they have just > become GPL v3 or later. If they say GPL>=2 all if fine, they get progated to GPL3 as a whole. The trouble is if they say GPL==2. IOW GPL==2 and GPL3 are incompatible. But the default license wording was GPL>=2, so most GPL2 software is really GPL>=2. But one needs to check nonetheless. Maybe the folks (tibbs? spot?) that wanted to purify the license tag should differentiate between GPL==2 and GPL>=2 in the rpm tag somehow. Don't know what the status of that project is though. -- 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 Sun Jul 22 19:58:09 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 22 Jul 2007 21:58:09 +0200 Subject: Want to trade reviews? Message-ID: <46A3B6D1.9050203@hhs.nl> Hi all, Have a review thats taking longer then you want? I know how that feels. So I'm looking for people who want to trade reviews with me, you review a package of mine and I'll review one of you. There is plenty of choice just claim one by assigning the ticket to you and let me know which package you want me to review in return: * arm-gp2x-linux-binutils Cross Compiling GNU binutils targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234749 * arm-gp2x-linux-kernel-headers Kernel headers for Cross Compiling to arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242203 * arm-gp2x-linux-gcc Cross Compiling GNU GCC targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242206 * arm-gp2x-linux-glibc Cross Compiled GNU C Library targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242207 * arm-gp2x-linux-SDL Cross Compiled SDL Library targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243147 * arm-gp2x-linux-zlib Cross Compiled zlib Library targeted at avr https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243254 * cdogs-sdl C-Dogs is an arcade shoot-em-up https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248511 * cdogs-date Data files for the C-Dogs game https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248513 * Alien Blaster 2d top-down shoot'em up https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249214 * Wildmidi soft midi wavetable synth lib (needed to add midi playback to gstreamer) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248597 * libXNVCtrl Library that provides the nvidia NV-CONTROL API https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248291 * libtimdity soft midi wavetable synth lib (needed to add midi playback to gstreamer) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248119 Thanks & Regards, Hans From cr33dog at gmail.com Sun Jul 22 20:09:05 2007 From: cr33dog at gmail.com (Chris Mohler) Date: Sun, 22 Jul 2007 15:09:05 -0500 Subject: Want to trade reviews? In-Reply-To: <46A3B6D1.9050203@hhs.nl> References: <46A3B6D1.9050203@hhs.nl> Message-ID: On 7/22/07, Hans de Goede wrote: > Hi all, > > Have a review thats taking longer then you want? I know how that feels. So I'm > looking for people who want to trade reviews with me, you review a package of > mine and I'll review one of you. FWIW, I'm looking over cdogs/cdogs data right now, but I'm a little rusty (and only maintain one package ATM). Chris From kwizart at gmail.com Sun Jul 22 20:15:04 2007 From: kwizart at gmail.com (KH KH) Date: Sun, 22 Jul 2007 22:15:04 +0200 Subject: Want to trade reviews? In-Reply-To: <46A3B6D1.9050203@hhs.nl> References: <46A3B6D1.9050203@hhs.nl> Message-ID: 2007/7/22, Hans de Goede : > Hi all, > > Have a review thats taking longer then you want? I know how that feels. So I'm > looking for people who want to trade reviews with me, you review a package of > mine and I'll review one of you. > > There is plenty of choice just claim one by assigning the ticket to you and let > me know which package you want me to review in return: > > * arm-gp2x-linux-binutils > Cross Compiling GNU binutils targeted at arm-gp2x-linux > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234749 > > * arm-gp2x-linux-kernel-headers > Kernel headers for Cross Compiling to arm-gp2x-linux > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242203 > > * arm-gp2x-linux-gcc > Cross Compiling GNU GCC targeted at arm-gp2x-linux > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242206 > > * arm-gp2x-linux-glibc > Cross Compiled GNU C Library targeted at arm-gp2x-linux > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242207 > > * arm-gp2x-linux-SDL > Cross Compiled SDL Library targeted at arm-gp2x-linux > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243147 > > * arm-gp2x-linux-zlib > Cross Compiled zlib Library targeted at avr > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243254 > > * cdogs-sdl > C-Dogs is an arcade shoot-em-up > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248511 > > * cdogs-date > Data files for the C-Dogs game > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248513 > > * Alien Blaster > 2d top-down shoot'em up > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249214 > > * Wildmidi > soft midi wavetable synth lib (needed to add midi playback to gstreamer) > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248597 > > * libXNVCtrl > Library that provides the nvidia NV-CONTROL API > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248291 I take this, as oyranos seems to link with it, to set color profiles... Nicolas (kwizart) > * libtimdity > soft midi wavetable synth lib (needed to add midi playback to gstreamer) > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248119 > > Thanks & Regards, > > Hans > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From luya_tfz at thefinalzone.com Sun Jul 22 20:23:25 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Sun, 22 Jul 2007 13:23:25 -0700 Subject: Moving Echo icons to a better host? hosted.fedoraproject.org? In-Reply-To: <46A39F1E.4070807@redhat.com> References: <1185085634.46a2f8c2ce852@ssl.mecca.ca> <46A2FE8A.5090809@fedoraproject.org> <46A39607.7040002@fedoraproject.org> <46A39F1E.4070807@redhat.com> Message-ID: <46A3BCBD.5040606@thefinalzone.com> Mike McGrath a ?crit : > Luya Tshimbalanga wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Rahul Sundaram a ?crit : >> >>> Yes. IMO hosted is a much better place for the icons. >>> >>> Rahul >>> >>> >> I initially planned to host echo-icons on luya.fedorapeople.org but I >> realize allowing uploading from other contributors will be more >> difficult. What I am looking for is a host that supports the existing >> fedoraproject.org account which leads to hosted.fedoraproject.org on >> Infrastructure wiki. >> >> Unfortunately, I could not find any details about requesting a host on >> Fedora Infrastructure. Could anyone provide assistance? >> > > Technically hosted is still in beta. Though that should be changing > very soon. > > On a side note, you should be able to chgrp +w art on > fedorapeople.org. This will allow you to give write access to > whatever you want to the art group. All groups in the fedora account > system are created and populated on fedorapeople.org > > Thank you. I have started to gradually migrate echo-icon to my fedorapeople.org. It will take a while to fully grab all png and svg since wget does not support php sublink like action=target for example. Luya From alan at redhat.com Mon Jul 23 09:43:53 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Jul 2007 05:43:53 -0400 Subject: gkrellm license change notificaition In-Reply-To: <200707222212.22699.ville.skytta@iki.fi> References: <46A39B47.6040009@hhs.nl> <200707222146.39061.ville.skytta@iki.fi> <20070722190418.GB24858@psilocybe.teonanacatl.org> <200707222212.22699.ville.skytta@iki.fi> Message-ID: <20070723094353.GB25156@devserv.devel.redhat.com> On Sun, Jul 22, 2007 at 10:12:22PM +0300, Ville Skytt? wrote: > Dunno. When combined with v3 work (which I gather is what happens when one > compiles a gkrellm plugin against the new v3 gkrellm), it would seem to me > that the result is no longer distributable as v2. If that's the case, > saying "v2 or later" in the copyright notices bundled with the distributable > doesn't sound right to me. You can still use the plugin with the v2 version so the copyright notice is correct. From jkeating at redhat.com Mon Jul 23 13:36:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 09:36:52 -0400 Subject: Procedure for verbatim takeover from FN to FN+1? In-Reply-To: <20070722153959.GA18458@puariko.nirvana> References: <20070722133954.GA18042@puariko.nirvana> <46A36765.5030700@hhs.nl> <20070722153959.GA18458@puariko.nirvana> Message-ID: <20070723093652.5af97e10@localhost.localdomain> On Sun, 22 Jul 2007 17:39:59 +0200 Axel Thimm wrote: > Inherit a package from FC6 into F7 (and later) w/o having to rebuild > it, e.g. no waste of dist/mirror space for large data-only packages. I > know it has been done before for a couple of packages (texmf trees for > example?). Anything that is a firmware or pure data > (e.g. dist-agnostic) is a candidate for this, but currently being a > manual procedure it is only worth while for bulkier bits. A) You must not have any build of that package tagged for later collections. B) Build in the earliest collection still active C) Once pushed as a stable update, future collections will inherit the build, provided no other build has been tagged in the future collections. Using 'list-tag-inheritance' should shed some light on this: $ koji list-tag-inheritance dist-f8 dist-f8 (12) ??dist-fc7-updates (14) ??dist-fc7 (5) ??fe7-merge (11) ??dist-fc6-updates (2) ??dist-fc6 (1) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Jul 23 14:14:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 23 Jul 2007 16:14:01 +0200 Subject: Procedure for verbatim takeover from FN to FN+1? In-Reply-To: <20070723093652.5af97e10@localhost.localdomain> References: <20070722133954.GA18042@puariko.nirvana> <46A36765.5030700@hhs.nl> <20070722153959.GA18458@puariko.nirvana> <20070723093652.5af97e10@localhost.localdomain> Message-ID: <20070723141401.GB14065@puariko.nirvana> On Mon, Jul 23, 2007 at 09:36:52AM -0400, Jesse Keating wrote: > On Sun, 22 Jul 2007 17:39:59 +0200 > Axel Thimm wrote: > > > Inherit a package from FC6 into F7 (and later) w/o having to rebuild > > it, e.g. no waste of dist/mirror space for large data-only packages. I > > know it has been done before for a couple of packages (texmf trees for > > example?). Anything that is a firmware or pure data > > (e.g. dist-agnostic) is a candidate for this, but currently being a > > manual procedure it is only worth while for bulkier bits. > > A) You must not have any build of that package tagged for later > collections. OK > B) Build in the earliest collection still active OK > C) Once pushed as a stable update, future collections will inherit the > build, provided no other build has been tagged in the future > collections. Well, I don't see the package in question (vtkdata) anywhere else than where I pushed it into. At any rate could you please wave your magic wand and make that appear in F7 and F8? Thanks! > Using 'list-tag-inheritance' should shed some light on this: > > $ koji list-tag-inheritance dist-f8 > dist-f8 (12) > ??dist-fc7-updates (14) > ??dist-fc7 (5) > ??fe7-merge (11) > ??dist-fc6-updates (2) > ??dist-fc6 (1) > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Jul 23 14:18:24 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Jul 2007 10:18:24 -0400 Subject: FUSE package changed its _exec_prefix In-Reply-To: <20070722115733.GK5244@puariko.nirvana> References: <20070722115733.GK5244@puariko.nirvana> Message-ID: <20070723141824.GI15831@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > On Sun, Jul 22, 2007 at 10:38:06AM +0400, Peter Lemenkov wrote: > > Hello All! > > A little note - subj due to very popular demand from users of NTFS-3G. > > If someone used full paths to fusermount he should change it from > > /usr/bin/fusermount to /bin/fusermount > > > > Looks like its a trivial and harmless change. > > How about creating compatibility symlinks in %{_bindir} to not break > user scripts? Especially if the new package is going to be pushed back to any prior releases. Bill From notting at redhat.com Mon Jul 23 14:21:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Jul 2007 10:21:03 -0400 Subject: gkrellm license change notificaition In-Reply-To: <46A39B47.6040009@hhs.nl> References: <46A39B47.6040009@hhs.nl> Message-ID: <20070723142103.GJ15831@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > For those who want to know, gkrellm has moved to GPL v3, coming from GPL v2 Are *ANY* of the plugins that use it, even the ones we do not ship, licensed under only GPL2? If so, we really can't push this on earlier releases. Bill From jkeating at redhat.com Mon Jul 23 14:24:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 10:24:41 -0400 Subject: Procedure for verbatim takeover from FN to FN+1? In-Reply-To: <20070723141401.GB14065@puariko.nirvana> References: <20070722133954.GA18042@puariko.nirvana> <46A36765.5030700@hhs.nl> <20070722153959.GA18458@puariko.nirvana> <20070723093652.5af97e10@localhost.localdomain> <20070723141401.GB14065@puariko.nirvana> Message-ID: <20070723102441.76e80760@localhost.localdomain> On Mon, 23 Jul 2007 16:14:01 +0200 Axel Thimm wrote: > Well, I don't see the package in question (vtkdata) anywhere else than > where I pushed it into. > > At any rate could you please wave your magic wand and make that appear > in F7 and F8? Thanks! Erm, where did you push it to? The inheritance only works within Koji, so f7 would be the entry point. Once it went out as a stable F7 update, it would automatically show up in the next rawhide push. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Mon Jul 23 14:36:00 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 23 Jul 2007 15:36:00 +0100 Subject: Procedure for verbatim takeover from FN to FN+1? In-Reply-To: <20070723093652.5af97e10@localhost.localdomain> References: <20070722133954.GA18042@puariko.nirvana> <46A36765.5030700@hhs.nl> <20070722153959.GA18458@puariko.nirvana> <20070723093652.5af97e10@localhost.localdomain> Message-ID: <46A4BCD0.300@city-fan.org> Jesse Keating wrote: > On Sun, 22 Jul 2007 17:39:59 +0200 > Axel Thimm wrote: > >> Inherit a package from FC6 into F7 (and later) w/o having to rebuild >> it, e.g. no waste of dist/mirror space for large data-only packages. I >> know it has been done before for a couple of packages (texmf trees for >> example?). Anything that is a firmware or pure data >> (e.g. dist-agnostic) is a candidate for this, but currently being a >> manual procedure it is only worth while for bulkier bits. > > A) You must not have any build of that package tagged for later > collections. > > B) Build in the earliest collection still active > > C) Once pushed as a stable update, future collections will inherit the > build, provided no other build has been tagged in the future > collections. > > Using 'list-tag-inheritance' should shed some light on this: > > $ koji list-tag-inheritance dist-f8 > dist-f8 (12) > ??dist-fc7-updates (14) > ??dist-fc7 (5) > ??fe7-merge (11) > ??dist-fc6-updates (2) > ??dist-fc6 (1) So supposing a package is buildt for dist-fc6-updates and nowhere else. The current state of play is that it "appears" in the repos for all subsequent releases, which is good. But what happens when FC^ is EOL-ed? Will it then be necessary to build the package for one of the later tags, somewhat defeating the object of the exercise? Paul. From j.w.r.degoede at hhs.nl Mon Jul 23 14:37:43 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 23 Jul 2007 16:37:43 +0200 Subject: gkrellm license change notificaition In-Reply-To: <20070723142103.GJ15831@nostromo.devel.redhat.com> References: <46A39B47.6040009@hhs.nl> <20070723142103.GJ15831@nostromo.devel.redhat.com> Message-ID: <46A4BD37.6030008@hhs.nl> Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: >> For those who want to know, gkrellm has moved to GPL v3, coming from GPL v2 > > Are *ANY* of the plugins that use it, even the ones we do not ship, licensed > under only GPL2? I don't know, wouldn't that be an additional requirement over the conditons for gkrellm itself, and thus a license violation? > If so, we really can't push this on earlier releases. I'm not planning on pushing it to anything earlier then rawhide. But if the need arises for any reason I will first check the license of all the plugins we ship. Regards, Hans From jkeating at redhat.com Mon Jul 23 14:44:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 10:44:29 -0400 Subject: Procedure for verbatim takeover from FN to FN+1? In-Reply-To: <46A4BCD0.300@city-fan.org> References: <20070722133954.GA18042@puariko.nirvana> <46A36765.5030700@hhs.nl> <20070722153959.GA18458@puariko.nirvana> <20070723093652.5af97e10@localhost.localdomain> <46A4BCD0.300@city-fan.org> Message-ID: <20070723104429.371fdada@localhost.localdomain> On Mon, 23 Jul 2007 15:36:00 +0100 Paul Howarth wrote: > So supposing a package is buildt for dist-fc6-updates and nowhere > else. The current state of play is that it "appears" in the repos for > all subsequent releases, which is good. But what happens when FC^ is > EOL-ed? Will it then be necessary to build the package for one of the > later tags, somewhat defeating the object of the exercise? I'll admit that this inheritance chain is a bit misleading. The FC6 tags are merely sync tags, not active. The real entry point is dist-fc7, the active point being dist-fc7-updates. However to answer your question, once a release is EOL you can't do a build on that tag, but that doesn't break inheritance. It just means that the next time you have to update the package, you update it on the oldest active branch and build it there. Inheritance will make sure that it is available in all future tags. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Jul 23 14:46:13 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Jul 2007 10:46:13 -0400 Subject: gkrellm license change notificaition In-Reply-To: <20070723142103.GJ15831@nostromo.devel.redhat.com> References: <46A39B47.6040009@hhs.nl> <20070723142103.GJ15831@nostromo.devel.redhat.com> Message-ID: <20070723144613.GL15831@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > For those who want to know, gkrellm has moved to GPL v3, coming from GPL v2 > > Are *ANY* of the plugins that use it, even the ones we do not ship, licensed > under only GPL2? If so, we really can't push this on earlier releases. ... and so it begins ... gkrellmms brings in xmms. As long as it's not pulling in any xmms *plugins*, this is probably OK. If it is, I don't even want to think about it, because that way lies madness. gkrellem-gkfreq does not specify 'or any later version', so is now no longer distributable. gkrellmoon does not specify 'or any later version', so is now no longer distributable. gkrellsun does not specify 'or any later version', so is now no longer distributable. gkrellweather does not specify 'or any later version', so is now no longer distributable At least both the sun and the moon are similarly encumbered. So, four separate gkrellm plugins are now no longer distributable until a) they change licenses b) we remove the new gkrellm Are we *sure* we want to ship a new gkrellm with the new license? Bill From notting at redhat.com Mon Jul 23 14:52:00 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Jul 2007 10:52:00 -0400 Subject: gkrellm license change notificaition In-Reply-To: <20070723144613.GL15831@nostromo.devel.redhat.com> References: <46A39B47.6040009@hhs.nl> <20070723142103.GJ15831@nostromo.devel.redhat.com> <20070723144613.GL15831@nostromo.devel.redhat.com> Message-ID: <20070723145200.GM15831@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Bill Nottingham (notting at redhat.com) said: > > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > > For those who want to know, gkrellm has moved to GPL v3, coming from GPL v2 > > > > Are *ANY* of the plugins that use it, even the ones we do not ship, licensed > > under only GPL2? If so, we really can't push this on earlier releases. > > ... and so it begins ... > > gkrellmms brings in xmms. As long as it's not pulling in any xmms *plugins*, > this is probably OK. If it is, I don't even want to think about it, because > that way lies madness. > > gkrellem-gkfreq does not specify 'or any later version', so is now no longer > distributable. > > gkrellmoon does not specify 'or any later version', so is now no longer > distributable. > > gkrellsun does not specify 'or any later version', so is now no longer > distributable. > > gkrellweather does not specify 'or any later version', so is now no longer > distributable > > At least both the sun and the moon are similarly encumbered. > > So, four separate gkrellm plugins are now no longer distributable until > a) they change licenses > b) we remove the new gkrellm Upon further reading... these four don't specify any version of the license at all. So they're technically OK, by accident. Gotta love licenses. Bill From j.w.r.degoede at hhs.nl Mon Jul 23 15:00:42 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 23 Jul 2007 17:00:42 +0200 Subject: gkrellm license change notificaition In-Reply-To: <20070723144613.GL15831@nostromo.devel.redhat.com> References: <46A39B47.6040009@hhs.nl> <20070723142103.GJ15831@nostromo.devel.redhat.com> <20070723144613.GL15831@nostromo.devel.redhat.com> Message-ID: <46A4C29A.9050800@hhs.nl> Bill Nottingham wrote: > Bill Nottingham (notting at redhat.com) said: >> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>> For those who want to know, gkrellm has moved to GPL v3, coming from GPL v2 >> Are *ANY* of the plugins that use it, even the ones we do not ship, licensed >> under only GPL2? If so, we really can't push this on earlier releases. > > ... and so it begins ... > > gkrellmms brings in xmms. As long as it's not pulling in any xmms *plugins*, > this is probably OK. If it is, I don't even want to think about it, because > that way lies madness. > AFAIK it is only talking to xmms through some kinda IPC, it might use parts of libxmms for this, but thats all. > gkrellem-gkfreq does not specify 'or any later version', so is now no longer > distributable. > > gkrellmoon does not specify 'or any later version', so is now no longer > distributable. > > gkrellsun does not specify 'or any later version', so is now no longer > distributable. > > gkrellweather does not specify 'or any later version', so is now no longer > distributable > As said in my previous post, one could argue that they were not distributable then in the first place because: 1) They are a derived work of gkrellm 2) gkrellm was licensed GPL v2 or (at your option) any later version 3) having a derived work of gkrellm that allows only gpl v2 would be placing an additional restriction on distributing, which is not allowed. In essence having a GPL v2 only work derive from a gpl v2 or any later version, is the same as forking a GPL v2 or any later version work, and removing the or any later version from the conditions for the fork, which can be argued is not allowed. You are restricting what the user can do. He may no longer distribute your fork under a later GPL version, which means he has less rights then the original / initial copyright holders granted him -> GPL violation. Or one can argue plugins using a clearly defined modular interface are not a derived work, in which case there isn't a problem under the GPL v3 either. > So, four separate gkrellm plugins are now no longer distributable until > a) they change licenses > b) we remove the new gkrellm > > Are we *sure* we want to ship a new gkrellm with the new license? > Yes, currently there isn't much in the new version making it worth any license hassle, but staying with the GPL v2 or later version is a dead road, I don't want to be maintaining a bit rotting version 2 years from now. Also gkrellm should be the least of our troubles, just wait till readline goes GPL v3, then we will have some real fireworks. In the mean time involved gkrellm plugin maintainers, please contact upstream and kindly ask them to move to GPL v3 too. Regards, Hans From tgl at redhat.com Mon Jul 23 15:10:40 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 23 Jul 2007 11:10:40 -0400 Subject: Procedure for verbatim takeover from FN to FN+1? In-Reply-To: <20070723104429.371fdada@localhost.localdomain> References: <20070722133954.GA18042@puariko.nirvana> <46A36765.5030700@hhs.nl> <20070722153959.GA18458@puariko.nirvana> <20070723093652.5af97e10@localhost.localdomain> <46A4BCD0.300@city-fan.org> <20070723104429.371fdada@localhost.localdomain> Message-ID: <25424.1185203440@sss.pgh.pa.us> Jesse Keating writes: > However to answer your question, once a release is EOL you can't do a > build on that tag, but that doesn't break inheritance. It just means > that the next time you have to update the package, you update it on the > oldest active branch and build it there. Inheritance will make sure > that it is available in all future tags. Does this work if you didn't follow the procedure from day zero? That is, assume that yesterday I built foo-1.2.3 separately in F-7 and devel branches. Tomorrow could I build foo-1.2.4 in F-7 only and have it inherit to F8? I always thought that was a big no-no. Also, what about keeping the CVS sources in sync? The obvious way of implementing this tactic is to work in the /F-7 directory only, which would leave /devel not reflecting what you expect to be shipping in F8, which seems like a really bad idea. regards, tom lane From jkeating at redhat.com Mon Jul 23 15:21:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 11:21:03 -0400 Subject: Procedure for verbatim takeover from FN to FN+1? In-Reply-To: <25424.1185203440@sss.pgh.pa.us> References: <20070722133954.GA18042@puariko.nirvana> <46A36765.5030700@hhs.nl> <20070722153959.GA18458@puariko.nirvana> <20070723093652.5af97e10@localhost.localdomain> <46A4BCD0.300@city-fan.org> <20070723104429.371fdada@localhost.localdomain> <25424.1185203440@sss.pgh.pa.us> Message-ID: <20070723112103.533025f0@localhost.localdomain> On Mon, 23 Jul 2007 11:10:40 -0400 Tom Lane wrote: > Does this work if you didn't follow the procedure from day zero? > That is, assume that yesterday I built foo-1.2.3 separately in > F-7 and devel branches. Tomorrow could I build foo-1.2.4 in F-7 only > and have it inherit to F8? I always thought that was a big no-no. See original statement A. Once you've got a build that is tagged specifically for a collection, that breaks inheritance. Queries of that tag will always see the specifically tagged build, regardless of what NVR is tagged in other inherited collections. The only way to accomplish inheritance after this is if all builds in the specific tag are untagged, so that when querying the tag, koji has to start down the inheritance path. > Also, what about keeping the CVS sources in sync? The obvious way > of implementing this tactic is to work in the /F-7 directory only, > which would leave /devel not reflecting what you expect to be > shipping in F8, which seems like a really bad idea. It is up to the maintainer to commit the changes to the branches as necessary, just not build. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Mon Jul 23 16:04:26 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 23 Jul 2007 19:04:26 +0300 Subject: gkrellm license change notificaition In-Reply-To: <20070723144613.GL15831@nostromo.devel.redhat.com> References: <46A39B47.6040009@hhs.nl> <20070723142103.GJ15831@nostromo.devel.redhat.com> <20070723144613.GL15831@nostromo.devel.redhat.com> Message-ID: <200707231904.26676.ville.skytta@iki.fi> On Monday 23 July 2007, Bill Nottingham wrote: > gkrellweather does not specify 'or any later version', so is now no longer > distributable FWIW, gkrellm-weather's README does say "or later". gkrellweather.c doesn't have a separate copyright notice embedded in it, except for strings in its "About" dialog which says "Released under the GNU Public License" [sic]. I think this misspelling was sometime part of a plugin template or something as quite a few other plugins have that too. From a.badger at gmail.com Mon Jul 23 16:59:10 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 23 Jul 2007 09:59:10 -0700 Subject: gkrellm license change notificaition In-Reply-To: <46A4C29A.9050800@hhs.nl> References: <46A39B47.6040009@hhs.nl> <20070723142103.GJ15831@nostromo.devel.redhat.com> <20070723144613.GL15831@nostromo.devel.redhat.com> <46A4C29A.9050800@hhs.nl> Message-ID: <1185209953.4709.26.camel@localhost.localdomain> On Mon, 2007-07-23 at 17:00 +0200, Hans de Goede wrote: > As said in my previous post, one could argue that they were not distributable > then in the first place because: > 1) They are a derived work of gkrellm > 2) gkrellm was licensed GPL v2 or (at your option) any later version > 3) having a derived work of gkrellm that allows only gpl v2 would be placing an > additional restriction on distributing, which is not allowed. IANAL but I think this is fallacious. gkrellm is giving me a license to use the software/code in any way that I see fit so long as I follow the GPLv2 or *(at my option)* any later version. So I can accept the gkrellm code under a GPLv2-only license and write my plugin with that understanding. I could also accept the gkrellm code under GPLv3-only and write my plugin to that. -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 alan at redhat.com Mon Jul 23 17:17:14 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Jul 2007 13:17:14 -0400 Subject: gkrellm license change notificaition In-Reply-To: <200707231904.26676.ville.skytta@iki.fi> References: <46A39B47.6040009@hhs.nl> <20070723142103.GJ15831@nostromo.devel.redhat.com> <20070723144613.GL15831@nostromo.devel.redhat.com> <200707231904.26676.ville.skytta@iki.fi> Message-ID: <20070723171714.GA22037@devserv.devel.redhat.com> On Mon, Jul 23, 2007 at 07:04:26PM +0300, Ville Skytt? wrote: > gkrellweather.c doesn't have a separate copyright notice embedded in it, > except for strings in its "About" dialog which says "Released under the GNU > Public License" [sic]. I think this misspelling was sometime part of a > plugin template or something as quite a few other plugins have that too. What mis-spelling ? It appears to be correct (unlike most software) Alan From j.w.r.degoede at hhs.nl Mon Jul 23 17:21:11 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 23 Jul 2007 19:21:11 +0200 Subject: gkrellm license change notificaition In-Reply-To: <1185209953.4709.26.camel@localhost.localdomain> References: <46A39B47.6040009@hhs.nl> <20070723142103.GJ15831@nostromo.devel.redhat.com> <20070723144613.GL15831@nostromo.devel.redhat.com> <46A4C29A.9050800@hhs.nl> <1185209953.4709.26.camel@localhost.localdomain> Message-ID: <46A4E387.2050501@hhs.nl> Toshio Kuratomi wrote: > On Mon, 2007-07-23 at 17:00 +0200, Hans de Goede wrote: > >> As said in my previous post, one could argue that they were not distributable >> then in the first place because: >> 1) They are a derived work of gkrellm >> 2) gkrellm was licensed GPL v2 or (at your option) any later version >> 3) having a derived work of gkrellm that allows only gpl v2 would be placing an >> additional restriction on distributing, which is not allowed. > > IANAL but I think this is fallacious. gkrellm is giving me a license to > use the software/code in any way that I see fit so long as I follow the > GPLv2 or *(at my option)* any later version. So I can accept the > gkrellm code under a GPLv2-only license and write my plugin with that > understanding. I could also accept the gkrellm code under GPLv3-only > and write my plugin to that. > You can write your plugin no matter what, because the GPL is about distributing, if you distribute your derived work, you must do so under the conditions of the original work, and those conditions say that you may not impose additional restrictions, taking away the receivers right to distribute the received derived work under a later version of the GPL is a further restriction. Regards, Hans From ville.skytta at iki.fi Mon Jul 23 17:28:56 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 23 Jul 2007 20:28:56 +0300 Subject: gkrellm license change notificaition In-Reply-To: <20070723171714.GA22037@devserv.devel.redhat.com> References: <46A39B47.6040009@hhs.nl> <200707231904.26676.ville.skytta@iki.fi> <20070723171714.GA22037@devserv.devel.redhat.com> Message-ID: <200707232028.56723.ville.skytta@iki.fi> On Monday 23 July 2007, Alan Cox wrote: > On Mon, Jul 23, 2007 at 07:04:26PM +0300, Ville Skytt? wrote: > > gkrellweather.c doesn't have a separate copyright notice embedded in it, > > except for strings in its "About" dialog which says "Released under the > > GNU Public License" [sic]. I think this misspelling was sometime part of > > a plugin template or something as quite a few other plugins have that > > too. > > What mis-spelling ? "GNU Public License" should be "GNU General Public License". From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jul 23 17:31:13 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 23 Jul 2007 19:31:13 +0200 Subject: gkrellm license change notificaition In-Reply-To: <20070723171714.GA22037@devserv.devel.redhat.com> References: <46A39B47.6040009@hhs.nl> <20070723142103.GJ15831@nostromo.devel.redhat.com> <20070723144613.GL15831@nostromo.devel.redhat.com> <200707231904.26676.ville.skytta@iki.fi> <20070723171714.GA22037@devserv.devel.redhat.com> Message-ID: <20070723193113.4fa55078@python3.es.egwn.lan> Alan Cox wrote : > On Mon, Jul 23, 2007 at 07:04:26PM +0300, Ville Skytt? wrote: > > gkrellweather.c doesn't have a separate copyright notice embedded in it, > > except for strings in its "About" dialog which says "Released under the GNU > > Public License" [sic]. I think this misspelling was sometime part of a > > plugin template or something as quite a few other plugins have that too. > > What mis-spelling ? It appears to be correct (unlike most software) He probably meant it should be the "GNU General Public License". Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.1-27.fc7 Load : 0.11 0.19 0.18 From ville.skytta at iki.fi Mon Jul 23 17:35:40 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 23 Jul 2007 20:35:40 +0300 Subject: gkrellm license change notificaition In-Reply-To: <46A4E387.2050501@hhs.nl> References: <46A39B47.6040009@hhs.nl> <1185209953.4709.26.camel@localhost.localdomain> <46A4E387.2050501@hhs.nl> Message-ID: <200707232035.40347.ville.skytta@iki.fi> On Monday 23 July 2007, Hans de Goede wrote: > You can write your plugin no matter what, because the GPL is about > distributing, if you distribute your derived work, you must do so under the > conditions of the original work, and those conditions say that you may not > impose additional restrictions, taking away the receivers right to > distribute the received derived work under a later version of the GPL is a > further restriction. If the original from which my stuff is derived from is "v2 or later", wouldn't dropping the v2 (ie. switching to v3+) be such a restriction too? From a.badger at gmail.com Mon Jul 23 17:44:30 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 23 Jul 2007 10:44:30 -0700 Subject: gkrellm license change notificaition In-Reply-To: <46A4E387.2050501@hhs.nl> References: <46A39B47.6040009@hhs.nl> <20070723142103.GJ15831@nostromo.devel.redhat.com> <20070723144613.GL15831@nostromo.devel.redhat.com> <46A4C29A.9050800@hhs.nl> <1185209953.4709.26.camel@localhost.localdomain> <46A4E387.2050501@hhs.nl> Message-ID: <1185212673.4709.38.camel@localhost.localdomain> On Mon, 2007-07-23 at 19:21 +0200, Hans de Goede wrote: > Toshio Kuratomi wrote: > > On Mon, 2007-07-23 at 17:00 +0200, Hans de Goede wrote: > > > >> As said in my previous post, one could argue that they were not distributable > >> then in the first place because: > >> 1) They are a derived work of gkrellm > >> 2) gkrellm was licensed GPL v2 or (at your option) any later version > >> 3) having a derived work of gkrellm that allows only gpl v2 would be placing an > >> additional restriction on distributing, which is not allowed. > > > > IANAL but I think this is fallacious. gkrellm is giving me a license to > > use the software/code in any way that I see fit so long as I follow the > > GPLv2 or *(at my option)* any later version. So I can accept the > > gkrellm code under a GPLv2-only license and write my plugin with that > > understanding. I could also accept the gkrellm code under GPLv3-only > > and write my plugin to that. > > > > You can write your plugin no matter what, because the GPL is about > distributing, if you distribute your derived work, you must do so under the > conditions of the original work, and those conditions say that you may not > impose additional restrictions, taking away the receivers right to distribute > the received derived work under a later version of the GPL is a further > restriction. > s/write/distribute/ in what I wrote and it comes out the same. GPLv2-or-later-at-my-option is giving me the choice of how to distribute the code. I think that language gives me the choice to distribute as GPLv2 only, GPLv3 only, or GPLv2+. In any case, I think this has reached a point where there's no use our arguing over it. Since we cannot agree as to what the meaning of the license is, it's obviously not as clear as either of us think. Only a lawyer can judge what the true interpretation is likely to be. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Tue Jul 24 00:26:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 24 Jul 2007 02:26:51 +0200 Subject: Procedure for verbatim takeover from FN to FN+1? In-Reply-To: <20070723104429.371fdada@localhost.localdomain> References: <20070722133954.GA18042@puariko.nirvana> <46A36765.5030700@hhs.nl> <20070722153959.GA18458@puariko.nirvana> <20070723093652.5af97e10@localhost.localdomain> <46A4BCD0.300@city-fan.org> <20070723104429.371fdada@localhost.localdomain> Message-ID: <20070724002651.GA24820@puariko.nirvana> On Mon, Jul 23, 2007 at 10:44:29AM -0400, Jesse Keating wrote: > I'll admit that this inheritance chain is a bit misleading. The FC6 > tags are merely sync tags, not active. The real entry point is > dist-fc7, the active point being dist-fc7-updates. OK, so for FC6->F7 one would need some manual magic wand anyway, could you pretty please wave it? :) And if I understand correctly the inhertiance mechanism, I see no way to stop a package from being inherited to F8. How are orphaned or otherwise unwanted packages in subsequent releases handled? How is their inhertiance 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 jkeating at redhat.com Tue Jul 24 03:08:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 23:08:39 -0400 Subject: Procedure for verbatim takeover from FN to FN+1? In-Reply-To: <20070724002651.GA24820@puariko.nirvana> References: <20070722133954.GA18042@puariko.nirvana> <46A36765.5030700@hhs.nl> <20070722153959.GA18458@puariko.nirvana> <20070723093652.5af97e10@localhost.localdomain> <46A4BCD0.300@city-fan.org> <20070723104429.371fdada@localhost.localdomain> <20070724002651.GA24820@puariko.nirvana> Message-ID: <20070723230839.6bd95e10@ender> On Tue, 24 Jul 2007 02:26:51 +0200 Axel Thimm wrote: > OK, so for FC6->F7 one would need some manual magic wand anyway, could > you pretty please wave it? :) I'd rather you built it in the oldest koji collection proper, so that we have the build logs and such kept in koji. > And if I understand correctly the inhertiance mechanism, I see no way > to stop a package from being inherited to F8. How are orphaned or > otherwise unwanted packages in subsequent releases handled? How is > their inhertiance broken? To remove packages, we use 'koji block-pkg', which effectively "blocks" that package from showing up when listing latest builds and such, which is used by the compose tools. http://fedoraproject.org/wiki/ReleaseEngineering/SOP/RemovingPackages -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Tue Jul 24 08:30:42 2007 From: opensource at till.name (Till Maas) Date: Tue, 24 Jul 2007 10:30:42 +0200 Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <200705221032.29028.jkeating@redhat.com> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <645d17210705220723s725802f8i431ae467b38289f@mail.gmail.com> <200705221032.29028.jkeating@redhat.com> Message-ID: <200707241030.44052.opensource@till.name> On Di Mai 22 2007, Jesse Keating wrote: > On Tuesday 22 May 2007 10:23:47 am Jonathan Underwood wrote: > > So unless I was "in the know" about the URL you gave above, I'd have > > no way of finding the build logs. So my suggestion really relates to > > usability, everything is there under the hood. > > Suggestions with patches are even more helpful (: There is a patch in the trac ticket for two months now without any comment from any koji developer and the patch is very very simple. Regards, Till From wolfy at nobugconsulting.ro Tue Jul 24 09:05:32 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 24 Jul 2007 12:05:32 +0300 Subject: koji build fail Message-ID: <46A5C0DC.5070503@nobugconsulting.ro> I am trying to build in koji a new package, but I've hit an error which I do not understand. - after cvs-import.sh: http://koji.fedoraproject.org/koji/taskinfo?taskID=75023 + http://koji.fedoraproject.org/koji/taskinfo?taskID=75024 The error displayed on screen was identical to the one listed below. - after cvs add, cvs commit, make tag, make build in F-7: [wolfy at wolfy64 F-7]$ make tag cvs tag -c qfaxreader-0_3_1-7_fc7 cvs tag: Tagging . T .cvsignore T Makefile T branch T qfaxreader-parallel_build.patch T qfaxreader.spec T sources Tagged with: qfaxreader-0_3_1-7_fc7 [wolfy at wolfy64 F-7]$ make build Created task: 75045 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=75045 Watching tasks (this may be safely interrupted)... 75045 build (dist-fc7-updates-candidate, F-7:qfaxreader-0_3_1-7_fc7): free 75045 build (dist-fc7-updates-candidate, F-7:qfaxreader-0_3_1-7_fc7): free -> open (ppc4.fedora.phx.redhat.com) 75046 buildSRPMFromCVS (F-7:qfaxreader-0_3_1-7_fc7): free 75046 buildSRPMFromCVS (F-7:qfaxreader-0_3_1-7_fc7): free -> open (xenbuilder4.fedora.phx.redhat.com) 75046 buildSRPMFromCVS (F-7:qfaxreader-0_3_1-7_fc7): open (xenbuilder4.fedora.phx.redhat.com) -> closed 0 free 1 open 1 done 0 failed 75045 build (dist-fc7-updates-candidate, F-7:qfaxreader-0_3_1-7_fc7): open (ppc4.fedora.phx.redhat.com) -> FAILED: BuildError: package qfaxreader not in list for tag dist-fc7-updates-candidate 0 free 0 open 1 done 1 failed 75045 build (dist-fc7-updates-candidate, F-7:qfaxreader-0_3_1-7_fc7) failed make: *** [koji] Error 1 Could someone please do a translation for me from koji language to plain English ? And provide a solution, if possible... TIA manuel From Axel.Thimm at ATrpms.net Tue Jul 24 09:22:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 24 Jul 2007 11:22:04 +0200 Subject: Procedure for verbatim takeover from FN to FN+1? In-Reply-To: <20070723230839.6bd95e10@ender> References: <20070722133954.GA18042@puariko.nirvana> <46A36765.5030700@hhs.nl> <20070722153959.GA18458@puariko.nirvana> <20070723093652.5af97e10@localhost.localdomain> <46A4BCD0.300@city-fan.org> <20070723104429.371fdada@localhost.localdomain> <20070724002651.GA24820@puariko.nirvana> <20070723230839.6bd95e10@ender> Message-ID: <20070724092204.GC24820@puariko.nirvana> On Mon, Jul 23, 2007 at 11:08:39PM -0400, Jesse Keating wrote: > On Tue, 24 Jul 2007 02:26:51 +0200 > Axel Thimm wrote: > > > OK, so for FC6->F7 one would need some manual magic wand anyway, could > > you pretty please wave it? :) > > I'd rather you built it in the oldest koji collection proper, so that > we have the build logs and such kept in koji. And double the mirror slack space and the *active* distribution upgrade churn? What's different with vtkdata in comparison to other tons of packages dublicated verbatim FC6->F7? Anyway, I asked 4 times, and I guess I should take no as an answer. -- 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 Tue Jul 24 11:06:00 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 24 Jul 2007 06:06:00 -0500 (CDT) Subject: koji build fail In-Reply-To: <46A5C0DC.5070503@nobugconsulting.ro> References: <46A5C0DC.5070503@nobugconsulting.ro> Message-ID: <10828.65.192.24.164.1185275160.squirrel@mail.jcomserv.net> > I am trying to build in koji a new package, but I've hit an error which > I do not understand. > > - after cvs-import.sh: > http://koji.fedoraproject.org/koji/taskinfo?taskID=75023 + > http://koji.fedoraproject.org/koji/taskinfo?taskID=75024 > The error displayed on screen was identical to the one listed below. > - after cvs add, cvs commit, make tag, make build in F-7: > > [wolfy at wolfy64 F-7]$ make tag > cvs tag -c qfaxreader-0_3_1-7_fc7 > cvs tag: Tagging . > T .cvsignore > T Makefile > T branch > T qfaxreader-parallel_build.patch > T qfaxreader.spec > T sources > Tagged with: qfaxreader-0_3_1-7_fc7 > > [wolfy at wolfy64 F-7]$ make build > Created task: 75045 > Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=75045 > Watching tasks (this may be safely interrupted)... > 75045 build (dist-fc7-updates-candidate, F-7:qfaxreader-0_3_1-7_fc7): free > 75045 build (dist-fc7-updates-candidate, F-7:qfaxreader-0_3_1-7_fc7): > free -> open (ppc4.fedora.phx.redhat.com) > 75046 buildSRPMFromCVS (F-7:qfaxreader-0_3_1-7_fc7): free > 75046 buildSRPMFromCVS (F-7:qfaxreader-0_3_1-7_fc7): free -> open > (xenbuilder4.fedora.phx.redhat.com) > 75046 buildSRPMFromCVS (F-7:qfaxreader-0_3_1-7_fc7): open > (xenbuilder4.fedora.phx.redhat.com) -> closed > 0 free 1 open 1 done 0 failed > 75045 build (dist-fc7-updates-candidate, F-7:qfaxreader-0_3_1-7_fc7): > open (ppc4.fedora.phx.redhat.com) -> FAILED: BuildError: package > qfaxreader not in list for tag dist-fc7-updates-candidate > 0 free 0 open 1 done 1 failed > > 75045 build (dist-fc7-updates-candidate, F-7:qfaxreader-0_3_1-7_fc7) > failed > make: *** [koji] Error 1 > > > Could someone please do a translation for me from koji language to > plain English ? And provide a solution, if possible... IANJK, but I'm guessing Test1 freeze? > TIA > manuel > > -- > 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 Tue Jul 24 11:44:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 07:44:15 -0400 Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <200707241030.44052.opensource@till.name> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <645d17210705220723s725802f8i431ae467b38289f@mail.gmail.com> <200705221032.29028.jkeating@redhat.com> <200707241030.44052.opensource@till.name> Message-ID: <20070724074415.105a99ed@ender> On Tue, 24 Jul 2007 10:30:42 +0200 Till Maas wrote: > There is a patch in the trac ticket for two months now without any > comment from any koji developer and the patch is very very simple. Unfortunately the developers are working on important things like garbage collection as we continuously overflow our storage. Then we'll be working on generating rpm deltas that can be picked up by composing tools for things like presto. While the patch exists and may be simple, it just isn't a priority. :( -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jul 24 11:46:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 07:46:14 -0400 Subject: koji build fail In-Reply-To: <46A5C0DC.5070503@nobugconsulting.ro> References: <46A5C0DC.5070503@nobugconsulting.ro> Message-ID: <20070724074614.7b4c9dba@ender> On Tue, 24 Jul 2007 12:05:32 +0300 Manuel Wolfshant wrote: > 75045 build (dist-fc7-updates-candidate, F-7:qfaxreader-0_3_1-7_fc7) > failed make: *** [koji] Error 1 It appears that whomever did this round of cvs admin requests didn't do the koji sync step in time for you to build. Nothing on your end, purely an admin issue. I'll check with the admin when they come online again. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Tue Jul 24 14:30:39 2007 From: opensource at till.name (Till Maas) Date: Tue, 24 Jul 2007 16:30:39 +0200 Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <20070724074415.105a99ed@ender> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <200707241030.44052.opensource@till.name> <20070724074415.105a99ed@ender> Message-ID: <200707241630.40568.opensource@till.name> On Di Juli 24 2007, Jesse Keating wrote: > Unfortunately the developers are working on important things like > garbage collection as we continuously overflow our storage. Then we'll > be working on generating rpm deltas that can be picked up by composing > tools for things like presto. While the patch exists and may be > simple, it just isn't a priority. :( Although only working on high priority targets is imho a bad scheduling, you could at least write a note that there is no time to apply patches instead of asking for them. Regards, Till From jkeating at redhat.com Tue Jul 24 14:48:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 10:48:11 -0400 Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <200707241630.40568.opensource@till.name> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <200707241030.44052.opensource@till.name> <20070724074415.105a99ed@ender> <200707241630.40568.opensource@till.name> Message-ID: <20070724104811.130c1cbc@localhost.localdomain> On Tue, 24 Jul 2007 16:30:39 +0200 Till Maas wrote: > Although only working on high priority targets is imho a bad > scheduling, you could at least write a note that there is no time to > apply patches instead of asking for them. Well the typical work method is work on a key feature or bugfix, test that it is successful, and then look at any low hanging fruit to include in the release, such as this patch here. We just haven't gotten to that stage yet. Please be patient. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buc at odusz.so-cdu.ru Tue Jul 24 16:39:15 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 24 Jul 2007 20:39:15 +0400 Subject: Koji reports "cvs timed out" ... Message-ID: <46A62B33.6030702@odu.neva.ru> Something goes wrong? > [buc at buc devel]$ make build > Created task: 75399 > Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=75399 > Watching tasks (this may be safely interrupted)... > 75399 build (dist-f8, devel:nail-12_3-1_fc8): free > 75399 build (dist-f8, devel:nail-12_3-1_fc8): free -> open > (ppc3.fedora.redhat.com) > 75400 buildSRPMFromCVS (devel:nail-12_3-1_fc8): free > 75400 buildSRPMFromCVS (devel:nail-12_3-1_fc8): free -> open > (xenbuilder2.fedora.redhat.com) > 75400 buildSRPMFromCVS (devel:nail-12_3-1_fc8): open > (xenbuilder2.fedora.redhat.com) -> FAILED: BuildError: Error with > checkout :pserver:anonymous at cvs.fedora.redhat.com:/cvs/pkgs: cvs > [checkout aborted]: connect to [cvs.fedora.redhat.com]:2401 failed: > Connection timed out > 0 free 1 open 0 done 1 failed > 75399 build (dist-f8, devel:nail-12_3-1_fc8): open > (ppc3.fedora.redhat.com) -> FAILED: BuildError: Error with checkout > :pserver:anonymous at cvs.fedora.redhat.com:/cvs/pkgs: cvs [checkout > aborted]: connect to [cvs.fedora.redhat.com]:2401 failed: Connection > timed out > 0 free 0 open 0 done 2 failed > make: *** [koji] Error 1 ~buc From jkeating at redhat.com Tue Jul 24 16:49:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 12:49:06 -0400 Subject: Koji reports "cvs timed out" ... In-Reply-To: <46A62B33.6030702@odu.neva.ru> References: <46A62B33.6030702@odu.neva.ru> Message-ID: <20070724124906.36ae04a3@localhost.localdomain> On Tue, 24 Jul 2007 20:39:15 +0400 Dmitry Butskoy wrote: > Something goes wrong? This was fixed earlier. A dns change left some machines not able to contact the cvs server correctly. A hosts file change has fixed this. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Jul 24 17:12:22 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 24 Jul 2007 12:12:22 -0500 Subject: kde4 In-Reply-To: <469F98B8.7000801@math.unl.edu> References: <469F98B8.7000801@math.unl.edu> Message-ID: <46A632F6.1000206@math.unl.edu> Rex Dieter wrote: > Just a heads-up that the KDE SIG will be working to import kde4 into > rawhide *real soon now*. "real soon now" is now defined as postponed at least until after test1. The KDE SIG will be updating our KDE4 plan on the wiki soon, stay tuned: http://fedoraproject.org/wiki/Releases/FeatureKDE4 -- Rex From jkeating at redhat.com Tue Jul 24 17:18:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 13:18:07 -0400 Subject: Koji reports "cvs timed out" ... In-Reply-To: <20070724124906.36ae04a3@localhost.localdomain> References: <46A62B33.6030702@odu.neva.ru> <20070724124906.36ae04a3@localhost.localdomain> Message-ID: <20070724131807.01ff5789@localhost.localdomain> On Tue, 24 Jul 2007 12:49:06 -0400 Jesse Keating wrote: > > Something goes wrong? > > This was fixed earlier. A dns change left some machines not able to > contact the cvs server correctly. A hosts file change has fixed > this Ooops, seems it wasn't quite fixed. An update of your common/ directory is needed so that it provides the correct URL to koji to get the content out of CVS. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Tue Jul 24 17:46:26 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 24 Jul 2007 13:46:26 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-07-24 Message-ID: <20070724174626.3FE91152131@buildsys.fedoraproject.org> 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: tracker FE6 > F7 (0:0.6.0-1.fc6.1 > 0:0.5.4-6.fc7) dmitry AT butskoy.name: nail FE6 > F7 (0:12.3-1.fc6 > 0:12.2-1.fc7) xawtv FE6 > F7-updates (0:3.95-4.fc6 > 0:3.95-3.fc7) ed AT eh3.com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico.scholz AT informatik.tu-chemnitz.de: fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) 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.16-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) jakub AT redhat.com: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jeff AT ocjtech.us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) jjohnstn AT redhat.com: eclipse-cdt FC6-updates > F7 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) lemenkov AT gmail.com: fuse FE6 > F7-updates-testing (0:2.7.0-3.fc6 > 0:2.7.0-2.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-4.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: phpMyAdmin FE6 > F7 (0:2.10.3-1.fc6 > 0:2.10.0.2-3.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) pawsa AT theochem.kth.se: balsa FE5 > F7 (0:2.3.16-3.fc5 > 0:2.3.14-1.fc7) FE6 > F7 (0:2.3.17-1.fc6 > 0:2.3.14-1.fc7) rc040203 AT freenet.de: perl-DBIx-DBSchema FE6 > F7 (0:0.33-1.fc6 > 0:0.32-1.fc7) perl-File-Remove FE6 > F7 (0:0.37-1.fc6 > 0:0.34-1.fc7) 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: kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) rmeggins AT redhat.com: mozldap FE5 > F7 (0:6.0.4-1.fc5 > 0:6.0.3-1.fc7) FE6 > F7 (0:6.0.4-1.fc6 > 0:6.0.3-1.fc7) perl-Mozilla-LDAP FE5 > F7 (0:1.5.1-1.fc5 > 0:1.5-9.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.5-9.fc7) splinux AT fedoraproject.org: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) tcallawa AT redhat.com: perl-File-MMagic-XS FE6 > F7 (0:0.09002-1.fc6 > 0:0.08-2.fc6) than AT redhat.com: kdemultimedia FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) ---------------------------------------------------------------------- balsa: pawsa AT theochem.kth.se FE5 > F7 (0:2.3.16-3.fc5 > 0:2.3.14-1.fc7) FE6 > F7 (0:2.3.17-1.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) eclipse-cdt: jjohnstn AT redhat.com FC6-updates > F7 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) fedora-usermgmt: enrico.scholz AT informatik.tu-chemnitz.de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.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-4.fc6 > 0:2.1.1-2.fc6) fuse: lemenkov AT gmail.com FE6 > F7-updates-testing (0:2.7.0-3.fc6 > 0:2.7.0-2.fc7) gcc: jakub AT redhat.com FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) 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) jrtplib: jeff AT ocjtech.us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) kdeartwork-extras: rdieter AT math.unl.edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdemultimedia: than AT redhat.com FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.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) lostirc: splinux AT fedoraproject.org FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) maxima: rdieter AT math.unl.edu FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) 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) mozldap: rmeggins AT redhat.com FE5 > F7 (0:6.0.4-1.fc5 > 0:6.0.3-1.fc7) FE6 > F7 (0:6.0.4-1.fc6 > 0:6.0.3-1.fc7) nail: dmitry AT butskoy.name FE6 > F7 (0:12.3-1.fc6 > 0:12.2-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-DBIx-DBSchema: rc040203 AT freenet.de FE6 > F7 (0:0.33-1.fc6 > 0:0.32-1.fc7) perl-Event: cweyl AT alumni.drew.edu FE6 > F7 (0:1.09-1.fc6 > 0:1.08-1.fc7) perl-File-MMagic-XS: tcallawa AT redhat.com FE6 > F7 (0:0.09002-1.fc6 > 0:0.08-2.fc6) perl-File-Remove: rc040203 AT freenet.de FE6 > F7 (0:0.37-1.fc6 > 0:0.34-1.fc7) 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-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-Mozilla-LDAP: rmeggins AT redhat.com FE5 > F7 (0:1.5.1-1.fc5 > 0:1.5-9.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.5-9.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) phpMyAdmin: mmcgrath AT redhat.com FE6 > F7 (0:2.10.3-1.fc6 > 0:2.10.0.2-3.fc7) python-cheetah: mikeb AT redhat.com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) scrip: ed AT eh3.com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) tracker: dakingun AT gmail.com FE6 > F7 (0:0.6.0-1.fc6.1 > 0:0.5.4-6.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) xawtv: dmitry AT butskoy.name FE6 > F7-updates (0:3.95-4.fc6 > 0:3.95-3.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.16-1.fc6 > 0:1.06.11-2.fc7) From bugs.michael at gmx.net Tue Jul 24 17:55:47 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 24 Jul 2007 19:55:47 +0200 Subject: Package EVR problems in Fedora 2007-07-24 In-Reply-To: <20070724174626.3FE91152131@buildsys.fedoraproject.org> References: <20070724174626.3FE91152131@buildsys.fedoraproject.org> Message-ID: <20070724195547.7716768f.bugs.michael@gmx.net> On Tue, 24 Jul 2007 13:46:26 -0400 (EDT), buildsys fedoraproject.org wrote: > cweyl AT alumni.drew.edu: > perl-Algorithm-C3 -many more,snip- Has anyone tried to contact Chris before (in addition to the private report mails)? The packages are listed in the report for a very long time. From buildsys at fedoraproject.org Tue Jul 24 18:07:59 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 24 Jul 2007 14:07:59 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-07-24 Message-ID: <20070724180759.8DB0D152131@buildsys.fedoraproject.org> alexl AT redhat.com: xdg-user-dirs F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) bdpepple AT ameritech.net: meld F7-updates-testing > F8 (0:1.1.5-2.fc7 > 0:1.1.5-1.fc8) 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: tracker FE6 > F7 (0:0.6.0-1.fc6.1 > 0:0.5.4-6.fc7) davidz AT redhat.com: dbus-python F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) redhat-artwork F7-updates > F8 (0:7.0.0-11.fc7 > 0:7.0.0-10.fc8) dmitry AT butskoy.name: nail FE6 > F7 (0:12.3-1.fc6 > 0:12.2-1.fc7) FE6 > F8 (0:12.3-1.fc6 > 0:12.2-1.fc7) xawtv FE6 > F7-updates (0:3.95-4.fc6 > 0:3.95-3.fc7) FE6 > F8 (0:3.95-4.fc6 > 0:3.95-3.fc8) ed AT eh3.com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico.scholz AT informatik.tu-chemnitz.de: fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (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) FE6 > F8 (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.16-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 F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) perl-Net-Libdnet F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) gemi AT bluewin.ch: tkcvs F7 > F8 (0:8.0.4-2.fc7 > 0:8.0.4-1.fc8) hellwolf.misty AT gmail.com: fuse-convmvfs FE6 > F8 (0:0.2.4-2.fc6 > 0:0.2.4-1.fc8) F7-updates > F8 (0:0.2.4-3.fc7 > 0:0.2.4-1.fc8) jakub AT redhat.com: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jeff AT ocjtech.us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) jjohnstn AT redhat.com: eclipse-cdt FC6-updates > F7 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) FC6-updates > F8 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) lemenkov AT gmail.com: fuse FE6 > F7-updates-testing (0:2.7.0-3.fc6 > 0:2.7.0-2.fc7) FE6 > F8 (0:2.7.0-3.fc6 > 0:2.7.0-2.fc8) luya_tfz AT thefinalzone.com: gdesklets F7-updates > F8 (0:0.35.4-8.fc7 > 0:0.35.4-7.1.fc8) mcepl AT redhat.com: JSDoc F7-updates > F8 (0:1.10.2-4.fc7 > 0:1.10.2-3.fc8) 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-4.fc6 > 0:2.1.1-2.fc6) mfleming+rpm AT enlartenment.com: pfqueue F7-updates-testing > F8 (0:0.5.6-5.fc7 > 0:0.5.6-4.fc8) mikeb AT redhat.com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) mmcgrath AT redhat.com: phpMyAdmin FE6 > F7 (0:2.10.3-1.fc6 > 0:2.10.0.2-3.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) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) pawsa AT theochem.kth.se: balsa FE5 > F7 (0:2.3.16-3.fc5 > 0:2.3.14-1.fc7) FE6 > F7 (0:2.3.17-1.fc6 > 0:2.3.14-1.fc7) rc040203 AT freenet.de: perl-DBIx-DBSchema FE6 > F7 (0:0.33-1.fc6 > 0:0.32-1.fc7) perl-File-Remove FE6 > F7 (0:0.37-1.fc6 > 0:0.34-1.fc7) 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: kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) redhat-bugzilla AT camperquake.de: audacious-plugins FE6 > F8 (0:1.3.5-2.fc6 > 0:1.3.5-1.fc8) F7-updates > F8 (0:1.3.5-2.fc7 > 0:1.3.5-1.fc8) rmeggins AT redhat.com: mozldap FE5 > F7 (0:6.0.4-1.fc5 > 0:6.0.3-1.fc7) FE6 > F7 (0:6.0.4-1.fc6 > 0:6.0.3-1.fc7) perl-Mozilla-LDAP FE5 > F7 (0:1.5.1-1.fc5 > 0:1.5-9.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.5-9.fc7) sandmann AT redhat.com: libXi F7-updates-testing > F8 (0:1.1.1-1.fc7 > 0:1.0.4-1) seg AT haxxed.com: rosegarden4 FE5 > F8 (0:1.5.1-1.fc5 > 0:1.4.0-1.fc7) FE6 > F8 (0:1.5.1-1.fc6 > 0:1.4.0-1.fc7) F7-updates-testing > F8 (0:1.5.1-1.fc7.1 > 0:1.4.0-1.fc7) splinux AT fedoraproject.org: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) steved AT redhat.com: libgssapi F7-updates-testing > F8 (0:0.11-1.fc7 > 0:0.10-3.fc7) nfs-utils F7-updates-testing > F8 (1:1.1.0-1.fc7 > 1:1.0.12-7.fc8) nfs-utils-lib F7-updates-testing > F8 (0:1.0.8-10.fc7 > 0:1.0.8-8.fc7) stransky AT redhat.com: alsa-lib F7 > F8 (0:1.0.14-0.4.rc3.fc7 > 0:1.0.14-0.4.fc8) alsa-utils F7-updates > F8 (0:1.0.14-0.7.rc2.fc7 > 0:1.0.14-0.7.fc8) tcallawa AT redhat.com: perl-File-MMagic-XS FE6 > F7 (0:0.09002-1.fc6 > 0:0.08-2.fc6) perl-Taint-Runtime FE6 > F8 (0:0.03-1.fc6 > 0:0.02-2.fc6) F7-updates-testing > F8 (0:0.03-1.fc7 > 0:0.02-2.fc6) than AT redhat.com: kdemultimedia FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) kdepim F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) veillard AT redhat.com: libxml2 FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) ---------------------------------------------------------------------- alsa-lib: stransky AT redhat.com F7 > F8 (0:1.0.14-0.4.rc3.fc7 > 0:1.0.14-0.4.fc8) alsa-utils: stransky AT redhat.com F7-updates > F8 (0:1.0.14-0.7.rc2.fc7 > 0:1.0.14-0.7.fc8) audacious-plugins: redhat-bugzilla AT camperquake.de FE6 > F8 (0:1.3.5-2.fc6 > 0:1.3.5-1.fc8) F7-updates > F8 (0:1.3.5-2.fc7 > 0:1.3.5-1.fc8) balsa: pawsa AT theochem.kth.se FE5 > F7 (0:2.3.16-3.fc5 > 0:2.3.14-1.fc7) FE6 > F7 (0:2.3.17-1.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) dbus-python: davidz AT redhat.com F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) eclipse-cdt: jjohnstn AT redhat.com FC6-updates > F7 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) FC6-updates > F8 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) fedora-usermgmt: enrico.scholz AT informatik.tu-chemnitz.de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.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-4.fc6 > 0:2.1.1-2.fc6) fuse: lemenkov AT gmail.com FE6 > F7-updates-testing (0:2.7.0-3.fc6 > 0:2.7.0-2.fc7) FE6 > F8 (0:2.7.0-3.fc6 > 0:2.7.0-2.fc8) fuse-convmvfs: hellwolf.misty AT gmail.com FE6 > F8 (0:0.2.4-2.fc6 > 0:0.2.4-1.fc8) F7-updates > F8 (0:0.2.4-3.fc7 > 0:0.2.4-1.fc8) gcc: jakub AT redhat.com FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) gdesklets: luya_tfz AT thefinalzone.com F7-updates > F8 (0:0.35.4-8.fc7 > 0:0.35.4-7.1.fc8) gtranslator: foolish AT guezz.net F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) 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) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) jrtplib: jeff AT ocjtech.us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) JSDoc: mcepl AT redhat.com F7-updates > F8 (0:1.10.2-4.fc7 > 0:1.10.2-3.fc8) kdeartwork-extras: rdieter AT math.unl.edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdemultimedia: than AT redhat.com FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) kdepim: than AT redhat.com F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) libgssapi: steved AT redhat.com F7-updates-testing > F8 (0:0.11-1.fc7 > 0:0.10-3.fc7) libtasn1: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (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) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) libXi: sandmann AT redhat.com F7-updates-testing > F8 (0:1.1.1-1.fc7 > 0:1.0.4-1) libxml2: veillard AT redhat.com FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) lostirc: splinux AT fedoraproject.org FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) maxima: rdieter AT math.unl.edu FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) meld: bdpepple AT ameritech.net F7-updates-testing > F8 (0:1.1.5-2.fc7 > 0:1.1.5-1.fc8) 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) mozldap: rmeggins AT redhat.com FE5 > F7 (0:6.0.4-1.fc5 > 0:6.0.3-1.fc7) FE6 > F7 (0:6.0.4-1.fc6 > 0:6.0.3-1.fc7) nail: dmitry AT butskoy.name FE6 > F7 (0:12.3-1.fc6 > 0:12.2-1.fc7) FE6 > F8 (0:12.3-1.fc6 > 0:12.2-1.fc7) nfs-utils: steved AT redhat.com F7-updates-testing > F8 (1:1.1.0-1.fc7 > 1:1.0.12-7.fc8) nfs-utils-lib: steved AT redhat.com F7-updates-testing > F8 (0:1.0.8-10.fc7 > 0:1.0.8-8.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-DBIx-DBSchema: rc040203 AT freenet.de FE6 > F7 (0:0.33-1.fc6 > 0:0.32-1.fc7) perl-Event: cweyl AT alumni.drew.edu FE6 > F7 (0:1.09-1.fc6 > 0:1.08-1.fc7) perl-File-MMagic-XS: tcallawa AT redhat.com FE6 > F7 (0:0.09002-1.fc6 > 0:0.08-2.fc6) perl-File-Remove: rc040203 AT freenet.de FE6 > F7 (0:0.37-1.fc6 > 0:0.34-1.fc7) 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-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-Mozilla-LDAP: rmeggins AT redhat.com FE5 > F7 (0:1.5.1-1.fc5 > 0:1.5-9.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.5-9.fc7) perl-Net-Libdnet: foolish AT guezz.net F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: foolish AT guezz.net F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) 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-Taint-Runtime: tcallawa AT redhat.com FE6 > F8 (0:0.03-1.fc6 > 0:0.02-2.fc6) F7-updates-testing > F8 (0:0.03-1.fc7 > 0:0.02-2.fc6) pfqueue: mfleming+rpm AT enlartenment.com F7-updates-testing > F8 (0:0.5.6-5.fc7 > 0:0.5.6-4.fc8) phpMyAdmin: mmcgrath AT redhat.com FE6 > F7 (0:2.10.3-1.fc6 > 0:2.10.0.2-3.fc7) python-cheetah: mikeb AT redhat.com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) redhat-artwork: davidz AT redhat.com F7-updates > F8 (0:7.0.0-11.fc7 > 0:7.0.0-10.fc8) rosegarden4: seg AT haxxed.com FE5 > F8 (0:1.5.1-1.fc5 > 0:1.4.0-1.fc7) FE6 > F8 (0:1.5.1-1.fc6 > 0:1.4.0-1.fc7) F7-updates-testing > F8 (0:1.5.1-1.fc7.1 > 0:1.4.0-1.fc7) scrip: ed AT eh3.com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) tkcvs: gemi AT bluewin.ch F7 > F8 (0:8.0.4-2.fc7 > 0:8.0.4-1.fc8) tracker: dakingun AT gmail.com FE6 > F7 (0:0.6.0-1.fc6.1 > 0:0.5.4-6.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) xawtv: dmitry AT butskoy.name FE6 > F7-updates (0:3.95-4.fc6 > 0:3.95-3.fc7) FE6 > F8 (0:3.95-4.fc6 > 0:3.95-3.fc8) xdg-user-dirs: alexl AT redhat.com F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) 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.16-1.fc6 > 0:1.06.11-2.fc7) From bugs.michael at gmx.net Tue Jul 24 18:02:17 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 24 Jul 2007 20:02:17 +0200 Subject: F8 covered in this report In-Reply-To: <20070724180759.8DB0D152131@buildsys.fedoraproject.org> References: <20070724180759.8DB0D152131@buildsys.fedoraproject.org> Message-ID: <20070724200217.8e9ac4fb.bugs.michael@gmx.net> This second message covers Rawhide as "F8". Packagers have received mails in private, too. From tibbs at math.uh.edu Tue Jul 24 18:55:41 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 24 Jul 2007 13:55:41 -0500 Subject: Package EVR problems in Fedora 2007-07-24 In-Reply-To: <20070724195547.7716768f.bugs.michael@gmx.net> References: <20070724174626.3FE91152131@buildsys.fedoraproject.org> <20070724195547.7716768f.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Has anyone tried to contact Chris before (in addition to the MS> private report mails)? The packages are listed in the report for a MS> very long time. I'd had no luck until he responded earlier today. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238230 - J< From rc040203 at freenet.de Tue Jul 24 19:07:49 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Jul 2007 21:07:49 +0200 Subject: F8 covered in this report In-Reply-To: <20070724200217.8e9ac4fb.bugs.michael@gmx.net> References: <20070724180759.8DB0D152131@buildsys.fedoraproject.org> <20070724200217.8e9ac4fb.bugs.michael@gmx.net> Message-ID: <1185304070.20980.72.camel@mccallum.corsepiu.local> On Tue, 2007-07-24 at 20:02 +0200, Michael Schwendt wrote: > This second message covers Rawhide as "F8". Packagers have received > mails in private, too. Do co-maintainers also receive them? From bugs.michael at gmx.net Tue Jul 24 18:58:14 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 24 Jul 2007 20:58:14 +0200 Subject: F8 covered in this report In-Reply-To: <1185304070.20980.72.camel@mccallum.corsepiu.local> References: <20070724180759.8DB0D152131@buildsys.fedoraproject.org> <20070724200217.8e9ac4fb.bugs.michael@gmx.net> <1185304070.20980.72.camel@mccallum.corsepiu.local> Message-ID: <20070724205814.5665618a.bugs.michael@gmx.net> On Tue, 24 Jul 2007 21:07:49 +0200, Ralf Corsepius wrote: > > This second message covers Rawhide as "F8". Packagers have received > > mails in private, too. > > Do co-maintainers also receive them? Yes. From rc040203 at freenet.de Tue Jul 24 19:32:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Jul 2007 21:32:13 +0200 Subject: F8 covered in this report In-Reply-To: <20070724205814.5665618a.bugs.michael@gmx.net> References: <20070724180759.8DB0D152131@buildsys.fedoraproject.org> <20070724200217.8e9ac4fb.bugs.michael@gmx.net> <1185304070.20980.72.camel@mccallum.corsepiu.local> <20070724205814.5665618a.bugs.michael@gmx.net> Message-ID: <1185305534.20980.95.camel@mccallum.corsepiu.local> On Tue, 2007-07-24 at 20:58 +0200, Michael Schwendt wrote: > On Tue, 24 Jul 2007 21:07:49 +0200, Ralf Corsepius wrote: > > > > This second message covers Rawhide as "F8". Packagers have received > > > mails in private, too. > > > > Do co-maintainers also receive them? > > Yes. Any reason, why these mails don't carry a CC: then? Ralf From bugs.michael at gmx.net Tue Jul 24 19:52:29 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 24 Jul 2007 21:52:29 +0200 Subject: F8 covered in this report In-Reply-To: <1185305534.20980.95.camel@mccallum.corsepiu.local> References: <20070724180759.8DB0D152131@buildsys.fedoraproject.org> <20070724200217.8e9ac4fb.bugs.michael@gmx.net> <1185304070.20980.72.camel@mccallum.corsepiu.local> <20070724205814.5665618a.bugs.michael@gmx.net> <1185305534.20980.95.camel@mccallum.corsepiu.local> Message-ID: <20070724215229.c64c805a.bugs.michael@gmx.net> On Tue, 24 Jul 2007 21:32:13 +0200, Ralf Corsepius wrote: > On Tue, 2007-07-24 at 20:58 +0200, Michael Schwendt wrote: > > On Tue, 24 Jul 2007 21:07:49 +0200, Ralf Corsepius wrote: > > > > > > This second message covers Rawhide as "F8". Packagers have received > > > > mails in private, too. > > > > > > Do co-maintainers also receive them? > > > > Yes. > Any reason, why these mails don't carry a CC: then? > > Ralf Yes, there's a reason. The broken upgrade path reports are sorted by recipient. A _single_ report per recipient. (That "bar@" is the co-owner [or observer] of one of "foo@"'s packages does not imply he should receive a summary of all of foo's broken upgrade paths.) From tla at rasmil.dk Wed Jul 25 10:44:06 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Wed, 25 Jul 2007 12:44:06 +0200 Subject: A easy review for a rainy day Message-ID: <46A72976.5030605@rasmil.dk> Hi. If somebody is looking for an easy review for a rainy day, i will be very pleased. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248991 Spec URL: http://timlau.fedorapeople.org/iniparse.spec SRPM URL: http://timlau.fedorapeople.org/iniparse-0.2-1.src.rpm Description: iniparse is an INI parser for Python which is API compatible with the standard library's ConfigParser, preserves structure of INI files (order of sections & options, indentation, comments, and blank lines are preserved when data is updated), and is more convenient to use. Thanks, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Wed Jul 25 12:13:24 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 25 Jul 2007 14:13:24 +0200 Subject: A easy review for a rainy day In-Reply-To: <46A72976.5030605@rasmil.dk> References: <46A72976.5030605@rasmil.dk> Message-ID: <46A73E64.20105@hhs.nl> Tim Lauridsen wrote: > Hi. > > If somebody is looking for an easy review for a rainy day, i will be > very pleased. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248991 > > > Spec URL: http://timlau.fedorapeople.org/iniparse.spec > SRPM URL: http://timlau.fedorapeople.org/iniparse-0.2-1.src.rpm > Description: iniparse is an INI parser for Python which is API compatible > with the standard library's ConfigParser, preserves structure of INI > files (order of sections & options, indentation, comments, and blank > lines are preserved when data is updated), and is more convenient to > use. > I'll trade you a review of the above for a review of, which is also easy: * Wildmidi soft midi wavetable synth lib (needed to add midi playback to gstreamer) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248597 Or even better a review of: * arm-gp2x-linux-binutils Cross Compiling GNU binutils targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234749 * arm-gp2x-linux-kernel-headers Kernel headers for Cross Compiling to arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242203 Which are both not all that hard either (the hard ones come further down in the dep chain) Thanks & Regards, Hans From j.w.r.degoede at hhs.nl Wed Jul 25 12:54:38 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 25 Jul 2007 14:54:38 +0200 Subject: A easy review for a rainy day In-Reply-To: <46A72976.5030605@rasmil.dk> References: <46A72976.5030605@rasmil.dk> Message-ID: <46A7480E.303@hhs.nl> Tim Lauridsen wrote: > Hi. > > If somebody is looking for an easy review for a rainy day, i will be > very pleased. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248991 > > > Spec URL: http://timlau.fedorapeople.org/iniparse.spec > SRPM URL: http://timlau.fedorapeople.org/iniparse-0.2-1.src.rpm > Description: iniparse is an INI parser for Python which is API compatible > with the standard library's ConfigParser, preserves structure of INI > files (order of sections & options, indentation, comments, and blank > lines are preserved when data is updated), and is more convenient to > use. > I'll trade you a review of the above for a review of, which is also easy: * Wildmidi Scrap that, that just got a reviewer, I'll trade you a review for a review of one of the 2 below then: * arm-gp2x-linux-binutils Cross Compiling GNU binutils targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234749 * arm-gp2x-linux-kernel-headers Kernel headers for Cross Compiling to arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242203 Which are both not all that hard either (the hard ones come further down in the dep chain) Thanks & Regards, Hans From ville.skytta at iki.fi Thu Jul 26 19:47:55 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 26 Jul 2007 22:47:55 +0300 Subject: Package orphan notice: upx, ucl, ksensors Message-ID: <200707262247.55559.ville.skytta@iki.fi> Hello, I've had upx, ucl and ksensors listed in Wiki as potentially orphaned for quite a while. I'm planning to go ahead and orphan them for real pretty soon now. They have no dependencies in Fedora as far as I can tell, and the packages should be in a good shape. If you're interested, now would be a good time to speak up. Also still listed as "potentially orphaned" are the following packages, these could really use a new or a co-maintainer: cvsgraph, cvsweb, openct, opensc, pcsc-perl, pcsc-tools. I've additionally contacted the maintainers of packages depending on perl-IPC-Run, perl-Set-IntSpan and perl-Text-Iconv as I no longer will have use for those three in the nearish future. From limb at jcomserv.net Thu Jul 26 21:39:38 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 26 Jul 2007 16:39:38 -0500 (CDT) Subject: Package orphan notice: upx, ucl, ksensors In-Reply-To: <200707262247.55559.ville.skytta@iki.fi> References: <200707262247.55559.ville.skytta@iki.fi> Message-ID: <4375.192.168.0.1.1185485978.squirrel@mail.jcomserv.net> > Hello, > > I've had upx, ucl and ksensors listed in Wiki as potentially orphaned for > quite a while. I'm planning to go ahead and orphan them for real pretty > soon > now. They have no dependencies in Fedora as far as I can tell, and the > packages should be in a good shape. If you're interested, now would be a > good time to speak up. I'll take upx and ucl. > Also still listed as "potentially orphaned" are the following packages, > these > could really use a new or a co-maintainer: cvsgraph, cvsweb, openct, > opensc, > pcsc-perl, pcsc-tools. I've additionally contacted the maintainers of > packages depending on perl-IPC-Run, perl-Set-IntSpan and perl-Text-Iconv > as I > no longer will have use for those three in the nearish future. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From john at curioussymbols.com Fri Jul 27 04:10:18 2007 From: john at curioussymbols.com (John Pye) Date: Fri, 27 Jul 2007 14:10:18 +1000 Subject: Looking for a review of 'sundials' library Message-ID: <46A9702A.2050600@curioussymbols.com> Hi all I'm looking for a review of the mathematical library 'sundials' that I recently added. Spec URL: http://jpye.fedorapeople.org/sundials/sundials.spec SRPM URL: http://jpye.fedorapeople.org/sundials/sundials-2.3.0-0.fc6.src.rpm This is a really nicely-written library (not by me) for solving nonlinear and ODE systems of equations as well as combined differential-and-algebraic systems of equations (DAEs). I have checked the SUNDIALS package with the RPM lint tools and have also built it in a clean-room environment using the OpenSUSE Build Service. And I have been using this RPM myself for a year or so. So I really don't anticipate any problems. But it's only my second package submitted to Fedora, so I would appreciate some feedback. I have another package (called ASCEND) that depends on SUNDIALS that I would like to add once this review is done. Anyone? Cheers JP From tibbs at math.uh.edu Fri Jul 27 07:06:53 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Jul 2007 02:06:53 -0500 Subject: Looking for a review of 'sundials' library In-Reply-To: <46A9702A.2050600@curioussymbols.com> References: <46A9702A.2050600@curioussymbols.com> Message-ID: >>>>> "JP" == John Pye writes: JP> Hi all I'm looking for a review of the mathematical library JP> 'sundials' that I recently added. JP> Spec URL: http://jpye.fedorapeople.org/sundials/sundials.spec What's the fedora_version, mandriva_version, suse_version and xubuntu stuff about? Even if such stuff was acceptable, nothing seems to set %{fedora_version}. This makes the package fail to even start building for me due to missing dependencies. - J< From j.w.r.degoede at hhs.nl Fri Jul 27 07:53:32 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 27 Jul 2007 09:53:32 +0200 Subject: Package orphan notice: upx, ucl, ksensors In-Reply-To: <4375.192.168.0.1.1185485978.squirrel@mail.jcomserv.net> References: <200707262247.55559.ville.skytta@iki.fi> <4375.192.168.0.1.1185485978.squirrel@mail.jcomserv.net> Message-ID: <46A9A47C.7080500@hhs.nl> Jon Ciesla wrote: >> Hello, >> >> I've had upx, ucl and ksensors listed in Wiki as potentially orphaned for >> quite a while. I'm planning to go ahead and orphan them for real pretty >> soon >> now. They have no dependencies in Fedora as far as I can tell, and the >> packages should be in a good shape. If you're interested, now would be a >> good time to speak up. > > I'll take upx and ucl. > >> as I >> no longer will have use for those three in the nearish future. >> And since I've become sortof a sensors expert I'll take ksensors, can you please file a CVS admin request to make me the new owner, thanks! Regards, Hans From laurent.rineau__fedora at normalesup.org Fri Jul 27 08:41:35 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Fri, 27 Jul 2007 10:41:35 +0200 Subject: Looking for a review of 'sundials' library In-Reply-To: References: <46A9702A.2050600@curioussymbols.com> Message-ID: <200707271041.35159@rineau.tsetse> On Friday 27 July 2007 09:06:53 Jason L Tibbitts III wrote: > >>>>> "JP" == John Pye writes: > > JP> Hi all I'm looking for a review of the mathematical library > JP> 'sundials' that I recently added. > > JP> Spec URL: http://jpye.fedorapeople.org/sundials/sundials.spec > > What's the fedora_version, mandriva_version, suse_version and xubuntu > stuff about? That seems to be macros setted by the openSUSE build system, that is becoming increasingly popular. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From bnocera at redhat.com Fri Jul 27 10:12:04 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 27 Jul 2007 11:12:04 +0100 Subject: taking libbtctl and gnome-bluetooth In-Reply-To: References: <1184265890.4117.195.camel@cookie.hadess.net> Message-ID: <1185531124.2848.18.camel@cookie.hadess.net> On Fri, 2007-07-13 at 20:58 +0200, Linus Walleij wrote: > On Thu, 12 Jul 2007, Bastien Nocera wrote: > > > In all cases, I'm upstream for those packages, and hoping to deprecate > > them in the long-term (hopefully before Fedora 9, although it looks > > unlikely for Fedora 8 right now). > > Just out of curiosity: what's gonna happen to them? hard deprecation, when the functionality is moved to bluez-gnome. > > The only package depending on those is gnome-phone-manager (which is due > > an upstream release as well). > > Anyone against me taking those? > > Do you want gnome-phone-manager as well? Else, I'm very happy if you want > to co-maintain it, so you can sync release of all three programs and roll > in a single Bodhi release. Co-maintainership of gnome-phone-manager would be good, but I don't expect major changes in libbtctl or gnome-bluetooth that would warrant build-chains in the future. Cheers From buildsys at fedoraproject.org Fri Jul 27 12:06:27 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 27 Jul 2007 08:06:27 -0400 (EDT) Subject: Package EVR problems in Fedora 2007-07-27 Message-ID: <20070727120627.CCDCC152133@buildsys.fedoraproject.org> alexl AT redhat.com: xdg-user-dirs F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) aportal AT univ-montp2.fr: pikloops FE6 > F8 (0:0.2.3-1.fc6 > 0:0.2.2-5.fc8) F7-updates-testing > F8 (0:0.2.3-1.fc7 > 0:0.2.2-5.fc8) berrange AT redhat.com: python-virtinst F7-updates-testing > F8 (0:0.200.0-2.fc7 > 0:0.200.0-1.fc8) cbalint AT redhat.com: gdal FE6 > F7 (0:1.4.2-2.fc6 > 0:1.4.1-3.fc7) FE6 > F8 (0:1.4.2-2.fc6 > 0:1.4.1-4.fc8) grass FE6 > F7 (0:6.2.2-1.fc6 > 0:6.2.1-16.fc7) FE6 > F8 (0:6.2.2-1.fc6 > 0:6.2.2-0.2.RC1.fc8) 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) davidz AT redhat.com: dbus-python F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) hal-info F7-updates-testing > F8 (0:20070725-1.fc7 > 0:20070516-2.fc7) redhat-artwork F7-updates > F8 (0:7.0.0-11.fc7 > 0:7.0.0-10.fc8) dlutter AT redhat.com: puppet F7-updates-testing > F8 (0:0.23.1-1.fc7 > 0:0.23.0-1.fc8) dmitry AT butskoy.name: nail FE6 > F8 (0:12.3-1.fc6 > 0:12.2-1.fc7) F7-updates-testing > F8 (0:12.3-1.fc7 > 0:12.2-1.fc7) ed AT eh3.com: scrip FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) enrico.scholz AT informatik.tu-chemnitz.de: fedora-usermgmt FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (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) FE6 > F8 (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.16-1.fc6 > 0:1.06.11-2.fc7) foolish AT guezz.net: gtranslator F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) perl-Net-Libdnet F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) giallu AT gmail.com: sysprof-kmod F7-updates > F8 (0:1.0.8-1.2.6.22.1_27.fc7 > 0:1.0.8-1.2.6.21_1.3228.fc7) hellwolf.misty AT gmail.com: fuse-convmvfs FE6 > F8 (0:0.2.4-2.fc6 > 0:0.2.4-1.fc8) F7-updates > F8 (0:0.2.4-3.fc7 > 0:0.2.4-1.fc8) jakub AT redhat.com: gcc FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) jeff.gilchrist AT gmail.com: pbzip2 F7-updates-testing > F8 (0:1.0.2-2.fc7 > 0:1.0.1-1.fc7) jeff AT ocjtech.us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) jeremy AT hinegardner.org: nginx F7-updates-testing > F8 (0:0.5.29-1.fc7 > 0:0.5.28-1.fc8) ragel F7-updates-testing > F8 (0:5.23-1.fc7 > 0:5.22-1.fc8) jjohnstn AT redhat.com: eclipse-cdt FC6-updates > F7 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) FC6-updates > F8 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) jpo AT di.uminho.pt: syslog-ng F7-updates-testing > F8 (0:2.0.5-1.fc7 > 0:2.0.4-4.fc8) limb AT jcomserv.net: drupal F7-updates > F8 (0:5.2-1.fc7 > 0:5.1-5.fc8) lmacken AT redhat.com: gobby F7-updates-testing > F8 (0:0.4.4-1.fc7 > 0:0.4.3-1.fc7) luya_tfz AT thefinalzone.com: gdesklets F7-updates > F8 (0:0.35.4-8.fc7 > 0:0.35.4-7.1.fc8) matthias AT rpmforge.net: lighttpd FE6 > F8 (0:1.4.16-1.fc6 > 0:1.4.15-1.fc7) F7-updates > F8 (0:1.4.16-1.fc7 > 0:1.4.15-1.fc7) mcepl AT redhat.com: JSDoc F7-updates > F8 (0:1.10.2-4.fc7 > 0:1.10.2-3.fc8) 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-4.fc6 > 0:2.1.1-2.fc6) mfleming+rpm AT enlartenment.com: pfqueue F7-updates > F8 (0:0.5.6-5.fc7 > 0:0.5.6-4.fc8) mikeb AT redhat.com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) mmcgrath AT redhat.com: phpMyAdmin FE6 > F7 (0:2.10.3-1.fc6 > 0:2.10.0.2-3.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) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) pawsa AT theochem.kth.se: balsa FE5 > F7 (0:2.3.16-3.fc5 > 0:2.3.14-1.fc7) FE6 > F7 (0:2.3.17-1.fc6 > 0:2.3.14-1.fc7) peter AT thecodergeek.com: deluge FE6 > F8 (0:0.5.3-1.fc6 > 0:0.5.2.90-1.fc8) F7-updates-testing > F8 (0:0.5.3-1.fc7 > 0:0.5.2.90-1.fc8) rc040203 AT freenet.de: perl-DBIx-DBSchema FE6 > F7 (0:0.33-1.fc6 > 0:0.32-1.fc7) perl-File-Remove FE6 > F7 (0:0.37-1.fc6 > 0:0.34-1.fc7) 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) perl-Want FE6 > F7 (0:0.15-1.fc6 > 0:0.14-1.fc7) FE6 > F8 (0:0.15-1.fc6 > 0:0.14-1.fc7) rdieter AT math.unl.edu: kdeartwork-extras FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) lyx F7-updates-testing > F8 (0:1.5.0-1.fc7.1 > 0:1.5.0-0.10.rc2.fc8) maxima FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) FE6 > F7-updates (0:5.12.0-3.fc6 > 0:5.12.0-2.fc7) redhat-bugzilla AT camperquake.de: audacious-plugins FE6 > F8 (0:1.3.5-2.fc6 > 0:1.3.5-1.fc8) F7-updates > F8 (0:1.3.5-2.fc7 > 0:1.3.5-1.fc8) s.adam AT diffingo.com: fwbackups FE6 > F8 (0:1.43.1-2.fc6 > 0:1.43.1-1.fc8) F7-updates > F8 (0:1.43.1-2.fc7 > 0:1.43.1-1.fc8) sandmann AT redhat.com: libXi F7-updates > F8 (0:1.1.1-1.fc7 > 0:1.0.4-1) seg AT haxxed.com: rosegarden4 FE5 > F8 (0:1.5.1-1.fc5 > 0:1.4.0-1.fc7) FE6 > F8 (0:1.5.1-1.fc6 > 0:1.4.0-1.fc7) F7-updates-testing > F8 (0:1.5.1-1.fc7.1 > 0:1.4.0-1.fc7) shahms AT shahms.com: bzr F7-updates-testing > F8 (0:0.18-1.fc7 > 0:0.17-2.fc8) bzr-gtk F7-updates-testing > F8 (0:0.18.0-1.fc7 > 0:0.17.0-1.fc8) bzrtools F7-updates-testing > F8 (0:0.18.0-1.fc7 > 0:0.17.1-1.fc8) skvidal AT linux.duke.edu: yum-utils F7-updates-testing > F8 (0:1.1.6-1.fc7 > 0:1.1.5-1.fc8) splinux AT fedoraproject.org: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) steved AT redhat.com: libgssapi F7-updates-testing > F8 (0:0.11-1.fc7 > 0:0.10-3.fc7) nfs-utils F7-updates-testing > F8 (1:1.1.0-1.fc7 > 1:1.0.12-7.fc8) nfs-utils-lib F7-updates-testing > F8 (0:1.0.8-10.fc7 > 0:1.0.8-8.fc7) stransky AT redhat.com: alsa-lib F7 > F8 (0:1.0.14-0.4.rc3.fc7 > 0:1.0.14-0.4.fc8) alsa-utils F7-updates > F8 (0:1.0.14-0.7.rc2.fc7 > 0:1.0.14-0.7.fc8) than AT redhat.com: kdemultimedia FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) kdepim F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) veillard AT redhat.com: libxml2 FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) wolters.liste AT gmx.net: speedcrunch FE6 > F7 (0:0.8-4.fc6 > 0:0.7-1.fc7) FE6 > F8 (0:0.8-4.fc6 > 0:0.7-1.fc7) ---------------------------------------------------------------------- alsa-lib: stransky AT redhat.com F7 > F8 (0:1.0.14-0.4.rc3.fc7 > 0:1.0.14-0.4.fc8) alsa-utils: stransky AT redhat.com F7-updates > F8 (0:1.0.14-0.7.rc2.fc7 > 0:1.0.14-0.7.fc8) audacious-plugins: redhat-bugzilla AT camperquake.de FE6 > F8 (0:1.3.5-2.fc6 > 0:1.3.5-1.fc8) F7-updates > F8 (0:1.3.5-2.fc7 > 0:1.3.5-1.fc8) balsa: pawsa AT theochem.kth.se FE5 > F7 (0:2.3.16-3.fc5 > 0:2.3.14-1.fc7) FE6 > F7 (0:2.3.17-1.fc6 > 0:2.3.14-1.fc7) bzr: shahms AT shahms.com F7-updates-testing > F8 (0:0.18-1.fc7 > 0:0.17-2.fc8) bzr-gtk: shahms AT shahms.com F7-updates-testing > F8 (0:0.18.0-1.fc7 > 0:0.17.0-1.fc8) bzrtools: shahms AT shahms.com F7-updates-testing > F8 (0:0.18.0-1.fc7 > 0:0.17.1-1.fc8) dbus-python: davidz AT redhat.com F7-updates-testing > F8 (0:0.82.0-2.fc7 > 0:0.82.0-1.fc8) deluge: peter AT thecodergeek.com FE6 > F8 (0:0.5.3-1.fc6 > 0:0.5.2.90-1.fc8) F7-updates-testing > F8 (0:0.5.3-1.fc7 > 0:0.5.2.90-1.fc8) drupal: limb AT jcomserv.net F7-updates > F8 (0:5.2-1.fc7 > 0:5.1-5.fc8) eclipse-cdt: jjohnstn AT redhat.com FC6-updates > F7 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) FC6-updates > F8 (1:3.1.2-4.fc6 > 1:3.1.2-3.fc7) fedora-usermgmt: enrico.scholz AT informatik.tu-chemnitz.de FE6 > F7 (0:0.10-1.fc6 > 0:0.9-2.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-4.fc6 > 0:2.1.1-2.fc6) fuse-convmvfs: hellwolf.misty AT gmail.com FE6 > F8 (0:0.2.4-2.fc6 > 0:0.2.4-1.fc8) F7-updates > F8 (0:0.2.4-3.fc7 > 0:0.2.4-1.fc8) fwbackups: s.adam AT diffingo.com FE6 > F8 (0:1.43.1-2.fc6 > 0:1.43.1-1.fc8) F7-updates > F8 (0:1.43.1-2.fc7 > 0:1.43.1-1.fc8) gcc: jakub AT redhat.com FC6-updates > F7 (0:4.1.2-13.fc6 > 0:4.1.2-12) gdal: cbalint AT redhat.com FE6 > F7 (0:1.4.2-2.fc6 > 0:1.4.1-3.fc7) FE6 > F8 (0:1.4.2-2.fc6 > 0:1.4.1-4.fc8) gdesklets: luya_tfz AT thefinalzone.com F7-updates > F8 (0:0.35.4-8.fc7 > 0:0.35.4-7.1.fc8) gobby: lmacken AT redhat.com F7-updates-testing > F8 (0:0.4.4-1.fc7 > 0:0.4.3-1.fc7) grass: cbalint AT redhat.com FE6 > F7 (0:6.2.2-1.fc6 > 0:6.2.1-16.fc7) FE6 > F8 (0:6.2.2-1.fc6 > 0:6.2.2-0.2.RC1.fc8) gtranslator: foolish AT guezz.net F7-updates > F8 (0:1.1.7-4.fc7 > 0:1.1.7-3.fc8) hal-info: davidz AT redhat.com F7-updates-testing > F8 (0:20070725-1.fc7 > 0:20070516-2.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) FC5-updates > F8 (2:0.55-4.fc5 > 2:0.55-3.fc8) jrtplib: jeff AT ocjtech.us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) JSDoc: mcepl AT redhat.com F7-updates > F8 (0:1.10.2-4.fc7 > 0:1.10.2-3.fc8) kdeartwork-extras: rdieter AT math.unl.edu FE6 > F7 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) FE6 > F8 (0:3.5.7-2.fc6 > 0:3.5.6-3.fc7) kdemultimedia: than AT redhat.com FC6-updates > F7-updates (6:3.5.7-1.fc6 > 6:3.5.7-0.1.fc7) kdepim: than AT redhat.com F7-updates > F8 (6:3.5.7-3.fc7 > 6:3.5.7-2.fc8) libgssapi: steved AT redhat.com F7-updates-testing > F8 (0:0.11-1.fc7 > 0:0.10-3.fc7) libtasn1: enrico.scholz AT informatik.tu-chemnitz.de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE5 > F8 (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) FE6 > F8 (0:0.3.10-1.fc6 > 0:0.3.9-1.fc7) libXi: sandmann AT redhat.com F7-updates > F8 (0:1.1.1-1.fc7 > 0:1.0.4-1) libxml2: veillard AT redhat.com FC6-updates > F8 (0:2.6.29-1.fc6 > 0:2.6.29-1) F7-updates > F8 (0:2.6.29-1.fc7 > 0:2.6.29-1) lighttpd: matthias AT rpmforge.net FE6 > F8 (0:1.4.16-1.fc6 > 0:1.4.15-1.fc7) F7-updates > F8 (0:1.4.16-1.fc7 > 0:1.4.15-1.fc7) lostirc: splinux AT fedoraproject.org FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) FE6 > F8 (0:0.4.6-3.fc6 > 0:0.4.6-2.fc8) lyx: rdieter AT math.unl.edu F7-updates-testing > F8 (0:1.5.0-1.fc7.1 > 0:1.5.0-0.10.rc2.fc8) maxima: rdieter AT math.unl.edu FE5 > F7-updates (0:5.12.0-3.fc5 > 0:5.12.0-2.fc7) 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) nail: dmitry AT butskoy.name FE6 > F8 (0:12.3-1.fc6 > 0:12.2-1.fc7) F7-updates-testing > F8 (0:12.3-1.fc7 > 0:12.2-1.fc7) nfs-utils: steved AT redhat.com F7-updates-testing > F8 (1:1.1.0-1.fc7 > 1:1.0.12-7.fc8) nfs-utils-lib: steved AT redhat.com F7-updates-testing > F8 (0:1.0.8-10.fc7 > 0:1.0.8-8.fc7) nginx: jeremy AT hinegardner.org F7-updates-testing > F8 (0:0.5.29-1.fc7 > 0:0.5.28-1.fc8) pbzip2: jeff.gilchrist AT gmail.com F7-updates-testing > F8 (0:1.0.2-2.fc7 > 0:1.0.1-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-DBIx-DBSchema: rc040203 AT freenet.de FE6 > F7 (0:0.33-1.fc6 > 0:0.32-1.fc7) perl-Event: cweyl AT alumni.drew.edu FE6 > F7 (0:1.09-1.fc6 > 0:1.08-1.fc7) perl-File-Remove: rc040203 AT freenet.de FE6 > F7 (0:0.37-1.fc6 > 0:0.34-1.fc7) 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-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-Net-Libdnet: foolish AT guezz.net F7-updates > F8 (0:0.01-3.fc7.1 > 0:0.01-2.fc8) perl-Nmap-Parser: foolish AT guezz.net F7-updates > F8 (0:1.05-4.fc7 > 0:1.05-3.fc8) 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-Want: rc040203 AT freenet.de FE6 > F7 (0:0.15-1.fc6 > 0:0.14-1.fc7) FE6 > F8 (0:0.15-1.fc6 > 0:0.14-1.fc7) pfqueue: mfleming+rpm AT enlartenment.com F7-updates > F8 (0:0.5.6-5.fc7 > 0:0.5.6-4.fc8) phpMyAdmin: mmcgrath AT redhat.com FE6 > F7 (0:2.10.3-1.fc6 > 0:2.10.0.2-3.fc7) pikloops: aportal AT univ-montp2.fr FE6 > F8 (0:0.2.3-1.fc6 > 0:0.2.2-5.fc8) F7-updates-testing > F8 (0:0.2.3-1.fc7 > 0:0.2.2-5.fc8) puppet: dlutter AT redhat.com F7-updates-testing > F8 (0:0.23.1-1.fc7 > 0:0.23.0-1.fc8) python-cheetah: mikeb AT redhat.com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) FE6 > F8 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-virtinst: berrange AT redhat.com F7-updates-testing > F8 (0:0.200.0-2.fc7 > 0:0.200.0-1.fc8) ragel: jeremy AT hinegardner.org F7-updates-testing > F8 (0:5.23-1.fc7 > 0:5.22-1.fc8) redhat-artwork: davidz AT redhat.com F7-updates > F8 (0:7.0.0-11.fc7 > 0:7.0.0-10.fc8) rosegarden4: seg AT haxxed.com FE5 > F8 (0:1.5.1-1.fc5 > 0:1.4.0-1.fc7) FE6 > F8 (0:1.5.1-1.fc6 > 0:1.4.0-1.fc7) F7-updates-testing > F8 (0:1.5.1-1.fc7.1 > 0:1.4.0-1.fc7) scrip: ed AT eh3.com FE6 > F7 (0:1.4-7.fc6 > 0:1.4-6.fc6) FE6 > F8 (0:1.4-7.fc6 > 0:1.4-6.fc6) speedcrunch: wolters.liste AT gmx.net FE6 > F7 (0:0.8-4.fc6 > 0:0.7-1.fc7) FE6 > F8 (0:0.8-4.fc6 > 0:0.7-1.fc7) syslog-ng: jpo AT di.uminho.pt F7-updates-testing > F8 (0:2.0.5-1.fc7 > 0:2.0.4-4.fc8) sysprof-kmod: giallu AT gmail.com F7-updates > F8 (0:1.0.8-1.2.6.22.1_27.fc7 > 0:1.0.8-1.2.6.21_1.3228.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) xdg-user-dirs: alexl AT redhat.com F7-updates > F8 (0:0.8-3.fc7 > 0:0.8-2.fc8) 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.16-1.fc6 > 0:1.06.11-2.fc7) yum-utils: skvidal AT linux.duke.edu F7-updates-testing > F8 (0:1.1.6-1.fc7 > 0:1.1.5-1.fc8) From cbalint at redhat.com Fri Jul 27 13:18:13 2007 From: cbalint at redhat.com (Balint Cristian) Date: Fri, 27 Jul 2007 15:18:13 +0200 Subject: tag libgeotiff-1.2.4-0.3.rc1.fc7 from update-candidates -> update Message-ID: <200707271518.13951.cbalint@redhat.com> Hello ! I would like to move into updates from update-candidates this package: libgeotiff-1.2.4-0.3.rc1.fc7 Reason: 1) package is new but is needed by latest gdal which will be a bugfix release GeoTIFF enabled one. 2) without this i cannot build bugfix release of gdal plus enable the long waited geotiff functions in gdal. 3) without geotiff support gdal is pretty useless, we solved license proble of geotiff recently so i would like to enable it. 4) grass bugfix release is olso pending on top of these twho sub libraries. I did the same for FC-6 i had no problem. -- Balint Cristian (Red Hat Release Engineering Team) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From berrange at redhat.com Fri Jul 27 13:24:12 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 27 Jul 2007 14:24:12 +0100 Subject: Package EVR problems in Fedora 2007-07-27 In-Reply-To: <20070727120627.CCDCC152133@buildsys.fedoraproject.org> References: <20070727120627.CCDCC152133@buildsys.fedoraproject.org> Message-ID: <20070727132412.GA6698@redhat.com> On Fri, Jul 27, 2007 at 08:06:27AM -0400, buildsys at fedoraproject.org wrote: > berrange AT redhat.com: > python-virtinst > F7-updates-testing > F8 (0:0.200.0-2.fc7 > 0:0.200.0-1.fc8) This report is bogus. I built the F7 and F8 versions within minutes of each other yesterday mid-afternoon. The F8 version is 0:0.200.0-2.fc8 Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From paul at city-fan.org Fri Jul 27 13:34:30 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 27 Jul 2007 14:34:30 +0100 Subject: Package EVR problems in Fedora 2007-07-27 In-Reply-To: <20070727132412.GA6698@redhat.com> References: <20070727120627.CCDCC152133@buildsys.fedoraproject.org> <20070727132412.GA6698@redhat.com> Message-ID: <46A9F466.6060406@city-fan.org> Daniel P. Berrange wrote: > On Fri, Jul 27, 2007 at 08:06:27AM -0400, buildsys at fedoraproject.org wrote: >> berrange AT redhat.com: >> python-virtinst >> F7-updates-testing > F8 (0:0.200.0-2.fc7 > 0:0.200.0-1.fc8) > > This report is bogus. I built the F7 and F8 versions within minutes > of each other yesterday mid-afternoon. The F8 version is 0:0.200.0-2.fc8 The F8 version is invisible to the script (and Rawhide users) due to the Test1 freeze, hence the report. Paul. From bugs.michael at gmx.net Fri Jul 27 13:42:09 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 27 Jul 2007 15:42:09 +0200 Subject: Package EVR problems in Fedora 2007-07-27 In-Reply-To: <20070727132412.GA6698@redhat.com> References: <20070727120627.CCDCC152133@buildsys.fedoraproject.org> <20070727132412.GA6698@redhat.com> Message-ID: <20070727154209.94e24be2.bugs.michael@gmx.net> On Fri, 27 Jul 2007 14:24:12 +0100, Daniel P. Berrange wrote: > On Fri, Jul 27, 2007 at 08:06:27AM -0400, buildsys fedoraproject org wrote: > > berrange AT redhat.com: > > python-virtinst > > F7-updates-testing > F8 (0:0.200.0-2.fc7 > 0:0.200.0-1.fc8) > > This report is bogus. I built the F7 and F8 versions within minutes > of each other yesterday mid-afternoon. The F8 version is 0:0.200.0-2.fc8 Your package is not in the rawhide repodata, and it is not tagged f8-test1 either. That's all that counts. From berrange at redhat.com Fri Jul 27 13:46:09 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 27 Jul 2007 14:46:09 +0100 Subject: Package EVR problems in Fedora 2007-07-27 In-Reply-To: <20070727154209.94e24be2.bugs.michael@gmx.net> References: <20070727120627.CCDCC152133@buildsys.fedoraproject.org> <20070727132412.GA6698@redhat.com> <20070727154209.94e24be2.bugs.michael@gmx.net> Message-ID: <20070727134609.GC6698@redhat.com> On Fri, Jul 27, 2007 at 03:42:09PM +0200, Michael Schwendt wrote: > On Fri, 27 Jul 2007 14:24:12 +0100, Daniel P. Berrange wrote: > > > On Fri, Jul 27, 2007 at 08:06:27AM -0400, buildsys fedoraproject org wrote: > > > berrange AT redhat.com: > > > python-virtinst > > > F7-updates-testing > F8 (0:0.200.0-2.fc7 > 0:0.200.0-1.fc8) > > > > This report is bogus. I built the F7 and F8 versions within minutes > > of each other yesterday mid-afternoon. The F8 version is 0:0.200.0-2.fc8 > > Your package is not in the rawhide repodata, and it is not tagged f8-test1 > either. That's all that counts. Given that this situation will resolve itself as soon as the test1 freeze is release, IMHO, the script should not complain. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From dakingun at gmail.com Fri Jul 27 13:47:02 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Fri, 27 Jul 2007 09:47:02 -0400 Subject: tag libgeotiff-1.2.4-0.3.rc1.fc7 from update-candidates -> update In-Reply-To: <200707271518.13951.cbalint@redhat.com> References: <200707271518.13951.cbalint@redhat.com> Message-ID: On 7/27/07, Balint Cristian wrote: > > Hello ! > > I would like to move into updates from update-candidates this package: > You'll need to follow the update procedure using bodhi, see step 7 of http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo. Deji From bugs.michael at gmx.net Fri Jul 27 13:43:17 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 27 Jul 2007 15:43:17 +0200 Subject: tag libgeotiff-1.2.4-0.3.rc1.fc7 from update-candidates -> update In-Reply-To: <200707271518.13951.cbalint@redhat.com> References: <200707271518.13951.cbalint@redhat.com> Message-ID: <20070727154317.7c005b26.bugs.michael@gmx.net> On Fri, 27 Jul 2007 15:18:13 +0200, Balint Cristian wrote: > > Hello ! > > I would like to move into updates from update-candidates this package: > > libgeotiff-1.2.4-0.3.rc1.fc7 > > Reason: > 1) package is new but is needed by latest gdal which will be a bugfix release GeoTIFF enabled one. > 2) without this i cannot build bugfix release of gdal plus enable the long waited geotiff functions in gdal. > 3) without geotiff support gdal is pretty useless, we solved license proble of geotiff recently so i would like to enable it. > 4) grass bugfix release is olso pending on top of these twho sub libraries. > > I did the same for FC-6 i had no problem. Do it with bodhi, the F7 Updates System. From bugs.michael at gmx.net Fri Jul 27 13:50:19 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 27 Jul 2007 15:50:19 +0200 Subject: Package EVR problems in Fedora 2007-07-27 In-Reply-To: <20070727134609.GC6698@redhat.com> References: <20070727120627.CCDCC152133@buildsys.fedoraproject.org> <20070727132412.GA6698@redhat.com> <20070727154209.94e24be2.bugs.michael@gmx.net> <20070727134609.GC6698@redhat.com> Message-ID: <20070727155019.24b33cd2.bugs.michael@gmx.net> On Fri, 27 Jul 2007 14:46:09 +0100, Daniel P. Berrange wrote: > On Fri, Jul 27, 2007 at 03:42:09PM +0200, Michael Schwendt wrote: > > On Fri, 27 Jul 2007 14:24:12 +0100, Daniel P. Berrange wrote: > > > > > On Fri, Jul 27, 2007 at 08:06:27AM -0400, buildsys fedoraproject org wrote: > > > > berrange AT redhat.com: > > > > python-virtinst > > > > F7-updates-testing > F8 (0:0.200.0-2.fc7 > 0:0.200.0-1.fc8) > > > > > > This report is bogus. I built the F7 and F8 versions within minutes > > > of each other yesterday mid-afternoon. The F8 version is 0:0.200.0-2.fc8 > > > > Your package is not in the rawhide repodata, and it is not tagged f8-test1 > > either. That's all that counts. > > Given that this situation will resolve itself as soon as the test1 freeze > is release, IMHO, the script should not complain. > > Dan. The only sane work-around *during the freeze* would be to exclude F7 updates-testing. Everything else remains a broken upgrade path for the F8 Test 1 testers. From cbalint at redhat.com Fri Jul 27 13:58:26 2007 From: cbalint at redhat.com (Balint Cristian) Date: Fri, 27 Jul 2007 15:58:26 +0200 Subject: tag libgeotiff-1.2.4-0.3.rc1.fc7 from update-candidates -> update In-Reply-To: <20070727154317.7c005b26.bugs.michael@gmx.net> References: <200707271518.13951.cbalint@redhat.com> <20070727154317.7c005b26.bugs.michael@gmx.net> Message-ID: <200707271558.26826.cbalint@redhat.com> On Friday 27 July 2007, Michael Schwendt wrote: > libgeotiff-1.2.4-0.3.rc1.fc7 Sorted out. Thanks everyone for support. ~cristian -------------- 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 Jul 27 14:06:37 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 27 Jul 2007 23:06:37 +0900 Subject: Package EVR problems in Fedora 2007-07-27 In-Reply-To: <20070727154209.94e24be2.bugs.michael@gmx.net> References: <20070727120627.CCDCC152133@buildsys.fedoraproject.org> <20070727132412.GA6698@redhat.com> <20070727154209.94e24be2.bugs.michael@gmx.net> Message-ID: <46A9FBED.4030809@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote, at 07/27/2007 10:42 PM +9:00: > On Fri, 27 Jul 2007 14:24:12 +0100, Daniel P. Berrange wrote: > >> On Fri, Jul 27, 2007 at 08:06:27AM -0400, buildsys fedoraproject org wrote: >>> berrange AT redhat.com: >>> python-virtinst >>> F7-updates-testing > F8 (0:0.200.0-2.fc7 > 0:0.200.0-1.fc8) >> This report is bogus. I built the F7 and F8 versions within minutes >> of each other yesterday mid-afternoon. The F8 version is 0:0.200.0-2.fc8 > > Your package is not in the rawhide repodata, and it is not tagged f8-test1 > either. That's all that counts. Well, I don't know how this EVR problem report is created, however is it possible that we compare F7 repodata and koji repodata, i.e. the repodata on http://koji.fedoraproject.org/static-repos/dist-f8-build-current/i386/repodata/ while rawhide is frozen until F8T1? Mamoru From triad at df.lth.se Fri Jul 27 14:56:40 2007 From: triad at df.lth.se (Linus Walleij) Date: Fri, 27 Jul 2007 16:56:40 +0200 (CEST) Subject: taking libbtctl and gnome-bluetooth In-Reply-To: <1185531124.2848.18.camel@cookie.hadess.net> References: <1184265890.4117.195.camel@cookie.hadess.net> <1185531124.2848.18.camel@cookie.hadess.net> Message-ID: On Fri, 27 Jul 2007, Bastien Nocera wrote: > Co-maintainership of gnome-phone-manager would be good, but I don't > expect major changes in libbtctl or gnome-bluetooth that would warrant > build-chains in the future. OK sounds good, please just change the CVS for g-p-m or gnokii (as of recently, to great succes) whenever you feel the need for it. Linus From ville.skytta at iki.fi Fri Jul 27 16:03:57 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 27 Jul 2007 19:03:57 +0300 Subject: Package orphan notice: upx, ucl, ksensors In-Reply-To: <46A9A47C.7080500@hhs.nl> References: <200707262247.55559.ville.skytta@iki.fi> <4375.192.168.0.1.1185485978.squirrel@mail.jcomserv.net> <46A9A47C.7080500@hhs.nl> Message-ID: <200707271903.58368.ville.skytta@iki.fi> On Friday 27 July 2007, Hans de Goede wrote: > Jon Ciesla wrote: > >> Hello, > >> > >> I've had upx, ucl and ksensors listed in Wiki as potentially orphaned > >> for quite a while. I'm planning to go ahead and orphan them for real > >> pretty soon > >> now. They have no dependencies in Fedora as far as I can tell, and the > >> packages should be in a good shape. If you're interested, now would be > >> a good time to speak up. > > > > I'll take upx and ucl. > > > >> as I > >> no longer will have use for those three in the nearish future. > > And since I've become sortof a sensors expert I'll take ksensors, can you > please file a CVS admin request to make me the new owner, thanks! Done, thanks, and thanks to Jon for taking ucl and upx. From debarshi.ray at gmail.com Fri Jul 27 18:20:14 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 27 Jul 2007 23:50:14 +0530 Subject: Reviewer for Bouml. Message-ID: <3170f42f0707271120o496681c4u89fa5cf3651bc4f@mail.gmail.com> I am looking for someone to review: * https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247417 -- bouml * https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249892 -- bouml-doc I do not mean to be pushy but I personally know a lot of people itching for this to become a part of Fedora and is also part of https://fedoraproject.org/wiki/PackageMaintainers/WishList Also there has been an upstream release while waiting for a reviewer to appear, and it is not very interesting to keep on doing version bumps through Bugzilla. :-) Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From tibbs at math.uh.edu Fri Jul 27 20:21:04 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Jul 2007 15:21:04 -0500 Subject: Reviewer for Bouml. In-Reply-To: <3170f42f0707271120o496681c4u89fa5cf3651bc4f@mail.gmail.com> References: <3170f42f0707271120o496681c4u89fa5cf3651bc4f@mail.gmail.com> Message-ID: >>>>> "DR" == Debarshi 'Rishi' Ray writes: DR> I do not mean to be pushy but I personally know a lot of people DR> itching for this to become a part of Fedora and is also part of DR> https://fedoraproject.org/wiki/PackageMaintainers/WishList Then why aren't any of those people willing to review it? - J< From j.w.r.degoede at hhs.nl Fri Jul 27 22:46:24 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 28 Jul 2007 00:46:24 +0200 Subject: Need help with weird builderror Message-ID: <46AA75C0.2070901@hhs.nl> Hi all, Does anyone have any hints for this error? : http://koji.fedoraproject.org/koji/getfile?taskID=80031&name=build.log And then specifically: /bin/sh ../libtool --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -g -o libWildMidi.la -rpath /usr/lib64 -shared -lm -lc -no-undefined libWildMidi_la-wildmidi_lib.lo *** Warning: linker path does not have real file for library -lm. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libm but no candidates were found. (...for file magic test) *** Warning: linker path does not have real file for library -lc. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libc but no candidates were found. (...for file magic test) *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. --- I've compared the configure output with a local x86_64 build and they are identical, so are the libtool invocations, yet here it works and on the buildsys it does the above? Regards, Hans From bugs.michael at gmx.net Sat Jul 28 00:05:58 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 28 Jul 2007 02:05:58 +0200 Subject: Package EVR problems in Fedora 2007-07-27 In-Reply-To: <46A9FBED.4030809@ioa.s.u-tokyo.ac.jp> References: <20070727120627.CCDCC152133@buildsys.fedoraproject.org> <20070727132412.GA6698@redhat.com> <20070727154209.94e24be2.bugs.michael@gmx.net> <46A9FBED.4030809@ioa.s.u-tokyo.ac.jp> Message-ID: <20070728020558.2726d91d.bugs.michael@gmx.net> On Fri, 27 Jul 2007 23:06:37 +0900, Mamoru Tasaka wrote: > Michael Schwendt wrote, at 07/27/2007 10:42 PM +9:00: > > On Fri, 27 Jul 2007 14:24:12 +0100, Daniel P. Berrange wrote: > > > >> On Fri, Jul 27, 2007 at 08:06:27AM -0400, buildsys fedoraproject org wrote: > >>> berrange AT redhat.com: > >>> python-virtinst > >>> F7-updates-testing > F8 (0:0.200.0-2.fc7 > 0:0.200.0-1.fc8) > >> This report is bogus. I built the F7 and F8 versions within minutes > >> of each other yesterday mid-afternoon. The F8 version is 0:0.200.0-2.fc8 > > > > Your package is not in the rawhide repodata, and it is not tagged f8-test1 > > either. That's all that counts. > > Well, I don't know how this EVR problem report is created, however It's a script in fedora cvs /fedora/upgradecheck which I've run manually recently after we had run it automatically after every Extras push. > is it possible that we compare F7 repodata and koji repodata, i.e. > the repodata on > http://koji.fedoraproject.org/static-repos/dist-f8-build-current/i386/repodata/ > while rawhide is frozen until F8T1? Yes, good suggestion. Thanks for that. But meanwhile I've been told some people in IRC spread false rumours about the results of this script. Like claiming that the report would be useless as it would only report false positives because the FE release procedure doesn't push packages through updates-testing like bodhi does. *urgh* That is a false claim. Lots of issues in the report are unfixed for many weeks. Another packager told me he ignores the private reports because he boycotts bodhi until there will be a "make release" or similar. With opposition like that and spreading of false rumours, I rather stop running the script altogether. It has become another thankless effort with no backup from FESCo. From kwizart at gmail.com Sat Jul 28 02:40:05 2007 From: kwizart at gmail.com (KH KH) Date: Sat, 28 Jul 2007 04:40:05 +0200 Subject: Need help with weird builderror In-Reply-To: <46AA75C0.2070901@hhs.nl> References: <46AA75C0.2070901@hhs.nl> Message-ID: 2007/7/28, Hans de Goede : > Hi all, > > Does anyone have any hints for this error? : > http://koji.fedoraproject.org/koji/getfile?taskID=80031&name=build.log Hello Hans Don't you forgot to add ? BuildRequires: glibc-headers Nicolas (kwizart) From debarshi.ray at gmail.com Sat Jul 28 02:58:08 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 28 Jul 2007 08:28:08 +0530 Subject: Reviewer for Bouml. In-Reply-To: References: <3170f42f0707271120o496681c4u89fa5cf3651bc4f@mail.gmail.com> Message-ID: <3170f42f0707271958u6597da8bpae3a326f329a73f9@mail.gmail.com> > DR> I do not mean to be pushy but I personally know a lot of people > DR> itching for this to become a part of Fedora and is also part of > DR> https://fedoraproject.org/wiki/PackageMaintainers/WishList > Then why aren't any of those people willing to review it? They are all Bouml users, but not capable enough to review a package. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From j.w.r.degoede at hhs.nl Sat Jul 28 08:47:48 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 28 Jul 2007 10:47:48 +0200 Subject: Reviewer for Bouml. In-Reply-To: <3170f42f0707271120o496681c4u89fa5cf3651bc4f@mail.gmail.com> References: <3170f42f0707271120o496681c4u89fa5cf3651bc4f@mail.gmail.com> Message-ID: <46AB02B4.1020806@hhs.nl> Debarshi 'Rishi' Ray wrote: > I am looking for someone to review: > * https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247417 -- bouml > * https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249892 -- bouml-doc > > I do not mean to be pushy but I personally know a lot of people > itching for this to become a part of Fedora and is also part of > https://fedoraproject.org/wiki/PackageMaintainers/WishList > > Also there has been an upstream release while waiting for a reviewer > to appear, and it is not very interesting to keep on doing version > bumps through Bugzilla. :-) > Erm, the review is assigned to Mamoru Tasaka, so you already have a reviewer. My guess is that he is waiting for you to fix the libdir and cflags issues. I'll take a look at the spec and post some hints howto fix both of these as a comment in BZ, Regards, Hans From debarshi.ray at gmail.com Sat Jul 28 09:28:20 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 28 Jul 2007 14:58:20 +0530 Subject: Reviewer for Bouml. In-Reply-To: <46AB02B4.1020806@hhs.nl> References: <3170f42f0707271120o496681c4u89fa5cf3651bc4f@mail.gmail.com> <46AB02B4.1020806@hhs.nl> Message-ID: <3170f42f0707280228i7b4159acled5b65e49411131c@mail.gmail.com> > Erm, the review is assigned to Mamoru Tasaka, so you already have a reviewer. > My guess is that he is waiting for you to fix the libdir and cflags issues. That happened only after I posted here. :-) > I'll take a look at the spec and post some hints howto fix both of these as a > comment in BZ, Thanks, that can be helpful. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jkeating at redhat.com Sat Jul 28 11:13:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 28 Jul 2007 07:13:02 -0400 Subject: Package EVR problems in Fedora 2007-07-27 In-Reply-To: <20070728020558.2726d91d.bugs.michael@gmx.net> References: <20070727120627.CCDCC152133@buildsys.fedoraproject.org> <20070727132412.GA6698@redhat.com> <20070727154209.94e24be2.bugs.michael@gmx.net> <46A9FBED.4030809@ioa.s.u-tokyo.ac.jp> <20070728020558.2726d91d.bugs.michael@gmx.net> Message-ID: <20070728071302.36ddf43b@ender> On Sat, 28 Jul 2007 02:05:58 +0200 Michael Schwendt wrote: > But meanwhile I've been told some people in IRC spread false rumours > about the results of this script. Like claiming that the report would > be useless as it would only report false positives because the FE > release procedure doesn't push packages through updates-testing like > bodhi does. *urgh* That is a false claim. Lots of issues in the > report are unfixed for many weeks. Another packager told me he > ignores the private reports because he boycotts bodhi until there > will be a "make release" or similar. With opposition like that and > spreading of false rumours, I rather stop running the script > altogether. It has become another thankless effort with no backup > from FESCo. I for one really appreciate the mails. When I have spare moments I try to help people through the issues. Unfortunately I haven't had a lot of spare moments lately. After the Test1 release, would you be willing to assist rel-eng in making this script run automatically from bodhi pushes and/or rawhide pushes? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From john at curioussymbols.com Sun Jul 29 09:14:59 2007 From: john at curioussymbols.com (John Pye) Date: Sun, 29 Jul 2007 19:14:59 +1000 Subject: Looking for a review of 'sundials' library In-Reply-To: References: <46A9702A.2050600@curioussymbols.com> Message-ID: <46AC5A93.8020709@curioussymbols.com> Jason L Tibbitts III wrote: > "JP" == John Pye writes: > > http://jpye.fedorapeople.org/sundials/ > JP> Hi all I'm looking for a review of the mathematical library > JP> 'sundials' that I recently added. > > JP> Spec URL: http://jpye.fedorapeople.org/sundials/sundials.spec > > What's the fedora_version, mandriva_version, suse_version and xubuntu > stuff about? Even if such stuff was acceptable, nothing seems to set > %{fedora_version}. This makes the package fail to even start building > for me due to missing dependencies. > > - J< > Hi Jason I have uploaded a new version with all the non-Fedora stuff stripped out. Please take another look if you are able: http://jpye.fedorapeople.org/sundials/ Also note the updated filename of the .src.rpm there. Cheers JP From debarshi.ray at gmail.com Sun Jul 29 12:46:28 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sun, 29 Jul 2007 18:16:28 +0530 Subject: Looking for a review of 'sundials' library In-Reply-To: <46AC5A93.8020709@curioussymbols.com> References: <46A9702A.2050600@curioussymbols.com> <46AC5A93.8020709@curioussymbols.com> Message-ID: <3170f42f0707290546t681a048ar28e1fc76b1a0eb3@mail.gmail.com> > I have uploaded a new version with all the non-Fedora stuff stripped > out. Please take another look if you are able: Assuming that http://jpye.fedorapeople.org/sundials/sundials.spec is the latest version of the spec file, here are my comments: 1. You should consult https://fedoraproject.org/wiki/Packaging/Guidelines#head-b4fdd45fa76cbf54c885ef0836361319ab962473 to pick the value for your BuildRoot. 2. Why are you invoking ./configure directly instead of using '%configure' in the '%build' stanza? 3. Do you really need to use '%makeinstall' in the '%install' stanza? Consult https://fedoraproject.org/wiki/Packaging/Guidelines#head-fcaf3e6fcbd51194a5d0dbcfbdd2fcb7791dd002 4. Consult http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-d0dbcb7eec27622a21df280009c5b089b02f5bef to fix your post[un] scriptlets. Finally have you filed a review request in Bugzilla? Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From j.w.r.degoede at hhs.nl Sun Jul 29 20:14:14 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 29 Jul 2007 22:14:14 +0200 Subject: Away for the coming 5 days Message-ID: <46ACF516.4020901@hhs.nl> Hi All, I'll be on vacation for the coming 5 days starting tomorrow morning. As usual you all have permisson to do any needed (hot) fixes to my packages, and also as usual they are all ACL free, thus open for anyone. For those who concider these mails offtopic / not scaling, please realize that discussions about this being offtopic is even more offtopic and that sofar there hasn't been a flood of these mails, so nothing to worry about. Thus please send any offtopic flames to /dev/null. Regards, Hans From peter at thecodergeek.com Sun Jul 29 20:32:05 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 29 Jul 2007 13:32:05 -0700 Subject: Away for the coming 5 days In-Reply-To: <46ACF516.4020901@hhs.nl> References: <46ACF516.4020901@hhs.nl> Message-ID: <1185741125.4036.1.camel@tuxhugs> On Sun, 2007-07-29 at 22:14 +0200, Hans de Goede wrote: > Hi All, > > I'll be on vacation for the coming 5 days starting tomorrow morning. As usual > you all have permisson to do any needed (hot) fixes to my packages, and also as > usual they are all ACL free, thus open for anyone. Have a happy and safe vacation! Don't worry; your packages will be safe with us. :) -- 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 peter at thecodergeek.com Sun Jul 29 20:33:34 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 29 Jul 2007 13:33:34 -0700 Subject: Away for the coming 5 days In-Reply-To: <46ACF516.4020901@hhs.nl> References: <46ACF516.4020901@hhs.nl> Message-ID: <1185741214.4036.3.camel@tuxhugs> Err. Don't forget to update the Vacation wiki page, too. :) http://fedoraproject.org/wiki/Vacation Thanks. -- 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 luya_tfz at thefinalzone.com Sun Jul 29 23:57:17 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Sun, 29 Jul 2007 16:57:17 -0700 Subject: How to create a hosted project Message-ID: <46AD295D.4050900@thefinalzone.com> Following this instruction, I am unable to connect on cvs-int.fedora.redhat.com because it does not exist, could anyone provide the right cvs address? [1]http://fedoraproject.org/wiki/Infrastructure/ProjectHosting/RepositorySetup Luya From jkeating at redhat.com Mon Jul 30 00:14:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 29 Jul 2007 20:14:48 -0400 Subject: How to create a hosted project In-Reply-To: <46AD295D.4050900@thefinalzone.com> References: <46AD295D.4050900@thefinalzone.com> Message-ID: <20070729201448.7b2cbf87@ender> On Sun, 29 Jul 2007 16:57:17 -0700 Luya Tshimbalanga wrote: > Following this instruction, I am unable to connect on > cvs-int.fedora.redhat.com because it does not exist, could anyone > provide the right cvs address? > > > [1]http://fedoraproject.org/wiki/Infrastructure/ProjectHosting/RepositorySetup hi Luya. Currently only a few admins can create projects. I have your project request in my queue and should be able to process it tomorrow when I return to the office. Sorry for the delay, there was lots of F8 Test1 things to get out of the way. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From john at curioussymbols.com Mon Jul 30 03:04:00 2007 From: john at curioussymbols.com (John Pye) Date: Mon, 30 Jul 2007 13:04:00 +1000 Subject: Looking for a review of 'sundials' library In-Reply-To: <3170f42f0707290546t681a048ar28e1fc76b1a0eb3@mail.gmail.com> References: <46A9702A.2050600@curioussymbols.com> <46AC5A93.8020709@curioussymbols.com> <3170f42f0707290546t681a048ar28e1fc76b1a0eb3@mail.gmail.com> Message-ID: <46AD5520.1090007@curioussymbols.com> Hi Debarsi, Thanks very much for looking at this. Debarshi 'Rishi' Ray wrote: >> I have uploaded a new version with all the non-Fedora stuff stripped >> out. Please take another look if you are able: >> > > Assuming that http://jpye.fedorapeople.org/sundials/sundials.spec is > the latest version of the spec file, here are my comments: > > 1. You should consult > https://fedoraproject.org/wiki/Packaging/Guidelines#head-b4fdd45fa76cbf54c885ef0836361319ab962473 > to pick the value for your BuildRoot. > OK, fixed > 2. Why are you invoking ./configure directly instead of using > '%configure' in the '%build' stanza? > OK, fixed (reason was related to the following, but %configure is still OK, so I use it now) > 3. Do you really need to use '%makeinstall' in the '%install' stanza? > Consult https://fedoraproject.org/wiki/Packaging/Guidelines#head-fcaf3e6fcbd51194a5d0dbcfbdd2fcb7791dd002 > Yes, SUNDIALS does not support the 'DESTDIR' thing AFAICT. > 4. Consult http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-d0dbcb7eec27622a21df280009c5b089b02f5bef > to fix your post[un] scriptlets. > OK, fixed > Finally have you filed a review request in Bugzilla? > Yes, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249034 I have uploaded the updated files to the *NEW* location (don't have my fedorapeople key here) of: http://ascend.cheme.cmu.edu/ftp/jpye/ Cheers JP From debarshi.ray at gmail.com Mon Jul 30 03:36:03 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 30 Jul 2007 09:06:03 +0530 Subject: Looking for a review of 'sundials' library In-Reply-To: <46AD5520.1090007@curioussymbols.com> References: <46A9702A.2050600@curioussymbols.com> <46AC5A93.8020709@curioussymbols.com> <3170f42f0707290546t681a048ar28e1fc76b1a0eb3@mail.gmail.com> <46AD5520.1090007@curioussymbols.com> Message-ID: <3170f42f0707292036m57d46c26l4174680e92571238@mail.gmail.com> >> 2. Why are you invoking ./configure directly instead of using >> '%configure' in the '%build' stanza? > OK, fixed (reason was related to the following, but %configure is still > OK, so I use it now) Some of the flags that you are passing manually are automatically taken care of by the %configure macro. You could remove the unnecessary ones and use the rpmbuild defaults. > I have uploaded the updated files to the *NEW* location (don't have my > fedorapeople key here) of: > > http://ascend.cheme.cmu.edu/ftp/jpye/ It would be better if you briefly mentioned what you actually fixed instead of "Fixing for Debarshi Ray's feedback." in the ChangeLog. That would help others to know what actually happened. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From john at curioussymbols.com Mon Jul 30 04:07:21 2007 From: john at curioussymbols.com (John Pye) Date: Mon, 30 Jul 2007 14:07:21 +1000 Subject: Looking for a review of 'sundials' library In-Reply-To: <3170f42f0707292036m57d46c26l4174680e92571238@mail.gmail.com> References: <46A9702A.2050600@curioussymbols.com> <46AC5A93.8020709@curioussymbols.com> <3170f42f0707290546t681a048ar28e1fc76b1a0eb3@mail.gmail.com> <46AD5520.1090007@curioussymbols.com> <3170f42f0707292036m57d46c26l4174680e92571238@mail.gmail.com> Message-ID: <46AD63F9.6060302@curioussymbols.com> Hi again, Debarshi 'Rishi' Ray wrote: >>> 2. Why are you invoking ./configure directly instead of using >>> '%configure' in the '%build' stanza? >>> > > >> OK, fixed (reason was related to the following, but %configure is still >> OK, so I use it now) >> > > Some of the flags that you are passing manually are automatically > taken care of by the %configure macro. You could remove the > unnecessary ones and use the rpmbuild defaults. > Not true AFAICT (looking at Fedora Core 5 when I say this). Don't have access to a more recent machine for testing at this point (I can correct these things once I get CVS access for this package). Here is what I get on FC5: + ./configure --host=i686-redhat-linux-gnu --build=i686-redhat-linux-gnu --target=i386-redhat-linux --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info CXX=g++ CC=gcc F77=gfortran --enable-static=no --enable-shared=yes --disable-mpi > >> I have uploaded the updated files to the *NEW* location (don't have my >> fedorapeople key here) of: >> >> http://ascend.cheme.cmu.edu/ftp/jpye/ >> > > It would be better if you briefly mentioned what you actually fixed > instead of "Fixing for Debarshi Ray's feedback." in the ChangeLog. > That would help others to know what actually happened. > Fair point. Much more important to note the changes once we get to the point of a released package, of course. Wonder if you might be prepare to mark this 'review +' now (if you are able)? If not, perhaps it would be better to continue this discussion on Bugzilla? Cheers JP From debarshi.ray at gmail.com Mon Jul 30 05:40:26 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 30 Jul 2007 11:10:26 +0530 Subject: Looking for a review of 'sundials' library In-Reply-To: <46AD63F9.6060302@curioussymbols.com> References: <46A9702A.2050600@curioussymbols.com> <46AC5A93.8020709@curioussymbols.com> <3170f42f0707290546t681a048ar28e1fc76b1a0eb3@mail.gmail.com> <46AD5520.1090007@curioussymbols.com> <3170f42f0707292036m57d46c26l4174680e92571238@mail.gmail.com> <46AD63F9.6060302@curioussymbols.com> Message-ID: <3170f42f0707292240v19c226eeh4c9c11d5c6669de7@mail.gmail.com> > > It would be better if you briefly mentioned what you actually fixed > > instead of "Fixing for Debarshi Ray's feedback." in the ChangeLog. > > That would help others to know what actually happened. > Fair point. Much more important to note the changes once we get to the > point of a released package, of course. It is better to have them now itself even before the package is accepted. That way the reviewer can track the flow of the changes you made. > Wonder if you might be prepare to mark this 'review +' now (if you are > able)? If not, perhaps it would be better to continue this discussion on > Bugzilla? Sure. :-) Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From john at curioussymbols.com Mon Jul 30 05:52:52 2007 From: john at curioussymbols.com (John Pye) Date: Mon, 30 Jul 2007 15:52:52 +1000 Subject: Looking for a review of 'sundials' library In-Reply-To: <3170f42f0707292240v19c226eeh4c9c11d5c6669de7@mail.gmail.com> References: <46A9702A.2050600@curioussymbols.com> <46AC5A93.8020709@curioussymbols.com> <3170f42f0707290546t681a048ar28e1fc76b1a0eb3@mail.gmail.com> <46AD5520.1090007@curioussymbols.com> <3170f42f0707292036m57d46c26l4174680e92571238@mail.gmail.com> <46AD63F9.6060302@curioussymbols.com> <3170f42f0707292240v19c226eeh4c9c11d5c6669de7@mail.gmail.com> Message-ID: <46AD7CB4.2000806@curioussymbols.com> Hi again, Debarshi 'Rishi' Ray wrote: >>> It would be better if you briefly mentioned what you actually fixed >>> instead of "Fixing for Debarshi Ray's feedback." in the ChangeLog. >>> That would help others to know what actually happened. >>> > > >> Fair point. Much more important to note the changes once we get to the >> point of a released package, of course. >> > > It is better to have them now itself even before the package is > accepted. That way the reviewer can track the flow of the changes you > made. > Added comments as suggested. Please reply at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249034 Are you able to mark 'review +' ? Cheers JP From debarshi.ray at gmail.com Mon Jul 30 06:16:53 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 30 Jul 2007 11:46:53 +0530 Subject: Looking for a review of 'sundials' library In-Reply-To: <46AD7CB4.2000806@curioussymbols.com> References: <46A9702A.2050600@curioussymbols.com> <46AC5A93.8020709@curioussymbols.com> <3170f42f0707290546t681a048ar28e1fc76b1a0eb3@mail.gmail.com> <46AD5520.1090007@curioussymbols.com> <3170f42f0707292036m57d46c26l4174680e92571238@mail.gmail.com> <46AD63F9.6060302@curioussymbols.com> <3170f42f0707292240v19c226eeh4c9c11d5c6669de7@mail.gmail.com> <46AD7CB4.2000806@curioussymbols.com> Message-ID: <3170f42f0707292316o4e6ba33ejf486a2bbe9f61c8d@mail.gmail.com> > Are you able to mark 'review +' ? >From the fact that you have a fedorapeople.org account, I am assuming that you are sponsored and not a first time contributor. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Mon Jul 30 06:29:39 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 30 Jul 2007 11:59:39 +0530 Subject: Looking for a review of 'sundials' library In-Reply-To: <3170f42f0707292316o4e6ba33ejf486a2bbe9f61c8d@mail.gmail.com> References: <46A9702A.2050600@curioussymbols.com> <46AC5A93.8020709@curioussymbols.com> <3170f42f0707290546t681a048ar28e1fc76b1a0eb3@mail.gmail.com> <46AD5520.1090007@curioussymbols.com> <3170f42f0707292036m57d46c26l4174680e92571238@mail.gmail.com> <46AD63F9.6060302@curioussymbols.com> <3170f42f0707292240v19c226eeh4c9c11d5c6669de7@mail.gmail.com> <46AD7CB4.2000806@curioussymbols.com> <3170f42f0707292316o4e6ba33ejf486a2bbe9f61c8d@mail.gmail.com> Message-ID: <3170f42f0707292329v65278752qd01bc051615e7506@mail.gmail.com> > > Are you able to mark 'review +' ? > > From the fact that you have a fedorapeople.org account, I am assuming > that you are sponsored and not a first time contributor. Never mind you _are_ sponsored since you are there on https://admin.fedoraproject.org/accounts/dump-group.cgi?group=cvsextras&role_type=user&format=html Silly me... Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From fedora at leemhuis.info Mon Jul 30 17:11:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 30 Jul 2007 19:11:15 +0200 Subject: EPEL report week 30 2007 Message-ID: <46AE1BB3.7010908@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week30 = Weekly EPEL Summary = Week 30/2007 == Most important happenings == * It's party time -- EPEL was announced! https://www.redhat.com/archives/epel-devel-list/2007-July/msg00237.html == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * Jeff_S (Jeff Sheltren) (had to leave after half the meeting) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * quaid (KarstenWade) * stahnma (MichaelStahnke) Missing from the Steering Committee: * nirik (KevinFenzi) (vacation) Others that participated the meeting: marek === Summary === * broken deps -- all * move them to testing (happened in between) to have a clean proper repo for announcement * when to run the spam o magic script -- mmcgrath * not that easy to let it run asynchronously after a push; we'll stick to the weekly run * branch for EPEL if Fedora maintainer does not react -- knurd * dglimore issued concerns about https://www.redhat.com/archives/epel-devel-list/2007-July/msg00104.html ; he'll write something up and post it to the list * Free discussion around EPEL * some discussion about yum in EPEL4; continue on the list === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-July/msg00225.html == Stats == === General === Number of EPEL Contributors 124 We welcome 12 new contributors: andreas_AT_bawue.net, andy_AT_smile.org.ua, bugs.michael_AT_gmx.net, cbalint_AT_redhat.com, cgoorah_AT_yahoo.com.au, dmitry_AT_butskoy.name, ivazqueznet_AT_gmail.com, kaboom_AT_oobleck.net, lemenkov_AT_gmail.com, matt_AT_truch.net, neslami_AT_redhat.com, rvinyard_AT_cs.nmsu.edu === EPEL 5 === Number of source packages: 483 Number of binary packages: 872 There are 30 new Packages: * drupal | An open-source content-management platform * GeoIP | C library for country/city/organization to IP address or hostname mapping * libmcrypt | Encryption algorithms library * librx | POSIX regexp functions * lighttpd | Lightning fast webserver with light system requirements * logjam | GTK2 client for LiveJournal * lout | A document formatting system * mcrypt | Replacement for crypt() * memcached | High Performance, Distributed Memory Object Cache * mhash | Thread-safe hash algorithms library * mod_geoip | GeoIP module for the Apache HTTP Server * perl-File-MMagic | A Perl module emulating the file(1) command * perl-File-MMagic-XS | Guess file type with XS * perl-Geography-Countries | 2-letter, 3-letter, and numerical codes for countries * perl-Mail-IMAPClient | An IMAP Client API * perl-Net-Domain-TLD | Work with TLD names * perl-Object-Realize-Later | Delayed creation of objects * perl-Parse-RecDescent | Parse-RecDescent Perl module * perl-Pod-POM | Object-oriented interface to Perl POD documents * perl-Taint-Runtime | Runtime enable taint checking * perl-User-Identity | Maintains info about a physical person * phpMyAdmin | Web based MySQL browser written in php * python-GeoIP | Python bindings for the GeoIP geographical lookup libraries * python-imaging | Python's own image processing library * qfaxreader | A multipage monochrome/color TIFF/FAX viewer * qstat | Real-time Game Server Status for FPS game servers * QuantLib | A software framework for quantitative finance * sipp | SIP test tool / traffic generator * sipsak | SIP swiss army knife * smolt | Fedora hardware profiler === EPEL 4 === Number of source packages: 295 Number of binary packages: 596 There are 31 new Packages: * drupal | An open-source content-management platform * GeoIP | C library for country/city/organization to IP address or hostname mapping * graphviz | Graph Visualization Tools * libmcrypt | Encryption algorithms library * librx | POSIX regexp functions * logjam | GTK2 client for LiveJournal * lout | A document formatting system * mcrypt | Replacement for crypt() * mhash | Thread-safe hash algorithms library * mod_geoip | GeoIP module for the Apache HTTP Server * perl-Date-Pcalc | Gregorian calendar date calculations * perl-File-MMagic | A Perl module emulating the file(1) command * perl-File-MMagic-XS | Guess file type with XS * perl-Geography-Countries | 2-letter, 3-letter, and numerical codes for countries * perl-Mail-IMAPClient | An IMAP Client API * perl-MIME-Lite | MIME::Lite - low-calorie MIME generator * perl-MIME-tools | Modules for parsing and creating MIME entities in Perl * perl-Net-Domain-TLD | Work with TLD names * perl-Object-Realize-Later | Delayed creation of objects * perl-Parse-RecDescent | Parse-RecDescent Perl module * perl-Pod-POM | Object-oriented interface to Perl POD documents * perl-Taint-Runtime | Runtime enable taint checking * perl-TimeDate | A Perl module for time and date manipulation * perl-User-Identity | Maintains info about a physical person * phpMyAdmin | Web based MySQL browser written in php * python-cheetah | Template engine and code-generator * python-GeoIP | Python bindings for the GeoIP geographical lookup libraries * qfaxreader | A multipage monochrome/color TIFF/FAX viewer * qstat | Real-time Game Server Status for FPS game servers * sipp | SIP test tool / traffic generator * sipsak | SIP swiss army knife ---- ["CategoryEPELReports"] From krh at redhat.com Mon Jul 30 18:52:28 2007 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Mon, 30 Jul 2007 14:52:28 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs Message-ID: <1185821548.11086.9.camel@hinata.boston.redhat.com> Hi all, As you may know, xfs and chkfontpath is going away for Fedora 8. Basically xfs was always an unnecessary complication, that we pulled in because chkfontpath gave us the ability to reconfigure xfs on the fly. With the new fontpath.d change to libXfont, we can acheive the same using symlinks in /etc/X11/fontpath.d and thus, we're getting rid of xfs and chkfontpath. More details here (including the description below): http://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS Third party font packages, if any, will need to drop their configuration symlink in /etc/X11/fontpath.d rather than run chkfontpath. Note that you only need to do this if you want the fonts to be available over the old core font mechanism. If you're just doing client-side fonts (as both gtk and qt do nowadays) then you can demolish the chkfontpath call entirely. What I've done for the packages I've updates (the xorg-x11 font packages) is to install the symlink in %install and just list it in the %files section. For 3rd party core font RPMs I recommend using the package name as the symlink name to avoid conflicts if you install the fonts in a non-standard directory. For example, from the ghostscript-fonts specfile: %define fontdir %{_datadir}/fonts/default/ghostscript %define catalogue /etc/X11/fontpath.d ... %install ... # Install catalogue symlink mkdir -p $RPM_BUILD_ROOT%{catalogue} ln -sf %{fontdir} $RPM_BUILD_ROOT%{catalogue}/ghostscript %files ... %dir %{catalogue} %{catalogue}/fonts-default We're hoping to these changes before F8 goes out, so if you maintain a font package that installs core fonts (i.e. it runs chkfontpath), your help in getting these changes done is much appreciated. thanks, Kristian From krh at redhat.com Mon Jul 30 18:57:48 2007 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Mon, 30 Jul 2007 14:57:48 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <1185821548.11086.9.camel@hinata.boston.redhat.com> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> Message-ID: <1185821868.11086.11.camel@hinata.boston.redhat.com> On Mon, 2007-07-30 at 14:52 -0400, Kristian H?gsberg wrote: > Hi all, > > As you may know, xfs and chkfontpath is going away for Fedora 8. > Basically xfs was always an unnecessary complication, that we pulled in > because chkfontpath gave us the ability to reconfigure xfs on the fly. > With the new fontpath.d change to libXfont, we can acheive the same > using symlinks in /etc/X11/fontpath.d and thus, we're getting rid of xfs > and chkfontpath. Bill Nottingham ran a repoquery and got this: > According to repoquery, the following require chkfontpath: > > fonts-KOI8-R-75dpi-0:1.0-9.1.1.noarch > efont-unicode-bdf-0:0.4.2-6.1.fc6.noarch > fonts-KOI8-R-100dpi-0:1.0-9.1.1.noarch > fonts-ISO8859-2-0:1.0-17.1.noarch > fonts-japanese-0:0.20061016-6.fc7.noarch > fonts-korean-0:1.0.11-9.1.1.noarch > fonts-x11-apl-0:4.20.2-19.fc8.x86_64 > wqy-bitmap-fonts-0:0.8.1-6.fc8.noarch > fonts-truetype-apl-0:4.20.2-19.fc8.x86_64 > x3270-x11-0:3.3.4p7-5.fc6.x86_64 > libdockapp-fonts-0:0.6.1-3.fc8.x86_64 > fonts-ISO8859-2-100dpi-0:1.0-17.1.noarch > grace-0:5.1.21-1.fc7.x86_64 > urw-fonts-0:2.3-6.1.1.noarch > fonts-chinese-0:3.03-4.fc7.noarch > fonts-ISO8859-2-75dpi-0:1.0-17.1.noarch > fonts-KOI8-R-0:1.0-9.1.1.noarch > terminus-font-x11-0:4.20-5.fc6.noarch > zvbi-fonts-0:0.2.25-1.fc8.x86_64 cheers, Kristian From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jul 30 19:26:55 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 31 Jul 2007 04:26:55 +0900 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <1185821548.11086.9.camel@hinata.boston.redhat.com> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> Message-ID: <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> >From packaging issue: Kristian H?gsberg wrote, at 07/31/2007 03:52 AM +9:00: > Hi all, > > As you may know, xfs and chkfontpath is going away for Fedora 8. > > Third party font packages, if any, will need to drop their configuration > symlink in /etc/X11/fontpath.d rather than run chkfontpath. > > What I've done for the packages I've updates (the xorg-x11 font > packages) is to install the symlink in %install and just list it in the > %files section. > > %define fontdir %{_datadir}/fonts/default/ghostscript > %define catalogue /etc/X11/fontpath.d > ... > > %install > ... > # Install catalogue symlink > mkdir -p $RPM_BUILD_ROOT%{catalogue} > ln -sf %{fontdir} $RPM_BUILD_ROOT%{catalogue}/ghostscript The symlink should be not absolute but relative, shouldn't be? Mamoru From ajackson at redhat.com Mon Jul 30 19:27:30 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 30 Jul 2007 15:27:30 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> Message-ID: <1185823650.2794.177.camel@localhost.localdomain> On Tue, 2007-07-31 at 04:26 +0900, Mamoru Tasaka wrote: > >From packaging issue: > > Kristian H?gsberg wrote, at 07/31/2007 03:52 AM +9:00: > > Hi all, > > > > As you may know, xfs and chkfontpath is going away for Fedora 8. > > > > Third party font packages, if any, will need to drop their configuration > > symlink in /etc/X11/fontpath.d rather than run chkfontpath. > > > > What I've done for the packages I've updates (the xorg-x11 font > > packages) is to install the symlink in %install and just list it in the > > %files section. > > > > %define fontdir %{_datadir}/fonts/default/ghostscript > > %define catalogue /etc/X11/fontpath.d > > ... > > > > %install > > ... > > # Install catalogue symlink > > mkdir -p $RPM_BUILD_ROOT%{catalogue} > > ln -sf %{fontdir} $RPM_BUILD_ROOT%{catalogue}/ghostscript > > The symlink should be not absolute but relative, shouldn't be? Which will do you exactly no good, because the only path component they have in common, is / . Seriously. What does a relative symlink win you here? - ajax From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jul 30 20:03:03 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 31 Jul 2007 05:03:03 +0900 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <1185823650.2794.177.camel@localhost.localdomain> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> Message-ID: <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> Adam Jackson wrote, at 07/31/2007 04:27 AM +9:00: > On Tue, 2007-07-31 at 04:26 +0900, Mamoru Tasaka wrote: >> >From packaging issue: >> >> Kristian H?gsberg wrote, at 07/31/2007 03:52 AM +9:00: >>> Hi all, >>> >>> As you may know, xfs and chkfontpath is going away for Fedora 8. >>> >>> Third party font packages, if any, will need to drop their configuration >>> symlink in /etc/X11/fontpath.d rather than run chkfontpath. >>> >>> What I've done for the packages I've updates (the xorg-x11 font >>> packages) is to install the symlink in %install and just list it in the >>> %files section. >>> >>> %define fontdir %{_datadir}/fonts/default/ghostscript >>> %define catalogue /etc/X11/fontpath.d >>> ... >>> >>> %install >>> ... >>> # Install catalogue symlink >>> mkdir -p $RPM_BUILD_ROOT%{catalogue} >>> ln -sf %{fontdir} $RPM_BUILD_ROOT%{catalogue}/ghostscript >> The symlink should be not absolute but relative, shouldn't be? > > Which will do you exactly no good, because the only path component they > have in common, is / . > > Seriously. What does a relative symlink win you here? As I said "from packaging issue", current Fedora's packaging policy is: --------------------------------------------------------------------------- $ rpmlint -I symlink-should-be-relative symlink-should-be-relative : Absolute symlinks are problematic eg. when working with chroot environments. --------------------------------------------------------------------------- And we already have the example in which the common path is only / ---------------------------------------------------------------------------- $ ls -al /usr/lib/libz.so lrwxrwxrwx 1 root root 23 2007-05-31 14:53 /usr/lib/libz.so -> ../../lib/libz.so.1.2.3 ---------------------------------------------------------------------------- Mamoru From jkeating at redhat.com Mon Jul 30 20:07:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 30 Jul 2007 16:07:33 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> Message-ID: <20070730160733.057ee235@localhost.localdomain> On Tue, 31 Jul 2007 05:03:03 +0900 Mamoru Tasaka wrote: > As I said "from packaging issue", current Fedora's packaging policy > is: > --------------------------------------------------------------------------- > $ rpmlint -I symlink-should-be-relative symlink-should-be-relative : > Absolute symlinks are problematic eg. when working with chroot > environments. > --------------------------------------------------------------------------- > > > And we already have the example in which the common path is only / > ---------------------------------------------------------------------------- > $ ls -al /usr/lib/libz.so > lrwxrwxrwx 1 root root 23 2007-05-31 14:53 /usr/lib/libz.so > -> ../../lib/libz.so.1.2.3 > ---------------------------------------------------------------------------- I think this is clearly taking the guidelines a bit too literal. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From shahms at shahms.com Mon Jul 30 20:27:43 2007 From: shahms at shahms.com (Shahms King) Date: Mon, 30 Jul 2007 13:27:43 -0700 Subject: orphaning packages Message-ID: <7ca1f8930707301327x117a23fegc26bf869acf37319@mail.gmail.com> All, I have, unfortunately, been unable to provide adequate maintenance of my packages due to a change in day job and the increasing demands that places on my free time. As much as I've enjoyed being able to contribute to Fedora, the current demands on my time preclude my continued participation. I've managed to find co-maintainers for many of my packages (largely because they volunteered when they noticed my waning responsiveness to requests), but the following still need some love and care: bazaar python-durus python-psyco python-psycopg python-quixote python-simpletal python-tpg 'bazaar' is the original baz, which has largely been superseded and may very well be obsolete at this point (not entirely sure, as I haven't been able to keep up with it). Some of the other packages may also be obsolete (psycopg, for example has been replaced upstream by psycopg2, IIRC). I'm throwing this out there so that any of you with any interest in these packages may pick them up. I'm happy to file CVS change request bugs for these things, if necessary, but the packages are up for grabs. I've also entered the above packages on the OrphanedPackages list. ---Shahms From tibbs at math.uh.edu Mon Jul 30 20:31:10 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Jul 2007 15:31:10 -0500 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <20070730160733.057ee235@localhost.localdomain> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> <20070730160733.057ee235@localhost.localdomain> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> I think this is clearly taking the guidelines a bit too literal. It depends on the reasoning behind the guideline, I suppose. The point is to make installs in chroots be sane. With absolute links, they point to different places depending on whether you're in the chroot or not. Heck, I'd run into this rather often as it is very common for me to unpack an rpm into a temp tree and inspect it. - J< From ajackson at redhat.com Mon Jul 30 20:12:51 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 30 Jul 2007 16:12:51 -0400 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <46AE3B7F.80903@ioa.s.u-tokyo.ac.jp> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> Message-ID: <1185826371.2794.180.camel@localhost.localdomain> On Tue, 2007-07-31 at 05:03 +0900, Mamoru Tasaka wrote: > Adam Jackson wrote, at 07/31/2007 04:27 AM +9:00: > > Seriously. What does a relative symlink win you here? > > As I said "from packaging issue", current Fedora's packaging policy is: > --------------------------------------------------------------------------- > $ rpmlint -I symlink-should-be-relative > symlink-should-be-relative : > Absolute symlinks are problematic eg. when working with chroot environments. > --------------------------------------------------------------------------- This is merely an rpmlink complaint. Symlinks aren't mentioned in the packaging policy at all. - ajax From ville.skytta at iki.fi Mon Jul 30 20:37:43 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 30 Jul 2007 23:37:43 +0300 Subject: Font packages changes required for dropping chkfontpath/xfs In-Reply-To: <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> References: <1185821548.11086.9.camel@hinata.boston.redhat.com> <1185823650.2794.177.camel@localhost.localdomain> <46AE43F7.1080201@ioa.s.u-tokyo.ac.jp> Message-ID: <200707302337.44043.ville.skytta@iki.fi> On Monday 30 July 2007, Mamoru Tasaka wrote: > > As I said "from packaging issue", current Fedora's packaging policy is: > --------------------------------------------------------------------------- > $ rpmlint -I symlink-should-be-relative http://fedoraproject.org/wiki/Packaging/Guidelines#rpmlint rpmlint != packaging policy, and will not be. It will continue to say things that aren't "mandated" by the guidelines, and it will not enforce every item in them. About this particular case, while I personally tend to lean slightly towards relative symlinks being the better general choice of the two, I don't remember the packaging guidelines saying anything about it at the moment. From devrim at CommandPrompt.com Mon Jul 30 20:40:20 2007 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Mon, 30 Jul 2007 23:40:20 +0300 Subject: orphaning packages In-Reply-To: <7ca1f8930707301327x117a23fegc26bf869acf37319@mail.gmail.com> References: <7ca1f8930707301327x117a23fegc26bf869acf37319@mail.gmail.com> Message-ID: <1185828020.3050.158.camel@laptop.gunduz.org> Hi, On Mon, 2007-07-30 at 13:27 -0700, Shahms King wrote: > Some of the other packages may also be obsolete (psycopg, for example > has been replaced upstream by psycopg2, IIRC) Yes, and psycopg2 is already in Fedora repos. Regards, -- Devrim G?ND?Z PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Mon Jul 30 21:05:45 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 30 Jul 2007 22:05:45 +0100 Subject: Help needed, GStreamer issue on PPC64 Message-ID: <1185829545.10604.12.camel@snoogens.fab.redhat.com> Heya, If you have a PPC64 machine at hand, you can help all the GStreamer-based packages get better plugin detection in their configure scripts. Currently, to initialise the plugin registry, we run "/usr/bin/gst-inspect-0.10 --print-all > /dev/null", in the spec file. The problem is that a plugin is causing problems on PPC64, causing the above command to fail. Not having access to a PPC64, I can't find which plugin is causing problems. Would anyone have some time, or remote access to a (virtual) machine where I could reproduce this problem? Otherwise, I'll have to try and get someone to buy me a PS3 ;) Cheers -------------- next part -------------- An embedded message was scrubbed... From: Koji Build System Subject: Package: totem-2.19.6-1.fc8 Tag: dist-f8 Status: failed Built by: hadess Date: Mon, 30 Jul 2007 11:12:59 -0700 Size: 4020 URL: From luya_tfz at thefinalzone.com Mon Jul 30 21:19:35 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Mon, 30 Jul 2007 14:19:35 -0700 Subject: How to create a hosted project In-Reply-To: <20070729201448.7b2cbf87@ender> References: <46AD295D.4050900@thefinalzone.com> <20070729201448.7b2cbf87@ender> Message-ID: <46AE55E7.2050307@thefinalzone.com> Jesse Keating a ?crit : > On Sun, 29 Jul 2007 16:57:17 -0700 > Luya Tshimbalanga wrote: > > >> Following this instruction, I am unable to connect on >> cvs-int.fedora.redhat.com because it does not exist, could anyone >> provide the right cvs address? >> >> >> [1]http://fedoraproject.org/wiki/Infrastructure/ProjectHosting/RepositorySetup >> > > hi Luya. Currently only a few admins can create projects. I have your > project request in my queue and should be able to process it tomorrow > when I return to the office. Sorry for the delay, there was lots of F8 > Test1 things to get out of the way. > > Understood. From tibbs at math.uh.edu Mon Jul 30 22:00:24 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Jul 2007 17:00:24 -0500 Subject: Help needed, GStreamer issue on PPC64 In-Reply-To: <1185829545.10604.12.camel@snoogens.fab.redhat.com> References: <1185829545.10604.12.camel@snoogens.fab.redhat.com> Message-ID: >>>>> "BN" == Bastien Nocera writes: BN> The problem is that a plugin is causing problems on PPC64, causing BN> the above command to fail. Not having access to a PPC64, I can't BN> find which plugin is causing problems. Not that I know anything about gstreamer, but: configure: error: Cannot find required GStreamer-0.10 plugin 'playbin'. It should be part of gst-plugins-base. Please install it. - J< From jspaleta at gmail.com Mon Jul 30 22:58:07 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 30 Jul 2007 14:58:07 -0800 Subject: Interested in holding a session at Virtual FudCon? Message-ID: <604aa7910707301558k49ed2790q2d41018826c33dce@mail.gmail.com> I am putting a draft together for the Online UnFudcon aka (Virtual Fudcon) http://fedoraproject.org/wiki/JefSpaleta/VirtualFudCon I've already contacted many of the F8 Feature drivers concerning presenting something and the draft includes those items for which there was interest in holding a presentation. I am writing to the maintainers list specifically to ask if any persons would be willing to act as the point person for an irc based package review hackfest? If so can you please update the page and add your name as the contact person(s) and set a timeframe for the session inside the scope of the UnConference. If you have any questions please feel free to email me. -jef From dcbw at redhat.com Tue Jul 31 01:12:18 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 30 Jul 2007 21:12:18 -0400 Subject: Help needed, GStreamer issue on PPC64 In-Reply-To: References: <1185829545.10604.12.camel@snoogens.fab.redhat.com> Message-ID: <1185844338.13690.8.camel@xo-13-A4-25.localdomain> On Mon, 2007-07-30 at 17:00 -0500, Jason L Tibbitts III wrote: > >>>>> "BN" == Bastien Nocera writes: > > BN> The problem is that a plugin is causing problems on PPC64, causing > BN> the above command to fail. Not having access to a PPC64, I can't > BN> find which plugin is causing problems. > > Not that I know anything about gstreamer, but: > > configure: error: > Cannot find required GStreamer-0.10 > plugin 'playbin'. > It should be part of > gst-plugins-base. Please install it. The gstreamer plugins are quite sensitive to build-time environment. If you don't BuildRequire the right devel packages when building the plugins, some plugins just don't get built. That really, really sucks for packagers, and hopefully gets caught by the RPM %files section. Beware of this, if it turns out to be relevant to the problem :) Dan From bnocera at redhat.com Tue Jul 31 12:10:44 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 31 Jul 2007 13:10:44 +0100 Subject: Help needed, GStreamer issue on PPC64 In-Reply-To: References: <1185829545.10604.12.camel@snoogens.fab.redhat.com> Message-ID: <1185883844.3046.9.camel@snoogens.fab.redhat.com> On Mon, 2007-07-30 at 17:00 -0500, Jason L Tibbitts III wrote: > >>>>> "BN" == Bastien Nocera writes: > > BN> The problem is that a plugin is causing problems on PPC64, causing > BN> the above command to fail. Not having access to a PPC64, I can't > BN> find which plugin is causing problems. > > Not that I know anything about gstreamer, but: > > configure: error: > Cannot find required GStreamer-0.10 > plugin 'playbin'. > It should be part of > gst-plugins-base. Please install it. That's because gst-inspect failed to create the registry, and thus doesn't find the plugin. I'll repeat what I'm looking for: - There's a bug in a plugin on PPC64 - It causes gst-inspect to fail - gst-inspect failing means that we don't have an up-to-date registry It's not a missing dependency, as it builds on every single arch, but not on PPC64. From dan at danny.cz Tue Jul 31 14:47:54 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Tue, 31 Jul 2007 16:47:54 +0200 Subject: orphaning packages In-Reply-To: <1185828020.3050.158.camel@laptop.gunduz.org> References: <7ca1f8930707301327x117a23fegc26bf869acf37319@mail.gmail.com> <1185828020.3050.158.camel@laptop.gunduz.org> Message-ID: <1185893274.4150.2.camel@eagle.danny.cz> Devrim G?ND?Z p??e v Po 30. 07. 2007 v 23:40 +0300: > Hi, > > On Mon, 2007-07-30 at 13:27 -0700, Shahms King wrote: > > Some of the other packages may also be obsolete (psycopg, for example > > has been replaced upstream by psycopg2, IIRC) > > Yes, and psycopg2 is already in Fedora repos. > But AFAIK they are not API compatible and TinyERP requires psycopg. So if there will nobody interested, I will take it. Dan From silfreed at silfreed.net Tue Jul 31 18:54:00 2007 From: silfreed at silfreed.net (Douglas E. Warner) Date: Tue, 31 Jul 2007 14:54:00 -0400 Subject: PPC build error for qtpfsgui Message-ID: <200707311454.06935.silfreed@silfreed.net> Does anyone have any insight as to why this would fail on PPC for FC-6, but not for F-7 or devel? -Doug -------------- next part -------------- An embedded message was scrubbed... From: buildsys at fedoraproject.org Subject: Build Error (Job 35321): qtpfsgui-1_8_11-1_fc6 on fedora-6-extras Date: Tue, 31 Jul 2007 14:50:54 -0400 (EDT) Size: 4100 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 dan at danny.cz Tue Jul 31 20:11:55 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Tue, 31 Jul 2007 22:11:55 +0200 Subject: delete old pending updates from Bodhi Message-ID: <1185912715.9716.4.camel@eagle.danny.cz> Hello, please, can someone delete old pending updates from Bodhi? There are many packages that were replaced with a newer version even before getting into updates-testing. The oldest one is from June 1st. Thanks Dan -- Fedora maintainer: TinyERP, Code::Blocks, QGit, Tailor From orion at cora.nwra.com Tue Jul 31 22:39:33 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 31 Jul 2007 16:39:33 -0600 Subject: PPC build error for qtpfsgui In-Reply-To: <200707311454.06935.silfreed@silfreed.net> References: <200707311454.06935.silfreed@silfreed.net> Message-ID: <46AFBA25.1050004@cora.nwra.com> Douglas E. Warner wrote: > Does anyone have any insight as to why this would fail on PPC for FC-6, but > not for F-7 or devel? > > -Doug > > > Job failed on arch ppc > > > Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-6-extras/35321-qtpfsgui-1.8.11-1.fc6/ > > > ------------------------------------------------- > > g++ -c -pipe -O3 -funroll-loops -fstrength-reduce -fschedule-insns2 -felide-constructors -frerun-loop-opt -fexceptions -fno-strict-aliasing -fexpensive-optimizations -ffast-math -pipe -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -m32 -D_REENTRANT -Wall -W -DQT_NO_DEBUG_OUTPUT -DHAVE_FFTW -DI18NDIR=\"/usr/share/qtpfsgui/i18n\" -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/qt4/mkspecs/linux-g++ -I. -I/usr/include/QtCore -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtGui -I/usr/include -I/usr/include/exiv2 -I/usr/include/OpenEXR -I/usr/include -Igenerated_moc -Igenerated_uic -o generated_obj/exif_operations.o src/Exif/exif_operations.cpp > g++ -c -pipe -O3 -funroll-loops -fstrength-reduce -fschedule-insns2 -felide-constructors -frerun-loop-opt -fexceptions -fno-strict-aliasing -fexpensive-optimizations -ffast-math -pipe -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -m32 -D_REENTRANT -Wall -W -DQT_NO_DEBUG_OUTPUT -DHAVE_FFTW -DI18NDIR=\"/usr/share/qtpfsgui/i18n\" -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/qt4/mkspecs/linux-g++ -I. -I/usr/include/QtCore -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtGui -I/usr/include -I/usr/include/exiv2 -I/usr/include/OpenEXR -I/usr/include -Igenerated_moc -Igenerated_uic -o generated_obj/pfsinexr.o src/Fileformat/pfsinexr.cpp > {standard input}: Assembler messages: > {standard input}:0: Warning: end of file not at end of a line; newline inserted > g++: Internal error: Killed (program cc1plus) > Please submit a full bug report. > See for instructions. > make: *** [generated_obj/tmo_ashikhmin02.o] Error 1 > make: *** Waiting for unfinished jobs.... > {standard input}: Assembler messages: > {standard input}:0: Warning: end of file not at end of a line; newline inserted > {standard input}:2170: Error: missing operand > {standard input}:2170: Error: missing operand > {standard input}:2170: Error: missing operand > g++: Internal error: Killed (program cc1plus) > Please submit a full bug report. > See for instructions. Looks like a g++ bug. -- 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 shahms at shahms.com Tue Jul 31 23:12:30 2007 From: shahms at shahms.com (Shahms King) Date: Tue, 31 Jul 2007 16:12:30 -0700 Subject: orphaning packages In-Reply-To: <1185893274.4150.2.camel@eagle.danny.cz> References: <7ca1f8930707301327x117a23fegc26bf869acf37319@mail.gmail.com> <1185828020.3050.158.camel@laptop.gunduz.org> <1185893274.4150.2.camel@eagle.danny.cz> Message-ID: <7ca1f8930707311612j6b79eca5w5de60fab86e57052@mail.gmail.com> There should be a backward-compatibility layer in psycopg2, but it requires changing the import statement on the affected code. --Shahms On 7/31/07, Dan Hor?k wrote: > Devrim G?ND?Z p??e v Po 30. 07. 2007 v 23:40 +0300: > > Hi, > > > > On Mon, 2007-07-30 at 13:27 -0700, Shahms King wrote: > > > Some of the other packages may also be obsolete (psycopg, for example > > > has been replaced upstream by psycopg2, IIRC) > > > > Yes, and psycopg2 is already in Fedora repos. > > > > But AFAIK they are not API compatible and TinyERP requires psycopg. So > if there will nobody interested, I will take it. > > > Dan > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From Axel.Thimm at ATrpms.net Tue Jul 31 23:27:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 1 Aug 2007 01:27:06 +0200 Subject: When are kernels removed from the download repository? (was Re: Policy for retiring packages?) In-Reply-To: <200707042216.37679.jkeating@redhat.com> References: <20070704125900.GA25570@puariko.nirvana> <20070704164122.GB600@puariko.nirvana> <1183569153.3628.27.camel@localhost.localdomain> <200707042216.37679.jkeating@redhat.com> Message-ID: <20070731232706.GA22441@puariko.nirvana> On Wed, Jul 04, 2007 at 10:16:37PM -0400, Jesse Keating wrote: > On Wednesday 04 July 2007 13:12:33 Toshio Kuratomi wrote: > > So those policies aren't going to help you since you need to find out > > when a built kernel rpm is being dropped from the download repository. > > The policy only addresses when a package is being dropped from the cvs > > repository. > > > > Jesse, Michael Schwendt, or one of the relengs might know the answer to > > this but there's currently no written policy that I'm aware of. > > In the new merged world, only the latest updates are in the repo at any time. > This is just due to how mash is used in conjunction with Koji. We ask koji > for all the latest packages in the dist-fc7-updates and > dist-fc7-updates-testing tags and create repos from scratch. This seems to not hold true for the kernel packages, currently both 33 and 41 are in updates-released. (not that I mind, but I wanted to understand the retiring policy to be able to react better with kernel supproting packages, aka kmdls) -- 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: