From ianburrell at gmail.com Sat Jul 1 01:10:20 2006 From: ianburrell at gmail.com (Ian Burrell) Date: Fri, 30 Jun 2006 18:10:20 -0700 Subject: extras mirrorlist with out-of-date mirrors Message-ID: How is the Fedora Extras mirrorlist determined? Is it maintained? I just noticed that my extras packages weren't being updated with packages I knew had been deployed. The reason is that it was using a mirror which is out-of-date. And not a few minutes out-of-date but having a repomd.xml from May 27. http://mirror.pacific.net.au/linux/fedora/linux/extras/5/ have repomd.xml's for both i386 and x86_64 that is from May 27. ftp://mirror.newnanutilities.org/pub/fedora/linux/extras/5/ have repomd.xml's from Mar 21. - Ian From michael at knox.net.nz Sat Jul 1 04:27:41 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 01 Jul 2006 16:27:41 +1200 Subject: [Fedora-infrastructure-list] Extras Package Database In-Reply-To: <821D642B-63A5-4CEE-A82D-DE14C8B3FA14@redhat.com> References: <821D642B-63A5-4CEE-A82D-DE14C8B3FA14@redhat.com> Message-ID: <44A5F9BD.8030502@knox.net.nz> Elliot Lee wrote: > Hi all, > > http://fedoraproject.org/wiki/Infrastructure/PackageDatabase has been > out there for a bit... > > I've put together a strawman schema (as a TurboGears model.py) to help > move things along - apologies if someone else has beaten me to it. I > think at this point the right questions to be asking are long the lines > of "will this schema support feature X or use case Y?". From a quick > glance at the web page, I *think* it mostly will. There are some > problems with this still, but open source is all about fixing those > problems :) > This is cool Elliot. This is a project I would like to help out on, but didn't really know where to start. Hopefully we can get a few other people to pitch in. Michael From dtimms at bigpond.net.au Sat Jul 1 08:58:45 2006 From: dtimms at bigpond.net.au (David Timms) Date: Sat, 01 Jul 2006 18:58:45 +1000 Subject: extras mirrorlist with out-of-date mirrors In-Reply-To: References: Message-ID: <44A63945.9060804@bigpond.net.au> Ian Burrell wrote: > http://mirror.pacific.net.au/linux/fedora/linux/extras/5/ have > repomd.xml's for both i386 and x86_64 that is from May 27. I'll contact pacific.net to see what is happening {their last mention was they rsync it each 8 hours}. DaveT. From fedora at leemhuis.info Sat Jul 1 10:10:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 01 Jul 2006 12:10:51 +0200 Subject: FESCo election -- only some hours left, go vote Message-ID: <44A64A2B.2050609@leemhuis.info> Hi! For those that forgot -- the election for the next FESCo still runs and will end soon (soon=tomorrow, July 2nd at 23:59 UTC -- round about 34 hours from now)! So if you are a Fedora Extras contributor go and vote the right people for the next FESCo at https://admin.fedoraproject.org/voting/vote.cgi More details about the election can be found at: https://www.redhat.com/archives/fedora-maintainers/2006-June/msg00104.html CU thl From fedora at leemhuis.info Sat Jul 1 10:25:54 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 01 Jul 2006 12:25:54 +0200 Subject: Mass rebuild of Extras packages for FC6? (was: Re: Mass rebuild of core packages coming soon) In-Reply-To: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> References: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> Message-ID: <44A64DB2.2080505@leemhuis.info> Hi I suppose a lot of people won't like the topic I'll bring up with this mail but we IMHO should discuss this nevertheless. Jesse Keating schrieb: > I've been requested to rebuild every Core package for a few reasons. > > 1) rpm signing w/ sha256sum > 2) New toolset feature to speed up dynamic lib linking by 50%~ > 3) get all packages built through new build system (brew) Change the last point to 3) get all packages build with the new and reduced set of packages installed in the default mock buildroot and add 4) make sure all packagers/contributors are still around just a we did during the mass-rebuild for FC5 Now it makes four good reasons to build all Extras packages in devel before FC6. Opinions? And if your opinion is "No mass-rebuild of Extras for FC6" then please give some ideas how to realize the goals stated above without a mass-rebuild. CU thl BTW, does anyone have details on the technical background of "New toolset feature to speed up dynamic lib linking by 50%~" ? From Axel.Thimm at ATrpms.net Sat Jul 1 10:39:26 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 1 Jul 2006 12:39:26 +0200 Subject: extras mirrorlist with out-of-date mirrors In-Reply-To: References: Message-ID: <20060701103926.GN15707@neu.nirvana> On Fri, Jun 30, 2006 at 06:10:20PM -0700, Ian Burrell wrote: > How is the Fedora Extras mirrorlist determined? Is it maintained? I > just noticed that my extras packages weren't being updated with > packages I knew had been deployed. The reason is that it was using a > mirror which is out-of-date. And not a few minutes out-of-date but > having a repomd.xml from May 27. > > http://mirror.pacific.net.au/linux/fedora/linux/extras/5/ have > repomd.xml's for both i386 and x86_64 that is from May 27. > > ftp://mirror.newnanutilities.org/pub/fedora/linux/extras/5/ have > repomd.xml's from Mar 21. It would be nice to have mirrors being checked automatically by some script and whine when the mirror is out of sync for some given time. It is probably enough to test the size/timestamp of the metadata. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonathan.underwood at gmail.com Sat Jul 1 10:55:34 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 1 Jul 2006 11:55:34 +0100 Subject: Mass rebuild of Extras packages for FC6? (was: Re: Mass rebuild of core packages coming soon) In-Reply-To: <44A64DB2.2080505@leemhuis.info> References: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> <44A64DB2.2080505@leemhuis.info> Message-ID: <645d17210607010355i1c6a3a1ey59606b226ad322c1@mail.gmail.com> On 01/07/06, Thorsten Leemhuis wrote: > > 1) rpm signing w/ sha256sum > > 2) New toolset feature to speed up dynamic lib linking by 50%~ > 3) get all packages build with the new and reduced set of packages > installed in the default mock buildroot These all seem like good reasons for a rebuild to me. > 4) make sure all packagers/contributors are still around just a we did > during the mass-rebuild for FC5 This seems like a commendable desire, but I'm not sure that clobbering the build system to achieve this goal alone is the best way to go about it. As a side effect of a mass rebuild for reasons 1-3 though, it's a nice bonus. I suppose this points to a need to have some automated way of verifying that package maintainers are still around. Jonathan From fedora at leemhuis.info Sat Jul 1 11:09:43 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 01 Jul 2006 13:09:43 +0200 Subject: Mass rebuild of Extras packages for FC6? In-Reply-To: <645d17210607010355i1c6a3a1ey59606b226ad322c1@mail.gmail.com> References: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> <44A64DB2.2080505@leemhuis.info> <645d17210607010355i1c6a3a1ey59606b226ad322c1@mail.gmail.com> Message-ID: <44A657F7.60004@leemhuis.info> Jonathan Underwood schrieb: > On 01/07/06, Thorsten Leemhuis wrote: [...] >> 4) make sure all packagers/contributors are still around just a we did >> during the mass-rebuild for FC5 [...] > As a side effect of a mass rebuild for reasons 1-3 though, > it's a nice bonus. Yes. > I suppose this points to a need to have some > automated way of verifying that package maintainers are still around. There is some progress in this direction -- see the thread "AWOL owners and stale packages." on this list and the plans for the package database http://www.fedoraproject.org/wiki/Infrastructure/PackageDatabase Cu thl From dtimms at bigpond.net.au Sat Jul 1 11:22:46 2006 From: dtimms at bigpond.net.au (David Timms) Date: Sat, 01 Jul 2006 21:22:46 +1000 Subject: extras mirrorlist with out-of-date mirrors In-Reply-To: <20060701103926.GN15707@neu.nirvana> References: <20060701103926.GN15707@neu.nirvana> Message-ID: <44A65B06.70404@bigpond.net.au> Axel Thimm wrote: > On Fri, Jun 30, 2006 at 06:10:20PM -0700, Ian Burrell wrote: >> How is the Fedora Extras mirrorlist determined? Is it maintained? I >> just noticed that my extras packages weren't being updated with >> packages I knew had been deployed. The reason is that it was using a >> mirror which is out-of-date. And not a few minutes out-of-date but >> having a repomd.xml from May 27. >> >> http://mirror.pacific.net.au/linux/fedora/linux/extras/5/ have >> repomd.xml's for both i386 and x86_64 that is from May 27. >> >> ftp://mirror.newnanutilities.org/pub/fedora/linux/extras/5/ have >> repomd.xml's from Mar 21. > > It would be nice to have mirrors being checked automatically by some > script and whine when the mirror is out of sync for some given > time. It is probably enough to test the size/timestamp of the > metadata. Tony Nelson has made some efforts in this direction: http://www.redhat.com/archives/rhl-list/2006-May/msg04193.html He has published repoinsync under the gpl on http://www.georgeanelson.com/reposinsync.htm It would be good if such a service was hosted at fedora.redhat.com, perhaps with a master list of mirrors/paths to check. Mirrors with up2date repodata (filelist.xml) would then be actively published in a dynamic mirrorlist: http://fedora.redhat.com/download/mirrors/fedora-extras-$releasever, ensuring that only mirrors with up2date filelist would be accessed. This would probably best done a few times a day. Or is such a thing already in development ? DaveT. From Axel.Thimm at ATrpms.net Sat Jul 1 11:34:29 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 1 Jul 2006 13:34:29 +0200 Subject: fc5.90/fc5.91/... disttags and automated rebuilds (was: Mass rebuild of Extras packages for FC6?) In-Reply-To: <44A64DB2.2080505@leemhuis.info> References: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> <44A64DB2.2080505@leemhuis.info> Message-ID: <20060701113429.GA20490@neu.nirvana> On Sat, Jul 01, 2006 at 12:25:54PM +0200, Thorsten Leemhuis wrote: > I suppose a lot of people won't like the topic I'll bring up with this > mail but we IMHO should discuss this nevertheless. > > Jesse Keating schrieb: > > I've been requested to rebuild every Core package for a few reasons. > > > > 1) rpm signing w/ sha256sum > > 2) New toolset feature to speed up dynamic lib linking by 50%~ > > 3) get all packages built through new build system (brew) > > Change the last point to > > 3) get all packages build with the new and reduced set of packages > installed in the default mock buildroot All the above three could be automated for packages using %{?dist}, if the disttag would propagate in fedora time as well. E.g. the internal release version of FC6test1 is 5.90, if the disttag was matched to this, we would have automated rebuilds for each test release and for the final release as well w/o anyone having to do anything about it (sparing bugs of course). If rebuilds are needed more often (because gcc was upgraded in between) then disttags could look like 5.90.1 to indicate a rebuild between test1 and test2. Before test1 rawhide had the version 5.89, so we're covered in that area, too. If we're going to mass-rebuilt (and therefore touch each specfile), could we consider using such disttags for rawhide/test releases from now on? E.g. make %{?dist} become 5.90.1 is the mass rebuild is before test2, or if the mass rebuild coincides with test2 go 5.91. It doesn't cover packages not using disttags (so it's perhaps another incentive for these packagers to use them) and due to everything being automated doesn't serve as a way to ping absent packagers. But that was only a side effect of the humanly powered mass-rebuilds, which will be managed differently anyway in the future. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sat Jul 1 11:56:30 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 01 Jul 2006 13:56:30 +0200 Subject: Removing zoo from Fedora Extras Message-ID: <1151754990.9339.86.camel@rousalka.dyndns.org> Hi, I'm going to ask the removal of the zoo archiver suite from Fedora Extras repositories. The existing zoo codebase is potentially insecure, and there is no one to audit it and coordinate fixes. This unfortunate situation haven't changed since the last CERT alerts, and the rushed fixes we used then. As far as I know zoo was never used in Fedora except as a pluggin in mail filters to uncompress zoo attachements and scan them. Needless to say the last thing you want when processing external uncontrolled input is old crufty orphaned unaudited code. If you need zoo for something please ping me and I'll give over maintainership to you. But please remember accepting the maintainership now implies doing the security audit zoo sorely needs, as I don't see how the package could be kept in Fedora repositories otherwise. If no one objects I'll go on with the orphaning and request for repository removal tomorrow evening (CET time) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bugs.michael at gmx.net Sat Jul 1 15:25:34 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 1 Jul 2006 17:25:34 +0200 Subject: soname change policy proposal In-Reply-To: <1151398545.2768.52.camel@localhost.localdomain> References: <44A0E14B.9010200@hhs.nl> <1151398545.2768.52.camel@localhost.localdomain> Message-ID: <20060701172534.5de4be52.bugs.michael@gmx.net> On Tue, 27 Jun 2006 11:55:45 +0300, Ville Skytt? wrote: > > After the warning one must wait 7 days minimum before the > > new version may be build. > > 7 days is too much. If Core devel is not in the post-last-testX freeze > before the next release, 1 day is enough. If Core devel is in that > freeze, rules for released distro branches apply to devel too. > Example: according to the current > http://fedoraproject.org/wiki/Core/Schedule, the final post-last-testX > freeze would be 23 Aug - 27 Sep. > > For released branches, we assume that a smoothly working compat-foo has > been already created before the incompatible upgrade is pushed and it > has stayed in a review for a little while anyway. So there's no wait > period, but the notice must be posted to the fedora-maintainers list > when the new compat package is posted for review, and the review bug > number is included in that notice. It is not that easy. For every scenario in which a packager starts working on a compat-fooX package for a _release branch_ of a dist, much more must happen prior to shipping the package. First of all, and provided that the packager notices the SONAME change (or ABI/API change) at all, it _must_ be verified that existing software in the release branch can still be (re-)built with either compat-fooX-devel or the new foo-devel. This step is mandatory. It requires review, testing, and approval. I see phrases like "quick and dirty" and would prefer if it were called "painstakinly and safe" instead. Any API break in a release branch may prevent the next security fix from being built quickly and painlessly. Further, packagers, especially library packagers, ought to become familiar with what in the distribution depends on them. I'm not convinced that maintainers-list is the right forum where to address package owners and where to warn about ABI/API breakage. I'd rather see packagers use bugzilla or private mail to announce and talk about a change in SONAMEs before agreeing on introducing the changes. There ought to be coordination and collaboration. Application packagers could be the reviewers of library packagers' review requests. > > 2) When a compat package must be created there are 2 possible scenarios. > > When the soname is changed the ABI is changed, however sometimes the > > API is not changed or kept compatible. When the API is not changed then > > the compat package must not come with a -devel subpackage and the quick > > and dirty method described below may be used. When the API is changed > > the compat package is concidered a new package and must go through the > > review process as usual, in this case the compat-package must come with > > a -devel subpackage. > > All compat-* need to go through a review. But of course! From j.w.r.degoede at hhs.nl Sat Jul 1 15:54:07 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 01 Jul 2006 17:54:07 +0200 Subject: soname change policy proposal In-Reply-To: <20060701172534.5de4be52.bugs.michael@gmx.net> References: <44A0E14B.9010200@hhs.nl> <1151398545.2768.52.camel@localhost.localdomain> <20060701172534.5de4be52.bugs.michael@gmx.net> Message-ID: <44A69A9F.8090301@hhs.nl> Hi, I think you are trying to make this failproof in a totally over the top way. The end result being that nobody will do a soname bump in the non-devel branch possible keeping nice packages out non devel branches because they need a newer version and/or keeping bugs in the non-devel branch because releasing the bugfix version would require the maintainer todo some kinda big and long ceremonial dance. I wrote this with cases like directfb in mind where upstream changes the soname every! release. The whole idea behind my policy proposal was to have a sane and reasonably* safe policy, while at the same timing not making it nearly impossible for maintainers to actually do an soname change. *100% safe does not exist, get that stupid notion of 100% safe out of your head please As I also wrote a API change which causes non trivial to fix build errors, makes it mandatory to add a -devel sub package to the compat package, so in the security problem case the fixed package can build against this -compat-devel package. But I've learned from your and other reactions that there is appearantly no support on the list for a balanced soname policy. With the end result being that there probably isn't going to be any policy at all. I must say I'm disappointed in the lack of the ability to see the balance of things here on the list. Because of this will probably be my last post in this thread. Regards, Hans Michael Schwendt wrote: > On Tue, 27 Jun 2006 11:55:45 +0300, Ville Skytt? wrote: > >>> After the warning one must wait 7 days minimum before the >>> new version may be build. >> 7 days is too much. If Core devel is not in the post-last-testX freeze >> before the next release, 1 day is enough. If Core devel is in that >> freeze, rules for released distro branches apply to devel too. >> Example: according to the current >> http://fedoraproject.org/wiki/Core/Schedule, the final post-last-testX >> freeze would be 23 Aug - 27 Sep. >> >> For released branches, we assume that a smoothly working compat-foo has >> been already created before the incompatible upgrade is pushed and it >> has stayed in a review for a little while anyway. So there's no wait >> period, but the notice must be posted to the fedora-maintainers list >> when the new compat package is posted for review, and the review bug >> number is included in that notice. > > It is not that easy. > > For every scenario in which a packager starts working on a compat-fooX > package for a _release branch_ of a dist, much more must happen prior to > shipping the package. > > First of all, and provided that the packager notices the SONAME change (or > ABI/API change) at all, it _must_ be verified that existing software in > the release branch can still be (re-)built with either compat-fooX-devel > or the new foo-devel. This step is mandatory. It requires review, testing, > and approval. > > I see phrases like "quick and dirty" and would prefer if it were called > "painstakinly and safe" instead. Any API break in a release branch may > prevent the next security fix from being built quickly and painlessly. > > Further, packagers, especially library packagers, ought to become familiar > with what in the distribution depends on them. I'm not convinced that > maintainers-list is the right forum where to address package owners and > where to warn about ABI/API breakage. I'd rather see packagers use > bugzilla or private mail to announce and talk about a change in SONAMEs > before agreeing on introducing the changes. There ought to be coordination > and collaboration. Application packagers could be the reviewers of library > packagers' review requests. > >>> 2) When a compat package must be created there are 2 possible scenarios. >>> When the soname is changed the ABI is changed, however sometimes the >>> API is not changed or kept compatible. When the API is not changed then >>> the compat package must not come with a -devel subpackage and the quick >>> and dirty method described below may be used. When the API is changed >>> the compat package is concidered a new package and must go through the >>> review process as usual, in this case the compat-package must come with >>> a -devel subpackage. >> All compat-* need to go through a review. > > But of course! > > From seg at haxxed.com Sat Jul 1 17:30:05 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 01 Jul 2006 12:30:05 -0500 Subject: Removing zoo from Fedora Extras In-Reply-To: <1151754990.9339.86.camel@rousalka.dyndns.org> References: <1151754990.9339.86.camel@rousalka.dyndns.org> Message-ID: <1151775005.13315.5.camel@localhost> On Sat, 2006-07-01 at 13:56 +0200, Nicolas Mailhot wrote: > As far as I know zoo was never used in Fedora except as a pluggin in > mail filters to uncompress zoo attachements and scan them. Needless to > say the last thing you want when processing external uncontrolled input > is old crufty orphaned unaudited code. Some Atari ST software was packaged in zoo files, as well as a multitude of other obscure long dead formats... But considering how long dead the Atari ST is now, I've been considering just repacking everything in my Atari ST mirrors to zip and burn it all to CDs. :P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Sat Jul 1 17:31:41 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 1 Jul 2006 19:31:41 +0200 Subject: soname change policy proposal In-Reply-To: <44A69A9F.8090301@hhs.nl> References: <44A0E14B.9010200@hhs.nl> <1151398545.2768.52.camel@localhost.localdomain> <20060701172534.5de4be52.bugs.michael@gmx.net> <44A69A9F.8090301@hhs.nl> Message-ID: <20060701193141.bf9c8a57.bugs.michael@gmx.net> On Sat, 01 Jul 2006 17:54:07 +0200, Hans de Goede wrote: > I think you are trying to make this failproof in a totally over the top > way. Totally over the top is when SONAME changes or API changes are introduced into release branches _without_ prior communication or without clear benefit. > The end result being that nobody will do a soname bump in the > non-devel branch possible keeping nice packages out non devel branches > because they need a newer version and/or keeping bugs in the non-devel > branch because releasing the bugfix version would require the maintainer > todo some kinda big and long ceremonial dance. On the contrary, packagers switching BR from foo-devel to compat-foo-devel, not getting any bug fixes, then sticking to compat-foo-devel, with the result that there are multiple instances of "foo" in a release branch, some with -devel packages, others not. No fun! > I wrote this with cases like directfb in mind where upstream changes the > soname every! release. This is an education problem. Contact upstream and lobby for a smarter release scheme. I've seen library authors who just didn't care much about how their version info ended up in the soname in an inappropriate/unexpected way. Also, a single ugly case does not justify rushing things and coming up with a general policy which opens up the flood-gates for many other compat-libfooX packages to enter a distribution. Much of this is about _release branches_ of the distribution. And I really would like to see _who_ does the needed investigation as whether and how a new library breakes API/ABI and so on _before_ publishing rushed compat-foo packages. > The whole idea behind my policy proposal was to > have a sane and reasonably* safe policy, while at the same timing not > making it nearly impossible for maintainers to actually do an soname change. IMO, many maintainers don't do any ABI/API checks at all when they release upgrades. Similarly, they don't compare the feature set of released packages with the packages to be released. > *100% safe does not exist, get that stupid notion of 100% safe out of > your head please It's not stupid. It's a different point of view. > As I also wrote a API change which causes non trivial to fix build > errors, makes it mandatory to add a -devel sub package to the compat > package, so in the security problem case the fixed package can build > against this -compat-devel package. Which a) must co-exist with the new -devel package, must co-exist with further compat -devel packages (because you don't limit the number of compat packages), and b) can be a non-trivial thing to create (e.g. think of moving headers, renaming helper scripts, libfoo.so points to most recent SONAME). > But I've learned from your and other reactions that there is appearantly > no support on the list for a balanced soname policy. With the end > result being that there probably isn't going to be any policy at all. > > I must say I'm disappointed in the lack of the ability to see the > balance of things here on the list. > > Because of this will probably be my last post in this thread. For some topics it needs quite some endurance before a satisfactory solution is developed. From nicolas.mailhot at laposte.net Sat Jul 1 17:57:32 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 01 Jul 2006 19:57:32 +0200 Subject: Removing zoo from Fedora Extras In-Reply-To: <1151775005.13315.5.camel@localhost> References: <1151754990.9339.86.camel@rousalka.dyndns.org> <1151775005.13315.5.camel@localhost> Message-ID: <1151776653.9339.106.camel@rousalka.dyndns.org> Le samedi 01 juillet 2006 ? 12:30 -0500, Callum Lerwick a ?crit : > Some Atari ST software was packaged in zoo files, as well as a multitude > of other obscure long dead formats... > > But considering how long dead the Atari ST is now, I've been considering > just repacking everything in my Atari ST mirrors to zip and burn it all > to CDs. :P If you want to do it the hard way and take responsibility for cleaning up zoo code, just ask ;)) Regards, -- Nicolas Mailhot Portugal 3 - England 1 -------------- 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 Matt_Domsch at dell.com Sat Jul 1 18:38:33 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 1 Jul 2006 13:38:33 -0500 Subject: Mass rebuild of Extras packages for FC6? (was: Re: Mass rebuild of core packages coming soon) In-Reply-To: <645d17210607010355i1c6a3a1ey59606b226ad322c1@mail.gmail.com> References: <1151696839.21773.18.camel@dhcp83-49.boston.redhat.com> <44A64DB2.2080505@leemhuis.info> <645d17210607010355i1c6a3a1ey59606b226ad322c1@mail.gmail.com> Message-ID: <20060701183833.GA17654@lists.us.dell.com> On Sat, Jul 01, 2006 at 11:55:34AM +0100, Jonathan Underwood wrote: > On 01/07/06, Thorsten Leemhuis wrote: > >> 1) rpm signing w/ sha256sum > >> 2) New toolset feature to speed up dynamic lib linking by 50%~ > >3) get all packages build with the new and reduced set of packages > >installed in the default mock buildroot > > These all seem like good reasons for a rebuild to me. > > >4) make sure all packagers/contributors are still around just a we did > >during the mass-rebuild for FC5 > > This seems like a commendable desire, but I'm not sure that clobbering > the build system to achieve this goal alone is the best way to go > about it. The build system can handle it. A top-to-bottom rebuild of Extras takes ~24 hours on 3 x86_64 servers (I do it regularly). PPC would probably be the holdup, maybe dragging that out to 2 days... Let computers do what they're designed to do, and leave the more interesting work to humans. :-) Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From opensource at till.name Sun Jul 2 14:17:10 2006 From: opensource at till.name (Till Maas) Date: Sun, 02 Jul 2006 16:17:10 +0200 Subject: adding optipng to extras Message-ID: <200607021617.10414.opensource@till.name> Hiyas, I would like to package OptiPNG for Extras (http://optipng.sourceforge.net/). It is a PNG-optimizer and converter that tries to compress pngs the best way possible. It uses own version of zlib to get a better compression and pnglib to even work. Can it be added to Extras anyways? Regards, Till From jonathan.underwood at gmail.com Sun Jul 2 15:04:29 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 2 Jul 2006 16:04:29 +0100 Subject: adding optipng to extras In-Reply-To: <200607021617.10414.opensource@till.name> References: <200607021617.10414.opensource@till.name> Message-ID: <645d17210607020804h2e654109nd51fd8d1e74ce202@mail.gmail.com> On 02/07/06, Till Maas wrote: > I would like to package OptiPNG for Extras (http://optipng.sourceforge.net/). > It is a PNG-optimizer and converter that tries to compress pngs the best way > possible. It uses own version of zlib to get a better compression and pnglib > to even work. Can it be added to Extras anyways? The license, which is apparently the zlib/libpng license (from the project webpage) reads: Copyright (C) 2001-2006 Cosmin Truta. This software is provided 'as-is', without any express or implied warranty. In no event will the author(s) be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. As such, I believe that is fine wrt FE inclusion. The program as far as I can tell doesn't use any patented compression schemes. I'm sure other members of the list will verify/dispute these observations :) Have you read the instructions for contributing to FE? They can be found here: http://fedoraproject.org/wiki/Extras/Contributors Best wishes, Jonathan From opensource at till.name Sun Jul 2 15:16:58 2006 From: opensource at till.name (Till Maas) Date: Sun, 02 Jul 2006 17:16:58 +0200 Subject: adding optipng to extras In-Reply-To: <645d17210607020804h2e654109nd51fd8d1e74ce202@mail.gmail.com> References: <200607021617.10414.opensource@till.name> <645d17210607020804h2e654109nd51fd8d1e74ce202@mail.gmail.com> Message-ID: <200607021716.58400.opensource@till.name> Hello, Am Sonntag, 2. Juli 2006 17:04 schrieb Jonathan Underwood: > On 02/07/06, Till Maas wrote: > > I would like to package OptiPNG for Extras > > (http://optipng.sourceforge.net/). It is a PNG-optimizer and converter > > that tries to compress pngs the best way possible. It uses own version of > > zlib to get a better compression and pnglib to even work. Can it be added > > to Extras anyways? > Have you read the instructions for contributing to FE? They can be found > here: http://fedoraproject.org/wiki/Extras/Contributors yes, thanks for your comment, actually I was refering to the Guidelines in my first email. Sorry, that I did not make this clear. http://fedoraproject.org/wiki/Packaging/Guidelines#head-17396a3b06ec849a7c0c6fc3243673b17e5fed90 says that packages should not include their own version of a library. This is what OptiPNG does. Does this block OptiPNG from beeing added to Extras? Regards, Till From sopwith at redhat.com Sun Jul 2 15:45:09 2006 From: sopwith at redhat.com (Elliot Lee) Date: Sun, 2 Jul 2006 11:45:09 -0400 Subject: Fwd: [Fedora-infrastructure-list] New package version control References: <1151617881.3023.17.camel@localhost> Message-ID: <02182270-6372-41B3-A3FE-F9EC1BDC2BF8@redhat.com> Relevant to Extras in particular... -- Elliot Begin forwarded message: > From: Toshio Kuratomi > Date: June 29, 2006 17:51:21 EDT > To: fedora-infrastructure-list at redhat.com > Subject: [Fedora-infrastructure-list] New package version control > > Greetings all, > > A few of us, warren, mmcgrath, and I are designing a new system of > version control for the packages in Core and Extras. The main page of > requirements and some pros and cons of various VCS's are listed on: > http://www.fedoraproject.org/wiki/Infrastructure/VersionControl/ > > If you have some dispassionate features or reviews to add about any > VCS > you think could address the requirements, go ahead and add it to the > page. > > A draft of one possible prototype is here: > http://www.fedoraproject.org/wiki/Infrastructure/VersionControl/ > ArchitectureDraft > > The ArchitectureDraft attempts to address the list of > requirements. An > actual implementation is in the works to see how well it actually > meets > our needs. > > mmcgrath is working on a separate prototype using subversion that > sounds > like it is close to being ready for an initial review. > > Comments specific to the drafts or with ideas for doing things > differently are entirely welcome :-) Let's get some discussion going! > > -Toshio > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From sopwith at redhat.com Sun Jul 2 15:56:26 2006 From: sopwith at redhat.com (Elliot Lee) Date: Sun, 2 Jul 2006 11:56:26 -0400 Subject: [Fedora-infrastructure-list] Extras Package Database In-Reply-To: <44A5F9BD.8030502@knox.net.nz> References: <821D642B-63A5-4CEE-A82D-DE14C8B3FA14@redhat.com> <44A5F9BD.8030502@knox.net.nz> Message-ID: On Jul 1, 2006, at 00:27, Michael J. Knox wrote: > Elliot Lee wrote: >> Hi all, >> http://fedoraproject.org/wiki/Infrastructure/PackageDatabase has >> been out there for a bit... >> I've put together a strawman schema (as a TurboGears model.py) to >> help move things along - apologies if someone else has beaten me >> to it. I think at this point the right questions to be asking are >> long the lines of "will this schema support feature X or use case >> Y?". From a quick glance at the web page, I *think* it mostly >> will. There are some problems with this still, but open source is >> all about fixing those problems :) > > This is cool Elliot. This is a project I would like to help out on, > but didn't really know where to start. That in itself is helpful to know, because it's never 100% clear whether progress is dependent on having time or having knowledge :) In general, quite a few projects are at the stage where the main helping out to be done is figuring out what needs to be done. There's no set task list for the packageDB or account system, just a need for someone to figure out what's going on, and to keep pushing at it until a complete spec emerges. Are there areas where others could use more elaboration to get them started? Best, -- Elliot From jonathan.underwood at gmail.com Sun Jul 2 16:13:33 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 2 Jul 2006 17:13:33 +0100 Subject: adding optipng to extras In-Reply-To: <200607021716.58400.opensource@till.name> References: <200607021617.10414.opensource@till.name> <645d17210607020804h2e654109nd51fd8d1e74ce202@mail.gmail.com> <200607021716.58400.opensource@till.name> Message-ID: <645d17210607020913r22c3c79tbfa738d01c0a73a2@mail.gmail.com> On 02/07/06, Till Maas wrote: > yes, thanks for your comment, actually I was refering to the Guidelines in my > first email. Sorry, that I did not make this clear. > http://fedoraproject.org/wiki/Packaging/Guidelines#head-17396a3b06ec849a7c0c6fc3243673b17e5fed90 > says that packages should not include their own version of a library. This is > what OptiPNG does. Does this block OptiPNG from beeing added to Extras? Yes, I believe that is a blocker. You could package it to use the currently packaged version of that library though. Or convince upstream OptiPNG folks to move to using the upstream library, submitting their patches if necessary. What library is it that they include? Jonathan From dragoran at feuerpokemon.de Sun Jul 2 16:19:48 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 02 Jul 2006 18:19:48 +0200 Subject: adding optipng to extras In-Reply-To: <645d17210607020913r22c3c79tbfa738d01c0a73a2@mail.gmail.com> References: <200607021617.10414.opensource@till.name> <645d17210607020804h2e654109nd51fd8d1e74ce202@mail.gmail.com> <200607021716.58400.opensource@till.name> <645d17210607020913r22c3c79tbfa738d01c0a73a2@mail.gmail.com> Message-ID: <44A7F224.7010307@feuerpokemon.de> Jonathan Underwood wrote: > On 02/07/06, Till Maas wrote: >> yes, thanks for your comment, actually I was refering to the >> Guidelines in my >> first email. Sorry, that I did not make this clear. >> http://fedoraproject.org/wiki/Packaging/Guidelines#head-17396a3b06ec849a7c0c6fc3243673b17e5fed90 >> >> says that packages should not include their own version of a library. >> This is >> what OptiPNG does. Does this block OptiPNG from beeing added to Extras? > > Yes, I believe that is a blocker. You could package it to use the > currently packaged version of that library though. Or convince > upstream OptiPNG folks to move to using the upstream library, > submitting their patches if necessary. What library is it that they > include? > > Jonathan > from the first post: > It uses own version of zlib to get a better compression and pnglib > to even work. From fedora at leemhuis.info Sun Jul 2 16:53:30 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 02 Jul 2006 18:53:30 +0200 Subject: Summary from the last FESCo meeting Message-ID: <44A7FA0A.6020902@leemhuis.info> == Summary == Present from FESCo: thl, scop, mschwendt, spot * FESCo election * round about only 50 votes so far * thl will send out a "go voting" reminder * CTRL-C problem (cvs-commits-mails can be prevented by hitting CTRL+C during commit) * Ticket 2006070210000016 created in OTRS * Weekly sponsorship nomination * Orion Poplawski upgraded to sponsor * some discussion about making Steve Pritchard sponsor. He he doesn't do much reviews but he maintains 83 packages in Extras. Some people say "Given the large # of packages he maintains, I think we know his loyalties and it wouldn't hurt to give it to him. (He probably wont screw things up.) Whether it would benefit us is unclear though if he doesn't review." while others "like to see more reviews". * Sponsors' obligations are not documented anywhere, unfortunately * discuss this on the list further * legacy updates in build roots * added by dgilmore; more discussion on the list * scop gave a quick summary from the first packaging committee meeting * A real summary will be sent out soon * /usr/libexec is ok * mono is all %{_libdir}, no noarch * ruby packaging guidelines are a-ok * php guidelines need some work, moratorium called * confirmed packaging committee members: http://fedoraproject.org/wiki/PackagingGroup * Note: this was the last meeting of the "old" FESCo. The newly elected FESCo will meet for the first time next Thursday == Full Log == http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060629 From opensource at till.name Sun Jul 2 18:12:29 2006 From: opensource at till.name (Till Maas) Date: Sun, 02 Jul 2006 20:12:29 +0200 Subject: adding optipng to extras In-Reply-To: <645d17210607020913r22c3c79tbfa738d01c0a73a2@mail.gmail.com> References: <200607021617.10414.opensource@till.name> <200607021716.58400.opensource@till.name> <645d17210607020913r22c3c79tbfa738d01c0a73a2@mail.gmail.com> Message-ID: <200607022012.29594.opensource@till.name> Am Sonntag, 2. Juli 2006 18:13 schrieb Jonathan Underwood: > Yes, I believe that is a blocker. You could package it to use the > currently packaged version of that library though. Or convince > upstream OptiPNG folks to move to using the upstream library, > submitting their patches if necessary. What library is it that they > include? OptiPNG can be compiled with the system libz, but according to the author then OptiPNG may not be as efficient. He only changed some constants in zlib so I do not think this will be changed upstream. In libpng he changed some constants, too. But he also uses some private functions or structures that cannot be accessed otherwise. Regards, Till From dmobrien_2001 at yahoo.com Sun Jul 2 21:02:13 2006 From: dmobrien_2001 at yahoo.com (Dan O'Brien) Date: Sun, 2 Jul 2006 14:02:13 -0700 (PDT) Subject: Fw: [Audacity-devel] [Audacity-help] Fedora Core Audacity w/o MP3 "support" Message-ID: <20060702210213.52270.qmail@web31807.mail.mud.yahoo.com> According to the Audacity developers, libmad is not patent encumbered and it should be possible for Fedora Core to distribute libmad and compile Audacity against it. I've contacted the libmad developers to get their take. I'm going to foward another email from them next. I appeal to the Fedora Extra gods to reconsider libmad and Audacity so that us mere mortals not have to recompile Audacity with MP3 support. This leads to a messy system per my bugzilla report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196981 Rgds, Dan O'Brien, dmobrien_2001 at yahoo.com Phone: 614-783-4859 ----- Forwarded Message ---- From: Richard Ash To: Dan O'Brien Cc: David Avery ; audacity-help at lists.sourceforge.net; audacity-devel at lists.sourceforge.net; richard at audacityteam.org Sent: Sunday, July 2, 2006 1:51:47 PM Subject: Re: [Audacity-devel] [Audacity-help] Fedora Core Audacity w/o MP3 "support" Dan O'Brien wrote: > Thanks, I understand the MP3 patent issue. > XMMS, mplayer, and others be compiled and ship unencumbered and > by adding libraries outside of the formal vendor distributions > and then they support MP3. > Why can't audacity work similarly so the distributions can ship the > unencumbered > code and allow the end user the choice of adding the required > libraries instead of recompiling the source code. The can do. Libmad is not patent encumbered, and LAME is not required to build audacity. Therefore any distribution can supply audacity compiled with libmad support and with the DLL-loader interface set up ready to use LAME. This is not at any point patent encumbered (it's the way Windows binaries of audacity are shipped). The user can then obtain libmp3lame.so and use it if they so wish, or have a fully functional editor without MP3 exports without it. Every other distro that ships audacity does this without problems. Richard Ash > ----- Original Message ---- > From: David Avery > To: audacity-help at lists.sourceforge.net; > audacity-devel at lists.sourceforge.net > Cc: Dan O'Brien ; richard at audacityteam.org > Sent: Saturday, July 1, 2006 9:43:24 PM > Subject: Re: [Audacity-devel] [Audacity-help] Fedora Core Audacity w/o MP3 > "support" > > Richard Ash wrote: >> On Tue, 2006-06-27 at 18:24 -0700, Dan O'Brien wrote: >>> I reported this bug to Fedora Core support: >>> >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196981 >>> >>> They won't provide Audacity with MP3 support "compiled" saying that >>> it requires libmad which makes it tainted with regards MP3 patents. >>> >>> >From the Audacity FAQ it seems this is contrary to Audacity's original >>> intent to be able to handle MP3 but not directly ship patent encumbered >>> code. >>> >>> Who's right? >> >> The two comments relate to different code, and the bugzilla entry is >> failing to distinguish them. >> >> libmad (http://www.underbit.com/products/mad/) is not covered by any of >> the MP3 software patents to my knowledge. As an MP3 DECODER only it is >> certainly not covered by the Thompson patents surrounding MP3 ENCODING >> software. >> >> LAME (http://lame.sourceforge.net/) is an MP3 ENCODING library, and as >> such subject to the Thompson AG patents in such jusidictions as they are >> valid - basically in the US, not in quite a lot of Europe at the moment. >> >> libmad is required to IMPORT MP3 files, and is a compile-time option >> when building audacity. This does not to the best of our knowledge >> infringe any software patents and can be freely distributed. >> >> LAME is required only to EXPORT MP3 files, and is a run-time option. >> This means that it is always enabled in the binary, but does not work >> without the libmp3lame.so library installed. This is a choice that the >> user can make if they can legitimately obtain and use the LAME library >> in their jurisdiction. >> >> To say Audacity has "MP3 Support" is therefore misleading - there are >> two separate options, to enable MP3 IMPORTING via libmad, and to enable >> MP3 EXPORTING via LAME. >> >> Regardless of the enable/disable libmad options you can always use LAME >> for exporting at runtime, and there is not a patent issue with linking >> audacity against libmad for importing. >> >> Richard Ash > see: http://www.mp3licensing.com/royalty/software.html > > MP3 requires minimum payment of US$ 15000.00 / year for software > encoders or decoders. decoders are US$0.75 / unit or US$50,000.00 > onetime. encoders are US$2.50 per unit. and they will not allow > redistribution. > > fedora is therefore unable to ship _any_ MP3 encoding or decoding software > > > > > > From dmobrien_2001 at yahoo.com Sun Jul 2 21:02:57 2006 From: dmobrien_2001 at yahoo.com (Dan O'Brien) Date: Sun, 2 Jul 2006 14:02:57 -0700 (PDT) Subject: Fw: [Audacity-devel] [Audacity-help] Fedora Core Audacity w/o MP3 "support" Message-ID: <20060702210257.67771.qmail@web31809.mail.mud.yahoo.com> Send email regarding Audacity vsv libmad Rgds, Dan O'Brien, dmobrien_2001 at yahoo.com Phone: 614-783-4859 ----- Forwarded Message ---- From: Richard Ash To: David Avery ; Dan O'Brien Cc: audacity-help at lists.sourceforge.net; audacity-devel at lists.sourceforge.net Sent: Sunday, July 2, 2006 2:17:59 PM Subject: Re: [Audacity-devel] [Audacity-help] Fedora Core Audacity w/o MP3 "support" David Avery wrote: > see: http://www.mp3licensing.com/royalty/software.html > > MP3 requires minimum payment of US$ 15000.00 / year for software > encoders or decoders. decoders are US$0.75 / unit or US$50,000.00 > onetime. encoders are US$2.50 per unit. and they will not allow > redistribution. > fedora is therefore unable to ship _any_ MP3 encoding or decoding software The decoder licensing is not enforecable in most parts of the world, and I don't know of a single program paying it. The original patents granted were for encoders, and those are the only ones that have been actively enforced. No-one actually knows what patent number (presumably US patent) the decoder license is for, as none of the ones usally cited cover any decoding of ISO compliant material. The last debate of this on the libmad development list came to no conclusion in 2002, as far as I can see from the archives. Richard Ash From lists at forevermore.net Mon Jul 3 05:33:28 2006 From: lists at forevermore.net (Chris Petersen) Date: Sun, 02 Jul 2006 22:33:28 -0700 Subject: Fwd: [Fedora-infrastructure-list] New package version control In-Reply-To: <02182270-6372-41B3-A3FE-F9EC1BDC2BF8@redhat.com> References: <1151617881.3023.17.camel@localhost> <02182270-6372-41B3-A3FE-F9EC1BDC2BF8@redhat.com> Message-ID: <44A8AC28.9010600@forevermore.net> >> A few of us, warren, mmcgrath, and I are designing a new system of >> version control for the packages in Core and Extras. The main page of >> requirements and some pros and cons of various VCS's are listed on: >> http://www.fedoraproject.org/wiki/Infrastructure/VersionControl/ >> >> If you have some dispassionate features or reviews to add about any VCS >> you think could address the requirements, go ahead and add it to the >> page. Wasn't quite sure how to put this on the page, so I'm posting here. "con" for subversion is listed that auth must be through DAV, but a "pro" for mercurial is that it can do ssh. Just an fyi, but subversion works GREAT over ssh (via the svn+ssh:// uri), and projects like mythtv use this to separate anon checkout (http) with developer access (ssh). Granted, you're still limited to "full repository" access or no access with ssh since svn handles everything in its own database format. -Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From toshio at tiki-lounge.com Mon Jul 3 06:10:03 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sun, 02 Jul 2006 23:10:03 -0700 Subject: Fwd: [Fedora-infrastructure-list] New package version control In-Reply-To: <44A8AC28.9010600@forevermore.net> References: <1151617881.3023.17.camel@localhost> <02182270-6372-41B3-A3FE-F9EC1BDC2BF8@redhat.com> <44A8AC28.9010600@forevermore.net> Message-ID: <1151907003.3038.9.camel@localhost> On Sun, 2006-07-02 at 22:33 -0700, Chris Petersen wrote: > >> A few of us, warren, mmcgrath, and I are designing a new system of > >> version control for the packages in Core and Extras. The main page of > >> requirements and some pros and cons of various VCS's are listed on: > >> http://www.fedoraproject.org/wiki/Infrastructure/VersionControl/ > >> > >> If you have some dispassionate features or reviews to add about any VCS > >> you think could address the requirements, go ahead and add it to the > >> page. > > Wasn't quite sure how to put this on the page, so I'm posting here. > > "con" for subversion is listed that auth must be through DAV, but a > "pro" for mercurial is that it can do ssh. Just an fyi, but subversion > works GREAT over ssh (via the svn+ssh:// uri), and projects like mythtv > use this to separate anon checkout (http) with developer access (ssh). > > Granted, you're still limited to "full repository" access or no access > with ssh since svn handles everything in its own database format. Yeah, that's pretty much a blocker for using svn+ssh. One of the requirements is that each individual developer may or may not have access to a branch of the repository. This could be emulated with a slew of repositories but I don't think subversion is really meant to handle that sort of setup the way a distributed version control system is. I don't know how mercurial handles this differently, though. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at fedoraproject.org Mon Jul 3 10:44:30 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 3 Jul 2006 06:44:30 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-03 Message-ID: <20060703104430.7434115217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 24 clips-6.24-14.fc5 darcs-1.0.8-2.fc5 djvulibre-3.5.17-1.fc5 gcfilms-6.3-1.fc5 ghdl-0.23-0.58svn.1.fc5 gtk-qt-engine-0.60-10.cvs20060629.fc5 haddock-0.7-3.fc5 kdirstat-2.5.3-3.fc5 lat-1.0.6-1.fc5 libkexif-0.2.4-1.fc5 mail-notification-3.0-2.fc5 paraview-2.4.3-7.fc5 perl-List-Compare-0.33-1.fc5 perl-Module-ScanDeps-0.61-1.fc5 perl-PAR-Dist-0.10-1.fc5 perl-Regexp-Shellish-0.93-2.fc5 perl-YAML-0.58-3.fc5 php-pecl-mailparse-2.1.1-4.fc5 python-sqlite2-2.3.2-1.fc5 qps-1.9.17-1.fc5 verbiste-0.1.14-2.fc5 wavpack-4.32-2.fc5 wine-0.9.16-1.fc5 xcompmgr-1.1.3-4.fc5.1 Packages built and released for Fedora Extras 4: 9 bazaar-1.4.2-7.fc4 gcfilms-6.3-1.fc4 gtk-qt-engine-0.60-10.cvs20060629.fc4 mail-notification-3.0-1.fc4 perl-List-Compare-0.33-1.fc4 perl-Module-ScanDeps-0.61-1.fc4 perl-Regexp-Shellish-0.93-2.fc4 qps-1.9.17-1.fc4 verbiste-0.1.14-2.fc4 Packages built and released for Fedora Extras 3: 0 Packages built and released for Fedora Extras development: 36 clips-6.24-14.fc6 cmake-2.4.2-1.fc6 compat-erlang-R10B-10.3.fc6 djvulibre-3.5.17-1.fc6 ez-ipupdate-3.0.11-0.10.b8.fc6 ganymed-ssh2-209-4.fc6 gcfilms-6.3-1.fc6 gdl-0.9-0.pre2.fc6 haddock-0.7-3.fc6 i8kutils-1.25-10.fc6 javasvn-1.0.6-1.fc6 kdirstat-2.5.3-3.fc6 lat-1.0.6-1.fc6 libkexif-0.2.4-1.fc6 lirc-0.8.1-0.1.pre1.fc6 mail-notification-3.0-2.fc6 moin-1.5.4-1.fc6 nazghul-0.5.4-1.fc6 paraview-2.4.3-8.fc6 perl-BerkeleyDB-0.28-1.fc6 perl-CPANPLUS-0.072-1.fc6 perl-Data-Structure-Util-0.12-1.fc6 perl-List-Compare-0.33-1.fc6 perl-Module-ScanDeps-0.61-1.fc6 perl-Parse-CPAN-Packages-2.26-2.fc6 perl-Regexp-Shellish-0.93-2.fc6 perl-Test-Base-0.52-1.fc6 php-pecl-mailparse-2.1.1-4.fc6 python-sqlite2-2.3.2-1.fc6 qps-1.9.17-1.fc6 qt4-4.1.4-5.fc6 wavpack-4.32-2.fc6 wine-0.9.16-1.fc6 xbindkeys-1.7.3-3.fc6 xcompmgr-1.1.3-4.fc6 xscreensaver-5.00-12.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Jul 3 10:44:59 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 3 Jul 2006 06:44:59 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-03 Message-ID: <20060703104459.EB76E15217B@buildsys.fedoraproject.org> abiword: 5: 1:2.4.4-4.fc5 (FE5) 6: 1:2.4.4-2.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) brightside: 5: 0:1.4.0-11.fc5 (FE5) 6: 0:1.4.0-10.fc5 (FE6) cairo-java: 5: 0:1.0.4-0.FC5 (FC5-updates) 6: 0:1.0.4-0 (FC6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.0 (FC6) dosfstools: 5: 0:2.11-5.FC5 (FC5-updates) 6: 0:2.11-5 (FC6) dovecot: 5: 0:1.0-0.beta8.2.fc5 (FC5-updates) 6: 0:1.0-0.beta8.2 (FC6) ecl: 5: 0:0.9h-6.fc5 (FE5) 6: 0:0.9h-5.fc5 (FE6) factory: 5: 0:2.0.5-7.fc5 (FE5) 6: 0:2.0.5-6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) ghdl: 5: 0:0.23-0.58svn.1.fc5 (FE5) 6: 0:0.23-0.58svn.0.fc6 (FE6) glib-java: 5: 0:0.2.5-0.FC5 (FC5-updates) 6: 0:0.2.5-0 (FC6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) hspell: 4: 0:1.0-4.fc4 (FE4) 5: 0:1.0-3.fc5 (FE5) 6: 0:1.0-3.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libfac: 5: 0:2.0.5-4.fc5 (FE5) 6: 0:2.0.5-3 (FE6) libglade-java: 5: 0:2.12.4-0.FC5 (FC5-updates) 6: 0:2.12.4-0 (FC6) libgnome-java: 5: 0:2.12.3-0.FC5 (FC5-updates) 6: 0:2.12.3-0 (FC6) libgtk-java: 5: 0:2.8.5-0.FC5 (FC5-updates) 6: 0:2.8.5-0 (FC6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libvirt: 5: 0:0.1.1-1.FC5 (FC5-updates) 6: 0:0.1.1-1 (FC6) libvte-java: 5: 0:0.12.0-0.FC5 (FC5-updates) 6: 0:0.12.0-0 (FC6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-10.fc6 (FC6) mcelog: 5: 1:0.7-1.20_FC5 (FC5-updates) 6: 1:0.7-1.19 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) nfs-utils: 5: 1:1.0.8-2.fc5 (FC5-updates) 6: 0:1.0.8-2 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-Net-Jabber: 5: 0:2.0-6.fc5 (FE5) 6: 0:2.0-5.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96-6.fc5 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) squid: 5: 7:2.5.STABLE14-2.FC5 (FC5-updates) 6: 7:2.5.STABLE14-2 (FC6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion: 5: 0:1.3.2-2.1 (FC5-updates) 6: 0:1.3.1-4 (FC6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) tcl: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) testdisk: 5: 0:6.4-2.fc5 (FE5) 6: 0:6.3-1.fc5 (FE6) tetex-fonts-hebrew: 4: 0:0.1-6.fc4 (FE4) 5: 0:0.1-5.fc5 (FE5) 6: 0:0.1-5.fc6 (FE6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) tk: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tzdata: 5: 0:2006g-1.fc5 (FC5-updates) 6: 0:2006g-1 (FC6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) verbiste: 5: 0:0.1.14-2.fc5 (FE5) 6: 0:0.1.14-1.1.fc5 (FE6) wine-docs: 3: 0:0.9.16-1.fc3 (FE3) 4: 0:0.9.16-0.1.fc4 (FE4) 5: 0:0.9.16-1.fc5 (FE5) 6: 0:0.9.16-1.fc6 (FE6) From Axel.Thimm at ATrpms.net Mon Jul 3 11:16:11 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 3 Jul 2006 13:16:11 +0200 Subject: New package version control In-Reply-To: <1151907003.3038.9.camel@localhost> References: <1151617881.3023.17.camel@localhost> <02182270-6372-41B3-A3FE-F9EC1BDC2BF8@redhat.com> <44A8AC28.9010600@forevermore.net> <1151907003.3038.9.camel@localhost> Message-ID: <20060703111611.GA25241@neu.nirvana> On Sun, Jul 02, 2006 at 11:10:03PM -0700, Toshio Kuratomi wrote: > On Sun, 2006-07-02 at 22:33 -0700, Chris Petersen wrote: > > >> A few of us, warren, mmcgrath, and I are designing a new system of > > >> version control for the packages in Core and Extras. The main page of > > >> requirements and some pros and cons of various VCS's are listed on: > > >> http://www.fedoraproject.org/wiki/Infrastructure/VersionControl/ > > >> > > >> If you have some dispassionate features or reviews to add about any VCS > > >> you think could address the requirements, go ahead and add it to the > > >> page. > > > > Wasn't quite sure how to put this on the page, so I'm posting here. > > > > "con" for subversion is listed that auth must be through DAV, but a > > "pro" for mercurial is that it can do ssh. Just an fyi, but subversion > > works GREAT over ssh (via the svn+ssh:// uri), and projects like mythtv > > use this to separate anon checkout (http) with developer access (ssh). I added some remarks to the page yesterday to reflect this. I'm no mercurial expert (only used it slightly), but AFAIU both svn and hg have the same authentication problems/solution. ssh is too coarse and the web side is best served through apache and using the same auth mechanisms. > > Granted, you're still limited to "full repository" access or no access > > with ssh since svn handles everything in its own database format. > > Yeah, that's pretty much a blocker for using svn+ssh. One of the > requirements is that each individual developer may or may not have > access to a branch of the repository. This could be emulated with a > slew of repositories but I don't think subversion is really meant to > handle that sort of setup the way a distributed version control system > is. > > I don't know how mercurial handles this differently, though. Doesn't mercurial pushing (write access) require *require* ssh (or local access in general)? At least that was what I was told on the mercurial list http://www.selenic.com/pipermail/mercurial/2006-April/007542.html -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Mon Jul 3 11:04:26 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 03 Jul 2006 11:04:26 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-03 Message-ID: <20060703110426.24596.35228@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc4.i386 maxima-runtime-sbcl - 5.9.3-4.fc4.ppc maxima-runtime-sbcl - 5.9.3-4.fc4.x86_64 qt4-config - 4.1.4-1.fc4.i386 qt4-config - 4.1.4-1.fc4.ppc qt4-config - 4.1.4-1.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.i386 requires sbcl = 0:0.9.13 qt4-config-4.1.4-1.fc4.i386 requires qt4 = 0:4.1.4-1.fc4 wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.ppc requires sbcl = 0:0.9.13 qt4-config-4.1.4-1.fc4.ppc requires qt4 = 0:4.1.4-1.fc4 wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.x86_64 requires sbcl = 0:0.9.13 qt4-config-4.1.4-1.fc4.x86_64 requires qt4 = 0:4.1.4-1.fc4 wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) From buildsys at fedoraproject.org Mon Jul 3 11:04:26 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 03 Jul 2006 11:04:26 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-03 Message-ID: <20060703110426.24603.1836@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de qiv - 2.0-4.i386 qiv - 2.0-4.ppc qiv - 2.0-4.x86_64 wine - 0.9.16-1.fc6.i386 wine-arts - 0.9.16-1.fc6.i386 wine-capi - 0.9.16-1.fc6.i386 wine-cms - 0.9.16-1.fc6.i386 wine-devel - 0.9.16-1.fc6.i386 wine-esd - 0.9.16-1.fc6.i386 wine-jack - 0.9.16-1.fc6.i386 wine-ldap - 0.9.16-1.fc6.i386 wine-nas - 0.9.16-1.fc6.i386 wine-tools - 0.9.16-1.fc6.i386 wine-twain - 0.9.16-1.fc6.i386 byte AT fedoraproject.org MagicPoint - 1.11b-2.fc5.i386 MagicPoint - 1.11b-2.fc5.ppc MagicPoint - 1.11b-2.fc5.x86_64 gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 extras-orphan AT fedoraproject.org Gtk-Perl - 0.7008-40.fc5.i386 Gtk-Perl - 0.7008-40.fc5.ppc Gtk-Perl - 0.7008-40.fc5.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 paul AT all-the-johnsons.co.uk amaya - 8.5-2.x86_64 amaya - 9.5-1.fc6.i386 amaya - 9.5-1.fc6.ppc qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 rdieter AT math.unl.edu qt4-config - 4.1.4-1.fc6.i386 qt4-config - 4.1.4-1.fc6.ppc qt4-config - 4.1.4-1.fc6.x86_64 qt4-debug - 4.1.4-2.fc6.i386 qt4-debug - 4.1.4-2.fc6.ppc qt4-debug - 4.1.4-2.fc6.x86_64 steve AT silug.org perl-CPANPLUS - 0.072-1.fc6.noarch perl-CPANPLUS - 0.072-1.fc6.noarch perl-CPANPLUS - 0.072-1.fc6.noarch Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.i386 requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.i386 requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.i386 requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.i386 requires libzvt.so.2 MagicPoint-1.11b-2.fc5.i386 requires imlib MagicPoint-1.11b-2.fc5.i386 requires libImlib.so.11 amaya-9.5-1.fc6.i386 requires libgdk_imlib.so.1 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 perl-CPANPLUS-0.072-1.fc6.noarch requires perl(Package::Constants) qiv-2.0-4.i386 requires libgdk_imlib.so.1 qt4-config-4.1.4-1.fc6.i386 requires qt4 = 0:4.1.4-1.fc6 qt4-debug-4.1.4-2.fc6.i386 requires qt4 = 0:4.1.4-2.fc6 sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.ppc requires libglade.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libart_lgpl.so.2 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomesupport.so.0 Gtk-Perl-0.7008-40.fc5.ppc requires libgnome.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libgdk_imlib.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgtkxmhtml.so.1 Gtk-Perl-0.7008-40.fc5.ppc requires libgnomeui.so.32 Gtk-Perl-0.7008-40.fc5.ppc requires libzvt.so.2 MagicPoint-1.11b-2.fc5.ppc requires imlib MagicPoint-1.11b-2.fc5.ppc requires libImlib.so.11 amaya-9.5-1.fc6.ppc requires libgdk_imlib.so.1 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgdk_imlib.so.1 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgdk_imlib.so.1 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 perl-CPANPLUS-0.072-1.fc6.noarch requires perl(Package::Constants) qiv-2.0-4.ppc requires libgdk_imlib.so.1 qt4-config-4.1.4-1.fc6.ppc requires qt4 = 0:4.1.4-1.fc6 qt4-debug-4.1.4-2.fc6.ppc requires qt4 = 0:4.1.4-2.fc6 sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- Gtk-Perl-0.7008-40.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomesupport.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libglade.so.0()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libart_lgpl.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgtkxmhtml.so.1()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnome.so.32()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libzvt.so.2()(64bit) Gtk-Perl-0.7008-40.fc5.x86_64 requires libgnomeui.so.32()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires libImlib.so.11()(64bit) MagicPoint-1.11b-2.fc5.x86_64 requires imlib amaya-8.5-2.x86_64 requires libgdk_imlib.so.1()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgdk_imlib.so.1()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) perl-CPANPLUS-0.072-1.fc6.noarch requires perl(Package::Constants) qiv-2.0-4.x86_64 requires libgdk_imlib.so.1()(64bit) qt4-config-4.1.4-1.fc6.x86_64 requires qt4 = 0:4.1.4-1.fc6 qt4-debug-4.1.4-2.fc6.x86_64 requires qt4 = 0:4.1.4-2.fc6 sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 wine-0.9.16-1.fc6.i386 requires wine-core = 0:0.9.16-1.fc6 wine-arts-0.9.16-1.fc6.i386 requires libwine.so.1(WINE_1.0) wine-arts-0.9.16-1.fc6.i386 requires libwine.so.1 wine-arts-0.9.16-1.fc6.i386 requires wine-core = 0:0.9.16-1.fc6 wine-arts-0.9.16-1.fc6.i386 requires libwine_unicode.so.1 wine-capi-0.9.16-1.fc6.i386 requires libwine.so.1(WINE_1.0) wine-capi-0.9.16-1.fc6.i386 requires libwine.so.1 wine-capi-0.9.16-1.fc6.i386 requires wine-core = 0:0.9.16-1.fc6 wine-cms-0.9.16-1.fc6.i386 requires libwine.so.1 wine-cms-0.9.16-1.fc6.i386 requires wine-core = 0:0.9.16-1.fc6 wine-cms-0.9.16-1.fc6.i386 requires libwine.so.1(WINE_1.0) wine-devel-0.9.16-1.fc6.i386 requires libwine_unicode.so.1(WINE_1.0) wine-devel-0.9.16-1.fc6.i386 requires libwine.so.1 wine-devel-0.9.16-1.fc6.i386 requires wine-core = 0:0.9.16-1.fc6 wine-devel-0.9.16-1.fc6.i386 requires libwine_unicode.so.1 wine-esd-0.9.16-1.fc6.i386 requires wine-core = 0:0.9.16-1.fc6 wine-esd-0.9.16-1.fc6.i386 requires libwine.so.1(WINE_1.0) wine-esd-0.9.16-1.fc6.i386 requires libwine.so.1 wine-jack-0.9.16-1.fc6.i386 requires libwine.so.1(WINE_1.0) wine-jack-0.9.16-1.fc6.i386 requires libwine.so.1 wine-jack-0.9.16-1.fc6.i386 requires wine-core = 0:0.9.16-1.fc6 wine-jack-0.9.16-1.fc6.i386 requires libwine_unicode.so.1 wine-ldap-0.9.16-1.fc6.i386 requires libwine.so.1(WINE_1.0) wine-ldap-0.9.16-1.fc6.i386 requires libwine.so.1 wine-ldap-0.9.16-1.fc6.i386 requires wine-core = 0:0.9.16-1.fc6 wine-nas-0.9.16-1.fc6.i386 requires libwine.so.1(WINE_1.0) wine-nas-0.9.16-1.fc6.i386 requires libwine.so.1 wine-nas-0.9.16-1.fc6.i386 requires wine-core = 0:0.9.16-1.fc6 wine-nas-0.9.16-1.fc6.i386 requires libwine_unicode.so.1 wine-tools-0.9.16-1.fc6.i386 requires libwine.so.1(WINE_1.0) wine-tools-0.9.16-1.fc6.i386 requires libwine.so.1 wine-tools-0.9.16-1.fc6.i386 requires wine-core = 0:0.9.16-1.fc6 wine-twain-0.9.16-1.fc6.i386 requires libwine.so.1(WINE_1.0) wine-twain-0.9.16-1.fc6.i386 requires libwine.so.1 wine-twain-0.9.16-1.fc6.i386 requires wine-core = 0:0.9.16-1.fc6 ====================================================================== New report for: lmacken AT redhat.com package: obby - 0.4.0-2.rc2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 package: sobby - 0.4.0-2.rc1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 package: gobby - 0.4.0-3.rc2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgnutls.so.12 package: obby - 0.4.0-2.rc2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) package: gobby - 0.4.0-3.rc2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) package: sobby - 0.4.0-2.rc1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnutls.so.12()(64bit) package: obby - 0.4.0-2.rc2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 package: gobby - 0.4.0-3.rc2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 package: sobby - 0.4.0-2.rc1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgnutls.so.12 ====================================================================== New report for: paul AT all-the-johnsons.co.uk package: amaya - 9.5-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgdk_imlib.so.1 package: amaya - 8.5-2.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgdk_imlib.so.1()(64bit) package: amaya - 9.5-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgdk_imlib.so.1 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: qiv - 2.0-4.i386 from fedora-extras-development-i386 unresolved deps: libgdk_imlib.so.1 package: wine-capi - 0.9.16-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc6 package: wine-cms - 0.9.16-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libwine.so.1 wine-core = 0:0.9.16-1.fc6 libwine.so.1(WINE_1.0) package: wine-devel - 0.9.16-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libwine_unicode.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc6 libwine_unicode.so.1 package: qiv - 2.0-4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgdk_imlib.so.1()(64bit) package: wine-arts - 0.9.16-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc6 libwine_unicode.so.1 package: wine-twain - 0.9.16-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc6 package: wine-esd - 0.9.16-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: wine-core = 0:0.9.16-1.fc6 libwine.so.1(WINE_1.0) libwine.so.1 package: wine-jack - 0.9.16-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc6 libwine_unicode.so.1 package: wine - 0.9.16-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: wine-core = 0:0.9.16-1.fc6 package: wine-ldap - 0.9.16-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc6 package: wine-nas - 0.9.16-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc6 libwine_unicode.so.1 package: wine-tools - 0.9.16-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc6 package: qiv - 2.0-4.ppc from fedora-extras-development-ppc unresolved deps: libgdk_imlib.so.1 ====================================================================== New report for: steve AT silug.org package: perl-CPANPLUS - 0.072-1.fc6.noarch from fedora-extras-development-i386 unresolved deps: perl(Package::Constants) package: perl-CPANPLUS - 0.072-1.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: perl(Package::Constants) package: perl-CPANPLUS - 0.072-1.fc6.noarch from fedora-extras-development-ppc unresolved deps: perl(Package::Constants) ====================================================================== New report for: byte AT fedoraproject.org package: MagicPoint - 1.11b-2.fc5.i386 from fedora-extras-development-i386 unresolved deps: imlib libImlib.so.11 package: MagicPoint - 1.11b-2.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libImlib.so.11()(64bit) imlib package: MagicPoint - 1.11b-2.fc5.ppc from fedora-extras-development-ppc unresolved deps: imlib libImlib.so.11 From buildsys at fedoraproject.org Mon Jul 3 11:04:26 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 03 Jul 2006 11:04:26 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-03 Message-ID: <20060703110426.24587.33543@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From buildsys at fedoraproject.org Mon Jul 3 11:04:26 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 03 Jul 2006 11:04:26 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-03 Message-ID: <20060703110426.24599.28434@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de wine - 0.9.16-1.fc5.i386 wine-arts - 0.9.16-1.fc5.i386 wine-capi - 0.9.16-1.fc5.i386 wine-cms - 0.9.16-1.fc5.i386 wine-devel - 0.9.16-1.fc5.i386 wine-esd - 0.9.16-1.fc5.i386 wine-jack - 0.9.16-1.fc5.i386 wine-ldap - 0.9.16-1.fc5.i386 wine-nas - 0.9.16-1.fc5.i386 wine-tools - 0.9.16-1.fc5.i386 wine-twain - 0.9.16-1.fc5.i386 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc5.i386 maxima-runtime-sbcl - 5.9.3-4.fc5.ppc maxima-runtime-sbcl - 5.9.3-4.fc5.x86_64 qt4-config - 4.1.4-1.fc5.i386 qt4-config - 4.1.4-1.fc5.ppc qt4-config - 4.1.4-1.fc5.x86_64 zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc5.i386 requires sbcl = 0:0.9.13 qt4-config-4.1.4-1.fc5.i386 requires qt4 = 0:4.1.4-1.fc5 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc5.ppc requires sbcl = 0:0.9.13 qt4-config-4.1.4-1.fc5.ppc requires qt4 = 0:4.1.4-1.fc5 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 maxima-runtime-sbcl-5.9.3-4.fc5.x86_64 requires sbcl = 0:0.9.13 qt4-config-4.1.4-1.fc5.x86_64 requires qt4 = 0:4.1.4-1.fc5 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 wine-0.9.16-1.fc5.i386 requires wine-core = 0:0.9.16-1.fc5 wine-arts-0.9.16-1.fc5.i386 requires libwine.so.1(WINE_1.0) wine-arts-0.9.16-1.fc5.i386 requires libwine.so.1 wine-arts-0.9.16-1.fc5.i386 requires wine-core = 0:0.9.16-1.fc5 wine-arts-0.9.16-1.fc5.i386 requires libwine_unicode.so.1 wine-capi-0.9.16-1.fc5.i386 requires libwine.so.1(WINE_1.0) wine-capi-0.9.16-1.fc5.i386 requires libwine.so.1 wine-capi-0.9.16-1.fc5.i386 requires wine-core = 0:0.9.16-1.fc5 wine-cms-0.9.16-1.fc5.i386 requires libwine.so.1 wine-cms-0.9.16-1.fc5.i386 requires wine-core = 0:0.9.16-1.fc5 wine-cms-0.9.16-1.fc5.i386 requires libwine.so.1(WINE_1.0) wine-devel-0.9.16-1.fc5.i386 requires libwine_unicode.so.1(WINE_1.0) wine-devel-0.9.16-1.fc5.i386 requires libwine_unicode.so.1 wine-devel-0.9.16-1.fc5.i386 requires wine-core = 0:0.9.16-1.fc5 wine-esd-0.9.16-1.fc5.i386 requires libwine.so.1(WINE_1.0) wine-esd-0.9.16-1.fc5.i386 requires libwine.so.1 wine-esd-0.9.16-1.fc5.i386 requires wine-core = 0:0.9.16-1.fc5 wine-jack-0.9.16-1.fc5.i386 requires libwine.so.1(WINE_1.0) wine-jack-0.9.16-1.fc5.i386 requires libwine.so.1 wine-jack-0.9.16-1.fc5.i386 requires libwine_unicode.so.1 wine-jack-0.9.16-1.fc5.i386 requires wine-core = 0:0.9.16-1.fc5 wine-ldap-0.9.16-1.fc5.i386 requires libwine.so.1(WINE_1.0) wine-ldap-0.9.16-1.fc5.i386 requires libwine.so.1 wine-ldap-0.9.16-1.fc5.i386 requires wine-core = 0:0.9.16-1.fc5 wine-nas-0.9.16-1.fc5.i386 requires libwine.so.1(WINE_1.0) wine-nas-0.9.16-1.fc5.i386 requires libwine.so.1 wine-nas-0.9.16-1.fc5.i386 requires libwine_unicode.so.1 wine-nas-0.9.16-1.fc5.i386 requires wine-core = 0:0.9.16-1.fc5 wine-tools-0.9.16-1.fc5.i386 requires libwine.so.1(WINE_1.0) wine-tools-0.9.16-1.fc5.i386 requires libwine.so.1 wine-tools-0.9.16-1.fc5.i386 requires wine-core = 0:0.9.16-1.fc5 wine-twain-0.9.16-1.fc5.i386 requires libwine.so.1(WINE_1.0) wine-twain-0.9.16-1.fc5.i386 requires libwine.so.1 wine-twain-0.9.16-1.fc5.i386 requires wine-core = 0:0.9.16-1.fc5 ====================================================================== New report for: oliver AT linux-kernel.at package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: wine-capi - 0.9.16-1.fc5.i386 from fedora-extras-5-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc5 package: wine-cms - 0.9.16-1.fc5.i386 from fedora-extras-5-x86_64 unresolved deps: libwine.so.1 wine-core = 0:0.9.16-1.fc5 libwine.so.1(WINE_1.0) package: wine - 0.9.16-1.fc5.i386 from fedora-extras-5-x86_64 unresolved deps: wine-core = 0:0.9.16-1.fc5 package: wine-twain - 0.9.16-1.fc5.i386 from fedora-extras-5-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc5 package: wine-arts - 0.9.16-1.fc5.i386 from fedora-extras-5-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc5 libwine_unicode.so.1 package: wine-ldap - 0.9.16-1.fc5.i386 from fedora-extras-5-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc5 package: wine-nas - 0.9.16-1.fc5.i386 from fedora-extras-5-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 libwine_unicode.so.1 wine-core = 0:0.9.16-1.fc5 package: wine-esd - 0.9.16-1.fc5.i386 from fedora-extras-5-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc5 package: wine-jack - 0.9.16-1.fc5.i386 from fedora-extras-5-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 libwine_unicode.so.1 wine-core = 0:0.9.16-1.fc5 package: wine-devel - 0.9.16-1.fc5.i386 from fedora-extras-5-x86_64 unresolved deps: libwine_unicode.so.1(WINE_1.0) libwine_unicode.so.1 wine-core = 0:0.9.16-1.fc5 package: wine-tools - 0.9.16-1.fc5.i386 from fedora-extras-5-x86_64 unresolved deps: libwine.so.1(WINE_1.0) libwine.so.1 wine-core = 0:0.9.16-1.fc5 From nicolas.mailhot at laposte.net Mon Jul 3 11:47:30 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 3 Jul 2006 13:47:30 +0200 (CEST) Subject: New package version control In-Reply-To: <20060703111611.GA25241@neu.nirvana> References: <1151617881.3023.17.camel@localhost> <02182270-6372-41B3-A3FE-F9EC1BDC2BF8@redhat.com> <44A8AC28.9010600@forevermore.net> <1151907003.3038.9.camel@localhost> <20060703111611.GA25241@neu.nirvana> Message-ID: <45747.192.54.193.52.1151927250.squirrel@rousalka.dyndns.org> Hi, This page needs a ? on git, at least to explain why it's not being considered. With major projects like the kernel and xorg switching to git, not mentionning it at all seems very odd. Regards, -- Nicolas Mailhot From Christian.Iseli at licr.org Mon Jul 3 13:16:50 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 03 Jul 2006 15:16:50 +0200 Subject: Mass rebuild of Extras packages for FC6? (was: Re: Mass rebuild of core packages coming soon) In-Reply-To: Your message of "Sat, 01 Jul 2006 12:25:54 +0200." <44A64DB2.2080505@leemhuis.info> Message-ID: <200607031316.k63DGoHq014915@ludwig-alpha.unil.ch> fedora at leemhuis.info said: > BTW, does anyone have details on the technical background of "New toolset > feature to speed up dynamic lib linking by 50%~" ? Probably this: http://sourceware.org/ml/libc-alpha/2006-06/msg00095.html Cheers, Christian From jeff at ocjtech.us Mon Jul 3 13:16:58 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 03 Jul 2006 08:16:58 -0500 Subject: Fwd: [Fedora-infrastructure-list] New package version control In-Reply-To: <1151907003.3038.9.camel@localhost> References: <1151617881.3023.17.camel@localhost> <02182270-6372-41B3-A3FE-F9EC1BDC2BF8@redhat.com> <44A8AC28.9010600@forevermore.net> <1151907003.3038.9.camel@localhost> Message-ID: <1151932619.24495.3.camel@pc04331.campus.dmacc.edu> On Sun, 2006-07-02 at 23:10 -0700, Toshio Kuratomi wrote: > On Sun, 2006-07-02 at 22:33 -0700, Chris Petersen wrote: > > >> A few of us, warren, mmcgrath, and I are designing a new system of > > >> version control for the packages in Core and Extras. The main page of > > >> requirements and some pros and cons of various VCS's are listed on: > > >> http://www.fedoraproject.org/wiki/Infrastructure/VersionControl/ > > >> > > > > "con" for subversion is listed that auth must be through DAV, but a > > "pro" for mercurial is that it can do ssh. Just an fyi, but subversion > > works GREAT over ssh (via the svn+ssh:// uri), and projects like mythtv > > use this to separate anon checkout (http) with developer access (ssh). > > > > Granted, you're still limited to "full repository" access or no access > > with ssh since svn handles everything in its own database format. > > Yeah, that's pretty much a blocker for using svn+ssh. Why not use HTTPS and WebDAV for secure access to a SVN repository? SSL client certificates are already being generated/maintained for plague client access, why not use those certs for accessing the SVN repository? Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From enrico.scholz at informatik.tu-chemnitz.de Mon Jul 3 15:35:18 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 03 Jul 2006 17:35:18 +0200 Subject: Fwd: [Fedora-infrastructure-list] New package version control In-Reply-To: <44A8AC28.9010600@forevermore.net> (Chris Petersen's message of "Sun, 02 Jul 2006 22:33:28 -0700") References: <1151617881.3023.17.camel@localhost> <02182270-6372-41B3-A3FE-F9EC1BDC2BF8@redhat.com> <44A8AC28.9010600@forevermore.net> Message-ID: <873bdiu2fd.fsf@kosh.bigo.ensc.de> lists at forevermore.net (Chris Petersen) writes: > "con" for subversion is listed that auth must be through DAV, but a > "pro" for mercurial is that it can do ssh. I would see any non-HTTP(S) access as a 'con' because this will not work behind firewalls resp. requires big holes through them. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From orion at cora.nwra.com Mon Jul 3 17:07:12 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 03 Jul 2006 11:07:12 -0600 Subject: CVS server problems? Message-ID: <44A94EC0.5020706@cora.nwra.com> make new-source FILES=matplotlib-0.87.3.tar.gz Checking : matplotlib-0.87.3.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status make: *** [new-source] Error 255 -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From mmcgrath at fedoraproject.org Mon Jul 3 18:28:45 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 03 Jul 2006 13:28:45 -0500 Subject: CVS server problems? In-Reply-To: <44A94EC0.5020706@cora.nwra.com> References: <44A94EC0.5020706@cora.nwra.com> Message-ID: <44A961DD.4070004@fedoraproject.org> Orion Poplawski wrote: > make new-source FILES=matplotlib-0.87.3.tar.gz > > Checking : matplotlib-0.87.3.tar.gz on > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > ERROR: could not check remote file status > make: *** [new-source] Error 255 > > I'll look into this. -Mike From mmcgrath at fedoraproject.org Mon Jul 3 20:34:40 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 03 Jul 2006 15:34:40 -0500 Subject: CVS server problems? In-Reply-To: <44A961DD.4070004@fedoraproject.org> References: <44A94EC0.5020706@cora.nwra.com> <44A961DD.4070004@fedoraproject.org> Message-ID: <44A97F60.8080808@fedoraproject.org> Mike McGrath wrote: > Orion Poplawski wrote: >> make new-source FILES=matplotlib-0.87.3.tar.gz >> >> Checking : matplotlib-0.87.3.tar.gz on >> https://cvs.fedora.redhat.com/repo/extras/upload.cgi... >> ERROR: could not check remote file status >> make: *** [new-source] Error 255 >> >> > I'll look into this. > > -Mike > Has anyone on else on the list been unable to upload new sources? I haven't been able to reproduce this issue. -Mike From bugs.michael at gmx.net Mon Jul 3 20:51:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 3 Jul 2006 22:51:16 +0200 Subject: CVS server problems? In-Reply-To: <44A97F60.8080808@fedoraproject.org> References: <44A94EC0.5020706@cora.nwra.com> <44A961DD.4070004@fedoraproject.org> <44A97F60.8080808@fedoraproject.org> Message-ID: <20060703225116.90aa6796.bugs.michael@gmx.net> On Mon, 03 Jul 2006 15:34:40 -0500, Mike McGrath wrote: > Mike McGrath wrote: > > Orion Poplawski wrote: > >> make new-source FILES=matplotlib-0.87.3.tar.gz > >> > >> Checking : matplotlib-0.87.3.tar.gz on > >> https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > >> ERROR: could not check remote file status > >> make: *** [new-source] Error 255 > >> > >> > > I'll look into this. > > > > -Mike > > > Has anyone on else on the list been unable to upload new sources? I > haven't been able to reproduce this issue. Isn't it the same old ~/.fedora.cert "certificate expired" issue? Would be fixed by downloading a new cert from the account system web page. From orion at cora.nwra.com Mon Jul 3 21:07:16 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 03 Jul 2006 15:07:16 -0600 Subject: CVS server problems? In-Reply-To: <20060703225116.90aa6796.bugs.michael@gmx.net> References: <44A94EC0.5020706@cora.nwra.com> <44A961DD.4070004@fedoraproject.org> <44A97F60.8080808@fedoraproject.org> <20060703225116.90aa6796.bugs.michael@gmx.net> Message-ID: <44A98704.8020202@cora.nwra.com> Michael Schwendt wrote: > Isn't it the same old ~/.fedora.cert "certificate expired" issue? > Would be fixed by downloading a new cert from the account system > web page. > Probably. However, I'm trying to download a new cert but I keep getting an empty file. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Mon Jul 3 21:15:15 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 03 Jul 2006 15:15:15 -0600 Subject: CVS server problems? In-Reply-To: <44A98704.8020202@cora.nwra.com> References: <44A94EC0.5020706@cora.nwra.com> <44A961DD.4070004@fedoraproject.org> <44A97F60.8080808@fedoraproject.org> <20060703225116.90aa6796.bugs.michael@gmx.net> <44A98704.8020202@cora.nwra.com> Message-ID: <44A988E3.8070602@cora.nwra.com> Orion Poplawski wrote: > Michael Schwendt wrote: >> Isn't it the same old ~/.fedora.cert "certificate expired" issue? >> Would be fixed by downloading a new cert from the account system >> web page. >> > > Probably. However, I'm trying to download a new cert but I keep getting > an empty file. > Hmm, latest firefox on FC5 didn't like saving it. lynx handled it after I changed the named to fedora.cert (from .fedora.cert). -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From eric.tanguy at univ-nantes.fr Mon Jul 3 21:20:13 2006 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Mon, 03 Jul 2006 23:20:13 +0200 Subject: Problem building with mock Message-ID: <1151961613.12701.6.camel@bureau.maison> When i build a package locally using rpmbuild -bb foo.spec the package build fine when i try to build it using mock foo.src.rpm the building failed : lines building mock : make[2]: Entering directory `/builddir/build/BUILD/drgeo-1.1.0' /bin/sh ./mkinstalldirs /var/tmp/drgeo-1.1.0-8.fc5-root-mockbuild/usr/bin /bin/sh ./libtool --mode=install /usr/bin/install -c drgeo /var/tmp/drgeo-1.1.0-8.fc5-root-mockbuild/usr/bin/drgeo /usr/bin/install -c drgeo /var/tmp/drgeo-1.1.0-8.fc5-root-mockbuild/usr/bin/drgeo LC_ALL=C ./intltool-merge -d -u -c ./po/.intltool-merge-cache ./po drgeo.desktop.in drgeo.desktop /bin/sh ./mkinstalldirs /var/tmp/drgeo-1.1.0-8.fc5-root-mockbuild/usr/share/applications mkdir -p -- /var/tmp/drgeo-1.1.0-8.fc5-root-mockbuild/usr/share/applications /usr/bin/install -c -m 644 ./drgeo.desktop /var/tmp/drgeo-1.1.0-8.fc5-root-mockbuild/usr/share/applications/drgeo.desktop /usr/bin/install: cannot stat `./drgeo.desktop': No such file or directory same lines building locally : make[2]: Entering directory `/home/tanguy/rpmbuild/BUILD/drgeo-1.1.0' /bin/sh ./mkinstalldirs /var/tmp/drgeo-1.1.0-8-root-tanguy/usr/bin /bin/sh ./libtool --mode=install /usr/bin/install -c drgeo /var/tmp/drgeo-1.1.0-8-root-tanguy/usr/bin/drgeo /usr/bin/install -c drgeo /var/tmp/drgeo-1.1.0-8-root-tanguy/usr/bin/drgeo /bin/sh ./mkinstalldirs /var/tmp/drgeo-1.1.0-8-root-tanguy/usr/share/applications mkdir -p -- /var/tmp/drgeo-1.1.0-8-root-tanguy/usr/share/applications /usr/bin/install -c -m 644 drgeo.desktop /var/tmp/drgeo-1.1.0-8-root-tanguy/usr/share/applications/drgeo.desktop make[2]: Leaving directory `/home/tanguy/rpmbuild/BUILD/drgeo-1.1.0' I can't understand why there is a problem with mock. Someone could explain me ? Thanks Eric From lists at timj.co.uk Mon Jul 3 21:54:38 2006 From: lists at timj.co.uk (Tim Jackson) Date: Mon, 03 Jul 2006 22:54:38 +0100 Subject: Fwd: [Fedora-infrastructure-list] New package version control In-Reply-To: <44A8AC28.9010600@forevermore.net> References: <1151617881.3023.17.camel@localhost> <02182270-6372-41B3-A3FE-F9EC1BDC2BF8@redhat.com> <44A8AC28.9010600@forevermore.net> Message-ID: <44A9921E.3080200@timj.co.uk> Chris Petersen wrote: > "con" for subversion is listed that auth must be through DAV, but a > "pro" for mercurial is that it can do ssh. Just an fyi, but subversion > works GREAT over ssh (via the svn+ssh:// uri), and projects like mythtv > use this to separate anon checkout (http) with developer access (ssh). > > Granted, you're still limited to "full repository" access or no access > with ssh since svn handles everything in its own database format. Are we talking at cross-purposes or is the Subversion commit hook that can be used for path-based access control for svn+ssh being overlooked here? From /usr/share/doc/subversion-1.3.2/tools/hook-scripts which is an example config file for the supplied (example, but useful) Perl hook script: ----------------------------------------------------------------- [Make everything read-only for all users] match = .* access = read-only [Make project1 read-write for users Jane and Joe] match = ^(branches|tags|trunk)/project1 users = jane joe access = read-write [However, we don't trust Joe with project1's Makefile] match = ^(branches|tags|trunk)/project1/Makefile users = joe access = read-only ----------------------------------------------------------------- Tim From Matt_Domsch at dell.com Tue Jul 4 02:39:32 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 3 Jul 2006 21:39:32 -0500 Subject: Problem building with mock In-Reply-To: <1151961613.12701.6.camel@bureau.maison> References: <1151961613.12701.6.camel@bureau.maison> Message-ID: <20060704023932.GA14138@lists.us.dell.com> On Mon, Jul 03, 2006 at 11:20:13PM +0200, Eric Tanguy wrote: > When i build a package locally using rpmbuild -bb foo.spec the package > build fine when i try to build it using mock foo.src.rpm the building > failed : Missing BuildRequires: intltool perhaps? Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From dan at danny.cz Tue Jul 4 08:46:19 2006 From: dan at danny.cz (Hor=?ISO-8859-2?Q?=E1?=k) Date: Tue, 4 Jul 2006 10:46:19 +0200 Subject: Fwd: [Fedora-infrastructure-list] New package version control Message-ID: <200607041046.AA95355126@danny.cz> >Are we talking at cross-purposes or is the Subversion commit hook that >can be used for path-based access control for svn+ssh being overlooked here? > > From /usr/share/doc/subversion-1.3.2/tools/hook-scripts which is an >example config file for the supplied (example, but useful) Perl hook script: > >----------------------------------------------------------------- >[Make everything read-only for all users] >match = .* >access = read-only > >[Make project1 read-write for users Jane and Joe] >match = ^(branches|tags|trunk)/project1 >users = jane joe >access = read-write > >[However, we don't trust Joe with project1's Makefile] >match = ^(branches|tags|trunk)/project1/Makefile >users = joe >access = read-only >----------------------------------------------------------------- There is also a python hook called svnperms.py also with an example config file which yet more interesting, I think. Dan From mailinglists at erwinrol.com Tue Jul 4 12:16:15 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 04 Jul 2006 14:16:15 +0200 Subject: opengroupware for FE Message-ID: <1152015375.30969.315.camel@xpc.home.erwinrol.com> Hey all, we had a small discussion on OpenGroupware (OGo) on the Fedora Core developers list, and decided to move that discussion here :-) Axel already has most parts as fedora RPMS and probably could add the following parts to FE; gnustep-make, libobjc-lf2 and libFoundation. That leaves two parts, sope and opengroupware itself. The OGo project already has RPMS for several (if not all) platforms they just need some tuning to fit in the FE buildsystem. The question is how can we push this project forward? A good and supported groupware server would be a big plus for fedora (and actually for Red Hat too) especially when combined with the Fedora Directory Server. - Erwin From Axel.Thimm at ATrpms.net Tue Jul 4 12:34:56 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 4 Jul 2006 14:34:56 +0200 Subject: New package version control In-Reply-To: <44A9921E.3080200@timj.co.uk> References: <1151617881.3023.17.camel@localhost> <02182270-6372-41B3-A3FE-F9EC1BDC2BF8@redhat.com> <44A8AC28.9010600@forevermore.net> <44A9921E.3080200@timj.co.uk> Message-ID: <20060704123456.GA18364@neu.nirvana> On Mon, Jul 03, 2006 at 10:54:38PM +0100, Tim Jackson wrote: > Chris Petersen wrote: > > >"con" for subversion is listed that auth must be through DAV, but a > >"pro" for mercurial is that it can do ssh. Just an fyi, but subversion > >works GREAT over ssh (via the svn+ssh:// uri), and projects like mythtv > >use this to separate anon checkout (http) with developer access (ssh). > > > >Granted, you're still limited to "full repository" access or no access > >with ssh since svn handles everything in its own database format. > > Are we talking at cross-purposes or is the Subversion commit hook that > can be used for path-based access control for svn+ssh being overlooked here? That hook can only work in non-ssh setups. In this case we can use the power of apache's auth/acls. When you have ssh access it's full write access to everything unless you place yet another suid app involving svnserve on the server to control access control. I think in that case http(s) access has more benefits. The above is true for both svn and hg AFAIS. -- 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 mailinglists at erwinrol.com Tue Jul 4 12:38:17 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 04 Jul 2006 14:38:17 +0200 Subject: opengroupware for FE In-Reply-To: References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> Message-ID: <1152016697.30969.320.camel@xpc.home.erwinrol.com> On Tue, 2006-07-04 at 14:22 +0200, Helge Hess wrote: > On Jul 4, 2006, at 14:16, Erwin Rol wrote: > > Axel already has most parts as fedora RPMS and probably could add the > > following parts to FE; gnustep-make, libobjc-lf2 and libFoundation. > > FYI: I started to remove the libobjc-lf2 dependency. "removed dependency" as in libobjc-lf2 will not be needed anymore at all ? - Erwin From helge.hess at opengroupware.org Tue Jul 4 12:41:10 2006 From: helge.hess at opengroupware.org (Helge Hess) Date: Tue, 4 Jul 2006 14:41:10 +0200 Subject: opengroupware for FE In-Reply-To: <1152016697.30969.320.camel@xpc.home.erwinrol.com> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <1152016697.30969.320.camel@xpc.home.erwinrol.com> Message-ID: <3E9068DD-BB60-415E-A029-1760947E7D47@opengroupware.org> On Jul 4, 2006, at 14:38, Erwin Rol wrote: > "removed dependency" as in libobjc-lf2 will not be needed anymore at > all ? Correct. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From Axel.Thimm at ATrpms.net Tue Jul 4 12:43:45 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 4 Jul 2006 14:43:45 +0200 Subject: opengroupware for FE In-Reply-To: References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> Message-ID: <20060704124345.GB18364@neu.nirvana> On Tue, Jul 04, 2006 at 02:22:34PM +0200, Helge Hess wrote: > On Jul 4, 2006, at 14:16, Erwin Rol wrote: > >Axel already has most parts as fedora RPMS and probably could add the > >following parts to FE; gnustep-make, libobjc-lf2 and libFoundation. > > FYI: I started to remove the libobjc-lf2 dependency. Further OGo > trunk has fixes for plenty of 64bit issues and stupid gcc 4.1 > warnings (but the port is *not* yet complete). > Maybe we can release a 64bit ready SOPE 4.5.8 / OGo 1.1.5 at the end > of the week. That's great. I'll start to push the rest (not sope/ogo yet) to the repo. > BTW: gnustep-make is only a build time dependency for OGo (so the > gstep-make configured for lF / SOPE / OGo should be a -dev package). That's how it is done now already. gnustep-make, libFoundation are non-issues. libobjc-lf2 is a hack, but in this light still packaged decently, but getting rid of it would be a blessing. Wrt to sope one would need to check on the subpackaging. And finally ogo specfiles need all our love. > >The OGo project already has RPMS for several (if not all) platforms > >they just need some tuning to fit in the FE buildsystem. Note that the FE buildsystem (and also ATrpms' and all other used) is not imposing any special requirements. It just wants to be able to reproducably install a bunch of packages and have the package built. So the resulting packages are not tuned to a special buildsystem, but probably more away from one (I know Erwin didn't mean otherwise, just clarifying in order to avoid any misinterpretation). > PS: I think I'm not on the extra's list. We can keep you on Cc, but your mails to the list won't show up then (like the one I'm replying to right now). BTW I'm on fedora-extras and opengrouware lists, no need to Cc me explicitly unless you want my full attention :) -- 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 helge.hess at opengroupware.org Tue Jul 4 13:36:17 2006 From: helge.hess at opengroupware.org (Helge Hess) Date: Tue, 4 Jul 2006 15:36:17 +0200 Subject: opengroupware for FE In-Reply-To: <20060704124345.GB18364@neu.nirvana> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> Message-ID: On Jul 4, 2006, at 14:43, Axel Thimm wrote: >> FYI: I started to remove the libobjc-lf2 dependency. Further OGo >> trunk has fixes for plenty of 64bit issues and stupid gcc 4.1 >> warnings (but the port is *not* yet complete). >> Maybe we can release a 64bit ready SOPE 4.5.8 / OGo 1.1.5 at the end >> of the week. > That's great. I'll start to push the rest (not sope/ogo yet) to the > repo. Ahm, well, this is actually a dependency of libFoundation :-) So maybe you want to wait a bit longer. > That's how it is done now already. gnustep-make, libFoundation are > non-issues. libobjc-lf2 is a hack, but in this light still packaged > decently, but getting rid of it would be a blessing. > > Wrt to sope one would need to check on the subpackaging. And finally > ogo specfiles need all our love. Ack. > Note that the FE buildsystem (and also ATrpms' and all other used) is > not imposing any special requirements. It just wants to be able to > reproducably install a bunch of packages and have the package > built. So the resulting packages are not tuned to a special > buildsystem, but probably more away from one (I know Erwin didn't mean > otherwise, just clarifying in order to avoid any misinterpretation). Well, my conception was that the package name layout has to follow a certain style. >> PS: I think I'm not on the extra's list. I subscribed. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From dtimms at bigpond.net.au Tue Jul 4 13:46:15 2006 From: dtimms at bigpond.net.au (David Timms) Date: Tue, 04 Jul 2006 23:46:15 +1000 Subject: opengroupware for FE In-Reply-To: <20060704124345.GB18364@neu.nirvana> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> Message-ID: <44AA7127.7070609@bigpond.net.au> Axel Thimm wrote: > On Tue, Jul 04, 2006 at 02:22:34PM +0200, Helge Hess wrote: >> On Jul 4, 2006, at 14:16, Erwin Rol wrote: >>> Axel already has most parts as fedora RPMS and probably could add the >>> following parts to FE; gnustep-make, libobjc-lf2 and libFoundation. >> FYI: I started to remove the libobjc-lf2 dependency. Further OGo >> trunk has fixes for plenty of 64bit issues and stupid gcc 4.1 >> warnings (but the port is *not* yet complete). >> Maybe we can release a 64bit ready SOPE 4.5.8 / OGo 1.1.5 at the end >> of the week. > > That's great. I'll start to push the rest (not sope/ogo yet) to the > repo. > >> BTW: gnustep-make is only a build time dependency for OGo (so the >> gstep-make configured for lF / SOPE / OGo should be a -dev package). > > That's how it is done now already. gnustep-make, libFoundation are > non-issues. libobjc-lf2 is a hack, but in this light still packaged > decently, but getting rid of it would be a blessing. > > Wrt to sope one would need to check on the subpackaging. And finally > ogo specfiles need all our love. > >>> The OGo project already has RPMS for several (if not all) platforms >>> they just need some tuning to fit in the FE buildsystem. I while ago I setup a demo opengroupware server via make etc, after not being able to get [I forgot which] rpms to make a working server. On fc3 I think it was. It was difficult to get openldap integration going, never achieved it :( So, is this packaging already done, or could you use some help from a beginner packager (I am yet to complete my first package) ? Perhaps a small / easy part or review of such ? DaveT. From paul at city-fan.org Tue Jul 4 15:20:30 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 04 Jul 2006 16:20:30 +0100 Subject: rpms/monodoc/devel monodoc.spec,1.5,1.6 In-Reply-To: <200607041509.k64F9UVh029581@cvs-int.fedora.redhat.com> References: <200607041509.k64F9UVh029581@cvs-int.fedora.redhat.com> Message-ID: <44AA873E.20808@city-fan.org> Paul F. Johnson (pfj) wrote: > %build > -autoconf > -%configure --target=sparc86x > +%ifarch x86_64 ia64 > +%configure --libdir=/usr/lib64 > +%else > +%configure > +%endif What's the point of this construct? "rpm --eval '%configure'" on a 64-bit box should show --libdir=/usr/lib64 by default. Paul. From paul at all-the-johnsons.co.uk Tue Jul 4 15:57:52 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 04 Jul 2006 16:57:52 +0100 Subject: rpms/monodoc/devel monodoc.spec,1.5,1.6 In-Reply-To: <44AA873E.20808@city-fan.org> References: <200607041509.k64F9UVh029581@cvs-int.fedora.redhat.com> <44AA873E.20808@city-fan.org> Message-ID: <1152028672.3496.83.camel@T7.Linux> Hi, > What's the point of this construct? > > "rpm --eval '%configure'" on a 64-bit box should show > --libdir=/usr/lib64 by default. It's gone. I've been rebuilding on a new test rig and making things compliant with the new packaging regs. mono is lovely to use, just an utter bitch to package on anything other than x86 :-( Reason for delay : flu. TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 troels at arvin.dk Tue Jul 4 17:12:19 2006 From: troels at arvin.dk (Troels Arvin) Date: Tue, 04 Jul 2006 19:12:19 +0200 Subject: python-psycopg2 package spec Message-ID: Hello, At http://troels.arvin.dk/code/psycopg2/rpm/python-psycopg2.spec I've put a spec-file for a "python-psycopg2" package. The spec-file is modified from the spec-file in http://fedoraproject.org/extras/development/SRPMS/python-psycopg-1.1.21-4.fc5.src.rpm An rpm from the spec-file has been tested on my x86_64 installation and seems to work well. I considered adding a "Conflicts: python-psycopg", but it seems that there is no conflict in having both python-psycopg and python-psycopg2. -- Greetings from Troels Arvin From mmcgrath at fedoraproject.org Tue Jul 4 17:54:09 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 4 Jul 2006 12:54:09 -0500 Subject: PHP packaging guidelines not yet accepted In-Reply-To: <200606291631.06087.jkeating@redhat.com> References: <200606291631.06087.jkeating@redhat.com> Message-ID: <3237e4410607041054o4bbd6b3bg3902f34459153942@mail.gmail.com> > On Thursday 29 June 2006 14:28, Jason L Tibbitts III wrote: > > The packaging committee met for the first time today, in part to take > > up the issue of the PHP guidelines. The result was that the current > > draft was not accepted. are these guidelines supposed to outline how to package actual php apps as well? I'm thinking emphasizing that config files go in /etc/, apps should only be available to localhost by default, even though its a web app it must still follow FHS, etc? -Mike From tibbs at math.uh.edu Tue Jul 4 18:21:03 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 04 Jul 2006 13:21:03 -0500 Subject: PHP packaging guidelines not yet accepted In-Reply-To: <3237e4410607041054o4bbd6b3bg3902f34459153942@mail.gmail.com> (Mike McGrath's message of "Tue, 4 Jul 2006 12:54:09 -0500") References: <200606291631.06087.jkeating@redhat.com> <3237e4410607041054o4bbd6b3bg3902f34459153942@mail.gmail.com> Message-ID: >>>>> "MM" == Mike McGrath writes: MM> are these guidelines supposed to outline how to package actual php MM> apps as well? No, applications which happen to be written in PHP are not intended to be covered by these guidelines. There is a section at the end of the main guidelines (http://fedoraproject.org/wiki/Packaging/Guidelines) which covers web applications (written in PHP or otherwise): Web applications packaged in Fedora should put their content into /usr/share/%{name} and NOT into /var/www/. This is done because: * /var is supposed to contain variable data files and logs. /usr/share is much more appropriate for this. * Many users already have content in /var/www, and we do not want any Fedora package to step on top of that. * /var/www is no longer specified by the Filesystem Hierarchy Standard If you think something should be added, please feel free to send your proposal to the fedora-packaging list so that we can discuss it. - J< From sean.bruno at dsl-only.net Tue Jul 4 18:25:16 2006 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Tue, 04 Jul 2006 11:25:16 -0700 Subject: Azureus/gcj x86_64 Message-ID: <1152037516.27652.2.camel@home-desk> I have noted that Azureus with gcj under FC5 while downloading seems to stop dlding after about 2 or 3 minutes. With the sun java package I haven't had any issues. I was going to file a ticket, but I wanted to ask if anyone else using Azureus w/gcj is having issues downloading and if they are running x86_64 or i386 before I file a ticket. As I think this is more of an issue with gcj than an issue with Azureus. sean From buildsys at fedoraproject.org Tue Jul 4 19:23:52 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 4 Jul 2006 15:23:52 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-04 Message-ID: <20060704192352.5D44015217B@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 13 CastPodder-5.0-6.fc5 ejabberd-1.1.1-9.fc5 flasm-1.61-1.fc5 gcompris-7.4-12.fc5 gonvert-0.2.15-2.fc5 hercules-3.04.1-2.fc5 lat-1.0.6-2.fc5 perl-Calendar-Simple-1.13-3.fc5 proftpd-1.3.0-5.fc5 pyxmms-2.06-2.fc5 thttpd-2.25b-11.fc5 wordpress-2.0.3-3.fc5 wxGTK-2.6.3-2.6.3.2.2.fc5 Packages built and released for Fedora Extras 4: 7 ejabberd-1.1.1-9.fc4 flasm-1.61-1.fc4 perl-Calendar-Simple-1.13-3.fc4 thttpd-2.25b-11.fc4 wine-0.9.16-1.fc4 wordpress-2.0.3-4.fc4 wxGTK-2.6.3-2.6.3.2.2.fc4 Packages built and released for Fedora Extras 3: 2 dillo-0.8.6-2.fc3 wine-0.9.16-1.fc3 Packages built and released for Fedora Extras development: 24 dillo-0.8.6-2.fc6 ejabberd-1.1.1-9.fc6 flasm-1.61-1.fc6 gcompris-7.4-12.fc6 gonvert-0.2.15-2.fc6 gtk-gnutella-0.96.1-2.fc6 hercules-3.04.1-2.fc6 imlib-1.9.13-28.fc6 jack-audio-connection-kit-0.101.1-11.fc6 lat-1.0.6-2.fc6 libtranslate-0.99-8.fc6 perl-Contextual-Return-v0.1.0-1.fc6 perl-IO-Prompt-v0.99.4-1.fc6 perl-List-MoreUtils-0.22-1.fc6 perl-Math-Round-0.05-1.fc6 perl-Object-Accessor-0.20-1.fc6 proftpd-1.3.0-5.fc6 python-basemap-0.9-1.fc6 python-basemap-data-0.9-1.fc6 python-matplotlib-0.87.3-1.fc6 thttpd-2.25b-11.fc6 wordpress-2.0.3-3.fc6 wxGTK-2.6.3-2.6.3.2.2.fc6 xscreensaver-5.00-13.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From katzj at redhat.com Tue Jul 4 19:58:19 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Jul 2006 15:58:19 -0400 Subject: rpms/monodoc/devel monodoc.spec,1.5,1.6 In-Reply-To: <44AA873E.20808@city-fan.org> References: <200607041509.k64F9UVh029581@cvs-int.fedora.redhat.com> <44AA873E.20808@city-fan.org> Message-ID: <1152043099.20228.31.camel@aglarond.local> On Tue, 2006-07-04 at 16:20 +0100, Paul Howarth wrote: > Paul F. Johnson (pfj) wrote: > > %build > > -autoconf > > -%configure --target=sparc86x > > +%ifarch x86_64 ia64 > > +%configure --libdir=/usr/lib64 > > +%else > > +%configure > > +%endif > > What's the point of this construct? > > "rpm --eval '%configure'" on a 64-bit box should show > --libdir=/usr/lib64 by default. Also, it's especially wrong for ia64 -- %{_libdir} on ia64 is /usr/lib. Don't ask... Jeremy From buildsys at fedoraproject.org Tue Jul 4 19:42:49 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 04 Jul 2006 19:42:49 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-04 Message-ID: <20060704194249.8794.36121@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 wine-core - 0.9.16-1.fc3.i386 wine-core - 0.9.16-1.fc3.i386 steve AT silug.org amavisd-new - 2.3.3-5.fc3.noarch amavisd-new - 2.3.3-5.fc3.noarch Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- amavisd-new-2.3.3-5.fc3.noarch requires zoo fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg wine-core-0.9.16-1.fc3.i386 requires /usr/bin/xmessage Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- amavisd-new-2.3.3-5.fc3.noarch requires zoo fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg wine-core-0.9.16-1.fc3.i386 requires /usr/bin/xmessage ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: wine-core - 0.9.16-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: /usr/bin/xmessage package: wine-core - 0.9.16-1.fc3.i386 from fedora-extras-3-x86_64 unresolved deps: /usr/bin/xmessage ====================================================================== New report for: steve AT silug.org package: amavisd-new - 2.3.3-5.fc3.noarch from fedora-extras-3-i386 unresolved deps: zoo package: amavisd-new - 2.3.3-5.fc3.noarch from fedora-extras-3-x86_64 unresolved deps: zoo From buildsys at fedoraproject.org Tue Jul 4 19:42:49 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 04 Jul 2006 19:42:49 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-04 Message-ID: <20060704194249.8806.3147@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de wine-core - 0.9.16-1.fc4.i386 wine-core - 0.9.16-1.fc4.i386 ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc4.i386 maxima-runtime-sbcl - 5.9.3-4.fc4.ppc maxima-runtime-sbcl - 5.9.3-4.fc4.x86_64 steve AT silug.org amavisd-new - 2.4.0-1.fc4.noarch amavisd-new - 2.4.0-1.fc4.noarch amavisd-new - 2.4.0-1.fc4.noarch Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- amavisd-new-2.4.0-1.fc4.noarch requires zoo maxima-runtime-sbcl-5.9.3-4.fc4.i386 requires sbcl = 0:0.9.13 wine-core-0.9.16-1.fc4.i386 requires /usr/bin/xmessage wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- amavisd-new-2.4.0-1.fc4.noarch requires zoo maxima-runtime-sbcl-5.9.3-4.fc4.ppc requires sbcl = 0:0.9.13 wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- amavisd-new-2.4.0-1.fc4.noarch requires zoo maxima-runtime-sbcl-5.9.3-4.fc4.x86_64 requires sbcl = 0:0.9.13 wine-core-0.9.16-1.fc4.i386 requires /usr/bin/xmessage wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: wine-core - 0.9.16-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: /usr/bin/xmessage package: wine-core - 0.9.16-1.fc4.i386 from fedora-extras-4-x86_64 unresolved deps: /usr/bin/xmessage ====================================================================== New report for: steve AT silug.org package: amavisd-new - 2.4.0-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: zoo package: amavisd-new - 2.4.0-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: zoo package: amavisd-new - 2.4.0-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: zoo From buildsys at fedoraproject.org Tue Jul 4 19:42:49 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 04 Jul 2006 19:42:49 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-04 Message-ID: <20060704194249.8813.24779@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 steve AT silug.org perl-CPANPLUS - 0.072-1.fc6.noarch perl-CPANPLUS - 0.072-1.fc6.noarch perl-CPANPLUS - 0.072-1.fc6.noarch Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 perl-CPANPLUS-0.072-1.fc6.noarch requires perl(Package::Constants) sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 perl-CPANPLUS-0.072-1.fc6.noarch requires perl(Package::Constants) sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) perl-CPANPLUS-0.072-1.fc6.noarch requires perl(Package::Constants) sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From buildsys at fedoraproject.org Tue Jul 4 19:42:49 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 04 Jul 2006 19:42:49 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-04 Message-ID: <20060704194249.8810.92679@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc5.i386 maxima-runtime-sbcl - 5.9.3-4.fc5.ppc maxima-runtime-sbcl - 5.9.3-4.fc5.x86_64 steve AT silug.org amavisd-new - 2.4.0-1.fc5.noarch amavisd-new - 2.4.0-1.fc5.noarch amavisd-new - 2.4.0-1.fc5.noarch zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- amavisd-new-2.4.0-1.fc5.noarch requires zoo maxima-runtime-sbcl-5.9.3-4.fc5.i386 requires sbcl = 0:0.9.13 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- amavisd-new-2.4.0-1.fc5.noarch requires zoo maxima-runtime-sbcl-5.9.3-4.fc5.ppc requires sbcl = 0:0.9.13 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- amavisd-new-2.4.0-1.fc5.noarch requires zoo freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 maxima-runtime-sbcl-5.9.3-4.fc5.x86_64 requires sbcl = 0:0.9.13 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: steve AT silug.org package: amavisd-new - 2.4.0-1.fc5.noarch from fedora-extras-5-i386 unresolved deps: zoo package: amavisd-new - 2.4.0-1.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: zoo package: amavisd-new - 2.4.0-1.fc5.noarch from fedora-extras-5-ppc unresolved deps: zoo From nicolas.mailhot at laposte.net Tue Jul 4 20:17:03 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 04 Jul 2006 22:17:03 +0200 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-04 In-Reply-To: <20060704194249.8810.92679@extras64.linux.duke.edu> References: <20060704194249.8810.92679@extras64.linux.duke.edu> Message-ID: <1152044223.21876.23.camel@rousalka.dyndns.org> Hi Steve, Seems you missed FE5 in the remove zoo dep from amavis round Le mardi 04 juillet 2006 ? 19:42 +0000, Fedora Extras repoclosure a ?crit : > Summary of broken packages (by owner): > ---------------------------------------------------------------------- > steve AT silug.org > amavisd-new - 2.4.0-1.fc5.noarch > amavisd-new - 2.4.0-1.fc5.noarch > amavisd-new - 2.4.0-1.fc5.noarch > package: amavisd-new - 2.4.0-1.fc5.noarch from fedora-extras-5-i386 > unresolved deps: > zoo > > package: amavisd-new - 2.4.0-1.fc5.noarch from fedora-extras-5-x86_64 > unresolved deps: > zoo > > package: amavisd-new - 2.4.0-1.fc5.noarch from fedora-extras-5-ppc > unresolved deps: > zoo > -- 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 bugs.michael at gmx.net Tue Jul 4 21:55:31 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 4 Jul 2006 23:55:31 +0200 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-04 In-Reply-To: <1152044223.21876.23.camel@rousalka.dyndns.org> References: <20060704194249.8810.92679@extras64.linux.duke.edu> <1152044223.21876.23.camel@rousalka.dyndns.org> Message-ID: <20060704235531.1886b906.bugs.michael@gmx.net> On Tue, 04 Jul 2006 22:17:03 +0200, Nicolas Mailhot wrote: > Hi Steve, > > Seems you missed FE5 in the remove zoo dep from amavis round Note that wherever the report reads something like New report for: steve AT silug.org that is a copy of the private mail sent to the package owner. And unless the src.rpm id (NEVR) of the broken package changes, the mail is sent again every 14 days. From stickster at gmail.com Tue Jul 4 22:31:14 2006 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 04 Jul 2006 18:31:14 -0400 Subject: rpms/wordpress/FC-5 README.fedora.wordpress, NONE, 1.1 wordpress.spec, 1.1, 1.2 In-Reply-To: <200607040523.k645NNEG000534@cvs-int.fedora.redhat.com> References: <200607040523.k645NNEG000534@cvs-int.fedora.redhat.com> Message-ID: <1152052274.6169.18.camel@localhost.localdomain> On Mon, 2006-07-03 at 22:23 -0700, John Berninger wrote: > Author: jwb > > Update of /cvs/extras/rpms/wordpress/FC-5 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv508 [...snip...] > Index: wordpress.spec > =================================================================== > RCS file: /cvs/extras/rpms/wordpress/FC-5/wordpress.spec,v > retrieving revision 1.1 > retrieving revision 1.2 > diff -u -r1.1 -r1.2 > --- wordpress.spec 20 Jun 2006 15:10:54 -0000 1.1 > +++ wordpress.spec 4 Jul 2006 05:23:21 -0000 1.2 > @@ -3,15 +3,16 @@ > Name: wordpress > Version: 2.0.3 > Group: Applications/Publishing > -Release: 2%{?dist} > +Release: 3%{?dist} > License: GPL > # Source0 with name-version does not work for web retrieval, > # latest.tar.gz does not work for build > # Source0: http://wordpress.org/latest.tar.gz > Source0: http://wordpress.org/%{name}-%{version}.tar.gz > Source1: wordpress-httpd-conf > +Source2: README.fedora.wordpress > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > -Requires: php >= 4.1.0, httpd, mysql-server > +Requires: php >= 4.1.0, httpd, mysql-server, php-mysql > BuildArch: noarch Why does this package require mysql-server? I should be able to install this program on a box separate from the MySQL server without having to pull in the mysql-server package, right? Would a note in the README.fedora.wordpress be sufficient to establish the need for the package if you don't already have it installed somewhere? Just my $0.02, but I didn't want to file a bug if there was an obvious Good Thing about this particular Requires I was missing beyond "ease of use," nor if that particular factor is sufficient to overwhelm any opposition. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://www.fedoraproject.org/wiki/Board Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 helge.hess at opengroupware.org Tue Jul 4 23:04:05 2006 From: helge.hess at opengroupware.org (Helge Hess) Date: Wed, 5 Jul 2006 01:04:05 +0200 Subject: opengroupware for FE In-Reply-To: <20060704124345.GB18364@neu.nirvana> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> Message-ID: <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> On Jul 4, 2006, at 14:43, Axel Thimm wrote: > That's how it is done now already. gnustep-make, libFoundation are > non-issues. libobjc-lf2 is a hack, but in this light still packaged > decently, but getting rid of it would be a blessing. We have released libFoundation 1.1.0 which removes the hack and adds a preliminary x86_64 port (seems to work fine but is not well tested ...): http://svn.opengroupware.org/ThirdParty/releases/libFoundation-1.1.0/ We'll work on packaging it (including RPMs and tarballs) ASAP but maybe you want to look into this as well for your Fedora package. best regards, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From dtimms at bigpond.net.au Tue Jul 4 23:13:00 2006 From: dtimms at bigpond.net.au (David Timms) Date: Wed, 05 Jul 2006 09:13:00 +1000 Subject: Azureus/gcj x86_64 In-Reply-To: <1152037516.27652.2.camel@home-desk> References: <1152037516.27652.2.camel@home-desk> Message-ID: <44AAF5FC.3090900@bigpond.net.au> Sean Bruno wrote: > I have noted that Azureus with gcj under FC5 while downloading seems to > stop dlding after about 2 or 3 minutes. > > With the sun java package I haven't had any issues. > > I was going to file a ticket, but I wanted to ask if anyone else using > Azureus w/gcj is having issues downloading and if they are running > x86_64 or i386 before I file a ticket. As I think this is more of an > issue with gcj than an issue with Azureus. On FC5, I couldn't get either limewire or azureus to run with gcj. Went with the sun rpm.bins and both works fine. You obviously got further than I did. DaveT. From sean.bruno at dsl-only.net Tue Jul 4 23:49:28 2006 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Tue, 04 Jul 2006 16:49:28 -0700 Subject: Azureus/gcj x86_64 In-Reply-To: <44AAF5FC.3090900@bigpond.net.au> References: <1152037516.27652.2.camel@home-desk> <44AAF5FC.3090900@bigpond.net.au> Message-ID: <1152056968.27652.5.camel@home-desk> On Wed, 2006-07-05 at 09:13 +1000, David Timms wrote: > Sean Bruno wrote: > > I have noted that Azureus with gcj under FC5 while downloading seems to > > stop dlding after about 2 or 3 minutes. > > > > With the sun java package I haven't had any issues. > > > > I was going to file a ticket, but I wanted to ask if anyone else using > > Azureus w/gcj is having issues downloading and if they are running > > x86_64 or i386 before I file a ticket. As I think this is more of an > > issue with gcj than an issue with Azureus. > On FC5, I couldn't get either limewire or azureus to run with gcj. Went > with the sun rpm.bins and both works fine. You obviously got further > than I did. > > DaveT. > Are you running the i386 or x86_64 distro of FC5? Sean From steve at silug.org Wed Jul 5 00:42:01 2006 From: steve at silug.org (Steven Pritchard) Date: Tue, 4 Jul 2006 19:42:01 -0500 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-04 In-Reply-To: <1152044223.21876.23.camel@rousalka.dyndns.org> References: <20060704194249.8810.92679@extras64.linux.duke.edu> <1152044223.21876.23.camel@rousalka.dyndns.org> Message-ID: <20060705004201.GA18802@osiris.silug.org> On Tue, Jul 04, 2006 at 10:17:03PM +0200, Nicolas Mailhot wrote: > Seems you missed FE5 in the remove zoo dep from amavis round I haven't had a chance to test amavisd-new 2.4.1 yet, so I haven't built it for anything other than rawhide so far. I'll work on it tomorrow. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From icon at fedoraproject.org Wed Jul 5 02:36:04 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 4 Jul 2006 22:36:04 -0400 Subject: Move Squirrelmail to Extras? Message-ID: Would it make sense to move Squirrelmail to Extras? I am the upstream package maintainer, and would happily maintain it here instead of having to do it on squirrelmail.org. Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From jima at beer.tclug.org Wed Jul 5 04:26:00 2006 From: jima at beer.tclug.org (Jima) Date: Tue, 4 Jul 2006 23:26:00 -0500 (CDT) Subject: Move Squirrelmail to Extras? In-Reply-To: References: Message-ID: On Tue, 4 Jul 2006, Konstantin Ryabitsev wrote: > Would it make sense to move Squirrelmail to Extras? I am the upstream > package maintainer, and would happily maintain it here instead of > having to do it on squirrelmail.org. I don't see any reason why not. It'd be rather unusual to find a case where one needs Squirrelmail but lacks the Internet connection to install it from an Extras mirror. ;) Jima (a happy Squirrelmail admin/part-time user) From green at redhat.com Wed Jul 5 05:43:59 2006 From: green at redhat.com (Anthony Green) Date: Tue, 04 Jul 2006 22:43:59 -0700 Subject: Azureus/gcj x86_64 In-Reply-To: <44AAF5FC.3090900@bigpond.net.au> References: <1152037516.27652.2.camel@home-desk> <44AAF5FC.3090900@bigpond.net.au> Message-ID: <1152078239.2880.49.camel@localhost.localdomain> On Wed, 2006-07-05 at 09:13 +1000, David Timms wrote: > On FC5, I couldn't get either limewire or azureus to run with gcj. Went > with the sun rpm.bins and both works fine. You obviously got further > than I did. Are you actually running the azureus from Fedora Extras? What does "rpm -qf /usr/bin/azureus" say? Older unpackaged versions of azureus didn't run on gcj because they used proprietary Sun extensions to the java platform. I fixed all this in the FE version and got my changes accepted upstream. Very new versions should run, but I recommend running the FE packaged release. AG From green at redhat.com Wed Jul 5 05:49:45 2006 From: green at redhat.com (Anthony Green) Date: Tue, 04 Jul 2006 22:49:45 -0700 Subject: Azureus/gcj x86_64 In-Reply-To: <1152037516.27652.2.camel@home-desk> References: <1152037516.27652.2.camel@home-desk> Message-ID: <1152078586.2880.54.camel@localhost.localdomain> On Tue, 2006-07-04 at 11:25 -0700, Sean Bruno wrote: > I have noted that Azureus with gcj under FC5 while downloading seems to > stop dlding after about 2 or 3 minutes. It probably would start up again if you leave it. I see this now and then. There's a bug in libgcj's NIO socket code that impacts performance. I think somebody is working on a fix that hopefully will be in FC6. > With the sun java package I haven't had any issues. That's the one nice thing about our "alternatives" system. You're not locked into any specific implementation. > I was going to file a ticket, but I wanted to ask if anyone else using > Azureus w/gcj is having issues downloading and if they are running > x86_64 or i386 before I file a ticket. As I think this is more of an > issue with gcj than an issue with Azureus. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187103 AG From nicolas.mailhot at laposte.net Wed Jul 5 06:04:47 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 05 Jul 2006 08:04:47 +0200 Subject: DejaVu fonts for Fedora Core 6 feedback call Message-ID: <1152079490.23468.0.camel@rousalka.dyndns.org> Dear Fedora user, A new font family is being proposed as the Fedora Core default. It probably impacts your language. Please tell us what you think about it: http://fedoraproject.org/wiki/Fonts/DejavuFeedbackCall Happy testing! -- Nicolas Mailhot Fedora Extras DejaVu maintainer -------------- 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 dragoran at feuerpokemon.de Wed Jul 5 06:29:06 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 05 Jul 2006 08:29:06 +0200 Subject: Azureus/gcj x86_64 In-Reply-To: <44AAF5FC.3090900@bigpond.net.au> References: <1152037516.27652.2.camel@home-desk> <44AAF5FC.3090900@bigpond.net.au> Message-ID: <44AB5C32.3010105@feuerpokemon.de> David Timms wrote: > Sean Bruno wrote: >> I have noted that Azureus with gcj under FC5 while downloading seems to >> stop dlding after about 2 or 3 minutes. >> >> With the sun java package I haven't had any issues. >> >> I was going to file a ticket, but I wanted to ask if anyone else using >> Azureus w/gcj is having issues downloading and if they are running >> x86_64 or i386 before I file a ticket. As I think this is more of an >> issue with gcj than an issue with Azureus. > On FC5, I couldn't get either limewire or azureus to run with gcj. > Went with the sun rpm.bins and both works fine. You obviously got > further than I did. > > DaveT. > a gcj compiled azureus is in extras From dragoran at feuerpokemon.de Wed Jul 5 06:37:33 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 05 Jul 2006 08:37:33 +0200 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <1152079490.23468.0.camel@rousalka.dyndns.org> References: <1152079490.23468.0.camel@rousalka.dyndns.org> Message-ID: <44AB5E2D.8060707@feuerpokemon.de> Nicolas Mailhot wrote: > Dear Fedora user, > > A new font family is being proposed as the Fedora Core default. It > probably impacts your language. Please tell us what you think about it: > > http://fedoraproject.org/wiki/Fonts/DejavuFeedbackCall > > Happy testing! > > I tryed it but for me the default font used in apps (FC5) looks better and is easier to read... the new fonts look to 'thin' and are harder to read because of this .. notes: 1) I am using a TFT with a german locale + no subpixel AA, but greyscale AA 2) I have recompiled the freetypelib with the bytecode interpretter enabled From seg at haxxed.com Wed Jul 5 06:57:39 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 05 Jul 2006 01:57:39 -0500 Subject: Azureus/gcj x86_64 In-Reply-To: <1152037516.27652.2.camel@home-desk> References: <1152037516.27652.2.camel@home-desk> Message-ID: <1152082660.3792.12.camel@localhost> On Tue, 2006-07-04 at 11:25 -0700, Sean Bruno wrote: > I have noted that Azureus with gcj under FC5 while downloading seems to > stop dlding after about 2 or 3 minutes. > > With the sun java package I haven't had any issues. > > I was going to file a ticket, but I wanted to ask if anyone else using > Azureus w/gcj is having issues downloading and if they are running > x86_64 or i386 before I file a ticket. As I think this is more of an > issue with gcj than an issue with Azureus. The Azureus that's IN extras works fine for me these days. Other than having a bizzare tendency to crash the dnsmasq on my wireless router... I run it on both i386 and x86_64. -------------- 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 at knox.net.nz Wed Jul 5 07:27:09 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 05 Jul 2006 19:27:09 +1200 Subject: next FESCo meeting agenda. Message-ID: <44AB69CD.8000607@knox.net.nz> Can this proposed policy be discussed in the next FESCo meeting? http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy There has been no (apparent) opposition to the policy. The meetings happen at 5am (my time) and while I will make an attempt to be present to push this myself, it would be cool if it could be on the agenda even if I am not present. Thanks! Michael From paul at all-the-johnsons.co.uk Wed Jul 5 07:40:18 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 05 Jul 2006 08:40:18 +0100 Subject: next FESCo meeting agenda. In-Reply-To: <44AB69CD.8000607@knox.net.nz> References: <44AB69CD.8000607@knox.net.nz> Message-ID: <1152085219.3496.117.camel@T7.Linux> On Wed, 2006-07-05 at 19:27 +1200, Michael J. Knox wrote: > Can this proposed policy be discussed in the next FESCo meeting? > > http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy > > There has been no (apparent) opposition to the policy. The only thing that looks slightly amiss is this "- If you are a not an existing Extras contributor, you can still take over a package. All of the above must be followed. When you seek approval for the take over, you, again, must provide a bugzilla report as if it were a new Extras package review. This will allow the normal review process to happen. Being how the package is in Extras already, this process should be swift." If you are not a contributor, you won't have CVS access and so will need to go through the sign up, get a sponsor etc procedure. I personally would not like to see that circumvented as it adds in that extra layer of security. I could have misread the above para, but I'm not sure I have. The rest of it looks good :-) TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 chris.stone at gmail.com Wed Jul 5 08:12:37 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 01:12:37 -0700 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <44AB5E2D.8060707@feuerpokemon.de> References: <1152079490.23468.0.camel@rousalka.dyndns.org> <44AB5E2D.8060707@feuerpokemon.de> Message-ID: For some strange reason ? (⇩) is showing up as an up arrow in firefox, works in konqueror though and pasting the character in the gmail email works too, very strange. From pertusus at free.fr Wed Jul 5 08:32:36 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 5 Jul 2006 10:32:36 +0200 Subject: next FESCo meeting agenda. In-Reply-To: <44AB69CD.8000607@knox.net.nz> References: <44AB69CD.8000607@knox.net.nz> Message-ID: <20060705083236.GA2487@free.fr> On Wed, Jul 05, 2006 at 07:27:09PM +1200, Michael J. Knox wrote: > Can this proposed policy be discussed in the next FESCo meeting? > > http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy I think that only existing Fedora Contributors should be able to take over a package. However the sponsors should consider every contribution to fedora extras, including working on AWOL packages for sponsorship. I also think that a maintainer should not be considered AWOL when he has shown some activity in a package or other packages even if he doesn't respond to some bugs in a particular package. If he is still active in other parts of fedora extras, maybe it could be the sponsor responsibility to try to come to an agreement. I also think that "a maintainer isn't answering their bugs, not answering rebuild requests, emails or the like" opens a bit too much for interpretation. In my opinion it should be only serious issues that allows AWOL procedure. Like security bug, big usability bug, broken dependency, or a need to rebuild against newer library version. I don't think it would be right to allow people to bug maintainers for minor/wrong issues and then start the AWOL procedure. -- Pat From michael at knox.net.nz Wed Jul 5 08:38:11 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 05 Jul 2006 20:38:11 +1200 Subject: next FESCo meeting agenda. In-Reply-To: <20060705083236.GA2487@free.fr> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> Message-ID: <44AB7A73.5070201@knox.net.nz> Patrice Dumas wrote: > On Wed, Jul 05, 2006 at 07:27:09PM +1200, Michael J. Knox wrote: >> Can this proposed policy be discussed in the next FESCo meeting? >> >> http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy > > I think that only existing Fedora Contributors should be able to take over > a package. However the sponsors should consider every contribution to > fedora extras, including working on AWOL packages for sponsorship. This was suggested in the earlier discussions, but the consensus at the time was to allow non FE contributors to take on AWOL packages. > I also think that a maintainer should not be considered AWOL when he has > shown some activity in a package or other packages even if he doesn't > respond to some bugs in a particular package. If he is still active in > other parts of fedora extras, maybe it could be the sponsor responsibility > to try to come to an agreement. > > I also think that "a maintainer isn't answering their bugs, not answering > rebuild requests, emails or the like" opens a bit too much for interpretation. > In my opinion it should be only serious issues that allows AWOL procedure. > Like security bug, big usability bug, broken dependency, or a need to rebuild > against newer library version. I don't think it would be right to allow > people to bug maintainers for minor/wrong issues and then start the AWOL > procedure. This is why its required to post to fedora-extras@ and a FESCo member give approval. Thanks! Michael From michael at knox.net.nz Wed Jul 5 08:39:47 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 05 Jul 2006 20:39:47 +1200 Subject: next FESCo meeting agenda. In-Reply-To: <1152085219.3496.117.camel@T7.Linux> References: <44AB69CD.8000607@knox.net.nz> <1152085219.3496.117.camel@T7.Linux> Message-ID: <44AB7AD3.4020708@knox.net.nz> Paul wrote: > On Wed, 2006-07-05 at 19:27 +1200, Michael J. Knox wrote: >> Can this proposed policy be discussed in the next FESCo meeting? >> >> http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy >> >> There has been no (apparent) opposition to the policy. > > The only thing that looks slightly amiss is this > > "- If you are a not an existing Extras contributor, you can still take > over a package. All of the above must be followed. When you seek > approval for the take over, you, again, must provide a bugzilla report > as if it were a new Extras package review. This will allow the normal > review process to happen. Being how the package is in Extras already, > this process should be swift." > > If you are not a contributor, you won't have CVS access and so will need > to go through the sign up, get a sponsor etc procedure. I personally > would not like to see that circumvented as it adds in that extra layer > of security. > Though you can get the srpms with out CVS access. You can also get the CVS HEAD version from anon CVS checkout. Then the normal review process starts. Thanks! Michael From paul at all-the-johnsons.co.uk Wed Jul 5 08:49:01 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 05 Jul 2006 09:49:01 +0100 Subject: next FESCo meeting agenda. In-Reply-To: <20060705083236.GA2487@free.fr> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> Message-ID: <1152089341.3496.126.camel@T7.Linux> Hi, > I also think that "a maintainer isn't answering their bugs, not answering > rebuild requests, emails or the like" opens a bit too much for interpretation. It also has a problem. I've been out of things for about 10 days, which means that I have an anjuta bug which is over 2 weeks old. I'm also waiting on an upstream response for a bug problem, so it's slow going. The bug is still being worked on, but hasn't been fixed. You also have the problem of folks being on holiday. It's not unusual in the UK for people to vanish for 2 - 3 weeks. Some bugs are also much bigger than first thought. z88dk on 64 bit being one such example. It is still being worked on, but the problem is that the code generated isn't happy fully, so it's not in a state that I would want to see released. > In my opinion it should be only serious issues that allows AWOL procedure. > Like security bug, big usability bug, broken dependency, or a need to rebuild > against newer library version. I don't think it would be right to allow > people to bug maintainers for minor/wrong issues and then start the AWOL > procedure. The AWOL problem is not a trivial one. A while back, I posted something similar to Mike's proposal to the f-extras list - the main problem identified was that it is hard to fix time limits on things (though the thread may have been on orphaned packages). As I say, other than the third para (the one about not current contributors), I think Mike's suggestions are good ones. TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 nicolas.mailhot at laposte.net Wed Jul 5 09:06:00 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 5 Jul 2006 11:06:00 +0200 (CEST) Subject: next FESCo meeting agenda. In-Reply-To: <44AB7A73.5070201@knox.net.nz> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <44AB7A73.5070201@knox.net.nz> Message-ID: <30486.192.54.193.53.1152090360.squirrel@rousalka.dyndns.org> Le Mer 5 juillet 2006 10:38, Michael J. Knox a ?crit : > I don't think it would be right to allow > people to bug maintainers for minor/wrong issues and then start the AWOL > procedure. There is a very simple rule which could be used : if a problem is reported before FCnT1 and not fixed by FCn time, the FE package should be considered orphaned regardless of what the maintainer does for other packages. Would probably be best if we created FEnTarget trackers to follow such cases - only allow people to block FEnTarget before FCnT1, review the bugs at FCn release time Regards, -- Nicolas Mailhot From fedora at leemhuis.info Wed Jul 5 09:08:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Jul 2006 11:08:32 +0200 Subject: next FESCo meeting agenda. In-Reply-To: <44AB69CD.8000607@knox.net.nz> References: <44AB69CD.8000607@knox.net.nz> Message-ID: <44AB8190.1080900@leemhuis.info> Michael J. Knox schrieb: > Can this proposed policy be discussed in the next FESCo meeting? > > http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy > > There has been no (apparent) opposition to the policy. > > The meetings happen at 5am (my time) and while I will make an attempt to > be present to push this myself, it would be cool if it could be on the > agenda even if I am not present. I added it to the schedule -- but this thursday is the first meeting after the FESCo election (*1) and I'm not sure if we have enough time to go through the regular schedule in the meeting so it might have to wait another week. CU thl *1 -- no, I don't have results yet -- hopefully today someone (Sopwith?) from the sysadmin group can provide the results. From pertusus at free.fr Wed Jul 5 09:13:22 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 5 Jul 2006 11:13:22 +0200 Subject: next FESCo meeting agenda. In-Reply-To: <44AB7A73.5070201@knox.net.nz> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <44AB7A73.5070201@knox.net.nz> Message-ID: <20060705091321.GB2487@free.fr> > >I also think that a maintainer should not be considered AWOL when he has > >shown some activity in a package or other packages even if he doesn't > >respond to some bugs in a particular package. If he is still active in > >other parts of fedora extras, maybe it could be the sponsor responsibility > >to try to come to an agreement. No comment on that part? > This is why its required to post to fedora-extras@ and a FESCo member > give approval. Indeed, but I think that it should also be stated in the proposal. I propose something along (for the first point in Outline): When Fedora Extras member sees that a maintainer isn't answering serious bugs, in particular when there is a fix provided, and for the bugs related to security, major usability issues (crashs), request for rebuild against newer libs, and that the maintainer is not answering rebuild requests, emails or the like, they need to file a bug against the package in bugzilla asking for the maintainer to respond. -- Pat From paul at city-fan.org Wed Jul 5 09:26:30 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 05 Jul 2006 10:26:30 +0100 Subject: next FESCo meeting agenda. In-Reply-To: <1152085219.3496.117.camel@T7.Linux> References: <44AB69CD.8000607@knox.net.nz> <1152085219.3496.117.camel@T7.Linux> Message-ID: <44AB85C6.6080301@city-fan.org> Paul wrote: > On Wed, 2006-07-05 at 19:27 +1200, Michael J. Knox wrote: >> Can this proposed policy be discussed in the next FESCo meeting? >> >> http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy >> >> There has been no (apparent) opposition to the policy. > > The only thing that looks slightly amiss is this > > "- If you are a not an existing Extras contributor, you can still take > over a package. All of the above must be followed. When you seek > approval for the take over, you, again, must provide a bugzilla report > as if it were a new Extras package review. This will allow the normal > review process to happen. Being how the package is in Extras already, > this process should be swift." > > If you are not a contributor, you won't have CVS access and so will need > to go through the sign up, get a sponsor etc procedure. I personally > would not like to see that circumvented as it adds in that extra layer > of security. > > I could have misread the above para, but I'm not sure I have. I don't think anyone is suggesting that the sponsorship process should be circumvented. However, whilst the review process for an existing package should be quick, the sponsorship process is unlikely to be. Taking over an existing package doesn't do much to demonstrate a new contributor's ability as a packager or their understanding of the Extras processes and guidelines. In other words, they may struggle to find a sponsor without going down the regular contributor route. Paul. From Axel.Thimm at ATrpms.net Wed Jul 5 09:36:42 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 5 Jul 2006 11:36:42 +0200 Subject: RFE: Review Request:
- Message-ID: <20060705093642.GE1419@neu.nirvana> Hi, currently the new package creation process in bugzilla: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&format=extras-review suggests using "Review Request:
" in bugzilla's summary. It would make the sent mails and bugzilla browsing much more interesting if the package's purpose could already be read off this one-liner. Currently I see some submitted packages and unless I already know the project I can't associate anything with it. Some submitters are already adding the package's summary to bugzilla's, but if the URL above would change the template to suggest always doing so, that would be perfect, 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 bugs.michael at gmx.net Wed Jul 5 09:51:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 5 Jul 2006 11:51:16 +0200 Subject: next FESCo meeting agenda. In-Reply-To: <20060705083236.GA2487@free.fr> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> Message-ID: <20060705115116.83628f34.bugs.michael@gmx.net> On Wed, 5 Jul 2006 10:32:36 +0200, Patrice Dumas wrote: > On Wed, Jul 05, 2006 at 07:27:09PM +1200, Michael J. Knox wrote: > > Can this proposed policy be discussed in the next FESCo meeting? > > > > http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy > > I think that only existing Fedora Contributors should be able to take over > a package. However the sponsors should consider every contribution to > fedora extras, including working on AWOL packages for sponsorship. This is contradictory. With the current sponsorship process, all that is needed to find a sponsor is to show a good understanding of the packaging [guidelines]. Yes, it may be too easy for somebody to take an existing src.rpm (CVS checkout), bump the version or release, present it as an update package for review and be sponsored. But if it were not possible, the same person could request review of a trivial new package, find a sponsor that way, and then proceed to taking over orphans. Conclusively, it's a sponsor's decision whether to accept a new contributor and regardless of what he wants to work on. It could also be that somebody writes "All the packages I'm interested in are in FE already. But if it is possible that we can work together on foo and bar, I'd like to offer my help." and a sponsor and package maintainer accepts this without extra steps or special requirements. The general procedure for becoming a Fedora Extras Contributor, however, is to provide a new package in accordance with the instructions found in the Wiki. > I also think that a maintainer should not be considered AWOL when he has > shown some activity in a package or other packages even if he doesn't > respond to some bugs in a particular package. If he is still active in > other parts of fedora extras, maybe it could be the sponsor responsibility > to try to come to an agreement. This is troublesome. It would need a specific example to explain why a maintainer _is active_ but doesn't respond to an issue with one of his packages which causes other people to demand action. And, of course, if a contributor is still active and seems to ignore a PR deliberately, there are ways to escalate that in case it is believed that the issue is serious enough. It's certainly possible to contact FESCO. Just do it and don't create overly complex policy documents. > I also think that "a maintainer isn't answering their bugs, not answering > rebuild requests, emails or the like" opens a bit too much for interpretation. No. There's no room for interpretations. There must be a bugzilla ticket, where all attempts at contacting the packager must be mentioned and tracked, and which explains what the issue with the package is. > In my opinion it should be only serious issues that allows AWOL procedure. > Like security bug, big usability bug, broken dependency, or a need to rebuild > against newer library version. I don't think it would be right to allow > people to bug maintainers for minor/wrong issues and then start the AWOL > procedure. It's called "common sense". But it is not easy to define. What may be a minor defect in your point of view, could be considered a serious defect by other users or packagers. So, assuming that the AWOL procedure is not started too often, it would be extremely impolite of a Fedora Extras Contributor to refuse to comment in bugzilla. Especially when a fellow contributor joins the AWOL procedure in agreement that the reported issue is serious. From paul at all-the-johnsons.co.uk Wed Jul 5 10:12:19 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 05 Jul 2006 11:12:19 +0100 Subject: next FESCo meeting agenda. In-Reply-To: <44AB85C6.6080301@city-fan.org> References: <44AB69CD.8000607@knox.net.nz> <1152085219.3496.117.camel@T7.Linux> <44AB85C6.6080301@city-fan.org> Message-ID: <1152094339.3496.139.camel@T7.Linux> Hi, > In other words, they may struggle to find a > sponsor without going down the regular contributor route. Won't that mean that things become even slower then? Seems a tad daft if that is the case to make a slower process even slower! TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 Wed Jul 5 10:23:30 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 5 Jul 2006 12:23:30 +0200 Subject: opengroupware for FE In-Reply-To: <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> Message-ID: <20060705102330.GF1419@neu.nirvana> On Wed, Jul 05, 2006 at 01:04:05AM +0200, Helge Hess wrote: > On Jul 4, 2006, at 14:43, Axel Thimm wrote: > >That's how it is done now already. gnustep-make, libFoundation are > >non-issues. libobjc-lf2 is a hack, but in this light still packaged > >decently, but getting rid of it would be a blessing. > > We have released libFoundation 1.1.0 which removes the hack So gnustep-make can safely use -lobjc instead of -lobjc-lf2 as a default? > and adds a preliminary x86_64 port (seems to work fine but is not > well tested ...): > > http://svn.opengroupware.org/ThirdParty/releases/libFoundation-1.1.0/ > > We'll work on packaging it (including RPMs and tarballs) ASAP but > maybe you want to look into this as well for your Fedora package. I'd prefer using a released tarball otherwise it will make the review process much harder (the reviewer is supposed to check the sources). Even if it sounds silly, can you please just officially upload the tarball to a permanent URL? 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 nicolas.mailhot at laposte.net Wed Jul 5 08:43:13 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 5 Jul 2006 10:43:13 +0200 (CEST) Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: References: <1152079490.23468.0.camel@rousalka.dyndns.org> <44AB5E2D.8060707@feuerpokemon.de> Message-ID: <8460.192.54.193.53.1152088993.squirrel@rousalka.dyndns.org> Thank your for the testing. Problem reported as https://bugs.freedesktop.org/show_bug.cgi?id=7426 Regards, -- Nicolas Mailhot From pertusus at free.fr Wed Jul 5 10:34:05 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 5 Jul 2006 12:34:05 +0200 Subject: next FESCo meeting agenda. In-Reply-To: <1152094339.3496.139.camel@T7.Linux> References: <44AB69CD.8000607@knox.net.nz> <1152085219.3496.117.camel@T7.Linux> <44AB85C6.6080301@city-fan.org> <1152094339.3496.139.camel@T7.Linux> Message-ID: <20060705103405.GA4619@free.fr> On Wed, Jul 05, 2006 at 11:12:19AM +0100, Paul wrote: > > In other words, they may struggle to find a > > sponsor without going down the regular contributor route. > > Won't that mean that things become even slower then? Seems a tad daft if > that is the case to make a slower process even slower! Having a packager AWOL shouldn't be a reason to relax the rule for sponsorship. Becoming a contributor should always be conditional on showing knowledge and acceptance of fedora extras rules and guidelines. -- Pat From pertusus at free.fr Wed Jul 5 10:45:56 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 5 Jul 2006 12:45:56 +0200 Subject: next FESCo meeting agenda. In-Reply-To: <20060705115116.83628f34.bugs.michael@gmx.net> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <20060705115116.83628f34.bugs.michael@gmx.net> Message-ID: <20060705104556.GB4619@free.fr> > Conclusively, it's a sponsor's decision whether to accept a new contributor > and regardless of what he wants to work on. I completely agree on that. What I am saying is that one should be sponsored in order to take over a package. > > I also think that a maintainer should not be considered AWOL when he has > > shown some activity in a package or other packages even if he doesn't > > respond to some bugs in a particular package. If he is still active in > > other parts of fedora extras, maybe it could be the sponsor responsibility > > to try to come to an agreement. > > This is troublesome. It would need a specific example to explain why a maintainer > _is active_ but doesn't respond to an issue with one of his packages which causes > other people to demand action. Imagine that a maintainer is active on package foo but doesn't respond on issues about pakage bar. It is not clear, in the AWOL policy whether the AWOL procedure should be started or not. I believe it shouldn't, but instead his sponsor may be contacted, and the issue sorted out with his help, or escalated to FESCO as you say below. > > against newer library version. I don't think it would be right to allow > > people to bug maintainers for minor/wrong issues and then start the AWOL > > procedure. > > It's called "common sense". But it is not easy to define. What may be a minor > defect in your point of view, could be considered a serious defect by other > users or packagers. In the current proposal, it isn't said that only serious defects qualify for launching the AWOL procedure. > So, assuming that the AWOL procedure is not started too often, it would be That's what I think should be avoided by providing enough guidelines. > extremely impolite of a Fedora Extras Contributor to refuse to comment in > bugzilla. Especially when a fellow contributor joins the AWOL procedure in > agreement that the reported issue is serious. -- Pat From mailinglists at erwinrol.com Wed Jul 5 10:53:03 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 05 Jul 2006 12:53:03 +0200 Subject: opengroupware for FE In-Reply-To: <20060705102330.GF1419@neu.nirvana> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> Message-ID: <1152096783.30969.328.camel@xpc.home.erwinrol.com> On Wed, 2006-07-05 at 12:23 +0200, Axel Thimm wrote: > On Wed, Jul 05, 2006 at 01:04:05AM +0200, Helge Hess wrote: > > On Jul 4, 2006, at 14:43, Axel Thimm wrote: > > >That's how it is done now already. gnustep-make, libFoundation are > > >non-issues. libobjc-lf2 is a hack, but in this light still packaged > > >decently, but getting rid of it would be a blessing. > > > > We have released libFoundation 1.1.0 which removes the hack > > So gnustep-make can safely use -lobjc instead of -lobjc-lf2 as a > default? > > > and adds a preliminary x86_64 port (seems to work fine but is not > > well tested ...): > > > > http://svn.opengroupware.org/ThirdParty/releases/libFoundation-1.1.0/ > > > > We'll work on packaging it (including RPMs and tarballs) ASAP but > > maybe you want to look into this as well for your Fedora package. > > I'd prefer using a released tarball otherwise it will make the review > process much harder (the reviewer is supposed to check the sources). > > Even if it sounds silly, can you please just officially upload the > tarball to a permanent URL? Thanks! So after this is done it means gnustep-make and libFoundation packages can be added to FE ? Axel will you "arrange" that ? The next step would be sope, Helge is there any magic going on in sope, or is that just a matter of packaging the latest release tarball. Like Axel mentioned working from a non tarball makes things a bit hard (local testing would work of course). - Erwin From Axel.Thimm at ATrpms.net Wed Jul 5 11:00:40 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 5 Jul 2006 13:00:40 +0200 Subject: opengroupware for FE In-Reply-To: <1152096783.30969.328.camel@xpc.home.erwinrol.com> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> <1152096783.30969.328.camel@xpc.home.erwinrol.com> Message-ID: <20060705110040.GH1419@neu.nirvana> On Wed, Jul 05, 2006 at 12:53:03PM +0200, Erwin Rol wrote: > On Wed, 2006-07-05 at 12:23 +0200, Axel Thimm wrote: > > On Wed, Jul 05, 2006 at 01:04:05AM +0200, Helge Hess wrote: > > > On Jul 4, 2006, at 14:43, Axel Thimm wrote: > > > >That's how it is done now already. gnustep-make, libFoundation are > > > >non-issues. libobjc-lf2 is a hack, but in this light still packaged > > > >decently, but getting rid of it would be a blessing. > > > > > > We have released libFoundation 1.1.0 which removes the hack > > > > So gnustep-make can safely use -lobjc instead of -lobjc-lf2 as a > > default? > > > > > and adds a preliminary x86_64 port (seems to work fine but is not > > > well tested ...): > > > > > > http://svn.opengroupware.org/ThirdParty/releases/libFoundation-1.1.0/ > > > > > > We'll work on packaging it (including RPMs and tarballs) ASAP but > > > maybe you want to look into this as well for your Fedora package. > > > > I'd prefer using a released tarball otherwise it will make the review > > process much harder (the reviewer is supposed to check the sources). > > > > Even if it sounds silly, can you please just officially upload the > > tarball to a permanent URL? Thanks! > > So after this is done it means gnustep-make and libFoundation packages > can be added to FE ? Axel will you "arrange" that ? Already started earlier today, but I'm waiting till the end of week to make a call for reviewers (where Helge will have released some more bits :). See for example: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197649 I'll repost with a list of all opengroupware related bugzillas when they are submitted. > The next step would be sope, Helge is there any magic going on in sope, > or is that just a matter of packaging the latest release tarball. Like > Axel mentioned working from a non tarball makes things a bit hard (local > testing would work of course). It's just packaging it up and I hope the current specfile will still be able to do it. I recently packaged sope 4.5.7 and apart from an ICE in objc in fc4 it went fine. -- 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 jwboyer at jdub.homelinux.org Wed Jul 5 11:45:38 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 05 Jul 2006 06:45:38 -0500 Subject: next FESCo meeting agenda. In-Reply-To: <1152089341.3496.126.camel@T7.Linux> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> Message-ID: <1152099938.22623.15.camel@weaponx.rchland.ibm.com> On Wed, 2006-07-05 at 09:49 +0100, Paul wrote: > Hi, > > > I also think that "a maintainer isn't answering their bugs, not answering > > rebuild requests, emails or the like" opens a bit too much for interpretation. > > It also has a problem. I've been out of things for about 10 days, which > means that I have an anjuta bug which is over 2 weeks old. I'm also > waiting on an upstream response for a bug problem, so it's slow going. > The bug is still being worked on, but hasn't been fixed. Easy to indicate in a bug report, hence showing that you are not AWOL. > > You also have the problem of folks being on holiday. It's not unusual in > the UK for people to vanish for 2 - 3 weeks. We have a vacation page in the wiki. That should be checked first. > > Some bugs are also much bigger than first thought. z88dk on 64 bit being > one such example. It is still being worked on, but the problem is that > the code generated isn't happy fully, so it's not in a state that I > would want to see released. Also easy to indicate in a bug report. > > > In my opinion it should be only serious issues that allows AWOL procedure. > > Like security bug, big usability bug, broken dependency, or a need to rebuild > > against newer library version. I don't think it would be right to allow > > people to bug maintainers for minor/wrong issues and then start the AWOL > > procedure. > > The AWOL problem is not a trivial one. A while back, I posted something > similar to Mike's proposal to the f-extras list - the main problem > identified was that it is hard to fix time limits on things (though the > thread may have been on orphaned packages). Yes, fixed time limits are hard to do. I had a situation a while ago were 2 weeks would not have been enough, so I would suggest something a bit longer. josh From jwboyer at jdub.homelinux.org Wed Jul 5 11:50:46 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 05 Jul 2006 06:50:46 -0500 Subject: next FESCo meeting agenda. In-Reply-To: <20060705091321.GB2487@free.fr> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <44AB7A73.5070201@knox.net.nz> <20060705091321.GB2487@free.fr> Message-ID: <1152100246.22623.20.camel@weaponx.rchland.ibm.com> On Wed, 2006-07-05 at 11:13 +0200, Patrice Dumas wrote: > > >I also think that a maintainer should not be considered AWOL when he has > > >shown some activity in a package or other packages even if he doesn't > > >respond to some bugs in a particular package. If he is still active in > > >other parts of fedora extras, maybe it could be the sponsor responsibility > > >to try to come to an agreement. > > No comment on that part? I think the maintainer is being negligent in that situation. It takes little effort to simply comment a bug with an excuse as to why that other package isn't being worked on. And if that type of behavior continues, then for all intents and purposes that particular package has an AWOL maintainer. It's up to the sponsor of that maintainer to either help educate and correct the behavior, or re-evaluate whether or not that is acceptable behavior from a maintainer. josh From nicolas.mailhot at laposte.net Wed Jul 5 08:50:24 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 5 Jul 2006 10:50:24 +0200 (CEST) Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <44AB5E2D.8060707@feuerpokemon.de> References: <1152079490.23468.0.camel@rousalka.dyndns.org> <44AB5E2D.8060707@feuerpokemon.de> Message-ID: <34740.192.54.193.53.1152089424.squirrel@rousalka.dyndns.org> Le Mer 5 juillet 2006 08:37, dragoran a ?crit : > I tryed it but for me the default font used in apps (FC5) looks better > and is easier to read... > the new fonts look to 'thin' and are harder to read because of this .. > notes: > 1) I am using a TFT with a german locale + no subpixel AA, but greyscale > AA > 2) I have recompiled the freetypelib with the bytecode interpretter > enabled I seem to remember the bytecode interpreter makes DejaVu lighter (and users of proprietary systems prefer it this way). Can you try it with the default fedora freetype ? I've opened the following ticket. Feel free to complete it https://bugs.freedesktop.org/show_bug.cgi?id=7427 Regards, -- Nicolas Mailhot From bugs.michael at gmx.net Wed Jul 5 12:18:04 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 5 Jul 2006 14:18:04 +0200 Subject: next FESCo meeting agenda. In-Reply-To: <20060705104556.GB4619@free.fr> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <20060705115116.83628f34.bugs.michael@gmx.net> <20060705104556.GB4619@free.fr> Message-ID: <20060705141804.54508ca3.bugs.michael@gmx.net> On Wed, 5 Jul 2006 12:45:56 +0200, Patrice Dumas wrote: > > Conclusively, it's a sponsor's decision whether to accept a new contributor > > and regardless of what he wants to work on. > > I completely agree on that. What I am saying is that one should be sponsored > in order to take over a package. A non-issue. So far, you cannot get the necessary access _without_ a sponsor. > Imagine that a maintainer is active on package foo but doesn't respond on > issues about pakage bar. But why is that? What are we discussing here? I find such discussions tiresome and unneeded. Please, let's not get lost in unimportant details before we even have seen an AWOL procedure in action. Do we care whether a person is busy with something that there is no time to write a single word in almost a month? How do we know whether the person notices incoming PRs at all? -- We do not care. We want to create a procedure for finding out whether somebody is still reachable. We want to know what can be done about somebody, who appears to be unreachable according to the mandatory tracking of contact attempts. What are the right steps? The procedure is necessary, so at the time FESCO is contacted, there is input which can be examined. > It is not clear, in the AWOL policy whether the > AWOL procedure should be started or not. If you're unsure whether you've reported something serious, consult a mailing-list first. There may be suggestions that a reported issue is unimportant. After another month, possibly the situation changes and more people think the package is in a desolate state which justifies starting with the AWOL procedure. From bugs.michael at gmx.net Wed Jul 5 12:34:07 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 5 Jul 2006 14:34:07 +0200 Subject: next FESCo meeting agenda. In-Reply-To: <20060705091321.GB2487@free.fr> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <44AB7A73.5070201@knox.net.nz> <20060705091321.GB2487@free.fr> Message-ID: <20060705143407.78f8eef2.bugs.michael@gmx.net> On Wed, 5 Jul 2006 11:13:22 +0200, Patrice Dumas wrote: > > This is why its required to post to fedora-extras@ and a FESCo member > > give approval. > > Indeed, but I think that it should also be stated in the proposal. I propose > something along (for the first point in Outline): > > When Fedora Extras member sees that a maintainer isn't answering serious > bugs, in particular when there is a fix provided, and for the bugs related > to security, major usability issues (crashs), request for rebuild against > newer libs, and that the maintainer is not answering rebuild requests, > emails or the like, they need to file a bug against the package in bugzilla > asking for the maintainer to respond. Is all this really needed? In case of security vulnerabilities, the Security Team should not need to wait long for any response anyway. And all the things you sum up have one thing in common already: a _bugzilla ticket_ about an issue with a package. Creating a long list of issues is not necessary. But the exceptions, when starting the AWOL procedure would be exaggerated, are only a few. A fellow contributor might want something else when opening a bugzilla ticket, e.g. a coordinated API upgrade before next freeze. How long would you wait for a response? It doesn't hurt to start an official procedure early. The package maintainer might be missing actually, and it is important to find out about that. From dtimms at bigpond.net.au Wed Jul 5 12:39:16 2006 From: dtimms at bigpond.net.au (David Timms) Date: Wed, 05 Jul 2006 22:39:16 +1000 Subject: Azureus/gcj x86_64 (i'm on i386) In-Reply-To: <1152078239.2880.49.camel@localhost.localdomain> References: <1152037516.27652.2.camel@home-desk> <44AAF5FC.3090900@bigpond.net.au> <1152078239.2880.49.camel@localhost.localdomain> Message-ID: <44ABB2F4.1030108@bigpond.net.au> Anthony Green wrote: > On Wed, 2006-07-05 at 09:13 +1000, David Timms wrote: >> On FC5, I couldn't get either limewire or azureus to run with gcj. Went >> with the sun rpm.bins and both works fine. You obviously got further >> than I did. > > Are you actually running the azureus from Fedora Extras? Ack. {Sean:Linux davidtdesktop 2.6.17-1.2138_FC5 #1 Tue Jun 20 16:39:39 EDT 2006 i686 athlon i386 GNU/Linux} > What does "rpm -qf /usr/bin/azureus" say? azureus-2.4.0.3-0.20060529cvs_1.fc5 Build Host: hammer2.fedora.redhat.com > Older unpackaged versions of azureus didn't run on gcj because they used > proprietary Sun extensions to the java platform. I fixed all this in > the FE version and got my changes accepted upstream. Very new versions > should run, but I recommend running the FE packaged release. # alternatives --display java java - status is manual. link currently points to /usr/java/jdk1.5.0_06/bin/java /usr/lib/jvm/jre-1.4.2-gcj/bin/java - priority 1420 ... /opt/jre1.5/bin/java - priority 2 ... /usr/java/jdk1.5.0_06/bin/java - priority 2 ... Current `best' version is /usr/lib/jvm/jre-1.4.2-gcj ---2.4.0.3_cvs Java 1.5.0_06 Sun Microsystems Inc. SWT v3139, gtk Linux v2.6.17-1.2138_FC5, i386 ---2.4.0.2 (from jar) Java 1.5.0_06 Sun Microsystems Inc. SWT v3139, gtk Linux v2.6.17-1.2138_FC5, i386 /bin/java. Looks like both start OK, and both currently use sun java. I changed alternative to auto: link currently points to /usr/lib/jvm/jre-1.4.2-gcj/bin/java I can confirm what you said 2.4.0.2 crashes during startup on gcj, while 2.4.0.3_cvs on gcj runs, and seems to be downloading some fudcon videos OK. DavidT. From riku.seppala at kymp.net Wed Jul 5 13:04:12 2006 From: riku.seppala at kymp.net (=?ISO-8859-1?Q?Riku_Sepp=E4l=E4?=) Date: Wed, 05 Jul 2006 16:04:12 +0300 Subject: For wishlist: KeyTouch Message-ID: <44ABB8CC.8050906@kymp.net> Hello Not sure if this is the right place to ask, but I wish this I could see this on Fedora Extras someday. I think it could be very usefull for many desktop users and would make Fedora more user friendly. KeyTouch http://keytouch.sourceforge.net/ About keyTouch KeyTouch is a program which allows you to easily configure the extra function keys of your keyboard. This means that you can define, for every individual function key, what to do if it is pressed. Riku. From dtimms at bigpond.net.au Wed Jul 5 13:18:42 2006 From: dtimms at bigpond.net.au (David Timms) Date: Wed, 05 Jul 2006 23:18:42 +1000 Subject: RFE: Review Request:
- In-Reply-To: <20060705093642.GE1419@neu.nirvana> References: <20060705093642.GE1419@neu.nirvana> Message-ID: <44ABBC32.9080705@bigpond.net.au> Axel Thimm wrote: > Hi, > > currently the new package creation process in bugzilla: > > https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&format=extras-review > > suggests using "Review Request:
" in > bugzilla's summary. It would make the sent mails and bugzilla browsing > much more interesting if the package's purpose could already be read > off this one-liner. > > Currently I see some submitted packages and unless I already know the > project I can't associate anything with it. > > Some submitters are already adding the package's summary to > bugzilla's, but if the URL above would change the template to suggest > always doing so, that would be perfect, thanks! :) Is there a limit to the length of the summary field ? Some complicated packages are pretty hard to summarize in a few words ;) --- I would like to see a final item added to the guidelines: "When the package is reviewed, accepted and committed to CVS, the maintainer is required to add a final comment in the bug with the link to the .spec file in the repository. For example: http://cvs.fedora.redhat.com/viewcvs/rpms/azureus/devel/azureus.spec?root=extras&view=markup" Reason, I been trying to learn/understand the rpm/spec/extras process. Just about every package in the reviewrequest bugs has links to spec files that have since been removed, perhaps even the day that the spec is imported into cvs. People need easy access to the current spec file to make it easier to learn tricks about best practice etc. DaveT. From Axel.Thimm at ATrpms.net Wed Jul 5 13:27:13 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 5 Jul 2006 15:27:13 +0200 Subject: RFE: Review Request:
- In-Reply-To: <44ABBC32.9080705@bigpond.net.au> References: <20060705093642.GE1419@neu.nirvana> <44ABBC32.9080705@bigpond.net.au> Message-ID: <20060705132713.GI1419@neu.nirvana> On Wed, Jul 05, 2006 at 11:18:42PM +1000, David Timms wrote: > Axel Thimm wrote: > >Hi, > > > >currently the new package creation process in bugzilla: > > > >https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&format=extras-review > > > >suggests using "Review Request:
" in > >bugzilla's summary. It would make the sent mails and bugzilla browsing > >much more interesting if the package's purpose could already be read > >off this one-liner. > > > >Currently I see some submitted packages and unless I already know the > >project I can't associate anything with it. > > > >Some submitters are already adding the package's summary to > >bugzilla's, but if the URL above would change the template to suggest > >always doing so, that would be perfect, thanks! :) > Is there a limit to the length of the summary field ? Some complicated > packages are pretty hard to summarize in a few words ;) I hope there is a limit. Complicated or not Summaries should be summaries, I'd even like an rpmlint option to warn when summaries are half the package's content. > --- > I would like to see a final item added to the guidelines: This is completely off-topic to this thread (also known as thread hijacking). Why not open up a new one instead? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Wed Jul 5 13:33:23 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 5 Jul 2006 15:33:23 +0200 Subject: next FESCo meeting agenda. In-Reply-To: <1152089341.3496.126.camel@T7.Linux> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> Message-ID: <20060705153323.3f7032b4.bugs.michael@gmx.net> On Wed, 05 Jul 2006 09:49:01 +0100, Paul wrote: > Hi, > > > I also think that "a maintainer isn't answering their bugs, not answering > > rebuild requests, emails or the like" opens a bit too much for interpretation. > > It also has a problem. I've been out of things for about 10 days, which > means that I have an anjuta bug which is over 2 weeks old. I'm also > waiting on an upstream response for a bug problem, so it's slow going. > The bug is still being worked on, but hasn't been fixed. I fail to see where this is relevant, It is not an issue when there has been activity in the ticket previously and it becomes clear that a fix is "hard" or does not exist yet. Starting the AWOL procedure without being able to fix the bug doesn't sound likely. > You also have the problem of folks being on holiday. It's not unusual in > the UK for people to vanish for 2 - 3 weeks. So what? While on vacation, one of your packages may need the attention. It's best to have co-maintainers. > Some bugs are also much bigger than first thought. z88dk on 64 bit being > one such example. It is still being worked on, but the problem is that > the code generated isn't happy fully, so it's not in a state that I > would want to see released. Same as with above anjuta bug. From skvidal at linux.duke.edu Wed Jul 5 13:40:19 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 09:40:19 -0400 Subject: next FESCo meeting agenda. In-Reply-To: <20060705153323.3f7032b4.bugs.michael@gmx.net> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> <20060705153323.3f7032b4.bugs.michael@gmx.net> Message-ID: <1152106819.8883.7.camel@cutter> > > You also have the problem of folks being on holiday. It's not unusual in > > the UK for people to vanish for 2 - 3 weeks. > > So what? While on vacation, one of your packages may need the attention. > It's best to have co-maintainers. +1 for co-maintainers. -sv From fedora at leemhuis.info Wed Jul 5 13:53:47 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Jul 2006 15:53:47 +0200 Subject: enforce co-maintainers (was: Re: next FESCo meeting agenda.) In-Reply-To: <1152106819.8883.7.camel@cutter> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> <20060705153323.3f7032b4.bugs.michael@gmx.net> <1152106819.8883.7.camel@cutter> Message-ID: <44ABC46B.7050702@leemhuis.info> seth vidal schrieb: >>> You also have the problem of folks being on holiday. It's not unusual in >>> the UK for people to vanish for 2 - 3 weeks. >> So what? While on vacation, one of your packages may need the attention. >> It's best to have co-maintainers. > +1 for co-maintainers. Well, should we try to enforce co-maintainers in the longer term? E.g. a rule "each package must have at least one primary maintainer and one co-maintainer"? Cu thl From skvidal at linux.duke.edu Wed Jul 5 14:00:20 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 10:00:20 -0400 Subject: enforce co-maintainers (was: Re: next FESCo meeting agenda.) In-Reply-To: <44ABC46B.7050702@leemhuis.info> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> <20060705153323.3f7032b4.bugs.michael@gmx.net> <1152106819.8883.7.camel@cutter> <44ABC46B.7050702@leemhuis.info> Message-ID: <1152108020.8883.17.camel@cutter> On Wed, 2006-07-05 at 15:53 +0200, Thorsten Leemhuis wrote: > seth vidal schrieb: > >>> You also have the problem of folks being on holiday. It's not unusual in > >>> the UK for people to vanish for 2 - 3 weeks. > >> So what? While on vacation, one of your packages may need the attention. > >> It's best to have co-maintainers. > > +1 for co-maintainers. > > Well, should we try to enforce co-maintainers in the longer term? E.g. a > rule "each package must have at least one primary maintainer and one > co-maintainer"? > That'll just make the barrier to addition higher. I'd say we don't mandate it but make sure all the bits are there for it to be encouraged :) -sv From rc040203 at freenet.de Wed Jul 5 14:02:18 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 05 Jul 2006 16:02:18 +0200 Subject: enforce co-maintainers (was: Re: next FESCo meeting agenda.) In-Reply-To: <44ABC46B.7050702@leemhuis.info> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> <20060705153323.3f7032b4.bugs.michael@gmx.net> <1152106819.8883.7.camel@cutter> <44ABC46B.7050702@leemhuis.info> Message-ID: <1152108138.6721.25.camel@mccallum.corsepiu.local> On Wed, 2006-07-05 at 15:53 +0200, Thorsten Leemhuis wrote: > seth vidal schrieb: > >>> You also have the problem of folks being on holiday. It's not unusual in > >>> the UK for people to vanish for 2 - 3 weeks. > >> So what? While on vacation, one of your packages may need the attention. > >> It's best to have co-maintainers. > > +1 for co-maintainers. > > Well, should we try to enforce co-maintainers in the longer term? Enforce? ... encourage, yes. > E.g. a > rule "each package must have at least one primary maintainer and one > co-maintainer"? I am strongly opposed to this. It would be counterproductive. What we need is teams, dealing with certain tasks (e.g. systematic packaging bugs, x86_64 portability issues, security), not "multiple owners", fighting for details. Ralf From mmcgrath at fedoraproject.org Wed Jul 5 14:06:33 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 05 Jul 2006 09:06:33 -0500 Subject: enforce co-maintainers In-Reply-To: <1152108020.8883.17.camel@cutter> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> <20060705153323.3f7032b4.bugs.michael@gmx.net> <1152106819.8883.7.camel@cutter> <44ABC46B.7050702@leemhuis.info> <1152108020.8883.17.camel@cutter> Message-ID: <44ABC769.9060102@fedoraproject.org> seth vidal wrote: > On Wed, 2006-07-05 at 15:53 +0200, Thorsten Leemhuis wrote: > >> seth vidal schrieb: >> >>>>> You also have the problem of folks being on holiday. It's not unusual in >>>>> the UK for people to vanish for 2 - 3 weeks. >>>>> >>>> So what? While on vacation, one of your packages may need the attention. >>>> It's best to have co-maintainers. >>>> >>> +1 for co-maintainers. >>> >> Well, should we try to enforce co-maintainers in the longer term? E.g. a >> rule "each package must have at least one primary maintainer and one >> co-maintainer"? >> >> > > That'll just make the barrier to addition higher. > > I'd say we don't mandate it but make sure all the bits are there for it > to be encouraged :) > > -sv > Why not just have a task force who's job it is to make sure that critical updates get applied in a timely manner. If a bug is not responded to in a certain amount of time then the task force imports and builds the new package. 2-3 weeks is a long time for a security vulnerability, but it doesn't seem that long to wait for a major/minor release. -Mike From mattdm at mattdm.org Wed Jul 5 14:11:51 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Jul 2006 10:11:51 -0400 Subject: enforce co-maintainers (was: Re: next FESCo meeting agenda.) In-Reply-To: <1152108138.6721.25.camel@mccallum.corsepiu.local> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> <20060705153323.3f7032b4.bugs.michael@gmx.net> <1152106819.8883.7.camel@cutter> <44ABC46B.7050702@leemhuis.info> <1152108138.6721.25.camel@mccallum.corsepiu.local> Message-ID: <20060705141151.GA32545@jadzia.bu.edu> On Wed, Jul 05, 2006 at 04:02:18PM +0200, Ralf Corsepius wrote: > What we need is teams, dealing with certain tasks (e.g. systematic > packaging bugs, x86_64 portability issues, security), not "multiple "ipv6 support". :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From pertusus at free.fr Wed Jul 5 14:11:12 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 5 Jul 2006 16:11:12 +0200 Subject: enforce co-maintainers In-Reply-To: <44ABC769.9060102@fedoraproject.org> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> <20060705153323.3f7032b4.bugs.michael@gmx.net> <1152106819.8883.7.camel@cutter> <44ABC46B.7050702@leemhuis.info> <1152108020.8883.17.camel@cutter> <44ABC769.9060102@fedoraproject.org> Message-ID: <20060705141112.GA5078@free.fr> On Wed, Jul 05, 2006 at 09:06:33AM -0500, Mike McGrath wrote: > Why not just have a task force who's job it is to make sure that > critical updates get applied in a timely manner. If a bug is not > responded to in a certain amount of time then the task force imports and > builds the new package. 2-3 weeks is a long time for a security > vulnerability, but it doesn't seem that long to wait for a major/minor > release. Such a proposal is outlined here: http://fedoraproject.org/wiki/Extras/Schedule/SecurityPolicy (I don't remember what is the current status, though). -- Pat From fedora at leemhuis.info Wed Jul 5 14:15:47 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Jul 2006 16:15:47 +0200 Subject: enforce co-maintainers In-Reply-To: <1152108138.6721.25.camel@mccallum.corsepiu.local> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> <20060705153323.3f7032b4.bugs.michael@gmx.net> <1152106819.8883.7.camel@cutter> <44ABC46B.7050702@leemhuis.info> <1152108138.6721.25.camel@mccallum.corsepiu.local> Message-ID: <44ABC993.70500@leemhuis.info> Ralf Corsepius schrieb: > On Wed, 2006-07-05 at 15:53 +0200, Thorsten Leemhuis wrote: >> seth vidal schrieb: >>>>> You also have the problem of folks being on holiday. It's not unusual in >>>>> the UK for people to vanish for 2 - 3 weeks. >>>> So what? While on vacation, one of your packages may need the attention. >>>> It's best to have co-maintainers. >>> +1 for co-maintainers. >> Well, should we try to enforce co-maintainers in the longer term? > Enforce? ... encourage, yes. Yeah, that's probably better. But we have support for that for some time now but it's rarely used afaics :-/ >> E.g. a >> rule "each package must have at least one primary maintainer and one >> co-maintainer"? > I am strongly opposed to this. It would be counterproductive. > > What we need is teams, dealing with certain tasks (e.g. systematic > packaging bugs, x86_64 portability issues, security), Agreed. > not "multiple > owners", fighting for details. That's why I (or this idea that was posted to the list some month ago iirc) mentioned "primary" maintainer. Cu thl From rc040203 at freenet.de Wed Jul 5 14:15:03 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 05 Jul 2006 16:15:03 +0200 Subject: enforce co-maintainers (was: Re: next FESCo meeting agenda.) In-Reply-To: <20060705141151.GA32545@jadzia.bu.edu> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> <20060705153323.3f7032b4.bugs.michael@gmx.net> <1152106819.8883.7.camel@cutter> <44ABC46B.7050702@leemhuis.info> <1152108138.6721.25.camel@mccallum.corsepiu.local> <20060705141151.GA32545@jadzia.bu.edu> Message-ID: <1152108904.6721.34.camel@mccallum.corsepiu.local> On Wed, 2006-07-05 at 10:11 -0400, Matthew Miller wrote: > On Wed, Jul 05, 2006 at 04:02:18PM +0200, Ralf Corsepius wrote: > > What we need is teams, dealing with certain tasks (e.g. systematic > > packaging bugs, x86_64 portability issues, security), not "multiple > > "ipv6 support". :) Yes, ... if you want to enforce ipv6 support in all packages, set up a team consisting of specialists to review packages/code wrt. this topic. Ralf From jima at beer.tclug.org Wed Jul 5 14:15:39 2006 From: jima at beer.tclug.org (Jima) Date: Wed, 5 Jul 2006 09:15:39 -0500 (CDT) Subject: enforce co-maintainers (was: Re: next FESCo meeting agenda.) In-Reply-To: <1152108020.8883.17.camel@cutter> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> <20060705153323.3f7032b4.bugs.michael@gmx.net> <1152106819.8883.7.camel@cutter> <44ABC46B.7050702@leemhuis.info> <1152108020.8883.17.camel@cutter> Message-ID: On Wed, 5 Jul 2006, seth vidal wrote: > On Wed, 2006-07-05 at 15:53 +0200, Thorsten Leemhuis wrote: >> Well, should we try to enforce co-maintainers in the longer term? E.g. a >> rule "each package must have at least one primary maintainer and one >> co-maintainer"? >> > > That'll just make the barrier to addition higher. > > I'd say we don't mandate it but make sure all the bits are there for it > to be encouraged :) +1 to that. I can't agree with mandating a co-maintainer for every package. I do, however, certainly like the idea of the infrastructure to support co-maintainership being in place. I used to maintain various packages before they were added to Extras (by others, mind); that gives me something of an advantage when working with that package. I'd be happy to apply for co-maintainership for those packages. As an aside, as I see more emails pour in on this subject, I'd like to respond to Mike McGrath's "task force" suggestion: In a more broad sense, I think that works, but if there's someone with a more active knowledge/interest in the package, I feel they're a better candidate to be tinkering with it. If there isn't, though, then the task force idea isn't a bad one. But doesn't that kind of describe the Security Team? Jima From mmcgrath at fedoraproject.org Wed Jul 5 14:34:39 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 05 Jul 2006 09:34:39 -0500 Subject: FESCo Election Results Message-ID: <44ABCDFF.8030609@fedoraproject.org> Below are the election results for the recent FESCo Election. I'd encourage another person to verify these results. The cutoff line was 13. Votes | Human_name | Fedora_account_id 61 Tom Callaway 100061 60 Jeremy Katz 100036 57 Thorsten Leemhuis 100066 56 Ville Skytta 100055 53 Rex Dieter 100082 50 Michael Schwendt 100044 49 Jason Tibbitts 100158 44 Warren Togami 100073 41 Seth Vidal 100059 38 Toshio Ernie Kuratomi 100068 33 Joshua W. Boyer 100115 32 Dennis Gilmore 100103 31 Andreas Bierfert 100011 --------------------------------------- 30 Christian Iseli 100114 28 Brian Pepple 100012 25 Michael J Knox 100390 25 Kevin Fenzi 100037 17 Jose Pedro Oliveira 100033 Total Votes: 730 Total Ballots: 69 -Mike From shahms at shahms.com Wed Jul 5 14:41:43 2006 From: shahms at shahms.com (Shahms King) Date: Wed, 05 Jul 2006 07:41:43 -0700 Subject: python-psycopg2 package spec In-Reply-To: References: Message-ID: <44ABCFA7.4060207@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Troels Arvin wrote: > Hello, > > At http://troels.arvin.dk/code/psycopg2/rpm/python-psycopg2.spec I've put > a spec-file for a "python-psycopg2" package. The spec-file is modified > from the spec-file in > http://fedoraproject.org/extras/development/SRPMS/python-psycopg-1.1.21-4.fc5.src.rpm > > An rpm from the spec-file has been tested on my x86_64 installation and > seems to work well. > > I considered adding a "Conflicts: python-psycopg", but it seems that there > is no conflict in having both python-psycopg and python-psycopg2. > The psycopg2 package doesn't conflict with psycopg as the names have changed. Additionally, psycopg2 provides a backwards compatibility module. I'm not sure how complete the back-compat is and am simply waiting for psycopg2 to get out of beta before packaging it. Due to the upstream name change, there are some minor administrative questions about packaging the new package as well as determining how to deal with backwards compatibility. It's on my list, just not terribly high priority until psycopg2 is out of beta. - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEq8+n/qs2NkWy11sRAnmVAJ9C+DCgWvWauWHOW/pXEaradDzeGgCfYzg7 TMgtQ4y7eodOCXIp5BpoGoc= =h1sB -----END PGP SIGNATURE----- From Christian.Iseli at licr.org Wed Jul 5 14:47:19 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 05 Jul 2006 16:47:19 +0200 Subject: FE Package Status of Jul 5, 2006 Message-ID: <200607051447.k65ElJCV014971@ludwig-alpha.unil.ch> Hi folks, The weekly report is here... Still no news on kimdaba and php-apc ... I still think they should be removed from CVS. We have a rate of about 20 packages accepted per week. FE-NEW is pretty stable with 178 open tickets. FE-REVIEW tickets are up a bit with 112 open tickets. FE-NEEDSPONSOR is stable at 32 tickets. OPEN-BUGS is slightly down with 209 open tickets. One note to people doing reviews: please assign yourself to the ticket. We have "bugzilla-sink at leemhuis dot info" now showing up on the top-25 list of people doing reviews... that can't be right. ---- FE Package Status of Jul 5, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 1935 packages - 38 orphans - 26 packages not available in extras devel or release Fedora at FamilleCollet dot com php-pecl-zip Fedora at FamilleCollet dot com php-pear-HTTP cgoorah at yahoo dot com dot au kadischi davidhart at tqmcube dot com leafnode fredrik at dolda2000 dot com icmpdn ghenry at suretecsystems dot com gnome-applet-netmon ivazquez at ivazquez dot net gpredict jpo at di dot uminho dot pt perl-Test-Builder-Tester jvdias at redhat dot com webmin matteo dot ricchetti at libero dot it ss5 matthias at rpmforge dot net fillets-ng-data-cs nicolas dot mailhot at laposte dot net zoo notting at redhat dot com aqhbci-qt-tools notting at redhat dot com comps oliver at linux-kernel dot at squidGuard tcallawa at redhat dot com R-RScaLAPACK tcallawa at redhat dot com libgdamm tcallawa at redhat dot com R-hdf5 tcallawa at redhat dot com lout tcallawa at redhat dot com pam_pkcs11 tcallawa at redhat dot com opendap toniw at iki dot fi silky toniw at iki dot fi libmatchbox toshio at tiki-lounge dot com hula wolters dot liste at gmx dot net ktorrent wtogami at redhat dot com iiimf-le-simplehangul - 7 packages not available in extras devel but present in release andreas at bawue dot net echoping andreas at bawue dot net mboxgrep drfickle at k-lug dot org libhugetlbfs ianburrell at gmail dot com perl-Algorithm-Annotate noa at resare dot com vorbisgain zipsonic at gmail dot com nx zipsonic at gmail dot com freenx - 3 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=187818,189375 ktorrent wolters.liste at gmx.net Maelstrom notting at redhat.com https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=197653 x3270 karsten at redhat.com - 2 packages present in the development repo which have no owners entry perl-List-Compare perl-Math-Round - 2 orphaned packages, yet available in extras devel gtkglarea2 soundtracker - 39 packages that moved to core Packages appearing both in Core and Extras: - 2 packages duplicated for devel: petersen at redhat dot com scim-bridge tagoh at redhat dot com paps FE-ACCEPT packages stats: - 991 accepted, closed package reviews - 7 accepted, closed package reviews not in repo - 4 accepted, closed package reviews not in owners - 12 accepted, open package reviews older than 4 weeks; - 7 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 112 open tickets - 24 tickets with no activity in eight weeks - 24 tickets with no activity in four weeks - 2 closed tickets FE-NEW packages stats: - 178 open tickets - 21 tickets with no activity in eight weeks - 43 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 32 open tickets - 2 tickets with no activity in eight weeks - 11 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets - 1 tickets with no activity in four weeks OPEN-BUGS packages stats: - 220 open tickets - 146 tickets with no activity in eight weeks - 24 tickets with no activity in four weeks CVS stats: - 1910 packages with a devel directory - 9 packages with no owners entry initng kile-i18n kimdaba muse pcb perl-List-Compare perl-Math-Round perl-Maypole php-apc - 2 packages in CVS devel *and* Core libevent paps - 99 packages were dropped from extras Maintainers stats: - 207 maintainers - 16 inactive maintainers with open bugs - 28 inactive maintainers Dropped FC packages: - 260 packages were dropped from core since FC 1 From jwboyer at jdub.homelinux.org Wed Jul 5 14:57:58 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 05 Jul 2006 09:57:58 -0500 Subject: FE Package Status of Jul 5, 2006 In-Reply-To: <200607051447.k65ElJCV014971@ludwig-alpha.unil.ch> References: <200607051447.k65ElJCV014971@ludwig-alpha.unil.ch> Message-ID: <1152111478.22623.37.camel@weaponx.rchland.ibm.com> On Wed, 2006-07-05 at 16:47 +0200, Christian.Iseli at licr.org wrote: > Hi folks, > > The weekly report is here... > - 7 packages not available in extras devel but present in release > drfickle at k-lug dot org libhugetlbfs FYI, this one was explicitly called out in the review as not working in devel yet. I believe it's a temporary situation that will be corrected eventually. josh From Christian.Iseli at licr.org Wed Jul 5 15:03:43 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 05 Jul 2006 17:03:43 +0200 Subject: FESCo Election Results In-Reply-To: Your message of "Wed, 05 Jul 2006 09:34:39 CDT." <44ABCDFF.8030609@fedoraproject.org> Message-ID: <200607051503.k65F3hhE015297@ludwig-alpha.unil.ch> Thanks for posting the results. And congrats to the new FESCO members. Looking forward for your inspiring leadership. :-) Cheers, Christian From opensource at till.name Wed Jul 5 15:14:14 2006 From: opensource at till.name (Till Maas) Date: Wed, 05 Jul 2006 17:14:14 +0200 Subject: enforce co-maintainers In-Reply-To: <44ABC769.9060102@fedoraproject.org> References: <44AB69CD.8000607@knox.net.nz> <1152108020.8883.17.camel@cutter> <44ABC769.9060102@fedoraproject.org> Message-ID: <200607051714.14469.opensource@till.name> Am Mittwoch, 5. Juli 2006 16:06 schrieb Mike McGrath: > Why not just have a task force who's job it is to make sure that > critical updates get applied in a timely manner. If a bug is not > responded to in a certain amount of time then the task force imports and > builds the new package. 2-3 weeks is a long time for a security > vulnerability, but it doesn't seem that long to wait for a major/minor > release. This task force could as well act as an vacation stand-in so that timeframes can be shortened if a maintainer announces that he is in vacation. The task force could then perform critical updates as soon as possible while the maintainer is in vacation. Regards, Till From kevin-fedora-extras at scrye.com Wed Jul 5 15:17:14 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Wed, 05 Jul 2006 09:17:14 -0600 (MDT) Subject: FE Package Status of Jul 5, 2006 References: <200607051447.k65ElJCV014971@ludwig-alpha.unil.ch> Message-ID: <20060705.091714.164937741.kevin@scrye.com> >>>>> "Christian" == Christian Iseli writes: Christian> Hi folks, The weekly report is here... Christian> Still no news on kimdaba and php-apc ... I still think Christian> they should be removed from CVS. kimdaba is the old name for kphotoalbum. It was changed upstream. Not sure if it should be removed from CVS (perhaps someone would have some historical interest in it?) or just marked that it's a dead package. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin-fedora-extras at scrye.com Wed Jul 5 15:19:09 2006 From: kevin-fedora-extras at scrye.com (Kevin Fenzi) Date: Wed, 05 Jul 2006 09:19:09 -0600 (MDT) Subject: FESCo Election Results References: <44ABCDFF.8030609@fedoraproject.org> Message-ID: <20060705.091909.596600225.kevin@scrye.com> Congrats to the incoming FESCo. I'm looking forward to exciting things... :) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Jul 5 15:24:23 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Jul 2006 17:24:23 +0200 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: <44ABCDFF.8030609@fedoraproject.org> References: <44ABCDFF.8030609@fedoraproject.org> Message-ID: <44ABD9A7.2040306@leemhuis.info> Mike McGrath schrieb: > Below are the election results for the recent FESCo Election. I'd > encourage another person to verify these results. The cutoff line was 13. > Votes | Human_name | Fedora_account_id thx for posting the results mmcgrath, thx to the infrastructure team in general, thx to Toshio and everybody else for programing the voting app and congrats to all those that got elected. But now to the real topic of this mail: What do all of you think about the whole election. Was it a good idea? Or only wasted time? "Total Ballots: 69" (we have round about 270 people that were permitted to vote) looks a bit sad IMHO. Should we do another election in the future? When? Reelect half of the seats after FC7 (FC6 is to short)? The other half after FC8, then the first half again after FC9 (and so forth)? Anything else we should handle differently in the future? CU thl From chabotc at xs4all.nl Wed Jul 5 15:39:13 2006 From: chabotc at xs4all.nl (Chris Chabot) Date: Wed, 05 Jul 2006 17:39:13 +0200 Subject: FE Package Status of Jul 5, 2006 In-Reply-To: <200607051447.k65ElJCV014971@ludwig-alpha.unil.ch> References: <200607051447.k65ElJCV014971@ludwig-alpha.unil.ch> Message-ID: <1152113953.1866.9.camel@localhost.localdomain> On Wed, 2006-07-05 at 16:47 +0200, Christian.Iseli at licr.org wrote: > Still no news on kimdaba and php-apc ... I still think they should be removed > from CVS. I agree about the php-apc ;-) I added this note a while back to: http://fedoraproject.org/wiki/Extras/CVSSyncNeeded "Put requests for special CVS change/removal operations here: * php-apc, being renamed to php-pecl-apc" just took a while for it to be picked up :-) (all this happened when someone who wasn;t qualified to review/approve did so on the package, on subsiquent real review, the package name got changed, but after cvs import) -- Chris From Christian.Iseli at licr.org Wed Jul 5 16:15:30 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 05 Jul 2006 18:15:30 +0200 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: Your message of "Wed, 05 Jul 2006 17:24:23 +0200." <44ABD9A7.2040306@leemhuis.info> Message-ID: <200607051645.k65Gj9m9022226@mx3.redhat.com> fedora at leemhuis.info said: > But now to the real topic of this mail: What do all of you think about the > whole election. Was it a good idea? Yes. > Or only wasted time? No. > "Total Ballots: 69" > (we have round about 270 people that were permitted to vote) looks a bit sad > IMHO. So ? If the remaining 201 people don't have an opinion, that's their right. Maybe they'll form an opinion over time, and participate in the next election. > Should we do another election in the future? Yes. > When? Reelect half of the seats > after FC7 (FC6 is to short)? The other half after FC8, then the first half > again after FC9 (and so forth)? Yes, I think that was the idea. > Anything else we should handle differently in the future? I see Seth, Ville, and Michael got re-elected even though it said on the nomination page: nominated for the new FESCo as contingent by skvidal (contingent: if no one else wants it - they will step up and do the job) I know I abstained voting for them because of this message... I do hope they'll accept the job now. Maybe next time it'd be better if the nomination page is a bit clearer and doesn't mislead me into thinking some of the people there might prefer not being elected. Cheers, Christian From skvidal at linux.duke.edu Wed Jul 5 16:53:46 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 12:53:46 -0400 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: <200607051645.k65Gj9m9022226@mx3.redhat.com> References: <200607051645.k65Gj9m9022226@mx3.redhat.com> Message-ID: <1152118426.8883.37.camel@cutter> On Wed, 2006-07-05 at 18:15 +0200, Christian.Iseli at licr.org wrote: > fedora at leemhuis.info said: > > But now to the real topic of this mail: What do all of you think about the > > whole election. Was it a good idea? > > Yes. > > > Or only wasted time? > > No. > > > "Total Ballots: 69" > > (we have round about 270 people that were permitted to vote) looks a bit sad > > IMHO. > > So ? If the remaining 201 people don't have an opinion, that's their right. > Maybe they'll form an opinion over time, and participate in the next election. > > > Should we do another election in the future? > > Yes. > > > When? Reelect half of the seats > > after FC7 (FC6 is to short)? The other half after FC8, then the first half > > again after FC9 (and so forth)? > > Yes, I think that was the idea. > > > Anything else we should handle differently in the future? > > I see Seth, Ville, and Michael got re-elected even though it said on the > nomination page: > nominated for the new FESCo as contingent by skvidal > (contingent: if no one else wants it - they will step up and do the job) > > I know I abstained voting for them because of this message... > > I do hope they'll accept the job now. > > Maybe next time it'd be better if the nomination page is a bit clearer and > doesn't mislead me into thinking some of the people there might prefer not > being elected. > Actually. You need to email me or find me on irc. We should discuss that very issue. As discussed with Thorsten -seeing as there are other people who want the job I'd happily step aside for you to take my spot. -sv From Christian.Iseli at licr.org Wed Jul 5 15:51:04 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 05 Jul 2006 17:51:04 +0200 Subject: FE Package Status of Jul 5, 2006 In-Reply-To: Your message of "Wed, 05 Jul 2006 09:17:14 MDT." <20060705.091714.164937741.kevin@scrye.com> Message-ID: <200607051649.k65Gn9HN023227@mx3.redhat.com> kevin-fedora-extras at scrye.com said: > or just marked that it's a dead package. Yes, that'd be fine too. Christian From rdieter at math.unl.edu Wed Jul 5 16:52:26 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Jul 2006 11:52:26 -0500 Subject: FE Package Status of Jul 5, 2006 In-Reply-To: <200607051447.k65ElJCV014971@ludwig-alpha.unil.ch> References: <200607051447.k65ElJCV014971@ludwig-alpha.unil.ch> Message-ID: Christian.Iseli at licr.org wrote: > Still no news on kimdaba and php-apc ... I still think they should be removed > from CVS. ... > CVS stats: ,,, > - 9 packages with no owners entry > kile-i18n kimdaba Both kile-i18n, kimdaba are packages that have been Obsoleted by others. What extra "news" is required? -- Rex From skvidal at linux.duke.edu Wed Jul 5 17:12:29 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 13:12:29 -0400 Subject: FESCo Election Results In-Reply-To: <44ABCDFF.8030609@fedoraproject.org> References: <44ABCDFF.8030609@fedoraproject.org> Message-ID: <1152119550.8883.42.camel@cutter> On Wed, 2006-07-05 at 09:34 -0500, Mike McGrath wrote: > Below are the election results for the recent FESCo Election. I'd > encourage another person to verify these results. The cutoff line was 13. > > Votes | Human_name | Fedora_account_id > > 61 Tom Callaway 100061 > 60 Jeremy Katz 100036 > 57 Thorsten Leemhuis 100066 > 56 Ville Skytta 100055 > 53 Rex Dieter 100082 > 50 Michael Schwendt 100044 > 49 Jason Tibbitts 100158 > 44 Warren Togami 100073 > 41 Seth Vidal 100059 > 38 Toshio Ernie Kuratomi 100068 > 33 Joshua W. Boyer 100115 > 32 Dennis Gilmore 100103 > 31 Andreas Bierfert 100011 > --------------------------------------- > 30 Christian Iseli 100114 > 28 Brian Pepple 100012 > 25 Michael J Knox 100390 > 25 Kevin Fenzi 100037 > 17 Jose Pedro Oliveira 100033 > > Hi Everyone, I was 'elected' in some sense or another however as I promised I am willing to step down if someone else among those nominated but not elected wish to take my place. As Christian received the most votes below the line I'm offering to step down and for him to take my place. Everyone cool w/that? -sv From mmcgrath at fedoraproject.org Wed Jul 5 17:11:19 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 05 Jul 2006 12:11:19 -0500 Subject: FESCo Election Results In-Reply-To: <1152119550.8883.42.camel@cutter> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> Message-ID: <44ABF2B7.4080506@fedoraproject.org> seth vidal wrote: > On Wed, 2006-07-05 at 09:34 -0500, Mike McGrath wrote: > >> Below are the election results for the recent FESCo Election. I'd >> encourage another person to verify these results. The cutoff line was 13. >> >> Votes | Human_name | Fedora_account_id >> >> 61 Tom Callaway 100061 >> 60 Jeremy Katz 100036 >> 57 Thorsten Leemhuis 100066 >> 56 Ville Skytta 100055 >> 53 Rex Dieter 100082 >> 50 Michael Schwendt 100044 >> 49 Jason Tibbitts 100158 >> 44 Warren Togami 100073 >> 41 Seth Vidal 100059 >> 38 Toshio Ernie Kuratomi 100068 >> 33 Joshua W. Boyer 100115 >> 32 Dennis Gilmore 100103 >> 31 Andreas Bierfert 100011 >> --------------------------------------- >> 30 Christian Iseli 100114 >> 28 Brian Pepple 100012 >> 25 Michael J Knox 100390 >> 25 Kevin Fenzi 100037 >> 17 Jose Pedro Oliveira 100033 >> >> >> > > Hi Everyone, > I was 'elected' in some sense or another however as I promised I am > willing to step down if someone else among those nominated but not > elected wish to take my place. As Christian received the most votes > below the line I'm offering to step down and for him to take my place. > > Everyone cool w/that? > > -sv > +1 From jkeating at redhat.com Wed Jul 5 17:17:08 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Jul 2006 13:17:08 -0400 Subject: FESCo Election Results In-Reply-To: <1152119550.8883.42.camel@cutter> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> Message-ID: <200607051317.08742.jkeating@redhat.com> On Wednesday 05 July 2006 13:12, seth vidal wrote: > Hi Everyone, > ?I was 'elected' in some sense or another however as I promised I am > willing to step down if someone else among those nominated but not > elected wish to take my place. As Christian received the most votes > below the line I'm offering to step down and for him to take my place. > > Everyone cool w/that? +1 From jamatos at fc.up.pt Wed Jul 5 17:20:14 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 5 Jul 2006 18:20:14 +0100 Subject: FESCo Election Results In-Reply-To: <1152119550.8883.42.camel@cutter> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> Message-ID: <200607051820.14556.jamatos@fc.up.pt> On Wednesday 05 July 2006 18:12, seth vidal wrote: > Hi Everyone, > ?I was 'elected' in some sense or another however as I promised I am > willing to step down if someone else among those nominated but not > elected wish to take my place. As Christian received the most votes > below the line I'm offering to step down and for him to take my place. > > Everyone cool w/that? OK. Even on a pragmatical ground it is difficult to imagine how we could force you to be there against your will. :-) > -sv -- Jos? Ab?lio From skvidal at linux.duke.edu Wed Jul 5 17:27:27 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 13:27:27 -0400 Subject: FESCo Election Results In-Reply-To: <200607051820.14556.jamatos@fc.up.pt> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <200607051820.14556.jamatos@fc.up.pt> Message-ID: <1152120447.8883.44.camel@cutter> On Wed, 2006-07-05 at 18:20 +0100, Jose' Matos wrote: > On Wednesday 05 July 2006 18:12, seth vidal wrote: > > Hi Everyone, > > I was 'elected' in some sense or another however as I promised I am > > willing to step down if someone else among those nominated but not > > elected wish to take my place. As Christian received the most votes > > below the line I'm offering to step down and for him to take my place. > > > > Everyone cool w/that? > > OK. > > Even on a pragmatical ground it is difficult to imagine how we could force > you to be there against your will. :-) Thorsten and Max are lethal in their knowledge of krav maga. ;) -sv From jwboyer at jdub.homelinux.org Wed Jul 5 17:24:56 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 05 Jul 2006 12:24:56 -0500 Subject: FESCo Election Results In-Reply-To: <1152119550.8883.42.camel@cutter> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> Message-ID: <1152120296.22623.42.camel@weaponx.rchland.ibm.com> On Wed, 2006-07-05 at 13:12 -0400, seth vidal wrote: > > Hi Everyone, > I was 'elected' in some sense or another however as I promised I am > willing to step down if someone else among those nominated but not > elected wish to take my place. As Christian received the most votes > below the line I'm offering to step down and for him to take my place. > > Everyone cool w/that? Fine with me. josh From mattdm at mattdm.org Wed Jul 5 17:34:13 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Jul 2006 13:34:13 -0400 Subject: FESCo Election Results In-Reply-To: <1152119550.8883.42.camel@cutter> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> Message-ID: <20060705173413.GA8086@jadzia.bu.edu> On Wed, Jul 05, 2006 at 01:12:29PM -0400, seth vidal wrote: > I was 'elected' in some sense or another however as I promised I am > willing to step down if someone else among those nominated but not > elected wish to take my place. As Christian received the most votes > below the line I'm offering to step down and for him to take my place. > Everyone cool w/that? Yes. That's exactly what I presumed the "contingent" comment on the nominations page meant. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From helge.hess at opengroupware.org Wed Jul 5 17:42:02 2006 From: helge.hess at opengroupware.org (Helge Hess) Date: Wed, 5 Jul 2006 19:42:02 +0200 Subject: opengroupware for FE In-Reply-To: <20060705102330.GF1419@neu.nirvana> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> Message-ID: On Jul 5, 2006, at 12:23, Axel Thimm wrote: >> We have released libFoundation 1.1.0 which removes the hack > So gnustep-make can safely use -lobjc instead of -lobjc-lf2 as a > default? Exactly. objc-lf2 can be dropped completely. >> and adds a preliminary x86_64 port (seems to work fine but is not >> well tested ...): >> >> http://svn.opengroupware.org/ThirdParty/releases/ >> libFoundation-1.1.0/ >> >> We'll work on packaging it (including RPMs and tarballs) ASAP but >> maybe you want to look into this as well for your Fedora package. > > I'd prefer using a released tarball otherwise it will make the review > process much harder (the reviewer is supposed to check the sources). > > Even if it sounds silly, can you please just officially upload the > tarball to a permanent URL? Thanks! The tarballs are automagically generated by our build system, once per day. Its up in the meantime: http://download.opengroupware.org/nightly/sources/releases/ libFoundation-1.1.0-r144.tar.gz Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From helge.hess at opengroupware.org Wed Jul 5 17:48:02 2006 From: helge.hess at opengroupware.org (Helge Hess) Date: Wed, 5 Jul 2006 19:48:02 +0200 Subject: opengroupware for FE In-Reply-To: <1152096783.30969.328.camel@xpc.home.erwinrol.com> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> <1152096783.30969.328.camel@xpc.home.erwinrol.com> Message-ID: On Jul 5, 2006, at 12:53, Erwin Rol wrote: > The next step would be sope, Helge is there any magic going on in > sope, > or is that just a matter of packaging the latest release tarball. Should be the latter. But I suggest waiting for the next SOPE release (4.5.8) which I expect on Friday or on the weekend. For me its a clean compile on SuSE 10.0, x86_64: ./configure make Well, the only thing which might be tricky is the Apache module (mod_ngobjweb) which currently requires patches to compile with Apache 2.2. BTW: OGo trunk now works on x86_64. It probably has some 64bit related bugs, but so far I haven't discovered anything obvious. > Like > Axel mentioned working from a non tarball makes things a bit hard > (local > testing would work of course). As mentioned the build system automatically generates tarballs of all repositories: http://download.opengroupware.org/nightly/sources/ It just has a lag of up to 24h ;-) Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From fedora at leemhuis.info Wed Jul 5 17:50:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Jul 2006 19:50:28 +0200 Subject: "contingent" (was Re: FESCo Election Results) In-Reply-To: <20060705173413.GA8086@jadzia.bu.edu> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <20060705173413.GA8086@jadzia.bu.edu> Message-ID: <44ABFBE4.1010303@leemhuis.info> Matthew Miller schrieb: > On Wed, Jul 05, 2006 at 01:12:29PM -0400, seth vidal wrote: >> I was 'elected' in some sense or another however as I promised I am >> willing to step down if someone else among those nominated but not >> elected wish to take my place. As Christian received the most votes >> below the line I'm offering to step down and for him to take my place. >> Everyone cool w/that? > Yes. That's exactly what I presumed the "contingent" comment on the > nominations page meant. Just my 2 cent: Yes, that's what the "contingent" comment means in general. But from my point of view those three are still free to join FESCo -- e.g. if one of them says "Hey, I got so many votes, it seems people really want me to do the job" then I think they should do the job if they want to. CU thl From tibbs at math.uh.edu Wed Jul 5 17:50:42 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 05 Jul 2006 12:50:42 -0500 Subject: Opinions on the election In-Reply-To: <44ABD9A7.2040306@leemhuis.info> (Thorsten Leemhuis's message of "Wed, 05 Jul 2006 17:24:23 +0200") References: <44ABCDFF.8030609@fedoraproject.org> <44ABD9A7.2040306@leemhuis.info> Message-ID: >>>>> "TL" == Thorsten Leemhuis writes: TL> "Total Ballots: 69" (we have round about 270 people that were TL> permitted to vote) looks a bit sad IMHO. I don't see it as a problem, although I think it would be interesting to know why people chose not to vote. Was the election not advertised sufficiently?: Was the voting process too difficult? Is there a perception that votes don't matter, or that FESCo doesn't matter? - J< From skvidal at linux.duke.edu Wed Jul 5 17:59:49 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 13:59:49 -0400 Subject: Opinions on the election In-Reply-To: References: <44ABCDFF.8030609@fedoraproject.org> <44ABD9A7.2040306@leemhuis.info> Message-ID: <1152122389.8883.50.camel@cutter> On Wed, 2006-07-05 at 12:50 -0500, Jason L Tibbitts III wrote: > >>>>> "TL" == Thorsten Leemhuis writes: > > TL> "Total Ballots: 69" (we have round about 270 people that were > TL> permitted to vote) looks a bit sad IMHO. > > I don't see it as a problem, although I think it would be interesting > to know why people chose not to vote. Was the election not advertised > sufficiently?: Was the voting process too difficult? Is there a > perception that votes don't matter, or that FESCo doesn't matter? maybe it is that only 69 people are involved in extras anymore despite there being many more people who have commit access... that'd be worrisome. -sv From chris.stone at gmail.com Wed Jul 5 17:56:35 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 10:56:35 -0700 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <8460.192.54.193.53.1152088993.squirrel@rousalka.dyndns.org> References: <1152079490.23468.0.camel@rousalka.dyndns.org> <44AB5E2D.8060707@feuerpokemon.de> <8460.192.54.193.53.1152088993.squirrel@rousalka.dyndns.org> Message-ID: On 7/5/06, Nicolas Mailhot wrote: > Thank your for the testing. > Problem reported as > https://bugs.freedesktop.org/show_bug.cgi?id=7426 I put up a sample page here: http://tkmame.retrogames.com/fedora-extras/arrows.html Firefox will render the glyph as an up arrow when E9; is used. However simply highlighting the arrows and pasting to a window here: ???? works fine (the last arrow points down). My guess is that this is a firefox bug, but a very strange one at that. From bugs.michael at gmx.net Wed Jul 5 17:59:04 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 5 Jul 2006 19:59:04 +0200 Subject: Leaving - Re: FESCo Election Results In-Reply-To: <1152119550.8883.42.camel@cutter> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> Message-ID: <20060705195904.eddbfd03.bugs.michael@gmx.net> On Wed, 05 Jul 2006 13:12:29 -0400, seth vidal wrote: > On Wed, 2006-07-05 at 09:34 -0500, Mike McGrath wrote: > > Below are the election results for the recent FESCo Election. I'd > > encourage another person to verify these results. The cutoff line was 13. > > > > Votes | Human_name | Fedora_account_id > > > > 61 Tom Callaway 100061 > > 60 Jeremy Katz 100036 > > 57 Thorsten Leemhuis 100066 > > 56 Ville Skytta 100055 > > 53 Rex Dieter 100082 > > 50 Michael Schwendt 100044 > > 49 Jason Tibbitts 100158 > > 44 Warren Togami 100073 > > 41 Seth Vidal 100059 > > 38 Toshio Ernie Kuratomi 100068 > > 33 Joshua W. Boyer 100115 > > 32 Dennis Gilmore 100103 > > 31 Andreas Bierfert 100011 > > --------------------------------------- > > 30 Christian Iseli 100114 > > 28 Brian Pepple 100012 > > 25 Michael J Knox 100390 > > 25 Kevin Fenzi 100037 > > 17 Jose Pedro Oliveira 100033 > > > > > > Hi Everyone, > I was 'elected' in some sense or another however as I promised I am > willing to step down if someone else among those nominated but not > elected wish to take my place. As Christian received the most votes > below the line I'm offering to step down and for him to take my place. > > Everyone cool w/that? > > -sv > > Same here. I already acknowledged it in private mail, but was asked to announce it publicly. Brian Pepple, who has the second highest number of votes of the people below the line, may take my place. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Wed Jul 5 18:01:23 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 05 Jul 2006 13:01:23 -0500 Subject: "contingent" (was Re: FESCo Election Results) In-Reply-To: <44ABFBE4.1010303@leemhuis.info> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <20060705173413.GA8086@jadzia.bu.edu> <44ABFBE4.1010303@leemhuis.info> Message-ID: <1152122483.22623.47.camel@weaponx.rchland.ibm.com> On Wed, 2006-07-05 at 19:50 +0200, Thorsten Leemhuis wrote: > > Matthew Miller schrieb: > > On Wed, Jul 05, 2006 at 01:12:29PM -0400, seth vidal wrote: > >> I was 'elected' in some sense or another however as I promised I am > >> willing to step down if someone else among those nominated but not > >> elected wish to take my place. As Christian received the most votes > >> below the line I'm offering to step down and for him to take my place. > >> Everyone cool w/that? > > Yes. That's exactly what I presumed the "contingent" comment on the > > nominations page meant. > > Just my 2 cent: Yes, that's what the "contingent" comment means in > general. But from my point of view those three are still free to join > FESCo -- e.g. if one of them says "Hey, I got so many votes, it seems > people really want me to do the job" then I think they should do the job > if they want to. Right. Seth has already said Christian is welcome to his seat. It's up to Michael (S) and Ville to decide if they want to vacate their seats to Brian and Michael (K). josh From chris.stone at gmail.com Wed Jul 5 18:07:26 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 11:07:26 -0700 Subject: RFE: Review Request:
- In-Reply-To: <44ABBC32.9080705@bigpond.net.au> References: <20060705093642.GE1419@neu.nirvana> <44ABBC32.9080705@bigpond.net.au> Message-ID: On 7/5/06, David Timms wrote: > Is there a limit to the length of the summary field ? Some complicated > packages are pretty hard to summarize in a few words ;) I have some fairly lengthy summary fields, for example: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197419 From nicolas.mailhot at laposte.net Wed Jul 5 18:12:30 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 05 Jul 2006 20:12:30 +0200 Subject: Opinions on the election In-Reply-To: <1152122389.8883.50.camel@cutter> References: <44ABCDFF.8030609@fedoraproject.org> <44ABD9A7.2040306@leemhuis.info> <1152122389.8883.50.camel@cutter> Message-ID: <1152123150.3161.14.camel@rousalka.dyndns.org> Le mercredi 05 juillet 2006 ? 13:59 -0400, seth vidal a ?crit : > maybe it is that only 69 people are involved in extras anymore despite > there being many more people who have commit access... No, it was probably more like "they all want more or less the same thing, they seem to be trusted by others, let them have the job - why bother voting". So far FE has been a consensual project with few abrasive personalities. Who's in fesco does not seem to matter (what matters there are suckers willing to take the job). Low stakes election means few voters. -- 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 michael at knox.net.nz Wed Jul 5 18:12:34 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 06 Jul 2006 06:12:34 +1200 Subject: FESCo Election Results In-Reply-To: <44ABCDFF.8030609@fedoraproject.org> References: <44ABCDFF.8030609@fedoraproject.org> Message-ID: <44AC0112.2060101@knox.net.nz> Well Done lads! Michael Mike McGrath wrote: > Below are the election results for the recent FESCo Election. I'd > encourage another person to verify these results. The cutoff line was 13. > Votes | Human_name | Fedora_account_id > > 61 Tom Callaway 100061 > 60 Jeremy Katz 100036 > 57 Thorsten Leemhuis 100066 > 56 Ville Skytta 100055 > 53 Rex Dieter 100082 > 50 Michael Schwendt 100044 > 49 Jason Tibbitts 100158 > 44 Warren Togami 100073 > 41 Seth Vidal 100059 > 38 Toshio Ernie Kuratomi 100068 > 33 Joshua W. Boyer 100115 > 32 Dennis Gilmore 100103 > 31 Andreas Bierfert 100011 > --------------------------------------- > 30 Christian Iseli 100114 > 28 Brian Pepple 100012 > 25 Michael J Knox 100390 > 25 Kevin Fenzi 100037 > 17 Jose Pedro Oliveira 100033 > > > Total Votes: 730 > Total Ballots: 69 > > > -Mike > From toshio at tiki-lounge.com Wed Jul 5 18:14:24 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 05 Jul 2006 11:14:24 -0700 Subject: FESCo Election Results In-Reply-To: <1152119550.8883.42.camel@cutter> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> Message-ID: <1152123264.24961.63.camel@localhost> On Wed, 2006-07-05 at 13:12 -0400, seth vidal wrote: > Hi Everyone, > I was 'elected' in some sense or another however as I promised I am > willing to step down if someone else among those nominated but not > elected wish to take my place. As Christian received the most votes > below the line I'm offering to step down and for him to take my place. > > Everyone cool w/that? Yes and no. We really should have discussed this case a bit more before the elections but it slipped my mind and apparently everyone else's as well. You can't have an election if there's no one to vote for. You can't have a good election if there's no one to vote against. Without having sufficiently more candidates on the ballot than open seats to fill, there's really no choice being given to the voters. In this particular election we had 18 candidates and 13 seats. If the three who made their candidacy contingent step down, then this election really only decided the outcome for two seats rather than making a difference for five seats and five platforms (over a third of FESCo as opposed to less than a sixth.) Additionally, each of the three candidates who made their candidacy contingent fell within the top half of vote getters. This tells me that there is pretty strong support to having these people sit on FESCo and make decisions. If all three of the candidates who conditionalized their candidacy step down, then I think we're doing the people who made an effort to vote a disservice as they made a conscious choice to elect them to this position. On the other hand, the candidates themselves know how much time they have and what contributions they're making to Fedora outside of FESCo so if they feel they cannot do the job at present they are best qualified to make that decision. I would encourage them to think hard on the decision first, though, and not feel that they must step down because they initially made their candidacy contingent on the number of candidates to step forward. -Toshio P.S. If any of the candidates do feel honor bound to let someone further down the chain in but feel they have the time to continue doing the job I fell below the top 50% of the vote and would be happy to give my spot to *any* one of them. -------------- 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 shahms at shahms.com Wed Jul 5 18:18:59 2006 From: shahms at shahms.com (Shahms King) Date: Wed, 05 Jul 2006 11:18:59 -0700 Subject: python-psycopg2 package spec In-Reply-To: <44ABCFA7.4060207@shahms.com> References: <44ABCFA7.4060207@shahms.com> Message-ID: <44AC0293.4040300@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Shahms King wrote: > Troels Arvin wrote: >>> Hello, >>> >>> At http://troels.arvin.dk/code/psycopg2/rpm/python-psycopg2.spec I've put >>> a spec-file for a "python-psycopg2" package. The spec-file is modified >>> from the spec-file in >>> http://fedoraproject.org/extras/development/SRPMS/python-psycopg-1.1.21-4.fc5.src.rpm >>> >>> An rpm from the spec-file has been tested on my x86_64 installation and >>> seems to work well. >>> >>> I considered adding a "Conflicts: python-psycopg", but it seems that there >>> is no conflict in having both python-psycopg and python-psycopg2. >>> > > The psycopg2 package doesn't conflict with psycopg as the names have > changed. Additionally, psycopg2 provides a backwards compatibility > module. I'm not sure how complete the back-compat is and am simply > waiting for psycopg2 to get out of beta before packaging it. Due to the > upstream name change, there are some minor administrative questions > about packaging the new package as well as determining how to deal with > backwards compatibility. It's on my list, just not terribly high > priority until psycopg2 is out of beta. I spoke too soon. It appears as though psycopg2 is finally out of beta and I will get on packaging it ASAP. The administrative issues involving the upgrade path still remain, but I will resolve those and work on psycopg2 packages soon. - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFErAKT/qs2NkWy11sRAvH+AKCYNvI8Ud6qNmugGxYJmSNCW+3UtACfcAUk LkjTm4rsovIquP6RU/keQlQ= =TZLk -----END PGP SIGNATURE----- From nicolas.mailhot at laposte.net Wed Jul 5 18:21:33 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 05 Jul 2006 20:21:33 +0200 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: References: <1152079490.23468.0.camel@rousalka.dyndns.org> <44AB5E2D.8060707@feuerpokemon.de> <8460.192.54.193.53.1152088993.squirrel@rousalka.dyndns.org> Message-ID: <1152123693.3161.19.camel@rousalka.dyndns.org> Le mercredi 05 juillet 2006 ? 10:56 -0700, Christopher Stone a ?crit : > On 7/5/06, Nicolas Mailhot wrote: > > Thank your for the testing. > > Problem reported as > > https://bugs.freedesktop.org/show_bug.cgi?id=7426 > > I put up a sample page here: > http://tkmame.retrogames.com/fedora-extras/arrows.html > > Firefox will render the glyph as an up arrow when E9; is used. > However simply highlighting the arrows and pasting to a window here: > ???? works fine (the last arrow points down). > > My guess is that this is a firefox bug, but a very strange one at that. It's strange, it renders fine here and all my apps use DejaVu as default. Maybe you could use CSS on your page to force use of DejaVu so we're sure your browser is not substituting some other broken font. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From michael at knox.net.nz Wed Jul 5 18:23:10 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 06 Jul 2006 06:23:10 +1200 Subject: next FESCo meeting agenda. In-Reply-To: <44AB8190.1080900@leemhuis.info> References: <44AB69CD.8000607@knox.net.nz> <44AB8190.1080900@leemhuis.info> Message-ID: <44AC038E.9090608@knox.net.nz> Thorsten Leemhuis wrote: > > Michael J. Knox schrieb: >> Can this proposed policy be discussed in the next FESCo meeting? >> >> http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy >> >> There has been no (apparent) opposition to the policy. >> >> The meetings happen at 5am (my time) and while I will make an attempt to >> be present to push this myself, it would be cool if it could be on the >> agenda even if I am not present. > > I added it to the schedule -- but this thursday is the first meeting > after the FESCo election (*1) and I'm not sure if we have enough time to > go through the regular schedule in the meeting so it might have to wait > another week. > Then perhaps it should be left off for the next meeting? Thanks Michael From ville.skytta at iki.fi Wed Jul 5 18:27:53 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 05 Jul 2006 21:27:53 +0300 Subject: "contingent" (was Re: FESCo Election Results) In-Reply-To: <44ABFBE4.1010303@leemhuis.info> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <20060705173413.GA8086@jadzia.bu.edu> <44ABFBE4.1010303@leemhuis.info> Message-ID: <1152124073.2728.149.camel@localhost.localdomain> On Wed, 2006-07-05 at 19:50 +0200, Thorsten Leemhuis wrote: > Matthew Miller schrieb: > On Wed, Jul 05, 2006 at 01:12:29PM -0400, seth vidal wrote: > >> I was 'elected' in some sense or another however as I promised I am > >> willing to step down if someone else among those nominated but not > >> elected wish to take my place. As Christian received the most votes > >> below the line I'm offering to step down and for him to take my place. > >> Everyone cool w/that? > > Yes. That's exactly what I presumed the "contingent" comment on the > > nominations page meant. > > Just my 2 cent: Yes, that's what the "contingent" comment means in > general. Not being a native English speaker nor familiar with that word before the initial discussions about the election, my understanding of it is based on http://www.m-w.com/dictionary/contingent which seems to me to leave more things open than the interpretation above... > But from my point of view those three are still free to join > FESCo -- e.g. if one of them says "Hey, I got so many votes, it seems > people really want me to do the job" then I think they should do the job > if they want to. ...and after some consideration, that would be me. Because it looks like I can find enough time to make myself useful, dropping out now would not seem fair towards the voters, so I'll stick around for this round. Thanks and sorry ;) From skvidal at linux.duke.edu Wed Jul 5 18:34:15 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 14:34:15 -0400 Subject: "contingent" (was Re: FESCo Election Results) In-Reply-To: <1152124073.2728.149.camel@localhost.localdomain> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <20060705173413.GA8086@jadzia.bu.edu> <44ABFBE4.1010303@leemhuis.info> <1152124073.2728.149.camel@localhost.localdomain> Message-ID: <1152124455.8883.53.camel@cutter> On Wed, 2006-07-05 at 21:27 +0300, Ville Skytt? wrote: > ...and after some consideration, that would be me. Because it looks > like I can find enough time to make myself useful, dropping out now > would not seem fair towards the voters, so I'll stick around for this > round. Thanks and sorry ;) Or given how highly you ranked in the list we should call them: Your adoring fans. :-D -sv From mailinglists at erwinrol.com Wed Jul 5 18:33:50 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 05 Jul 2006 20:33:50 +0200 Subject: opengroupware for FE In-Reply-To: References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> <1152096783.30969.328.camel@xpc.home.erwinrol.com> Message-ID: <1152124431.30969.334.camel@xpc.home.erwinrol.com> On Wed, 2006-07-05 at 19:48 +0200, Helge Hess wrote: > On Jul 5, 2006, at 12:53, Erwin Rol wrote: > > The next step would be sope, Helge is there any magic going on in > > sope, > > or is that just a matter of packaging the latest release tarball. > > Should be the latter. But I suggest waiting for the next SOPE release > (4.5.8) which I expect on Friday or on the weekend. For me its a > clean compile on SuSE 10.0, x86_64: > ./configure > make That sounds good :-) > Well, the only thing which might be tricky is the Apache module > (mod_ngobjweb) which currently requires patches to compile with > Apache 2.2. Hmmm is this module really needed, i saw some info on using things like mod_proxy instead ? > BTW: OGo trunk now works on x86_64. It probably has some 64bit > related bugs, but so far I haven't discovered anything obvious. Well if things end up in FE there surely will be more ppl testing things on "weird" 64bit platforms like S390 and find more bugs :-) - Erwin From michael at knox.net.nz Wed Jul 5 18:35:21 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 06 Jul 2006 06:35:21 +1200 Subject: next FESCo meeting agenda. In-Reply-To: <20060705104556.GB4619@free.fr> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <20060705115116.83628f34.bugs.michael@gmx.net> <20060705104556.GB4619@free.fr> Message-ID: <44AC0669.5030806@knox.net.nz> Patrice Dumas wrote: >>> I also think that a maintainer should not be considered AWOL when he has >>> shown some activity in a package or other packages even if he doesn't >>> respond to some bugs in a particular package. If he is still active in >>> other parts of fedora extras, maybe it could be the sponsor responsibility >>> to try to come to an agreement. >> This is troublesome. It would need a specific example to explain why a maintainer >> _is active_ but doesn't respond to an issue with one of his packages which causes >> other people to demand action. > > Imagine that a maintainer is active on package foo but doesn't respond on > issues about pakage bar. It is not clear, in the AWOL policy whether the > AWOL procedure should be started or not. I believe it shouldn't, but instead > his sponsor may be contacted, and the issue sorted out with his help, or > escalated to FESCO as you say below. The proposed AWOL policy states that the time line is 3 weeks. This is plenty of time for a FE package to make a comment. If a FE package can not comment on a bug report for 3 weeks, then ignore the public take over request that is approved by FESCo... then we have a problem that is out side the scope of the proposed policy. >>> against newer library version. I don't think it would be right to allow >>> people to bug maintainers for minor/wrong issues and then start the AWOL >>> procedure. >> It's called "common sense". But it is not easy to define. What may be a minor >> defect in your point of view, could be considered a serious defect by other >> users or packagers. > > In the current proposal, it isn't said that only serious defects qualify > for launching the AWOL procedure. Define serious? Capture all possible definitions. What is serious to me may not be serious to you. As Michael said, common sense is required. As I have seen so far, the FE maitainers have plenty of this. >> So, assuming that the AWOL procedure is not started too often, it would be > > That's what I think should be avoided by providing enough guidelines. This is *why* FESCo is required to approve the final step! There are way too many "what if's" and "but then" to capture. Common sense is needed. Thanks Mihcael From michael at knox.net.nz Wed Jul 5 18:36:22 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 06 Jul 2006 06:36:22 +1200 Subject: next FESCo meeting agenda. In-Reply-To: <1152099938.22623.15.camel@weaponx.rchland.ibm.com> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <1152089341.3496.126.camel@T7.Linux> <1152099938.22623.15.camel@weaponx.rchland.ibm.com> Message-ID: <44AC06A6.6020103@knox.net.nz> Josh Boyer wrote: > Yes, fixed time limits are hard to do. I had a situation a while ago > were 2 weeks would not have been enough, so I would suggest something a > bit longer. > Lucky this is 3 weeks ;-) Michael From tcallawa at redhat.com Wed Jul 5 18:55:16 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 05 Jul 2006 13:55:16 -0500 Subject: For wishlist: KeyTouch In-Reply-To: <44ABB8CC.8050906@kymp.net> References: <44ABB8CC.8050906@kymp.net> Message-ID: <1152125716.16687.125.camel@localhost.localdomain> On Wed, 2006-07-05 at 16:04 +0300, Riku Sepp?l? wrote: > Hello > > Not sure if this is the right place to ask, but I wish this I could see > this on Fedora Extras someday. > I think it could be very usefull for many desktop users and would make > Fedora more user friendly. > > KeyTouch http://keytouch.sourceforge.net/ > > About keyTouch > KeyTouch is a program which allows you to easily configure the extra > function keys of your keyboard. > This means that you can define, for every individual function key, what > to do if it is pressed. I whipped up a FC5+ package for this, but I'm hesitant to own it, as I really don't have any need for this right now. Perhaps an existing contributor might pick this up and drive it? http://www.auroralinux.org/people/spot/review/keytouch-2.2.0-0.1.beta3.src.rpm http://www.auroralinux.org/people/spot/review/keytouch.spec ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From chris.stone at gmail.com Wed Jul 5 19:05:49 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 12:05:49 -0700 Subject: For wishlist: KeyTouch In-Reply-To: <1152125716.16687.125.camel@localhost.localdomain> References: <44ABB8CC.8050906@kymp.net> <1152125716.16687.125.camel@localhost.localdomain> Message-ID: On 7/5/06, Tom 'spot' Callaway wrote: > http://www.auroralinux.org/people/spot/review/keytouch-2.2.0-0.1.beta3.src.rpm > http://www.auroralinux.org/people/spot/review/keytouch.spec Why are you adding pkgconfig to the BuildRequires? This should be picked up by the -devel packages. From chris.stone at gmail.com Wed Jul 5 19:16:13 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 12:16:13 -0700 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <1152123693.3161.19.camel@rousalka.dyndns.org> References: <1152079490.23468.0.camel@rousalka.dyndns.org> <44AB5E2D.8060707@feuerpokemon.de> <8460.192.54.193.53.1152088993.squirrel@rousalka.dyndns.org> <1152123693.3161.19.camel@rousalka.dyndns.org> Message-ID: On 7/5/06, Nicolas Mailhot wrote: > It's strange, it renders fine here and all my apps use DejaVu as > default. Maybe you could use CSS on your page to force use of DejaVu so > we're sure your browser is not substituting some other broken font. I mucked around with my font settings in firefox and changed them to DejuVu and it is rendering properly now. Thanks for your help! :) From j.w.r.degoede at hhs.nl Wed Jul 5 19:20:10 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 05 Jul 2006 21:20:10 +0200 Subject: Opinions on the election In-Reply-To: <1152123150.3161.14.camel@rousalka.dyndns.org> References: <44ABCDFF.8030609@fedoraproject.org> <44ABD9A7.2040306@leemhuis.info> <1152122389.8883.50.camel@cutter> <1152123150.3161.14.camel@rousalka.dyndns.org> Message-ID: <44AC10EA.5070509@hhs.nl> Nicolas Mailhot wrote: > Le mercredi 05 juillet 2006 ? 13:59 -0400, seth vidal a ?crit : > >> maybe it is that only 69 people are involved in extras anymore despite >> there being many more people who have commit access... > > No, it was probably more like "they all want more or less the same > thing, they seem to be trusted by others, let them have the job - why > bother voting". So far FE has been a consensual project with few > abrasive personalities. Who's in fesco does not seem to matter (what > matters there are suckers willing to take the job). > > Low stakes election means few voters. > > Yes, I myself thought of not voting because of this, but I've been deducated that its my democratic obligation to vote :) Regards, Hans From tcallawa at redhat.com Wed Jul 5 19:38:51 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 05 Jul 2006 14:38:51 -0500 Subject: For wishlist: KeyTouch In-Reply-To: References: <44ABB8CC.8050906@kymp.net> <1152125716.16687.125.camel@localhost.localdomain> Message-ID: <1152128332.16687.128.camel@localhost.localdomain> On Wed, 2006-07-05 at 12:05 -0700, Christopher Stone wrote: > On 7/5/06, Tom 'spot' Callaway wrote: > > http://www.auroralinux.org/people/spot/review/keytouch-2.2.0-0.1.beta3.src.rpm > > http://www.auroralinux.org/people/spot/review/keytouch.spec > > Why are you adding pkgconfig to the BuildRequires? This should be > picked up by the -devel packages. You're right, that is a BR that can be safely removed. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From michael at knox.net.nz Wed Jul 5 19:42:59 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 06 Jul 2006 07:42:59 +1200 Subject: For wishlist: KeyTouch In-Reply-To: <1152125716.16687.125.camel@localhost.localdomain> References: <44ABB8CC.8050906@kymp.net> <1152125716.16687.125.camel@localhost.localdomain> Message-ID: <44AC1643.4090003@knox.net.nz> Tom 'spot' Callaway wrote: > On Wed, 2006-07-05 at 16:04 +0300, Riku Sepp?l? wrote: > >>Hello >> >>Not sure if this is the right place to ask, but I wish this I could see >>this on Fedora Extras someday. >>I think it could be very usefull for many desktop users and would make >>Fedora more user friendly. >> >>KeyTouch http://keytouch.sourceforge.net/ >> >>About keyTouch >>KeyTouch is a program which allows you to easily configure the extra >>function keys of your keyboard. >>This means that you can define, for every individual function key, what >>to do if it is pressed. > > > I whipped up a FC5+ package for this, but I'm hesitant to own it, as I > really don't have any need for this right now. > > Perhaps an existing contributor might pick this up and drive it? > > http://www.auroralinux.org/people/spot/review/keytouch-2.2.0-0.1.beta3.src.rpm > http://www.auroralinux.org/people/spot/review/keytouch.spec > If no one objects, I would take this on.. I am sick of having "dead" keys on my keyboard, would certainly be useful. Michael From peter at thecodergeek.com Wed Jul 5 20:11:27 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 05 Jul 2006 15:11:27 -0500 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <1152079490.23468.0.camel@rousalka.dyndns.org> References: <1152079490.23468.0.camel@rousalka.dyndns.org> Message-ID: <20060705151127.07rjktphmf4wock4@www.thecodergeek.com> On Wed, 05 Jul 2006 08:04:47 +0200, Nicolas Mailhot wrote: > Dear Fedora user, > > A new font family is being proposed as the Fedora Core default. It > probably impacts your language. Please tell us what you think about it: > > http://fedoraproject.org/wiki/Fonts/DejavuFeedbackCall > > Happy testing! > I've been setting DejaVu as my preferred font in virtually every desktop application I use since it was first mentioned to me several months ago; and I must say that I think it's fantastic. It covers all the glyphs I use in both en_US (US English) and es (Spanish) locales and - so far as I can tell - also covers most of everything else I come across such as people that I know ranting to me in German (de). (I don't understand much of what they're saying, but the glyphs render nicely! ~_^) It's also *much* clearer than the prior default fonts in Fedora and a couple of other distros that I've tried. I'm running on a 17" Amptron CRT at 1400x1050 and 111 DPI (4:3 aspect), on a Radeon 9250 with EXA and the as-shipped Fedora X.org/Mesa/DRI stuff. An older screenshot of my font preferences[1] is available and its shown values are still in use on my system. I'm also using the standard Fedora freetype build. [1] http://thecodergeek.com/images/screenshot-fonts.png -- Peter Gordon (codergeek42) This message was sent through a webmail interface, thus has no digital signature. From helge.hess at opengroupware.org Wed Jul 5 20:19:08 2006 From: helge.hess at opengroupware.org (Helge Hess) Date: Wed, 5 Jul 2006 22:19:08 +0200 Subject: opengroupware for FE In-Reply-To: <1152124431.30969.334.camel@xpc.home.erwinrol.com> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> <1152096783.30969.328.camel@xpc.home.erwinrol.com> <1152124431.30969.334.camel@xpc.home.erwinrol.com> Message-ID: On Jul 5, 2006, at 20:33, Erwin Rol wrote: >> Well, the only thing which might be tricky is the Apache module >> (mod_ngobjweb) which currently requires patches to compile with >> Apache 2.2. > Hmmm is this module really needed, Yes. > i saw some info on using things like mod_proxy instead ? Not recommended (just like directly connecting OGo on its HTTP port). >> BTW: OGo trunk now works on x86_64. It probably has some 64bit >> related bugs, but so far I haven't discovered anything obvious. > Well if things end up in FE there surely will be more ppl testing > things > on "weird" 64bit platforms like S390 and find more bugs :-) Is S390 Linux 64bit now? Last time I compiled OGo on such a machine the Linux was 31/32bit. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From Christian.Iseli at licr.org Wed Jul 5 20:35:21 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 05 Jul 2006 22:35:21 +0200 Subject: FESCo Election Results In-Reply-To: Your message of "Wed, 05 Jul 2006 13:12:29 EDT." <1152119550.8883.42.camel@cutter> Message-ID: <200607052035.k65KZMLR019945@mx1.redhat.com> skvidal at linux.duke.edu said: > As Christian received the most votes below the line I'm offering to step down > and for him to take my place. Time will tell whether I (and the rest of the extras contributors, for that matter) should thank you or curse you :-) Seeing the other mails in f-e-l and after a little chat on IRC, I'll accept Seth's proposition. Thanks, and cheers, Christian From skvidal at linux.duke.edu Wed Jul 5 20:41:22 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 16:41:22 -0400 Subject: FESCo Election Results In-Reply-To: <200607052035.k65KZMLR019945@mx1.redhat.com> References: <200607052035.k65KZMLR019945@mx1.redhat.com> Message-ID: <1152132082.8883.68.camel@cutter> On Wed, 2006-07-05 at 22:35 +0200, Christian.Iseli at licr.org wrote: > skvidal at linux.duke.edu said: > > As Christian received the most votes below the line I'm offering to step down > > and for him to take my place. > > Time will tell whether I (and the rest of the extras contributors, for that > matter) should thank you or curse you :-) > > Seeing the other mails in f-e-l and after a little chat on IRC, I'll accept > Seth's proposition. > Thanks Christian! good luck (you're gonna need it ;) -sv From mailinglists at erwinrol.com Wed Jul 5 20:36:55 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 05 Jul 2006 22:36:55 +0200 Subject: opengroupware for FE In-Reply-To: References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> <1152096783.30969.328.camel@xpc.home.erwinrol.com> <1152124431.30969.334.camel@xpc.home.erwinrol.com> Message-ID: <1152131815.30969.339.camel@xpc.home.erwinrol.com> On Wed, 2006-07-05 at 22:19 +0200, Helge Hess wrote: > On Jul 5, 2006, at 20:33, Erwin Rol wrote: > >> Well, the only thing which might be tricky is the Apache module > >> (mod_ngobjweb) which currently requires patches to compile with > >> Apache 2.2. > > Hmmm is this module really needed, > > Yes. > > > i saw some info on using things like mod_proxy instead ? > > Not recommended (just like directly connecting OGo on its HTTP port). OK so a RPM for the mod_ngobjweb is needed too, and well for the apache version that comes with Fedora Core. > >> BTW: OGo trunk now works on x86_64. It probably has some 64bit > >> related bugs, but so far I haven't discovered anything obvious. > > Well if things end up in FE there surely will be more ppl testing > > things > > on "weird" 64bit platforms like S390 and find more bugs :-) > > Is S390 Linux 64bit now? Last time I compiled OGo on such a machine > the Linux was 31/32bit. Used to be s390 31/32bit and s390x 64bit, but they are merged now, AFAIK. But anyway its a platform that not everybody has at home, like a AMD64 :-) - Erwin From Christian.Iseli at licr.org Wed Jul 5 20:54:07 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 05 Jul 2006 22:54:07 +0200 Subject: FE Package Status of Jul 5, 2006 In-Reply-To: Your message of "Wed, 05 Jul 2006 11:52:26 CDT." Message-ID: <200607052054.k65Ks7oW027513@mx1.redhat.com> rdieter at math.unl.edu said: > What extra "news" is required? Go into the CVS devel directory, "cvs remove" all the files, create a dead.package file and "cvs add" it ... That's the standard procedure for retired packages... Cheers, Christian From opensource at till.name Wed Jul 5 21:50:41 2006 From: opensource at till.name (Till Maas) Date: Wed, 05 Jul 2006 23:50:41 +0200 Subject: Packaging/Guidelines - Usage of %{optflags}, Source tag Message-ID: <200607052350.42005.opensource@till.name> Hiyas, at this time the Packaging-Guidelines do not mention whether or not %{optflags} should / must be used. They are used everytime %configure is executed, but there are also packages that do not have a ./configure script and for this reason would not use the %{optflags}. The flags in %{optflags} contain not only optimization but also security flags. For this reason I suggest that the Guidelines state that they have to be used. This will also help new contributors to know about this. As well the Guidelines do not mention that the Source tag with upstream source should be a url / downloadable. Maybe this can be added, too. Regards, Till From pertusus at free.fr Wed Jul 5 22:01:11 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 6 Jul 2006 00:01:11 +0200 Subject: Packaging/Guidelines - Usage of %{optflags}, Source tag In-Reply-To: <200607052350.42005.opensource@till.name> References: <200607052350.42005.opensource@till.name> Message-ID: <20060705220111.GH5078@free.fr> On Wed, Jul 05, 2006 at 11:50:41PM +0200, Till Maas wrote: > Hiyas, > > at this time the Packaging-Guidelines do not mention whether or > not %{optflags} should / must be used. They are used everytime %configure is > executed, but there are also packages that do not have a ./configure script > and for this reason would not use the %{optflags}. The flags in %{optflags} > contain not only optimization but also security flags. For this reason I > suggest that the Guidelines state that they have to be used. This will also > help new contributors to know about this. I was persuaded that it was in the Guidelines. I all the reviews I have seen, not using the optflags (with configure or not) was a blocker (there may be valid exceptions though when it is too complicated for example, for example in the cernlib). > As well the Guidelines do not mention that the Source tag with upstream source > should be a url / downloadable. Maybe this can be added, too. Sometimes it is not practical. For example if the upstream source isn't versionned, it may be convenient to rename the file by appending a version string, and leave the upsteam source within comments, for example like (taken from tetex-tex4ht): # renamed to tex4ht-all-YYYYMMDD.zip - based on last timestamp in directory Source1: tex4ht-all-20050228.zip # unversioned upstream source, downloaded with wget -N #Source1 http://www.cse.ohio-state.edu/~gurari/TeX4ht/tex4ht-all.zip Another example is when the upstream source has disappeared and the latest available is within something else, for example in a src.rpm. Admitedly these are exceptions. -- Pat From seg at haxxed.com Thu Jul 6 00:42:02 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 05 Jul 2006 19:42:02 -0500 Subject: FESCo Election Results In-Reply-To: <1152123264.24961.63.camel@localhost> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <1152123264.24961.63.camel@localhost> Message-ID: <1152146523.2975.7.camel@localhost> Is there any chance that someone with access to the data could apply a Proportional Approval Vote to it? Described here: http://en.wikipedia.org/wiki/Proportional_approval_voting It would be interesting to see how/if the results differ. Also I question the "Vote for no more than 13" limit. Approval voting systems don't usually place a limit. -------------- 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 toshio at tiki-lounge.com Thu Jul 6 00:43:31 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 05 Jul 2006 17:43:31 -0700 Subject: next FESCo meeting agenda. In-Reply-To: <20060705115116.83628f34.bugs.michael@gmx.net> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <20060705115116.83628f34.bugs.michael@gmx.net> Message-ID: <1152146611.24961.151.camel@localhost> On Wed, 2006-07-05 at 11:51 +0200, Michael Schwendt wrote: > On Wed, 5 Jul 2006 10:32:36 +0200, Patrice Dumas wrote: > > > On Wed, Jul 05, 2006 at 07:27:09PM +1200, Michael J. Knox wrote: > > > Can this proposed policy be discussed in the next FESCo meeting? > > > > > > http://fedoraproject.org/wiki/MikeKnox/AWOL_Policy > > > > I think that only existing Fedora Contributors should be able to take over > > a package. However the sponsors should consider every contribution to > > fedora extras, including working on AWOL packages for sponsorship. > > This is contradictory. > > With the current sponsorship process, all that is needed to find a sponsor > is to show a good understanding of the packaging [guidelines]. Yes, it may > be too easy for somebody to take an existing src.rpm (CVS checkout), bump > the version or release, present it as an update package for review and be > sponsored. But if it were not possible, the same person could request > review of a trivial new package, find a sponsor that way, and then > proceed to taking over orphans. > > Conclusively, it's a sponsor's decision whether to accept a new contributor > and regardless of what he wants to work on. > > It could also be that somebody writes > > "All the packages I'm interested in are in FE already. But if it is > possible that we can work together on foo and bar, I'd like to offer > my help." > > and a sponsor and package maintainer accepts this without extra steps > or special requirements. > > The general procedure for becoming a Fedora Extras Contributor, however, > is to provide a new package in accordance with the instructions found > in the Wiki. I would like to see another level of Fedora Extras Contributor. Someone previously unsponsored who wants to work on an orphaned package (or potentially orphaned due to AWOL maintainer) could be sponsored as a mentored packager. The mentor would track their mentoree's actions more closely than normal. Watch their cvs commits. Take a hand in watching upstream's changes. Act as co-maintainer for the mentorees packages. This would require someone willing to help other packagers develop to take on partial maintenance of another package but it can be helpful in the long run. Instead of refusing to sponsor a person because of their inexperience, we can lead them to be more productive long-term. In the end, they will be doing good enough work to submit and take-over packages without someone overseeing their work and the mentor can move on to helping someone else. Some ideas for implementing this: 1) The mentoree would have commit rights only to the package they are taking over. 2) The mentor and mentoree would be comaintainers with the mentor being the senior partner (but letting the mentoree make most of the decisions so they can learn.) 3) Eventual sponsorship of the mentored packager should be done by someone other than the mentor. 4) We need tools to make it easier to track the changes made by the mentoree. The implementation may not be possible yet but if the idea of mentors/mentorees is sound we should figure out what needs to be done to create it in a sane manner. Many of the pieces are being worked on currently (package db, accounts system, new version control system) so now is a good time to request features that make this possible. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Thu Jul 6 01:05:39 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 05 Jul 2006 20:05:39 -0500 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: <44ABD9A7.2040306@leemhuis.info> References: <44ABCDFF.8030609@fedoraproject.org> <44ABD9A7.2040306@leemhuis.info> Message-ID: <1152147940.2975.16.camel@localhost> On Wed, 2006-07-05 at 17:24 +0200, Thorsten Leemhuis wrote: > Should we do another election in the future? When? Reelect half of the > seats after FC7 (FC6 is to short)? The other half after FC8, then the > first half again after FC9 (and so forth)? I don't see why we need to do the re-elect half thing. Unless we get twice the number of nominations as available seats, its not even possible to elect a completely new committee. Unless we somehow get far more nominations than we got this time, most existing members are going to remain anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.stone at gmail.com Thu Jul 6 01:14:35 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 18:14:35 -0700 Subject: FESCo Election Results In-Reply-To: <1152146523.2975.7.camel@localhost> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <1152123264.24961.63.camel@localhost> <1152146523.2975.7.camel@localhost> Message-ID: On 7/5/06, Callum Lerwick wrote: > Also I question the "Vote for no more than 13" limit. Approval voting > systems don't usually place a limit. +1 I think a lot of people felt they had to vote for 13 members and voted for people they were unsure about just to fill the 13 number. By not having any limit it is clear to voters that they can vote on as many or as few people as they like. Voting for every member would be the same as not voting at all. From toshio at tiki-lounge.com Thu Jul 6 01:42:14 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 05 Jul 2006 18:42:14 -0700 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: <44ABD9A7.2040306@leemhuis.info> References: <44ABCDFF.8030609@fedoraproject.org> <44ABD9A7.2040306@leemhuis.info> Message-ID: <1152150134.24961.170.camel@localhost> On Wed, 2006-07-05 at 17:24 +0200, Thorsten Leemhuis wrote: > Mike McGrath schrieb: > > Below are the election results for the recent FESCo Election. I'd > > encourage another person to verify these results. The cutoff line was 13. > > Votes | Human_name | Fedora_account_id > > thx for posting the results mmcgrath, thx to the infrastructure team in > general, thx to Toshio and everybody else for programing the voting app > and congrats to all those that got elected. > > But now to the real topic of this mail: What do all of you think about > the whole election. Was it a good idea? Yes. > Or only wasted time? "Total > Ballots: 69" (we have round about 270 people that were permitted to > vote) looks a bit sad IMHO. > No. It sets a precedent that representative governance is the way the Fedora Project is going to be run in the future. > Should we do another election in the future? yes. > When? Reelect half of the > seats after FC7 (FC6 is to short)? The other half after FC8, then the > first half again after FC9 (and so forth)? > Are there going to be other Steering Comittee/Board Elections? If the Fedora Advisory Board starts having elections as well, it might be nice to have less elections at the Steering Comittee level (in terms of voter burnout). > Anything else we should handle differently in the future? I think Contingent Candidates should be handled a bit different as the way we did it this time was a bit confusing. Perhaps encourage the candidates to throw their hat in the ring without contingencies. Perhaps if open seats < number of non-contingent candidates put the contingent candidates in the election and hold them to wherever they end up in the voting; otherwise take them off the ballot entirely. -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 skvidal at linux.duke.edu Thu Jul 6 01:50:51 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Jul 2006 21:50:51 -0400 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: <1152150134.24961.170.camel@localhost> References: <44ABCDFF.8030609@fedoraproject.org> <44ABD9A7.2040306@leemhuis.info> <1152150134.24961.170.camel@localhost> Message-ID: <1152150651.12287.7.camel@cutter> > I think Contingent Candidates should be handled a bit different as the > way we did it this time was a bit confusing. Perhaps encourage the > candidates to throw their hat in the ring without contingencies. > Perhaps if open seats < number of non-contingent candidates put the > contingent candidates in the election and hold them to wherever they end > up in the voting; otherwise take them off the ballot entirely. Well that's how it worked this time - I guess the gist was our names weren't ever taken off the list once enough people had joined. -sv From mattdm at mattdm.org Thu Jul 6 02:21:59 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Jul 2006 22:21:59 -0400 Subject: FESCo Election Results In-Reply-To: References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <1152123264.24961.63.camel@localhost> <1152146523.2975.7.camel@localhost> Message-ID: <20060706022159.GA26575@jadzia.bu.edu> On Wed, Jul 05, 2006 at 06:14:35PM -0700, Christopher Stone wrote: > >Also I question the "Vote for no more than 13" limit. Approval voting > >systems don't usually place a limit. > +1 > I think a lot of people felt they had to vote for 13 members and voted > for people they were unsure about just to fill the 13 number. By not > having any limit it is clear to voters that they can vote on as many > or as few people as they like. Voting for every member would be the > same as not voting at all. If we're going to get all fancy, I'd kind of like to see a "Yes/No/No Opinion" choice. As it is, it's not clear from the lack of a checkmark if I don't care or if I TOTALLY HATE THEM because they don't put version numbers in their changelogs. * * :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From chris.stone at gmail.com Thu Jul 6 02:33:58 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 5 Jul 2006 19:33:58 -0700 Subject: FESCo Election Results In-Reply-To: <20060706022159.GA26575@jadzia.bu.edu> References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <1152123264.24961.63.camel@localhost> <1152146523.2975.7.camel@localhost> <20060706022159.GA26575@jadzia.bu.edu> Message-ID: On 7/5/06, Matthew Miller wrote: > If we're going to get all fancy, I'd kind of like to see a "Yes/No/No > Opinion" choice. As it is, it's not clear from the lack of a checkmark if I > don't care or if I TOTALLY HATE THEM because they don't put version numbers > in their changelogs. * > * :) LOL! So what would happen in this case if 13 members did not get a vote total above zero? Do we elect someone the majority hates? ;-) From jes at martnet.com Thu Jul 6 02:07:42 2006 From: jes at martnet.com (Joe Smith) Date: Wed, 05 Jul 2006 22:07:42 -0400 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <1152079490.23468.0.camel@rousalka.dyndns.org> References: <1152079490.23468.0.camel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > A new font family is being proposed as the Fedora Core default. It > probably impacts your language. Please tell us what you think about it: > > http://fedoraproject.org/wiki/Fonts/DejavuFeedbackCall Sorry, I appreciate the need for wider glyph coverage and the Dejavu set is nice in many visual respects, in small amounts, but I very much prefer the original default face that came with Fedora 5 (Luxi?). My eyesight is not what it used to be and I find the Dejavu fonts very much less readable (seems mostly spacing issues: too "cramped" too "lumpy"). Sorry I can't be any more specific. I installed as suggested: # yum --enablerepo=extras install dejavu-fonts \ dejavu-fonts-experimental dejavu-fonts-makedefault I tried to revert by uninstalling dejavu-fonts-makedefault, but it had no effect. How do I get back to the original default fonts? References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <1152123264.24961.63.camel@localhost> <1152146523.2975.7.camel@localhost> <20060706022159.GA26575@jadzia.bu.edu> Message-ID: <1152160102.12287.23.camel@cutter> On Wed, 2006-07-05 at 22:21 -0400, Matthew Miller wrote: > On Wed, Jul 05, 2006 at 06:14:35PM -0700, Christopher Stone wrote: > > >Also I question the "Vote for no more than 13" limit. Approval voting > > >systems don't usually place a limit. > > +1 > > I think a lot of people felt they had to vote for 13 members and voted > > for people they were unsure about just to fill the 13 number. By not > > having any limit it is clear to voters that they can vote on as many > > or as few people as they like. Voting for every member would be the > > same as not voting at all. > > If we're going to get all fancy, I'd kind of like to see a "Yes/No/No > Opinion" choice. As it is, it's not clear from the lack of a checkmark if I > don't care or if I TOTALLY HATE THEM because they don't put version numbers > in their changelogs. * > > > > * :) you're just lucky I decided to step aside from my duly elected position - otherwise there'd be a new MUST in the guidelines something like: MUST sign up mattdm at mattdm.org for a new spam list before package can be approved. -sv From bugs.michael at gmx.net Thu Jul 6 05:56:40 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 6 Jul 2006 07:56:40 +0200 Subject: next FESCo meeting agenda. In-Reply-To: <1152146611.24961.151.camel@localhost> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <20060705115116.83628f34.bugs.michael@gmx.net> <1152146611.24961.151.camel@localhost> Message-ID: <20060706075640.dfa684d8.bugs.michael@gmx.net> On Wed, 05 Jul 2006 17:43:31 -0700, Toshio Kuratomi wrote: > I would like to see another level of Fedora Extras Contributor. Someone > previously unsponsored who wants to work on an orphaned package (or > potentially orphaned due to AWOL maintainer) could be sponsored as a > mentored packager. Are you convinced that you would find enough people who want an official role that sounds so "uncool"? Long ago we've done something similar occasionally for some time. People with access to CVS and buildsys have forwarded the modifications sent by contributors without access. It is still possible at a limited degree, provided that a sponsor is willing to do it. It doesn't add any security. And it doesn't work smoothly for new packages, btw. (It bears a big risk that the sponsor ends up with orphans) > The mentor would track their mentoree's actions more > closely than normal. What would be "normal"? ;) > Watch their cvs commits. Take a hand in watching > upstream's changes. Act as co-maintainer for the mentorees packages. The majority of contributors want the full show, and quickly. A "Fedora account". Even if they know they will have problems handling some things (like working with the relevant tools). Further, some people sign up quicker than they have an idea what to contribute. It's the old "be part of it" community game without clear activities or contributions. Many more people would sign up for an account if that became possible without needing a sponsor and without actual contributions. It doesn't help Fedora Extras if people are sponsored without contributing anything to the package maintenance. On the contrary, when refusing access to CVS or buildsys for someone who started getting active in bugzilla with a package submission, there would be complaints that it hurts their productivity. But remember, that it is possible to revoke sponsorship. > This would -snip- From fedora at camperquake.de Thu Jul 6 09:04:36 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 6 Jul 2006 11:04:36 +0200 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: References: <1152079490.23468.0.camel@rousalka.dyndns.org> Message-ID: <20060706110436.4e9c5aa3@voip.int.addix.net> Hi. On Wed, 05 Jul 2006 22:07:42 -0400, Joe Smith wrote: > much prefer the original default face that came with Fedora 5 > (Luxi?). My eyesight is not what it used to be and I find the Dejavu > fonts very much less readable (seems mostly spacing issues: too > "cramped" too "lumpy"). Sorry I can't be any more specific. One occassion where I noted this is the combination of T with a smaller letter following (Ta or To, for example). The smaller letter is very close to the T. I used Vera before, and it hat no such issue. From fedora at leemhuis.info Thu Jul 6 11:00:30 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 06 Jul 2006 13:00:30 +0200 Subject: FE Package Status of Jul 5, 2006 In-Reply-To: <200607052054.k65Ks7oW027513@mx1.redhat.com> References: <200607052054.k65Ks7oW027513@mx1.redhat.com> Message-ID: <44ACED4E.1030505@leemhuis.info> Christian.Iseli at licr.org schrieb: > rdieter at math.unl.edu said: >> What extra "news" is required? > Go into the CVS devel directory, "cvs remove" all the files, create a > dead.package file and "cvs add" it ... > > That's the standard procedure for retired packages... Yeah, but that "standard procedure" is not documented probably in the wiki. Could somebody please do that? tia! CU thl From bugs.michael at gmx.net Thu Jul 6 12:32:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 6 Jul 2006 14:32:15 +0200 Subject: FE Package Status of Jul 5, 2006 In-Reply-To: <44ACED4E.1030505@leemhuis.info> References: <200607052054.k65Ks7oW027513@mx1.redhat.com> <44ACED4E.1030505@leemhuis.info> Message-ID: <20060706143215.4e2ab8fb.bugs.michael@gmx.net> On Thu, 06 Jul 2006 13:00:30 +0200, Thorsten Leemhuis wrote: > Christian.Iseli at licr.xxx schrieb: > > rdieter at math.unl.xxx said: > >> What extra "news" is required? > > Go into the CVS devel directory, "cvs remove" all the files, create a > > dead.package file and "cvs add" it ... > > > > That's the standard procedure for retired packages... > > Yeah, but that "standard procedure" is not documented probably in the > wiki. Could somebody please do that? tia! Could you please discuss this at FESCO-level, find out whether the CVS branch script recognises the "dead.package" file. Then it could become the official procedure. Else all dead packages would be branched for FC-6. From fedora at leemhuis.info Thu Jul 6 12:57:30 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 06 Jul 2006 14:57:30 +0200 Subject: FE Package Status of Jul 5, 2006 In-Reply-To: <20060706143215.4e2ab8fb.bugs.michael@gmx.net> References: <200607052054.k65Ks7oW027513@mx1.redhat.com> <44ACED4E.1030505@leemhuis.info> <20060706143215.4e2ab8fb.bugs.michael@gmx.net> Message-ID: <44AD08BA.7090805@leemhuis.info> Michael Schwendt schrieb: > On Thu, 06 Jul 2006 13:00:30 +0200, Thorsten Leemhuis wrote: > >> Christian.Iseli at licr.xxx schrieb: >>> rdieter at math.unl.xxx said: >>>> What extra "news" is required? >>> Go into the CVS devel directory, "cvs remove" all the files, create a >>> dead.package file and "cvs add" it ... >>> That's the standard procedure for retired packages... >> Yeah, but that "standard procedure" is not documented probably in the >> wiki. Could somebody please do that? tia! > Could you please discuss this at FESCO-level, find out whether the CVS > branch script recognises the "dead.package" file. Then it could become > the official procedure. Else all dead packages would be branched for FC-6. Well, is was discussed in FESCo months ago. From http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060323 19:41 < thl> | something else regarding cvs: 19:42 < thl> | we created FC5 branches in CVS for a lot of old packages that are orpahend or obsoleted 19:42 < thl> | should they be deleted? 19:42 < thl> | and the devel branch too? 19:43 < thl> | jeremy, can the devel branch readded easily? 19:44 < jeremy> | thl: probably. and rather than delete the devel branch, possibly just a DEAD_PACKAGE marker 19:44 < jeremy> | the problem with deleting it is that we lose history if it needs to come back 19:44 < thl> | jeremy, k, sounds sane 19:44 < thl> | jeremy, how could a DEAD_PACKAGE marker look like? 19:45 < thl> | jeremy, just a file "dead.package"? 19:45 < thl> | with a short explanation why it's dead in it? 19:45 < jeremy> | works for me :-) 19:45 < thl> | jeremy, the branch script would need to take care that no new branched are created later 19:45 < thl> | but that's probably easy 19:46 < jeremy> | well, allowing an older branch to be made is fine. but not creating it when doing mass-branching is good 19:46 < thl> | jeremy, exactly 19:46 < thl> | k, that was all from my side 19:46 < jeremy> | and the mass-branching is just a giant "for i in ..." script 19:46 < jeremy> | if you get me a list of FC-5 branches which need to be killed, I can do that 19:47 <-- | dgregor has quit (Read error: 110 (Connection timed out)) 19:47 < thl> | jeremy, k, will try to find someone for that task ;-) For me that discussion is enough (especially as the dead.package marker is used already) even if there was no "formal" decision /"voting" on it. Michael, or is there anything else that you'd like to see discussed? Then I'll put it on the schedule. CU thl From dragoran at feuerpokemon.de Thu Jul 6 13:20:35 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 06 Jul 2006 15:20:35 +0200 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <34740.192.54.193.53.1152089424.squirrel@rousalka.dyndns.org> References: <1152079490.23468.0.camel@rousalka.dyndns.org> <44AB5E2D.8060707@feuerpokemon.de> <34740.192.54.193.53.1152089424.squirrel@rousalka.dyndns.org> Message-ID: <44AD0E23.3020901@feuerpokemon.de> Nicolas Mailhot wrote: > Le Mer 5 juillet 2006 08:37, dragoran a ?crit : > > >> I tryed it but for me the default font used in apps (FC5) looks better >> and is easier to read... >> the new fonts look to 'thin' and are harder to read because of this .. >> notes: >> 1) I am using a TFT with a german locale + no subpixel AA, but greyscale >> AA >> 2) I have recompiled the freetypelib with the bytecode interpretter >> enabled >> > > I seem to remember the bytecode interpreter makes DejaVu lighter (and > users of proprietary systems prefer it this way). Can you try it with the > default fedora freetype ? > > I've opened the following ticket. Feel free to complete it > https://bugs.freedesktop.org/show_bug.cgi?id=7427 > > this is marked as wontfix :( using no bytecode interpreter makes other fonts (the ms stuff used on most webpages looks very(!!) ugly what about a dejavu-fonts-bytecodeinterpreter package with fixed fonts for bytecode interpretter users? > Regards, > > From bugs.michael at gmx.net Thu Jul 6 13:42:49 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 6 Jul 2006 15:42:49 +0200 Subject: FE Package Status of Jul 5, 2006 In-Reply-To: <44AD08BA.7090805@leemhuis.info> References: <200607052054.k65Ks7oW027513@mx1.redhat.com> <44ACED4E.1030505@leemhuis.info> <20060706143215.4e2ab8fb.bugs.michael@gmx.net> <44AD08BA.7090805@leemhuis.info> Message-ID: <20060706154249.c5b2bccc.bugs.michael@gmx.net> On Thu, 06 Jul 2006 14:57:30 +0200, Thorsten Leemhuis wrote: > Michael Schwendt schrieb: > > On Thu, 06 Jul 2006 13:00:30 +0200, Thorsten Leemhuis wrote: > > > >> Christian.Iseli at licr.xxx schrieb: > >>> rdieter at math.unl.xxx said: > >>>> What extra "news" is required? > >>> Go into the CVS devel directory, "cvs remove" all the files, create a > >>> dead.package file and "cvs add" it ... > >>> That's the standard procedure for retired packages... > >> Yeah, but that "standard procedure" is not documented probably in the > >> wiki. Could somebody please do that? tia! > > Could you please discuss this at FESCO-level, find out whether the CVS > > branch script recognises the "dead.package" file. Then it could become > > the official procedure. Else all dead packages would be branched for FC-6. > > Well, is was discussed in FESCo months ago. From > > http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060323 > > 19:41 < thl> | something else regarding cvs: > 19:42 < thl> | we created FC5 branches in CVS for a lot of old > packages that are orpahend or obsoleted > 19:42 < thl> | should they be deleted? > 19:42 < thl> | and the devel branch too? > 19:43 < thl> | jeremy, can the devel branch readded easily? > 19:44 < jeremy> | thl: probably. and rather than delete the devel > branch, possibly just a DEAD_PACKAGE marker > 19:44 < jeremy> | the problem with deleting it is that we lose > history if it needs to come back > 19:44 < thl> | jeremy, k, sounds sane > 19:44 < thl> | jeremy, how could a DEAD_PACKAGE marker look like? > 19:45 < thl> | jeremy, just a file "dead.package"? > 19:45 < thl> | with a short explanation why it's dead in it? > 19:45 < jeremy> | works for me :-) > 19:45 < thl> | jeremy, the branch script would need to take care > that no new branched are created later > 19:45 < thl> | but that's probably easy > 19:46 < jeremy> | well, allowing an older branch to be made is > fine. but not creating it when doing mass-branching is good > 19:46 < thl> | jeremy, exactly > 19:46 < thl> | k, that was all from my side > 19:46 < jeremy> | and the mass-branching is just a giant "for i in > ..." script > 19:46 < jeremy> | if you get me a list of FC-5 branches which need > to be killed, I can do that > 19:47 <-- | dgregor has quit (Read error: 110 (Connection > timed out)) > 19:47 < thl> | jeremy, k, will try to find someone for that task ;-) > > For me that discussion is enough (especially as the dead.package marker > is used already) even if there was no "formal" decision /"voting" on it. > > Michael, or is there anything else that you'd like to see discussed? > Then I'll put it on the schedule. Missing is the clear confirmation that this particular "dead.package" marker file is supported by the relevant scripts actually. And as you've noticed, too, this is completely undocumented. It's insufficient that an IRC log contains comments about it. FESCO fails to make clear announcements and doesn't even try to reach a broader audience. How often have we discussed something in IRC only to forget about it because of inactivity on the mailing-list? (e.g. whether Cc in owners.list still works!) From j.w.r.degoede at hhs.nl Thu Jul 6 13:56:37 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 06 Jul 2006 15:56:37 +0200 Subject: FE Package Status of Jul 5, 2006 In-Reply-To: <20060706154249.c5b2bccc.bugs.michael@gmx.net> References: <200607052054.k65Ks7oW027513@mx1.redhat.com> <44ACED4E.1030505@leemhuis.info> <20060706143215.4e2ab8fb.bugs.michael@gmx.net> <44AD08BA.7090805@leemhuis.info> <20060706154249.c5b2bccc.bugs.michael@gmx.net> Message-ID: <44AD1695.6020908@hhs.nl> Michael Schwendt wrote: > e.g. whether Cc in owners.list still > works! > Actually, it doesn't work atm, I complained about it on the list an the response was know issue. Is this in bugzilla? If not where should I file it? Regards, Hans From bugzilla at redhat.com Thu Jul 6 14:38:07 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 6 Jul 2006 10:38:07 -0400 Subject: [Bug 171541] Review Request: kimdaba: KDE Image Database In-Reply-To: Message-ID: <200607061438.k66Ec75O026050@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: kimdaba: KDE Image Database https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171541 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com ------- Additional Comments From rdieter at math.unl.edu 2006-07-06 10:29 EST ------- FYI, name deprecated, package renamed upstream to kphotoalbum. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From toshio at tiki-lounge.com Thu Jul 6 15:51:04 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 06 Jul 2006 08:51:04 -0700 Subject: next FESCo meeting agenda. In-Reply-To: <20060706075640.dfa684d8.bugs.michael@gmx.net> References: <44AB69CD.8000607@knox.net.nz> <20060705083236.GA2487@free.fr> <20060705115116.83628f34.bugs.michael@gmx.net> <1152146611.24961.151.camel@localhost> <20060706075640.dfa684d8.bugs.michael@gmx.net> Message-ID: <1152201064.24961.229.camel@localhost> On Thu, 2006-07-06 at 07:56 +0200, Michael Schwendt wrote: > On Wed, 05 Jul 2006 17:43:31 -0700, Toshio Kuratomi wrote: > > > I would like to see another level of Fedora Extras Contributor. Someone > > previously unsponsored who wants to work on an orphaned package (or > > potentially orphaned due to AWOL maintainer) could be sponsored as a > > mentored packager. > > Are you convinced that you would find enough people who want an official > role that sounds so "uncool"? Long ago we've done something similar > occasionally for some time. People with access to CVS and buildsys have > forwarded the modifications sent by contributors without access. It is > still possible at a limited degree, provided that a sponsor is willing to > do it. It doesn't add any security. > I don't know. I'd be willing to do it. But I forsee that it's really only possible to handle one mentoree at a time so just saying I'd do it doesn't scale very well. I would not want to gate changes to cvs, though. I'd want the mentoree to have full access to the package they are comaintaining. My additional responsibility is to scrutinize the actions that the mentoree is taking. The mentoree gets the full experience of maintaining a package in Extras. > And it doesn't work smoothly for new packages, btw. (It bears a big risk > that the sponsor ends up with orphans) > I can see that risk. The answer is really that the mentor has to be willing to maintain the packages that their mentoree is working on if they go AWOL. Which is, on one hand, another burden on the mentor. But it is less than if the mentor would have packaged (or picked up from orphan status) the package themselves and had to keep it updated without benefit of a co-maintainer. > > The mentor would track their mentoree's actions more > > closely than normal. > > What would be "normal"? ;) > "Without clearly defined responsibilities for sponsors...." *grin* > > Watch their cvs commits. Take a hand in watching > > upstream's changes. Act as co-maintainer for the mentorees packages. > > The majority of contributors want the full show, and quickly. A "Fedora > account". Even if they know they will have problems handling some things > (like working with the relevant tools). This is the piece I want to address with a mentor-mentoree relationship. The new contributor gains access to commit to a specific package and use other infrastructure earlier in the process but they have someone overseeing their work and the scope of their power is limited to a few packages (until they've proved themselves and moved out on their own.) > Further, some people sign up > quicker than they have an idea what to contribute. It's the old "be part > of it" community game without clear activities or contributions. Many more > people would sign up for an account if that became possible without > needing a sponsor and without actual contributions. It doesn't help Fedora > Extras if people are sponsored without contributing anything to the > package maintenance. On the contrary, when refusing access to CVS or > buildsys for someone who started getting active in bugzilla with a package > submission, there would be complaints that it hurts their productivity. > The mentor plan is for when someone wants to maintain a few packages but doesn't have the history to prove they know how to package. It is not an "open the gates to the unwashed" plan. The mentoree would have to be "sponsored" by a mentor (Which will probably be a smaller pool than the sponsors as not every sponsor will want to take on the burden of having mentorees.) > But remember, that it is possible to revoke sponsorship. There are a few people who are currently contributing to Fedora Extras that I think would have benefited from a mentorship program. They are enthusiastic, committed, and willing to take advice. But they don't have the experience to know how to troubleshoot build failures, what kind of spec file changes are acceptable and which are fugly hacks, and so forth. If they had a mentor that forced them to justify their spec file changes or that was available to figure out the pros and cons of the ideas they bounce around they'd be much higher quality packagers by now. I don't think we want to revoke the sponsorship of these types of packagers, just figure out a better way to educate them. -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 katzj at redhat.com Thu Jul 6 15:56:59 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 06 Jul 2006 11:56:59 -0400 Subject: FE Package Status of Jul 5, 2006 In-Reply-To: <20060706154249.c5b2bccc.bugs.michael@gmx.net> References: <200607052054.k65Ks7oW027513@mx1.redhat.com> <44ACED4E.1030505@leemhuis.info> <20060706143215.4e2ab8fb.bugs.michael@gmx.net> <44AD08BA.7090805@leemhuis.info> <20060706154249.c5b2bccc.bugs.michael@gmx.net> Message-ID: <1152201420.29621.1.camel@orodruin.boston.redhat.com> On Thu, 2006-07-06 at 15:42 +0200, Michael Schwendt wrote: > Missing is the clear confirmation that this particular "dead.package" > marker file is supported by the relevant scripts actually. There isn't really a "mass-branch" script -- it's more of a for i in /cvs/extras/rpms ; do ... type of thing. > And as you've noticed, too, this is completely undocumented. Documenting it definitely makes sense though Jeremy From jima at beer.tclug.org Thu Jul 6 16:45:15 2006 From: jima at beer.tclug.org (Jima) Date: Thu, 6 Jul 2006 11:45:15 -0500 (CDT) Subject: FESCo Election Results In-Reply-To: References: <44ABCDFF.8030609@fedoraproject.org> <1152119550.8883.42.camel@cutter> <1152123264.24961.63.camel@localhost> <1152146523.2975.7.camel@localhost> Message-ID: On Wed, 5 Jul 2006, Christopher Stone wrote: > On 7/5/06, Callum Lerwick wrote: >> Also I question the "Vote for no more than 13" limit. Approval voting >> systems don't usually place a limit. > > +1 > > I think a lot of people felt they had to vote for 13 members and voted > for people they were unsure about just to fill the 13 number. From Mike McGrath's original email tallying the votes: Total Votes: 730 Total Ballots: 69 This here gcalctool window seems to inform me that 730 votes divided by 69 ballots gives an average of about 10.58 votes per ballot. So I'm not sure people felt necessarily pressured to vote for 13 candidates. Jima From dragoran at feuerpokemon.de Thu Jul 6 17:17:21 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 06 Jul 2006 19:17:21 +0200 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <44AD2F60.1090105@feuerpokemon.de> References: <1152079490.23468.0.camel@rousalka.dyndns.org> <44AD2F60.1090105@feuerpokemon.de> Message-ID: <44AD45A1.80606@feuerpokemon.de> dragoran wrote: > Nicolas Mailhot wrote: >> Dear Fedora user, >> >> A new font family is being proposed as the Fedora Core default. It >> probably impacts your language. Please tell us what you think about it: >> >> http://fedoraproject.org/wiki/Fonts/DejavuFeedbackCall >> >> Happy testing! >> >> > > the monospace font seem to be broken (chars overlap see screenshot) > > monospace issue fixed (X restart was required): https://bugs.freedesktop.org/show_bug.cgi?id=7440 From j.w.r.degoede at hhs.nl Thu Jul 6 19:10:51 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 06 Jul 2006 21:10:51 +0200 Subject: allegro using packages need a rebuild Message-ID: <44AD603B.6020906@hhs.nl> Hi all, Allegro the gaming library contains some asm code which is put in a static lib (liballeg_unsharable.so) because its not PIC. Unfortunatly these asm files don't (didn't) properly add a GNU stack section to the obj files they generate causing apps linked against allegro (using allegro-config --libs) to require an executable stack. This has caused allegro using apps to fail now that allow_exec_mem has been set to false in newer targeted-policy releases. Yes you've read that correctly because execmem has been set to false. The problem here is that create_pthread tries to create a piece of executable mem to use as stack for the new thread. Now that allegro has been fixed all apps using allegro must be rebuild. here is a list of packages which are linked against allegro: [hans at localhost ~]$ repoquery --whatrequires liballeg.so.4.2 allegro-tools-0:4.2.0-11.i386 crystal-stacker-theme-editor-0:1.5-0.pre.2.fc5.i386 shippy-allegro-0:1.3.3.7-2.fc5.i386 allegro-tools-0:4.2.0-12.fc5.i386 zasx-0:1.30-1.fc5.i386 worminator-0:3.0R2.1-3.fc5.i386 dumb-0:0.9.3-2.fc5.i386 overgod-0:1.0-3.fc5.i386 AllegroOGG-0:1.0.3-2.fc5.i386 crystal-stacker-0:1.5-0.pre.2.fc5.i386 dumb-0:0.9.3-3.fc5.i386 DevIL-0:1.6.8-0.7.rc1.fc5.i386 DevIL-0:1.6.8-0.8.rc1.fc5.i386 worminator-0:3.0R2.1-2.fc5.i386 adime-0:2.2.1-3.fc5.i386 lacewing-0:1.10-4.fc5.i386 rafkill-0:1.2.1-1.fc5.i386 raidem-0:0.3.1-2.fc5.i386 raidem-0:0.3-2.fc5.i386 This is on FC-5 as repoquery is broken on devel atm. Now all those packages are maintained by me except for DevIL, however I was the reviewer of DevIL and DevIl doesn't link against alleg_unsharable, thats left up to the application, since if DevIL would do this it would be become non PIC. I've queued rebuilds for devel for all apps listed above, all libs listed above do not need a rebuild because of the same reasons as DevIL. So unless I'm mistaken nobody needs todo anything, still I wanted to let you all know about this. Regards, Hans From peter at thecodergeek.com Thu Jul 6 21:36:26 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 06 Jul 2006 14:36:26 -0700 Subject: allegro using packages need a rebuild In-Reply-To: <44AD603B.6020906@hhs.nl> References: <44AD603B.6020906@hhs.nl> Message-ID: <20060706143626.d1u5kbrnfgg00wo8@www.thecodergeek.com> On Thu, 06 Jul 2006 21:10:51 +0200, Hans de Goede wrote: > I've queued rebuilds for devel for all apps listed above, all libs > listed above do not need a rebuild because of the same reasons as DevIL. Thanks for the notice, Hans. Just for curiosity, though: Does this include FC-5 Extras too, or is ist just devel? -- Peter Gordon (codergeek42) This message was sent through a webmail interface, thus has no digital signature. From j.w.r.degoede at hhs.nl Thu Jul 6 21:44:52 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 06 Jul 2006 23:44:52 +0200 Subject: allegro using packages need a rebuild In-Reply-To: <20060706143626.d1u5kbrnfgg00wo8@www.thecodergeek.com> References: <44AD603B.6020906@hhs.nl> <20060706143626.d1u5kbrnfgg00wo8@www.thecodergeek.com> Message-ID: <44AD8454.2080202@hhs.nl> Peter Gordon wrote: > On Thu, 06 Jul 2006 21:10:51 +0200, Hans de Goede wrote: >> I've queued rebuilds for devel for all apps listed above, all libs >> listed above do not need a rebuild because of the same reasons as DevIL. > > Thanks for the notice, Hans. Just for curiosity, though: Does this include > FC-5 Extras too, or is ist just devel? > I just did the rebuild for devel since execmem is allowed by default under FC-5 afaik. Regards, hans From bugzilla at redhat.com Thu Jul 6 22:00:06 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 6 Jul 2006 18:00:06 -0400 Subject: [Bug 180066] Request: Inclusion of a ruby template file In-Reply-To: Message-ID: <200607062200.k66M06EH030467@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request: Inclusion of a ruby template file https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180066 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO Flag| |needinfo? ------- Additional Comments From ville.skytta at iki.fi 2006-07-06 17:51 EST ------- There's a spurious "BuildArchitectures: noarch" line in the new template, I suppose there are no objections to removing that. A BuildArch: placeholder is already there. I see ruby_sitelib and ruby_sitearch have had "dir" appended to them. While cosmetic, I think it would be good to be consistent with the perl and python precedents in templates and/or macros shipping in the main rpm package; both of perl and python use *_sitelib and *_sitearch without the trailing "dir". I've committed to rpmdevtools CVS with those changes, let me know if there are strong opinions on the *_site*dir macro names and/or if they're "set in stone" and I'll add those changes too. http://cvs.fedora.redhat.com/viewcvs/fedora-rpmdevtools/spectemplate-ruby.spec?root=fedora&rev=.&view=markup -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From packages at amiga-hardware.com Thu Jul 6 22:09:50 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Thu, 06 Jul 2006 23:09:50 +0100 Subject: allegro using packages need a rebuild In-Reply-To: <44AD603B.6020906@hhs.nl> References: <44AD603B.6020906@hhs.nl> Message-ID: <44AD8A2E.7030007@amiga-hardware.com> Hans de Goede wrote: > I've queued rebuilds for devel for all apps listed above, all libs > listed above do not need a rebuild because of the same reasons as DevIL. > > So unless I'm mistaken nobody needs todo anything, still I wanted to let > you all know about this. I'm glad I read the end of the mail and didn't decide to jump the gun ;-) -- Ian Chapman. From nicolas.mailhot at laposte.net Thu Jul 6 22:55:50 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 07 Jul 2006 00:55:50 +0200 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <44AD0E23.3020901@feuerpokemon.de> References: <1152079490.23468.0.camel@rousalka.dyndns.org> <44AB5E2D.8060707@feuerpokemon.de> <34740.192.54.193.53.1152089424.squirrel@rousalka.dyndns.org> <44AD0E23.3020901@feuerpokemon.de> Message-ID: <1152226550.27758.11.camel@rousalka.dyndns.org> Le jeudi 06 juillet 2006 ? 15:20 +0200, dragoran a ?crit : > > I've opened the following ticket. Feel free to complete it > > https://bugs.freedesktop.org/show_bug.cgi?id=7427 > > > > > this is marked as wontfix :( > using no bytecode interpreter makes other fonts (the ms stuff used on > most webpages looks very(!!) ugly > what about a dejavu-fonts-bytecodeinterpreter package with fixed fonts > for bytecode interpretter users? Can you try to drop the following files in /etc/fonts/conf.d and report if it fixes your problems ? (you may have to play with the autohinter part - I don't have the bytecode interpreter there, so I guessed the syntax. Maybe autohinter on with no hinter off is sufficient) If this is the case I'll include them in the next package iteration Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: 99-DejaVu-autohinter-only.conf Type: application/xml Size: 918 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 99-DejaVu-limit-hinting.conf Type: application/xml Size: 915 bytes Desc: not available URL: -------------- 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 brkamikaze at gmail.com Thu Jul 6 22:51:40 2006 From: brkamikaze at gmail.com (Nikolai) Date: Thu, 6 Jul 2006 19:51:40 -0300 Subject: How to split a package to have a -devel one? Message-ID: I am creating a RPM to submit to FE, but it is a development library. Since it has some .so* files and some .h files; I think the package should be split into a simpler package, with the .so* files and a -devel package with the .h files. How can I do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Thu Jul 6 22:58:46 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 07 Jul 2006 00:58:46 +0200 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <20060706110436.4e9c5aa3@voip.int.addix.net> References: <1152079490.23468.0.camel@rousalka.dyndns.org> <20060706110436.4e9c5aa3@voip.int.addix.net> Message-ID: <1152226726.27758.15.camel@rousalka.dyndns.org> Le jeudi 06 juillet 2006 ? 11:04 +0200, Ralf Ertzinger a ?crit : > Hi. > > On Wed, 05 Jul 2006 22:07:42 -0400, Joe Smith wrote: > > > much prefer the original default face that came with Fedora 5 > > (Luxi?). My eyesight is not what it used to be and I find the Dejavu > > fonts very much less readable (seems mostly spacing issues: too > > "cramped" too "lumpy"). Sorry I can't be any more specific. > > One occassion where I noted this is the combination of T with a > smaller letter following (Ta or To, for example). The smaller letter > is very close to the T. I used Vera before, and it hat no such > issue. I think DejaVu enabled a kerning feature which allows glyphs to be spaced much closer. But they got too far and the new layout is overtight. Would it be possible for you to spend some time listing all the letter combos you feel are too close now ? Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From brkamikaze at gmail.com Thu Jul 6 23:39:06 2006 From: brkamikaze at gmail.com (Nikolai) Date: Thu, 6 Jul 2006 20:39:06 -0300 Subject: Problem with a package Message-ID: I'm packaging also the Widelands game; and I noticed it uses a weird filesystem structure, because it has no "make install" and the data files are on the subdirs on the same dir as the executable. How should I fix this? Put everything on /usr/bin or make a special folder for widelands on /usr/share and fix the .desktop file? -------------- next part -------------- An HTML attachment was scrubbed... URL: From toshio at tiki-lounge.com Thu Jul 6 23:40:45 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 06 Jul 2006 16:40:45 -0700 Subject: This week's FESCo Meeting Summary Message-ID: <1152229246.24961.270.camel@localhost> 2006 July, 06 FESCo Meeting =========================== Note: This is the first meeting of the new FESCo. The new membership is listed on the wiki: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee Meeting Summaries are posted on the wiki at: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings Attending from FESCo -------------------- * c4chris * scop * abadger1999 * jeremy * dgilmore * rdieter * jwb * tibbs * warren * thl (late) Summary ------- * FESCo organization - thl was nominated and accepted as the chair until FC7. Then someone else will need to take over. - It was decided to start a "Vice President" position to run meetings when the chair cannot make the meetings. Discussion of nominees will take place on the FESCo list. - Scribe position to summarize the meetings. abadger1999 will do it for now. Possibly rotate. - Meeting time will stay 17:00 UTC for now, 18:00 UTC during the winter. * FESCo list. jeremy is taking care of subscriptions so the new FESCo receives mail there. FESCo members, be sure to send a message to jeremy with the email address to subscribe to the list. * Ctrl+C problem. (cvs-commits-mails can be prevented by hitting CTRL +C) - Sopwith put in a potential fix. - Little testing has been done. Hans (bug reporter) was emailed to see if it is still hackable. - Warren asked if anyone has tested whether breaking the ssh connection to the server at the right time will prevent syncmail from running. Jeremy replied that in theory syncmail will still run. * Encouraging Extras Reviews - Better guidelines for reviews have been worked on. - New ideas solicited: + possibility of scripting pieces of the review (how does this differ from rpmlint?) + Creating an alternative to package reviews to getting a package into Extras. How do we avoid fire-and-forget packagers with this? Auto remove orphans? + Reviving review days + Making reviews more beneficial to the reviewer; * Publishing stats on number of reviews per person * Making the requirement to do reviews more prominent * Encouraging swapping reviews - A points system to allow reviewers to gain points towards having their package reviewed. + Requires automated tools for tracking - tibbs is going to try simply asking the reviewed person to make a review in return. - c4chris will retrieve some stats on how the package review queue has changed over the course of time. - Creating a new tracker bug FE-GUIDELINES to block bugs which are stuck because guidelines are in flux (as in php extensions are being worked on right now) * Deferred: - Plan for the next election - change log format (Was decided on the Packaging list) - IPv6 proposal: Will be discussed at the next FESCo then bumped to the packaging list. Full Log -------- :: (10:01:01) scop [n=scop] entered the room. (10:01:14) ***c4chris__ is around... (10:02:22) jima: oh, right, fesco meeting. and i'll miss it, doh. (10:02:31) jima: (and the new fesco breathes a sigh of relief) (10:02:32) ***abadger1999 is extricating from the packaging meeting (10:02:39) ***scop ditto (10:02:41) ***jeremy is around-ish (10:02:42) c4chris__: well, not sure if there'll be a meeting... (10:03:04) ***dgilmore is here (10:03:16) scop: c4chris, ? (10:03:53) c4chris__: scop, thl won't be around, and wondered what would happen... (10:03:55) abadger1999: scop: thl is going to be late. (10:03:59) rdieter: ho hum. (10:04:00) ixs: mhhhm. I should go home. (10:04:08) ixs: I'm always reading "fiasco meeting" (10:04:12) jwb: i'm here (10:04:54) abadger1999: I think we should start by voting thl extra responsibilities ;-) (10:05:03) c4chris__: right :) (10:05:19) jwb: abadger1999, thl said he wouldn't mind being chair still (10:05:23) scop: wasn't one item of this meeting choosing a new chair? (10:05:27) jwb: scop, yes (10:05:32) dgilmore: yep (10:05:37) jwb: scop, that is what thl wanted to primarily do today (10:05:42) c4chris__: any other candidate ? (10:05:51) jwb has changed the topic to: FESCo meeting in progress - New Chair (10:05:53) dgilmore: is anyone intrested in it? (10:06:02) jwb: jeremy, you around? (10:06:07) tibbs: The silence is deafening. (10:06:08) c4chris__: nope, just got here... (10:06:23) Seg: Aww I get to miss the possible non meeting. Math test today! (10:06:41) jwb: ok, who's here? (10:06:50) scop: I think there would be some value in shuffling people around, but if there are no other nominees and thl doesn't mind... (10:07:08) jwb: scop, tibbs, c4chris__, dgilmore, abadger1999, rdieter (10:07:09) jeremy: jwb: vaguely (10:07:14) Seg: Back in about 3 hours. ;P (10:07:16) tibbs: thl should choose a second for those times he can't be here. (10:07:24) jwb: jeremy, enough to pay attention? (10:07:27) jwb: warren, you around? (10:07:32) jeremy: jwb: we'll see :) (10:07:34) c4chris__: tibbs, good idea (10:07:58) tibbs: I have tried to run a meeting before and it's not terribly difficult; maintaining the schedule is not so easy. (10:08:00) warren: jwb, nope (10:08:04) dgilmore: anyone intrested in the backup job? (10:08:04) ***scop says tibbs do it today until thl arrives (10:08:20) jeremy: scop: seconded (10:08:21) ***dgilmore agrees with scop (10:08:23) tibbs: OK, let me un-run the other meeting. (10:08:23) warren: jwb, what's up? (10:08:30) jwb: warren, FESCo meeting (10:08:50) c4chris__: scop, +1 (10:09:05) jwb: ok, so tibbs is running it today (10:09:23) jwb: but was there anyone that wanted to nominate for Chair? (10:10:08) jwb: ok, i take that as a no (10:10:14) rdieter: thl? (: (10:10:25) jwb: rdieter, he said he would do it again if nobody else wanted it (10:10:25) tibbs: I guess that's a no. Let's put the chair bit off until thl is back. (10:10:29) dgilmore: rdieter: he said he would do it until FC7 (10:10:34) jwb: right (10:10:52) jwb: tibbs, you want to create a "Vice President" position? (10:11:08) jwb: was that the suggestion? or just someone to run the meeting in the Chair's absence? (10:11:09) tibbs: That seems reasonable; thl deserves a day off every couple of years or so. (10:11:24) jwb: ok, i like the VP idea (10:11:29) rdieter: vp++ (10:11:36) c4chris__: yup (10:11:43) tibbs: +1 (10:11:48) abadger1999: +1 (10:11:54) jwb: abadger1999, jeremy, warren? (10:11:58) jwb: oh, sorry abadger1999 (10:12:22) warren: +1 (10:12:23) scop: any VP nominees? (10:12:33) jwb: yeah, that's the next question (10:12:43) ***scop nominates abadger1999 (10:12:53) ***dgilmore nominates scop (10:13:07) dgilmore: abadger1999 would be good also (10:13:08) ***abadger1999 nominates tibbs (10:13:27) jwb: i say we discuss the nominees on the fesco list and vote next meeting (10:13:28) jeremy: grr.. network sucking :-/ (10:13:31) abadger1999: Real question, does anyone accept? (10:13:47) dgilmore: speaking of the fesco list i guess i need to subscibe to it (10:13:48) jeremy: on the subject of fesco list, new members -- send me a mail with the email address you want subscribed and I'll do that (10:13:52) tibbs: I have a meeting immediately before this one, so I'm probably not the best person. (10:13:55) jeremy: I didn't want to figure out people's address that they wanted :) (10:14:10) abadger1999: tibbs: scop and I are there as well :-) (10:14:19) c4chris__: jeremy, k, will do (10:14:20) abadger1999: I guess that excuses all of us :-) (10:14:20) tibbs: Crap. (10:14:26) scop: what about purging old members' subscriptions? (10:14:35) jeremy: scop: I'll take care of that too (10:14:41) scop: jeremy, ok (10:14:46) jeremy: that's easier :) (10:15:05) jwb has changed the topic to: FESCo meeting in progress - VP candidates (10:15:22) ***jwb notes that tibbs is supposed to be doing this ;) (10:15:32) tibbs: I have now un-run the other meeting. (10:15:57) ***abadger1999 notes that jwb is doing a fine job ;-) (10:16:11) tibbs: Candidates: I agree that we should discuss on the list. (10:16:24) c4chris__: and he didn't give excuses of other preceeding meetings... (10:17:03) tibbs: I have to learn everyone's nicks. Crap. (10:17:09) scop: list++, next ;) (10:17:14) jwb: ok, so i'll start a thread on the list (10:17:24) jwb: once jeremy says everyone is subscribed (10:17:32) tibbs: Great. Next. (10:17:42) jwb: tibbs, i put the nicks on http://fedoraproject.org/wiki/Extras/SteeringCommittee (10:17:50) tibbs: The CTRL-C problem? (10:18:05) jeremy: tibbs: an attempted fix went in (10:18:09) dgilmore: warren: any update on ctrl-c (10:18:10) tibbs has changed the topic to: FESCo meeting in progress - CTRL-C problem (10:18:21) tibbs: jeremy: Has anyone tried to hack it? (10:18:29) warren: dgilmore, I haven't been able to work on it at all while I didn't have sysadmin access during the election. (10:18:30) tibbs: I recall that Hans could do it at will. (10:18:45) jeremy: tibbs: dunno (10:18:53) jeremy: tibbs: it's definitely going ot be _harder_ now (10:19:01) jwb: can somebody ask Hans to try again? (10:19:05) warren: dgilmore, and frankly, I cannot prioritize doing that myself right now. (10:19:06) rdieter: what is the "cntl-c" problem exactly? (10:19:09) dgilmore: should we get hans to try since he brought it up (10:19:11) jeremy: tibbs: sopwith made it so the script should ignore ctrl-c (10:19:23) tibbs: I don't think he does IRC; I'll shoot him an email. (10:19:25) ***rdieter remembers now, never mind. (10:19:27) jwb: rdieter, if you hit CTRL-C at the right time then you would cancel the commit email (10:19:30) dgilmore: rdieter: if you press ctrlc at the right time in a cvs commit syncmail doesnt run (10:19:59) ***tibbs will move on soon (10:20:04) dgilmore: tibbs: he does sometimes but mostly not (10:20:06) warren: What if you break the SSH connection at the right moment? (10:20:23) dgilmore: warren: probably the same (10:20:24) ensc [n=irc-ensc] entered the room. (10:20:41) ***tibbs will move in in 30 (10:20:54) warren: The script sounds to be ignoring the signal now, but will it prevent syncmail from failing if you break the SSH connection? (10:21:16) warren: If stdout is directed there, it might not. (10:21:31) tibbs has changed the topic to: FESCo meeting in progress - Encourage Extras Reviews (10:21:34) jeremy: warren: it shouldn't afaik (10:21:52) tibbs: I was doing this, but aside from better guidelines I'm all out of ideas. (10:22:13) jwb: tibbs, would it help if some of the stuff was scripted? (10:22:23) dgilmore: I know i need to do more reviews (10:22:33) dgilmore: jwb: you would think so (10:22:42) tibbs: jwb: I'm not sure, honestly. (10:22:59) jwb: dgilmore, i was looking at it today... there isn't a ton that can be scripted but some can (10:23:08) tibbs: Even when people know it's a requirement for sponsorship, they still don't do it. (10:23:21) scop: huh, scripted reviews? (10:23:26) warren: tibbs, thus we should drop review requirement? (10:23:27) jwb: tibbs, i was actually thinking of the reviewers (10:23:27) dgilmore: I guess there isi not much glory in reviews (10:23:36) jwb: scop, no not scripted reviews (10:23:50) scop: :) (10:23:59) dgilmore: should we start sending emails with stats on reviews? like was done a long time ago (10:23:59) tibbs: warren: I don't think we should drop the requirement, no. But it needs to be more prominent. (10:24:03) ***edhill suggests that, for more reviews, we figure out how to clone tibbs (10:24:08) jwb: scop, just a tool to check for some of the simple stuff. like license, spec name vs. %{name}, etc (10:24:26) tibbs: jwb: Sounds like rpmlint. (10:24:28) scop: jwb, like rpmlint? (10:24:39) jwb: scop, yeah does rpmlint do all that already though? (10:24:45) tibbs: rpmlint is good, and improving it is good, but it doesn't get to the root of the problem. (10:24:49) dgilmore: rpmlint on steroids? (10:24:57) jwb: yes, rpmlint on steroids (10:25:15) jwb: tibbs, right it doesn't solve the root of the problem. but it helps... maybe (10:25:16) tibbs: The problem is that people want to maintain the packages they're interested in. They don't want to be involved in other peoples' packages. (10:25:41) tibbs: I recall that we used to have review days; did they help? (10:25:52) c4chris__: the trick is to get at least two people interested in oen package. (10:25:55) scop: IMO *that*'s not a problem in a volunteer project (10:26:00) ***thl on the keyboard now (10:26:09) scop: volunteers do what they are interested in (10:26:25) tibbs: scop: True. You can't really change that. (10:26:45) stickster left the room (quit: "Ack! Thppptt..."). (10:26:47) scop: reviewing for the sake of reviewing doesn't make much sense (10:27:08) rdieter: imo, if no one is interested enough in pkg x to review it, then it shouldn't be in extras. (10:27:17) warren: Maybe we should work on some *other* way of getting a package in that nobody else is interested in? (10:27:26) tibbs: rdieter: You're probably right. (10:27:43) tibbs: But I pick up packages that I'm not interested in. Lots of them. (10:27:56) c4chris__: rdieter, I feel the same (10:28:02) cweyl [n=cweyl] entered the room. (10:28:08) dgilmore: tibbs: you have super powers though (10:28:37) rdieter: but warren has a point, if pkg x *were* in extras, maybe more people would get interested and use it. (10:28:38) cweyl: that he does, especially when it comes to perl packages :) (10:28:38) tibbs: dgilmore: Honestly I don't think so. It doesn't really even take all that much time. (10:29:01) warren: The question is how to define this (10:29:02) abadger1999: warren: Do we keep enough stats to correlate fire-and-forget packagers with # of reviews? (10:29:11) c4chris__: encourage more swapping reviews ? (10:29:19) warren: And yes, fire-and-forget packagers is a HUGE risk here. (10:29:44) ChitleshGoorah left the room (quit: "Konversation terminated!"). (10:29:47) Sopwith: What is the risk? (10:29:50) dgilmore: c4chris__: i think that can help. I know that i dont review alot but the ones i do i hope they will return the favour (10:30:10) warren: We don't want to encourage people to dump packages into Extras and they don't maintain them. (10:30:19) c4chris__: Sopwith, orphans ? (10:30:37) Sopwith: Maybe we auto-remove orphaned packages? (10:31:00) dgilmore: Sopwith: we did that just before FC5 was released (10:31:06) cweyl: Sopwith: a package may be orphaned but very much in use. maybe just from devel? (10:31:25) c4chris__: cweyl, yes, for devel (10:31:27) ***thl likey to add a note to the CTRL-C conversation: Sopwith changed something and it should be harder to trigger now; but no one tried yet if it's really better now (10:31:31) scop: definitely only from devel if there are no security issues or compleat borkage (10:31:40) tibbs: I think we're back to where we started: I have no ideas for encouraging reviews. (10:31:53) jwb: thl, i think tibbs is going to as Hans to try again with the ctrl-c thing (10:32:06) thl: jwb, I asked Hans already (10:32:08) abadger1999: dgilmore, c4chris: Contribute to a review and receive a point. Guide a review start to finish and receive five? Redeem points with a set of package reviewers that will review your package for five points? (10:32:33) dgilmore: abadger1999: that could be incentive (10:32:36) thl: he said "I only triggered it once and don't know how to trigger it again" (10:32:43) jwb: thl, ok (10:32:46) tibbs: abadger1999: I guess it's worth a try. (10:33:01) tibbs: thl: I thought he said it was easy to do? A tempest in a teapot, perhaps? (10:33:03) c4chris__: abadger1999, why not. (10:33:04) jwb: abadger1999, how to track that? (10:33:33) c4chris__: jwb, yes, that's the next question... (10:33:34) abadger1999: jwb: I don't think we can automate it yet :-( (10:33:54) jwb: abadger1999, then you're not much better off than doing swap reviews... (10:34:21) c4chris__: abadger1999, cough package database cough (10:34:25) abadger1999: Yes. Except that you don't have to swap directly reviewer to reviewee. (10:34:47) jwb: abadger1999, right. but someone has to 'assign' points until it's automated (10:35:27) scop: anyone have stats about how the length of the pending review queue has developed eg. this year? (10:35:40) c4chris__: jwb, could be the duty of the packager once his package is approved (10:35:56) tibbs: scop: You should be able to look over c4chris's reports. (10:36:14) c4chris__: scop, I can dig some stuff up, but not for a whoel year yet (10:36:22) abadger1999: c4chris__: If the package db tracked who reviewed a package then we'd be able to pull that. But tracking contributors might be harder. (10:36:24) scop: cool (10:36:30) tibbs: I've been following it pretty closely but I don't have any hard figures. It's definitely gone up recently; we're blocked on a whole pile of PHP stuff. (10:36:36) jwb: abadger1999, want to draft up a strawman for the points system and send it out? (10:37:06) dgilmore: tibbs: wasnt there a huge perl influx the last couple of weeks? (10:37:09) jwb: tibbs, isn't the PHP stuff waiting on guideline changes? (10:37:19) tibbs: I think I'm going to try something simple. When I approve a package, I'll ask the submitter to do a package review. We'll see if it makes any difference at all. (10:37:20) warren: a points system wont work at all unless it is automated as part of bugzilla and the account system (10:37:21) dgilmore: jwb: yeah it is (10:37:34) tibbs: dgilmore: I have finished off most of the Perl stuff. (10:37:37) jwb: warren, that's my thinking too (10:37:53) warren: Note that GNOME Bugzilla has an excellent example of a points system that modifies contributor behavior to do productive things. (10:38:02) jwb: warren, but a strawman for how it would work can't hurt (10:38:05) abadger1999: jwb: I could. I'd like to figure out a little more about tracking first. If we know it's possible after we implement some tools that's doable, if we don't know how to automate at all that's quite another. (10:38:25) warren: Points scale by a logarithm instead of just linear. (10:38:26) ***dgilmore brb (10:38:37) warren: abadger1999, ++ (10:38:50) warren: I think tracking the metrics of the review queue is a good first start. (10:39:17) jwb: k, who's going to do that? c4chris__ ? (10:39:45) c4chris__: jwb, k, I'll dig some figures and post them. (10:39:52) jwb: cool (10:39:54) tibbs: Perhaps we need to indicate that some tickets are blocked waiting for guidelines. That would give is a clearer picture of what's really sitting around. (10:40:05) jwb: tibbs, +1 (10:40:24) thl: FE-BLOCKEDGUIDELINES ? (10:40:31) c4chris__: tibbs, I guess they have php in the summary? (10:40:34) thl: or any other blocker bug? (10:40:40) jwb: thl, yes that would work (10:40:41) tibbs: Or one for each guideline? PHP, mono. (10:40:52) cweyl: tibbs: on a related note, a "review/don't review" table at the top of ReviewGuidelines would be a nice clue for reviewers, too (10:40:53) tibbs: Mono stuff doesn't have mono in the summary. (10:40:55) thl: tibbs, no, one geneeral blocker bug should be enough (10:41:09) thl: tibbs, those things hopefully should not happen that often (10:41:10) jwb: cweyl, huh? (10:41:13) thl: (in the longer term) (10:41:44) thl: Tracking Bug for PHP, Perl, Python, ... stuff in general were discussed once (10:41:45) cweyl: jwb: e.g "don't review php packages ; do review perl ; don't review..." etc (10:41:59) thl: but only a few persons liked that idea then (10:42:21) tibbs: My bugzilla-fu is poor; anyone want to set up that tracking bug and start blocking things? (10:42:37) thl: I can set up that bug and use my bugzilla-sink account for it (10:42:41) jwb: cweyl, oh. that would be a short lived table. i think a blocking bug for things waiting on guidelines and statement about "if the bug is blocking FE-BLOCKEDGUIDELINES don't review" should be ok (10:42:50) warren: cweyl, "don't review php packages"? (10:43:03) warren: cweyl, you're going to make bress cry. =) (10:43:11) cweyl: jwb: gotcha. either or, just so long as there's a clue to be had :) (10:43:12) jwb: warren, because of being blocked on guidelines for now. not for forever (10:43:24) jwb: warren, in other words "don't waste time on this ATM" (10:43:28) warren: oh (10:43:29) thl: btw, has anybody a better name for that tracking bug -- FE-BLOCKEDGUIDELINES has a lot of chars ;-) (10:43:31) cweyl: warren: for now! I've been wanting phpMyAdmin in there forever ;) (10:43:40) jwb: thl, FE-GUIDELINES ? (10:43:44) thl: jwb, +1 (10:43:45) kanarip left the room (quit: Read error: 104 (Connection reset by peer)). (10:43:52) warren: heh... in the past years I've untarred phpmyadmin every time I wanted to use it. (10:44:00) tibbs: bress should help us out with guidelines if he wants it done quickly. (10:44:02) warren: jwb, +1 (10:44:11) cweyl: warren: yah... same here. it gets old quickly :) (10:44:12) tibbs: BTW, phpmyadmin should be reviewable now. (10:44:16) jwb: btw, does this apply to Core as well? (10:44:16) abadger1999: jwb: +1 (10:44:18) rdieter: jwb, +1 (10:44:19) c4chris__: jwb, +1 (10:44:36) ***scop needs to go in 5 minutes (10:44:39) thl: okay, I'll create FE-GUIDELINES and post about it to the list (10:44:43) tibbs: phpmyadmin is not a php extension package. (10:44:50) ***c4chris__ needs to run soon too (10:44:53) tibbs: scop: anything you wanted to cover before you leave? (10:45:02) tibbs: c4chris as well. (10:45:18) scop: resolution on chair, perhaps quickie on co-maintainership (10:45:24) c4chris__: I guess we'll do the AWOL next time? (10:45:28) cweyl: tibbs: and that's exactly why we/I need this clue, I had it stuck in my head "no php at all right now" (10:45:34) thl: AWOL next time IMHO (10:45:40) jwb: AWOL next time (10:45:58) jwb: thl, nobody stepped forward for the Chair. still ok with doing it until FC7? (10:46:07) thl: yeah (10:46:08) scop: re php, note that phpmyadmin may depend on some other php stuff which is subject to guideline changes (10:46:13) jwb: +1 for thl as Chair (10:46:20) tibbs: +1 thl (10:46:22) abadger1999: +1 thl (10:46:26) c4chris__: +1 for thl (10:46:26) dgilmore: `+1 for thl (10:46:36) thl: btw, I wanted to bring in a "Vice President", too (10:46:36) cweyl: +1 (rabble, tho ;)) (10:46:52) jwb: thl, cool. i'm starting a thread on fesco list for that with nominees (10:46:52) thl has changed the topic to: FESCo meeting in progress -- FESCo self organisation (10:46:54) scop: +1 thl, and we agreed to discuss VP on list (10:46:59) dgilmore: jwb as VP (10:47:03) rdieter: +1 thl (10:47:11) tibbs: That's 7. (10:47:12) thl: scop, k (10:47:33) thl: thx guys (10:47:45) thl: well, there is one other thing I#d like to change (10:47:53) thl: I'm getting tired of writing the summaries (10:48:04) thl: I would prefer if that job rotates (10:48:16) warren: Or we could have a FESCO scribe (10:48:21) warren: doesn't necessarily need to be in FESCO (10:48:26) jwb: i like the idea of a scribe (10:48:35) scop: ditto (10:49:03) abadger1999: I can do meeting summaries. (10:49:10) warren: The scribe should *usually* attend meetings, but could actually do it from logs afterward. (10:49:21) ***c4chris__ too, but I'm not sure I like scribing much... (10:49:45) c4chris__: abadger1999, thx (10:49:49) thl: we don't have to find a proper solution now (10:49:53) jwb: sure (10:50:05) jwb: abadger1999, want to take this meeting for now then until we finalize? (10:50:06) thl: but doing it every time is frustrating (10:50:24) abadger1999: jwb: Sounds good to me. (10:50:25) thl: abadger1999, I can post the log to the wiki if you don#t have one (10:50:35) c4chris__: thl, yup. Rotation is good. (10:50:50) scop: I need to run now, see ya (10:50:53) thl: scop, bye (10:51:08) scop left the room ("Leaving"). (10:51:13) thl: one other thing (10:51:20) abadger1999: I have a log. We might want to make sure the chair always keeps one, though, just in case the scribe isn't present. (10:51:33) thl: I'd like to make plans for the next election soon (10:51:53) thl: that might be the best now that the memorie of the recent election is still fresh (10:52:05) c4chris__: thl, k. Put it on the agenda? (10:52:14) thl: yes, that's my plan (10:52:30) thl: but abadger1999, you seem to have the best knowledge of the voting systems in general (10:52:51) thl: abadger1999, can you put togehter a rough plan how the next election should be done? (10:52:55) c4chris__: gotta run now (sorry) (10:53:04) abadger1999: thl: Just what we've implemented thus far. (10:53:05) c4chris__: see you all later (10:53:20) thl: thl, I didn#t mean the voting app (10:53:23) thl: more the scheme (10:53:36) thl: Let's discuss this afterwards (10:53:37) nim-nim [n=nim-nim] entered the room. (10:53:41) thl: I'll mail to the list (10:53:44) abadger1999: thl: Sounds good. (10:54:01) lmacken: are multiple *Requires packages separated by spaces or commas ? (10:54:10) jwb has changed the topic to: FESCo meeting in progress -- Free Discussion (10:54:21) jwb: i have 2 items i'd like to get on the agenda (10:54:27) jwb: 1) change log format (10:54:33) jwb: 2) IPv6 proposal (10:54:49) ***thl likes to note: all FESCo members can put things on the agenda (10:55:11) tibbs: jwb: changelog format has been voted on by the packaging committee and should be written up soon. (10:55:14) thl: please just give enough infomrations so other know the most important backgrounds (10:55:26) thl: and maybe announce the addition on a mailinglist (10:55:28) rdieter: jwb: changelog format was discussed already in the Packaging comittee. (10:55:40) jwb: tibbs, rdieter, even better then (10:56:07) thl: jwb, just out of interest: what did you meant with "IPv6 proposal" (10:56:53) dgilmore: lmacken: both work (10:57:02) jwb: thl, dwmw2 made a proposal on fedora-maintainers that all Extras packages should support IPv6 if they support IPv4. if they don't, it's a MUST to add it to a blocker bug (similar to ExcludeArch), and explain why (10:57:20) jwb: thl, he wants that added to the guidelines (10:57:30) tibbs: I like the idea of encouraging IPV6-ness and certainly making sure it's enabled if a package supports, but I don't think lack of it should be a blocker. (10:57:43) jwb: tibbs, rdieter: what's the relationship between the packaging committee and FESCo? (10:57:55) warren: lord and serf (10:57:59) _wart_: jwb: does the proposal include instructions on how to test for ipv6 support? (10:58:02) tibbs: jwb: Packaging committee decides on packaging guidelines for both core and extras. (10:58:04) thl: jwb, well, add it to the schedule then (10:58:14) jwb: _wart_, his example does not (10:58:16) jwb: thl, will do (10:58:33) thl: jwb, but my opinion is "we do packaging guidelines and that's often not packaging" (10:58:33) jwb: tibbs, yes but shouldn't FESCo agree to them before they become set in stone? (10:58:35) dgilmore: tibbs: I think that if ipv6 support its there then it should be turned on (10:58:47) jwb: thl, my opinion as well (10:58:53) thl: and the packaging guidelines are done by the Packaging Commitee (10:58:56) thl: nevertheless (10:59:02) thl: let's talk about that once (10:59:14) thl: but not today (10:59:19) jwb: right (10:59:40) thl: btw, does anyone know if all new FESCo member are in the US or Europe? (10:59:58) thl: does Thursday, 17:00 UTC fit everybody well? (11:00:05) dgilmore: thl: im in the US (11:00:08) jwb: .us (11:00:18) jwb: i think most are from .us (11:00:19) abadger1999: Works well for me (.us) (11:00:25) thl: or do we need to rotate two or three different times to make sure everyone can attent? (11:00:38) ***thl would prefer one fixed time (11:00:46) jwb: i prefer a fixed time as well (11:00:49) ***warren prefers one fixed time that works for both US and EU. (11:01:46) thl: okay, then we stick to 17:00 UTC (11:01:52) jima: holy crap, it's still going! (11:01:54) thl: (and 18:00 UTC during winters) (11:02:05) thl: anything else we should discuss today? (11:02:15) thl: any sponsor nominations? (11:02:45) jwb: it's late. i say we save those for next week (11:03:04) thl: yeah, let's close the meeting for today then (11:03:09) ***thl will close in 30 (11:03:28) ***thl will close in 10 (11:03:40) thl: -- MARK -- Meeting end -------------- 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 paul at all-the-johnsons.co.uk Thu Jul 6 23:53:26 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 07 Jul 2006 00:53:26 +0100 Subject: Anjuta : RFC Message-ID: <1152230006.3734.86.camel@T7.Linux> Hi, The Anjuta 1 branch has now been closed off with the exception of security fixes and all involved are concerned with the 2.0 version. Currently, anjuta-gdl is in FE with gnome-build and autogen currently under review. What I'm proposing is the following. 1. I put Anjuta-2.0.x back through the usual FE review system 2. When it is accepted, it is imported only into rawhide. 3. Those using stable and one version back from that, continue to use 1.2.4a 4. When all is stable and happy, the following happens 4a. 1.2.4a is moved to legacy and the 1.x branch removed from FE CVS 4b. 2.0.x is imported into the current version and one version back (as per the FC system) 5. The world goes on it's ever decreasing spiral. Comments? TTFN Paul BZ refs : autogen (197814 ), gnome-build (182320 ), anjuta-2 (189685 ) -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 Fri Jul 7 00:14:24 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 06 Jul 2006 17:14:24 -0700 Subject: How to split a package to have a -devel one? In-Reply-To: References: Message-ID: <44ADA760.2040504@thecodergeek.com> Nikolai wrote: > I am creating a RPM to submit to FE, but it is a development library. Since > it has some .so* files and some .h files; I think the package should be > split into a simpler package, with the .so* files and a -devel package with > the .h files. How can I do this? I find the OpenEXR case study near the bottom of Docs/Drafts/BuildingPackagesGuide [1] to be very useful as a guide for creating -devel subpackages. :) [1] http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide -- 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: 251 bytes Desc: OpenPGP digital signature URL: From brkamikaze at gmail.com Fri Jul 7 00:28:53 2006 From: brkamikaze at gmail.com (Nikolai) Date: Thu, 6 Jul 2006 21:28:53 -0300 Subject: How to split a package to have a -devel one? In-Reply-To: References: <44ADA760.2040504@thecodergeek.com> Message-ID: I just found the probable cause. The beginning of the file was ignored a bit since I was thinking only about the file list :) From brkamikaze at gmail.com Fri Jul 7 00:27:37 2006 From: brkamikaze at gmail.com (Nikolai) Date: Thu, 6 Jul 2006 21:27:37 -0300 Subject: How to split a package to have a -devel one? In-Reply-To: <44ADA760.2040504@thecodergeek.com> References: <44ADA760.2040504@thecodergeek.com> Message-ID: The snippet doesn't work. After putting the " %files devel %defattr(-,root,root,-) %doc %{_includedir}/*.h " snippet after the original %files section, I get the error "erro: linha 46: O pacote n?o existe: %files devel", which can be translated to "Error: line 46: The package doesn't exists: %files devel". What is wrong? 2006/7/6, Peter Gordon : > Nikolai wrote: > > I am creating a RPM to submit to FE, but it is a development library. Since > > it has some .so* files and some .h files; I think the package should be > > split into a simpler package, with the .so* files and a -devel package with > > the .h files. How can I do this? > > I find the OpenEXR case study near the bottom of > Docs/Drafts/BuildingPackagesGuide [1] to be very useful as a guide for > creating -devel subpackages. :) > > [1] http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide > -- > Peter Gordon (codergeek42) > GnuPG Public Key ID: 0xFFC19479 / Fingerprint: > DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 > > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > > From mmcgrath at fedoraproject.org Fri Jul 7 03:22:13 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 6 Jul 2006 22:22:13 -0500 Subject: Source file consolidation on CVS Message-ID: <3237e4410607062022k7d04f947o6240013e457ea7a1@mail.gmail.com> I'll be working to consolidate some of the source files on the CVS box over the next couple of days. Pay attention and let me know immediately if something breaks. I don't foresee any issues. Right now legacy, cvs, and dist all have individual sources in them. The sources are stored by file name and md5sum, for example: putty-0.58.tar.gz/ffb78a7db7e4802896189b2112714a9f/putty-0.58.tar.gz A collision between the different trees is unlikely. The purpose for this consolidation is to ease the efforts of the legacy team and provide them a proper development and build environment. In the end a source tarball is a source tarball, it makes sense to store them in one spot. Currently the dist repo is 73G and the extras repo is 12G. It seems a shame to make a copy of all of that when the exact same files would be a directory away. Send objections, comments, suggestions and consecutive unmarked-bills my way. -Mike From rc040203 at freenet.de Fri Jul 7 05:25:27 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 07 Jul 2006 07:25:27 +0200 Subject: rpms/perl-Class-InsideOut/devel perl-Class-InsideOut.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200607070302.k6732feq007254@cvs-int.fedora.redhat.com> References: <200607070302.k6732feq007254@cvs-int.fedora.redhat.com> Message-ID: <1152249928.14649.27.camel@mccallum.corsepiu.local> On Thu, 2006-07-06 at 20:02 -0700, Chris Weyl wrote: > Author: cweyl > --- NEW FILE perl-Class-InsideOut.spec --- > Name: perl-Class-InsideOut .. > BuildArch: noarch ... > %build > %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="%{optflags}" .. OPTIMIZE is meaningless and superfluous in noarch packages. > find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';' ... And this find also probably is superfluous. Ralf From rc040203 at freenet.de Fri Jul 7 05:28:33 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 07 Jul 2006 07:28:33 +0200 Subject: rpms/bit/devel bit.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200607062056.k66Kuph1011080@cvs-int.fedora.redhat.com> References: <200607062056.k66Kuph1011080@cvs-int.fedora.redhat.com> Message-ID: <1152250113.14649.31.camel@mccallum.corsepiu.local> On Thu, 2006-07-06 at 13:56 -0700, Rick L. Vinyard wrote: > Author: rvinyard > > --- NEW FILE bit.spec --- > # Target: Fedora .. > %build > %configure --enable-static=no .. > find %{buildroot} -type f -name "*.la" -exec rm -f {} ';' > %{__rm} -rf %{buildroot}/usr/bin Is this package using an autoconf generated configure? Then you should be using %{_bindir} instead of /usr/bin in the "rm" above. Ralf From dragoran at feuerpokemon.de Fri Jul 7 06:01:35 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 07 Jul 2006 08:01:35 +0200 Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <1152226550.27758.11.camel@rousalka.dyndns.org> References: <1152079490.23468.0.camel@rousalka.dyndns.org> <44AB5E2D.8060707@feuerpokemon.de> <34740.192.54.193.53.1152089424.squirrel@rousalka.dyndns.org> <44AD0E23.3020901@feuerpokemon.de> <1152226550.27758.11.camel@rousalka.dyndns.org> Message-ID: <44ADF8BF.1000703@feuerpokemon.de> Nicolas Mailhot wrote: > Le jeudi 06 juillet 2006 ? 15:20 +0200, dragoran a ?crit : > > >>> I've opened the following ticket. Feel free to complete it >>> https://bugs.freedesktop.org/show_bug.cgi?id=7427 >>> >>> >>> >> this is marked as wontfix :( >> using no bytecode interpreter makes other fonts (the ms stuff used on >> most webpages looks very(!!) ugly >> what about a dejavu-fonts-bytecodeinterpreter package with fixed fonts >> for bytecode interpretter users? >> > > Can you try to drop the following files in /etc/fonts/conf.d and report > if it fixes your problems ? > > (you may have to play with the autohinter part - I don't have the > bytecode interpreter there, so I guessed the syntax. Maybe autohinter on > with no hinter off is sufficient) > > If this is the case I'll include them in the next package iteration > > forgott this this is an non issue now doing an X restart after install does not only fix the monospace stuff but this one too ;) (fontconfig is broken) I am now using them as my default fonts they look very nice now ;) thx for the good work > Regards, > > From rc040203 at freenet.de Fri Jul 7 06:50:47 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 07 Jul 2006 08:50:47 +0200 Subject: [Bug 197198] Review Request: ntop In-Reply-To: <200607070626.k676QmKQ023836@bugzilla.redhat.com> References: <200607070626.k676QmKQ023836@bugzilla.redhat.com> Message-ID: <1152255047.14649.44.camel@mccallum.corsepiu.local> On Fri, 2006-07-07 at 02:26 -0400, bugzilla at redhat.com wrote: > Please do not reply directly to this Now that bugzilla seems to be broken, it seems to have swallowed my reply ;) > Summary: Review Request: ntop > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197198 > > > > > > ------- Additional Comments From michael at knox.net.nz 2006-07-07 02:18 EST ------- > (In reply to comment #29) > > * upstream uses the -release for libtool using the package version, > > this is wrong in general, since it trigggers a soname change even > > when the abi don't change, however those libraries are not meant to > > ne linked against, so if the *.so that don't have the release within > > their names are not distributed it is right. > > I am not sure I follow you here. Could you clarify? c.f. info libtool 'Release numbers' Upstream is using -release, which is a bad idea. Ralf From rc040203 at freenet.de Fri Jul 7 07:27:32 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 07 Jul 2006 09:27:32 +0200 Subject: rpms/bit/devel bit.spec,1.1,1.2 In-Reply-To: <200607070723.k677NNnc019460@cvs-int.fedora.redhat.com> References: <200607070723.k677NNnc019460@cvs-int.fedora.redhat.com> Message-ID: <1152257252.14649.49.camel@mccallum.corsepiu.local> On Fri, 2006-07-07 at 00:23 -0700, Rick L. Vinyard wrote: > Author: rvinyard > =================================================================== > RCS file: /cvs/extras/rpms/bit/devel/bit.spec,v > ;' > -%{__rm} -rf %{buildroot}/usr/bin > +%{__rm} -rf %{buildroot}/%{_bindir} This should be: %{__rm} -rf %{buildroot}%{_bindir} Note %{_bindir}, not /%{_bindir} Ralf From rvinyard at cs.nmsu.edu Fri Jul 7 07:28:51 2006 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Fri, 07 Jul 2006 01:28:51 -0600 Subject: rpms/bit/devel bit.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <1152250113.14649.31.camel@mccallum.corsepiu.local> References: <200607062056.k66Kuph1011080@cvs-int.fedora.redhat.com> <1152250113.14649.31.camel@mccallum.corsepiu.local> Message-ID: <44AE0D33.20304@cs.nmsu.edu> Ralf Corsepius wrote: >> find %{buildroot} -type f -name "*.la" -exec rm -f {} ';' >> %{__rm} -rf %{buildroot}/usr/bin >> > > Is this package using an autoconf generated configure? Then you should > be using %{_bindir} instead of /usr/bin in the "rm" above. > Yes, it is an autoconf package. It's changed. Thanks Ralf, From andy at smile.org.ua Fri Jul 7 08:18:07 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Fri, 07 Jul 2006 11:18:07 +0300 Subject: wine for FC4 problem? Message-ID: <44AE18BF.7080002@smile.org.ua> Hi, Andreas! I can't to update wine in FC4 due to xmessage dependence issue. There are core's package requirements: Requires: %{_bindir}/xmessage Requires: /usr/X11R6/bin/xmessage Is it wrong? -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From gauret at free.fr Fri Jul 7 09:13:47 2006 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 07 Jul 2006 11:13:47 +0200 Subject: Packaging questions about libvisual Message-ID: Hey, The new version of Amarok needs to update libvisual from 0.2 to 0.4. This will break dependencies in libvisual-plugins and gstreamer08-plugins (that's what "repoquery --whatrequires libvisual.so.0" says). I have four options : 1) Warn the maintainers of the dependencies, ask them to try to rebuild their packages with the new version, update in devel and FC-5, and ask the maintainers to rebuild their packages for version 0.4. That sounds very error-prone. 2) Update to version 0.4 only in devel, disabling visualisation plugins in the new amarok. That's not nice to those who like them. 3) Update to version 0.4 only in devel, and update amarok only in devel too. That's not nice, amarok is one of these apps for which you always want the latest version :) 4) Create a compat-libvisual020 package and update in devel and FC5. That sounds like the best solution, but may I create this package and import it in CVS without review ? Are there guidelines for this type of packages ? What do you think is best ? Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Make everything as simple as possible, but not simpler." -- Albert Einstein From paul at city-fan.org Fri Jul 7 09:15:11 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 07 Jul 2006 10:15:11 +0100 Subject: wine for FC4 problem? In-Reply-To: <44AE18BF.7080002@smile.org.ua> References: <44AE18BF.7080002@smile.org.ua> Message-ID: <44AE261F.8020002@city-fan.org> Andy Shevchenko wrote: > Hi, Andreas! > > I can't to update wine in FC4 due to xmessage dependence issue. > There are core's package requirements: > Requires: %{_bindir}/xmessage > Requires: /usr/X11R6/bin/xmessage > > Is it wrong? Discussed on fedora-list a couple of days ago: http://www.redhat.com/archives/fedora-list/2006-July/msg00651.html Should be fixed with the next push. Paul. From pertusus at free.fr Fri Jul 7 09:19:02 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 7 Jul 2006 11:19:02 +0200 Subject: [Bug 197198] Review Request: ntop In-Reply-To: <1152255047.14649.44.camel@mccallum.corsepiu.local> References: <200607070626.k676QmKQ023836@bugzilla.redhat.com> <1152255047.14649.44.camel@mccallum.corsepiu.local> Message-ID: <20060707091902.GB2568@free.fr> > > c.f. info libtool 'Release numbers' > > Upstream is using -release, which is a bad idea. Exactly. In that case I believe it is not that annoying since there won't be any -devel pacakge, still it may get annoying for upstream. -- Pat From michael at knox.net.nz Fri Jul 7 09:24:36 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 07 Jul 2006 21:24:36 +1200 Subject: [Bug 197198] Review Request: ntop In-Reply-To: <20060707091902.GB2568@free.fr> References: <200607070626.k676QmKQ023836@bugzilla.redhat.com> <1152255047.14649.44.camel@mccallum.corsepiu.local> <20060707091902.GB2568@free.fr> Message-ID: <44AE2854.5090002@knox.net.nz> Patrice Dumas wrote: >> c.f. info libtool 'Release numbers' >> >> Upstream is using -release, which is a bad idea. > > Exactly. In that case I believe it is not that annoying since there won't > be any -devel pacakge, still it may get annoying for upstream. > That's what I was thinking, it not that big of a problem, since the libraries aren't split out to devel sub-package, but I was not certain I was on the right page. Hence my asking for clarification :) So should this be fixed or not? How does one fix these sorts of problems? Michael From rc040203 at freenet.de Fri Jul 7 09:33:27 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 07 Jul 2006 11:33:27 +0200 Subject: [Bug 197198] Review Request: ntop In-Reply-To: <44AE2854.5090002@knox.net.nz> References: <200607070626.k676QmKQ023836@bugzilla.redhat.com> <1152255047.14649.44.camel@mccallum.corsepiu.local> <20060707091902.GB2568@free.fr> <44AE2854.5090002@knox.net.nz> Message-ID: <1152264807.14649.68.camel@mccallum.corsepiu.local> On Fri, 2006-07-07 at 21:24 +1200, Michael J. Knox wrote: > Patrice Dumas wrote: > >> c.f. info libtool 'Release numbers' > >> > >> Upstream is using -release, which is a bad idea. > > > > Exactly. In that case I believe it is not that annoying since there won't > > be any -devel pacakge, still it may get annoying for upstream. > > > > That's what I was thinking, it not that big of a problem, since the > libraries aren't split out to devel sub-package, but I was not certain I > was on the right page. Hence my asking for clarification :) > > So should this be fixed or not? If you don't ship a *-devel package, there should not be any need to change anything. > How does one fix these sorts of problems? In general, by contacting upstream and teaching them about their mistakes. If they are capable to learn - fine. If not, you can chose: - Not to ship a package (I usually refuse to approve such packages) - If it's an important package, bite the bullet and ship their crap, but to apply a very conservative update policy - In most cases, this implies not to ship any update during a release) - If it's a non-important package, change the sources (cf. to info libtool, how to supply a proper library versioning) Ralf From pertusus at free.fr Fri Jul 7 09:42:09 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 7 Jul 2006 11:42:09 +0200 Subject: [Bug 197198] Review Request: ntop In-Reply-To: <44AE2854.5090002@knox.net.nz> References: <200607070626.k676QmKQ023836@bugzilla.redhat.com> <1152255047.14649.44.camel@mccallum.corsepiu.local> <20060707091902.GB2568@free.fr> <44AE2854.5090002@knox.net.nz> Message-ID: <20060707094209.GC2568@free.fr> > So should this be fixed or not? How does one fix these sorts of problems? Direct upstream to read info libtool 'Versioning' it describes the issues of binary compatibility and versionning quite precisely. The following are hints based on how it implemented in some packages. In configure.in add something along (change DAPLIB with something appropriate), one for each library: DAPLIB_CURRENT=5 DAPLIB_AGE=0 DAPLIB_REVISION=0 AC_SUBST(DAPLIB_CURRENT) AC_SUBST(DAPLIB_AGE) AC_SUBST(DAPLIB_REVISION) LIBDAP_VERSION="$DAPLIB_CURRENT:$DAPLIB_REVISION:$DAPLIB_AGE" AC_SUBST(LIBDAP_VERSION) And in the Makefile -release $(VERSION) is replaced with -version-info $(LIBDAP_VERSION). Or something along those directions. -- Pat From nicolas.mailhot at laposte.net Fri Jul 7 10:13:55 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 7 Jul 2006 12:13:55 +0200 (CEST) Subject: DejaVu fonts for Fedora Core 6 feedback call In-Reply-To: <20060706110436.4e9c5aa3@voip.int.addix.net> References: <1152079490.23468.0.camel@rousalka.dyndns.org> <20060706110436.4e9c5aa3@voip.int.addix.net> Message-ID: <27457.192.54.193.52.1152267235.squirrel@rousalka.dyndns.org> Le Jeu 6 juillet 2006 11:04, Ralf Ertzinger a ?crit : > One occassion where I noted this is the combination of T with a > smaller letter following (Ta or To, for example). The smaller letter > is very close to the T. I used Vera before, and it hat no such > issue. Tracked as https://bugs.freedesktop.org/show_bug.cgi?id=7450 -- Nicolas Mailhot From bugs.michael at gmx.net Fri Jul 7 11:44:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 7 Jul 2006 13:44:22 +0200 Subject: Anjuta : RFC In-Reply-To: <1152230006.3734.86.camel@T7.Linux> References: <1152230006.3734.86.camel@T7.Linux> Message-ID: <20060707134422.2c371742.bugs.michael@gmx.net> On Fri, 07 Jul 2006 00:53:26 +0100, Paul wrote: > Hi, > > The Anjuta 1 branch has now been closed off with the exception of > security fixes and all involved are concerned with the 2.0 version. > > Currently, anjuta-gdl is in FE with gnome-build and autogen currently > under review. > > What I'm proposing is the following. > > 1. I put Anjuta-2.0.x back through the usual FE review system > 2. When it is accepted, it is imported only into rawhide. > 3. Those using stable and one version back from that, continue to use > 1.2.4a > 4. When all is stable and happy, the following happens > 4a. 1.2.4a is moved to legacy and the 1.x branch removed from FE CVS What do you mean with "branch removed from FE CVS"? There is nothing you should remove in CVS in any special way. Just update your working copy and commit the changes for an upgrade from 1.x to 2.x. > 4b. 2.0.x is imported into the current version and one version back (as > per the FC system) > 5. The world goes on it's ever decreasing spiral. > > Comments? Note that a review is not required for Anjuta 2.x when it is an ordinary version upgrade. It would be your personal decision to request reviews in order to get feedback prior to upgrading the package in FE Development. From bugs.michael at gmx.net Fri Jul 7 11:49:33 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 7 Jul 2006 13:49:33 +0200 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: <44ABD9A7.2040306@leemhuis.info> References: <44ABCDFF.8030609@fedoraproject.org> <44ABD9A7.2040306@leemhuis.info> Message-ID: <20060707134933.45cd9e80.bugs.michael@gmx.net> On Wed, 05 Jul 2006 17:24:23 +0200, Thorsten Leemhuis wrote: > Mike McGrath schrieb: > > Below are the election results for the recent FESCo Election. I'd > > encourage another person to verify these results. The cutoff line was 13. > > Votes | Human_name | Fedora_account_id > > thx for posting the results mmcgrath, thx to the infrastructure team in > general, thx to Toshio and everybody else for programing the voting app > and congrats to all those that got elected. > > But now to the real topic of this mail: What do all of you think about > the whole election. Was it a good idea? Or only wasted time? "Total > Ballots: 69" (we have round about 270 people that were permitted to > vote) looks a bit sad IMHO. ACK. The participation was very disappointing. One would assume the FE contributors would back up old or new members of FESCO much more actively. Not voting leaves too much room for interpretation and could also be understood as disapproval of the nominees. > Anything else we should handle differently in the future? Clearer instructions on how exactly the "13 out of N" election works. Doesn't each nominee need at least 50% of the possible votes? From mattdm at mattdm.org Fri Jul 7 12:03:38 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 7 Jul 2006 08:03:38 -0400 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: <20060707134933.45cd9e80.bugs.michael@gmx.net> References: <44ABCDFF.8030609@fedoraproject.org> <44ABD9A7.2040306@leemhuis.info> <20060707134933.45cd9e80.bugs.michael@gmx.net> Message-ID: <20060707120338.GA1097@jadzia.bu.edu> On Fri, Jul 07, 2006 at 01:49:33PM +0200, Michael Schwendt wrote: > ACK. The participation was very disappointing. > One would assume the FE contributors would back up old or new members of > FESCO much more actively. Not voting leaves too much room for > interpretation and could also be understood as disapproval of the > nominees. I think it was just a lack of interesting controversy. I went and read the list and everyone's ideas and almost didn't vote. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rdieter at math.unl.edu Fri Jul 7 12:51:30 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 07 Jul 2006 07:51:30 -0500 Subject: Packaging questions about libvisual References: Message-ID: Aurelien Bompard wrote: > Hey, > > The new version of Amarok needs to update libvisual from 0.2 to 0.4. This > will break dependencies in libvisual-plugins and gstreamer08-plugins > (that's what "repoquery --whatrequires libvisual.so.0" says). I have four > options : > 1) Warn the maintainers of the dependencies, ask them to try to rebuild > their packages with the new version, update in devel and FC-5, and ask the > maintainers to rebuild their packages for version 0.4. That sounds very > error-prone. > 2) Update to version 0.4 only in devel, disabling visualisation plugins > in > the new amarok. That's not nice to those who like them. > 3) Update to version 0.4 only in devel, and update amarok only in devel > too. That's not nice, amarok is one of these apps for which you always > want the latest version :) > 4) Create a compat-libvisual020 package and update in devel and FC5. That > sounds like the best solution, but may I create this package and import it > in CVS without review ? Are there guidelines for this type of packages ? > > What do you think is best ? IMO, If possible, 1, else a combination of 4 and 1, ie, dropping compat-libvisual (or whatever it's named) when/if all other dependancies are updated to libvisual-0.4. -- Rex From notting at redhat.com Fri Jul 7 12:31:26 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 7 Jul 2006 08:31:26 -0400 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: <20060707134933.45cd9e80.bugs.michael@gmx.net> References: <44ABCDFF.8030609@fedoraproject.org> <44ABD9A7.2040306@leemhuis.info> <20060707134933.45cd9e80.bugs.michael@gmx.net> Message-ID: <20060707123126.GA8047@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > > thx for posting the results mmcgrath, thx to the infrastructure team in > > general, thx to Toshio and everybody else for programing the voting app > > and congrats to all those that got elected. > > > > But now to the real topic of this mail: What do all of you think about > > the whole election. Was it a good idea? Or only wasted time? "Total > > Ballots: 69" (we have round about 270 people that were permitted to > > vote) looks a bit sad IMHO. > > ACK. The participation was very disappointing. Perhaps the voting reminders should be sent individually instead of to the list? I suppose we could survey all the contributors that didn't vote... ... We noticed that you did not vote in the FESCO elections. Was that because... [ ] I didn't have an opinion on the candidates [ ] I didn't notice the call for votes [ ] I don't like *any* of the candidates [ ] I was on vacation [ ] I've stopped working on Fedora [ ] < fill in the reason here > ... Bill From paul at all-the-johnsons.co.uk Fri Jul 7 13:55:00 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 07 Jul 2006 14:55:00 +0100 Subject: Anjuta : RFC In-Reply-To: <20060707134422.2c371742.bugs.michael@gmx.net> References: <1152230006.3734.86.camel@T7.Linux> <20060707134422.2c371742.bugs.michael@gmx.net> Message-ID: <1152280500.3734.95.camel@T7.Linux> Hi, > > 4a. 1.2.4a is moved to legacy and the 1.x branch removed from FE CVS > > What do you mean with "branch removed from FE CVS"? Currently, when I do a cvs co for anjuta, directories for RH-9 to FC-devel are checked out. What I propose is that for anjuta-2.x is that only rawhide, the current version and one version back exists, the rest are shifted to legacy (which I don't have any real interest in supporting). Apologies if I've used the wrong terminology. > Note that a review is not required for Anjuta 2.x when it is an ordinary > version upgrade. It would be your personal decision to request reviews in > order to get feedback prior to upgrading the package in FE Development. Anjuta-2.x is almost (but not quite) a different beast to anjuta-1.x. While I'm aware that I just have to do a fresh import for the upgrade, I'd rather get the new package peer reviewed incase I've broken something while building etc. Anjuta-2.x is not a trivial package! TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 7 14:04:11 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Jul 2006 10:04:11 -0400 Subject: Anjuta : RFC In-Reply-To: <1152280500.3734.95.camel@T7.Linux> References: <1152230006.3734.86.camel@T7.Linux> <20060707134422.2c371742.bugs.michael@gmx.net> <1152280500.3734.95.camel@T7.Linux> Message-ID: <200607071004.14739.jkeating@redhat.com> On Friday 07 July 2006 09:55, Paul wrote: > Currently, when I do a cvs co for anjuta, directories for RH-9 to > FC-devel are checked out. What I propose is that for anjuta-2.x is that > only rawhide, the current version and one version back exists, the rest > are shifted to legacy (which I don't have any real interest in > supporting). Apologies if I've used the wrong terminology. If any sort of "legacy" were to maintain that package, it would be within the same module space. The security response team is who would issue updates for the releases you don't care about anymore, and they would do so from the existing module, not copying all the cvs to yet another tree. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Christian.Iseli at licr.org Fri Jul 7 14:16:19 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 07 Jul 2006 16:16:19 +0200 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: Your message of "Fri, 07 Jul 2006 08:31:26 EDT." <20060707123126.GA8047@nostromo.devel.redhat.com> Message-ID: <200607071416.k67EGJSK007929@ludwig-alpha.unil.ch> notting at redhat.com said: > I suppose we could survey all the contributors that didn't vote... A bit nosy/pushy I guess, but why not try... Christian From bugs.michael at gmx.net Fri Jul 7 14:22:39 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 7 Jul 2006 16:22:39 +0200 Subject: Anjuta : RFC In-Reply-To: <1152280500.3734.95.camel@T7.Linux> References: <1152230006.3734.86.camel@T7.Linux> <20060707134422.2c371742.bugs.michael@gmx.net> <1152280500.3734.95.camel@T7.Linux> Message-ID: <20060707162239.dc0021e2.bugs.michael@gmx.net> On Fri, 07 Jul 2006 14:55:00 +0100, Paul wrote: > Hi, > > > > 4a. 1.2.4a is moved to legacy and the 1.x branch removed from FE CVS > > > > What do you mean with "branch removed from FE CVS"? > > Currently, when I do a cvs co for anjuta, directories for RH-9 to > FC-devel are checked out. What I propose is that for anjuta-2.x is that > only rawhide, the current version and one version back exists, the rest > are shifted to legacy (which I don't have any real interest in > supporting). Apologies if I've used the wrong terminology. There are several options: 1) Only check out individual branches: cvs co anjuta/devel anjuta/FC-5 2) Remove all files from the old unsupported branches with "cvs remove -fR" and commit the empty directories. They could be resurrected (= checked out) by anybody who is still interested in them. If, however, you want a cvs admin to remove directories at the server-level, this should be decided by FESCO first. Whether and when old branches (like RHL-9) might be purged, should not be decided by the individual packagers, since the corresponding requests in the Wiki would require too much extra work by the cvs admins. From paul at all-the-johnsons.co.uk Fri Jul 7 14:50:30 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 07 Jul 2006 15:50:30 +0100 Subject: Anjuta : RFC In-Reply-To: <20060707162239.dc0021e2.bugs.michael@gmx.net> References: <1152230006.3734.86.camel@T7.Linux> <20060707134422.2c371742.bugs.michael@gmx.net> <1152280500.3734.95.camel@T7.Linux> <20060707162239.dc0021e2.bugs.michael@gmx.net> Message-ID: <1152283830.3734.98.camel@T7.Linux> Hi, > There are several options: > > 1) Only check out individual branches: > > cvs co anjuta/devel anjuta/FC-5 > > 2) Remove all files from the old unsupported branches with "cvs remove > -fR" and commit the empty directories. They could be resurrected (= > checked out) by anybody who is still interested in them. I'll think this over. In the meantime, I've now got Anjuta-2.0.2-3 built and running through mock. The only thing holding it being put into the big bad world is gnome-build and autogen needing their reviews completed. TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 mmcgrath at fedoraproject.org Fri Jul 7 15:23:03 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 07 Jul 2006 10:23:03 -0500 Subject: Opinions on the election In-Reply-To: <20060707134933.45cd9e80.bugs.michael@gmx.net> References: <44ABCDFF.8030609@fedoraproject.org> <44ABD9A7.2040306@leemhuis.info> <20060707134933.45cd9e80.bugs.michael@gmx.net> Message-ID: <44AE7C57.7030701@fedoraproject.org> Michael Schwendt wrote: > On Wed, 05 Jul 2006 17:24:23 +0200, Thorsten Leemhuis wrote: > > >> Mike McGrath schrieb: >> >>> Below are the election results for the recent FESCo Election. I'd >>> encourage another person to verify these results. The cutoff line was 13. >>> Votes | Human_name | Fedora_account_id >>> >> thx for posting the results mmcgrath, thx to the infrastructure team in >> general, thx to Toshio and everybody else for programing the voting app >> and congrats to all those that got elected. >> >> But now to the real topic of this mail: What do all of you think about >> the whole election. Was it a good idea? Or only wasted time? "Total >> Ballots: 69" (we have round about 270 people that were permitted to >> vote) looks a bit sad IMHO. >> > > ACK. The participation was very disappointing. > I think low participation is just an indication that the previous FESCo was doing a good job. People become complacent when things are going well. Besides that though, think about how hard it is for us to get people to rebuild their packages during a mass rebuild. I guess we'll have to see how things are during the next election. -Mike From Christian.Iseli at licr.org Fri Jul 7 15:34:48 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 07 Jul 2006 17:34:48 +0200 Subject: Package review stats Message-ID: <200607071534.k67FYmA5009008@ludwig-alpha.unil.ch> Hi folks, I wrote a little tool to gather some stats on the rate of opened/closed package review tickets. I attach a PNG with the plotted data (hoping it gets through the ml...) Getting open date is easy and correct, but the close date is another matter. So ATM I just grab the last time the ticket was modified. To get the real close date, I should grab the "bug activity" table, but I don't know how to do it in batch mode... so if anyone can clue me in, that'd be great (short of sending over 1000 requests to show_activity.cgi and parsing the returned table, that is...) The somewhat worrisome fact is that the queue of still open tickets is steadily growing... Cheers, Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: bzstat.png Type: image/png Size: 14439 bytes Desc: bzstat.png URL: From rvinyard at cs.nmsu.edu Fri Jul 7 15:44:10 2006 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Fri, 07 Jul 2006 09:44:10 -0600 Subject: rpms/bit/devel bit.spec,1.1,1.2 In-Reply-To: <1152257252.14649.49.camel@mccallum.corsepiu.local> References: <200607070723.k677NNnc019460@cvs-int.fedora.redhat.com> <1152257252.14649.49.camel@mccallum.corsepiu.local> Message-ID: <44AE814A.5050600@cs.nmsu.edu> Ralf Corsepius wrote: > On Fri, 2006-07-07 at 00:23 -0700, Rick L. Vinyard wrote: > >> Author: rvinyard >> =================================================================== >> RCS file: /cvs/extras/rpms/bit/devel/bit.spec,v >> ;' >> -%{__rm} -rf %{buildroot}/usr/bin >> +%{__rm} -rf %{buildroot}/%{_bindir} >> > > This should be: > %{__rm} -rf %{buildroot}%{_bindir} > > Note %{_bindir}, not /%{_bindir} > > Ralf > > Got it. Thanks again Ralf. From tibbs at math.uh.edu Fri Jul 7 16:31:41 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 07 Jul 2006 11:31:41 -0500 Subject: Package review stats In-Reply-To: <200607071534.k67FYmA5009008@ludwig-alpha.unil.ch> (Christian Iseli's message of "Fri, 07 Jul 2006 17:34:48 +0200") References: <200607071534.k67FYmA5009008@ludwig-alpha.unil.ch> Message-ID: >>>>> "CI" == Christian Iseli writes: CI> The somewhat worrisome fact is that the queue of still open CI> tickets is steadily growing... I think we've been able to hold it mostly steady lately, especially if you discount tickets blocked on guidelines. Still, I'm not sure what's represented by "queue size". Does this include just FE-NEW tickets, or FE-REVIEW tickets as well? What about FC-* tickets? One problem I'm having is lack of action on approved packages. I have a couple where I know the package submitters are active, reviewing and commenting on other tickets and posting messages to the list, but won't act on their packages. Thanks for doing this; these statistics are quite useful. - J< From Christian.Iseli at licr.org Fri Jul 7 16:48:02 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 07 Jul 2006 18:48:02 +0200 Subject: Package review stats In-Reply-To: Your message of "Fri, 07 Jul 2006 11:31:41 CDT." Message-ID: <200607071648.k67Gm8j5025169@mx1.redhat.com> tibbs at math.uh.edu said: > I think we've been able to hold it mostly steady lately, especially if you > discount tickets blocked on guidelines. Still, I'm not sure what's > represented by "queue size". Does this include just FE-NEW tickets, or > FE-REVIEW tickets as well? Ah yes, I guess I should've explained a bit better... :-) The script grabs all "Package Review" tickets. It then looks at "opendate" and counts the number of opened ticket, and keeps a running count of opened tickets. Second, it looks at "changeddate", and if the package is marked CLOSED, it will have a look at the RESOLUTION field to categorize a bit. The script counts the number of closed tickets per week (though ATM that's biased because the date looked at is the changeddate...) and keeps a running count of all closed tickets. The queue length is the difference between the opened and the closed ticket running sum. So, in short, it's FE-NEW + FE-REVIEW + still open FE-ACCEPT... > What about FC-* tickets? I didn't check those. It'd be quite easy to, though... The script is here: http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/?root=fedora (named grabBZstats) > One problem I'm having is lack of action on approved packages. I have a > couple where I know the package submitters are active, reviewing and > commenting on other tickets and posting messages to the list, but won't act > on their packages. Have you tried to ping 'em ? Christian From jima at beer.tclug.org Fri Jul 7 17:06:02 2006 From: jima at beer.tclug.org (Jima) Date: Fri, 7 Jul 2006 12:06:02 -0500 (CDT) Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: <20060707120338.GA1097@jadzia.bu.edu> References: <44ABCDFF.8030609@fedoraproject.org> <44ABD9A7.2040306@leemhuis.info> <20060707134933.45cd9e80.bugs.michael@gmx.net> <20060707120338.GA1097@jadzia.bu.edu> Message-ID: On Fri, 7 Jul 2006, Matthew Miller wrote: > On Fri, Jul 07, 2006 at 01:49:33PM +0200, Michael Schwendt wrote: >> ACK. The participation was very disappointing. >> One would assume the FE contributors would back up old or new members of >> FESCO much more actively. Not voting leaves too much room for >> interpretation and could also be understood as disapproval of the >> nominees. > > I think it was just a lack of interesting controversy. I went and read the > list and everyone's ideas and almost didn't vote. Okay, so we'll have to stage a scandal next election. Someone needs to anonymously attest that they saw Dennis Gilmore install Ubuntu on his T1000, or something.* Then he'll in turn fling mud back at whoever arranged that relevation (oops, maybe I shouldn't have said that), and you can guess where that'll go. Then someone will probably bribe Sopwith to "make a few database adjustments" during the election, which will lead to a Fedora Advisory Board investigation, and then all bets are off who will be on FESCo. Maybe THAT will drum up enough interest in the election. For that matter, maybe I sullied Dennis's reputation enough that a sufficient majority of Fedora contributors will demand a recall, during which Alan Cox will be elected to replace him. Aren't politics fun? Jima [*] This actually happened, but only so he could figure out what drivers Aurora needed enabled. From dennis at ausil.us Fri Jul 7 17:19:30 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 7 Jul 2006 12:19:30 -0500 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: References: <44ABCDFF.8030609@fedoraproject.org> <20060707120338.GA1097@jadzia.bu.edu> Message-ID: <200607071219.30745.dennis@ausil.us> On Friday 07 July 2006 12:06, Jima wrote: > On Fri, 7 Jul 2006, Matthew Miller wrote: > > On Fri, Jul 07, 2006 at 01:49:33PM +0200, Michael Schwendt wrote: > >> ACK. The participation was very disappointing. > >> One would assume the FE contributors would back up old or new members of > >> FESCO much more actively. Not voting leaves too much room for > >> interpretation and could also be understood as disapproval of the > >> nominees. > > > > I think it was just a lack of interesting controversy. I went and read > > the list and everyone's ideas and almost didn't vote. > > Okay, so we'll have to stage a scandal next election. Someone needs to > anonymously attest that they saw Dennis Gilmore install Ubuntu on his > T1000, or something.* Then he'll in turn fling mud back at whoever > arranged that relevation (oops, maybe I shouldn't have said that), and you > can guess where that'll go. Then someone will probably bribe Sopwith to > "make a few database adjustments" during the election, which will lead to > a Fedora Advisory Board investigation, and then all bets are off who will > be on FESCo. Maybe THAT will drum up enough interest in the election. > For that matter, maybe I sullied Dennis's reputation enough that a > sufficient majority of Fedora contributors will demand a recall, during > which Alan Cox will be elected to replace him. > Aren't politics fun? > > Jima > > [*] This actually happened, but only so he could figure out what drivers > Aurora needed enabled. ok ubuntu lived on that machine all of a few minutes. I can say that it was the worst installer anywhere on this planet. forcing X configuration for a machine with no video card is wrong. along with many other just wrong things, plus it took longer to install than it ran on the machine. But i think i forgot to add to the wiki that a vote for me was a vote for SPARC as an offically supported arch. So now we need to add some SPARC builders to the buildsys :D. Sopwith will get mad at me remove all my votes from the DB and all hell breaks loose. But seriously I would like to know some reasons why people who did not vote, choose to not vote. Was he voting window too short? was there not enough noise about the election? and people just plain forgot? Dennis From skvidal at linux.duke.edu Fri Jul 7 17:30:31 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 07 Jul 2006 13:30:31 -0400 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: <200607071219.30745.dennis@ausil.us> References: <44ABCDFF.8030609@fedoraproject.org> <20060707120338.GA1097@jadzia.bu.edu> <200607071219.30745.dennis@ausil.us> Message-ID: <1152293432.16624.2.camel@cutter> On Fri, 2006-07-07 at 12:19 -0500, Dennis Gilmore wrote: > ok ubuntu lived on that machine all of a few minutes. I can say that it was > the worst installer anywhere on this planet. forcing X configuration for a > machine with no video card is wrong. along with many other just wrong things, > plus it took longer to install than it ran on the machine. > So you're a FLIP FLOPPER!!! ;) Sorry, I couldn't resist. -sv From gemi at bluewin.ch Fri Jul 7 17:48:21 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 07 Jul 2006 19:48:21 +0200 Subject: Zaurus connecting USB error Message-ID: <1152294501.3039.1.camel@scriabin.tannenrauch.ch> I cannot connect a Zaurus SL-6000L via USB. This should normally provided the Zaurus filesystem as a USB mass storage device, but I get the following: Jul 7 19:46:08 scriabin kernel: usb 4-6.1: new full speed USB device using ehci_hcd and address 10 Jul 7 19:46:08 scriabin kernel: usb 4-6.1: device descriptor read/64, error -32Jul 7 19:46:09 scriabin kernel: usb 4-6.1: device descriptor read/64, error -32Jul 7 19:46:09 scriabin kernel: usb 4-6.1: new full speed USB device using ehci_hcd and address 11 Jul 7 19:46:09 scriabin kernel: usb 4-6.1: device descriptor read/64, error -32Jul 7 19:46:09 scriabin kernel: usb 4-6.1: device descriptor read/64, error -32Jul 7 19:46:09 scriabin kernel: usb 4-6.1: new full speed USB device using ehci_hcd and address 12 Jul 7 19:46:10 scriabin kernel: usb 4-6.1: device not accepting address 12, error -32 Jul 7 19:46:10 scriabin kernel: usb 4-6.1: new full speed USB device using ehci_hcd and address 13 Jul 7 19:46:10 scriabin kernel: usb 4-6.1: device not accepting address 13, error -32 BTW, where can the meaning for the error number be found? Regards, -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From tibbs at math.uh.edu Fri Jul 7 17:53:52 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 07 Jul 2006 12:53:52 -0500 Subject: Package review stats In-Reply-To: <200607071648.k67Gm8j5025169@mx1.redhat.com> (Christian Iseli's message of "Fri, 07 Jul 2006 18:48:02 +0200") References: <200607071648.k67Gm8j5025169@mx1.redhat.com> Message-ID: >>>>> "CI" == Christian Iseli writes: CI> So, in short, it's FE-NEW + FE-REVIEW + still open FE-ACCEPT... OK, that makes more sense. Personally I only worry about FE-NEW plus my personal FE-REVIEW and FE-ACCEPT stuff. I think we're doing a reasonable job of keeping FE-NEW under control. Occasionally it climbs up and then gets beaten back down. The recent blast of PHP stuff that's blocked on guidelines and a long chain of interdependent Perl modules account for most of the recent growth. I'll have the Perl modules finished up soon. CI> Have you tried to ping 'em ? Several times. I'm starting to revoke my approvals and close the tickets. - J< From gemi at bluewin.ch Fri Jul 7 17:57:12 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 07 Jul 2006 19:57:12 +0200 Subject: Zaurus connecting USB error In-Reply-To: <1152294501.3039.1.camel@scriabin.tannenrauch.ch> References: <1152294501.3039.1.camel@scriabin.tannenrauch.ch> Message-ID: <1152295032.3039.3.camel@scriabin.tannenrauch.ch> On Fri, 2006-07-07 at 19:48 +0200, G?rard Milmeister wrote: Sorry, wrong list. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From Christian.Iseli at licr.org Fri Jul 7 18:21:34 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 07 Jul 2006 20:21:34 +0200 Subject: Package review stats In-Reply-To: Your message of "Fri, 07 Jul 2006 12:53:52 CDT." Message-ID: <200607071821.k67ILZhr003980@mx3.redhat.com> tibbs at math.uh.edu said: > Personally I only worry about FE-NEW plus my personal FE-REVIEW and FE-ACCEPT > stuff. I think we're doing a reasonable job of keeping FE-NEW under control. Yea, I think so too. If you'd like to see a separate count of FE-NEW, I can add it pretty easily. > Occasionally it climbs up and then gets beaten back down. The recent blast > of PHP stuff that's blocked on guidelines and a long chain of interdependent > Perl modules account for most of the recent growth. Right. > I'll have the Perl modules finished up soon. I'm positively impressed. :-) > I'm starting to revoke my approvals and close the tickets. Sad. And disappointing... Christian From florin at andrei.myip.org Fri Jul 7 18:34:41 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 07 Jul 2006 11:34:41 -0700 Subject: RogueScanner Message-ID: <1152297281.9960.3.camel@stantz.corp.sgi.com> Anybody planning to build an RPM with RogueScanner for Extras? http://roguescanner.networkchemistry.net/ It's a wireless scanner, similar to Kismet. -- Florin Andrei http://florin.myip.org/ From jima at beer.tclug.org Fri Jul 7 18:51:37 2006 From: jima at beer.tclug.org (Jima) Date: Fri, 7 Jul 2006 13:51:37 -0500 (CDT) Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: <200607071219.30745.dennis@ausil.us> References: <44ABCDFF.8030609@fedoraproject.org> <20060707120338.GA1097@jadzia.bu.edu> <200607071219.30745.dennis@ausil.us> Message-ID: On Fri, 7 Jul 2006, Dennis Gilmore wrote: > But i think i forgot to add to the wiki that a vote for me was a vote for > SPARC as an offically supported arch. So now we need to add some SPARC > builders to the buildsys :D. Sopwith will get mad at me remove all my > votes from the DB and all hell breaks loose. Well, one of Spot's platforms implied that without actually saying as much (although I think everyone knows what it meant, especially since he mentioned Aurora): "Work towards enabling Fedora to truly grow beyond x86/x86_64, with a multiple tiered architecture model" > But seriously I would like to know some reasons why people who did not > vote, choose to not vote. Was he voting window too short? was there not > enough noise about the election? and people just plain forgot? Voter apathy is a very sad thing. :( Jima From tibbs at math.uh.edu Fri Jul 7 20:12:06 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 07 Jul 2006 15:12:06 -0500 Subject: This week's FESCo Meeting Summary In-Reply-To: <1152229246.24961.270.camel@localhost> (Toshio Kuratomi's message of "Thu, 06 Jul 2006 16:40:45 -0700") References: <1152229246.24961.270.camel@localhost> Message-ID: TK> Creating a new tracker bug FE-GUIDELINES to block bugs which are TK> stuck because guidelines are in flux (as in php extensions are TK> being worked on right now) I have created FE-GUIDELINES and started adding some bugs as blockers, although I'm probably not going about it in the simplest way. Others should feel free to set appropriate tickets to block this bug. - J< From mpeters at mac.com Fri Jul 7 20:21:58 2006 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 07 Jul 2006 13:21:58 -0700 Subject: Opinions on the election (was: Re: FESCo Election Results) In-Reply-To: References: <44ABCDFF.8030609@fedoraproject.org> <20060707120338.GA1097@jadzia.bu.edu> <200607071219.30745.dennis@ausil.us> Message-ID: <1152303719.5989.15.camel@atlantis.mpeters.local> On Fri, 2006-07-07 at 13:51 -0500, Jima wrote: > > > But seriously I would like to know some reasons why people who did not > > vote, choose to not vote. Was he voting window too short? was there not > > enough noise about the election? and people just plain forgot? > > Voter apathy is a very sad thing. :( I did not vote because I've suddenly become swamped with work including travel, and have not had the opportunity to pay much time to Linux let alone Extras for the past month or so. I did not see anyone nominated that I had a problem with though, so I can blindly say I'm probably happy with the results, any of them. From j.w.r.degoede at hhs.nl Fri Jul 7 20:34:49 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 07 Jul 2006 22:34:49 +0200 Subject: Short vacation Message-ID: <44AEC569.6090901@hhs.nl> Hi All, I'm going on a short vacation from Monday 10 juli till Friday 14 juli, so if I'm not responding to any queries thats why. I here by grant other FE contributers permission to make and push changes to my packages in case of emergency (like gnumeric eating spreadsheets :) Regards, Hans From peter at thecodergeek.com Fri Jul 7 20:34:13 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 07 Jul 2006 13:34:13 -0700 Subject: Short vacation In-Reply-To: <44AEC569.6090901@hhs.nl> References: <44AEC569.6090901@hhs.nl> Message-ID: <44AEC545.2020004@thecodergeek.com> Hans de Goede wrote: > I'm going on a short vacation from Monday 10 juli till Friday 14 juli, > so if I'm not responding to any queries thats why. Have a great time, and stay safe! :D -- 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: 251 bytes Desc: OpenPGP digital signature URL: From tibbs at math.uh.edu Fri Jul 7 20:38:54 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 07 Jul 2006 15:38:54 -0500 Subject: Package review stats In-Reply-To: <200607071821.k67ILZhr003980@mx3.redhat.com> (Christian Iseli's message of "Fri, 07 Jul 2006 20:21:34 +0200") References: <200607071821.k67ILZhr003980@mx3.redhat.com> Message-ID: >>>>> "CI" == Christian Iseli writes: >> I'm starting to revoke my approvals and close the tickets. CI> Sad. And disappointing... To be fair, some of these had been sitting for a while before I reviewed them. Some sat for so long that it would not be surprising to me if the the submitters had completely lost interest. - J< From gajownik at gmail.com Fri Jul 7 20:47:03 2006 From: gajownik at gmail.com (Dawid Gajownik) Date: Fri, 07 Jul 2006 22:47:03 +0200 Subject: Short vacation In-Reply-To: <44AEC569.6090901@hhs.nl> References: <44AEC569.6090901@hhs.nl> Message-ID: <44AEC847.3020303@gmail.com> Dnia 07/07/2006 10:32 PM, U?ytkownik Hans de Goede napisa?: > Hi All, Hi! > I'm going on a short vacation from Monday 10 juli till Friday 14 juli, > so if I'm not responding to any queries thats why. You may want to update this page ? http://fedoraproject.org/wiki/Vacation Have a nice time! Regards, Dawid -- ^_* From jwboyer at jdub.homelinux.org Fri Jul 7 20:45:59 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 07 Jul 2006 15:45:59 -0500 Subject: Package review stats In-Reply-To: <200607071821.k67ILZhr003980@mx3.redhat.com> References: <200607071821.k67ILZhr003980@mx3.redhat.com> Message-ID: <1152305159.17827.7.camel@weaponx.rchland.ibm.com> On Fri, 2006-07-07 at 20:21 +0200, Christian.Iseli at licr.org wrote: > tibbs at math.uh.edu said: > > Personally I only worry about FE-NEW plus my personal FE-REVIEW and FE-ACCEPT > > stuff. I think we're doing a reasonable job of keeping FE-NEW under control. > > Yea, I think so too. > > If you'd like to see a separate count of FE-NEW, I can add it pretty easily. > > > Occasionally it climbs up and then gets beaten back down. The recent blast > > of PHP stuff that's blocked on guidelines and a long chain of interdependent > > Perl modules account for most of the recent growth. > > Right. > > > I'll have the Perl modules finished up soon. > > I'm positively impressed. :-) > > > I'm starting to revoke my approvals and close the tickets. > > Sad. And disappointing... Actually, it's probably for the better. I'd rather a review request get canceled than have to orphan a package that made it in without real interest. josh From Christian.Iseli at licr.org Fri Jul 7 21:46:59 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 07 Jul 2006 23:46:59 +0200 Subject: Package review stats In-Reply-To: Your message of "Fri, 07 Jul 2006 15:45:59 CDT." <1152305159.17827.7.camel@weaponx.rchland.ibm.com> Message-ID: <200607072147.k67Ll5wH022534@mx3.redhat.com> jwboyer at jdub.homelinux.org said: > I'd rather a review request get canceled than have to orphan a package that > made it in without real interest. Agreed. Christian From bugzilla at redhat.com Fri Jul 7 22:07:50 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 7 Jul 2006 18:07:50 -0400 Subject: [Bug 180066] Request: Inclusion of a ruby template file In-Reply-To: Message-ID: <200607072207.k67M7owm023903@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Request: Inclusion of a ruby template file https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180066 dlutter at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Flag|needinfo? | ------- Additional Comments From dlutter at redhat.com 2006-07-07 17:59 EST ------- Thanks for fixing the BuildArch thing With the names of the *_site* macros, I tried to stay consistent with the entries in Config::CONFIG that get read out, but I am fine with dropping the *dir and making it look like perl/python. I'll update the packaging guidelines to use those shorter names, too. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From mpeters at mac.com Fri Jul 7 22:51:40 2006 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 07 Jul 2006 15:51:40 -0700 Subject: Short vacation In-Reply-To: <44AEC569.6090901@hhs.nl> References: <44AEC569.6090901@hhs.nl> Message-ID: <1152312701.5989.32.camel@atlantis.mpeters.local> On Fri, 2006-07-07 at 22:34 +0200, Hans de Goede wrote: > > I here by grant other FE contributers permission to make and push > changes to my packages in case of emergency (like gnumeric eating > spreadsheets :) Isn't that a feature? Oh wait - this is Fedora list, not MS list. From buildsys at fedoraproject.org Fri Jul 7 23:25:52 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 7 Jul 2006 19:25:52 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-07 Message-ID: <20060707232552.EFCF2152184@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 48 CastPodder-5.0-7.fc5 TurboGears-0.8.9-2.fc5 amavisd-new-2.4.1-1.fc5 anjuta-1.2.4a-4.fc5 asymptote-1.11-1.fc5 bit-0.2.2-4.fc5 conman-0.1.9.2-3.fc5 connect-proxy-1.95-4.fc5 gdmap-0.7.5-3.fc5 glabels-2.0.4-3.fc5 gtk-qt-engine-0.70-1.fc5 gxemul-0.4.0.1-2.fc5 highlight-2.4.7-1.fc5 lout-3.30-5.fc5 ode-0.6-2.fc5 pam_mount-0.13.0-6.fc5 perl-Apache-Session-Wrapper-0.29-1.fc5 perl-Class-MakeMethods-1.01-1.fc5 perl-File-ReadBackwards-1.04-1.fc5 perl-HTML-Tree-3.20-1.fc5 perl-Image-ExifTool-6.26-1.fc5 perl-Locale-SubCountry-1.37-1.fc5 perl-Math-Round-0.05-1.fc5 perl-OLE-Storage_Lite-0.14-7.fc5 perl-Object-InsideOut-1.45-1.fc5 perl-Package-Constants-0.01-1.fc5 perl-Params-Util-0.15-1.fc5 perl-Pod-POM-0.17-5.fc5 perl-Set-Infinite-0.61-1.fc5 perl-Spreadsheet-WriteExcel-2.17-1.fc5 perl-Template-Plugin-Class-0.13-1.fc5 perl-Test-WWW-Mechanize-1.12-1.fc5 perl-Tie-DBI-1.02-1.fc5 perl-version-0.64-1.fc5 python-cvstoys-1.0.10-3.fc5 python-kid-0.9.2-1.fc5 python-lxml-1.0.2-1.fc5 python-matplotlib-0.87.3-1.fc5 python-sqlalchemy-0.2.4-1.fc5 qt4-4.1.4-5.fc5 renrot-0.21.1-2.fc5 repoview-0.5.2-1.fc5 stellarium-0.8.1-1.fc5 sylpheed-claws-plugins-2.3.0-2.fc5 trac-0.9.6-1.fc5 uim-1.1.1-1.fc5 wifiroamd-1.09-1.fc5 xsupplicant-1.2.6-1.fc5 Packages built and released for Fedora Extras 4: 40 amavisd-new-2.4.1-1.fc4 anjuta-1.2.4a-4.fc4 asymptote-1.11-1.fc4 bit-0.2.2-4.fc4 conman-0.1.9.2-3.fc4 connect-proxy-1.95-4.fc4 dillo-0.8.6-2.fc4 glabels-2.0.4-2.fc4 gtk-qt-engine-0.70-1.fc4 gxemul-0.4.0.1-2.fc4 lout-3.30-5.fc4 perl-Apache-Session-Wrapper-0.29-1.fc4 perl-Class-MakeMethods-1.01-1.fc4 perl-File-ReadBackwards-1.04-1.fc4 perl-Image-ExifTool-6.26-1.fc4 perl-Locale-SubCountry-1.37-1.fc4 perl-Math-Round-0.05-1.fc4 perl-OLE-Storage_Lite-0.14-7.fc4 perl-Package-Constants-0.01-1.fc4 perl-Params-Util-0.15-1.fc4 perl-Pod-POM-0.17-5.fc4 perl-Set-Infinite-0.61-1.fc4 perl-Spreadsheet-WriteExcel-2.17-1.fc4 perl-Template-Plugin-Class-0.13-1.fc4 perl-Test-WWW-Mechanize-1.12-1.fc4 perl-Tie-DBI-1.02-1.fc4 perl-version-0.64-1.fc4 python-cvstoys-1.0.10-3.fc4 python-kid-0.9.2-1.fc4 python-lxml-1.0.2-1.fc4 python-sqlalchemy-0.2.4-1.fc4 qt4-4.1.4-5.fc4 renrot-0.21.1-2.fc4 repoview-0.5.2-1.fc4 sylpheed-claws-plugins-2.3.0-2.fc4 trac-0.9.6-1.fc4 uim-1.1.1-1.fc4 wifiroamd-1.09-1.fc4 wine-0.9.16-2.fc4 xsupplicant-1.2.6-1.fc4 Packages built and released for Fedora Extras 3: 4 amavisd-new-2.4.1-1.fc3 git-1.4.1-1.fc3 gtk-qt-engine-0.70-1.fc3.1 wine-0.9.16-2.fc3 Packages built and released for Fedora Extras development: 69 CastPodder-5.0-7.fc6 TurboGears-0.8.9-2.fc6 allegro-4.2.0-15.fc6 anjuta-1.2.4a-4.fc6 asymptote-1.11-1.fc6 bit-0.2.2-4.fc6 coldet-1.1-3.fc6 conman-0.1.9.2-3.fc6 connect-proxy-1.95-4.fc6 cppunit-1.12.0-1.fc6 crystal-stacker-1.5-2.fc6 drgeo-1.1.0-10.fc6 erlang-R11B-0.2.fc6 gdmap-0.7.5-3.fc6 git-1.4.1-1.fc6 glabels-2.0.4-3.fc6 grads-1.9b4-12.fc6 gtk-qt-engine-0.70-1.fc6 gxemul-0.4.0.1-2.fc6 highlight-2.4.7-1.fc6 lacewing-1.10-6.fc6 libhugetlbfs-0.20060706-1.fc6 lout-3.30-5.fc6 ode-0.6-2.fc6 ogre-1.2.1-2.fc6 overgod-1.0-4.fc6 pam_mount-0.13.0-8.fc6 perl-Algorithm-Annotate-0.10-4.fc6 perl-Apache-Session-Wrapper-0.29-1.fc6 perl-BerkeleyDB-0.29-1.fc6 perl-Class-InsideOut-1.00-1.fc6 perl-Class-MakeMethods-1.01-1.fc6 perl-DateTime-Set-0.25-2.fc6 perl-File-ReadBackwards-1.04-1.fc6 perl-HTML-Tree-3.20-1.fc6 perl-Image-ExifTool-6.26-1.fc6 perl-Locale-SubCountry-1.37-1.fc6 perl-OLE-Storage_Lite-0.14-7.fc6 perl-Object-InsideOut-1.45-1.fc6 perl-Package-Constants-0.01-1.fc6 perl-Params-Check-0.25-1.fc6 perl-Params-Util-0.15-1.fc6 perl-Pod-POM-0.17-5.fc6 perl-Set-Infinite-0.61-1.fc6 perl-Spreadsheet-WriteExcel-2.17-1.fc6 perl-Template-Plugin-Class-0.13-1.fc6 perl-Test-WWW-Mechanize-1.12-1.fc6 perl-Tie-DBI-1.02-1.fc6 perl-WWW-Myspace-0.49-1.fc6 perl-YAML-0.62-1.fc6 perl-version-0.64-1.fc6 python-cvstoys-1.0.10-3.fc6 python-kid-0.9.2-1.fc6 python-lxml-1.0.2-1.fc6 python-sqlalchemy-0.2.4-1.fc6 rafkill-1.2.1-2.fc6 raidem-0.3.1-3.fc6 renrot-0.21.1-2.fc6 repoview-0.5.2-1.fc6 shippy-1.3.3.7-3.fc6 stellarium-0.8.1-1.fc6 sylpheed-claws-plugins-2.3.0-2.fc6 trac-0.9.6-1.fc6 uim-1.1.1-1.fc6 wifiroamd-1.09-1.fc6 worminator-3.0R2.1-4.fc6 x3270-3.3.4p7-2.fc6 xsupplicant-1.2.6-1.fc6 zasx-1.30-2.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri Jul 7 23:45:20 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 7 Jul 2006 19:45:20 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-07 Message-ID: <20060707234520.9A5A4152184@buildsys.fedoraproject.org> abiword: 5: 1:2.4.4-4.fc5 (FE5) 6: 1:2.4.4-2.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) brightside: 5: 0:1.4.0-11.fc5 (FE5) 6: 0:1.4.0-10.fc5 (FE6) cairo-java: 5: 0:1.0.4-0.FC5 (FC5-updates) 6: 0:1.0.4-0 (FC6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.0 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) dovecot: 5: 0:1.0-0.beta8.2.fc5 (FC5-updates) 6: 0:1.0-0.beta8.2 (FC6) ecl: 5: 0:0.9h-6.fc5 (FE5) 6: 0:0.9h-5.fc5 (FE6) eclipse-changelog: 5: 1:2.1.0_fc-2 (FC5-updates) 6: 1:2.1.0_fc-1 (FC6) factory: 5: 0:2.0.5-7.fc5 (FE5) 6: 0:2.0.5-6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) ghdl: 5: 0:0.23-0.58svn.1.fc5 (FE5) 6: 0:0.23-0.58svn.0.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) glib-java: 5: 0:0.2.5-0.FC5 (FC5-updates) 6: 0:0.2.5-0 (FC6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) hspell: 4: 0:1.0-4.fc4 (FE4) 5: 0:1.0-3.fc5 (FE5) 6: 0:1.0-3.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libfac: 5: 0:2.0.5-4.fc5 (FE5) 6: 0:2.0.5-3 (FE6) libglade-java: 5: 0:2.12.4-0.FC5 (FC5-updates) 6: 0:2.12.4-0 (FC6) libgnome-java: 5: 0:2.12.3-0.FC5 (FC5-updates) 6: 0:2.12.3-0 (FC6) libgtk-java: 5: 0:2.8.5-0.FC5 (FC5-updates) 6: 0:2.8.5-0 (FC6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libvte-java: 5: 0:0.12.0-0.FC5 (FC5-updates) 6: 0:0.12.0-0 (FC6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-11.fc6 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-Net-Jabber: 5: 0:2.0-6.fc5 (FE5) 6: 0:2.0-5.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96-6.fc5 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) squid: 5: 7:2.5.STABLE14-2.FC5 (FC5-updates) 6: 7:2.5.STABLE14-2 (FC6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion: 5: 0:1.3.2-2.1 (FC5-updates) 6: 0:1.3.1-4 (FC6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) tcl: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) testdisk: 5: 0:6.4-2.fc5 (FE5) 6: 0:6.3-1.fc5 (FE6) tetex-fonts-hebrew: 4: 0:0.1-6.fc4 (FE4) 5: 0:0.1-5.fc5 (FE5) 6: 0:0.1-5.fc6 (FE6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) tk: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tzdata: 5: 0:2006g-1.fc5 (FC5-updates) 6: 0:2006g-1 (FC6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) verbiste: 5: 0:0.1.14-2.fc5 (FE5) 6: 0:0.1.14-1.1.fc5 (FE6) wine: 4: 0:0.9.16-2.fc4 (FE4) 5: 0:0.9.16-1.fc5 (FE5) 6: 0:0.9.16-1.fc6 (FE6) wine-docs: 3: 0:0.9.16-1.fc3 (FE3) 4: 0:0.9.16-0.1.fc4 (FE4) 5: 0:0.9.16-1.fc5 (FE5) 6: 0:0.9.16-1.fc6 (FE6) wordpress: 4: 0:2.0.3-4.fc4 (FE4) 5: 0:2.0.3-3.fc5 (FE5) 6: 0:2.0.3-3.fc6 (FE6) From buildsys at fedoraproject.org Fri Jul 7 23:50:06 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 07 Jul 2006 23:50:06 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-07 Message-ID: <20060707235006.2037.53299@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Fri Jul 7 23:50:06 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 07 Jul 2006 23:50:06 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-07 Message-ID: <20060707235006.2048.16331@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc5.i386 maxima-runtime-sbcl - 5.9.3-4.fc5.ppc maxima-runtime-sbcl - 5.9.3-4.fc5.x86_64 tcallawa AT redhat.com perl-Apache-Session-Wrapper - 0.29-1.fc5.noarch perl-Apache-Session-Wrapper - 0.29-1.fc5.noarch perl-Apache-Session-Wrapper - 0.29-1.fc5.noarch perl-Image-ExifTool - 6.26-1.fc5.noarch perl-Image-ExifTool - 6.26-1.fc5.noarch perl-Image-ExifTool - 6.26-1.fc5.noarch zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc5.i386 requires sbcl = 0:0.9.13 perl-Apache-Session-Wrapper-0.29-1.fc5.noarch requires perl(Apache::Session) >= 0:1.81 perl-Image-ExifTool-6.26-1.fc5.noarch requires perl(the) syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc5.ppc requires sbcl = 0:0.9.13 perl-Apache-Session-Wrapper-0.29-1.fc5.noarch requires perl(Apache::Session) >= 0:1.81 perl-Image-ExifTool-6.26-1.fc5.noarch requires perl(the) syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 maxima-runtime-sbcl-5.9.3-4.fc5.x86_64 requires sbcl = 0:0.9.13 perl-Apache-Session-Wrapper-0.29-1.fc5.noarch requires perl(Apache::Session) >= 0:1.81 perl-Image-ExifTool-6.26-1.fc5.noarch requires perl(the) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: zipsonic AT gmail.com package: freenx - 0.5.0-0.3.test7.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: nx >= 0:1.5.0 ====================================================================== New report for: tcallawa AT redhat.com package: perl-Image-ExifTool - 6.26-1.fc5.noarch from fedora-extras-5-i386 unresolved deps: perl(the) package: perl-Apache-Session-Wrapper - 0.29-1.fc5.noarch from fedora-extras-5-i386 unresolved deps: perl(Apache::Session) >= 0:1.81 package: perl-Image-ExifTool - 6.26-1.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: perl(the) package: perl-Apache-Session-Wrapper - 0.29-1.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: perl(Apache::Session) >= 0:1.81 package: perl-Image-ExifTool - 6.26-1.fc5.noarch from fedora-extras-5-ppc unresolved deps: perl(the) package: perl-Apache-Session-Wrapper - 0.29-1.fc5.noarch from fedora-extras-5-ppc unresolved deps: perl(Apache::Session) >= 0:1.81 From buildsys at fedoraproject.org Fri Jul 7 23:50:06 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 07 Jul 2006 23:50:06 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-07 Message-ID: <20060707235006.2052.85324@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 imlinux AT gmail.com nagios-plugins-sensors - 1.4.3-6.fc6.ppc lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 tcallawa AT redhat.com perl-Image-ExifTool - 6.26-1.fc6.noarch perl-Image-ExifTool - 6.26-1.fc6.noarch perl-Image-ExifTool - 6.26-1.fc6.noarch Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 perl-Image-ExifTool-6.26-1.fc6.noarch requires perl(the) sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 nagios-plugins-sensors-1.4.3-6.fc6.ppc requires /usr/bin/sensors nagios-plugins-sensors-1.4.3-6.fc6.ppc requires nagios-plugins = 0:1.4.3-6.fc6 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 perl-Image-ExifTool-6.26-1.fc6.noarch requires perl(the) sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) perl-Image-ExifTool-6.26-1.fc6.noarch requires perl(the) sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: tcallawa AT redhat.com package: perl-Image-ExifTool - 6.26-1.fc6.noarch from fedora-extras-development-i386 unresolved deps: perl(the) package: perl-Image-ExifTool - 6.26-1.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: perl(the) package: perl-Image-ExifTool - 6.26-1.fc6.noarch from fedora-extras-development-ppc unresolved deps: perl(the) ====================================================================== New report for: imlinux AT gmail.com package: nagios-plugins-sensors - 1.4.3-6.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr/bin/sensors nagios-plugins = 0:1.4.3-6.fc6 From buildsys at fedoraproject.org Fri Jul 7 23:50:06 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 07 Jul 2006 23:50:06 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-07 Message-ID: <20060707235006.2045.71255@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc4.i386 maxima-runtime-sbcl - 5.9.3-4.fc4.ppc maxima-runtime-sbcl - 5.9.3-4.fc4.x86_64 tcallawa AT redhat.com perl-Apache-Session-Wrapper - 0.29-1.fc4.noarch perl-Apache-Session-Wrapper - 0.29-1.fc4.noarch perl-Apache-Session-Wrapper - 0.29-1.fc4.noarch perl-Image-ExifTool - 6.26-1.fc4.noarch perl-Image-ExifTool - 6.26-1.fc4.noarch perl-Image-ExifTool - 6.26-1.fc4.noarch Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.i386 requires sbcl = 0:0.9.13 perl-Apache-Session-Wrapper-0.29-1.fc4.noarch requires perl(Apache::Session) >= 0:1.81 perl-Image-ExifTool-6.26-1.fc4.noarch requires perl(the) wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.ppc requires sbcl = 0:0.9.13 perl-Apache-Session-Wrapper-0.29-1.fc4.noarch requires perl(Apache::Session) >= 0:1.81 perl-Image-ExifTool-6.26-1.fc4.noarch requires perl(the) wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.x86_64 requires sbcl = 0:0.9.13 perl-Apache-Session-Wrapper-0.29-1.fc4.noarch requires perl(Apache::Session) >= 0:1.81 perl-Image-ExifTool-6.26-1.fc4.noarch requires perl(the) wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) ====================================================================== New report for: tcallawa AT redhat.com package: perl-Image-ExifTool - 6.26-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: perl(the) package: perl-Apache-Session-Wrapper - 0.29-1.fc4.noarch from fedora-extras-4-i386 unresolved deps: perl(Apache::Session) >= 0:1.81 package: perl-Apache-Session-Wrapper - 0.29-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: perl(Apache::Session) >= 0:1.81 package: perl-Image-ExifTool - 6.26-1.fc4.noarch from fedora-extras-4-x86_64 unresolved deps: perl(the) package: perl-Image-ExifTool - 6.26-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: perl(the) package: perl-Apache-Session-Wrapper - 0.29-1.fc4.noarch from fedora-extras-4-ppc unresolved deps: perl(Apache::Session) >= 0:1.81 From Matt_Domsch at dell.com Sat Jul 8 00:54:22 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 7 Jul 2006 19:54:22 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-07-07 Message-ID: <20060708005422.GC18685@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Fri Jul 7 18:34:33 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: argus-2.0.6.fixes.1-11.fc6 197215 NEW bazaar-1.4.2-7.fc6 197222 NEW bidiv-1.5-3.fc5 197224 NEW Number failed to build: 108 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 107 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 84 ---------------------------------- azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com camstream-0.26.3-9.fc5 nomis80 at nomis80.org contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net ddskk-12.2.0-7.fc5 petersen at redhat.com diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com epiphany-extensions-2.14.1-1 caillon at redhat.com exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com factory-2.0.5-6 rdieter at math.unl.edu flim-1.14.7-3 petersen at redhat.com gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de gnome-applet-rhythmbox-0.1.11-1.fc5 ivazquez at ivazquez.net gobby-0.4.0-3.rc2.fc6 lmacken at redhat.com grads-1.9b4-11.fc6 pertusus at free.fr gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org GtkAda-2.4.0-11.fc5 gemi at bluewin.ch gtktalog-1.0.4-7.fc5 matthias at rpmforge.net gtk-xfce-engine-2.2.8-2.fc5 kevin-redhat-bugzilla at tummy.com gwget-0.97-2.fc5 fedora at christoph-wickert.de Hermes-1.3.3-7 thomas at apestaart.org ifplugd-0.24-6 aaron.bennett at olin.edu jam-2.5-3.fc5 tcallawa at redhat.com john-1.6-4 ghenry at suretecsystems.com kanatest-0.3.6-4.fc5 robert at marcanoonline.com kdissert-1.0.5-1.1.fc5 icon at fedoraproject.org kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu kover-2.9.6-5 adrian at lisas.de ladspa-1.12-5 thomas at apestaart.org leafpad-0.8.9-1.fc6 ivazquez at ivazquez.net libfac-2.0.5-3 rdieter at math.unl.edu librx-1.5-6.fc5 tcallawa at redhat.com libtabe-0.2.6-14 llch at redhat.com libtomoe-gtk-0.1.0-5.fc5 ryo-dairiki at users.sourceforge.net licq-1.3.2-8 pvrabec at redhat.com linkchecker-3.3-3 redhat at flyn.org logjam-4.5.3-4.fc6 tcallawa at redhat.com lucidlife-0.9-8.fc6 peter at thecodergeek.com MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mfstools-2.0-9.snapshot050221.fc5 tcallawa at redhat.com multisync-0.90.18-5.fc5 andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 dennis at ausil.us nautilus-search-tool-0.2-1.fc5 ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 andreas.bierfert at lowlatency.de NetworkManager-vpnc-0.7.0-0.cvs20060529.fc6 davidz at redhat.com ngrep-1.44-4.fc5 oliver at linux-kernel.at openal-0.0.9-0.5.20060204cvs.fc5 andreas.bierfert at lowlatency.de opencv-0.9.7-15.fc5 nomis80 at nomis80.org orange-0.3-1.cvs20051118.fc6 andreas.bierfert at lowlatency.de pam_keyring-0.0.7-2 redhat at flyn.org pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.12-3.fc6 gemi at bluewin.ch powerman-1.0.24-1.fc6 jwilson at redhat.com python-cheetah-2.0-0.rc6.0.fc6 mikeb at redhat.com python-goopy-0.1-1 pjones at redhat.com python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net qalculate-kde-0.9.4-1.fc6 dakingun at gmail.com quarry-0.1.16-2.fc5 michel.salim at gmail.com rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rss-glx-0.8.1.p-3.fc6 nphilipp at redhat.com rssowl-1.2-12.fc6 green at redhat.com sabayon-2.12.3-3 markmc at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at scmxx-0.8.2-1.fc5 andreas at bawue.net SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-6.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net sloccount-2.26-4 bnocera at redhat.com stratagus-2.1-5.fc6 lemenkov at newmail.ru syck-0.55-7.fc5 oliver at linux-kernel.at synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com verbiste-0.1.14-1.1.fc5 icon at fedoraproject.org WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xcompmgr-1.1.3-4.fc6 dakingun at gmail.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com With bugs filed: 23 ---------------------------------- abiword-2.4.4-2.fc6 ['196690 NEW'] uwog at uwog.net alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com bmp-0.9.7.1-4.fc5 ['197356 NEW'] redhat-bugzilla at camperquake.de ccrtp-1.3.7-1.fc6 ['197362 NEW'] andreas at bawue.net cowbell-0.2.7.1-2.fc6 ['197366 CLOSED'] foolish at guezz.net dillo-0.8.6-2.fc6 ['197370 CLOSED'] andreas.bierfert at lowlatency.de drgeo-1.1.0-8.fc6 ['197614 CLOSED'] eric.tanguy at univ-nantes.fr driftnet-0.1.6-9 ['197685 NEW'] bnocera at redhat.com erlang-R11B-0.1.fc6 ['197696 CLOSED'] gemi at bluewin.ch fish-1.12.0-1.fc5 ['179296 NEW'] oliver at linux-kernel.at flow-tools-0.68-8.fc6 ['197706 NEW'] i at stingr.net gazpacho-0.6.5-1.fc5 ['197793 NEW'] icon at fedoraproject.org gdesklets-0.35.3-8.fc6 ['197799 NEW'] luya256 at yahoo.com glabels-2.0.4-2.fc5 ['197633 CLOSED'] peter at thecodergeek.com gnomad2-2.8.6-1.fc6 ['197920 NEW'] triad at df.lth.se gnome-applet-music-0.9.0-1.fc6 ['197924 NEW'] ivazquez at ivazquez.net gnome-schedule-1.0.0-1 ['197927 NEW'] frank at scirocco-5v-turbo.de grhino-0.15.0-5.fc5 ['197950 NEW'] michel.salim at gmail.com gsynaptics-0.9.5-2.fc5 ['197955 NEW'] fedora at leemhuis.info nco-3.1.2-1.fc6 ['193541 NEW'] ed at eh3.com xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Sat Jul 8 00:54:42 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 7 Jul 2006 19:54:42 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-07 Message-ID: <20060708005442.GD18685@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Fri Jul 7 18:30:48 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: argus-2.0.6.fixes.1-11.fc6 197215 NEW bazaar-1.4.2-7.fc6 197222 NEW bidiv-1.5-3.fc5 197224 NEW Number failed to build: 129 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 118 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 97 ---------------------------------- atitvout-0.4-5 andreas.bierfert at lowlatency.de azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com camstream-0.26.3-9.fc5 nomis80 at nomis80.org contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net ddskk-12.2.0-7.fc5 petersen at redhat.com diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com epiphany-extensions-2.14.1-1 caillon at redhat.com exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com factory-2.0.5-6 rdieter at math.unl.edu flim-1.14.7-3 petersen at redhat.com foobillard-3.0a-4 mitr at redhat.com gambas-1.0.14-2.fc5 tcallawa at redhat.com gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de gnome-applet-rhythmbox-0.1.11-1.fc5 ivazquez at ivazquez.net gobby-0.4.0-3.rc2.fc6 lmacken at redhat.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org GtkAda-2.4.0-11.fc5 gemi at bluewin.ch gtktalog-1.0.4-7.fc5 matthias at rpmforge.net gtk-xfce-engine-2.2.8-2.fc5 kevin-redhat-bugzilla at tummy.com gwget-0.97-2.fc5 fedora at christoph-wickert.de ifplugd-0.24-6 aaron.bennett at olin.edu jam-2.5-3.fc5 tcallawa at redhat.com john-1.6-4 ghenry at suretecsystems.com kanatest-0.3.6-4.fc5 robert at marcanoonline.com kdissert-1.0.5-1.1.fc5 icon at fedoraproject.org kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu kover-2.9.6-5 adrian at lisas.de ladspa-1.12-5 thomas at apestaart.org leafpad-0.8.9-1.fc6 ivazquez at ivazquez.net libfac-2.0.5-3 rdieter at math.unl.edu libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libtabe-0.2.6-14 llch at redhat.com libtomoe-gtk-0.1.0-5.fc5 ryo-dairiki at users.sourceforge.net licq-1.3.2-8 pvrabec at redhat.com linkchecker-3.3-3 redhat at flyn.org logjam-4.5.3-4.fc6 tcallawa at redhat.com lucidlife-0.9-8.fc6 peter at thecodergeek.com Macaulay2-0.9.8-0.3.cvs20060327.fc6 rdieter at math.unl.edu MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mhonarc-2.6.16-1.fc6 gauret at free.fr monodoc-1.1.13-13.fc6 paul at all-the-johnsons.co.uk multisync-0.90.18-5.fc5 andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 dennis at ausil.us nautilus-search-tool-0.2-1.fc5 ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 andreas.bierfert at lowlatency.de NetworkManager-vpnc-0.7.0-0.cvs20060529.fc6 davidz at redhat.com new-1.3.7-2 redhat at flyn.org ngrep-1.44-4.fc5 oliver at linux-kernel.at openal-0.0.9-0.5.20060204cvs.fc5 andreas.bierfert at lowlatency.de opencv-0.9.7-15.fc5 nomis80 at nomis80.org pam_keyring-0.0.7-2 redhat at flyn.org pam_mount-0.13.0-3 michael at knox.net.nz perl-Image-Info-1.21-2.fc6 jpo at di.uminho.pt perl-Unicode-Map8-0.12-8.fc5 gauret at free.fr perl-Unicode-MapUTF8-1.09-6.fc5 gauret at free.fr php-pear-DB-1.7.6-6 rpm at timj.co.uk pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.12-3.fc6 gemi at bluewin.ch powerman-1.0.24-1.fc6 jwilson at redhat.com python-cheetah-2.0-0.rc6.0.fc6 mikeb at redhat.com python-dateutil-1.1-2.fc5 orion at cora.nwra.com python-goopy-0.1-1 pjones at redhat.com python-reportlab-1.20-5.fc5 bdpepple at ameritech.net python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net q-7.1-2.fc6 gemi at bluewin.ch qalculate-kde-0.9.4-1.fc6 dakingun at gmail.com quarry-0.1.16-2.fc5 michel.salim at gmail.com rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rss-glx-0.8.1.p-3.fc6 nphilipp at redhat.com rssowl-1.2-12.fc6 green at redhat.com sabayon-2.12.3-3 markmc at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at scmxx-0.8.2-1.fc5 andreas at bawue.net SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-6.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net sloccount-2.26-4 bnocera at redhat.com stratagus-2.1-5.fc6 lemenkov at newmail.ru synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com uqm-0.5.0-1.fc5 icon at fedoraproject.org verbiste-0.1.14-1.1.fc5 icon at fedoraproject.org WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xcompmgr-1.1.3-4.fc6 dakingun at gmail.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com xsp-1.1.15-6.fc6 paul at all-the-johnsons.co.uk z88dk-1.6-8.fc5 paul at all-the-johnsons.co.uk With bugs filed: 21 ---------------------------------- alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com bmp-0.9.7.1-4.fc5 ['197356 NEW'] redhat-bugzilla at camperquake.de ccrtp-1.3.7-1.fc6 ['197362 NEW'] andreas at bawue.net cowbell-0.2.7.1-2.fc6 ['197366 CLOSED'] foolish at guezz.net dillo-0.8.6-2.fc6 ['197370 CLOSED'] andreas.bierfert at lowlatency.de drgeo-1.1.0-8.fc6 ['197614 CLOSED'] eric.tanguy at univ-nantes.fr driftnet-0.1.6-9 ['197685 NEW'] bnocera at redhat.com fish-1.12.0-1.fc5 ['179296 NEW'] oliver at linux-kernel.at flow-tools-0.68-8.fc6 ['197706 NEW'] i at stingr.net gazpacho-0.6.5-1.fc5 ['197793 NEW'] icon at fedoraproject.org gdesklets-0.35.3-8.fc6 ['197799 NEW'] luya256 at yahoo.com glabels-2.0.4-2.fc5 ['197633 CLOSED'] peter at thecodergeek.com gnomad2-2.8.6-1.fc6 ['197920 NEW'] triad at df.lth.se gnome-applet-music-0.9.0-1.fc6 ['197924 NEW'] ivazquez at ivazquez.net gnome-schedule-1.0.0-1 ['197927 NEW'] frank at scirocco-5v-turbo.de grhino-0.15.0-5.fc5 ['197950 NEW'] michel.salim at gmail.com gsynaptics-0.9.5-2.fc5 ['197955 NEW'] fedora at leemhuis.info nco-3.1.2-1.fc6 ['193541 NEW'] ed at eh3.com xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From tibbs at math.uh.edu Sat Jul 8 01:23:05 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 07 Jul 2006 20:23:05 -0500 Subject: This week's FESCo Meeting Summary In-Reply-To: (Jason L. Tibbitts, III's message of "Fri, 07 Jul 2006 15:12:06 -0500") References: <1152229246.24961.270.camel@localhost> Message-ID: >>>>> "JLT" == Jason L Tibbitts, writes: JLT> I have created FE-GUIDELINES and started adding some bugs as JLT> blockers, By the way, I apologize for the massive spam this caused. - J< From brkamikaze at gmail.com Sat Jul 8 11:14:21 2006 From: brkamikaze at gmail.com (Nikolai) Date: Sat, 8 Jul 2006 08:14:21 -0300 Subject: Question on the "Source:" line on a .spec file Message-ID: A package I am building has a very old stable version, and they recommend to build the program on it's CVS version. How can I specify a CVS version on the Source line? From bugs.michael at gmx.net Sat Jul 8 11:27:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 8 Jul 2006 13:27:16 +0200 Subject: Question on the "Source:" line on a .spec file In-Reply-To: References: Message-ID: <20060708132716.cd88f88a.bugs.michael@gmx.net> On Sat, 8 Jul 2006 08:14:21 -0300, Nikolai wrote: > A package I am building has a very old stable version, and they > recommend to build the program on it's CVS version. How can I specify > a CVS version on the Source line? Check it out of CVS, tar it, give it a useful file name, compress it, then specify the resulting archive file name on the Source line. :) It is good practice to add a comment on how to "reproduce" your tarball. From fedora at adslpipe.co.uk Sat Jul 8 13:24:57 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Sat, 08 Jul 2006 14:24:57 +0100 Subject: Package review stats In-Reply-To: References: <200607071821.k67ILZhr003980@mx3.redhat.com> Message-ID: <44AFB229.1040104@adslpipe.co.uk> Jason L Tibbitts III wrote: > Some sat for so long that it would not be surprising > to me if the the submitters had completely lost interest. I admit I *partly* lost interest in getting my first package reviewed/sponsored, I don't know if I haven't followed right procedures, or haven't spoken up loudly enough to attract attention https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 8 13:37:58 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 08 Jul 2006 15:37:58 +0200 Subject: Wiki not editable? Message-ID: <87r70wjjyh.fsf@kosh.bigo.ensc.de> Hello, the http://fedoraproject.org/wiki/Packaging/UserRegistry page on wiki which is indented to be editable by all users seems to be protected. Ditto, I am not able to edit the http://fedoraproject.org/wiki/Packaging/UserCreation page which was created by me. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From skvidal at linux.duke.edu Sat Jul 8 13:49:09 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 08 Jul 2006 09:49:09 -0400 Subject: Wiki not editable? In-Reply-To: <87r70wjjyh.fsf@kosh.bigo.ensc.de> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> Message-ID: <1152366549.19337.18.camel@cutter> On Sat, 2006-07-08 at 15:37 +0200, Enrico Scholz wrote: > Hello, > > the > > http://fedoraproject.org/wiki/Packaging/UserRegistry > > page on wiki which is indented to be editable by all users seems to be > protected. > > Ditto, I am not able to edit the > > http://fedoraproject.org/wiki/Packaging/UserCreation > > page which was created by me. > Spot wanted to close off Packaging for a bit from changes so he could make some w/o interruption, iirc. So the acl on the top level was changed. -sv From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 8 14:04:25 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 08 Jul 2006 16:04:25 +0200 Subject: Wiki not editable? In-Reply-To: <1152366549.19337.18.camel@cutter> (seth vidal's message of "Sat, 08 Jul 2006 09:49:09 -0400") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <1152366549.19337.18.camel@cutter> Message-ID: <87mzbkjiqe.fsf@kosh.bigo.ensc.de> skvidal at linux.duke.edu (seth vidal) writes: >> http://fedoraproject.org/wiki/Packaging/UserRegistry >> http://fedoraproject.org/wiki/Packaging/UserCreation > > Spot wanted to close off Packaging for a bit from changes so he could > make some w/o interruption, iirc. > > So the acl on the top level was changed. mmh... seemed to happen a month ago already so these changes should have been done in the meantime. Can proper ACLs (at least for the two pages above) be restored please? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From tibbs at math.uh.edu Sat Jul 8 15:42:17 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 08 Jul 2006 10:42:17 -0500 Subject: Package review stats In-Reply-To: <44AFB229.1040104@adslpipe.co.uk> (Andy Burns's message of "Sat, 08 Jul 2006 14:24:57 +0100") References: <200607071821.k67ILZhr003980@mx3.redhat.com> <44AFB229.1040104@adslpipe.co.uk> Message-ID: >>>>> "AB" == Andy Burns writes: AB> I admit I *partly* lost interest in getting my first package AB> reviewed/sponsored, I don't know if I haven't followed right AB> procedures, or haven't spoken up loudly enough to attract AB> attention First, http://fedoraproject.org/wiki/Extras/HowToGetSponsored Then, yes, speak up. Say "hey, I've contributed to package reviews of monodoc and monodevelop" and include links right there in the review ticket. Let the sponsors know that you're still interested and that you're working on demonstrating your understanding of the packaging guidelines. AB> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 - J< From steve at silug.org Sat Jul 8 15:44:37 2006 From: steve at silug.org (Steven Pritchard) Date: Sat, 8 Jul 2006 10:44:37 -0500 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-07 In-Reply-To: <20060707235006.2048.16331@extras64.linux.duke.edu> References: <20060707235006.2048.16331@extras64.linux.duke.edu> Message-ID: <20060708154437.GA1271@osiris.silug.org> On Fri, Jul 07, 2006 at 11:50:06PM -0000, Fedora Extras repoclosure wrote: > perl-Apache-Session-Wrapper-0.29-1.fc5.noarch requires perl(Apache::Session) >= 0:1.81 I'll update Apache::Session. (I've had the newer version in the devel branch for a long time without any complaints...) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From tibbs at math.uh.edu Sat Jul 8 16:26:57 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 08 Jul 2006 11:26:57 -0500 Subject: Wiki not editable? In-Reply-To: <87mzbkjiqe.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Sat, 08 Jul 2006 16:04:25 +0200") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <1152366549.19337.18.camel@cutter> <87mzbkjiqe.fsf@kosh.bigo.ensc.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> mmh... seemed to happen a month ago already so these changes ES> should have been done in the meantime. Most of the pages under Packaging are intended to be editable only by the packaging committee. I don't know what the intention is for those two pages. ES> Can proper ACLs (at least for the two pages above) be restored ES> please? Unfortunately while I can edit the pages I can't change the ACLs. If you let me know what changes you'd like to make, I'll make them. I'll talk to the rest of the committee about what the proper ACLs should be. - J< From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 8 16:37:16 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 08 Jul 2006 18:37:16 +0200 Subject: Wiki not editable? In-Reply-To: (Jason L. Tibbitts, III's message of "Sat, 08 Jul 2006 11:26:57 -0500") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <1152366549.19337.18.camel@cutter> <87mzbkjiqe.fsf@kosh.bigo.ensc.de> Message-ID: <87ac7kjbnn.fsf@kosh.bigo.ensc.de> tibbs at math.uh.edu (Jason L Tibbitts III) writes: > ES> mmh... seemed to happen a month ago already so these changes > ES> should have been done in the meantime. > > Most of the pages under Packaging are intended to be editable only by > the packaging committee. sorry; it's a wiki and everybody should be able to edit these pages... > I don't know what the intention is for those two pages. http://fedoraproject.org/wiki/Packaging/UserRegistry is intended to register new users/groups and must be writable for every packager therefore. http://fedoraproject.org/wiki/Packaging/UserCreation is one of my pages were I want to provide updated information. > ES> Can proper ACLs (at least for the two pages above) be restored > ES> please? > > Unfortunately while I can edit the pages I can't change the ACLs. If > you let me know what changes you'd like to make, I'll make them. ok; I want to document new fedora-usermgmt features. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Sat Jul 8 16:48:13 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 08 Jul 2006 17:48:13 +0100 Subject: %config in a spec file Message-ID: <1152377293.3734.166.camel@T7.Linux> Hi, While running rpmlint over anjuta-2.0.2-3, it has come back with W: anjuta non-conffile-in-etc /etc/gconf/schemas/anjuta-valgrind.schemas The spec file handles the schemas as per the instructions on the wiki and according to the rpmlint, I should mark the file as %config. Accordingly, in the spec, I have files -f %{name}.lang %defattr(-,root,root) %config %{_sysconfdir}/gconf/schemas/%{name}-valgrind.schemas However, rpmbuild fails with a file not found (/var/tmp/anjuta-2.0.2-3-root-build/etc/gconf/schemas/anjuta-valgrind.schemas) I'm obviously doing something wrong, but I'm not sure what. Should the % config line be at the top with BR, R et al and if it is, what (if anything) should be in the files section for it? TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Sat Jul 8 17:08:20 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 8 Jul 2006 19:08:20 +0200 Subject: Eiciel (was: Re: Package review stats) In-Reply-To: <44AFB229.1040104@adslpipe.co.uk> References: <200607071821.k67ILZhr003980@mx3.redhat.com> <44AFB229.1040104@adslpipe.co.uk> Message-ID: <20060708190820.191531ab.bugs.michael@gmx.net> On Sat, 08 Jul 2006 14:24:57 +0100, Andy Burns wrote: > Jason L Tibbitts III wrote: > > > Some sat for so long that it would not be surprising > > to me if the the submitters had completely lost interest. > > I admit I *partly* lost interest in getting my first package > reviewed/sponsored, I don't know if I haven't followed right procedures, > or haven't spoken up loudly enough to attract attention > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 There has been quite some traffic in that ticket. Feedback on mistakes in the packaging, for instance. 17 comments in total is much more than many trivial-to-review packages get. One cannot say that you have been ignored. :) Let me point out some things here instead of posting this in bugzilla: The ticket is assigned to you instead of the default dummy owner of Package Review tickets. This may be misunderstood by anyone who browses the FE-NEW list, looking for "unassigned" package reviews. When loading the ticket, it appears as if Paul Howarth is doing reviews already. Some of the package revisions look half-hearted, though. As somebody who has contributed reviews since the era before the Fedora Project, let me tell you that it can also happen that reviewers lose interest if the review'n'approval process gets too long and tiresome for a package. This can lead to potential sponsors waiting longer and observing you and your packages for a longer time. Usually it should be come obvious that the package submitter spends more time and thought into the package than the reviewer. Because it is the packager who wants to maintain the package later on. From my point of view, as much as I like to sponsor new contributors as soon as they provide one or two clean packages (fixing any reported issues without too much trouble), I would consider it a mistake to sponsor somebody, who will likely run into too many problems when working inside Fedora Extras CVS, with the buildsys, with the need to respond to bug reports, and so on. In addition to perusing existing documents, new [unsupported] contributors can seek for communication on fedora-extras-list actively, ask questions, request help and hints and demonstrate general interest in becoming a packager. On the contrary, new contributors who modify their offered packages only reluctantly or half-heartedly, give the [possibly false] impression that they don't really want to adhere to packaging guidelines and project policies. If a reviewer supplies a patch against your .spec, accept it or refuse it and discuss the reason. As a rule of thumb: don't modify your package too much in response to reviewer's feedback. Better ask before applying major changes, especially if you are not sure about them. This makes reviewing much easier. Taking a brief look at your latest package: $ rpmlint eiciel-0.9.2-4.src.rpm E: eiciel hardcoded-library-path in /usr/lib/debug/%{_bindir}/%{name}.debug E: eiciel hardcoded-library-path in /usr/lib/debug/%{_libdir}/nautilus/extensions-1.0/lib%{name}*.debug This smells like "packager confusion". Right now I can't take the time to read all 17 comments in the review ticket (writing all this probably has taken more, but well, ...). There is cleanup in the spec file needed. The debug files need not be excluded at all. They are not included in your package unless you include them explicitly or recursively (e.g. by including %_libdir which in turn would be a packaging mistake). > BuildRequires: nautilus Although this works, you really want "nautilus-devel", the virtual package for the Nautilus extension development files. "Nautilus" is written with upper-case 'N', so I would do the same in the package %description. > %{_datadir}/%{name}/* With this, the directory %{_datadir}/%{name} would not be included in your package. Listing the binary rpm confirms it: drwxr-xr-x /usr/share/eiciel/doc drwxr-xr-x /usr/share/eiciel/doc/C -rw-r--r-- /usr/share/eiciel/doc/C/eiciel.xml The fix is this %files entry: %{_datadir}/%{name}/ This includes the directory and the entire tree in it. The explicit slash at the end makes the .spec file easier to read. You see immediately that this entry includes a directory [recursively], instead of a single file. The package listing will look like (notice the top dir!): drwxr-xr-x /usr/share/eiciel drwxr-xr-x /usr/share/eiciel/doc drwxr-xr-x /usr/share/eiciel/doc/C -rw-r--r-- /usr/share/eiciel/doc/C/eiciel.xml > Summary: Eiciel graphical access control list editor Better: Summary: Graphical access control list (ACL) editor In wide parts of the RPM packaging world and for the majority of packages, it is considered bad taste to repeat or mention an application's name in the Summary. There is the package name "eiciel", which is very likely displayed together with the summary. And for anyone who doesn't know that "Eiciel" is a name, above summary is confusing. The one important thing to mention is the summary is to give a brief description of what this package does: it provides a graphical access control list editor. Everything beyond that can go into the %description. > -rw-r--r-- /usr/share/applications/eiciel.desktop > -rw-r--r-- /usr/share/applications/fedora-eiciel.desktop Two desktop entries. The one that appeared here in the menu does not work: Could not launch menu item Details: Failed to execute child process "/home/roger/eiciel/TEST/bin/eiciel" (No such file or directory) This indicates that you either want to remove "eiciel.desktop" or use it as the source for "desktop-file-install", adding vendor and your own changes, and using --delete-original to get rid of it. From bugs.michael at gmx.net Sat Jul 8 17:23:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 8 Jul 2006 19:23:16 +0200 Subject: %config in a spec file In-Reply-To: <1152377293.3734.166.camel@T7.Linux> References: <1152377293.3734.166.camel@T7.Linux> Message-ID: <20060708192316.8b8f3948.bugs.michael@gmx.net> On Sat, 08 Jul 2006 17:48:13 +0100, Paul wrote: > Hi, > > While running rpmlint over anjuta-2.0.2-3, it has come back with > > W: anjuta non-conffile-in-etc /etc/gconf/schemas/anjuta-valgrind.schemas > > The spec file handles the schemas as per the instructions on the wiki > and according to the rpmlint, I should mark the file as %config. > Accordingly, in the spec, I have > > files -f %{name}.lang > %defattr(-,root,root) > %config %{_sysconfdir}/gconf/schemas/%{name}-valgrind.schemas > > However, rpmbuild fails with a file not found > (/var/tmp/anjuta-2.0.2-3-root-build/etc/gconf/schemas/anjuta-valgrind.schemas) > > I'm obviously doing something wrong, but I'm not sure what. When you list the contents of your %{buildroot}, i.e. /var/tmp/anjuta-2.0.2-3-root-build, what do you see? If the file is really available, I'd like to see the unmodified .spec file. ;) > Should the % > config line be at the top with BR, R et al No. It is a marker for the %files section. From fedora at leemhuis.info Sat Jul 8 17:26:45 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 08 Jul 2006 19:26:45 +0200 Subject: FE-NEW assigned and unassigned (Was Eiciel ) In-Reply-To: <20060708190820.191531ab.bugs.michael@gmx.net> References: <200607071821.k67ILZhr003980@mx3.redhat.com> <44AFB229.1040104@adslpipe.co.uk> <20060708190820.191531ab.bugs.michael@gmx.net> Message-ID: <44AFEAD5.5070505@leemhuis.info> Michael Schwendt schrieb: > On Sat, 08 Jul 2006 14:24:57 +0100, Andy Burns wrote: >> Jason L Tibbitts III wrote: > The ticket is assigned to you instead of the default dummy owner of > Package Review tickets. This may be misunderstood by anyone who browses > the FE-NEW list, looking for "unassigned" package reviews. Agreed -- that's a common problem AFAICS (some bugs were for example accidentally assigned to the default and mostly ignored bugzilla-sink at leemhuis.info account). Well, what do do? We can change the state to "NEW" without asking the bugzilla admin IIRC (correct me if I'm wrong). So the best probably would be if reviewers would simply ignore the "new" or "assigned" status when looking at bugs blocking FE-NEW. That *should* work because all packages under review *should* block FE-REVIEW instead of FE-NEW. Okay, that were two "should" in one sentence, and that's probably the reason why it won't work :-/ CU thl From fedora at adslpipe.co.uk Sat Jul 8 18:00:12 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Sat, 08 Jul 2006 19:00:12 +0100 Subject: Eiciel In-Reply-To: <20060708190820.191531ab.bugs.michael@gmx.net> References: <200607071821.k67ILZhr003980@mx3.redhat.com><44AFB229.1040104@adslpipe.co.uk> <20060708190820.191531ab.bugs.michael@gmx.net> Message-ID: <44AFF2AC.80800@adslpipe.co.uk> Michael Schwendt wrote: > Let me point out some things here instead of posting this in bugzilla: Thanks for taking the time > The ticket is assigned to you instead of the default dummy owner of > Package Review tickets. This may be misunderstood by anyone who browses > the FE-NEW list, looking for "unassigned" package reviews. My mistake > Some of the package revisions look half-hearted, though. I'm a little but stumped by what you mean there, some of them have been a little minor, but I thought incremental was good when learning? > If a reviewer supplies a patch against your .spec, accept it or refuse it > and discuss the reason. I know what you mean there, I did rather ignore the patch submitted, but only because I'd already found my own way around some of the issues I was having. > Taking a brief look at your latest package: > > $ rpmlint eiciel-0.9.2-4.src.rpm > E: eiciel hardcoded-library-path in /usr/lib/debug/%{_bindir}/%{name}.debug > E: eiciel hardcoded-library-path in /usr/lib/debug/%{_libdir}/nautilus/extensions-1.0/lib%{name}*.debug Originally I had used macros, but I found that I *HAD* to hardcode that path, as it worked on x86 with macros, but failed on x86_64 as the files do not go into /usr/lib64/debug/usr/lib64 but into /usr/lib/debug/usr/lib64, perhaps I'm unaware of a macro that expands to /usr/lib on all platforms? Or perhaps eiciel's make install has placed them in the wrong location, and i should be correcting for that? I had been checking with rpmlint on RPMs and SRPM, and had got rid of all errors/warnings, obviously I failed to rpmlint again after my final change. > This smells like "packager confusion". Right now I can't take the time to > read all 17 comments in the review ticket (writing all this probably has > taken more, but well, ...). There is cleanup in the spec file needed. The > debug files need not be excluded at all. I was told (though not by an Extras contributor) that it was best to not package them > They are not included in your > package unless you include them explicitly or recursively (e.g. by > including %_libdir which in turn would be a packaging mistake). I thought I was aiming for the minimum number of includes (and optionally excludes) to catch all files that make install processed, >> BuildRequires: nautilus > > Although this works, you really want "nautilus-devel", the virtual > package for the Nautilus extension development files. > > "Nautilus" is written with upper-case 'N', so I would do the same > in the package %description. ok >> %{_datadir}/%{name}/* > > With this, the directory %{_datadir}/%{name} would not be included in > your package. Listing the binary rpm confirms it: > > drwxr-xr-x /usr/share/eiciel/doc > drwxr-xr-x /usr/share/eiciel/doc/C > -rw-r--r-- /usr/share/eiciel/doc/C/eiciel.xml > > The fix is this %files entry: > > %{_datadir}/%{name}/ > > This includes the directory and the entire tree in it. The explicit slash > at the end makes the .spec file easier to read. You see immediately that > this entry includes a directory [recursively], instead of a single file. > The package listing will look like (notice the top dir!): > > drwxr-xr-x /usr/share/eiciel > drwxr-xr-x /usr/share/eiciel/doc > drwxr-xr-x /usr/share/eiciel/doc/C > -rw-r--r-- /usr/share/eiciel/doc/C/eiciel.xml Hadn't realised the distinction in wildcards >> Summary: Eiciel graphical access control list editor > > Better: > Summary: Graphical access control list (ACL) editor > > In wide parts of the RPM packaging world and for the majority of packages, > it is considered bad taste to repeat or mention an application's name in > the Summary. There is the package name "eiciel", which is very likely > displayed together with the summary. And for anyone who doesn't know that > "Eiciel" is a name, above summary is confusing. The one important thing to > mention is the summary is to give a brief description of what this package > does: it provides a graphical access control list editor. Everything > beyond that can go into the %description. ok >> -rw-r--r-- /usr/share/applications/eiciel.desktop >> -rw-r--r-- /usr/share/applications/fedora-eiciel.desktop > > Two desktop entries. The one that appeared here in the menu does not work: > > Could not launch menu item > > Details: Failed to execute child process > "/home/roger/eiciel/TEST/bin/eiciel" (No such file or directory) > > This indicates that you either want to remove "eiciel.desktop" or use it > as the source for "desktop-file-install", adding vendor and your own > changes, and using --delete-original to get rid of it. I wasn't too clear about .desktop files, I should have asked about my use of desktop-file-install particularly about "vendor" and "add-category", I was just following what I could see elsewhere. Thanks again, I'll give it a brush up later ... From fedora at adslpipe.co.uk Sat Jul 8 18:23:58 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Sat, 08 Jul 2006 19:23:58 +0100 Subject: FE-NEW assigned and unassigned (Was Eiciel ) In-Reply-To: <44AFEAD5.5070505@leemhuis.info> References: <200607071821.k67ILZhr003980@mx3.redhat.com> <44AFB229.1040104@adslpipe.co.uk><20060708190820.191531ab.bugs.michael@gmx.net> <44AFEAD5.5070505@leemhuis.info> Message-ID: <44AFF83E.8050903@adslpipe.co.uk> Thorsten Leemhuis wrote: > Agreed -- that's a common problem AFAICS (some bugs were for example > accidentally assigned to the default and mostly ignored > bugzilla-sink at leemhuis.info account). Oh, having just looked at the activity and re-assigned the owner to it's original, but you're saying that "sink" was never the correct owner anyway? I just did a bugzilla query on product=Fedora Extras version=devel component=Package Review bug_status=NEW and the vast majority seem to be assigned to "sink" From packages at amiga-hardware.com Sat Jul 8 18:51:53 2006 From: packages at amiga-hardware.com (Ian Chapman) Date: Sat, 08 Jul 2006 19:51:53 +0100 Subject: Problem with a package In-Reply-To: References: Message-ID: <44AFFEC9.6020003@amiga-hardware.com> Nikolai wrote: > I'm packaging also the Widelands game; and I noticed it uses a weird > filesystem structure, because it has no "make install" and the data files > are on the subdirs on the same dir as the executable. How should I fix > this? > Put everything on /usr/bin or make a special folder for widelands on > /usr/share and fix the .desktop file? I would make the dir /usr/share/widelands and patch the game if necessary to use this location. -- Ian Chapman. From bugs.michael at gmx.net Sat Jul 8 19:45:15 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 8 Jul 2006 21:45:15 +0200 Subject: Eiciel In-Reply-To: <44AFF2AC.80800@adslpipe.co.uk> References: <200607071821.k67ILZhr003980@mx3.redhat.com> <44AFB229.1040104@adslpipe.co.uk> <20060708190820.191531ab.bugs.michael@gmx.net> <44AFF2AC.80800@adslpipe.co.uk> Message-ID: <20060708214515.c55be040.bugs.michael@gmx.net> On Sat, 08 Jul 2006 19:00:12 +0100, Andy Burns wrote: > > $ rpmlint eiciel-0.9.2-4.src.rpm > > E: eiciel hardcoded-library-path in /usr/lib/debug/%{_bindir}/%{name}.debug > > E: eiciel hardcoded-library-path in /usr/lib/debug/%{_libdir}/nautilus/extensions-1.0/lib%{name}*.debug > > Originally I had used macros, but I found that I *HAD* to hardcode that > path, as it worked on x86 with macros, but failed on x86_64 as the files > do not go into /usr/lib64/debug/usr/lib64 but into > /usr/lib/debug/usr/lib64, perhaps I'm unaware of a macro that expands > to /usr/lib on all platforms? You don't need to handle these files in your .spec at all. The files do not find a way into your "eiciel" package unless your include files you must not include. Just delete the two %exclude line. :) > Or perhaps eiciel's make install has placed them in the wrong location, > and i should be correcting for that? They are created by rpmbuild (with package "redhat-rpm-config" installed, and %_enable_debug_packages defaults to 1) and are put into an automatically created eiciel-debuginfo package. From toshio at tiki-lounge.com Sat Jul 8 20:01:51 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 08 Jul 2006 13:01:51 -0700 Subject: Wiki not editable? In-Reply-To: <87ac7kjbnn.fsf@kosh.bigo.ensc.de> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <1152366549.19337.18.camel@cutter> <87mzbkjiqe.fsf@kosh.bigo.ensc.de> <87ac7kjbnn.fsf@kosh.bigo.ensc.de> Message-ID: <1152388911.29936.7.camel@localhost> On Sat, 2006-07-08 at 18:37 +0200, Enrico Scholz wrote: > tibbs at math.uh.edu (Jason L Tibbitts III) writes: > > I don't know what the intention is for those two pages. > > http://fedoraproject.org/wiki/Packaging/UserRegistry > > is intended to register new users/groups and must be writable for every > packager therefore. This should definitely be made editable by everyone. I don't think it needs to stay in the Packaging hierarchy either. > http://fedoraproject.org/wiki/Packaging/UserCreation > > is one of my pages were I want to provide updated information. > Not sure about this one. This is something of a packaging guideline. But Enrico is most qualified to create and maintain the content on it. I think at the very least, Enrico should be put on the ACL for the page. Hopefully spot will weight in with some thoughts as he's the one with ACL editing abilities. -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 paul at all-the-johnsons.co.uk Sat Jul 8 21:02:59 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 08 Jul 2006 22:02:59 +0100 Subject: %config in a spec file In-Reply-To: <20060708192316.8b8f3948.bugs.michael@gmx.net> References: <1152377293.3734.166.camel@T7.Linux> <20060708192316.8b8f3948.bugs.michael@gmx.net> Message-ID: <1152392579.3734.173.camel@T7.Linux> Hi, > When you list the contents of your %{buildroot}, i.e. > /var/tmp/anjuta-2.0.2-3-root-build, what do you see? /etc/gconf/schemas/anjuta-valgrind.schemas > If the file is really available, I'd like to see the unmodified .spec file. ;) Here it is.... Summary: Integrated Development Environment Name: anjuta Version: 2.0.2 Release: 3%{?dist} License: GPL Group: Development/Tools URL: http://kent.dl.sourceforge.net/sourceforge/%{name}/%{name}-%{version}.tar.gz Source0: %{name}-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: glib, gtk2, ORBit2, gnome-vfs2, vte, pango, pcre, devhelp, anjuta-gdl, gnome-build, graphviz, neon, subversion BuildRequires: glib2-devel, gtk2-devel, ORBit2-devel, libglade2-devel, libgnome-devel, libgnomeui-devel, libgnomeprint22-devel, libgnomeprintui22-devel, gnome-vfs2-devel, libbonobo-devel, libbonoboui-devel, vte-devel, libxml2-devel, pango-devel, pcre-devel, devhelp-devel, anjuta-gdl-devel, gnome-build-devel, graphviz-devel, neon-devel, subversion-devel, autogen Requires(pre): GConf2 Requires(post): GConf2 Requires(preun): GConf2 %description Anjuta DevStudio is a versatile Integrated Development Environment (IDE) on GNOME Desktop Environment and features a number of advanced programming facilities. These include project management, application and class wizards, an on-board interactive debugger, powerful source editor, syntax highlighting, intellisense autocompletions, symbol navigation, version controls, integrated GUI designing and other tools. %package devel Summary: Libraries and include files for Anjuta plugins development. Group: Development/Libraries Requires: %{name} = %{?epoch:%{epoch}:}%{version}-%{release} %description devel Libraries, header files and API docs for developing Anjuta plugins. %prep %setup -q sed -i 's/\r//' doc/ScintillaDoc.html %build %configure --disable-static --disable-plugin-subversion #subversion disabled for now! %define libnoprefix %(echo %_libdir | sed 's,%_prefix/,,') sed -i -e 's!\(.*PACKAGE_PLUGIN_DIR@,.*\)lib\(/anjuta.*\)! \1%{libnoprefix}\2!g' config.status ; ./config.status make %install rm -rf %{buildroot} export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 make DESTDIR=%{buildroot} install %find_lang %{name} desktop-file-install --vendor fedora --delete-original \ --dir ${RPM_BUILD_ROOT}%{_datadir}/applications \ --add-category X-Fedora \ %{buildroot}%{_datadir}/applications/%{name}.desktop find %{buildroot} -type f -name "*.la" -exec rm -f {} ';' %clean rm -rf %{buildroot} %pre if [ "$1" -gt 1 ]; then export GCONF_CONFIG_SOURCE='gconftool-2 --get-default-source' gconftool-2 --makefile-uninstall-rule \ %{_sysconfdir}/gconf/schemas/%{name}-valgrind.schemas > /dev/null || : killall -HUP gconfd-2 || : fi %post export GCONF_CONFIG_SOURCE='gconftool-2 --get-default-source' gconftool-2 --makefile-install-rule \ %{_sysconfdir}/gconf/schemas/%{name}-valgrind.schemas > /dev/null || : killall -HUP gconfd-2 || : if which update-mime-database>/dev/null 2>&1; then \ update-mime-database %{_datadir}/mime; \ fi /sbin/ldconfig %preun if [ "$1" -eq 0 ]; then export GCONF_CONFIG_SOURCE='gconftool-2 --get-default-source' gconftool-2 --makefile-uninstall-rule \ %{_sysconfdir}/gconf/schemas/%{name}-valgrind.schemas > /dev/null || : killall -HUP gconfd-2 || : fi %postun if which update-mime-database>/dev/null 2>&1; then \ update-mime-database %{_datadir}/mime; \ fi /sbin/ldconfig %files -f %{name}.lang %defattr(-,root,root) %doc AUTHORS COPYING ChangeLog INSTALL NEWS README TODO %doc doc/ScintillaDoc.html %{_bindir}/%{name}* %config %{_sysconfdir}/gconf/schemas/%{name}-valgrind.schemas %{_bindir}/create_global_tags.sh %{_bindir}/test_tm_buffer %{_libdir}/lib%{name}*.so.* %{_libdir}/%{name} %{_datadir}/applications/*%{name}.desktop %{_datadir}/pixmaps/%{name} %{_datadir}/doc/%{name} %{_datadir}/application-registry/%{name}.applications %{_datadir}/mime-info/%{name}.mime %{_datadir}/mime-info/%{name}.keys %{_datadir}/mime/packages/%{name}.xml %{_datadir}/icons/gnome/48x48/mimetypes/*%{name}.png %{_datadir}/icons/hicolor/48x48/apps/anjuta_icon.png %{_datadir}/icons/hicolor/scalable/apps/anjuta_icon.svg %{_datadir}/gnome/help/anjuta/* %{_datadir}/man/man1/anjuta* %{_datadir}/omf/anjuta/* %files devel %defattr (-, root, root) %{_includedir}/*%{name}* %{_libdir}/pkgconfig/*%{name}* %{_libdir}/lib%{name}*.so %{_datadir}/gtk-doc/html/*%{name}* %{_datadir}/%{name} %exclude %{_datadir}/%{name}/project/cpp/AUTHORS %exclude %{_datadir}/%{name}/project/cpp/po/ChangeLog %exclude %{_datadir}/%{name}/project/cpp/NEWS %exclude %{_datadir}/%{name}/project/terminal/NEWS %exclude %{_datadir}/%{name}/project/mkfile/po/ChangeLog %exclude %{_datadir}/%{name}/project/cpp/ChangeLog %exclude %{_datadir}/%{name}/project/terminal/ChangeLog %exclude %{_datadir}/%{name}/project/terminal/AUTHORS %changelog * Fri Jul 07 2006 Paul F. Johnson 2.0.2-3 - renamed spec file - removed R autogen and added it as BR - lots of fixes thanks to rpmlint - Added gconf fixes -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 paul at all-the-johnsons.co.uk Sat Jul 8 22:24:51 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 08 Jul 2006 23:24:51 +0100 Subject: repodata shot? Message-ID: <1152397491.3734.178.camel@T7.Linux> Hi, I'm testing gnome-build in mock. In the BR is gnome-libs-devel. This package is listed in yum, but its reporting as not being found. Is there a problem with the FC repodata or is it something else? This problem has been independently seen. TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 linux.duke.edu Sat Jul 8 23:24:06 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 08 Jul 2006 19:24:06 -0400 Subject: repodata shot? In-Reply-To: <1152397491.3734.178.camel@T7.Linux> References: <1152397491.3734.178.camel@T7.Linux> Message-ID: <1152401047.20610.5.camel@cutter> On Sat, 2006-07-08 at 23:24 +0100, Paul wrote: > Hi, > > I'm testing gnome-build in mock. In the BR is gnome-libs-devel. This > package is listed in yum, but its reporting as not being found. 1. what arch 2. what repository? 3. what release? 4. attach the root.log you've given much too little information for anyone to be able to help you. -sv From paul at all-the-johnsons.co.uk Sat Jul 8 23:58:38 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 09 Jul 2006 00:58:38 +0100 Subject: repodata shot? In-Reply-To: <1152401047.20610.5.camel@cutter> References: <1152397491.3734.178.camel@T7.Linux> <1152401047.20610.5.camel@cutter> Message-ID: <1152403118.3734.184.camel@T7.Linux> Hi, > > I'm testing gnome-build in mock. In the BR is gnome-libs-devel. This > > package is listed in yum, but its reporting as not being found. > > 1. what arch i386 and x86_64 > 2. what repository? the main fedora one (i386), Core and mirrors.kernel.org (x86_64) > 3. what release? 5 > 4. attach the root.log ensuring dir /var/lib/mock/fedora-development-i386-core/state Cleaning Root Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core/root/proc umount: /var/lib/mock/fedora-development-i386-core/root/proc: not mounted Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core/root/dev/pts umount: /var/lib/mock/fedora-development-i386-core/root/dev/pts: not mounted Executing /usr/sbin/mock-helper rm -rf /var/lib/mock/fedora-development-i386-core ensuring dir /var/lib/mock/fedora-development-i386-core ensuring dir /var/lib/mock/fedora-development-i386-core/root ensuring dir /var/lib/mock/fedora-development-i386-core/state ensuring dir /var/lib/mock/fedora-development-i386-core/result Executing /usr/sbin/mock-helper unpack /var/lib/mock/fedora-development-i386-core /var/lib/mock/root-cache/fedora-development-i386-core.tar.gz ensuring dir /var/lib/mock/fedora-development-i386-core ensuring dir /var/lib/mock/fedora-development-i386-core/root ensuring dir /var/lib/mock/fedora-development-i386-core/state ensuring dir /var/lib/mock/fedora-development-i386-core/result ensuring dir /var/lib/mock/fedora-development-i386-core/root/var/lib/rpm ensuring dir /var/lib/mock/fedora-development-i386-core/root/var/log ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev ensuring dir /var/lib/mock/fedora-development-i386-core/root/etc/rpm ensuring dir /var/lib/mock/fedora-development-i386-core/root/tmp ensuring dir /var/lib/mock/fedora-development-i386-core/root/var/tmp ensuring dir /var/lib/mock/fedora-development-i386-core/root/etc/yum.repos.d ensuring dir /var/lib/mock/fedora-development-i386-core/root/proc Executing /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-development-i386-core/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev/pts Executing /usr/sbin/mock-helper mount -t devpts devpts /var/lib/mock/fedora-development-i386-core/root/dev/pts Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "chown 501.502 /etc/yum.conf" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "chown 501.502 /etc/hosts" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "chown 501.502 /etc/resolv.conf" ensuring dir /var/lib/mock/fedora-development-i386-core/root/proc Executing /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-development-i386-core/root/proc mount: proc already mounted or /var/lib/mock/fedora-development-i386-core/root/proc busy mount: according to mtab, proc is already mounted on /var/lib/mock/fedora-development-i386-core/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev/pts Executing /usr/sbin/mock-helper mount -t devpts devpts /var/lib/mock/fedora-development-i386-core/root/dev/pts mount: devpts already mounted or /var/lib/mock/fedora-development-i386-core/root/dev/pts busy mount: according to mtab, devpts is already mounted on /var/lib/mock/fedora-development-i386-core/root/dev/pts Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root update telinit: timeout opening/writing control channel /dev/initctl warning: /etc/passwd created as /etc/passwd.rpmnew ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: e2fsprogs i386 1.39-1 core 937 k e2fsprogs-libs i386 1.39-1 core 111 k krb5-libs i386 1.5-1 core 586 k libselinux i386 1.30.19-1 core 88 k ncurses i386 5.5-20 core 1.1 M setup noarch 2.5.52-1 core 125 k util-linux i386 2.13-0.29 core 1.7 M Transaction Summary ============================================================================= Install 0 Package(s) Update 7 Package(s) Remove 0 Package(s) Total download size: 4.7 M Updated: e2fsprogs.i386 0:1.39-1 e2fsprogs-libs.i386 0:1.39-1 krb5-libs.i386 0:1.5-1 libselinux.i386 0:1.30.19-1 ncurses.i386 0:5.5-20 setup.noarch 0:2.5.52-1 util-linux.i386 0:2.13-0.29 Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "rm -rf /builddir/build" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "mkdir -p /builddir/build/RPMS" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "mkdir -p /builddir/build/SRPMS" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "mkdir -p /builddir/build/SOURCES" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "mkdir -p /builddir/build/SPECS" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "mkdir -p /builddir/build/BUILD" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "mkdir -p /builddir/build/originals" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "chown -R mockbuild.mockbuild /builddir" ensuring dir /var/lib/mock/fedora-development-i386-core/root/proc Executing /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-development-i386-core/root/proc mount: proc already mounted or /var/lib/mock/fedora-development-i386-core/root/proc busy mount: according to mtab, proc is already mounted on /var/lib/mock/fedora-development-i386-core/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev/pts Executing /usr/sbin/mock-helper mount -t devpts devpts /var/lib/mock/fedora-development-i386-core/root/dev/pts mount: devpts already mounted or /var/lib/mock/fedora-development-i386-core/root/dev/pts busy mount: according to mtab, devpts is already mounted on /var/lib/mock/fedora-development-i386-core/root/dev/pts ensuring dir /var/lib/mock/fedora-development-i386-core/root/proc Executing /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-development-i386-core/root/proc mount: proc already mounted or /var/lib/mock/fedora-development-i386-core/root/proc busy mount: according to mtab, proc is already mounted on /var/lib/mock/fedora-development-i386-core/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev/pts Executing /usr/sbin/mock-helper mount -t devpts devpts /var/lib/mock/fedora-development-i386-core/root/dev/pts mount: devpts already mounted or /var/lib/mock/fedora-development-i386-core/root/dev/pts busy mount: according to mtab, devpts is already mounted on /var/lib/mock/fedora-development-i386-core/root/dev/pts Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "rm -rf /builddir/build" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "mkdir -p /builddir/build/RPMS" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "mkdir -p /builddir/build/SRPMS" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "mkdir -p /builddir/build/SOURCES" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "mkdir -p /builddir/build/SPECS" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "mkdir -p /builddir/build/BUILD" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "mkdir -p /builddir/build/originals" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "chown -R mockbuild.mockbuild /builddir" Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "/sbin/runuser -c 'rpm -Uvh --nodeps /builddir/build/originals/gnome-build-0.1.3-3.src.rpm' mockbuild" gnome-build warning: user build does not exist - using root warning: group build does not exist - using root ################################################## warning: user build does not exist - using root warning: group build does not exist - using root Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core/root /sbin/runuser - root -c "/sbin/runuser -c 'rpmbuild -bs --target i386 --nodeps /builddir/build/SPECS/gnome-build.spec' mockbuild" warning: Could not canonicalize hostname: T10.Linux Building target platforms: i386 Building for target i386 Wrote: /builddir/build/SRPMS/gnome-build-0.1.3-3.fc6.src.rpm ensuring dir /var/lib/mock/fedora-development-i386-core/root/proc Executing /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-development-i386-core/root/proc mount: proc already mounted or /var/lib/mock/fedora-development-i386-core/root/proc busy mount: according to mtab, proc is already mounted on /var/lib/mock/fedora-development-i386-core/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core/root/dev/pts Executing /usr/sbin/mock-helper mount -t devpts devpts /var/lib/mock/fedora-development-i386-core/root/dev/pts mount: devpts already mounted or /var/lib/mock/fedora-development-i386-core/root/dev/pts busy mount: according to mtab, devpts is already mounted on /var/lib/mock/fedora-development-i386-core/root/dev/pts Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core/root resolvedep 'perl(XML::Parser)' 'gtk+-devel >= 2.3.0' 'libglade2-devel' 'oaf-devel' 'gtkhtml3-devel' 'anjuta-gdl' 'gnome-vfs2-devel' No Package Found for oaf-devel 0:perl-XML-Parser-2.34-6.1.2.2.i386 1:gtk+-devel-1.2.10-53.fc6.i386 0:libglade2-devel-2.5.1-5.i386 0:gtkhtml3-devel-3.11.3-1.i386 0:anjuta-gdl-0.6.1-2.fc6.i386 0:gnome-vfs2-devel-2.15.2-1.i386 Cleaning up... Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core/root/proc Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core/root/dev/pts Done. This one shows oaf-devel as being missing, other times it shows gnome-libs-devel as being missing. TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 ianburrell at gmail.com Sun Jul 9 01:38:21 2006 From: ianburrell at gmail.com (Ian Burrell) Date: Sat, 8 Jul 2006 18:38:21 -0700 Subject: repodata shot? In-Reply-To: <1152397491.3734.178.camel@T7.Linux> References: <1152397491.3734.178.camel@T7.Linux> Message-ID: On 7/8/06, Paul wrote: > > I'm testing gnome-build in mock. In the BR is gnome-libs-devel. This > package is listed in yum, but its reporting as not being found. > > Is there a problem with the FC repodata or is it something else? This > problem has been independently seen. > Does gnome-build really depend on the GNOME 1 libraries? gnome-libs is the GNOME 1 libraries. libgnome is one of the GNOME 2 libraries. You are using the rawhide repositories, not FC5. My impression is that GNOME 1 and Gtk 1 packages were removed from development. Some have been added to Extras but gnome-libs is not one of them. - Ian From brkamikaze at gmail.com Sun Jul 9 10:33:43 2006 From: brkamikaze at gmail.com (Nikolai) Date: Sun, 9 Jul 2006 07:33:43 -0300 Subject: Problem with a package In-Reply-To: <44AFFEC9.6020003@amiga-hardware.com> References: <44AFFEC9.6020003@amiga-hardware.com> Message-ID: It looks like the CVS version use the FHS standard, putting the binaries on $(prefix)/bin and the data on $(prefix)/share/widelands. I will give the CVS a try, otherwise I'll put everything on the /usr/share/widelands and patch the desktop file. 2006/7/8, Ian Chapman : > Nikolai wrote: > > I'm packaging also the Widelands game; and I noticed it uses a weird > > filesystem structure, because it has no "make install" and the data files > > are on the subdirs on the same dir as the executable. How should I fix > > this? > > Put everything on /usr/bin or make a special folder for widelands on > > /usr/share and fix the .desktop file? > > I would make the dir /usr/share/widelands and patch the game if > necessary to use this location. > > -- > Ian Chapman. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From bugs.michael at gmx.net Sun Jul 9 11:52:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 9 Jul 2006 13:52:22 +0200 Subject: Problem with a package In-Reply-To: References: <44AFFEC9.6020003@amiga-hardware.com> Message-ID: <20060709135222.5c70541a.bugs.michael@gmx.net> On Sun, 9 Jul 2006 07:33:43 -0300, Nikolai wrote: > It looks like the CVS version use the FHS standard, putting the > binaries on $(prefix)/bin and the data on $(prefix)/share/widelands. I > will give the CVS a try, otherwise I'll put everything on the > /usr/share/widelands and patch the desktop file. Depends on what "everything" is. /usr/share is for platform-independent network-sharable data. The binary executables cannot go into it. > 2006/7/8, Ian Chapman : > > Nikolai wrote: > > > I'm packaging also the Widelands game; and I noticed it uses a weird > > > filesystem structure, because it has no "make install" and the data files > > > are on the subdirs on the same dir as the executable. How should I fix > > > this? > > > Put everything on /usr/bin or make a special folder for widelands on > > > /usr/share and fix the .desktop file? > > > > I would make the dir /usr/share/widelands and patch the game if > > necessary to use this location. > > > > -- > > Ian Chapman. From nicolas.mailhot at laposte.net Sun Jul 9 12:12:34 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 09 Jul 2006 14:12:34 +0200 Subject: Problem with a package In-Reply-To: <20060709135222.5c70541a.bugs.michael@gmx.net> References: <44AFFEC9.6020003@amiga-hardware.com> <20060709135222.5c70541a.bugs.michael@gmx.net> Message-ID: <1152447154.8685.15.camel@rousalka.dyndns.org> Le dimanche 09 juillet 2006 ? 13:52 +0200, Michael Schwendt a ?crit : > On Sun, 9 Jul 2006 07:33:43 -0300, Nikolai wrote: > > > It looks like the CVS version use the FHS standard, putting the > > binaries on $(prefix)/bin and the data on $(prefix)/share/widelands. I > > will give the CVS a try, otherwise I'll put everything on the > > /usr/share/widelands and patch the desktop file. > > Depends on what "everything" is. /usr/share is for platform-independent > network-sharable data. The binary executables cannot go into it. If your binaries are arch-independant they can certainly go there (but you need to version the dir) -- 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 paul at city-fan.org Sun Jul 9 13:05:04 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 09 Jul 2006 14:05:04 +0100 Subject: repodata shot? In-Reply-To: References: <1152397491.3734.178.camel@T7.Linux> Message-ID: <1152450305.10312.26.camel@laurel.intra.city-fan.org> On Sat, 2006-07-08 at 18:38 -0700, Ian Burrell wrote: > On 7/8/06, Paul wrote: > You are using the rawhide repositories, not FC5. My impression is > that GNOME 1 and Gtk 1 packages were removed from development. Some > have been added to Extras but gnome-libs is not one of them. I'm working on that. Hope to submit it (and its deps ORBit and libpng10) for review sometime next week. Paul. From paul at all-the-johnsons.co.uk Sun Jul 9 13:27:25 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 09 Jul 2006 14:27:25 +0100 Subject: repodata shot? In-Reply-To: <1152450305.10312.26.camel@laurel.intra.city-fan.org> References: <1152397491.3734.178.camel@T7.Linux> <1152450305.10312.26.camel@laurel.intra.city-fan.org> Message-ID: <1152451645.3734.198.camel@T7.Linux> Hi, > > You are using the rawhide repositories, not FC5. My impression is > > that GNOME 1 and Gtk 1 packages were removed from development. Some > > have been added to Extras but gnome-libs is not one of them. > > I'm working on that. Hope to submit it (and its deps ORBit and libpng10) > for review sometime next week. Thanks. Will the same be happening to oaf and gal? If they've been orphaned, I'm happy to build them for extras. TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- 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 Sun Jul 9 13:42:35 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 09 Jul 2006 15:42:35 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better Message-ID: <44B107CB.9070104@leemhuis.info> Hi all! Now that the election is over and the new FESCo is formed I thought it would be the right moment to recapitulate the current state of Fedora Extras and lay down some ideas for the near and the long term future with this mail. It's mainly a mail with a lot of different thoughts and random ideas just thrown together (mostly unordered) without going to much into the details and backgrounds. It's no real ToDo-List, but I hope we (all Extras contributors and FESCo members) can take it (after an discussion on this list) as a starting point to create a ToDo-List with priority's what should be realized soon and what can be worked on later (or ignored completely). Note: It covers all the things that came to my mind, but I'm probably forgetting a lot of stuff. If I'm forgetting something that's important in your opinion just reply to this mail and share your thoughts with the rest of us. Thanks in advance! Note2: Some ideas are not mine and stolen from Schedules in the Wiki, ToDo-List, Mails, Discussions, "Mission Statements" and other places. == So, where do we stand ? == Well, Extras works IMHO quite well. But not perfect afaics: * Packages * We have a lot of packages in it and nearly every day one (or even more) new comes aboard. * Most users seem to be satisfied with the package quality (I at least didn't hear any major criticism). * Most packages get Reviews in time, but there are still a lot of packages that got stuck in the QA queue for some time (or forever). * We have a standard for kmods in Extras, but all kmods are stuck in the QA queue * new contributors can get it with one package. But most interesting stuff is already packaged. We need other ways for new contributors to enter and help on Fedora Extras. * Why isn't the Fedora Directory Server still not in Extras? * FESCo * The old FESCo didn't work to well. A lot of members weren't very active. A lot of stuff was still discussed, but a lot of things didn't get done. Some things were discussed and agreed on, but not documented in the wiki. * How FESCo works isn't much documented * Discussions within FESCo and with the community are working often in acceptable ways on the lists and on IRC most of the time, but often nothing happens after the discussion is over and things remain unclear and undecided. * Co-Maintainership * This is IMO one of the biggest areas we should work on soon * each package should IMHO have at least two maintainers (one of them should be the "primary maintainer", who has the last word if there are disagreements how to do things) * MIA/AWOL * in the works already * we need way to detect if maintainers are still around (periodic ping?) * SIGS * Have a working PPC and x86_64 SIG that help fixing stuff for that arch in case a packager needs help * The games SIG is really doing well; hopefully the SIGs for perl, mono, python become as effective * Quality * get a review SIG together that makes sure that each commit on fedora-commits-list is *roughly* checked for bogus changes (at least I do some bogus things now and then and I'd be glad if someone would tell me) * set up scripts that check existing Spec-Files and packages automatically for bogus things and new rules/behaviors or common problems (empty debuginfo, hardcoded rpath, ...) * proper Rebuild policy for new releases (or automated rebuilds?) -- or we want to discuss this each time a new release comes up and decide on a case-by-case basis? Or simply rebuild all of Extras each time all of Core is rebuild? * Do we want to rebuild noarch packages now and then, too? We IMHO at least should make sure now and then that they still build. * can we stick to the "rolling release" scheme when anaconda will start supporting external repos during install (the rolling release scheme might break installs (not sure, but I think that is possible))? And/or do we need Releases of Fedora Extras? E.g. ISOs of FE6 and a stable repo on the servers and all new version go to a "updates" directory (similar to core)? * a proper orphans policy -- when to remove orphans from the devel branch? * automatic QA checks for build packages before pushing * MISC * we need a Update Policy/Guideline -- a lot of people update packages to the latest and greatest version in all supported Releases (and even in Releases that are in maintain mode) at the same time really a good idea? IMHO, especially as Extras has no updates-testing * When to EOL Fedora Extras -- is FE3 sill well maintained and is it checked by the security team -- if not call it officially EOL now * we shouldn't maintain two orphan lists (e.g. one in the wiki and one in owners.list) * we should have someone that fills the Fedora Weekly reports * Better web interface -- "yum search" is really slow and people on Windows or using other distributions should be able to search for packages and their contents, too * we need to make the x86_64 more multilib aware (i386 packages in the x86_64 repo) * Now that the first election is finished make everything ready for future elections * Send email to pkg owners whenever someone else edits/builds their pkg * Sponsors should be able to "subscribe" to the people they sponsored -- e.g. they should get additional mails when people they sponsored commit something to cvs, requested a build ... * we need a defined and documented policy to get definite answers for open legal question * fedora-devel-list, fedora-extras-list, fedora-maintainers -- these multiple lists get confusing, some things that are discussed on fedora-maintainers-list would be better suited for fedora-extras-list AFICS; * the broken deps reports are really nice, but maybe we should merge them into one per push (currently it's one per dist) * the "Broken upgrade paths" mail is also really nice, but it should also mail the responsible maintainers directly (if it doesn't do already) and have (a additional?) list sorted by maintainer (looking out for the names of all your package is probably not fun if you maintain a lot of packages)? * both "broken deps" and the "broken upgrade paths" mails should have a list how long something is broken already (that way other can notice "He that isn't fixed after know for 14 days -- I'll send out my ninjas to get the maintainer fix that shit" * Long-Term Fedora Extras contributors should get a small reward now and then: A Pen, Sticker, T-Shirt, LWN subscription, ... * Incompatible package upgrade policy (aka .so name changes) * Lower some of the hurdles to contribute to Extras * is it time to clarify/simplify the Fedora Packaging guidelines again to make them easier? * Scratch build target? * updates-testing repo for Extras? * better documentation in the wiki ("How does FESCo work" and Extras in general) * close the gap between Core and Extras as far as possible * We IMHO need more fine graded permissions, e.g. ACLs in the CVS, restricted access to queue builds in the buildsys. This would make is possible to grant new contributors or even upstream maintainers access to commit updates to CVS, but no access to the buildsys; a real Fedora Maintainer then could check the commits queue the new version for building * The wiki was a great place for informations in the beginning of Fedora Extras and still offers a lot of informations, but a lot of things are not probably documented. I might be time for a big cleanup. == As always: Just my 2 cent. CU thl From fedora at leemhuis.info Sun Jul 9 13:43:55 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 09 Jul 2006 15:43:55 +0200 Subject: FE-NEW assigned and unassigned (Was Eiciel ) In-Reply-To: <44AFF83E.8050903@adslpipe.co.uk> References: <200607071821.k67ILZhr003980@mx3.redhat.com> <44AFB229.1040104@adslpipe.co.uk><20060708190820.191531ab.bugs.michael@gmx.net> <44AFEAD5.5070505@leemhuis.info> <44AFF83E.8050903@adslpipe.co.uk> Message-ID: <44B1081B.6060405@leemhuis.info> Andy Burns schrieb: > Thorsten Leemhuis wrote: > >> Agreed -- that's a common problem AFAICS (some bugs were for example >> accidentally assigned to the default and mostly ignored >> bugzilla-sink at leemhuis.info account). > > Oh, having just looked at the activity and re-assigned the owner to it's > original, but you're saying that "sink" was never the correct owner anyway? It's the correct "owner" when the bugzilla-state/the bug is "new", but no bugs ever should be assigned to it normally. If they are please treat them as if they were "new". Cu thl From nicolas.mailhot at laposte.net Sun Jul 9 13:54:19 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 09 Jul 2006 15:54:19 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B107CB.9070104@leemhuis.info> References: <44B107CB.9070104@leemhuis.info> Message-ID: <1152453259.8685.26.camel@rousalka.dyndns.org> Le dimanche 09 juillet 2006 ? 15:42 +0200, Thorsten Leemhuis a ?crit : > * The wiki was a great place for informations in the beginning of > Fedora Extras and still offers a lot of informations, but a lot of > things are not probably documented. I might be time for a big cleanup. FE has probably grown enough now to require a full-time dedicated documentation team. Everyone hates doing doc and it doesn't help that some pages are locked. Good doc means less review work and disagreements of what the damn guidelines actually say (and on which wiki page the clear rule is hidden). (but at least we suck less than core) -- 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 buildsys at fedoraproject.org Sun Jul 9 14:09:30 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 9 Jul 2006 10:09:30 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-09 Message-ID: <20060709140930.7DF65152167@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 18 abiword-2.4.5-1.fc5 amarok-1.4.1-2.fc5 cal3d-0.11.0-1.fc5 clamav-0.88.3-1.fc5 clips-6.24-17.fc5 ecl-0.9i-1.fc5 gpp-0.6.6-1.fc5 grads-1.9b4-12.fc5 gstreamer08-plugins-0.8.12-5.fc5 hspell-1.0-4.fc5 libvisual-0.4.0-2.fc5 nexuiz-2.0-2.fc5 osgcal-0.1.40-3.fc5 perl-Apache-Session-1.81-1.fc5 perl-Data-Hierarchy-0.22-2.fc5 perl-DateTime-Format-Strptime-1.0700-1.fc5 perl-DateTime-Set-0.25-2.fc5 tetex-fonts-hebrew-0.1-6.fc5 Packages built and released for Fedora Extras 4: 10 cal3d-0.11.0-1.fc4 clamav-0.88.3-1.fc4 clips-6.24-14.fc4 ecl-0.9i-1.1.fc4 nexuiz-2.0-2.fc4 osgcal-0.1.40-3.fc4 perl-Apache-Session-1.81-1.fc4 perl-Data-Hierarchy-0.22-2.fc4 perl-DateTime-Format-Strptime-1.0700-1.fc4 perl-DateTime-Set-0.25-2.fc4 Packages built and released for Fedora Extras 3: 1 clamav-0.88.3-1.fc3 Packages built and released for Fedora Extras development: 23 abiword-2.4.5-1.fc6 anjuta-gdl-0.6.1-4.fc6 cal3d-0.11.0-1.fc6.1 chess-1.0-1.fc6 clamav-0.88.3-1.fc6 clips-6.24-17.fc6 ecl-0.9i-1.fc6 gpp-0.6.6-1.fc6 gstreamer08-plugins-0.8.12-6.fc6 gsynaptics-0.9.8-1.fc6 hspell-1.0-4.fc6 libvisual-0.4.0-2.fc6 osgcal-0.1.40-3.fc6 perl-DateTime-Event-ICal-0.09-1.fc6 perl-DateTime-Event-Recurrence-0.16-2.fc6 perl-DateTime-Format-ICal-0.08-2.fc6 perl-IO-All-0.35-3.fc6 perl-Log-Dispatch-Config-1.01-1.fc6 perl-OpenFrame-3.05-4.fc6 perl-POE-Component-JobQueue-0.5402-1.fc6 perl-POE-Component-Logger-1.00-1.fc6 perl-SVK-1.08-2.fc6 tetex-fonts-hebrew-0.1-6.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Jul 9 14:09:55 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 9 Jul 2006 10:09:55 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-09 Message-ID: <20060709140955.5A098152167@buildsys.fedoraproject.org> amarok: 5: 0:1.4.1-2.fc5 (FE5) 6: 0:1.4.0-5.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) brightside: 5: 0:1.4.0-11.fc5 (FE5) 6: 0:1.4.0-10.fc5 (FE6) cairo-java: 5: 0:1.0.4-0.FC5 (FC5-updates) 6: 0:1.0.4-0 (FC6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.0 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) dovecot: 5: 0:1.0-0.beta8.2.fc5 (FC5-updates) 6: 0:1.0-0.beta8.2 (FC6) ecl: 4: 0:0.9i-1.1.fc4 (FE4) 5: 0:0.9i-1.fc5 (FE5) 6: 0:0.9i-1.fc6 (FE6) eclipse-changelog: 5: 1:2.1.0_fc-2 (FC5-updates) 6: 1:2.1.0_fc-1 (FC6) factory: 5: 0:2.0.5-7.fc5 (FE5) 6: 0:2.0.5-6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) ghdl: 5: 0:0.23-0.58svn.1.fc5 (FE5) 6: 0:0.23-0.58svn.0.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) glib-java: 5: 0:0.2.5-0.FC5 (FC5-updates) 6: 0:0.2.5-0 (FC6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libfac: 5: 0:2.0.5-4.fc5 (FE5) 6: 0:2.0.5-3 (FE6) libglade-java: 5: 0:2.12.4-0.FC5 (FC5-updates) 6: 0:2.12.4-0 (FC6) libgnome-java: 5: 0:2.12.3-0.FC5 (FC5-updates) 6: 0:2.12.3-0 (FC6) libgtk-java: 5: 0:2.8.5-0.FC5 (FC5-updates) 6: 0:2.8.5-0 (FC6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libvte-java: 5: 0:0.12.0-0.FC5 (FC5-updates) 6: 0:0.12.0-0 (FC6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-11.fc6 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-Net-Jabber: 5: 0:2.0-6.fc5 (FE5) 6: 0:2.0-5.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96-6.fc5 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) squid: 5: 7:2.5.STABLE14-2.FC5 (FC5-updates) 6: 7:2.5.STABLE14-2 (FC6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion: 5: 0:1.3.2-2.1 (FC5-updates) 6: 0:1.3.1-4 (FC6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) tcl: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) testdisk: 5: 0:6.4-2.fc5 (FE5) 6: 0:6.3-1.fc5 (FE6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) tk: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tzdata: 5: 0:2006g-1.fc5 (FC5-updates) 6: 0:2006g-1 (FC6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) verbiste: 5: 0:0.1.14-2.fc5 (FE5) 6: 0:0.1.14-1.1.fc5 (FE6) wine: 4: 0:0.9.16-2.fc4 (FE4) 5: 0:0.9.16-1.fc5 (FE5) 6: 0:0.9.16-1.fc6 (FE6) wine-docs: 3: 0:0.9.16-1.fc3 (FE3) 4: 0:0.9.16-0.1.fc4 (FE4) 5: 0:0.9.16-1.fc5 (FE5) 6: 0:0.9.16-1.fc6 (FE6) wordpress: 4: 0:2.0.3-4.fc4 (FE4) 5: 0:2.0.3-3.fc5 (FE5) 6: 0:2.0.3-3.fc6 (FE6) From green at redhat.com Sun Jul 9 14:39:10 2006 From: green at redhat.com (Anthony Green) Date: Sun, 09 Jul 2006 07:39:10 -0700 Subject: Broken upgrade paths in FC+FE 2006-07-09 In-Reply-To: <20060709140955.5A098152167@buildsys.fedoraproject.org> References: <20060709140955.5A098152167@buildsys.fedoraproject.org> Message-ID: <1152455950.3123.150.camel@localhost.localdomain> Just FYI.. On Sun, 2006-07-09 at 10:09 -0400, buildsys at fedoraproject.org wrote: > azureus: > 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) > 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) A newer azureus is waiting on new java-1.4.2-gcj-compat and bouncycastle packages going into FC6. > rssowl: > 5: 0:1.2.1-2.fc5 (FE5) > 6: 0:1.2-12.fc6 (FE6) rssowl is busted in both FE5 and FE6 due to a libgcj regression introduced in FC5 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27271) I'll upgrade the FE6 rssowl once it runs again. AG From buildsys at fedoraproject.org Sun Jul 9 14:33:55 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 09 Jul 2006 14:33:55 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-09 Message-ID: <20060709143355.14378.78956@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Sun Jul 9 14:33:55 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 09 Jul 2006 14:33:55 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-09 Message-ID: <20060709143355.14386.54449@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc5.i386 maxima-runtime-sbcl - 5.9.3-4.fc5.ppc maxima-runtime-sbcl - 5.9.3-4.fc5.x86_64 tcallawa AT redhat.com perl-Image-ExifTool - 6.26-1.fc5.noarch perl-Image-ExifTool - 6.26-1.fc5.noarch perl-Image-ExifTool - 6.26-1.fc5.noarch zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 maxima-runtime-sbcl-5.9.3-4.fc5.i386 requires sbcl = 0:0.9.13 perl-Image-ExifTool-6.26-1.fc5.noarch requires perl(the) syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 maxima-runtime-sbcl-5.9.3-4.fc5.ppc requires sbcl = 0:0.9.13 perl-Image-ExifTool-6.26-1.fc5.noarch requires perl(the) syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) maxima-runtime-sbcl-5.9.3-4.fc5.x86_64 requires sbcl = 0:0.9.13 perl-Image-ExifTool-6.26-1.fc5.noarch requires perl(the) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: mpeters AT mac.com package: libvisual-plugins - 0.2.0-3.fc5.i386 from fedora-extras-5-i386 unresolved deps: libvisual.so.0 package: libvisual-plugins - 0.2.0-3.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libvisual.so.0()(64bit) package: libvisual-plugins - 0.2.0-3.fc5.ppc from fedora-extras-5-ppc unresolved deps: libvisual.so.0 From buildsys at fedoraproject.org Sun Jul 9 14:33:55 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 09 Jul 2006 14:33:55 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-09 Message-ID: <20060709143355.14384.97883@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 rdieter AT math.unl.edu maxima-runtime-sbcl - 5.9.3-4.fc4.i386 maxima-runtime-sbcl - 5.9.3-4.fc4.ppc maxima-runtime-sbcl - 5.9.3-4.fc4.x86_64 tcallawa AT redhat.com perl-Image-ExifTool - 6.26-1.fc4.noarch perl-Image-ExifTool - 6.26-1.fc4.noarch perl-Image-ExifTool - 6.26-1.fc4.noarch Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.i386 requires sbcl = 0:0.9.13 perl-Image-ExifTool-6.26-1.fc4.noarch requires perl(the) wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.ppc requires sbcl = 0:0.9.13 perl-Image-ExifTool-6.26-1.fc4.noarch requires perl(the) wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- maxima-runtime-sbcl-5.9.3-4.fc4.x86_64 requires sbcl = 0:0.9.13 perl-Image-ExifTool-6.26-1.fc4.noarch requires perl(the) wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) From buildsys at fedoraproject.org Sun Jul 9 14:33:55 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 09 Jul 2006 14:33:55 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-09 Message-ID: <20060709143355.14389.20573@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- adrian AT lisas.de xlockmore - 5.22-1.fc6.i386 xlockmore - 5.22-1.fc6.ppc byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 enrico.scholz AT informatik.tu-chemnitz.de kismet-extras - 0.0.2006.04.R1-2.fc6.i386 kismet-extras - 0.0.2006.04.R1-2.fc6.ppc kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 gauret AT free.fr amarok-visualisation - 1.4.0-5.fc6.i386 amarok-visualisation - 1.4.0-5.fc6.ppc amarok-visualisation - 1.4.0-5.fc6.x86_64 imlinux AT gmail.com nagios - 2.4-2.fc6.i386 nagios - 2.4-2.fc6.ppc nagios - 2.4-2.fc6.x86_64 lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 gfontview - 0.5.0-5.fc5.ppc gfontview - 0.5.0-5.fc5.x86_64 libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 qspencer AT ieee.org octave-forge - 2006.03.17-4.fc6.i386 octave-forge - 2006.03.17-4.fc6.ppc octave-forge - 2006.03.17-4.fc6.x86_64 rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 libibverbs - 1.0.3-1.fc6.ppc libibverbs - 1.0.3-1.fc6.x86_64 libibverbs-utils - 1.0.3-1.fc6.i386 libibverbs-utils - 1.0.3-1.fc6.ppc libibverbs-utils - 1.0.3-1.fc6.x86_64 tcallawa AT redhat.com perl-Image-ExifTool - 6.26-1.fc6.noarch perl-Image-ExifTool - 6.26-1.fc6.noarch perl-Image-ExifTool - 6.26-1.fc6.noarch thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 directfb - 0.9.24-5.fc5.ppc directfb - 0.9.24-5.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.i386 requires libvisual.so.0 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.i386 requires libMagick.so.9 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 nagios-2.4-2.fc6.i386 requires libttf.so.2 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.i386 requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.i386 requires libMagick.so.9 perl-Image-ExifTool-6.26-1.fc6.noarch requires perl(the) sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 xlockmore-5.22-1.fc6.i386 requires libttf.so.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.ppc requires libvisual.so.0 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 kismet-extras-0.0.2006.04.R1-2.fc6.ppc requires libMagick.so.9 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 nagios-2.4-2.fc6.ppc requires libttf.so.2 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 octave-forge-2006.03.17-4.fc6.ppc requires libMagick++.so.9 octave-forge-2006.03.17-4.fc6.ppc requires libMagick.so.9 perl-Image-ExifTool-6.26-1.fc6.noarch requires perl(the) sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 xlockmore-5.22-1.fc6.ppc requires libttf.so.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.x86_64 requires libvisual.so.0()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) kismet-extras-0.0.2006.04.R1-2.fc6.x86_64 requires libMagick.so.9()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) nagios-2.4-2.fc6.x86_64 requires libttf.so.2()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick++.so.9()(64bit) octave-forge-2006.03.17-4.fc6.x86_64 requires libMagick.so.9()(64bit) perl-Image-ExifTool-6.26-1.fc6.noarch requires perl(the) sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: mpeters AT mac.com package: gfontview - 0.5.0-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libttf.so.2 package: gfontview - 0.5.0-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libttf.so.2()(64bit) package: gfontview - 0.5.0-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libttf.so.2 ====================================================================== New report for: imlinux AT gmail.com package: nagios - 2.4-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libttf.so.2 package: nagios - 2.4-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libttf.so.2()(64bit) package: nagios - 2.4-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libttf.so.2 ====================================================================== New report for: qspencer AT ieee.org package: octave-forge - 2006.03.17-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick++.so.9 libMagick.so.9 package: octave-forge - 2006.03.17-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick++.so.9()(64bit) libMagick.so.9()(64bit) package: octave-forge - 2006.03.17-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick++.so.9 libMagick.so.9 ====================================================================== New report for: enrico.scholz AT informatik.tu-chemnitz.de package: kismet-extras - 0.0.2006.04.R1-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libMagick.so.9 package: kismet-extras - 0.0.2006.04.R1-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libMagick.so.9()(64bit) package: kismet-extras - 0.0.2006.04.R1-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libMagick.so.9 ====================================================================== New report for: thomas AT apestaart.org package: directfb - 0.9.24-5.fc5.i386 from fedora-extras-development-i386 unresolved deps: libsysfs.so.1 package: directfb - 0.9.24-5.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libsysfs.so.1()(64bit) package: directfb - 0.9.24-5.fc5.ppc from fedora-extras-development-ppc unresolved deps: libsysfs.so.1 ====================================================================== New report for: rolandd AT cisco.com package: libibverbs - 1.0.3-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libsysfs.so.1 package: libibverbs-utils - 1.0.3-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libsysfs.so.1 package: libibverbs - 1.0.3-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libsysfs.so.1()(64bit) package: libibverbs-utils - 1.0.3-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libsysfs.so.1()(64bit) package: libibverbs-utils - 1.0.3-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libsysfs.so.1 package: libibverbs - 1.0.3-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libsysfs.so.1 ====================================================================== New report for: gauret AT free.fr package: amarok-visualisation - 1.4.0-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libvisual.so.0 package: amarok-visualisation - 1.4.0-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libvisual.so.0()(64bit) package: amarok-visualisation - 1.4.0-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libvisual.so.0 ====================================================================== New report for: adrian AT lisas.de package: xlockmore - 5.22-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libttf.so.2 package: xlockmore - 5.22-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libttf.so.2 From bugs.michael at gmx.net Sun Jul 9 15:01:07 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 9 Jul 2006 17:01:07 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B107CB.9070104@leemhuis.info> References: <44B107CB.9070104@leemhuis.info> Message-ID: <20060709170107.facc519b.bugs.michael@gmx.net> On Sun, 09 Jul 2006 15:42:35 +0200, Thorsten Leemhuis wrote: > * FESCo > > * The old FESCo didn't work to well. A lot of members weren't very > active. A lot of stuff was still discussed, but a lot of things didn't > get done. Some things were discussed and agreed on, but not documented > in the wiki. There ought to be a web page with announcements. The history of decisions made by FESCo. As a contributor, even if you skim over the summary of a meeting, after a week you have forgotten what FESCo had agreed on in previous meetings. Also, the meeting summaries don't really concentrate on the important bits. There's too much noise in them. > * How FESCo works isn't much documented It's not documented at all. And it will get more complex now that other committees and project instances spring up like mushrooms. > * Discussions within FESCo and with the community are working often in > acceptable ways on the lists and on IRC most of the time, but often > nothing happens after the discussion is over and things remain unclear > and undecided. This paragraph contains a hint: "IRC" - those, who use IRC for real-time discussions, need to share the results of the communication, using the relevant mailing-lists. Participation in simple decisions "on list" has been poor, too, despite FESCo consisting of 17 members. > * Co-Maintainership > > * This is IMO one of the biggest areas we should work on soon It is unimportant. Co-maintenance is possible for a long time. It just needs additional communication between those who team up. The biggest hindrance in this area probably is the non-working "Cc" field in owners.list. > * each package should IMHO have at least two maintainers (one of them > should be the "primary maintainer", who has the last word if there are > disagreements how to do things) Not "each package", but packages with increased maintenance requirements would benefit from a team of packagers. > * Quality > > * get a review SIG together that makes sure that each commit on > fedora-commits-list is *roughly* checked for bogus changes (at least I > do some bogus things now and then and I'd be glad if someone would tell me) Unrealistic. For instance, I see 9817 unread/unfiltered messages in my fedora-extras-commits folder. And while it may be easy to spot obvious mistakes, it is less easy to find anything that's missing, especially during upgrades. > * proper Rebuild policy for new releases (or automated rebuilds?) -- > or we want to discuss this each time a new release comes up and decide > on a case-by-case basis? Or simply rebuild all of Extras each time all > of Core is rebuild? Well, when Core is rebuilt due to important changes/improvements in GCC, would it be possible that FESCo is notified about that? Or if somebody within FESCo learns about such a rebuild, that there will be an official announcement about what FE packagers should/must do? > * we shouldn't maintain two orphan lists (e.g. one in the wiki and > one in owners.list) owners.list is insufficient. Not enough fields for the various state information and/or comments. However, a policy could say that every package in owners.list which belongs to extras-orphan@ must not exist in the repository and must be disabled in CVS. > * we need to make the x86_64 more multilib aware (i386 packages in the > x86_64 repo) I've asked about it before, but have not found a wealth of information. In this area we depend on Core. We cannot invent our "own thing" in the push script, since Core must contain everything our multilib packages depend on. > * Sponsors should be able to "subscribe" to the people they sponsored > -- e.g. they should get additional mails when people they sponsored > commit something to cvs, requested a build ... Not necessary for commits. Full name and user name are in the "From" line in the mail header and in the "Author:" field of the body. Receiving copies of build server responses would be funny, though. > * we need a defined and documented policy to get definite answers for > open legal question > > * fedora-devel-list, fedora-extras-list, fedora-maintainers -- these > multiple lists get confusing, some things that are discussed on > fedora-maintainers-list would be better suited for fedora-extras-list > AFICS; It's not the confusion that hurts, but the insane amount of cross-posting. > * the broken deps reports are really nice, but maybe we should merge > them into one per push (currently it's one per dist) ... and none if no broken deps are found. So fix your broken packages and reduce the number of reports to one. :) Four (ore more) dists in one mail would decrease readability too much, IMO. > * the "Broken upgrade paths" mail is also really nice, but it should > also mail the responsible maintainers directly (if it doesn't do > already) and have (a additional?) list sorted by maintainer (looking out > for the names of all your package is probably not fun if you maintain a > lot of packages)? We might start collecting reusable Python code in a module, so it would become even easier to enhance new and existing scripts with extra features. > * is it time to clarify/simplify the Fedora Packaging guidelines again > to make them easier? Better don't. You cannot simplify them a lot because there are packages which are not simple to package/maintain. > * Scratch build target? > > * updates-testing repo for Extras? Both have been discussed multiple times before, and if not integrated _correctly_ we would end up with multiple build targets and "funny" side-effects in the build results. From paul at city-fan.org Sun Jul 9 15:03:45 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 09 Jul 2006 16:03:45 +0100 Subject: repodata shot? In-Reply-To: <1152451645.3734.198.camel@T7.Linux> References: <1152397491.3734.178.camel@T7.Linux> <1152450305.10312.26.camel@laurel.intra.city-fan.org> <1152451645.3734.198.camel@T7.Linux> Message-ID: <1152457426.10312.28.camel@laurel.intra.city-fan.org> On Sun, 2006-07-09 at 14:27 +0100, Paul wrote: > Hi, > > > > You are using the rawhide repositories, not FC5. My impression is > > > that GNOME 1 and Gtk 1 packages were removed from development. Some > > > have been added to Extras but gnome-libs is not one of them. > > > > I'm working on that. Hope to submit it (and its deps ORBit and libpng10) > > for review sometime next week. > > Thanks. Will the same be happening to oaf and gal? If they've been > orphaned, I'm happy to build them for extras. I don't think I need them (I'll be doing libglade though) so someone else will need to do those if they're needed. Paul. From gauret at free.fr Sun Jul 9 15:07:34 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 09 Jul 2006 17:07:34 +0200 Subject: [SIG Games] Package for TA Spring available Message-ID: Hi Fedora gamers, I've been packaging TA Spring recently, it's a clone of the famous game Total Anihilation, by Cavedog Entertainment (RIP). For those who don't know it, Total Anihilation was a great realtime strategy game, pretty impressive at the time (1997). See http://en.wikipedia.org/wiki/Total_Annihilation for more info. It's still under heavy development, but the Linux port begins to be playable. I don't know if I have sufficient interest in this game to maintain it further on, but since it was not listed on the Games wiki page, you might be interested in the spec files. You'll find them here: http://gauret.free.fr/fichiers/rpms/fedora/taspring-0.72-0.1.b1.src.rpm http://gauret.free.fr/fichiers/rpms/fedora/taspring.spec http://gauret.free.fr/fichiers/rpms/fedora/taspring-data-0.72-0.1.b1.src.rpm http://gauret.free.fr/fichiers/rpms/fedora/taspring-data.spec You'll also need: http://gauret.free.fr/fichiers/rpms/fedora/glew-1.3.4-1.src.rpm http://gauret.free.fr/fichiers/rpms/fedora/glew.spec There are still some areas to improve on : for example the game expects two dirs to be writable. Since I'm not good enough at C++ programming to patch it, I've symlinked those dirs to /var/games/taspring and set them 1777. Of course the best solution would be to have the game create subdirectories based on the user name, or even better look for them in ~/.taspring, but I have no idea how to patch that. If you are interested, feel free to grab my spec files, fix them, and submit them to Extras. It's a nice game, but in early stages of development... I hope you'll like it. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr I am the "ILOVEGNU" signature virus. Just copy me to your signature. This email was infected under the terms of the GNU General Public License. From mattdm at mattdm.org Sun Jul 9 15:11:59 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 9 Jul 2006 11:11:59 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B107CB.9070104@leemhuis.info> References: <44B107CB.9070104@leemhuis.info> Message-ID: <20060709151159.GA10946@jadzia.bu.edu> On Sun, Jul 09, 2006 at 03:42:35PM +0200, Thorsten Leemhuis wrote: > * can we stick to the "rolling release" scheme when anaconda will > start supporting external repos during install (the rolling release > scheme might break installs (not sure, but I think that is possible))? > And/or do we need Releases of Fedora Extras? E.g. ISOs of FE6 and a > stable repo on the servers and all new version go to a "updates" > directory (similar to core)? I think moving to proper releases (and an updates area) is vital to making Extras a true equal to core. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From gauret at free.fr Sun Jul 9 15:33:18 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 09 Jul 2006 17:33:18 +0200 Subject: Rolling Extras (was: Re: Recapitulate the current state of Fedora Extras and some ideas to make it better) References: <44B107CB.9070104@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > * can we stick to the "rolling release" scheme when anaconda will > start supporting external repos during install (the rolling release > scheme might break installs (not sure, but I think that is possible))? > And/or do we need Releases of Fedora Extras? E.g. ISOs of FE6 and a > stable repo on the servers and all new version go to a "updates" > directory (similar to core)? What I'd love to aim at is a structure similar to what FreeBSD has. A core system with release engineering, and the "ports collection", Extras here, which has a rolling scheme, but is rebuilt on each Core release. FreeBSD's base system is much more lightweight than the current Fedora Core (no X, no web servers, no databases, etc...), so we are very far from the same distinction, and we may not even want to push it this far, but separating the base system from the rest of the applications has *lots* of advantages from the administrator's and the user's point of view. No need to upgrade your OS to get the latest version of your favorite app, or of the services you're running on the box. So I would vote for a "rolling release" scheme in Extras, with a rebuild on each Core release to make sure Anaconda has something to feed on. This particular release could be kept on the mirrors (as we already keep the two last builds), just to be on the safe side with dependencies. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr The only "intuitive" interface is the nipple. After that it's all learned. From fedora at leemhuis.info Sun Jul 9 16:31:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 09 Jul 2006 18:31:51 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <20060709170107.facc519b.bugs.michael@gmx.net> References: <44B107CB.9070104@leemhuis.info> <20060709170107.facc519b.bugs.michael@gmx.net> Message-ID: <44B12F77.4050606@leemhuis.info> Michael Schwendt schrieb: > On Sun, 09 Jul 2006 15:42:35 +0200, Thorsten Leemhuis wrote: >> * FESCo >> * The old FESCo didn't work to well. A lot of members weren't very >> active. A lot of stuff was still discussed, but a lot of things didn't >> get done. Some things were discussed and agreed on, but not documented >> in the wiki. > There ought to be a web page with announcements. The history of decisions > made by FESCo. I think the FESCo meeting summaries should have a section annoucements. But I oppose a web page with a decision history. Decisions should be documented at a proper place where they belong (for exmplae the dead.package mechanism should be documented on the extras-cvs-faq page. Or in a maintainer guide). They need to be documented there in any case an maintaining two places is ridiculous IMHO. Note: Yes, for some decisions there might be no proper place. Creating a special page for them might be a good idea. >[...] >> * How FESCo works isn't much documented > It's not documented at all. And it will get more complex now that other > committees and project instances spring up like mushrooms. Agreed. >> * Discussions within FESCo and with the community are working often in >> acceptable ways on the lists and on IRC most of the time, but often >> nothing happens after the discussion is over and things remain unclear >> and undecided. > This paragraph contains a hint: "IRC" - those, who use IRC for real-time > discussions, need to share the results of the communication, using the > relevant mailing-lists. Agreed. > Participation in simple decisions "on list" has been poor, too, despite > FESCo consisting of 17 members. I think that will improve with the new FESCo members (and that was a reason for the Election). >> * Co-Maintainership >> * This is IMO one of the biggest areas we should work on soon > It is unimportant. It is important to work on... > Co-maintenance is possible for a long time. ..because it's not used. > [...] > The biggest hindrance in this area probably is the non-working "Cc" field > in owners.list. Agreed. And per-dist maintainers are also not possible >> * each package should IMHO have at least two maintainers (one of them >> should be the "primary maintainer", who has the last word if there are >> disagreements how to do things) > Not "each package", but packages with increased maintenance requirements > would benefit from a team of packagers. In my option: each package. Everyone is offline now and then or even on holiday for two or three weeks. A backup for those times would be good IMHO. >> * Quality >> * get a review SIG together that makes sure that each commit on >> fedora-commits-list is *roughly* checked for bogus changes (at least I >> do some bogus things now and then and I'd be glad if someone would tell me) > Unrealistic. Maybe. > For instance, I see 9817 unread/unfiltered messages in my > fedora-extras-commits folder. And while it may be easy to spot obvious > mistakes, I think it is and that's all I want because > it is less easy to find anything that's missing, especially > during upgrades. that is to hard job. >> * proper Rebuild policy for new releases (or automated rebuilds?) -- >> or we want to discuss this each time a new release comes up and decide >> on a case-by-case basis? Or simply rebuild all of Extras each time all >> of Core is rebuild? > Well, when Core is rebuilt due to important changes/improvements in GCC, > would it be possible that FESCo is notified about that? f13 announced the last mass-rebuilds on fedora-maintainers. And jeremy is in FESCo, I'm sure he'll poke us. > Or if somebody > within FESCo learns about such a rebuild, that there will be an official > announcement about what FE packagers should/must do? I'm not sure I understand you correctly. It for sure will be announced when FESCo agrees on a mass-rebuild. >> * we shouldn't maintain two orphan lists (e.g. one in the wiki and >> one in owners.list) > owners.list is insufficient. I love e-mail communication. Did I write anywhere the owners.list is the proper solution? No! > Not enough fields for the various state > information and/or comments. The package database is in the planing stages; please make sure it has all the fields you think that might be needed. > However, a policy could say that every package in owners.list which > belongs to extras-orphan@ must not exist in the devel > repository I think we agreed on that during the mass rebuild for FC5. > and must be > disabled in CVS. Sounds like a good idea. >> * we need to make the x86_64 more multilib aware (i386 packages in the >> x86_64 repo) > I've asked about it before, but have not found a wealth of information. > In this area we depend on Core. [...] Yes. >> * Sponsors should be able to "subscribe" to the people they sponsored >> -- e.g. they should get additional mails when people they sponsored >> commit something to cvs, requested a build ... > Not necessary for commits. I'd like to have them for commits. > Full name and user name are in the "From" > line in the mail header and in the "Author:" field of the body. Username might change and thus break local filters. Local filter can be forgotten. Or set up wrongly. Also non-sponsors might be interested in this feature as well. >[...] >> * fedora-devel-list, fedora-extras-list, fedora-maintainers -- these >> multiple lists get confusing, some things that are discussed on >> fedora-maintainers-list would be better suited for fedora-extras-list >> AFICS; > It's not the confusion that hurts, but the insane amount of cross-posting. Both AFAICS. I'd prefer if fedora-maintainers would be more like an moderated, non-discussion announce-list to inform all the maintainers about important things. Discussion on the other two lists. >> * the broken deps reports are really nice, but maybe we should merge >> them into one per push (currently it's one per dist) > ... and none if no broken deps are found. So fix your broken packages > and reduce the number of reports to one. :) :-) > Four (ore more) dists in one mail would decrease readability too much, > IMO. I disagree, but that's personal style. >> * is it time to clarify/simplify the Fedora Packaging guidelines again >> to make them easier? > Better don't. You cannot simplify them a lot because there are packages > which are not simple to package/maintain. I tend to agree. >> * Scratch build target? >> * updates-testing repo for Extras? > Both have been discussed multiple times before, and if not integrated > _correctly_ we would end up with multiple build targets and "funny" > side-effects in the build results. Yes. But that's not a rason to not have them on this list. Cu thl From fedora at adslpipe.co.uk Sun Jul 9 16:48:47 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Sun, 09 Jul 2006 17:48:47 +0100 Subject: Eiciel In-Reply-To: <20060708190820.191531ab.bugs.michael@gmx.net> References: <200607071821.k67ILZhr003980@mx3.redhat.com><44AFB229.1040104@adslpipe.co.uk> <20060708190820.191531ab.bugs.michael@gmx.net> Message-ID: <44B1336F.1020203@adslpipe.co.uk> Michael Schwendt wrote: >> -rw-r--r-- /usr/share/applications/eiciel.desktop >> -rw-r--r-- /usr/share/applications/fedora-eiciel.desktop > > Two desktop entries. The one that appeared here in the menu does not work: > > Could not launch menu item > > Details: Failed to execute child process > "/home/roger/eiciel/TEST/bin/eiciel" (No such file or directory) > > This indicates that you either want to remove "eiciel.desktop" or use it > as the source for "desktop-file-install", adding vendor and your own > changes, and using --delete-original to get rid of it. I see what happened there, originally eiciel didn't provide a .desktop file so I created one for my package and also provided it to the author, now I have updated to the latest source, I am picking up a broken .desktop file from the new source, so I will replace it with my version. From mpeters at mac.com Sun Jul 9 17:46:52 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 09 Jul 2006 10:46:52 -0700 Subject: Broken dependencies in Fedora Extras 5 - 2006-07-09 In-Reply-To: <20060709143355.14386.24636@extras64.linux.duke.edu> References: <20060709143355.14386.24636@extras64.linux.duke.edu> Message-ID: <1152467212.31677.2.camel@atlantis.mpeters.local> On Sun, 2006-07-09 at 14:33 +0000, Fedora Extras repoclosure wrote: > This is an automated mail created by an experimental script. > Your following packages in the repository contain broken dependencies: > > package: libvisual-plugins - 0.2.0-3.fc5.i386 from fedora-extras-5-i386 > unresolved deps: > libvisual.so.0 Having a slight problem - [mpeters at atlantis devel]$ make upload FILES="~/rpm/SOURCES/libvisual-plugins-0.4.0.tar.gz" Checking : libvisual-plugins-0.4.0.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status make: *** [upload] Error 255 [mpeters at atlantis devel]$ -=- Did the method for uploading a tarball change? From jwboyer at jdub.homelinux.org Sun Jul 9 17:57:22 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 09 Jul 2006 12:57:22 -0500 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B12F77.4050606@leemhuis.info> References: <44B107CB.9070104@leemhuis.info> <20060709170107.facc519b.bugs.michael@gmx.net> <44B12F77.4050606@leemhuis.info> Message-ID: <1152467842.14154.14.camel@vader.jdub.homelinux.org> On Sun, 2006-07-09 at 18:31 +0200, Thorsten Leemhuis wrote: > > Michael Schwendt schrieb: > > On Sun, 09 Jul 2006 15:42:35 +0200, Thorsten Leemhuis wrote: > >> * FESCo > >> * The old FESCo didn't work to well. A lot of members weren't very > >> active. A lot of stuff was still discussed, but a lot of things didn't > >> get done. Some things were discussed and agreed on, but not documented > >> in the wiki. > > There ought to be a web page with announcements. The history of decisions > > made by FESCo. > > I think the FESCo meeting summaries should have a section annoucements. > > But I oppose a web page with a decision history. Decisions should be > documented at a proper place where they belong (for exmplae the > dead.package mechanism should be documented on the extras-cvs-faq page. > Or in a maintainer guide). They need to be documented there in any case > an maintaining two places is ridiculous IMHO. > > Note: Yes, for some decisions there might be no proper place. Creating a > special page for them might be a good idea. +1 > >> * Co-Maintainership > >> * This is IMO one of the biggest areas we should work on soon > > It is unimportant. > > It is important to work on... > > > Co-maintenance is possible for a long time. > > ..because it's not used. > Not entirely the case. There are those that co-maintain packages already. Ville and I do this for tla. Admittedly, that is a fairly low-maintenance package though. > >> * proper Rebuild policy for new releases (or automated rebuilds?) -- > >> or we want to discuss this each time a new release comes up and decide > >> on a case-by-case basis? Or simply rebuild all of Extras each time all > >> of Core is rebuild? > > Well, when Core is rebuilt due to important changes/improvements in GCC, > > would it be possible that FESCo is notified about that? > > f13 announced the last mass-rebuilds on fedora-maintainers. And jeremy > is in FESCo, I'm sure he'll poke us. > > > Or if somebody > > within FESCo learns about such a rebuild, that there will be an official > > announcement about what FE packagers should/must do? > > I'm not sure I understand you correctly. It for sure will be announced > when FESCo agrees on a mass-rebuild. Maybe we should revisit how Extras rebuilds are done too. Personally, I like the way they're handled in Core. A single person starts it and maintainers email him if they _do not_ want their package rebuilt for whatever reason. IMHO, that provides the advantage that the number of cats to herd is fewer. > > Also non-sponsors might be interested in this feature as well. > > >[...] > >> * fedora-devel-list, fedora-extras-list, fedora-maintainers -- these > >> multiple lists get confusing, some things that are discussed on > >> fedora-maintainers-list would be better suited for fedora-extras-list > >> AFICS; > > It's not the confusion that hurts, but the insane amount of cross-posting. > > Both AFAICS. > > I'd prefer if fedora-maintainers would be more like an moderated, > non-discussion announce-list to inform all the maintainers about > important things. Discussion on the other two lists. Actually, I disagree. Having a list for Extras and a list for Core just segregates things more. This is a case where I think we need cohesion. We're already talking about doing releases differently to be more like Core, and various other Core<->Extras merge type issues, so having a single list for all package maintainers to discuss is a step towards that goal. josh From j.w.r.degoede at hhs.nl Sun Jul 9 18:05:33 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 09 Jul 2006 20:05:33 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <1152453259.8685.26.camel@rousalka.dyndns.org> References: <44B107CB.9070104@leemhuis.info> <1152453259.8685.26.camel@rousalka.dyndns.org> Message-ID: <44B1456D.2030303@hhs.nl> Nicolas Mailhot wrote: > Le dimanche 09 juillet 2006 ? 15:42 +0200, Thorsten Leemhuis a ?crit : > >> * The wiki was a great place for informations in the beginning of >> Fedora Extras and still offers a lot of informations, but a lot of >> things are not probably documented. I might be time for a big cleanup. > > FE has probably grown enough now to require a full-time dedicated > documentation team. Everyone hates doing doc and it doesn't help that > some pages are locked. > > Good doc means less review work and disagreements of what the damn > guidelines actually say (and on which wiki page the clear rule is > hidden). > > (but at least we suck less than core) > > Today I had a refrehsing drink in the sun with a friend of mine and we had a discussion about Fedora and about how despite Fedora being GREAT Ubuntu seems to be way more popular. One of the things he mentioned was the negative tone on the Fedora mailinglist, I disagreed. But reading this: he is right. We should drop the negative tone. Neither Core nor Extras do _NOT_ sucks at all. Yes certain things are better in Extras then Core, but we have it easier, they have all the _really_ _hard_ packages. And yes even we are not perfect, but both core and extras are pretty good if not excellent in the case of Extras. So not perfect, but most certainly not sucking at all! Talking about this negative attitude, we need to improve our self image as a community and we need to work on our image to the rest of the worl too, time for a Fedora Marketing team? Regards, Hans From j.w.r.degoede at hhs.nl Sun Jul 9 18:15:03 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 09 Jul 2006 20:15:03 +0200 Subject: QA ideas (was Recapitulate the current state of Fedora Extras and some ideas to make it better) In-Reply-To: <44B107CB.9070104@leemhuis.info> References: <44B107CB.9070104@leemhuis.info> Message-ID: <44B147A7.8060304@hhs.nl> Thorsten Leemhuis wrote: > Hi all! > > * set up scripts that check existing Spec-Files and packages > automatically for bogus things and new rules/behaviors or common > problems (empty debuginfo, hardcoded rpath, ...) > I was thinking about how right you are on this and then I had a very good idea, someone (with more experience with this then me and buildsys / cvs server access) should write a script which periodically 1) runs rpmlint on all RPMs 2) compares the output of this script with the following file in CVS: //rpmlint.ignore and removes all lines from the output which match with lines in this file. 3) mailes the maintainer of the checked package if there is any ouput left after removing the ignored lines I'm really enthousiastic about this idea, it would be great for QA and should be easy to implement! My only worry is the possible resource drain on the system doing the checking. Taking this one step further, in order to maximally benefit from this rpmlint should be extended to check as much of the packaging and review guidelines automaticly as possible, once rpmlint does this, then the review guidelines should be modified so that a part of the to check list gets moved to a seperate page which documents things checked by rpmlint, and the actual list of things that need checking manually for review can be reduced making reviews easier. Also I think that asap the package submission prococedure should be modified to make it mandatory for submitters to run rpmlint themselves and include the output in the initial review submission including motivations for the ignoring of each warning / error given by rpmlint Regards, Hans p.s. As said I'm going on vacation tomorrow so don't expect any quick replies to replies on this :) From ville.skytta at iki.fi Sun Jul 9 18:14:20 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 09 Jul 2006 21:14:20 +0300 Subject: "make upload" problems (was: Re: Broken dependencies in Fedora Extras 5 - 2006-07-09) In-Reply-To: <1152467212.31677.2.camel@atlantis.mpeters.local> References: <20060709143355.14386.24636@extras64.linux.duke.edu> <1152467212.31677.2.camel@atlantis.mpeters.local> Message-ID: <1152468860.2728.421.camel@localhost.localdomain> On Sun, 2006-07-09 at 10:46 -0700, Michael A. Peters wrote: > [mpeters at atlantis devel]$ make upload > FILES="~/rpm/SOURCES/libvisual-plugins-0.4.0.tar.gz" > > Checking : libvisual-plugins-0.4.0.tar.gz on > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > ERROR: could not check remote file status > make: *** [upload] Error 255 > [mpeters at atlantis devel]$ > > -=- > > Did the method for uploading a tarball change? No, but this has been reported already a couple of times and the suggestion to grab a renewed client cert at https://admin.fedoraproject.org/accounts/ has ended those threads pretty quickly. I don't remember if anyone has explicitly reported that it fixed this particular problem though, but it does fix plague-client errors like this: http://fedoraproject.org/wiki/Extras/BuildRequests From j.w.r.degoede at hhs.nl Sun Jul 9 18:18:15 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 09 Jul 2006 20:18:15 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <20060709170107.facc519b.bugs.michael@gmx.net> References: <44B107CB.9070104@leemhuis.info> <20060709170107.facc519b.bugs.michael@gmx.net> Message-ID: <44B14867.4070506@hhs.nl> Michael Schwendt wrote: >> * Co-Maintainership >> >> * This is IMO one of the biggest areas we should work on soon > > It is unimportant. Co-maintenance is possible for a long time. It > just needs additional communication between those who team up. > I wouldn't call it unimportant, having some guideliness for this might be good, but not much is needed, agreed. > The biggest hindrance in this area probably is the non-working "Cc" field > in owners.list. > YES YES YES +a zillion, can we please get this fixed? (someone who does co-maintainance already!) Regards, Hans From j.w.r.degoede at hhs.nl Sun Jul 9 18:20:18 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 09 Jul 2006 20:20:18 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <1152467842.14154.14.camel@vader.jdub.homelinux.org> References: <44B107CB.9070104@leemhuis.info> <20060709170107.facc519b.bugs.michael@gmx.net> <44B12F77.4050606@leemhuis.info> <1152467842.14154.14.camel@vader.jdub.homelinux.org> Message-ID: <44B148E2.9020001@hhs.nl> Josh Boyer wrote: > On Sun, 2006-07-09 at 18:31 +0200, Thorsten Leemhuis wrote: >> Michael Schwendt schrieb: >>> On Sun, 09 Jul 2006 15:42:35 +0200, Thorsten Leemhuis wrote: >>>> * Co-Maintainership >>>> * This is IMO one of the biggest areas we should work on soon >>> It is unimportant. >> It is important to work on... >> >>> Co-maintenance is possible for a long time. >> ..because it's not used. >> > > Not entirely the case. There are those that co-maintain packages > already. Ville and I do this for tla. Admittedly, that is a fairly > low-maintenance package though. > Simply not true is more like it. John Novy and I co maintain allegro, and Shitlesh and I ode and xxx and yyy, zzz. this is already done!! Regards, Hans From j.w.r.degoede at hhs.nl Sun Jul 9 18:22:09 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 09 Jul 2006 20:22:09 +0200 Subject: repodata shot? In-Reply-To: <1152450305.10312.26.camel@laurel.intra.city-fan.org> References: <1152397491.3734.178.camel@T7.Linux> <1152450305.10312.26.camel@laurel.intra.city-fan.org> Message-ID: <44B14951.8040103@hhs.nl> Paul Howarth wrote: > On Sat, 2006-07-08 at 18:38 -0700, Ian Burrell wrote: >> On 7/8/06, Paul wrote: >> You are using the rawhide repositories, not FC5. My impression is >> that GNOME 1 and Gtk 1 packages were removed from development. Some >> have been added to Extras but gnome-libs is not one of them. > > I'm working on that. Hope to submit it (and its deps ORBit and libpng10) > for review sometime next week. > Ouch, legacy people, legacy how many apps need these? How hard would it be to port them to something newer, what will be more work in the near future? Regards, Hans From ville.skytta at iki.fi Sun Jul 9 18:28:11 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 09 Jul 2006 21:28:11 +0300 Subject: QA ideas (was Recapitulate the current state of Fedora Extras and some ideas to make it better) In-Reply-To: <44B147A7.8060304@hhs.nl> References: <44B107CB.9070104@leemhuis.info> <44B147A7.8060304@hhs.nl> Message-ID: <1152469692.2728.434.camel@localhost.localdomain> On Sun, 2006-07-09 at 20:15 +0200, Hans de Goede wrote: > I was thinking about how right you are on this and then I had a very > good idea, someone (with more experience with this then me and buildsys > / cvs server access) should write a script which periodically > 1) runs rpmlint on all RPMs > 2) compares the output of this script with the following file in CVS: > //rpmlint.ignore > and removes all lines from the output which match with lines in this > file. > 3) mailes the maintainer of the checked package if there is any ouput > left after removing the ignored lines > > I'm really enthousiastic about this idea, it would be great for QA and > should be easy to implement! My only worry is the possible resource > drain on the system doing the checking. I've been eyeballing this every now and then too but haven't got around to doing anything about it. Debian has something very similar if not exactly the above in place already plus more, perhaps something could be borrowed from there: http://lintian.debian.org/ BTW, it should be trivial to implement the rpmlint.ignore part, just make it a rpmlint config file, add addFilter()'s as necessary (see /usr/share/rpmlint/config for examples) and invoke rpmlint with "-f /path/to///rpmlint.ignore". Folks should keep a pretty close eye on commits to those files though. > Also I think that asap the package submission prococedure should be > modified to make it mandatory for submitters to run rpmlint themselves > and include the output in the initial review submission including > motivations for the ignoring of each warning / error given by rpmlint +1. It should be also allowed and encouraged to just submit and ask for help if one doesn't know a good way to handle error/warning X instead of just desperately trying to get a clean output no matter what before the submission. From jonathan.underwood at gmail.com Sun Jul 9 18:41:26 2006 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 9 Jul 2006 19:41:26 +0100 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B107CB.9070104@leemhuis.info> References: <44B107CB.9070104@leemhuis.info> Message-ID: <645d17210607091141l7879e120l2f817361f401c5f6@mail.gmail.com> On 09/07/06, Thorsten Leemhuis wrote: > * Co-Maintainership > > * This is IMO one of the biggest areas we should work on soon > > * each package should IMHO have at least two maintainers (one of them > should be the "primary maintainer", who has the last word if there are > disagreements how to do things) This keeps coming up, and everyone agrees that co-maintainence is a good idea whenever possible (i.e. where there are willing people). OTOH very few people agree that having only a single maintainer should be a blocker, but that's ok. However, the CC list remains broken and the status quo remains. Without wishing to criticise, I genuinely wonder what is blocking progress on this? What can we do to help? Jonathan. From Matt_Domsch at dell.com Sun Jul 9 18:41:30 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 9 Jul 2006 13:41:30 -0500 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B12F77.4050606@leemhuis.info> References: <44B107CB.9070104@leemhuis.info> <20060709170107.facc519b.bugs.michael@gmx.net> <44B12F77.4050606@leemhuis.info> Message-ID: <20060709184130.GB25188@lists.us.dell.com> On Sun, Jul 09, 2006 at 06:31:51PM +0200, Thorsten Leemhuis wrote: > > > Michael Schwendt schrieb: > > On Sun, 09 Jul 2006 15:42:35 +0200, Thorsten Leemhuis wrote: > >> * FESCo > >> * The old FESCo didn't work to well. A lot of members weren't very > >> active. A lot of stuff was still discussed, but a lot of things didn't > >> get done. Some things were discussed and agreed on, but not documented > >> in the wiki. > > There ought to be a web page with announcements. The history of decisions > > made by FESCo. > > I think the FESCo meeting summaries should have a section annoucements. > > But I oppose a web page with a decision history. Decisions should be > documented at a proper place where they belong (for exmplae the > dead.package mechanism should be documented on the extras-cvs-faq page. > Or in a maintainer guide). They need to be documented there in any case > >> * Sponsors should be able to "subscribe" to the people they sponsored > >> -- e.g. they should get additional mails when people they sponsored > >> commit something to cvs, requested a build ... > > Not necessary for commits. > > I'd like to have them for commits. procmail. # Filter for my own packages :0 Hc * ^X-BeenThere:.*fedora-extras-commits at redhat.com * ? formail -x"Subject:" | egrep -is -f $HOME/.procmail-fedora-extras-packages $HOME/Mail/fe-mypackages > > Full name and user name are in the "From" > > line in the mail header and in the "Author:" field of the body. > > Username might change and thus break local filters. Local filter can be > forgotten. Or set up wrongly. > > Also non-sponsors might be interested in this feature as well. Sure, it can be over-engineered, but need it be? -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From ville.skytta at iki.fi Sun Jul 9 19:19:45 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 09 Jul 2006 22:19:45 +0300 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <645d17210607091141l7879e120l2f817361f401c5f6@mail.gmail.com> References: <44B107CB.9070104@leemhuis.info> <645d17210607091141l7879e120l2f817361f401c5f6@mail.gmail.com> Message-ID: <1152472785.2728.439.camel@localhost.localdomain> On Sun, 2006-07-09 at 19:41 +0100, Jonathan Underwood wrote: > However, the CC list remains broken and > the status quo remains. Without wishing to criticise, I genuinely > wonder what is blocking progress on this? What can we do to help? Seconded, but even though I haven't touched that field for a while, I thought a Bugzilla report wouldn't hurt. Those who know the details about how it doesn't work (for new entries? for updating old entries only? not at all?), go add some information at https://bugzilla.redhat.com/198109 From fedora at leemhuis.info Sun Jul 9 19:26:26 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 09 Jul 2006 21:26:26 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B148E2.9020001@hhs.nl> References: <44B107CB.9070104@leemhuis.info> <20060709170107.facc519b.bugs.michael@gmx.net> <44B12F77.4050606@leemhuis.info> <1152467842.14154.14.camel@vader.jdub.homelinux.org> <44B148E2.9020001@hhs.nl> Message-ID: <44B15862.4070300@leemhuis.info> Hans de Goede schrieb: > > Josh Boyer wrote: >> On Sun, 2006-07-09 at 18:31 +0200, Thorsten Leemhuis wrote: >>> Michael Schwendt schrieb: >>>> On Sun, 09 Jul 2006 15:42:35 +0200, Thorsten Leemhuis wrote: >>>>> * Co-Maintainership >>>>> * This is IMO one of the biggest areas we should work on soon >>>> It is unimportant. >>> It is important to work on... >>>> Co-maintenance is possible for a long time. >>> ..because it's not used. >> Not entirely the case. There are those that co-maintain packages >> already. Ville and I do this for tla. Admittedly, that is a fairly >> low-maintenance package though. > Simply not true is more like it. John Novy and I co maintain allegro, > and Shitlesh and I ode and xxx and yyy, zzz. this is already done!! Yeah, sorry, there should have been a "nearly" between "because" and "it's not used..". But it still think it should be used a lot more. CU thl From nman64 at n-man.com Sun Jul 9 20:03:12 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sun, 9 Jul 2006 15:03:12 -0500 Subject: What do Extras contributors use the wiki for? Message-ID: <200607091503.16790.nman64@n-man.com> In order to reduce the complexity in getting started with Extras, we have made a few adjustments in the past to avoid making EditGroup membership a requirement for Extras contributors. At present, some pages, like CVSSyncNeeded, have special ACLs that avoid the normal EditGroup requirement. I'd like to know where Extras contributors might currently need EditGroup membership in order to perform required tasks. Until we have a single sign-on ability (which is an Infrastructure to-do item), I'd like to enable Extras contributors to do their jobs without requiring EditGroup membership. While EditGroup membership is a small step for members of cvsextras, it is one step that we can avoid, and every little bit helps in the overcomplicated process that new contributors must currently complete. Candidates for adjustment include pages that any Extras contributor needs to edit but do not provide content to end-users. Eligible pages might include tracking pages, schedules or task lists. Ineligible pages would include SIG pages, documentation pages or policy pages. Some examples that I have already seen for eligible pages are the FCx Status pages, User Registry, Orphaned Packages List and Wish List. Does anyone have other pages to suggest or any reasons why these examples shouldn't be opened up? -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Matt_Domsch at dell.com Sun Jul 9 20:42:02 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 9 Jul 2006 15:42:02 -0500 Subject: obsolete dependencies on libsysfs.so.1 Message-ID: <20060709204202.GA18609@lists.us.dell.com> Core no longer contains libsysfs.so.1. The following packages currently in -development have dependencies on this library. This causes these apps to fail to upgrade (I noticed this as kdebase requires lm_sensors which requires libsysfs.so.1 thus that upgrade failed; there are other failure paths as well of course...). Core: cpufreq-utils-002-1.1.37 device-mapper-multipath-0.4.7-2.0 lm_sensors-2.10.0-2 (BZ #198055 filed) openhpi-2.4.1-4 Extras: directfb-0.9.24-5.fc5 (BZ #198111 filed) libibverbs-1.0.3-1.fc6 libibverbs-utils-1.0.3-1.fc6 Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From nicolas.mailhot at laposte.net Sun Jul 9 20:56:09 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 09 Jul 2006 22:56:09 +0200 Subject: QA ideas (was Recapitulate the current state of Fedora Extras and some ideas to make it better) In-Reply-To: <44B147A7.8060304@hhs.nl> References: <44B107CB.9070104@leemhuis.info> <44B147A7.8060304@hhs.nl> Message-ID: <1152478571.8685.58.camel@rousalka.dyndns.org> Le dimanche 09 juillet 2006 ? 20:15 +0200, Hans de Goede a ?crit : > > Thorsten Leemhuis wrote: > > Hi all! > > > > * set up scripts that check existing Spec-Files and packages > > automatically for bogus things and new rules/behaviors or common > > problems (empty debuginfo, hardcoded rpath, ...) > > > > I was thinking about how right you are on this and then I had a very > good idea, someone (with more experience with this then me and buildsys > / cvs server access) should write a script which periodically It's good to do periodic checks but what's more good is to trace evolutions over time : 1. is the number of broken packages increasing or decreasing ? 2. how long was a package broken in the last months, is the maintainer caring about it or letting it break for long periods of times ? 3. is it always breaking for the same reasons ? 4. how many bugs where opened against it ? All these things can be traced by plugging rddtools on your tests results. I doubt many people remember enough of the past now to correlate the test results with FC5t2 for example -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Sun Jul 9 21:18:09 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 09 Jul 2006 23:18:09 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B1456D.2030303@hhs.nl> References: <44B107CB.9070104@leemhuis.info> <1152453259.8685.26.camel@rousalka.dyndns.org> <44B1456D.2030303@hhs.nl> Message-ID: <1152479889.8685.78.camel@rousalka.dyndns.org> Le dimanche 09 juillet 2006 ? 20:05 +0200, Hans de Goede a ?crit : > Neither Core nor Extras do _NOT_ sucks at all. Yes certain things are > better in Extras then Core, but we have it easier, they have all the > _really_ _hard_ packages. And yes even we are not perfect, but both core > and extras are pretty good if not excellent in the case of Extras. > > So not perfect, but most certainly not sucking at all! > > Talking about this negative attitude, we need to improve our self image > as a community and we need to work on our image to the rest of the worl > too, time for a Fedora Marketing team? Hans, In case you haven't noticed we do have a marketing team with poor people trying to improve Fedora Core and Extras image. Including yours truly who just donated a big part of his week-end writing positive glowing prose about Fedora for a reporter. However what's good for the press is not good for a technical list. On a technical list we try to get work done and that means being honest and not shying before hard truths. If you want to improve Fedora image go work on the wiki, submit articles about Fedora to webzines, give helpful advice to newcomers on the help forums. But do not turn the PC police on the tech lists because Fedora didn't get insanely great (and I do think it's insanely great) by lying to itself about its problems. We do have some problems and the first step to solve them is admit they exist. And I'll stop there because after this evening final I'm not in the best moods to argue with you. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dwmw2 at infradead.org Sun Jul 9 22:18:32 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 09 Jul 2006 23:18:32 +0100 Subject: obsolete dependencies on libsysfs.so.1 In-Reply-To: <20060709204202.GA18609@lists.us.dell.com> References: <20060709204202.GA18609@lists.us.dell.com> Message-ID: <1152483512.3018.16.camel@pmac.infradead.org> On Sun, 2006-07-09 at 15:42 -0500, Matt Domsch wrote: > Core no longer contains libsysfs.so.1. The following packages > currently in -development have dependencies on this library. This > causes these apps to fail to upgrade (I noticed this as kdebase > requires lm_sensors which requires libsysfs.so.1 thus that upgrade > failed; there are other failure paths as well of course...). > > Core: > cpufreq-utils-002-1.1.37 > device-mapper-multipath-0.4.7-2.0 > lm_sensors-2.10.0-2 (BZ #198055 filed) > openhpi-2.4.1-4 Your list is missing iprutils. -- dwmw2 From Matt_Domsch at dell.com Sun Jul 9 23:00:44 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 9 Jul 2006 18:00:44 -0500 Subject: obsolete dependencies on libsysfs.so.1 In-Reply-To: <1152483512.3018.16.camel@pmac.infradead.org> References: <20060709204202.GA18609@lists.us.dell.com> <1152483512.3018.16.camel@pmac.infradead.org> Message-ID: <20060709230044.GB18609@lists.us.dell.com> On Sun, Jul 09, 2006 at 11:18:32PM +0100, David Woodhouse wrote: > On Sun, 2006-07-09 at 15:42 -0500, Matt Domsch wrote: > > Core no longer contains libsysfs.so.1. The following packages > > currently in -development have dependencies on this library. This > > causes these apps to fail to upgrade (I noticed this as kdebase > > requires lm_sensors which requires libsysfs.so.1 thus that upgrade > > failed; there are other failure paths as well of course...). > > > > Core: > > cpufreq-utils-002-1.1.37 > > device-mapper-multipath-0.4.7-2.0 > > lm_sensors-2.10.0-2 (BZ #198055 filed) > > openhpi-2.4.1-4 > > Your list is missing iprutils. indeed, and bridge-utils. I hadn't realized these were being caught by the daily rawhide report, and that for Core, package maintainers get auto-spammed by same. I went and filed bugs though against those in my last message that didn't have bugs filed. What's the Core equivalent of Extras' owners/owners.list? Each of the tools that's generating Core+Extras stats could make use of such to identify package owneres too. Thanks, Mat -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From sundaram at fedoraproject.org Sun Jul 9 23:09:57 2006 From: sundaram at fedoraproject.org (Rahul) Date: Mon, 10 Jul 2006 04:39:57 +0530 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B1456D.2030303@hhs.nl> References: <44B107CB.9070104@leemhuis.info> <1152453259.8685.26.camel@rousalka.dyndns.org> <44B1456D.2030303@hhs.nl> Message-ID: <44B18CC5.6090403@fedoraproject.org> Hans de Goede wrote: > > > > Today I had a refrehsing drink in the sun with a friend of mine and we > had a discussion about Fedora and about how despite Fedora being GREAT > Ubuntu seems to be way more popular. > > One of the things he mentioned was the negative tone on the Fedora > mailinglist, I disagreed. But reading this: he is right. We should drop > the negative tone. > > Neither Core nor Extras do _NOT_ sucks at all. Yes certain things are > better in Extras then Core, but we have it easier, they have all the > _really_ _hard_ packages. And yes even we are not perfect, but both core > and extras are pretty good if not excellent in the case of Extras. > > So not perfect, but most certainly not sucking at all! > > Talking about this negative attitude, we need to improve our self image > as a community and we need to work on our image to the rest of the worl > too, time for a Fedora Marketing team? > Awareness also helps. http://fedoraproject.org/wiki/Marketing. All help is most welcome. Rahul From sundaram at fedoraproject.org Sun Jul 9 23:34:44 2006 From: sundaram at fedoraproject.org (Rahul) Date: Mon, 10 Jul 2006 05:04:44 +0530 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B107CB.9070104@leemhuis.info> References: <44B107CB.9070104@leemhuis.info> Message-ID: <44B19294.1020106@fedoraproject.org> Thorsten Leemhuis wrote: > Hi all! > > * Why isn't the Fedora Directory Server still not in Extras? I had already brought this up recently in a board discussion. Will start a new one in the the Fedora advisory board list. > > * How FESCo works isn't much documented Someone within FESCo would be the ideal candidate. > > * Discussions within FESCo and with the community are working often in > acceptable ways on the lists and on IRC most of the time, but often > nothing happens after the discussion is over and things remain unclear > and undecided. Assign a owner to keep track of every agenda item. > > * we should have someone that fills the Fedora Weekly reports Someone please step up. > > * Better web interface -- "yum search" is really slow and people on > Windows or using other distributions should be able to search for > packages and their contents, too Many people use yum search where they really want to just grep the yum list. Maybe we need a yum search list or something like that to do this better or have this as the default with extras arguments for other kind of searches. > > * we need a defined and documented policy to get definite answers for > open legal question > Kindly contact the Fedora advisory board where our counsel is a member. Call this policy. http://fedoraproject.org/wiki/Board > * Long-Term Fedora Extras contributors should get a small reward now > and then: A Pen, Sticker, T-Shirt, LWN subscription, ... Another item for FAB. I will start a discussion. > > * close the gap between Core and Extras as far as possible Would be quite useful to document every single difference between core and extras somewhere so that we can tackle this as we move along. Can someone do this? Rahul From jkeating at redhat.com Sun Jul 9 23:54:00 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 9 Jul 2006 19:54:00 -0400 Subject: obsolete dependencies on libsysfs.so.1 In-Reply-To: <20060709230044.GB18609@lists.us.dell.com> References: <20060709204202.GA18609@lists.us.dell.com> <1152483512.3018.16.camel@pmac.infradead.org> <20060709230044.GB18609@lists.us.dell.com> Message-ID: <200607091954.04181.jkeating@redhat.com> On Sunday 09 July 2006 19:00, Matt Domsch wrote: > What's the Core equivalent of Extras' owners/owners.list? Each of the > tools that's generating Core+Extras stats could make use of such to > identify package owneres too. Currently there is a database within Red Hat that holds this information. It's part of brew, and it has the capability of one owner per release, so FC5's owner for grub could be different from RHEL4's owner of grub. This information is synced to bugzilla on a regular basis, so we could probably query bugzilla for component ownership of a given package. The good news is that the same method could be used for Core and Extras since bugzilla is used for both (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jul 9 23:57:37 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 9 Jul 2006 19:57:37 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B19294.1020106@fedoraproject.org> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> Message-ID: <200607091957.37579.jkeating@redhat.com> On Sunday 09 July 2006 19:34, Rahul wrote: > > ? * Better web interface -- "yum search" is really slow and people on > > Windows or using other distributions should be able to search for > > packages and their contents, too > > Many people use yum search where they really want to just grep the yum > list. Maybe we need a yum search list or something like that to do this > better or have this as the default with extras arguments for other kind > of searches. Something like this: http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/repodata/ ? We have one for Core too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wart at kobold.org Mon Jul 10 00:14:17 2006 From: wart at kobold.org (Wart) Date: Sun, 09 Jul 2006 17:14:17 -0700 Subject: Provides for Obsoletes Message-ID: <44B19BD9.4080407@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a package crossfire-maps-1.9.0 that also Provides: crossfire-maps-devel. The contents of the -devel package are map templates and one or two .c files that show how to randomly generate maps. Upstream recently released 1.9.1, and in this new version the contents of the -devel subpackage are now required at runtime. I merged the - -devel and base packages together, and added "Obsoletes: crossfire-maps-devel". Now rpmlint complains: E: crossfire-maps obsolete-not-provided crossfire-maps-devel ...which I think is bogus because nothing should depend on the -devel subpackage. Is there any reason why I need to add the Provides: for the obsoleted - -devel subpackage? - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEsZvYDeYlPfs40g8RAhkSAJwN5/KRLYCRfpy8bzTv7MYDsg7xOgCfQXpE x98PTSnTY+JTEzkCsms+wPk= =den2 -----END PGP SIGNATURE----- From jkeating at redhat.com Mon Jul 10 00:21:11 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 9 Jul 2006 20:21:11 -0400 Subject: Provides for Obsoletes In-Reply-To: <44B19BD9.4080407@kobold.org> References: <44B19BD9.4080407@kobold.org> Message-ID: <200607092021.11259.jkeating@redhat.com> On Sunday 09 July 2006 20:14, Wart wrote: > Is there any reason why I need to add the Provides: for the obsoleted > -devel subpackage? For an upgrade path. People that currently have -devel package installed will need to have it go away when they update to your new package. If your new package Obsoletes the -devel package, the update will break if the new package doesn't also provide crossfire-maps-devel. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Mon Jul 10 02:59:36 2006 From: wtogami at redhat.com (Warren Togami) Date: Sun, 09 Jul 2006 22:59:36 -0400 Subject: obsolete dependencies on libsysfs.so.1 In-Reply-To: <20060709204202.GA18609@lists.us.dell.com> References: <20060709204202.GA18609@lists.us.dell.com> Message-ID: <44B1C298.5070907@redhat.com> Matt Domsch wrote: > Extras: > directfb-0.9.24-5.fc5 (BZ #198111 filed) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198111 I attempted to just rebuild it in an attempt to make upgrading smoother sooner, but build failure occurs on x86_64. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Jul 10 03:40:00 2006 From: wtogami at redhat.com (Warren Togami) Date: Sun, 09 Jul 2006 23:40:00 -0400 Subject: Move Squirrelmail to Extras? In-Reply-To: References: Message-ID: <44B1CC10.8060204@redhat.com> Konstantin Ryabitsev wrote: > Would it make sense to move Squirrelmail to Extras? I am the upstream > package maintainer, and would happily maintain it here instead of > having to do it on squirrelmail.org. > > Cheers, I'd like to move it to Extras too. Would you like to coordinate and be co-maintainers of squirrelmail? http://cvs.fedora.redhat.com/viewcvs/devel/squirrelmail/ Beware. Red Hat's squirrelmail has a large amount of ugly looking i18n and language specific fixes and hacks. Some of these fixes need to be pushed upstream, but others (like the scripted mass encoding change) might never be accepted upstream. I'd also prefer to keep it a single package that Provides squirrelmail-i18n rather than split it like your upstream package. Is this problematic? Aside from this sub-package difference, I made modifications to the Red Hat package over the past years in an attempt to make it upgrade compatible with your upstream package. What things would you like to do to the current fc6 package? Let's discuss this. Thanks, Warren Togami wtogami at redhat.com From fedora at leemhuis.info Mon Jul 10 05:00:17 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 10 Jul 2006 07:00:17 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <20060709184130.GB25188@lists.us.dell.com> References: <44B107CB.9070104@leemhuis.info> <20060709170107.facc519b.bugs.michael@gmx.net> <44B12F77.4050606@leemhuis.info> <20060709184130.GB25188@lists.us.dell.com> Message-ID: <1152507617.2944.9.camel@thl.ct.heise.de> Am Sonntag, den 09.07.2006, 13:41 -0500 schrieb Matt Domsch: > On Sun, Jul 09, 2006 at 06:31:51PM +0200, Thorsten Leemhuis wrote: > > Michael Schwendt schrieb: > > > On Sun, 09 Jul 2006 15:42:35 +0200, Thorsten Leemhuis wrote: > > >> * FESCo > > >> * The old FESCo didn't work to well. A lot of members weren't very > > >> active. A lot of stuff was still discussed, but a lot of things didn't > > >> get done. Some things were discussed and agreed on, but not documented > > >> in the wiki. > > > There ought to be a web page with announcements. The history of decisions > > > made by FESCo. > > I think the FESCo meeting summaries should have a section annoucements. > > But I oppose a web page with a decision history. Decisions should be > > documented at a proper place where they belong (for exmplae the > > dead.package mechanism should be documented on the extras-cvs-faq page. > > Or in a maintainer guide). They need to be documented there in any case > > >> * Sponsors should be able to "subscribe" to the people they sponsored > > >> -- e.g. they should get additional mails when people they sponsored > > >> commit something to cvs, requested a build ... > > > Not necessary for commits. > > I'd like to have them for commits. > procmail. > # Filter for my own packages > :0 Hc > * ^X-BeenThere:.*fedora-extras-commits at redhat.com > * ? formail -x"Subject:" | egrep -is -f $HOME/.procmail-fedora-extras-packages > $HOME/Mail/fe-mypackages Sure, that's a solution (at least for all those that use procmail). But I'd prefer a solution on the server side that gets maintained automatically because a local setup is much more likely to break (package renames, forgetting to add new packages,...). Also imagine people like spot -- he sponsored 31 people (don't know how many packages they own) and owns 94 packages. Do you want to main a $HOME/.procmail-fedora-extras-packages file for him? That's what computers are good for. Also: People tend to set up filters wrongly. During the "FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected" discussion I chatted with a contributor privately. He told me that he won't miss commits from other people to his packages because be has a filter that (as he thought) copies all commits to his packages to a special folder. But after one or to minutes he said -- "OMG -- I set up the filter wrongly -- it only copies commits that are from me to that folders, so I won't miss all the commits from other people to my packages." > > > Full name and user name are in the "From" > > > line in the mail header and in the "Author:" field of the body. > > Username might change and thus break local filters. Local filter can be > > forgotten. Or set up wrongly. > > Also non-sponsors might be interested in this feature as well. > Sure, it can be over-engineered, but need it be? That's why the initial mail had "[...] should be realized soon and what can be worked on later (or ignored completely)." ;-) CU thl From cweyl at alumni.drew.edu Mon Jul 10 05:09:51 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sun, 9 Jul 2006 22:09:51 -0700 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <1152507617.2944.9.camel@thl.ct.heise.de> References: <44B107CB.9070104@leemhuis.info> <20060709170107.facc519b.bugs.michael@gmx.net> <44B12F77.4050606@leemhuis.info> <20060709184130.GB25188@lists.us.dell.com> <1152507617.2944.9.camel@thl.ct.heise.de> Message-ID: <7dd7ab490607092209g71de3f67wa52c6619abffd5a0@mail.gmail.com> On 7/9/06, Thorsten Leemhuis wrote: > Sure, that's a solution (at least for all those that use procmail). But > I'd prefer a solution on the server side that gets maintained > automatically because a local setup is much more likely to break > (package renames, forgetting to add new packages,...). A point you just made in passing is relevant -- I suspect there are a goodly number of us (like me) who prefer to let the good folks at google (or elsewhere) deal with our mail, and lack the ability to create truly sophisticated filters. A solution on the server side is consistent, universal, and places no additional "you MUSTs" on people. -Chris -- Chris Weyl Ex astris, scientia From seg at haxxed.com Mon Jul 10 06:47:10 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 10 Jul 2006 01:47:10 -0500 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B1456D.2030303@hhs.nl> References: <44B107CB.9070104@leemhuis.info> <1152453259.8685.26.camel@rousalka.dyndns.org> <44B1456D.2030303@hhs.nl> Message-ID: <1152514031.3170.33.camel@localhost> On Sun, 2006-07-09 at 20:05 +0200, Hans de Goede wrote: > Today I had a refrehsing drink in the sun with a friend of mine and we > had a discussion about Fedora and about how despite Fedora being GREAT > Ubuntu seems to be way more popular. There's a segment of the market that blindly follows whatever the latest trendy distribution is. Like sheep. Intermediate users who's sole hobby seems to be re-installing Linux. Over the years they've gone from Debian to Mandrake to Gentoo to Ubuntu... I don't remember if they ever jumped on Red Hat. It's been cool to hate Red Hat for a while now. (See: The gcc 2.96 non-debacle, etc) I suspect they're more of a noisy minority, people with nothing better to do than rave about how great the trendy distribution of the year is and flood support lists with questions about it, rather than an actual majority. And if you're friends with one of these, you get flooded with the questions, which I can only answer with "I don't know what your crazy ass distribution is doing" until I finally decide to install it on a spare machine, discover it blows chunks, and then the answer is "X blows chunks, install Fedora if you want me to help you", which is advice they gleefully ignore... Oh well, Gentoo/Ubuntu can have them. (Death to Mandrake*) (*) Seems mostly dead** now. (**) Which means its slightly alive. -------------- 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 paul at city-fan.org Mon Jul 10 07:36:59 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 10 Jul 2006 08:36:59 +0100 Subject: repodata shot? In-Reply-To: <44B14951.8040103@hhs.nl> References: <1152397491.3734.178.camel@T7.Linux> <1152450305.10312.26.camel@laurel.intra.city-fan.org> <44B14951.8040103@hhs.nl> Message-ID: <1152517020.10312.48.camel@laurel.intra.city-fan.org> On Sun, 2006-07-09 at 20:22 +0200, Hans de Goede wrote: > > Paul Howarth wrote: > > On Sat, 2006-07-08 at 18:38 -0700, Ian Burrell wrote: > >> On 7/8/06, Paul wrote: > >> You are using the rawhide repositories, not FC5. My impression is > >> that GNOME 1 and Gtk 1 packages were removed from development. Some > >> have been added to Extras but gnome-libs is not one of them. > > > > I'm working on that. Hope to submit it (and its deps ORBit and libpng10) > > for review sometime next week. > > > > Ouch, legacy people, legacy how many apps need these? Not that many, but the number is more than one. > How hard would it be to port them to something newer, My interest in this is that libglade is needed to build php-gtk, which in turn is needed by pptpconfig, a GUI tool for configuring PPTP-based VPNs. Work on porting php-gtk to GTK2 and PHP5 has been going on for well over a year now but it's still only at a pre-alpha stage. Work on migrating pptpconfig to pygtk2 has also started but is stalled on a lack of manpower (and I can't help because I don't know python). So for the FC6 timeframe, the old stack will be needed. Now I could just dump all of the needed packages into the upstream pptpclient repo, but I'd rather have them in Extras because: 1. They'll get reviewed first, and 2. They'll be available on more architectures than I can build for, and 3. I'm not the only one supporting legacy apps. > what will be more work in the near future? There's a few days' work now in getting the packages ready for Extras and through the review process. After that, since these are all legacy libraries with no real changes going on upstream (though libpng10 has had a security update this year), ongoing maintenance should not be a big issue. Paul. From paul at city-fan.org Mon Jul 10 07:44:01 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 10 Jul 2006 08:44:01 +0100 Subject: rpms/monodoc/devel monodoc.spec,1.7,1.8 In-Reply-To: <200607091305.k69D50M4005686@cvs-int.fedora.redhat.com> References: <200607091305.k69D50M4005686@cvs-int.fedora.redhat.com> Message-ID: <1152517441.10312.52.camel@laurel.intra.city-fan.org> On Sun, 2006-07-09 at 06:04 -0700, Paul F. Johnson wrote: > @@ -40,8 +40,8 @@ > %files > %defattr(-, root, root) > %doc COPYING AUTHORS ChangeLog NEWS README > -%{_libdir}/mono/gac/monodoc/ > -%{_libdir}/mono/monodoc/ > +/usr/lib/mono/gac/monodoc/ > +/usr/lib/mono/monodoc/ > %{_libdir}/%{name}/ > %{_bindir}/mdassembler > %{_bindir}/mdcs2ecma > @@ -58,6 +58,9 @@ > %{__rm} -rf %{buildroot} > > %changelog > +* Sun Jul 09 2006 Paul F. Johnson 1.1.13-17 > +- need to specify usr-lib for the mono and gac dir > + My reading of the mono packaging guidelines is that things should be in %{_libdir} rather than /usr/lib, and that the packager's effort should go into getting the application/library to put things there and use them from there. I realise this is non-trivial given the way that most upstream mono apps/libraries are written, but hardcoding /usr/lib has to be seen as a regression, doesn't it? Paul. From seg at haxxed.com Mon Jul 10 07:54:39 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 10 Jul 2006 02:54:39 -0500 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B107CB.9070104@leemhuis.info> References: <44B107CB.9070104@leemhuis.info> Message-ID: <1152518079.3170.37.camel@localhost> On Sun, 2006-07-09 at 15:42 +0200, Thorsten Leemhuis wrote: > * Co-Maintainership > > * This is IMO one of the biggest areas we should work on soon > > * each package should IMHO have at least two maintainers (one of them > should be the "primary maintainer", who has the last word if there are > disagreements how to do things) This seems like a good purpose for SIGs. The SIG can act as a collective maintainer/co-maintainer for packages in their areas of interest. -------------- 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 paul at all-the-johnsons.co.uk Mon Jul 10 08:06:32 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Mon, 10 Jul 2006 09:06:32 +0100 Subject: rpms/monodoc/devel monodoc.spec,1.7,1.8 In-Reply-To: <1152517441.10312.52.camel@laurel.intra.city-fan.org> References: <200607091305.k69D50M4005686@cvs-int.fedora.redhat.com> <1152517441.10312.52.camel@laurel.intra.city-fan.org> Message-ID: <1152518792.16965.7.camel@mrwibble.mrwobble> Hi, > My reading of the mono packaging guidelines is that things should be in > %{_libdir} rather than /usr/lib, and that the packager's effort should > go into getting the application/library to put things there and use them > from there. I realise this is non-trivial given the way that most > upstream mono apps/libraries are written, but hardcoding /usr/lib has to > be seen as a regression, doesn't it? The mono directory and gac directories are ALWAYS in /usr/lib irrespective of architecture or platform. These are the only exceptions to the rules. From memory, this was decided on many moons ago by Ximian (that's how old it is!) to be analogous of the Windows/System directory. I'm open to suggestions on this, but to maintain reliability and compliance with the mono infrastructure, it has to remain in /usr/lib TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From andreas.bierfert at lowlatency.de Mon Jul 10 08:14:21 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Mon, 10 Jul 2006 10:14:21 +0200 Subject: Buildsystem SSL Cert broken? Message-ID: <20060710101421.7a53b337@alkaid.a.lan> http://buildsys.fedoraproject.org/build-status/: Error was: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')] /usr/bin/plague-client build dosbox dosbox-0_65-2_fc4 fc4 Traceback (most recent call last): File "/usr/bin/plague-client", line 420, in ? cli = PlagueClient(os.path.expanduser(cfg_file)) File "/usr/bin/plague-client", line 85, in __init__ self._check_api_version(self._server) File "/usr/bin/plague-client", line 90, in _check_api_version server_ver = server.api_version() File "/usr/lib64/python2.4/xmlrpclib.py", line 1096, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.4/xmlrpclib.py", line 1383, in __request verbose=self.__verbose File "/usr/lib64/python2.4/xmlrpclib.py", line 1129, in request self.send_content(h, request_body) File "/usr/lib64/python2.4/xmlrpclib.py", line 1243, in send_content connection.endheaders() File "/usr/lib64/python2.4/httplib.py", line 798, in endheaders self._send_output() File "/usr/lib64/python2.4/httplib.py", line 679, in _send_output self.send(msg) File "/usr/lib64/python2.4/httplib.py", line 658, in send self.sock.sendall(str) File "/usr/lib/python2.4/site-packages/plague/SSLConnection.py", line 110, in sendall sent = con.send(data, flags) OpenSSL.SSL.Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')] make: *** [build] Error 1 - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Mon Jul 10 09:50:35 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Mon, 10 Jul 2006 10:50:35 +0100 Subject: gal and oaf for FE Message-ID: <1152525036.16965.28.camel@mrwibble.mrwobble> Hi, If gal and oaf have been officially orphaned (I can't remember seeing anything on the wiki about it), I'm happy to take them over (mainly as I need them for gnome-build). Could someone let me know if they are now dropped so I can get beavering on them tonight? TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From dwmw2 at infradead.org Mon Jul 10 10:18:36 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 10 Jul 2006 11:18:36 +0100 Subject: obsolete dependencies on libsysfs.so.1 In-Reply-To: <20060709230044.GB18609@lists.us.dell.com> References: <20060709204202.GA18609@lists.us.dell.com> <1152483512.3018.16.camel@pmac.infradead.org> <20060709230044.GB18609@lists.us.dell.com> Message-ID: <1152526716.3373.16.camel@pmac.infradead.org> On Sun, 2006-07-09 at 18:00 -0500, Matt Domsch wrote: > indeed, and bridge-utils. Nah, I updated and rebuilt bridge-utils yesterday. Actually, I think I _asked_ for sysfsutils to be updated a few weeks ago so that I could update bridge-utils, because by chance I happened to noticed that the autocrap stuff in new bridge-utils silently builds tools for a 2.4 kernel if you don't have sysfsutils-2.0.0. But I thought the answer was "not this late in the cycle", so I was vaguely surprised to see it change without getting any further email on the subject other than the dependency nag. > What's the Core equivalent of Extras' owners/owners.list? Each of the > tools that's generating Core+Extras stats could make use of such to > identify package owneres too. Er, not sure. I think bugzilla and/or brew has a list but I'm not sure how to access it. -- dwmw2 From bugs.michael at gmx.net Mon Jul 10 10:51:55 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 10 Jul 2006 12:51:55 +0200 Subject: Provides for Obsoletes In-Reply-To: <200607092021.11259.jkeating@redhat.com> References: <44B19BD9.4080407@kobold.org> <200607092021.11259.jkeating@redhat.com> Message-ID: <20060710125155.62846ba4.bugs.michael@gmx.net> On Sun, 9 Jul 2006 20:21:11 -0400, Jesse Keating wrote: > On Sunday 09 July 2006 20:14, Wart wrote: > > Is there any reason why I need to add the Provides: for the obsoleted > > -devel subpackage? > > For an upgrade path. People that currently have -devel package installed will > need to have it go away when they update to your new package. If your new > package Obsoletes the -devel package, the update will break if the new > package doesn't also provide crossfire-maps-devel. Not true, because the new package obsoletes the sub-package, regardless of whether it is a virtual package or not. It replaces it, and hence RPM removes it during the transaction. The "upgrade path" issues are separate ones: An "Obsoletes" does not add an automatic "Provides". Effectively, you remove a package name from the global namespace. Users, who are used to a specific package name, e.g. "yum install something" will need to search where the contents of package "something" have been moved. In case the contents of the obsolete [sub-]package are gone and cannot be found in the new packages, it would be _wrong_ to add "Provides". Example: someeditor-1.0-1 (/usr/bin/someeditor and common data files) someeditor-gui-1.0-1 (/usr/bin/someeditor-gui and requires main pkg) An upgrade removes the unfinished/hacked gui version, because no upstream developer continues working on it: someeditor-2.0-1 (Obsoletes: someeditor-gui < 2.0-1) It here would be wrong to make the package "Provides: someeditor-gui = %version-%release), since it is _not_ included. And as a second issue with upgrade paths, Yum, unless patched according to bug #190116, continues seeing old non-virtual and [meanwhile broken] sub-packages, even if there are "Obsoletes" in the new packages. From paul at city-fan.org Mon Jul 10 10:57:12 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 10 Jul 2006 11:57:12 +0100 Subject: gal and oaf for FE In-Reply-To: <1152525036.16965.28.camel@mrwibble.mrwobble> References: <1152525036.16965.28.camel@mrwibble.mrwobble> Message-ID: <44B23288.3030405@city-fan.org> PFJ wrote: > If gal and oaf have been officially orphaned (I can't remember seeing > anything on the wiki about it), I'm happy to take them over (mainly as I > need them for gnome-build). > > Could someone let me know if they are now dropped so I can get beavering > on them tonight? http://www.redhat.com/archives/fedora-devel-list/2006-April/msg00324.html Paul. From bugs.michael at gmx.net Mon Jul 10 10:59:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 10 Jul 2006 12:59:24 +0200 Subject: gal and oaf for FE In-Reply-To: <1152525036.16965.28.camel@mrwibble.mrwobble> References: <1152525036.16965.28.camel@mrwibble.mrwobble> Message-ID: <20060710125924.55b817b0.bugs.michael@gmx.net> On Mon, 10 Jul 2006 10:50:35 +0100, PFJ wrote: > Hi, > > If gal and oaf have been officially orphaned (I can't remember seeing > anything on the wiki about it), I'm happy to take them over (mainly as I > need them for gnome-build). > > Could someone let me know if they are now dropped so I can get beavering > on them tonight? Both have been Core packages. Somebody, who either decided to drop them or who knows for sure that they have been dropped finally, could announce this in a _clear_ way on maintainers-list or even inform FESCo about that. From paul at all-the-johnsons.co.uk Mon Jul 10 11:00:07 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Mon, 10 Jul 2006 12:00:07 +0100 Subject: gal and oaf for FE In-Reply-To: <44B23288.3030405@city-fan.org> References: <1152525036.16965.28.camel@mrwibble.mrwobble> <44B23288.3030405@city-fan.org> Message-ID: <1152529207.16965.43.camel@mrwibble.mrwobble> Hi, > http://www.redhat.com/archives/fedora-devel-list/2006-April/msg00324.html If that's the case, I hereby claim gal and oaf for Queen, country and the lesser spotted despot known as J. Peasmold Gruntphuttock. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From paul at city-fan.org Mon Jul 10 11:46:35 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 10 Jul 2006 12:46:35 +0100 Subject: rpms/monodoc/devel monodoc.spec,1.7,1.8 In-Reply-To: <1152518792.16965.7.camel@mrwibble.mrwobble> References: <200607091305.k69D50M4005686@cvs-int.fedora.redhat.com> <1152517441.10312.52.camel@laurel.intra.city-fan.org> <1152518792.16965.7.camel@mrwibble.mrwobble> Message-ID: <44B23E1B.1070801@city-fan.org> PFJ wrote: > Hi, > >> My reading of the mono packaging guidelines is that things should be in >> %{_libdir} rather than /usr/lib, and that the packager's effort should >> go into getting the application/library to put things there and use them >> from there. I realise this is non-trivial given the way that most >> upstream mono apps/libraries are written, but hardcoding /usr/lib has to >> be seen as a regression, doesn't it? > > The mono directory and gac directories are ALWAYS in /usr/lib > irrespective of architecture or platform. These are the only exceptions > to the rules. From memory, this was decided on many moons ago by Ximian > (that's how old it is!) to be analogous of the Windows/System directory. > > I'm open to suggestions on this, but to maintain reliability and > compliance with the mono infrastructure, it has to remain in /usr/lib My apologies. I was confusing things. Looking at http://fedoraproject.org/wiki/Packaging/Mono there are still references to %{_prefix}/lib/mono in the "gacutil" section. It should still be %{_prefix}/lib rather than /usr/lib though... Paul. From paul at city-fan.org Mon Jul 10 11:48:41 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 10 Jul 2006 12:48:41 +0100 Subject: rpms/nant/devel nant-libdir.patch, NONE, 1.1 nant.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200607092200.k69M06rI016243@cvs-int.fedora.redhat.com> References: <200607092200.k69M06rI016243@cvs-int.fedora.redhat.com> Message-ID: <44B23E99.3050902@city-fan.org> Paul F. Johnson (pfj) wrote: > %install > rm -rf %{buildroot} > %makeinstall > sed -i -e "s#%buildroot##" %buildroot%_bindir/%name Does "make DESTDIR=%{buildroot} install" not work for this application? Having to fix up buildroot artefacts using sed like this is one of the reasons that the DESTDIR approach is preferred to %makeinstall. Paul. From Christian.Iseli at licr.org Mon Jul 10 12:17:09 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 10 Jul 2006 14:17:09 +0200 Subject: FE-NEW assigned and unassigned (Was Eiciel ) In-Reply-To: Your message of "Sat, 08 Jul 2006 19:26:45 +0200." <44AFEAD5.5070505@leemhuis.info> Message-ID: <200607101217.k6ACH93r006812@ludwig-alpha.unil.ch> fedora at leemhuis.info said: > We can change the state to "NEW" without asking the bugzilla admin IIRC > (correct me if I'm wrong). s/can/can't/ right ? Apart from that, I agree the blocker bug is the important info. Christian From giallu at gmail.com Mon Jul 10 14:02:36 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 10 Jul 2006 16:02:36 +0200 Subject: VTK anyone? Message-ID: I am interested in packaging vtk (http://www.vtk.org), a 3d visualization toolkit, for an eventual inclusion in extras. Of course, if anyone is already working at that, I would happily save a lot time (it's not the most trivial pckage one can work on...) Cheers Gianluca From fedora at leemhuis.info Mon Jul 10 14:32:04 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 10 Jul 2006 16:32:04 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B19294.1020106@fedoraproject.org> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> Message-ID: <44B264E4.30803@leemhuis.info> Rahul schrieb: > Thorsten Leemhuis wrote: >> * Why isn't the Fedora Directory Server still not in Extras? > I had already brought this up recently in a board discussion. Will start > a new one in the the Fedora advisory board list. tia >> * Discussions within FESCo and with the community are working often in >> acceptable ways on the lists and on IRC most of the time, but often >> nothing happens after the discussion is over and things remain unclear >> and undecided. > Assign a owner to keep track of every agenda item. Yes and No. Yes: All things on the Extras/Schedule need to have a owner. This is one thing that I hope works better with the new FESCo -- Jobs simply didn't get assigned to anyone often because there were not enough people interested in driving things forward. No: Not all discussions should be added to the schedule cause we might soon end up with to much stuff on the schedule that without getting the most important things done. >> * we need a defined and documented policy to get definite answers for >> open legal question > Kindly contact the Fedora advisory board where our counsel is a member. > Call this policy. > http://fedoraproject.org/wiki/Board We need to discuss things first. Warren seems to be the one to contact when there are issues. But that's nowhere documented (and might be wrong) >> * Long-Term Fedora Extras contributors should get a small reward now >> and then: A Pen, Sticker, T-Shirt, LWN subscription, ... > Another item for FAB. I will start a discussion. tia! >> * close the gap between Core and Extras as far as possible > Would be quite useful to document every single difference between core > and extras somewhere so that we can tackle this as we move along. Can > someone do this? Hmmm. Yeah, it might make sense. But we, the Extras community, don't have much influence or knowledge about the details or plans to close the gap (or merge the two). So it seems someone from redhat should be the default owner for this task (with help from Extras contributors of course). CU thl From sundaram at fedoraproject.org Mon Jul 10 14:41:23 2006 From: sundaram at fedoraproject.org (Rahul) Date: Mon, 10 Jul 2006 20:11:23 +0530 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B264E4.30803@leemhuis.info> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> Message-ID: <44B26713.10200@fedoraproject.org> Thorsten Leemhuis wrote: > Rahul schrieb: >> Thorsten Leemhuis wrote: >>> * Why isn't the Fedora Directory Server still not in Extras? >> I had already brought this up recently in a board discussion. Will >> start a new one in the the Fedora advisory board list. > > tia > >>> * Discussions within FESCo and with the community are working often in >>> acceptable ways on the lists and on IRC most of the time, but often >>> nothing happens after the discussion is over and things remain unclear >>> and undecided. >> Assign a owner to keep track of every agenda item. > > Yes and No. > > Yes: All things on the Extras/Schedule need to have a owner. This is one > thing that I hope works better with the new FESCo -- Jobs simply didn't > get assigned to anyone often because there were not enough people > interested in driving things forward. Then leave it open and marked unassigned. > > No: Not all discussions should be added to the schedule cause we might > soon end up with to much stuff on the schedule that without getting the > most important things done. Which is why schedules have a priority. > >>> * we need a defined and documented policy to get definite answers for >>> open legal question >> Kindly contact the Fedora advisory board where our counsel is a >> member. Call this policy. >> http://fedoraproject.org/wiki/Board > > We need to discuss things first. Warren seems to be the one to contact > when there are issues. But that's nowhere documented (and might be wrong) Its already documented who the legal contact is clearly http://fedora.redhat.com/About/contact.html If you think that isnt working, the advisory board list is a open path. What exactly is the concern here? > >>> * Long-Term Fedora Extras contributors should get a small reward now >>> and then: A Pen, Sticker, T-Shirt, LWN subscription, ... >> Another item for FAB. I will start a discussion. > > tia! > >>> * close the gap between Core and Extras as far as possible >> Would be quite useful to document every single difference between core >> and extras somewhere so that we can tackle this as we move along. Can >> someone do this? > > Hmmm. Yeah, it might make sense. But we, the Extras community, don't > have much influence or knowledge about the details or plans to close the > gap (or merge the two). You dont require any knowledge about the future plans to merely document the differences. Still I dont mind owning this but then I need to bug someone with more extras repository knowledge than me to help me out. Rahul From rdieter at math.unl.edu Mon Jul 10 14:40:40 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 10 Jul 2006 09:40:40 -0500 Subject: Buildsystem SSL Cert broken? In-Reply-To: <20060710101421.7a53b337@alkaid.a.lan> References: <20060710101421.7a53b337@alkaid.a.lan> Message-ID: Andreas Bierfert wrote: > http://buildsys.fedoraproject.org/build-status/: > Error was: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate > verify failed')] > > /usr/bin/plague-client build dosbox dosbox-0_65-2_fc4 fc4 > Traceback (most recent call last): ... > OpenSSL.SSL.Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', > 'certificate verify failed')] make: *** [build] Error 1 Ditto. Filed support ticket: Zoom Ticket#: 2006071010000019 at http://admin.fedoraproject.org/tickets/ -- Rex From pertusus at free.fr Mon Jul 10 14:44:36 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 10 Jul 2006 16:44:36 +0200 Subject: VTK anyone? In-Reply-To: References: Message-ID: <20060710144436.GB5455@free.fr> On Mon, Jul 10, 2006 at 04:02:36PM +0200, Gianluca Sforna wrote: > I am interested in packaging vtk (http://www.vtk.org), a 3d > visualization toolkit, for an eventual inclusion in extras. > > Of course, if anyone is already working at that, I would happily save > a lot time (it's not the most trivial pckage one can work on...) I haven't tried to package it, but I will review you (and help if I can). Maybe you could have a look at paraview, allready included in fedora extras (and maintained by Orion) since it has an included version of vtk (last time it seemed to be a more recent version than the current vtk, that's why I didn't block paraview although it included vtk as a private library). -- Pat From skvidal at linux.duke.edu Mon Jul 10 14:53:36 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 10 Jul 2006 10:53:36 -0400 Subject: Buildsystem SSL Cert broken? In-Reply-To: References: <20060710101421.7a53b337@alkaid.a.lan> Message-ID: <1152543216.13562.7.camel@cutter> On Mon, 2006-07-10 at 09:40 -0500, Rex Dieter wrote: > Andreas Bierfert wrote: > > http://buildsys.fedoraproject.org/build-status/: > > Error was: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate > > verify failed')] > > > > /usr/bin/plague-client build dosbox dosbox-0_65-2_fc4 fc4 > > Traceback (most recent call last): > ... > > OpenSSL.SSL.Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', > > 'certificate verify failed')] make: *** [build] Error 1 > > Ditto. > > Filed support ticket: > Zoom Ticket#: 2006071010000019 > at http://admin.fedoraproject.org/tickets/ certs expired - need to figure out what to remake. -sv From giallu at gmail.com Mon Jul 10 14:56:32 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 10 Jul 2006 16:56:32 +0200 Subject: VTK anyone? In-Reply-To: <20060710144436.GB5455@free.fr> References: <20060710144436.GB5455@free.fr> Message-ID: On 7/10/06, Patrice Dumas wrote: > I haven't tried to package it, but I will review you (and help if I can). Thanks a lot. Really appreciated > > Maybe you could have a look at paraview, allready included in fedora extras > (and maintained by Orion) since it has an included version of vtk (last > time it seemed to be a more recent version than the current vtk, that's why > I didn't block paraview although it included vtk as a private library). Yap, I found that while looking for references to vtk in bugzilla. The version I am working on is 5.0.0, I don't know if it's the same as paraview use, but there will be something to learn for sure... From sander at hoentjen.eu Mon Jul 10 15:15:22 2006 From: sander at hoentjen.eu (Sander Hoentjen) Date: Mon, 10 Jul 2006 17:15:22 +0200 Subject: aMSN plugins Message-ID: <1152544522.12986.24.camel@peecee.hoentjen.eu> Hi, I am currently the packager of aMSN (and I intend to stay that). aMSN is an msn clone in a sense that it tries to mimic the looks and functionality of the official client, and more. For the more bit aMSN is extensible with various plugins. The upstream release tarball always has a few plugins included, so i made amsn and amsn-plugins from that source. There is also module in cvs with extra skins and plugins, and there exist various plugins and skins contributed by users. Should i create 2 extra packages, one for skins, and one for plugins, or a package for each skin/plugin? Also if one package for all plugins should be created how should i call it, something like amsn-plugins-extra or should i remove the amsn-plugins from the amsn.spec and include those plugins in amsn-plugins.spec Any hints would be appreciated Sander From dragoran at feuerpokemon.de Mon Jul 10 15:31:44 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 10 Jul 2006 17:31:44 +0200 Subject: aMSN plugins In-Reply-To: <1152544522.12986.24.camel@peecee.hoentjen.eu> References: <1152544522.12986.24.camel@peecee.hoentjen.eu> Message-ID: <44B272E0.5070402@feuerpokemon.de> Sander Hoentjen wrote: > Hi, > > I am currently the packager of aMSN (and I intend to stay that). aMSN is > an msn clone in a sense that it tries to mimic the looks and > functionality of the official client, and more. For the more bit aMSN is > extensible with various plugins. The upstream release tarball always has > a few plugins included, so i made amsn and amsn-plugins from that > source. There is also module in cvs with extra skins and plugins, and > there exist various plugins and skins contributed by users. Should i > create 2 extra packages, one for skins, and one for plugins, or a > package for each skin/plugin? > Also if one package for all plugins should be created how should i call > it, something like amsn-plugins-extra or should i remove the > amsn-plugins from the amsn.spec and include those plugins in > amsn-plugins.spec > something like amsn-plugins-extras is better (they wont need that much disk space so splitting it wont make sense) > Any hints would be appreciated > > Sander > > > From orion at cora.nwra.com Mon Jul 10 15:32:49 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 10 Jul 2006 09:32:49 -0600 Subject: VTK anyone? In-Reply-To: References: <20060710144436.GB5455@free.fr> Message-ID: <44B27321.4060809@cora.nwra.com> Gianluca Sforna wrote: > On 7/10/06, Patrice Dumas wrote: >> >> Maybe you could have a look at paraview, allready included in fedora >> extras >> (and maintained by Orion) since it has an included version of vtk (last >> time it seemed to be a more recent version than the current vtk, >> that's why >> I didn't block paraview although it included vtk as a private library). > Yap, I found that while looking for references to vtk in bugzilla. > The version I am working on is 5.0.0, I don't know if it's the same as > paraview use, but there will be something to learn for sure... > I've been slowly working on a version. Latest spec and srpm are at http://www.cora.nwra.com/~orion/fedora/. I believe the problem I'm having currently is getting some of the examples to compile. I'd be happy to let someone else maintain it though :-). -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From garrick at usc.edu Mon Jul 10 15:41:17 2006 From: garrick at usc.edu (Garrick Staples) Date: Mon, 10 Jul 2006 08:41:17 -0700 Subject: aMSN plugins In-Reply-To: <1152544522.12986.24.camel@peecee.hoentjen.eu> References: <1152544522.12986.24.camel@peecee.hoentjen.eu> Message-ID: <20060710154117.GB6257@polop.usc.edu> On Mon, Jul 10, 2006 at 05:15:22PM +0200, Sander Hoentjen alleged: > Hi, > > I am currently the packager of aMSN (and I intend to stay that). aMSN is > an msn clone in a sense that it tries to mimic the looks and > functionality of the official client, and more. For the more bit aMSN is > extensible with various plugins. The upstream release tarball always has > a few plugins included, so i made amsn and amsn-plugins from that > source. There is also module in cvs with extra skins and plugins, and > there exist various plugins and skins contributed by users. Should i > create 2 extra packages, one for skins, and one for plugins, or a > package for each skin/plugin? I say, follow the dependencies. If skins and various plugins have different external deps, then seperate them. You want to avoid the situation where there are lots of unwanted deps to get at 1 plugin. If a source package creates 10 plugins, 9 have no external deps, and the 10th requires some libfoo, than the 9 should be in 1 package, and the 10th in a seperate package. Don't needless seperate each skin and plugin into different packages; that it just annoying for the user. > Also if one package for all plugins should be created how should i call > it, something like amsn-plugins-extra or should i remove the > amsn-plugins from the amsn.spec and include those plugins in > amsn-plugins.spec Depends on the development. Can plugins be built without a main -devel package? Are main and extras developed and released at different rates? Do the upstream docs make a clear seperation between main and extras? Do upstream packages establish a precedent? -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Mon Jul 10 16:00:01 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 10 Jul 2006 18:00:01 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B26713.10200@fedoraproject.org> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> <44B26713.10200@fedoraproject.org> Message-ID: <20060710180001.09c7a5b7.bugs.michael@gmx.net> On Mon, 10 Jul 2006 20:11:23 +0530, Rahul wrote: > >>> * close the gap between Core and Extras as far as possible > >> Would be quite useful to document every single difference between core > >> and extras somewhere so that we can tackle this as we move along. Can > >> someone do this? > > > > Hmmm. Yeah, it might make sense. But we, the Extras community, don't > > have much influence or knowledge about the details or plans to close the > > gap (or merge the two). > > You dont require any knowledge about the future plans to merely document > the differences. Still I dont mind owning this but then I need to bug > someone with more extras repository knowledge than me to help me out. Can you shed some light on "plague vs. brew" and why Core and Extras buildsys and infrastructure divert in this area? Also, I've read that Red Hat can set a package owner _per dist release_ instead of _one owner per package_ (which is what our "owners.list" can do only). From pertusus at free.fr Mon Jul 10 16:07:19 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 10 Jul 2006 18:07:19 +0200 Subject: unversioned upstream source Message-ID: <20060710160719.GC5455@free.fr> Hello, I am seeking advice, or even better guidelines on the issue of unversionned upstream source. (I have allready mistakenly posted that mail to fedora-devel-list and I had 2 helpfull responses, but I repost it here since it is more appropriate for packaging (although other lists could also have been right...), sorry for the double post.) There is a dispute which may be seen here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197488 The upstream tarball is unversioned, I would like to add the timestamp to the tarball name to avoid having different tarballs with the same name, in case upstream wants to do a newer release without modifying the tarball name. This leads to: %define stamp 19981218 Source0: uread-%{stamp}.tar.gz # unversioned upstream source, downloaded with wget -N # renamed to uread-YYYYMMDD.tar.gz #Source0: http://www.engineers.auckland.ac.nz/~snor007/src/uread.tar.gz What do you think about that issue? What do you think is best practice and why? -- Pat From bugs.michael at gmx.net Mon Jul 10 16:12:02 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 10 Jul 2006 18:12:02 +0200 Subject: What do Extras contributors use the wiki for? In-Reply-To: <200607091503.16790.nman64@n-man.com> References: <200607091503.16790.nman64@n-man.com> Message-ID: <20060710181202.ed98093b.bugs.michael@gmx.net> On Sun, 9 Jul 2006 15:03:12 -0500, Patrick W. Barnes wrote: > In order to reduce the complexity in getting started with Extras, we have made > a few adjustments in the past to avoid making EditGroup membership a > requirement for Extras contributors. At present, some pages, like > CVSSyncNeeded, have special ACLs that avoid the normal EditGroup requirement. > > I'd like to know where Extras contributors might currently need EditGroup > membership in order to perform required tasks. Until we have a single > sign-on ability (which is an Infrastructure to-do item), I'd like to enable > Extras contributors to do their jobs without requiring EditGroup membership. > While EditGroup membership is a small step for members of cvsextras, it is > one step that we can avoid, and every little bit helps in the overcomplicated > process that new contributors must currently complete. > > Candidates for adjustment include pages that any Extras contributor needs to > edit but do not provide content to end-users. Eligible pages might include > tracking pages, schedules or task lists. Ineligible pages would include SIG > pages, documentation pages or policy pages. Some examples that I have > already seen for eligible pages are the FCx Status pages, User Registry, > Orphaned Packages List and Wish List. Does anyone have other pages to > suggest or any reasons why these examples shouldn't be opened up? Why should the FCx Status pages, the User Registry, the Orphaned Packages List be opened up to non-Contributors? Especially the FCx Status pages must not be writable by anyone who does not have a valid FE Account, since the requests added to those pages may result in changes to the repository. The Wiki is our "poor man's ticket-system" in this case. If more became known about the OTRS that has been set up in Fedora infrastructure, maybe we could switch to using that one for some of the FE related requests, too? From Christian.Iseli at licr.org Mon Jul 10 16:27:07 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 10 Jul 2006 18:27:07 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: Your message of "Sun, 09 Jul 2006 15:42:35 +0200." <44B107CB.9070104@leemhuis.info> Message-ID: <200607101627.k6AGR7vZ009034@ludwig-alpha.unil.ch> fedora at leemhuis.info said: > * can we stick to the "rolling release" scheme when anaconda will start > supporting external repos during install (the rolling release scheme might > break installs (not sure, but I think that is possible))? And/or do we need > Releases of Fedora Extras? E.g. ISOs of FE6 and a stable repo on the servers > and all new version go to a "updates" directory (similar to core)? I think having distributable ISOs including Extras is a desireable goal. So I'd like to see Extras devel rebuilt or frozen alongside FC releases. The "rebuild by default except when specifically asked not to" policy seems the best suited in this case. I'd like rpmlint run each time a package is built and the output diffed to a reference rpmlint output for that package. Differences would fail the build. I'd like a similar test procedure to the Provides of the package (i.e., diff all the things currently provided by the package vs. the things it provided in the previous published version, and build fails if there are differences). I'd like a similar test procedure for all the warnings (especially compiler warnings) produced during package building. Cheers, Christian From fedora at leemhuis.info Mon Jul 10 16:59:01 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 10 Jul 2006 18:59:01 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B26713.10200@fedoraproject.org> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> <44B26713.10200@fedoraproject.org> Message-ID: <44B28755.9040002@leemhuis.info> Rahul schrieb: > Thorsten Leemhuis wrote: >> Rahul schrieb: >>> Thorsten Leemhuis wrote: >>>> * we need a defined and documented policy to get definite answers for >>>> open legal question >>> Kindly contact the Fedora advisory board where our counsel is a >>> member. Call this policy. >>> http://fedoraproject.org/wiki/Board >> We need to discuss things first. Warren seems to be the one to contact >> when there are issues. But that's nowhere documented (and might be wrong) > > Its already documented who the legal contact is clearly > http://fedora.redhat.com/About/contact.html > If you think that isnt working, the advisory board list is a open path. > What exactly is the concern here? We are far away from the point where FAB need to be bought into the discussion. We simply need a documented way that lays down thinks like "If you have a software and are not sure if it can be packaged for Extras ask foo at bar.com for advice. He will forward it to FESCo and/or Fedora Legal if it becomes necessary and help you getting the problem resolved." CU thl From sander at hoentjen.eu Mon Jul 10 16:59:31 2006 From: sander at hoentjen.eu (Sander Hoentjen) Date: Mon, 10 Jul 2006 18:59:31 +0200 Subject: aMSN plugins In-Reply-To: <20060710154117.GB6257@polop.usc.edu> References: <1152544522.12986.24.camel@peecee.hoentjen.eu> <20060710154117.GB6257@polop.usc.edu> Message-ID: <1152550772.12986.43.camel@peecee.hoentjen.eu> On Mon, 2006-07-10 at 08:41 -0700, Garrick Staples wrote: > On Mon, Jul 10, 2006 at 05:15:22PM +0200, Sander Hoentjen alleged: > > Hi, > > > > I am currently the packager of aMSN (and I intend to stay that). aMSN is > > an msn clone in a sense that it tries to mimic the looks and > > functionality of the official client, and more. For the more bit aMSN is > > extensible with various plugins. The upstream release tarball always has > > a few plugins included, so i made amsn and amsn-plugins from that > > source. There is also module in cvs with extra skins and plugins, and > > there exist various plugins and skins contributed by users. Should i > > create 2 extra packages, one for skins, and one for plugins, or a > > package for each skin/plugin? > > I say, follow the dependencies. If skins and various plugins have > different external deps, then seperate them. You want to avoid the > situation where there are lots of unwanted deps to get at 1 plugin. > > If a source package creates 10 plugins, 9 have no external deps, and the > 10th requires some libfoo, than the 9 should be in 1 package, and the > 10th in a seperate package. Ok, that makes sense > > Don't needless seperate each skin and plugin into different packages; > that it just annoying for the user. > > > > Also if one package for all plugins should be created how should i call > > it, something like amsn-plugins-extra or should i remove the > > amsn-plugins from the amsn.spec and include those plugins in > > amsn-plugins.spec > > Depends on the development. Can plugins be built without a main -devel > package? Are main and extras developed and released at different rates? > Do the upstream docs make a clear seperation between main and extras? > Do upstream packages establish a precedent? Ah I just thought of another thing, most plugins are noarch (like a SpellCheck plugin, just an xml and a tcl file, with dependency on aspell). Actually, all plugins I know are noarch, except for 1, and I won't package that one because it kind of sucks. Plugins *can* be arch specific though, so I should separate those out. Before I mentioned that SpellCheck has a dependency on aspell, and that is true in a sense that you can fill out a path to a binary that does the translating in an ispell compatible way. If you don't have the binary, the plugin just does nothing. Most plugins have dependencies that way, another good example is the music plugin, it sets your personal message according to whatever song you are listening to. It works with xmms, amarok, rhytmbox, banshee, mpd. For the music plugins it seems obvious I shouldn't require all 5 players, but what should be the require for the SpellCheck plugin? Sander From fedora at leemhuis.info Mon Jul 10 17:25:52 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 10 Jul 2006 19:25:52 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <1152467842.14154.14.camel@vader.jdub.homelinux.org> References: <44B107CB.9070104@leemhuis.info> <20060709170107.facc519b.bugs.michael@gmx.net> <44B12F77.4050606@leemhuis.info> <1152467842.14154.14.camel@vader.jdub.homelinux.org> Message-ID: <44B28DA0.4010704@leemhuis.info> Josh Boyer schrieb: > On Sun, 2006-07-09 at 18:31 +0200, Thorsten Leemhuis wrote: >> Michael Schwendt schrieb: >>> On Sun, 09 Jul 2006 15:42:35 +0200, Thorsten Leemhuis wrote: >[...] >>> Or if somebody >>> within FESCo learns about such a rebuild, that there will be an official >>> announcement about what FE packagers should/must do? >> I'm not sure I understand you correctly. It for sure will be announced >> when FESCo agrees on a mass-rebuild. > Maybe we should revisit how Extras rebuilds are done too. Personally, I > like the way they're handled in Core. A single person starts it and > maintainers email him if they _do not_ want their package rebuilt for > whatever reason. IMHO, that provides the advantage that the number of > cats to herd is fewer. Well, yes, that might be easier. But the manual rebuild has one (IMHO important) benefit: All maintainers have to show up. That's the only time when we force them to do something and we found lot of orphans and AWOL packagers with this procedure during the mass rebuild for FC5. I suspect we'll find some again during a manual mass rebuild for FC. >> Also non-sponsors might be interested in this feature as well. >> >>> [...] >>>> * fedora-devel-list, fedora-extras-list, fedora-maintainers -- these >>>> multiple lists get confusing, some things that are discussed on >>>> fedora-maintainers-list would be better suited for fedora-extras-list >>>> AFICS; >>> It's not the confusion that hurts, but the insane amount of cross-posting. >> Both AFAICS. >> I'd prefer if fedora-maintainers would be more like an moderated, >> non-discussion announce-list to inform all the maintainers about >> important things. Discussion on the other two lists. > > Actually, I disagree. Having a list for Extras and a list for Core just > segregates things more. Just to make sure: fedora-maintainers is for both Core and Extras maintainers iirc. > This is a case where I think we need cohesion. > We're already talking about doing releases differently to be more like > Core, and various other Core<->Extras merge type issues, so having a > single list for all package maintainers to discuss is a step towards > that goal. I agree with the goal, but a merge of fedora-devel, fedora-maintainers and fedora-extras can still wait a bit -- currently it's IMHO better for the extras specific discussions remain on a separate list. CU thl From sundaram at fedoraproject.org Mon Jul 10 17:30:52 2006 From: sundaram at fedoraproject.org (Rahul) Date: Mon, 10 Jul 2006 23:00:52 +0530 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <20060710180001.09c7a5b7.bugs.michael@gmx.net> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> <44B26713.10200@fedoraproject.org> <20060710180001.09c7a5b7.bugs.michael@gmx.net> Message-ID: <44B28ECC.7000201@fedoraproject.org> Michael Schwendt wrote: > On Mon, 10 Jul 2006 20:11:23 +0530, Rahul wrote: > >>>>> * close the gap between Core and Extras as far as possible >>>> Would be quite useful to document every single difference between core >>>> and extras somewhere so that we can tackle this as we move along. Can >>>> someone do this? >>> Hmmm. Yeah, it might make sense. But we, the Extras community, don't >>> have much influence or knowledge about the details or plans to close the >>> gap (or merge the two). >> You dont require any knowledge about the future plans to merely document >> the differences. Still I dont mind owning this but then I need to bug >> someone with more extras repository knowledge than me to help me out. > > Can you shed some light on "plague vs. brew" and why Core and Extras > buildsys and infrastructure divert in this area? I can answer this now since I brought the exact question before to the board. Answer: Brew is not just the build system but Fedora Core's package management (tracking packages) system to produce a distribution too. This is esp important for something that is not pushed out as just rolling updates. > > Also, I've read that Red Hat can set a package owner _per dist release_ > instead of _one owner per package_ (which is what our "owners.list" can do > only). > Jesse Keating (adding to CC) would be able to answer this one and possibly expand more on the response to your first question too. Rahul From Axel.Thimm at ATrpms.net Mon Jul 10 17:33:51 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 10 Jul 2006 19:33:51 +0200 Subject: VTK anyone? In-Reply-To: References: Message-ID: <20060710173351.GD23026@neu.nirvana> On Mon, Jul 10, 2006 at 04:02:36PM +0200, Gianluca Sforna wrote: > I am interested in packaging vtk (http://www.vtk.org), a 3d > visualization toolkit, for an eventual inclusion in extras. > > Of course, if anyone is already working at that, I would happily save > a lot time (it's not the most trivial pckage one can work on...) > > Cheers > > Gianluca > I've been given it a try at http://ATrpms.net/name/vtk/ I think all but java bits (which still require Sun's java) work. -- 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 cweyl at alumni.drew.edu Mon Jul 10 17:35:56 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 10 Jul 2006 10:35:56 -0700 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B28ECC.7000201@fedoraproject.org> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> <44B26713.10200@fedoraproject.org> <20060710180001.09c7a5b7.bugs.michael@gmx.net> <44B28ECC.7000201@fedoraproject.org> Message-ID: <7dd7ab490607101035m70d4a889gf8467d3ac01017b@mail.gmail.com> On 7/10/06, Rahul wrote: > Brew is not just the build system but Fedora Core's package management > (tracking packages) system to produce a distribution too. This is esp > important for something that is not pushed out as just rolling updates. Semi OT, but is brew available externally to redhat anywhere? -Chris -- Chris Weyl Ex astris, scientia From rdieter at math.unl.edu Mon Jul 10 17:37:13 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 10 Jul 2006 12:37:13 -0500 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <200607101627.k6AGR7vZ009034@ludwig-alpha.unil.ch> References: <44B107CB.9070104@leemhuis.info> <200607101627.k6AGR7vZ009034@ludwig-alpha.unil.ch> Message-ID: Christian.Iseli at licr.org wrote: > I'd like rpmlint run each time a package is built and the output diffed to a > reference rpmlint output for that package. Differences would fail the build. > > I'd like a similar test procedure to the Provides of the package (i.e., diff > all the things currently provided by the package vs. the things it provided in > the previous published version, and build fails if there are differences). If by "fail the build" you really mean "warn the packager", then we're in agreement. (: -- Rex From sundaram at fedoraproject.org Mon Jul 10 17:47:31 2006 From: sundaram at fedoraproject.org (Rahul) Date: Mon, 10 Jul 2006 23:17:31 +0530 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <7dd7ab490607101035m70d4a889gf8467d3ac01017b@mail.gmail.com> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> <44B26713.10200@fedoraproject.org> <20060710180001.09c7a5b7.bugs.michael@gmx.net> <44B28ECC.7000201@fedoraproject.org> <7dd7ab490607101035m70d4a889gf8467d3ac01017b@mail.gmail.com> Message-ID: <44B292B3.8080307@fedoraproject.org> Chris Weyl wrote: > On 7/10/06, Rahul wrote: >> Brew is not just the build system but Fedora Core's package management >> (tracking packages) system to produce a distribution too. This is esp >> important for something that is not pushed out as just rolling updates. > > Semi OT, but is brew available externally to redhat anywhere? > > -Chris > Nope. Rahul From garrick at usc.edu Mon Jul 10 18:00:21 2006 From: garrick at usc.edu (Garrick Staples) Date: Mon, 10 Jul 2006 11:00:21 -0700 Subject: aMSN plugins In-Reply-To: <1152550772.12986.43.camel@peecee.hoentjen.eu> References: <1152544522.12986.24.camel@peecee.hoentjen.eu> <20060710154117.GB6257@polop.usc.edu> <1152550772.12986.43.camel@peecee.hoentjen.eu> Message-ID: <20060710180021.GD6257@polop.usc.edu> On Mon, Jul 10, 2006 at 06:59:31PM +0200, Sander Hoentjen alleged: > On Mon, 2006-07-10 at 08:41 -0700, Garrick Staples wrote: > > On Mon, Jul 10, 2006 at 05:15:22PM +0200, Sander Hoentjen alleged: > > > Hi, > > > > > > I am currently the packager of aMSN (and I intend to stay that). aMSN is > > > an msn clone in a sense that it tries to mimic the looks and > > > functionality of the official client, and more. For the more bit aMSN is > > > extensible with various plugins. The upstream release tarball always has > > > a few plugins included, so i made amsn and amsn-plugins from that > > > source. There is also module in cvs with extra skins and plugins, and > > > there exist various plugins and skins contributed by users. Should i > > > create 2 extra packages, one for skins, and one for plugins, or a > > > package for each skin/plugin? > > > > I say, follow the dependencies. If skins and various plugins have > > different external deps, then seperate them. You want to avoid the > > situation where there are lots of unwanted deps to get at 1 plugin. > > > > If a source package creates 10 plugins, 9 have no external deps, and the > > 10th requires some libfoo, than the 9 should be in 1 package, and the > > 10th in a seperate package. > Ok, that makes sense > > > > Don't needless seperate each skin and plugin into different packages; > > that it just annoying for the user. > > > > > > > Also if one package for all plugins should be created how should i call > > > it, something like amsn-plugins-extra or should i remove the > > > amsn-plugins from the amsn.spec and include those plugins in > > > amsn-plugins.spec > > > > Depends on the development. Can plugins be built without a main -devel > > package? Are main and extras developed and released at different rates? > > Do the upstream docs make a clear seperation between main and extras? > > Do upstream packages establish a precedent? > > Ah I just thought of another thing, most plugins are noarch (like a > SpellCheck plugin, just an xml and a tcl file, with dependency on > aspell). Actually, all plugins I know are noarch, except for 1, and I > won't package that one because it kind of sucks. Plugins *can* be arch > specific though, so I should separate those out. Before I mentioned that > SpellCheck has a dependency on aspell, and that is true in a sense that > you can fill out a path to a binary that does the translating in an > ispell compatible way. If you don't have the binary, the plugin just > does nothing. Most plugins have dependencies that way, another good > example is the music plugin, it sets your personal message according to > whatever song you are listening to. It works with xmms, amarok, > rhytmbox, banshee, mpd. For the music plugins it seems obvious I > shouldn't require all 5 players, but what should be the require for the > SpellCheck plugin? You can go either way with SpellCheck. I'd say that if a missing ispell is very apparent to the user, then just keep it with the other plugins and don't worry about it. If, from the viewpoint of the user, the plugin would just appear broken, then seperate it and require aspell. -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jul 10 18:03:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 10 Jul 2006 14:03:58 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <20060710180001.09c7a5b7.bugs.michael@gmx.net> References: <44B107CB.9070104@leemhuis.info> <44B26713.10200@fedoraproject.org> <20060710180001.09c7a5b7.bugs.michael@gmx.net> Message-ID: <200607101403.58498.jkeating@redhat.com> On Monday 10 July 2006 12:00, Michael Schwendt wrote: > Can you shed some light on "plague vs. brew" and why Core and Extras > buildsys and infrastructure divert in this area? Brew is a management layer over Mock, like Plague is. Brew was written with a package database backend in mind, and development on it started before Plague work began, but we didn't get to the point of actually using it until very recently. It is interesting now that there is work being considered to add a package database to Plague. Brew handles some things Red Hat needs for RHEL, much more strict tracking of build root contents for package builds, finer grained collection inheritince, collection locking (does plague do this?), an xml-rpc API to the package database, etc... Not all of these things are needed for Fedora, but some are pretty nice. There is some discussion about opensourcing Brew, the layers above mock. > Also, I've read that Red Hat can set a package owner _per dist release_ > instead of _one owner per package_ (which is what our "owners.list" can do > only). We can _now_. We weren't able to with beehive, the system brew replaces. -- 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 duncan_j_ferguson at yahoo.co.uk Mon Jul 10 17:30:34 2006 From: duncan_j_ferguson at yahoo.co.uk (Duncan Ferguson) Date: Mon, 10 Jul 2006 18:30:34 +0100 Subject: Advice on desktop icons Message-ID: <1152552634.3123.2.camel@queeg> I am in the process of creating an RPM for a desktop application. I have found the section on desktop files in the packaging guidelines in the wiki, but it make no mention of icons. What is the best way to include icons within an rpm, and what sizes of icons should be used (i have seen mention of 16x16, 24x24 and 48x48, but how should they be named/installed within the rpm)? Thanks Duncs ___________________________________________________________ All New Yahoo! Mail ? Tired of Vi at gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html From wart at kobold.org Mon Jul 10 18:36:37 2006 From: wart at kobold.org (Michael Thomas) Date: Mon, 10 Jul 2006 11:36:37 -0700 Subject: Advice on desktop icons In-Reply-To: <1152552634.3123.2.camel@queeg> References: <1152552634.3123.2.camel@queeg> Message-ID: <44B29E35.80301@kobold.org> Duncan Ferguson wrote: > I am in the process of creating an RPM for a desktop application. I > have found the section on desktop files in the packaging guidelines in > the wiki, but it make no mention of icons. > > What is the best way to include icons within an rpm, and what sizes of > icons should be used (i have seen mention of 16x16, 24x24 and 48x48, but > how should they be named/installed within the rpm)? I usually use 32x32 or 48x48 icons, but it's really your choice. And I name them to match the package name, such as "freedoom.png". To install it, you can use the following fragments: Source1: freedoom.png ... %install mkdir -p $RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/48x48/apps/ install -p -m 644 %{SOURCE1} \ $RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/48x48/apps/ %post touch --no-create %{_datadir}/icons/hicolor || : if [ -x %{_bindir}/gtk-update-icon-cache ]; then %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : fi %postun touch --no-create %{_datadir}/icons/hicolor || : if [ -x %{_bindir}/gtk-update-icon-cache ]; then %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : fi --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From duncan_j_ferguson at yahoo.co.uk Mon Jul 10 18:51:33 2006 From: duncan_j_ferguson at yahoo.co.uk (Duncan Ferguson) Date: Mon, 10 Jul 2006 19:51:33 +0100 Subject: Advice on desktop icons In-Reply-To: <44B29E35.80301@kobold.org> References: <1152552634.3123.2.camel@queeg> <44B29E35.80301@kobold.org> Message-ID: <1152557493.3123.7.camel@queeg> On Mon, 2006-07-10 at 11:36 -0700, Michael Thomas wrote: > Duncan Ferguson wrote: > > What is the best way to include icons within an rpm, and what sizes of > > icons should be used (i have seen mention of 16x16, 24x24 and 48x48, but > > how should they be named/installed within the rpm)? > > I usually use 32x32 or 48x48 icons, but it's really your choice. So I only really need one icon of a relevant size for the rpm (which I can choose arbitrarily), not a selection. That makes life easier, but I am surprised there isn't a more standardised approach across all rpm's for a number of icons of required sizes. Thanks Duncs ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From wart at kobold.org Mon Jul 10 18:56:35 2006 From: wart at kobold.org (Michael Thomas) Date: Mon, 10 Jul 2006 11:56:35 -0700 Subject: Advice on desktop icons In-Reply-To: <1152557493.3123.7.camel@queeg> References: <1152552634.3123.2.camel@queeg> <44B29E35.80301@kobold.org> <1152557493.3123.7.camel@queeg> Message-ID: <44B2A2E3.4010903@kobold.org> Duncan Ferguson wrote: > On Mon, 2006-07-10 at 11:36 -0700, Michael Thomas wrote: > >>Duncan Ferguson wrote: >> >>>What is the best way to include icons within an rpm, and what sizes of >>>icons should be used (i have seen mention of 16x16, 24x24 and 48x48, but >>>how should they be named/installed within the rpm)? >> >>I usually use 32x32 or 48x48 icons, but it's really your choice. > > > So I only really need one icon of a relevant size for the rpm (which I > can choose arbitrarily), not a selection. That makes life easier, but I > am surprised there isn't a more standardised approach across all rpm's > for a number of icons of required sizes. If you don't provide icons for the various sizes, then the desktop environment will resize them for you as-needed. If you notice that the automatic resizing doesn't look very good at certain sizes (say, a 48x48 reduced to 16x16), then you can provide an explicitly sized icon for the smaller (or larger) size. Whether you need multiple icons or not really depends on the icon and how good it looks when the desktop environment resizes it. --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From notting at redhat.com Mon Jul 10 19:10:11 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 10 Jul 2006 15:10:11 -0400 Subject: gal and oaf for FE In-Reply-To: <20060710125924.55b817b0.bugs.michael@gmx.net> References: <1152525036.16965.28.camel@mrwibble.mrwobble> <20060710125924.55b817b0.bugs.michael@gmx.net> Message-ID: <20060710191011.GC13423@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > > If gal and oaf have been officially orphaned (I can't remember seeing > > anything on the wiki about it), I'm happy to take them over (mainly as I > > need them for gnome-build). > > > > Could someone let me know if they are now dropped so I can get beavering > > on them tonight? > > Both have been Core packages. > > Somebody, who either decided to drop them or who knows for sure that they > have been dropped finally, could announce this in a _clear_ way on > maintainers-list or even inform FESCo about that. They are dead to me. Dead! I can dig up a full list of things that have Gone Away and post to maintainers later today. Bill From nicolas.mailhot at laposte.net Mon Jul 10 19:11:43 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 10 Jul 2006 21:11:43 +0200 Subject: Advice on desktop icons In-Reply-To: <1152557493.3123.7.camel@queeg> References: <1152552634.3123.2.camel@queeg> <44B29E35.80301@kobold.org> <1152557493.3123.7.camel@queeg> Message-ID: <1152558704.7269.42.camel@rousalka.dyndns.org> Le lundi 10 juillet 2006 ? 19:51 +0100, Duncan Ferguson a ?crit : > On Mon, 2006-07-10 at 11:36 -0700, Michael Thomas wrote: > > Duncan Ferguson wrote: > > > What is the best way to include icons within an rpm, and what sizes of > > > icons should be used (i have seen mention of 16x16, 24x24 and 48x48, but > > > how should they be named/installed within the rpm)? > > > > I usually use 32x32 or 48x48 icons, but it's really your choice. > > So I only really need one icon of a relevant size for the rpm (which I > can choose arbitrarily), not a selection. That makes life easier, but I > am surprised there isn't a more standardised approach across all rpm's > for a number of icons of required sizes. As http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html specifies "Minimally you should install a 48x48 icon in the hicolor theme" This is the *minimal* requirement. Ideally you should : * provide the full size range array : 16x16 22x22 24x24 32x32 36x36 48x48 64x64 72x72 96x96 128x128 192x192 (and not auto-scaled stuff - if it's to scale bitmaps in the Gimp without human intervention gtk can do it without your help thank you very much. If you provide different sizes that means you actually did some work so your scaled versions display better than auto-scaled ones) * and a scalable svg version * and do it for all the major icon themes (meaning you decline your icon following the style of every one of these themes Now considering the ideal case is probably too much work for you, if you want to do better than a 48x48 icon in the hicolor theme, you should follow the Tango guidelines (http://tango.freedesktop.org/). They strike a nice balance between achieved results and work put into the eye-candy. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Christian.Iseli at licr.org Mon Jul 10 19:21:27 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 10 Jul 2006 21:21:27 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: Your message of "Mon, 10 Jul 2006 12:37:13 CDT." Message-ID: <200607101921.k6AJLW2i009866@mx3.redhat.com> rdieter at math.unl.edu said: > If by "fail the build" you really mean "warn the packager", then we're in > agreement. (: I'd like something a bit more intrusive than a warning. What I'd like to see is: 1. package maintainer does its business and submits a build request 2. plague does the build, runs rpmlint, checks the provides, checks the warnings 3. if there are no diffs, succeed 4. if there are diffs, fail and report the diffs 5. at this point, maintainer has to scan the diffs and make a decision: A. the diffs are inocuous -> update the reference files and resubmit the build B. the diffs expose a problem -> back to step 1. Community will see the updates to the reference files and can comment where needed... I think this would be a pretty nice and easy QA improvement. Cheers, Christian From jamatos at fc.up.pt Mon Jul 10 19:22:14 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Mon, 10 Jul 2006 20:22:14 +0100 Subject: rpms/gambas/devel gambas-1.0.16-64bit.patch, NONE, 1.1 gambas.spec, 1.14, 1.15 In-Reply-To: <200607101906.k6AJ6cRs005888@cvs-int.fedora.redhat.com> References: <200607101906.k6AJ6cRs005888@cvs-int.fedora.redhat.com> Message-ID: <200607102022.14940.jamatos@fc.up.pt> On Monday 10 July 2006 20:06, Tom Callaway wrote: > Author: spot > > Update of /cvs/extras/rpms/gambas/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv5832/devel > > Modified Files: > gambas.spec > Added Files: > gambas-1.0.16-64bit.patch > Log Message: > > Fix the 64 bit architectures. > > > gambas-1.0.16-64bit.patch: > > --- NEW FILE gambas-1.0.16-64bit.patch --- > --- gambas-1.0.16/src/comp/gbi.c.BAD 2006-07-10 13:43:34.000000000 -0500 > +++ gambas-1.0.16/src/comp/gbi.c 2006-07-10 13:48:55.000000000 -0500 > @@ -115,7 +115,11 @@ > strncpy(_root, FILE_get_dir(FILE_get_dir(path)), MAX_PATH); > } > > +#if defined(_X86_64_) || defined(_IA64_) || defined(_PPC64_) || > defined(_SPARC64_) + strcpy(_lib_path, FILE_cat(_root, "lib64/gambas", > NULL)); > +#else > strcpy(_lib_path, FILE_cat(_root, "lib/gambas", NULL)); > +#endif > strcpy(_info_path, FILE_cat(_root, "share/gambas/info", NULL)); > > if (lt_dlinit()) > --- gambas-1.0.16/src/exec/gbx_project.c.BAD 2006-07-10 13:59:40.000000000 > -0500 +++ gambas-1.0.16/src/exec/gbx_project.c 2006-07-10 > 14:00:11.000000000 -0500 @@ -254,7 +254,11 @@ > > STRING_new(&PROJECT_exec_path, FILE_get_dir(FILE_get_dir(path)), -1); > > +#if defined(_X86_64_) || defined(_IA64_) || defined(_PPC64_) || > defined(_SPARC64_) + STRING_new(&PROJECT_lib_path, > FILE_cat(PROJECT_exec_path, "lib64/gambas", NULL), 0); +#else > STRING_new(&PROJECT_lib_path, FILE_cat(PROJECT_exec_path, "lib/gambas", > NULL), 0); +#endif > > /* fichier projet */ IIRC from reading this list (packagers or maintainer?), %{_libdir} for IA64 is /usr/lib and not /usr/lib64. (Or else I dreamed with this. :-) -- Jos? Ab?lio From notting at redhat.com Mon Jul 10 19:24:30 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 10 Jul 2006 15:24:30 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <20060710180001.09c7a5b7.bugs.michael@gmx.net> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> <44B26713.10200@fedoraproject.org> <20060710180001.09c7a5b7.bugs.michael@gmx.net> Message-ID: <20060710192430.GE13423@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > > You dont require any knowledge about the future plans to merely document > > the differences. Still I dont mind owning this but then I need to bug > > someone with more extras repository knowledge than me to help me out. > > Can you shed some light on "plague vs. brew" and why Core and Extras > buildsys and infrastructure divert in this area? brew was started before plague existed (although plague was obviously live first.) brew has many more options for dealing with packages once they're built; tagging them, organizing them, etc; it's needed for more complicated release engineering than what's currently done for Extras. > Also, I've read that Red Hat can set a package owner _per dist release_ > instead of _one owner per package_ (which is what our "owners.list" can do > only). True, it's because it's backed by a DB. owners.list is a very poor man's db. Bill From notting at redhat.com Mon Jul 10 19:25:15 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 10 Jul 2006 15:25:15 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <7dd7ab490607101035m70d4a889gf8467d3ac01017b@mail.gmail.com> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> <44B26713.10200@fedoraproject.org> <20060710180001.09c7a5b7.bugs.michael@gmx.net> <44B28ECC.7000201@fedoraproject.org> <7dd7ab490607101035m70d4a889gf8467d3ac01017b@mail.gmail.com> Message-ID: <20060710192515.GF13423@nostromo.devel.redhat.com> Chris Weyl (cweyl at alumni.drew.edu) said: > On 7/10/06, Rahul wrote: > >Brew is not just the build system but Fedora Core's package management > >(tracking packages) system to produce a distribution too. This is esp > >important for something that is not pushed out as just rolling updates. > > Semi OT, but is brew available externally to redhat anywhere? Not as of right now. Bill From skvidal at linux.duke.edu Mon Jul 10 19:26:41 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 10 Jul 2006 15:26:41 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <20060710192430.GE13423@nostromo.devel.redhat.com> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> <44B26713.10200@fedoraproject.org> <20060710180001.09c7a5b7.bugs.michael@gmx.net> <20060710192430.GE13423@nostromo.devel.redhat.com> Message-ID: <1152559601.13562.22.camel@cutter> On Mon, 2006-07-10 at 15:24 -0400, Bill Nottingham wrote: > Michael Schwendt (bugs.michael at gmx.net) said: > > > You dont require any knowledge about the future plans to merely document > > > the differences. Still I dont mind owning this but then I need to bug > > > someone with more extras repository knowledge than me to help me out. > > > > Can you shed some light on "plague vs. brew" and why Core and Extras > > buildsys and infrastructure divert in this area? > > brew was started before plague existed (although plague was obviously > live first.) > > brew has many more options for dealing with packages once they're built; > tagging them, organizing them, etc; it's needed for more complicated release > engineering than what's currently done for Extras. Well, we can only take your word for it having more options. No one can actually _see_ brew. :) -sv From chris.stone at gmail.com Mon Jul 10 18:26:25 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 10 Jul 2006 11:26:25 -0700 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <44B18CC5.6090403@fedoraproject.org> References: <44B107CB.9070104@leemhuis.info> <1152453259.8685.26.camel@rousalka.dyndns.org> <44B1456D.2030303@hhs.nl> <44B18CC5.6090403@fedoraproject.org> Message-ID: On 7/9/06, Rahul wrote: > Hans de Goede wrote: > > > > > > > > > Today I had a refrehsing drink in the sun with a friend of mine and we > > had a discussion about Fedora and about how despite Fedora being GREAT > > Ubuntu seems to be way more popular. > > > > One of the things he mentioned was the negative tone on the Fedora > > mailinglist, I disagreed. But reading this: he is right. We should drop > > the negative tone. > > > > Neither Core nor Extras do _NOT_ sucks at all. Yes certain things are > > better in Extras then Core, but we have it easier, they have all the > > _really_ _hard_ packages. And yes even we are not perfect, but both core > > and extras are pretty good if not excellent in the case of Extras. > > > > So not perfect, but most certainly not sucking at all! > > > > Talking about this negative attitude, we need to improve our self image > > as a community and we need to work on our image to the rest of the worl > > too, time for a Fedora Marketing team? > > > > Awareness also helps. http://fedoraproject.org/wiki/Marketing. All help > is most welcome. I don't think it's an awareness issue, I think it is more a polish issue. I've known people to choose ubuntu over fedora just because the extra function keys on their laptop work with ubuntu and not fedora. From notting at redhat.com Mon Jul 10 19:26:51 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 10 Jul 2006 15:26:51 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <200607101921.k6AJLW2i009866@mx3.redhat.com> References: <200607101921.k6AJLW2i009866@mx3.redhat.com> Message-ID: <20060710192651.GG13423@nostromo.devel.redhat.com> Christian.Iseli at licr.org (Christian.Iseli at licr.org) said: > > rdieter at math.unl.edu said: > > If by "fail the build" you really mean "warn the packager", then we're in > > agreement. (: > > I'd like something a bit more intrusive than a warning. What I'd like to see > is: > 1. package maintainer does its business and submits a build request > 2. plague does the build, runs rpmlint, checks the provides, > checks the warnings > 3. if there are no diffs, succeed > 4. if there are diffs, fail and report the diffs > 5. at this point, maintainer has to scan the diffs and make a decision: > A. the diffs are inocuous -> update the reference files and resubmit the > build > B. the diffs expose a problem -> back to step 1. > > Community will see the updates to the reference files and can comment where > needed... > > I think this would be a pretty nice and easy QA improvement. How about: 4. if there are diffs, move the package to holding 5. A) if the diffs are innocuous -> 'waive' the diffs, build is moved. Optionally, reference files are updated B) they expose a problem -> build is thrown away ? Bill From Christian.Iseli at licr.org Mon Jul 10 19:28:57 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 10 Jul 2006 21:28:57 +0200 Subject: gal and oaf for FE In-Reply-To: Your message of "Mon, 10 Jul 2006 15:10:11 EDT." <20060710191011.GC13423@nostromo.devel.redhat.com> Message-ID: <200607101928.k6AJSwDq015594@mx1.redhat.com> notting at redhat.com said: > I can dig up a full list of things that have Gone Away and post to > maintainers later today. There's a list here: http://fedoraproject.org/wiki/Extras/PackageStatus#head-fc61f83902f24ae4168e91ba0f4017ddeccea83b Cheers, Christian From rdieter at math.unl.edu Mon Jul 10 19:30:34 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 10 Jul 2006 14:30:34 -0500 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <200607101921.k6AJLW2i009866@mx3.redhat.com> References: <200607101921.k6AJLW2i009866@mx3.redhat.com> Message-ID: Christian.Iseli at licr.org wrote: > rdieter at math.unl.edu said: > >>If by "fail the build" you really mean "warn the packager", then we're in >>agreement. (: > > > I'd like something a bit more intrusive than a warning. What I'd like to see > is: ... > 5. at this point, maintainer has to scan the diffs and make a decision: > A. the diffs are inocuous -> update the reference files and resubmit the > build > > Community will see the updates to the reference files and can comment where > needed... > > I think this would be a pretty nice and easy QA improvement. Ugh, one more thing for packagers to do (maintaining rpmlint and rpm Provides/Requires reference files). I suppose if it could be made dead-simple to maintaine/update, via something like, make update-buildsys-reference-files (or whatever), I wouldn't mind. From sundaram at fedoraproject.org Mon Jul 10 19:32:16 2006 From: sundaram at fedoraproject.org (Rahul) Date: Tue, 11 Jul 2006 01:02:16 +0530 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: References: <44B107CB.9070104@leemhuis.info> <1152453259.8685.26.camel@rousalka.dyndns.org> <44B1456D.2030303@hhs.nl> <44B18CC5.6090403@fedoraproject.org> Message-ID: <44B2AB40.6020301@fedoraproject.org> Christopher Stone wrote: > On 7/9/06, Rahul wrote: >> Hans de Goede wrote: >> >> > >> > >> > >> > Today I had a refrehsing drink in the sun with a friend of mine and we >> > had a discussion about Fedora and about how despite Fedora being GREAT >> > Ubuntu seems to be way more popular. >> > >> > One of the things he mentioned was the negative tone on the Fedora >> > mailinglist, I disagreed. But reading this: he is right. We should drop >> > the negative tone. >> > >> > Neither Core nor Extras do _NOT_ sucks at all. Yes certain things are >> > better in Extras then Core, but we have it easier, they have all the >> > _really_ _hard_ packages. And yes even we are not perfect, but both >> core >> > and extras are pretty good if not excellent in the case of Extras. >> > >> > So not perfect, but most certainly not sucking at all! >> > >> > Talking about this negative attitude, we need to improve our self image >> > as a community and we need to work on our image to the rest of the worl >> > too, time for a Fedora Marketing team? >> > >> >> Awareness also helps. http://fedoraproject.org/wiki/Marketing. All help >> is most welcome. > > I don't think it's an awareness issue, I think it is more a polish > issue. I've known people to choose ubuntu over fedora just because > the extra function keys on their laptop work with ubuntu and not > fedora. > I was talking about the awareness that there already exists a marketing team. For other things, there is always bugzilla and yes Fedora does do more of the core hard system work compared to polishing now. A bit of focus on the polishing cant hurt. We are improving though. Help is welcome. Rahul From notting at redhat.com Mon Jul 10 19:32:19 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 10 Jul 2006 15:32:19 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <20060710192651.GG13423@nostromo.devel.redhat.com> References: <200607101921.k6AJLW2i009866@mx3.redhat.com> <20060710192651.GG13423@nostromo.devel.redhat.com> Message-ID: <20060710193219.GH13423@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > 4. if there are diffs, move the package to holding > 5. A) if the diffs are innocuous -> 'waive' the diffs, build is moved. Optionally, > reference files are updated > B) they expose a problem -> build is thrown away Even better if you do more tests versus the current build of the package, such as added/removed deps, changed sonames, loss of execshield protection, etc. Bill From notting at redhat.com Mon Jul 10 19:34:21 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 10 Jul 2006 15:34:21 -0400 Subject: gal and oaf for FE In-Reply-To: <200607101928.k6AJSwDq015594@mx1.redhat.com> References: <20060710191011.GC13423@nostromo.devel.redhat.com> <200607101928.k6AJSwDq015594@mx1.redhat.com> Message-ID: <20060710193421.GI13423@nostromo.devel.redhat.com> Christian.Iseli at licr.org (Christian.Iseli at licr.org) said: > > notting at redhat.com said: > > I can dig up a full list of things that have Gone Away and post to > > maintainers later today. > > There's a list here: > > http://fedoraproject.org/wiki/Extras/PackageStatus#head-fc61f83902f24ae4168e91ba0f4017ddeccea83b That's not FC5->FC6, though. Bill From jkeating at redhat.com Mon Jul 10 19:35:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 10 Jul 2006 15:35:41 -0400 Subject: rpms/gambas/devel gambas-1.0.16-64bit.patch, NONE, 1.1 gambas.spec, 1.14, 1.15 In-Reply-To: <200607102022.14940.jamatos@fc.up.pt> References: <200607101906.k6AJ6cRs005888@cvs-int.fedora.redhat.com> <200607102022.14940.jamatos@fc.up.pt> Message-ID: <200607101535.45380.jkeating@redhat.com> On Monday 10 July 2006 15:22, Jose' Matos wrote: > ? IIRC from reading this list (packagers or maintainer?), %{_libdir} for > IA64 is /usr/lib and not /usr/lib64. > > ? (Or else I dreamed with this. That is correct. ia64 is *fun*. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Mon Jul 10 19:50:54 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 10 Jul 2006 21:50:54 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <200607101921.k6AJLW2i009866@mx3.redhat.com> References: <200607101921.k6AJLW2i009866@mx3.redhat.com> Message-ID: <20060710215054.dde662a1.bugs.michael@gmx.net> On Mon, 10 Jul 2006 21:21:27 +0200, Christian.Iseli at licr.org wrote: > rdieter said: > > If by "fail the build" you really mean "warn the packager", then we're in > > agreement. (: It ought to be a warning, not another hurdle which requires packagers, who know their stuff, to "fight" with automated tests and questionable results. Even if there were a simple way to disable such tests, it makes using the entire package maintenance environment less comfortable. > I'd like something a bit more intrusive than a warning. What I'd like to see > is: > 1. package maintainer does its business and submits a build request > 2. plague does the build, runs rpmlint, checks the provides, > checks the warnings > 3. if there are no diffs, succeed > 4. if there are diffs, fail and report the diffs And: *boom* At this point in the queue of build jobs, other packages now fail or cause errors, since: a.) they require the results of earlier build jobs b.) they depend on later build jobs to be published c.) rpmlint at the server is not the same as packager's rpmlint ;) Additionally, packagers need to make rpmlint shut up at the buildsys level when it is mistaken about the things it finds and reports. Bad extra burden. Unless it is fully optional and can be requested by packagers explicitly for a "scratch target". > 5. at this point, maintainer has to scan the diffs and make a decision: > A. the diffs are inocuous -> update the reference files and resubmit the > build > B. the diffs expose a problem -> back to step 1. > > Community will see the updates to the reference files and can comment where > needed... It will create so much additional traffic that less community people will be able to handle it, and the important changes at the spec file level will be monitored by even less people. > I think this would be a pretty nice and easy QA improvement. As a first step, every packager (and package submitter) ought to use rpmlint manually more often and run it also on the binary rpms. From Christian.Iseli at licr.org Mon Jul 10 20:13:13 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 10 Jul 2006 22:13:13 +0200 Subject: gal and oaf for FE In-Reply-To: Your message of "Mon, 10 Jul 2006 15:34:21 EDT." <20060710193421.GI13423@nostromo.devel.redhat.com> Message-ID: <200607102013.k6AKDD2n001294@mx1.redhat.com> notting at redhat.com said: > That's not FC5->FC6, though. Ah, true. Guess I should add that... Christian From Christian.Iseli at licr.org Mon Jul 10 20:17:24 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 10 Jul 2006 22:17:24 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: Your message of "Mon, 10 Jul 2006 15:26:51 EDT." <20060710192651.GG13423@nostromo.devel.redhat.com> Message-ID: <200607102017.k6AKHTxI003100@mx1.redhat.com> notting at redhat.com said: > How about: > 4. if there are diffs, move the package to holding > 5. A) if the diffs are innocuous -> 'waive' the diffs, build is moved. > Optionally, reference files are updated > B) they expose a problem -> build is thrown away > ? That'd be fine too, but the buildsys would need a new command I guess. Christian From paul at city-fan.org Mon Jul 10 20:19:39 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 10 Jul 2006 21:19:39 +0100 Subject: gal and oaf for FE In-Reply-To: <20060710191011.GC13423@nostromo.devel.redhat.com> References: <1152525036.16965.28.camel@mrwibble.mrwobble> <20060710125924.55b817b0.bugs.michael@gmx.net> <20060710191011.GC13423@nostromo.devel.redhat.com> Message-ID: <1152562780.5120.2.camel@laurel.intra.city-fan.org> On Mon, 2006-07-10 at 15:10 -0400, Bill Nottingham wrote: > Michael Schwendt (bugs.michael at gmx.net) said: > > > If gal and oaf have been officially orphaned (I can't remember seeing > > > anything on the wiki about it), I'm happy to take them over (mainly as I > > > need them for gnome-build). > > > > > > Could someone let me know if they are now dropped so I can get beavering > > > on them tonight? > > > > Both have been Core packages. > > > > Somebody, who either decided to drop them or who knows for sure that they > > have been dropped finally, could announce this in a _clear_ way on > > maintainers-list or even inform FESCo about that. > > They are dead to me. Dead! As it happens, it turns out that gnome-build needs neither gal nor oaf anyway. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182320 Paul. From Christian.Iseli at licr.org Mon Jul 10 20:40:34 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 10 Jul 2006 22:40:34 +0200 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: Your message of "Mon, 10 Jul 2006 21:50:54 +0200." <20060710215054.dde662a1.bugs.michael@gmx.net> Message-ID: <200607102040.k6AKeY3R013651@mx1.redhat.com> bugs.michael at gmx.net said: > It ought to be a warning, not another hurdle which requires packagers, who > know their stuff, to "fight" with automated tests and questionable results. > Even if there were a simple way to disable such tests, it makes using the > entire package maintenance environment less comfortable. I am trying to deal with: - package staying within the packaging guidelines, one of which being an acceptable rpmlint output - unwanted things being suddenly provided by unexpceted packages - spurious soname changes - get to a point where it is pretty safe to have an automated rebuild of everything and be somewhat confident that the outcome is not completely broken > And: *boom* At this point in the queue of build jobs, other packages now > fail or cause errors, since: > a.) they require the results of earlier build jobs > b.) they depend on later build jobs to be published Yes. The hope is that it will only go *boom* for valid reasons. > c.) rpmlint at the server is not the same as packager's rpmlint ;) Could happen, but a new rpmlint error is probably something that needs to be dealt with. > Additionally, packagers need to make rpmlint shut up at the buildsys level > when it is mistaken about the things it finds and reports. Huh? Can you elaborate on this ? > Bad extra burden. Maybe. But I'm not so sure it's such a burden. All of this should be automated. > Unless it is fully optional and can be requested by > packagers explicitly for a "scratch target". Maybe that's a way to get there. > It will create so much additional traffic that less community people will be > able to handle it, and the important changes at the spec file level will be > monitored by even less people. My hope is that reference files will be more stable than the package files, so less traffic to monitor in the end. > As a first step, every packager (and package submitter) ought to use rpmlint > manually more often and run it also on the binary rpms. AFAIK, rpmlint is mostly useful on binary rpms. I'd just like to automate its use in a useful way. But these are just ideas. You are welcome to dislike them and/or offer other, better ones. Cheers, Christian From paul at all-the-johnsons.co.uk Mon Jul 10 20:47:28 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 10 Jul 2006 21:47:28 +0100 Subject: gal and oaf for FE In-Reply-To: <1152562780.5120.2.camel@laurel.intra.city-fan.org> References: <1152525036.16965.28.camel@mrwibble.mrwobble> <20060710125924.55b817b0.bugs.michael@gmx.net> <20060710191011.GC13423@nostromo.devel.redhat.com> <1152562780.5120.2.camel@laurel.intra.city-fan.org> Message-ID: <1152564448.24981.7.camel@T7.Linux> Hi, > As it happens, it turns out that gnome-build needs neither gal nor oaf > anyway. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182320 True, but there are probably a few other apps that need them. The offer is there... TTFN Paul -- "99 Jahre Krieg lie?en Keinen Platz f?r Sieger - Kriegesminister gibt's nicht mehr - und auch keine D?senflieger - heute ziehe ich meine Runden - sehe die Welt in Tr?mmern liegen - hab' nen Luftballon gefunden - denk an dich und la? ihn fliegen" - Nena, 99 luft balons -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Mon Jul 10 20:58:37 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 10 Jul 2006 23:58:37 +0300 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <20060710215054.dde662a1.bugs.michael@gmx.net> References: <200607101921.k6AJLW2i009866@mx3.redhat.com> <20060710215054.dde662a1.bugs.michael@gmx.net> Message-ID: <1152565117.2728.517.camel@localhost.localdomain> On Mon, 2006-07-10 at 21:50 +0200, Michael Schwendt wrote: > As a first step, every packager (and package submitter) ought to use > rpmlint manually more often and run it also on the binary rpms. And preferably also on _installed_ packages. Currently IIRC the only difference in rpmlint between checking uninstalled and installed binary rpms is that the latter fakes some checks to always succeed that make no sense for installed packages, and additionally checks for undefined non-weak symbols in shared libs. But it's likely that other useful checks that make sense for installed packages only will be introduced in the future. From ville.skytta at iki.fi Mon Jul 10 21:01:05 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 11 Jul 2006 00:01:05 +0300 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <200607102040.k6AKeY3R013651@mx1.redhat.com> References: <200607102040.k6AKeY3R013651@mx1.redhat.com> Message-ID: <1152565265.2728.520.camel@localhost.localdomain> On Mon, 2006-07-10 at 22:40 +0200, Christian.Iseli at licr.org wrote: > AFAIK, rpmlint is mostly useful on binary rpms. Mileages vary. Anyway some checks can be run against source rpms only, eg. those that examine the specfile directly. From paul at city-fan.org Mon Jul 10 21:03:12 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 10 Jul 2006 22:03:12 +0100 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <1152565117.2728.517.camel@localhost.localdomain> References: <200607101921.k6AJLW2i009866@mx3.redhat.com> <20060710215054.dde662a1.bugs.michael@gmx.net> <1152565117.2728.517.camel@localhost.localdomain> Message-ID: <1152565392.5120.10.camel@laurel.intra.city-fan.org> On Mon, 2006-07-10 at 23:58 +0300, Ville Skytt? wrote: > On Mon, 2006-07-10 at 21:50 +0200, Michael Schwendt wrote: > > > As a first step, every packager (and package submitter) ought to use > > rpmlint manually more often and run it also on the binary rpms. > > And preferably also on _installed_ packages. > > Currently IIRC the only difference in rpmlint between checking > uninstalled and installed binary rpms is that the latter fakes some > checks to always succeed that make no sense for installed packages, and > additionally checks for undefined non-weak symbols in shared libs. But > it's likely that other useful checks that make sense for installed > packages only will be introduced in the future. Unowned directory checks for instance? Paul. From ville.skytta at iki.fi Mon Jul 10 21:33:01 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 11 Jul 2006 00:33:01 +0300 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <1152565392.5120.10.camel@laurel.intra.city-fan.org> References: <200607101921.k6AJLW2i009866@mx3.redhat.com> <20060710215054.dde662a1.bugs.michael@gmx.net> <1152565117.2728.517.camel@localhost.localdomain> <1152565392.5120.10.camel@laurel.intra.city-fan.org> Message-ID: <1152567181.2728.524.camel@localhost.localdomain> On Mon, 2006-07-10 at 22:03 +0100, Paul Howarth wrote: > On Mon, 2006-07-10 at 23:58 +0300, Ville Skytt? wrote: > > > But > > it's likely that other useful checks that make sense for installed > > packages only will be introduced in the future. > > Unowned directory checks for instance? Good idea, filed as http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/35 Other candidates include something along the lines of https://www.redhat.com/archives/fedora-maintainers/2006-June/msg00176.html From chris.stone at gmail.com Mon Jul 10 21:45:46 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 10 Jul 2006 14:45:46 -0700 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <1152565117.2728.517.camel@localhost.localdomain> References: <200607101921.k6AJLW2i009866@mx3.redhat.com> <20060710215054.dde662a1.bugs.michael@gmx.net> <1152565117.2728.517.camel@localhost.localdomain> Message-ID: On 7/10/06, Ville Skytt? wrote: > On Mon, 2006-07-10 at 21:50 +0200, Michael Schwendt wrote: > > > As a first step, every packager (and package submitter) ought to use > > rpmlint manually more often and run it also on the binary rpms. > > And preferably also on _installed_ packages. Is there a way to do this without checking all installed packages? From chris.stone at gmail.com Mon Jul 10 21:53:53 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 10 Jul 2006 14:53:53 -0700 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: References: <200607101921.k6AJLW2i009866@mx3.redhat.com> <20060710215054.dde662a1.bugs.michael@gmx.net> <1152565117.2728.517.camel@localhost.localdomain> Message-ID: On 7/10/06, Christopher Stone wrote: > On 7/10/06, Ville Skytt? wrote: > > On Mon, 2006-07-10 at 21:50 +0200, Michael Schwendt wrote: > > > > > As a first step, every packager (and package submitter) ought to use > > > rpmlint manually more often and run it also on the binary rpms. > > > > And preferably also on _installed_ packages. > > Is there a way to do this without checking all installed packages? > nevermind, I was confused by the fact that the command "rpmlint asdfasdfasdfasdf" gave the same results as rpmlint poker-eval (one of my packages). I just assumed that rpmlint didnt do anything in this case, even using -v did not give any error message when I gave it a bogus package name. From mmcgrath at fedoraproject.org Mon Jul 10 22:41:15 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 10 Jul 2006 17:41:15 -0500 Subject: unversioned upstream source In-Reply-To: <20060710160719.GC5455@free.fr> References: <20060710160719.GC5455@free.fr> Message-ID: <3237e4410607101541h65c1de13v35e4cf40e89383e0@mail.gmail.com> > What do you think about that issue? What do you think is best practice > and why? > > -- > Pat > I'd say best practice is to query upstream and ask them to start providing a version. -Mike From peter at thecodergeek.com Mon Jul 10 22:55:15 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 10 Jul 2006 15:55:15 -0700 (PDT) Subject: unversioned upstream source In-Reply-To: <3237e4410607101541h65c1de13v35e4cf40e89383e0@mail.gmail.com> References: <20060710160719.GC5455@free.fr> <3237e4410607101541h65c1de13v35e4cf40e89383e0@mail.gmail.com> Message-ID: <56938.127.0.0.1.1152572115.squirrel@www.thecodergeek.com> Mike McGrath wrote: >> What do you think about that issue? What do you think is best practice >> and why? > I'd say best practice is to query upstream and ask them to start > providing a version. > > -Mike +1 That would make it simpler for the Fedora packager as well as packaging for other distributions/OSs. Plus, it's also a nicer way to keep archives of old versions just in case. (For example: Version 1.1 may work, but 1.2 may have a regression, and the only way to reliably compare the two is from their source tarballs. Note: This generally doesn't have to be a specific x.y(.z) version scheme or similar. Some projects use datestamps for their versions. My $0.02... -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From toshio at tiki-lounge.com Mon Jul 10 22:29:17 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 10 Jul 2006 15:29:17 -0700 Subject: rpms/monodoc/devel monodoc.spec,1.7,1.8 In-Reply-To: <44B23E1B.1070801@city-fan.org> References: <200607091305.k69D50M4005686@cvs-int.fedora.redhat.com> <1152517441.10312.52.camel@laurel.intra.city-fan.org> <1152518792.16965.7.camel@mrwibble.mrwobble> <44B23E1B.1070801@city-fan.org> Message-ID: <1152570558.2998.7.camel@localhost> On Mon, 2006-07-10 at 12:46 +0100, Paul Howarth wrote: > PFJ wrote: > > Hi, > > > >> My reading of the mono packaging guidelines is that things should be in > >> %{_libdir} rather than /usr/lib, and that the packager's effort should > >> go into getting the application/library to put things there and use them > >> from there. I realise this is non-trivial given the way that most > >> upstream mono apps/libraries are written, but hardcoding /usr/lib has to > >> be seen as a regression, doesn't it? > > > > The mono directory and gac directories are ALWAYS in /usr/lib > > irrespective of architecture or platform. These are the only exceptions > > to the rules. From memory, this was decided on many moons ago by Ximian > > (that's how old it is!) to be analogous of the Windows/System directory. > > > > I'm open to suggestions on this, but to maintain reliability and > > compliance with the mono infrastructure, it has to remain in /usr/lib > > My apologies. I was confusing things. Looking at > http://fedoraproject.org/wiki/Packaging/Mono there are still references > to %{_prefix}/lib/mono in the "gacutil" section. > > It should still be %{_prefix}/lib rather than /usr/lib though... When we discussed %{_libdir} I asked about the placement of /usr/lib/mono and the GAC. It was mentioned that we could file bugs on Core packages after we decided on guidelines. Does anyone know of a reason we should not consider moving the /usr/lib/mono hierarchy into %{_libdir}/mono? Otherwise I'll put in a bug and see if we can get the location changed in the FC7 timeframe. -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 buildsys at fedoraproject.org Mon Jul 10 23:07:38 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 10 Jul 2006 19:07:38 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-10 Message-ID: <20060710230738.462B9152167@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 25 TurboGears-0.8.9-3.fc5 c-ares-1.3.1-1.fc5 cvsgraph-1.6.1-1.fc5 dhcp-forwarder-0.7-9.fc5 dietlibc-0.30-1.fc5 dosbox-0.65-2.fc5 glipper-0.89-2.fc5 ip-sentinel-0.12-7.fc5 ipe-6.0-0.7.pre26.fc5 maxima-5.9.3-5.fc5 mimetic-0.9.1-1.fc5 monodoc-1.1.13-17.fc5 pcb-0.20060422-3 perl-Log-Dispatch-Config-1.01-1.fc5 perl-POE-Component-JobQueue-0.5402-1.fc5 perl-POE-Component-Logger-1.00-1.fc5 perl-SVK-1.08-2.fc5 pgp-tools-0.4.7-1.fc5 plone-2.5-1.fc5 python-clientform-0.2.2-4.fc5 python-mechanize-0.1.1a-4.fc5 python-sqlobject-0.7.0-6.fc5 verbiste-0.1.15-1.fc5 wine-docs-0.9.17-1.fc5 zope-2.9.3-3.fc5 Packages built and released for Fedora Extras 4: 18 abiword-2.4.5-1.fc4 c-ares-1.3.1-1.fc4 dietlibc-0.30-1.fc4 dosbox-0.65-2.fc4 ipe-6.0-0.7.pre26.fc4 maxima-5.9.3-5.fc4 mimetic-0.9.1-1.fc4 perl-Log-Dispatch-Config-1.01-1.fc4 perl-POE-Component-JobQueue-0.5402-1.fc4 perl-POE-Component-Logger-1.00-1.fc4 perl-SVK-1.08-2.fc4 pgp-tools-0.4.7-1.fc4 python-clientform-0.2.2-4.fc4 python-mechanize-0.1.1a-4.fc4 python-sqlobject-0.7.0-6.fc4 verbiste-0.1.15-1.fc4 wine-docs-0.9.17-0.1.fc4 zope-2.8.3-4.fc4 Packages built and released for Fedora Extras 3: 2 wine-docs-0.9.17-1.fc3 zope-2.8.0-3.fc3 Packages built and released for Fedora Extras development: 39 TurboGears-0.8.9-3.fc6 brightside-1.4.0-11.fc6 c-ares-1.3.1-1.fc6 crossfire-1.9.1-1.fc6 crossfire-client-1.9.1-1.fc6 crossfire-maps-1.9.1-2.fc6 cvsgraph-1.6.1-1.fc6 dhcp-forwarder-0.7-9.fc6 dietlibc-0.30-1.fc6 dosbox-0.65-2.fc6 factory-2.0.5-7.fc6 flow-tools-0.68-10.fc6 glipper-0.89-2.fc6 ip-sentinel-0.12-7.fc6 ipe-6.0-0.7.pre26.fc6 kismet-0.0.2006.04.R1-3.fc6 libfac-2.0.5-4.fc6 libibverbs-1.0.3-1.fc6 mimetic-0.9.1-1.fc6 mlton-20051202-7.fc6 monodoc-1.1.13-17.fc6 nagios-2.4-2.fc6 nant-0.85-5.fc6 octave-2.9.6-1.fc6 octave-forge-2006.07.09-1.fc6 pcb-0.20060422-3 perl-POE-Component-Child-1.39-1.fc6 perl-POE-Component-SimpleLog-1.03-1.fc6 pgp-tools-0.4.7-1.fc6 plone-2.5-1.fc6 python-mechanize-0.1.1a-4.fc6 python-sqlobject-0.7.0-6.fc6 scons-0.96.1-1.fc6 testdisk-6.4-2.fc6 util-vserver-0.30.210-3.fc6 verbiste-0.1.15-1.1.fc6 wine-docs-0.9.17-1.fc6 xlockmore-5.22-2.fc6 zope-2.9.3-3.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Jul 10 23:08:09 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 10 Jul 2006 19:08:09 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-10 Message-ID: <20060710230809.8F4DA152167@buildsys.fedoraproject.org> amarok: 5: 0:1.4.1-2.fc5 (FE5) 6: 0:1.4.0-5.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) cairo-java: 5: 0:1.0.4-0.FC5 (FC5-updates) 6: 0:1.0.4-0 (FC6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.0 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) dovecot: 5: 0:1.0-0.beta8.2.fc5 (FC5-updates) 6: 0:1.0-0.beta8.2 (FC6) ecl: 4: 0:0.9i-1.1.fc4 (FE4) 5: 0:0.9i-1.fc5 (FE5) 6: 0:0.9i-1.fc6 (FE6) eclipse-changelog: 5: 1:2.1.0_fc-2 (FC5-updates) 6: 1:2.1.0_fc-1 (FC6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) ghdl: 5: 0:0.23-0.58svn.1.fc5 (FE5) 6: 0:0.23-0.58svn.0.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) glib-java: 5: 0:0.2.5-0.FC5 (FC5-updates) 6: 0:0.2.5-0 (FC6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libglade-java: 5: 0:2.12.4-0.FC5 (FC5-updates) 6: 0:2.12.4-0 (FC6) libgnome-java: 5: 0:2.12.3-0.FC5 (FC5-updates) 6: 0:2.12.3-0 (FC6) libgtk-java: 5: 0:2.8.5-0.FC5 (FC5-updates) 6: 0:2.8.5-0 (FC6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libvte-java: 5: 0:0.12.0-0.FC5 (FC5-updates) 6: 0:0.12.0-0 (FC6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-11.fc6 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-Net-Jabber: 5: 0:2.0-6.fc5 (FE5) 6: 0:2.0-5.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) squid: 5: 7:2.5.STABLE14-2.FC5 (FC5-updates) 6: 7:2.5.STABLE14-2 (FC6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion: 5: 0:1.3.2-2.1 (FC5-updates) 6: 0:1.3.1-4 (FC6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) tcl: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) tk: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tzdata: 5: 0:2006g-1.fc5 (FC5-updates) 6: 0:2006g-1 (FC6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine: 4: 0:0.9.16-2.fc4 (FE4) 5: 0:0.9.16-1.fc5 (FE5) 6: 0:0.9.16-1.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) wordpress: 4: 0:2.0.3-4.fc4 (FE4) 5: 0:2.0.3-3.fc5 (FE5) 6: 0:2.0.3-3.fc6 (FE6) From buildsys at fedoraproject.org Mon Jul 10 23:31:58 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 10 Jul 2006 23:31:58 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-10 Message-ID: <20060710233158.25990.49873@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Mon Jul 10 23:31:58 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 10 Jul 2006 23:31:58 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-10 Message-ID: <20060710233158.26006.85857@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 nphilipp AT redhat.com bzflag - 2.0.8-1.fc5.i386 bzflag - 2.0.8-1.fc5.ppc bzflag - 2.0.8-1.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 tcallawa AT redhat.com perl-Image-ExifTool - 6.26-1.fc5.noarch perl-Image-ExifTool - 6.26-1.fc5.noarch perl-Image-ExifTool - 6.26-1.fc5.noarch zipsonic AT gmail.com freenx - 0.5.0-0.3.test7.fc5.noarch Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- bzflag-2.0.8-1.fc5.i386 requires libcares.so.0 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 perl-Image-ExifTool-6.26-1.fc5.noarch requires perl(the) syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- bzflag-2.0.8-1.fc5.ppc requires libcares.so.0 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 perl-Image-ExifTool-6.26-1.fc5.noarch requires perl(the) syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- bzflag-2.0.8-1.fc5.x86_64 requires libcares.so.0()(64bit) freenx-0.5.0-0.3.test7.fc5.noarch requires nx >= 0:1.5.0 libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) perl-Image-ExifTool-6.26-1.fc5.noarch requires perl(the) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: nphilipp AT redhat.com package: bzflag - 2.0.8-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: libcares.so.0 package: bzflag - 2.0.8-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libcares.so.0()(64bit) package: bzflag - 2.0.8-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: libcares.so.0 From buildsys at fedoraproject.org Mon Jul 10 23:31:58 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 10 Jul 2006 23:31:58 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-10 Message-ID: <20060710233158.26008.36422@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 gauret AT free.fr amarok-visualisation - 1.4.0-5.fc6.i386 amarok-visualisation - 1.4.0-5.fc6.ppc amarok-visualisation - 1.4.0-5.fc6.x86_64 imlinux AT gmail.com nagios - 2.4-2.fc6.i386 nagios - 2.4-2.fc6.ppc nagios - 2.4-2.fc6.x86_64 lmacken AT redhat.com gobby - 0.4.0-3.rc2.fc6.i386 gobby - 0.4.0-3.rc2.fc6.ppc gobby - 0.4.0-3.rc2.fc6.x86_64 obby - 0.4.0-2.rc2.fc6.i386 obby - 0.4.0-2.rc2.fc6.ppc obby - 0.4.0-2.rc2.fc6.x86_64 sobby - 0.4.0-2.rc1.fc6.i386 sobby - 0.4.0-2.rc1.fc6.ppc sobby - 0.4.0-2.rc1.fc6.x86_64 matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 gfontview - 0.5.0-5.fc5.ppc gfontview - 0.5.0-5.fc5.x86_64 libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 nphilipp AT redhat.com bzflag - 2.0.8-1.fc6.i386 bzflag - 2.0.8-1.fc6.ppc bzflag - 2.0.8-1.fc6.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 libibverbs - 1.0.3-1.fc6.ppc libibverbs - 1.0.3-1.fc6.x86_64 libibverbs-utils - 1.0.3-1.fc6.i386 libibverbs-utils - 1.0.3-1.fc6.ppc libibverbs-utils - 1.0.3-1.fc6.x86_64 tcallawa AT redhat.com perl-Image-ExifTool - 6.26-1.fc6.noarch perl-Image-ExifTool - 6.26-1.fc6.noarch perl-Image-ExifTool - 6.26-1.fc6.noarch thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 directfb - 0.9.24-5.fc5.ppc directfb - 0.9.24-5.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.i386 requires libvisual.so.0 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 bzflag-2.0.8-1.fc6.i386 requires libcares.so.0 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gobby-0.4.0-3.rc2.fc6.i386 requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 nagios-2.4-2.fc6.i386 requires libttf.so.2 obby-0.4.0-2.rc2.fc6.i386 requires libgnutls.so.12 perl-Image-ExifTool-6.26-1.fc6.noarch requires perl(the) sobby-0.4.0-2.rc1.fc6.i386 requires libgnutls.so.12 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.ppc requires libvisual.so.0 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 bzflag-2.0.8-1.fc6.ppc requires libcares.so.0 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gobby-0.4.0-3.rc2.fc6.ppc requires libgnutls.so.12 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 nagios-2.4-2.fc6.ppc requires libttf.so.2 obby-0.4.0-2.rc2.fc6.ppc requires libgnutls.so.12 perl-Image-ExifTool-6.26-1.fc6.noarch requires perl(the) sobby-0.4.0-2.rc1.fc6.ppc requires libgnutls.so.12 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.x86_64 requires libvisual.so.0()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) bzflag-2.0.8-1.fc6.x86_64 requires libcares.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gobby-0.4.0-3.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) nagios-2.4-2.fc6.x86_64 requires libttf.so.2()(64bit) obby-0.4.0-2.rc2.fc6.x86_64 requires libgnutls.so.12()(64bit) perl-Image-ExifTool-6.26-1.fc6.noarch requires perl(the) sobby-0.4.0-2.rc1.fc6.x86_64 requires libgnutls.so.12()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: nphilipp AT redhat.com package: bzflag - 2.0.8-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libcares.so.0 package: bzflag - 2.0.8-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libcares.so.0()(64bit) package: bzflag - 2.0.8-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libcares.so.0 From buildsys at fedoraproject.org Mon Jul 10 23:31:58 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 10 Jul 2006 23:31:58 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-10 Message-ID: <20060710233158.26002.80191@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 nphilipp AT redhat.com bzflag - 2.0.8-1.fc4.i386 bzflag - 2.0.8-1.fc4.ppc bzflag - 2.0.8-1.fc4.x86_64 tcallawa AT redhat.com perl-Image-ExifTool - 6.26-1.fc4.noarch perl-Image-ExifTool - 6.26-1.fc4.noarch perl-Image-ExifTool - 6.26-1.fc4.noarch Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- bzflag-2.0.8-1.fc4.i386 requires libcares.so.0 perl-Image-ExifTool-6.26-1.fc4.noarch requires perl(the) wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- bzflag-2.0.8-1.fc4.ppc requires libcares.so.0 perl-Image-ExifTool-6.26-1.fc4.noarch requires perl(the) wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- bzflag-2.0.8-1.fc4.x86_64 requires libcares.so.0()(64bit) perl-Image-ExifTool-6.26-1.fc4.noarch requires perl(the) wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) ====================================================================== New report for: nphilipp AT redhat.com package: bzflag - 2.0.8-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: libcares.so.0 package: bzflag - 2.0.8-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libcares.so.0()(64bit) package: bzflag - 2.0.8-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: libcares.so.0 ====================================================================== New report for: ivazquez AT ivazquez.net package: wp_tray - 0.5.1-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: libatkmm-1.6.so.1 package: wp_tray - 0.5.1-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libatkmm-1.6.so.1()(64bit) package: wp_tray - 0.5.1-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: libatkmm-1.6.so.1 From helge.hess at opengroupware.org Tue Jul 11 00:02:55 2006 From: helge.hess at opengroupware.org (Helge Hess) Date: Tue, 11 Jul 2006 02:02:55 +0200 Subject: opengroupware for FE In-Reply-To: <20060705110040.GH1419@neu.nirvana> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> <1152096783.30969.328.camel@xpc.home.erwinrol.com> <20060705110040.GH1419@neu.nirvana> Message-ID: On Jul 5, 2006, at 13:00, Axel Thimm wrote: > Already started earlier today, but I'm waiting till the end of week to > make a call for reviewers (where Helge will have released some more > bits :). OK, libFoundation 1.1.2 is up: http://download.opengroupware.org/nightly/sources/releases/ libFoundation-1.1.2-r152.tar.gz and works with our RPM buildsystem. This should work fine and should be ready for packaging. > See for example: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197649 Note: gnustep-make != gnustep-make. You need to consider the configuration of gnustep-make. If its configured for the gnu-fd-nil library combo (as currently required by OGo), it won't work with GNUstep and the other way around. Which is why we usually install the OGo "configuration" in /usr/local/ OGoRoot. (a better place might be /usr/local/share/gstep-make-gnu-fd- nil, don't know) Wrt the issue report, I'm trying hard to push FHS into GNUstep for a few years now. And while people do not seem to object anymore (no religious discussions like before), the people who need to do the required work (mostly Nicola Pero) are too busy to actually do it ;-/ Anyway, OGo / SOPE have the necessary makefile hacks to produce FHS binaries which do not require gstep-make at runtime. > I'll repost with a list of all opengroupware related bugzillas when > they are submitted. Thanks. > It's just packaging it up and I hope the current specfile will still > be able to do it. I recently packaged sope 4.5.7 and apart from an ICE > in objc in fc4 it went fine. Whats that ICE? Thanks, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From jwboyer at jdub.homelinux.org Tue Jul 11 00:47:42 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 10 Jul 2006 19:47:42 -0500 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <200607101403.58498.jkeating@redhat.com> References: <44B107CB.9070104@leemhuis.info> <44B26713.10200@fedoraproject.org> <20060710180001.09c7a5b7.bugs.michael@gmx.net> <200607101403.58498.jkeating@redhat.com> Message-ID: <1152578862.2729.3.camel@vader.jdub.homelinux.org> On Mon, 2006-07-10 at 14:03 -0400, Jesse Keating wrote: > On Monday 10 July 2006 12:00, Michael Schwendt wrote: > > Can you shed some light on "plague vs. brew" and why Core and Extras > > buildsys and infrastructure divert in this area? > > Brew is a management layer over Mock, like Plague is. Brew was written with a > package database backend in mind, and development on it started before Plague > work began, but we didn't get to the point of actually using it until very > recently. It is interesting now that there is work being considered to add a > package database to Plague. Interesting indeed. > > Brew handles some things Red Hat needs for RHEL, much more strict tracking of > build root contents for package builds, finer grained collection inheritince, > collection locking (does plague do this?), an xml-rpc API to the package > database, etc... Not all of these things are needed for Fedora, but some are > pretty nice. There is some discussion about opensourcing Brew, the layers > above mock. I believe this would be very good to do. Having extra stuff that Fedora doesn't really need isn't really a problem from my point of view. If we could get Core and Extras using the same buildsystem, it would be a Good Thing (tm). josh From katzj at redhat.com Tue Jul 11 02:24:27 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 10 Jul 2006 22:24:27 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <20060710193219.GH13423@nostromo.devel.redhat.com> References: <200607101921.k6AJLW2i009866@mx3.redhat.com> <20060710192651.GG13423@nostromo.devel.redhat.com> <20060710193219.GH13423@nostromo.devel.redhat.com> Message-ID: <1152584667.20018.27.camel@aglarond.local> On Mon, 2006-07-10 at 15:32 -0400, Bill Nottingham wrote: > Bill Nottingham (notting at redhat.com) said: > > 4. if there are diffs, move the package to holding > > 5. A) if the diffs are innocuous -> 'waive' the diffs, build is moved. Optionally, > > reference files are updated > > B) they expose a problem -> build is thrown away > > Even better if you do more tests versus the current build of the package, such > as added/removed deps, changed sonames, loss of execshield protection, etc. Don't forget checking for multilib conflicts[1] :) Jeremy [1] Simple stupid script attached -------------- next part -------------- A non-text attachment was scrubbed... Name: multilib-cmp.py Type: text/x-python Size: 3413 bytes Desc: not available URL: From nman64 at n-man.com Tue Jul 11 06:04:55 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Tue, 11 Jul 2006 01:04:55 -0500 Subject: What do Extras contributors use the wiki for? In-Reply-To: <20060710181202.ed98093b.bugs.michael@gmx.net> References: <200607091503.16790.nman64@n-man.com> <20060710181202.ed98093b.bugs.michael@gmx.net> Message-ID: <200607110104.58304.nman64@n-man.com> On Monday 10 July 2006 11:12, Michael Schwendt wrote: > On Sun, 9 Jul 2006 15:03:12 -0500, Patrick W. Barnes wrote: > > In order to reduce the complexity in getting started with Extras, we have > > made a few adjustments in the past to avoid making EditGroup membership a > > requirement for Extras contributors. At present, some pages, like > > CVSSyncNeeded, have special ACLs that avoid the normal EditGroup > > requirement. > > > > I'd like to know where Extras contributors might currently need EditGroup > > membership in order to perform required tasks. Until we have a single > > sign-on ability (which is an Infrastructure to-do item), I'd like to > > enable Extras contributors to do their jobs without requiring EditGroup > > membership. While EditGroup membership is a small step for members of > > cvsextras, it is one step that we can avoid, and every little bit helps > > in the overcomplicated process that new contributors must currently > > complete. > > > > Candidates for adjustment include pages that any Extras contributor needs > > to edit but do not provide content to end-users. Eligible pages might > > include tracking pages, schedules or task lists. Ineligible pages would > > include SIG pages, documentation pages or policy pages. Some examples > > that I have already seen for eligible pages are the FCx Status pages, > > User Registry, Orphaned Packages List and Wish List. Does anyone have > > other pages to suggest or any reasons why these examples shouldn't be > > opened up? > > Why should the FCx Status pages, the User Registry, the Orphaned Packages > List be opened up to non-Contributors? The objective is to remove the EditGroup requirement, allowing Extras contributors to work without having to obtain EditGroup membership. This saves on small step for Extras contributors who don't want the hassle. We already have Extras contributors that are not in the EditGroup, and they've been working with limitations that may keep them from doing what they need to do. Eventually, our infrastructure should solve this entirely by integrating the Account System for authentication and authorization, but this stop-gap measure might make the lives of some Extras contributors a little easier. If it is decided that all Extras contributors should be required to have EditGroup membership, then the already-loosened wiki pages can be tightened. > > Especially the FCx Status pages must not be writable by anyone who does > not have a valid FE Account, since the requests added to those pages may > result in changes to the repository. The Wiki is our "poor man's > ticket-system" in this case. The EditGroup really isn't a good measure of whether or not someone can be trusted. It is a small barrier that takes care of our licensing needs and keeps spammers from attacking the wiki, nothing more. Many members of the EditGroup are not Extras contributors, and not all Extras contributors are members of the EditGroup. > > If more became known about the OTRS that has been set up in Fedora > infrastructure, maybe we could switch to using that one for some of > the FE related requests, too? Now that's a good idea. ;-) https://admin.fedoraproject.org/tickets/customer.pl -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Jul 11 06:29:04 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 11 Jul 2006 08:29:04 +0200 Subject: What do Extras contributors use the wiki for? In-Reply-To: <200607110104.58304.nman64@n-man.com> References: <200607091503.16790.nman64@n-man.com> <20060710181202.ed98093b.bugs.michael@gmx.net> <200607110104.58304.nman64@n-man.com> Message-ID: <44B34530.8000605@leemhuis.info> Patrick W. Barnes schrieb: > On Monday 10 July 2006 11:12, Michael Schwendt wrote: >> On Sun, 9 Jul 2006 15:03:12 -0500, Patrick W. Barnes wrote: >> Why should the FCx Status pages, the User Registry, the Orphaned Packages >> List be opened up to non-Contributors? > > The objective is to remove the EditGroup requirement, allowing Extras > contributors to work without having to obtain EditGroup membership. Just a note: I don't like that goal to much. I'd prefer if all Extras contributors get automatically access to the wiki (and used to edit it) so they are able to improve the Documentation around Extras if they want to (without having to take other hurdles first). CU thl From bugzilla at redhat.com Tue Jul 11 06:46:33 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 11 Jul 2006 02:46:33 -0400 Subject: [Bug 178905] Review Request: smbldap-tools In-Reply-To: Message-ID: <200607110646.k6B6kX50003467@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: smbldap-tools https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178905 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com ------- Additional Comments From timosha at gmail.com 2006-07-11 02:37 EST ------- and now you can remove smbldap-tools files from samba package rpm -qd samba | grep smbldap-tools /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/CONTRIBUTORS /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/COPYING /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/ChangeLog /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/FILES /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/INFRA /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/INSTALL /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/Makefile /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/README /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/TODO /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/configure.pl /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/contents_motif.gif /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/index.html /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/next_motif.gif /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/previous_motif.gif /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/smbldap-tools.html /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/smbldap-tools001.html /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/smbldap-tools002.html /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/smbldap-tools003.html /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/smbldap-tools004.html /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/smbldap-tools005.html /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/smbldap-tools006.html /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/smbldap-tools007.html /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/smbldap-tools008.html /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/smbldap-tools009.html /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/html/smbldap-tools010.html /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/smbldap-migrate-pwdump-accounts /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/smbldap-migrate-pwdump-groups /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/smbldap-migrate-unix-accounts /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/smbldap-migrate-unix-groups /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/doc/smbldap-tools.pdf /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smb.conf /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap-groupadd /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap-groupdel /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap-groupmod /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap-groupshow /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap-passwd /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap-populate /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap-tools.spec /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap-useradd /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap-userdel /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap-userinfo /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap-usermod /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap-usershow /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap.conf /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap_bind.conf /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap_tools.pm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From nman64 at n-man.com Tue Jul 11 06:51:38 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Tue, 11 Jul 2006 01:51:38 -0500 Subject: What do Extras contributors use the wiki for? In-Reply-To: <44B34530.8000605@leemhuis.info> References: <200607091503.16790.nman64@n-man.com> <200607110104.58304.nman64@n-man.com> <44B34530.8000605@leemhuis.info> Message-ID: <200607110151.40708.nman64@n-man.com> On Tuesday 11 July 2006 01:29, Thorsten Leemhuis wrote: > Patrick W. Barnes schrieb: > > On Monday 10 July 2006 11:12, Michael Schwendt wrote: > >> On Sun, 9 Jul 2006 15:03:12 -0500, Patrick W. Barnes wrote: > >> Why should the FCx Status pages, the User Registry, the Orphaned > >> Packages List be opened up to non-Contributors? > > > > The objective is to remove the EditGroup requirement, allowing Extras > > contributors to work without having to obtain EditGroup membership. > > Just a note: I don't like that goal to much. I'd prefer if all Extras > contributors get automatically access to the wiki (and used to edit it) > so they are able to improve the Documentation around Extras if they want > to (without having to take other hurdles first). > In this case, at least three things need to happen: 1. Instructions for obtaining wiki-editing privileges should be added to the documentation for new contributors. http://fedoraproject.org/wiki/Extras/Contributors The exact method specified might need a little thought. Options might include visiting #fedora-extras, sending a message to fedora-extras-list, contacting a specific team or individual, or even using an ACL-reduced queue on the wiki. In any case, whomever is responsible for handling the requests will need to be versed in the rules and verification procedure. 2. All existing Extras contributors who do not have EditGroup membership need to get it. From my experience with other groups, this may take time and effort, with individual emails being sent to contributors to inform them of the requirement. Someone will need to compare a list of Extras contributors (cvsextras?) to the EditGroup and figure out who is missing, then find contact information and get in touch with them. 3. CVSSyncNeeded and any other Extras pages that currently have loosened ACLs will need those ACLs tightened. I can handle this, but task #2 should be taken care of first. If the Infrastructure team accomplishes all of its goals (which will take time), then this entire issue will become obsolete, as wiki edit access would be integrated with the Account System, and anyone who has completed the CLA would automatically gain editing permissions. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugzilla at redhat.com Tue Jul 11 07:00:44 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 11 Jul 2006 03:00:44 -0400 Subject: [Bug 178905] Review Request: smbldap-tools In-Reply-To: Message-ID: <200607110700.k6B70iYN004175@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: smbldap-tools https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178905 ------- Additional Comments From paul at city-fan.org 2006-07-11 02:51 EST ------- (In reply to comment #8) > and now you can remove smbldap-tools files from samba package > > rpm -qd samba | grep smbldap-tools > /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/CONTRIBUTORS (snip) > /usr/share/doc/samba-3.0.22/LDAP/smbldap-tools-0.9.1/smbldap_tools.pm You'd need to raise that as a separate issue with the samba package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From mailinglists at erwinrol.com Tue Jul 11 07:59:00 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 11 Jul 2006 09:59:00 +0200 Subject: opengroupware for FE In-Reply-To: References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> <1152096783.30969.328.camel@xpc.home.erwinrol.com> <20060705110040.GH1419@neu.nirvana> Message-ID: <1152604740.2819.308.camel@xpc.home.erwinrol.com> On Tue, 2006-07-11 at 02:02 +0200, Helge Hess wrote: > On Jul 5, 2006, at 13:00, Axel Thimm wrote: > > Already started earlier today, but I'm waiting till the end of week to > > make a call for reviewers (where Helge will have released some more > > bits :). > > OK, libFoundation 1.1.2 is up: > > http://download.opengroupware.org/nightly/sources/releases/ > libFoundation-1.1.2-r152.tar.gz great :-) > > and works with our RPM buildsystem. This should work fine and should > be ready for packaging. > > > See for example: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197649 > > Note: gnustep-make != gnustep-make. You need to consider the > configuration of gnustep-make. If its configured for the gnu-fd-nil > library combo (as currently required by OGo), it won't work with > GNUstep and the other way around. > Which is why we usually install the OGo "configuration" in /usr/local/ > OGoRoot. (a better place might be /usr/local/share/gstep-make-gnu-fd- > nil, don't know) Hmmm does this mean a package name of "gnustep-make" would possibly collide with another package named "gnustep-make" ? If so maybe a "oog-gnustep-make" package name is better ? - Erwin From helge.hess at opengroupware.org Tue Jul 11 08:16:44 2006 From: helge.hess at opengroupware.org (Helge Hess) Date: Tue, 11 Jul 2006 10:16:44 +0200 Subject: opengroupware for FE In-Reply-To: <1152604740.2819.308.camel@xpc.home.erwinrol.com> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> <1152096783.30969.328.camel@xpc.home.erwinrol.com> <20060705110040.GH1419@neu.nirvana> <1152604740.2819.308.camel@xpc.home.erwinrol.com> Message-ID: On Jul 11, 2006, at 09:59, Erwin Rol wrote: > Hmmm does this mean a package name of "gnustep-make" would possibly > collide with another package named "gnustep-make" ? Yes. > If so maybe a "oog-gnustep-make" package name is better ? gnustep-make-libfoundation or gnustep-make-gnu-fd-nil would be better. To explain the library combo: gnu-fd-nil. There are multiple Objective-C runtimes, Foundation and GUI libraries. A combination of those is called a "library-combo" by gstep-make and represented as a string: OBJCRUNTIME.FOUNDATION.GUI. The three most common ones: gnu-fd-nil: GNU Objective-C runtime, libFoundation Foundation, no GUI gnu-gnu-gnu: GNU Objective-C runtime, gnustep-base Foundation, gnustep-gui apple-apple-apple: Apple runtime, Cocoa Foundation, Cocoa GUI Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From Axel.Thimm at ATrpms.net Tue Jul 11 09:15:20 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 11 Jul 2006 11:15:20 +0200 Subject: opengroupware for FE In-Reply-To: References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> <1152096783.30969.328.camel@xpc.home.erwinrol.com> <20060705110040.GH1419@neu.nirvana> Message-ID: <20060711091520.GE9010@neu.nirvana> On Tue, Jul 11, 2006 at 02:02:55AM +0200, Helge Hess wrote: > Note: gnustep-make != gnustep-make. You need to consider the > configuration of gnustep-make. If its configured for the gnu-fd-nil > library combo (as currently required by OGo), it won't work with > GNUstep and the other way around. I though the parameter was the _default_ combo and could be overridden later on. Or does one need the "fat binaries"? While the current objective is ogo, it would be nice to already have the foundations for allowing further gnustep bits to work. Preferably w/o having a package for each library combo. > Wrt the issue report, I'm trying hard to push FHS into GNUstep for a > few years now. And while people do not seem to object anymore (no > religious discussions like before), the people who need to do the > required work (mostly Nicola Pero) are too busy to actually do it ;-/ Do you have fhs patches for gnustep-make? > >It's just packaging it up and I hope the current specfile will still > >be able to do it. I recently packaged sope 4.5.7 and apart from an ICE > >in objc in fc4 it went fine. > > Whats that ICE? Compiling file NGActiveSocket.m ... NGActiveSocket.m: In function '+[NGActiveSocket socketPair:inDomain:]': NGActiveSocket.m:89: internal compiler error: in expand_expr_real_1, at expr.c:6604 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Preprocessed source stored into /tmp/cctCFQvq.out file, please attach this to your bugreport. Happens only with FC4 (anything before or after is OK) and only with i386. I've submitted a couple objc bug reports and they were fixed in later gcc releases, but not anymore for fc4. -- 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 helge.hess at opengroupware.org Tue Jul 11 11:30:00 2006 From: helge.hess at opengroupware.org (Helge Hess) Date: Tue, 11 Jul 2006 13:30:00 +0200 Subject: opengroupware for FE In-Reply-To: <20060711091520.GE9010@neu.nirvana> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> <1152096783.30969.328.camel@xpc.home.erwinrol.com> <20060705110040.GH1419@neu.nirvana> <20060711091520.GE9010@neu.nirvana> Message-ID: On Jul 11, 2006, at 11:15, Axel Thimm wrote: > On Tue, Jul 11, 2006 at 02:02:55AM +0200, Helge Hess wrote: >> Note: gnustep-make != gnustep-make. You need to consider the >> configuration of gnustep-make. If its configured for the gnu-fd-nil >> library combo (as currently required by OGo), it won't work with >> GNUstep and the other way around. > I though the parameter was the _default_ combo and could be overridden > later on. Or does one need the "fat binaries"? Hm, yes, you are right. One can switch the library combo using a script (probably not even necessary for compilation, just doing a "make LIBRARY_COMBO=gnu-fd-nil" might do in this case). >> Wrt the issue report, I'm trying hard to push FHS into GNUstep for a >> few years now. And while people do not seem to object anymore (no >> religious discussions like before), the people who need to do the >> required work (mostly Nicola Pero) are too busy to actually do it ;-/ > Do you have fhs patches for gnustep-make? No. We hack that a layer above in the makefiles (fhs.make), which is quite annoying but works. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From Axel.Thimm at ATrpms.net Tue Jul 11 11:45:08 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 11 Jul 2006 13:45:08 +0200 Subject: opengroupware for FE In-Reply-To: References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> <1152096783.30969.328.camel@xpc.home.erwinrol.com> <20060705110040.GH1419@neu.nirvana> <20060711091520.GE9010@neu.nirvana> Message-ID: <20060711114508.GG9010@neu.nirvana> On Tue, Jul 11, 2006 at 01:30:00PM +0200, Helge Hess wrote: > On Jul 11, 2006, at 11:15, Axel Thimm wrote: > >On Tue, Jul 11, 2006 at 02:02:55AM +0200, Helge Hess wrote: > >>Note: gnustep-make != gnustep-make. You need to consider the > >>configuration of gnustep-make. If its configured for the gnu-fd-nil > >>library combo (as currently required by OGo), it won't work with > >>GNUstep and the other way around. > >I though the parameter was the _default_ combo and could be overridden > >later on. Or does one need the "fat binaries"? > > Hm, yes, you are right. One can switch the library combo using a > script (probably not even necessary for compilation, just doing a > "make LIBRARY_COMBO=gnu-fd-nil" might do in this case). OK, then how about having gnustep-make default to gnu-gnu-gnu, e.g. be gnustepish and pass the gnu-fd-nil combo for the further builds? We also got rid of libobjc-fd2, so we can make everybody happy. > >>Wrt the issue report, I'm trying hard to push FHS into GNUstep for a > >>few years now. And while people do not seem to object anymore (no > >>religious discussions like before), the people who need to do the > >>required work (mostly Nicola Pero) are too busy to actually do it ;-/ > >Do you have fhs patches for gnustep-make? > > No. We hack that a layer above in the makefiles (fhs.make), which is > quite annoying but works. I'll keep things more gnustep-like then fixing only the most ugly fhs breaking bits. Let's hope gnustep developers fix FHS, soon. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Tue Jul 11 15:15:08 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 11 Jul 2006 17:15:08 +0200 Subject: File conflicts in Fedora Extras Development Message-ID: <20060711171508.2ba36dd1.bugs.michael@gmx.net> No further comment at this point. [...] blackbox-0.70.1-4.fc5.i386.rpm File conflict with: /usr/bin/bsetbg File conflict with: /usr/bin/bsetbg File conflict with: /usr/bin/bsetroot File conflict with: /usr/bin/bsetroot => Package conflicts with: hackedbox - 0.8.4-6.fc5.i386 bsd-games-2.17-13.fc6.i386.rpm File conflict with: /usr/share/man/man6/worm.6.gz => Package conflicts with: xscreensaver-extras - 1:5.00-13.fc6.i386 compat-wxPythonGTK2-2.4.2.4-11.fc6.i386.rpm File conflict with: /usr/bin/pyalacarte File conflict with: /usr/bin/pyalacarte File conflict with: /usr/bin/pyalamode File conflict with: /usr/bin/pyalamode File conflict with: /usr/bin/pycrust File conflict with: /usr/bin/pycrust File conflict with: /usr/bin/pyshell File conflict with: /usr/bin/pyshell File conflict with: /usr/bin/pywrap File conflict with: /usr/bin/pywrap => Package conflicts with: wxPython - 2.6.3.2-1.fc6.i386 cyrus-imapd-2.3.1-2.6.fc5.i386.rpm File conflict with: /etc/pam.d/imap File conflict with: /etc/pam.d/imap File conflict with: /etc/pam.d/pop File conflict with: /etc/pam.d/pop File conflict with: /usr/share/man/man8/imapd.8.gz => Package conflicts with: uw-imap - 2004g-4.fc5.2.i386 clamav-0.88.3-1.fc6.i386.rpm File conflict with: /usr/share/man/man1/clamdscan.1.gz File conflict with: /usr/share/man/man5/clamd.conf.5.gz => Package conflicts with: clamav-server - 0.88.3-1.fc6.i386 fish-1.12.0-1.fc5.i386.rpm File conflict with: /usr/bin/count File conflict with: /usr/bin/count File conflict with: /usr/share/man/man1/count.1.gz => Package conflicts with: html-xml-utils - 3.7-3.fc5.i386 gnumeric-1.6.3-2.fc6.i386.rpm File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl => Package conflicts with: gnumeric-devel - 1:1.6.3-2.fc6.i386 gnumeric-devel-1.6.3-2.fc6.i386.rpm File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl => All file names in this package are found in the repository elsewhere! => Package conflicts with: gnumeric - 1:1.6.3-2.fc6.i386 hackedbox-0.8.4-6.fc5.i386.rpm File conflict with: /usr/bin/bsetbg File conflict with: /usr/bin/bsetbg File conflict with: /usr/bin/bsetroot File conflict with: /usr/bin/bsetroot => Package conflicts with: blackbox - 0.70.1-4.fc5.i386 html-xml-utils-3.7-3.fc5.i386.rpm File conflict with: /usr/bin/count File conflict with: /usr/bin/count File conflict with: /usr/share/man/man1/count.1.gz => Package conflicts with: fish - 1.12.0-1.fc5.i386 heartbeat-2.0.5-2.fc6.i386.rpm File conflict with: /usr/lib/libapphb.so.0 File conflict with: /usr/lib/libapphb.so.0.0.0 File conflict with: /usr/lib/libccmclient.so.1 File conflict with: /usr/lib/libccmclient.so.1.0.0 File conflict with: /usr/lib/libcib.so.1 File conflict with: /usr/lib/libcib.so.1.0.1 File conflict with: /usr/lib/libclm.so.1 File conflict with: /usr/lib/libclm.so.1.0.0 File conflict with: /usr/lib/libcrmcommon.so.1 File conflict with: /usr/lib/libcrmcommon.so.1.0.1 File conflict with: /usr/lib/libhbclient.so.1 File conflict with: /usr/lib/libhbclient.so.1.0.0 File conflict with: /usr/lib/libhbmgmt.so.0 File conflict with: /usr/lib/libhbmgmt.so.0.0.0 File conflict with: /usr/lib/libhbmgmtclient.so.0 File conflict with: /usr/lib/libhbmgmtclient.so.0.0.0 File conflict with: /usr/lib/libhbmgmtcommon.so.0 File conflict with: /usr/lib/libhbmgmtcommon.so.0.0.0 File conflict with: /usr/lib/libhbmgmttls.so.0 File conflict with: /usr/lib/libhbmgmttls.so.0.0.0 File conflict with: /usr/lib/liblrm.so.0 File conflict with: /usr/lib/liblrm.so.0.0.0 File conflict with: /usr/lib/libpengine.so.1 File conflict with: /usr/lib/libpengine.so.1.1.0 File conflict with: /usr/lib/libplumb.so.1 File conflict with: /usr/lib/libplumb.so.1.0.0 File conflict with: /usr/lib/libplumbgpl.so.1 File conflict with: /usr/lib/libplumbgpl.so.1.0.0 File conflict with: /usr/lib/librecoverymgr.so.1 File conflict with: /usr/lib/librecoverymgr.so.1.0.0 File conflict with: /usr/lib/libstonithd.so.0 File conflict with: /usr/lib/libstonithd.so.0.0.0 File conflict with: /usr/lib/libtransitioner.so.1 File conflict with: /usr/lib/libtransitioner.so.1.0.0 File conflict with: /usr/share/doc/heartbeat-2.0.5/AUTHORS File conflict with: /usr/share/doc/heartbeat-2.0.5/COPYING File conflict with: /usr/share/doc/heartbeat-2.0.5/COPYING.LGPL File conflict with: /usr/share/doc/heartbeat-2.0.5/ChangeLog File conflict with: /usr/share/doc/heartbeat-2.0.5/DirectoryMap.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/GettingStarted.html File conflict with: /usr/share/doc/heartbeat-2.0.5/GettingStarted.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/HardwareGuide.html File conflict with: /usr/share/doc/heartbeat-2.0.5/HardwareGuide.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/README File conflict with: /usr/share/doc/heartbeat-2.0.5/Requirements.html File conflict with: /usr/share/doc/heartbeat-2.0.5/Requirements.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/apphbd.cf File conflict with: /usr/share/doc/heartbeat-2.0.5/authkeys File conflict with: /usr/share/doc/heartbeat-2.0.5/faqntips.html File conflict with: /usr/share/doc/heartbeat-2.0.5/faqntips.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/ha.cf File conflict with: /usr/share/doc/heartbeat-2.0.5/ha_logd.cf File conflict with: /usr/share/doc/heartbeat-2.0.5/haresources File conflict with: /usr/share/doc/heartbeat-2.0.5/heartbeat_api.html File conflict with: /usr/share/doc/heartbeat-2.0.5/heartbeat_api.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/rsync.html File conflict with: /usr/share/doc/heartbeat-2.0.5/rsync.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/startstop => Package conflicts with: heartbeat-devel - 2.0.5-2.fc6.i386 => Package conflicts with: stonith - 2.0.5-2.fc6.i386 heartbeat-devel-2.0.5-2.fc6.i386.rpm File conflict with: /usr/include/pils/generic.h File conflict with: /usr/include/pils/interface.h File conflict with: /usr/include/pils/plugin.h File conflict with: /usr/lib/libpils.so File conflict with: /usr/share/doc/heartbeat-2.0.5/AUTHORS File conflict with: /usr/share/doc/heartbeat-2.0.5/COPYING File conflict with: /usr/share/doc/heartbeat-2.0.5/COPYING.LGPL File conflict with: /usr/share/doc/heartbeat-2.0.5/ChangeLog File conflict with: /usr/share/doc/heartbeat-2.0.5/DirectoryMap.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/GettingStarted.html File conflict with: /usr/share/doc/heartbeat-2.0.5/GettingStarted.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/HardwareGuide.html File conflict with: /usr/share/doc/heartbeat-2.0.5/HardwareGuide.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/README File conflict with: /usr/share/doc/heartbeat-2.0.5/Requirements.html File conflict with: /usr/share/doc/heartbeat-2.0.5/Requirements.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/apphbd.cf File conflict with: /usr/share/doc/heartbeat-2.0.5/authkeys File conflict with: /usr/share/doc/heartbeat-2.0.5/faqntips.html File conflict with: /usr/share/doc/heartbeat-2.0.5/faqntips.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/ha.cf File conflict with: /usr/share/doc/heartbeat-2.0.5/ha_logd.cf File conflict with: /usr/share/doc/heartbeat-2.0.5/haresources File conflict with: /usr/share/doc/heartbeat-2.0.5/heartbeat_api.html File conflict with: /usr/share/doc/heartbeat-2.0.5/heartbeat_api.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/rsync.html File conflict with: /usr/share/doc/heartbeat-2.0.5/rsync.txt File conflict with: /usr/share/doc/heartbeat-2.0.5/startstop => Package conflicts with: heartbeat - 2.0.5-2.fc6.i386 => Package conflicts with: pils - 2.0.5-2.fc6.i386 itext-1.3-1jpp_8.fc5.i386.rpm File conflict with: /usr/share/doc/itext-1.3/MPL-1.1.txt File conflict with: /usr/share/doc/itext-1.3/lgpl.txt => Package conflicts with: itext-manual - 1.3-1jpp_8.fc5.i386 itext-manual-1.3-1jpp_8.fc5.i386.rpm File conflict with: /usr/share/doc/itext-1.3/MPL-1.1.txt File conflict with: /usr/share/doc/itext-1.3/lgpl.txt => Package conflicts with: itext - 1.3-1jpp_8.fc5.i386 libgnomemm26-2.14.0-1.i386.rpm File conflict with: /usr/share/doc/libgnomemm26-2.14.0/AUTHORS File conflict with: /usr/share/doc/libgnomemm26-2.14.0/COPYING File conflict with: /usr/share/doc/libgnomemm26-2.14.0/ChangeLog File conflict with: /usr/share/doc/libgnomemm26-2.14.0/INSTALL File conflict with: /usr/share/doc/libgnomemm26-2.14.0/NEWS File conflict with: /usr/share/doc/libgnomemm26-2.14.0/README => Package conflicts with: libgnomemm26-devel - 2.14.0-1.i386 libgnomemm26-devel-2.14.0-1.i386.rpm File conflict with: /usr/share/doc/libgnomemm26-2.14.0/AUTHORS File conflict with: /usr/share/doc/libgnomemm26-2.14.0/COPYING File conflict with: /usr/share/doc/libgnomemm26-2.14.0/ChangeLog File conflict with: /usr/share/doc/libgnomemm26-2.14.0/INSTALL File conflict with: /usr/share/doc/libgnomemm26-2.14.0/NEWS File conflict with: /usr/share/doc/libgnomemm26-2.14.0/README => Package conflicts with: libgnomemm26 - 2.14.0-1.i386 pils-2.0.5-2.fc6.i386.rpm File conflict with: /usr/include/pils/generic.h File conflict with: /usr/include/pils/interface.h File conflict with: /usr/include/pils/plugin.h File conflict with: /usr/lib/libpils.so File conflict with: /usr/lib/libpils.so.1 File conflict with: /usr/lib/libpils.so.1.0.0 => Package conflicts with: heartbeat-devel - 2.0.5-2.fc6.i386 => Package conflicts with: stonith - 2.0.5-2.fc6.i386 stonith-2.0.5-2.fc6.i386.rpm File conflict with: /usr/lib/libapphb.so.0 File conflict with: /usr/lib/libapphb.so.0.0.0 File conflict with: /usr/lib/libccmclient.so.1 File conflict with: /usr/lib/libccmclient.so.1.0.0 File conflict with: /usr/lib/libcib.so.1 File conflict with: /usr/lib/libcib.so.1.0.1 File conflict with: /usr/lib/libclm.so.1 File conflict with: /usr/lib/libclm.so.1.0.0 File conflict with: /usr/lib/libcrmcommon.so.1 File conflict with: /usr/lib/libcrmcommon.so.1.0.1 File conflict with: /usr/lib/libhbclient.so.1 File conflict with: /usr/lib/libhbclient.so.1.0.0 File conflict with: /usr/lib/libhbmgmt.so.0 File conflict with: /usr/lib/libhbmgmt.so.0.0.0 File conflict with: /usr/lib/libhbmgmtclient.so.0 File conflict with: /usr/lib/libhbmgmtclient.so.0.0.0 File conflict with: /usr/lib/libhbmgmtcommon.so.0 File conflict with: /usr/lib/libhbmgmtcommon.so.0.0.0 File conflict with: /usr/lib/libhbmgmttls.so.0 File conflict with: /usr/lib/libhbmgmttls.so.0.0.0 File conflict with: /usr/lib/liblrm.so.0 File conflict with: /usr/lib/liblrm.so.0.0.0 File conflict with: /usr/lib/libpengine.so.1 File conflict with: /usr/lib/libpengine.so.1.1.0 File conflict with: /usr/lib/libpils.so.1 File conflict with: /usr/lib/libpils.so.1.0.0 File conflict with: /usr/lib/libplumb.so.1 File conflict with: /usr/lib/libplumb.so.1.0.0 File conflict with: /usr/lib/libplumbgpl.so.1 File conflict with: /usr/lib/libplumbgpl.so.1.0.0 File conflict with: /usr/lib/librecoverymgr.so.1 File conflict with: /usr/lib/librecoverymgr.so.1.0.0 File conflict with: /usr/lib/libstonithd.so.0 File conflict with: /usr/lib/libstonithd.so.0.0.0 File conflict with: /usr/lib/libtransitioner.so.1 File conflict with: /usr/lib/libtransitioner.so.1.0.0 => Package conflicts with: heartbeat - 2.0.5-2.fc6.i386 => Package conflicts with: pils - 2.0.5-2.fc6.i386 wine-devel-0.9.16-1.fc6.i386.rpm File conflict with: /usr/bin/winedump File conflict with: /usr/bin/winedump File conflict with: /usr/bin/winemaker File conflict with: /usr/bin/winemaker => Package conflicts with: wine-tools - 0.9.16-1.fc6.i386 wine-tools-0.9.16-1.fc6.i386.rpm File conflict with: /usr/bin/winedump File conflict with: /usr/bin/winedump File conflict with: /usr/bin/winemaker File conflict with: /usr/bin/winemaker => Package conflicts with: wine-devel - 0.9.16-1.fc6.i386 xscreensaver-extras-5.00-13.fc6.i386.rpm File conflict with: /usr/share/man/man6/worm.6.gz => Package conflicts with: bsd-games - 2.17-13.fc6.i386 pdftohtml-0.36-7.fc5.i386.rpm File conflict with: /usr/bin/pdftohtml File conflict with: /usr/bin/pdftohtml => Package conflicts with: poppler-utils - 0.5.3-1.i386 planet-1.0-0.6.20060218pre.noarch.rpm File conflict with: /usr/bin/planet File conflict with: /usr/bin/planet => Package conflicts with: plt-scheme - 350-1.fc6.i386 x3270-3.3.4p7-2.fc6.i386.rpm File conflict with: /usr/share/man/man1/ibm_hosts.1.gz File conflict with: /usr/share/man/man1/ibm_hosts.1x.gz File conflict with: /usr/share/man/man1/x3270-script.1.gz File conflict with: /usr/share/man/man1/x3270-script.1x.gz File conflict with: /usr/share/man/man1/x3270.1x.gz File conflict with: /usr/share/man/man1/x3270if.1.gz File conflict with: /usr/share/man/man1/x3270if.1x.gz => Package conflicts with: x3270-x11 - 3.3.4p7-2.fc6.i386 x3270-x11-3.3.4p7-2.fc6.i386.rpm File conflict with: /usr/share/man/man1/c3270.1.gz File conflict with: /usr/share/man/man1/ibm_hosts.1.gz File conflict with: /usr/share/man/man1/ibm_hosts.1x.gz File conflict with: /usr/share/man/man1/x3270-script.1.gz File conflict with: /usr/share/man/man1/x3270-script.1x.gz File conflict with: /usr/share/man/man1/x3270.1x.gz File conflict with: /usr/share/man/man1/x3270if.1.gz File conflict with: /usr/share/man/man1/x3270if.1x.gz => Package conflicts with: x3270 - 3.3.4p7-2.fc6.i386 => Package conflicts with: x3270-text - 3.3.4p7-2.fc6.i386 rekall-2.4.0-4.fc5.i386.rpm File conflict with: /usr/share/apps/rekallqt/script/py/RekallMain.py File conflict with: /usr/share/apps/rekallqt/script/py/RekallMain.pyc File conflict with: /usr/share/apps/rekallqt/script/py/RekallMain.pyo File conflict with: /usr/share/apps/rekallqt/script/py/RekallPYDBI.py File conflict with: /usr/share/apps/rekallqt/script/py/RekallPYDBI.pyc File conflict with: /usr/share/apps/rekallqt/script/py/RekallPYDBI.pyo File conflict with: /usr/share/apps/rekallqt/script/py/TableData.py File conflict with: /usr/share/apps/rekallqt/script/py/TableData.pyc File conflict with: /usr/share/apps/rekallqt/script/py/TableData.pyo File conflict with: /usr/share/apps/rekallqt/script/py/TableDesignQTE.py File conflict with: /usr/share/apps/rekallqt/script/py/TableDesignQTE.pyc File conflict with: /usr/share/apps/rekallqt/script/py/TableDesignQTE.pyo File conflict with: /usr/share/apps/rekallqt/script/py/TableDesignSTD.py File conflict with: /usr/share/apps/rekallqt/script/py/TableDesignSTD.pyc File conflict with: /usr/share/apps/rekallqt/script/py/TableDesignSTD.pyo File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBChoice.py File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBChoice.pyc File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBChoice.pyo File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBField.py File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBField.pyc File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBField.pyo File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBItem.py File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBItem.pyc File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBItem.pyo File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBObject.py File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBObject.pyc File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBObject.pyo File conflict with: /usr/share/apps/rekallqt/script/py/rkScan.py File conflict with: /usr/share/apps/rekallqt/script/py/rkScan.pyc File conflict with: /usr/share/apps/rekallqt/script/py/rkScan.pyo File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Add.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Cancel.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Close.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Delete.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/First.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Last.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Next.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Previous.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Save.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Search.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/Check.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/Choice.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/Field.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/Label.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/LinkQuery.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/LinkTable.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/Memo.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/RichText.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/SpinBox.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/ExecuteCopier.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/ExecuteMacro.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/OpenForm.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/OpenLinkedForm.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/OpenLinkedReport.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/OpenQuery.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/OpenReport.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/OpenTable.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Internet/EMail_kmail.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/AmendedDate.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/CreatedDate.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/RecordPosition.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/SaveToFile.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/Searcher.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/SummaryFloat.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/SummaryInteger.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Navigation/ButtonBar.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Navigation/Selector.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/dummy File conflict with: /usr/share/doc/rekall-2.4.0/LICENSE => Package conflicts with: rekall-python - 2.4.0-4.fc5.i386 => Package conflicts with: rekall-docs - 2.4.0-4.fc5.i386 rekall-docs-2.4.0-4.fc5.i386.rpm File conflict with: /usr/share/doc/rekall-2.4.0/LICENSE => Package conflicts with: rekall - 2.4.0-4.fc5.i386 rekall-python-2.4.0-4.fc5.i386.rpm File conflict with: /usr/share/apps/rekallqt/script/py/RekallMain.py File conflict with: /usr/share/apps/rekallqt/script/py/RekallMain.pyc File conflict with: /usr/share/apps/rekallqt/script/py/RekallMain.pyo File conflict with: /usr/share/apps/rekallqt/script/py/RekallPYDBI.py File conflict with: /usr/share/apps/rekallqt/script/py/RekallPYDBI.pyc File conflict with: /usr/share/apps/rekallqt/script/py/RekallPYDBI.pyo File conflict with: /usr/share/apps/rekallqt/script/py/TableData.py File conflict with: /usr/share/apps/rekallqt/script/py/TableData.pyc File conflict with: /usr/share/apps/rekallqt/script/py/TableData.pyo File conflict with: /usr/share/apps/rekallqt/script/py/TableDesignQTE.py File conflict with: /usr/share/apps/rekallqt/script/py/TableDesignQTE.pyc File conflict with: /usr/share/apps/rekallqt/script/py/TableDesignQTE.pyo File conflict with: /usr/share/apps/rekallqt/script/py/TableDesignSTD.py File conflict with: /usr/share/apps/rekallqt/script/py/TableDesignSTD.pyc File conflict with: /usr/share/apps/rekallqt/script/py/TableDesignSTD.pyo File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBChoice.py File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBChoice.pyc File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBChoice.pyo File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBField.py File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBField.pyc File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBField.pyo File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBItem.py File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBItem.pyc File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBItem.pyo File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBObject.py File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBObject.pyc File conflict with: /usr/share/apps/rekallqt/script/py/extend/ext_KBObject.pyo File conflict with: /usr/share/apps/rekallqt/script/py/rkScan.py File conflict with: /usr/share/apps/rekallqt/script/py/rkScan.pyc File conflict with: /usr/share/apps/rekallqt/script/py/rkScan.pyo File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Add.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Cancel.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Close.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Delete.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/First.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Last.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Next.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Previous.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Save.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Buttons/Search.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/Check.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/Choice.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/Field.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/Label.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/LinkQuery.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/LinkTable.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/Memo.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/RichText.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Controls/SpinBox.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/ExecuteCopier.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/ExecuteMacro.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/OpenForm.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/OpenLinkedForm.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/OpenLinkedReport.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/OpenQuery.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/OpenReport.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Execute/OpenTable.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Internet/EMail_kmail.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/AmendedDate.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/CreatedDate.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/RecordPosition.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/SaveToFile.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/Searcher.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/SummaryFloat.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Miscellaneous/SummaryInteger.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Navigation/ButtonBar.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/Navigation/Selector.cmp File conflict with: /usr/share/apps/rekallqt/stock/component/py/dummy => Package conflicts with: rekall - 2.4.0-4.fc5.i386 koffice-devel-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/libkdeinit_karbon.so File conflict with: /usr/lib/libkdeinit_kchart.so File conflict with: /usr/lib/libkdeinit_kexi.so File conflict with: /usr/lib/libkdeinit_kformula.so File conflict with: /usr/lib/libkdeinit_kivio.so File conflict with: /usr/lib/libkdeinit_koshell.so File conflict with: /usr/lib/libkdeinit_kplato.so File conflict with: /usr/lib/libkdeinit_kpresenter.so File conflict with: /usr/lib/libkdeinit_krita.so File conflict with: /usr/lib/libkdeinit_kspread.so File conflict with: /usr/lib/libkdeinit_kthesaurus.so File conflict with: /usr/lib/libkdeinit_kudesigner.so File conflict with: /usr/lib/libkdeinit_kugar.so File conflict with: /usr/lib/libkdeinit_kword.so File conflict with: /usr/lib/libkudesignercore.so => Package conflicts with: koffice-kspread - 1.5.1-2.fc6.i386 => Package conflicts with: koffice-kivio - 1.5.1-2.fc6.i386 => Package conflicts with: koffice-kpresenter - 1.5.1-2.fc6.i386 => Package conflicts with: koffice-kexi - 1.5.1-2.fc6.i386 => Package conflicts with: koffice-kugar - 1.5.1-2.fc6.i386 => Package conflicts with: koffice-kword - 1.5.1-2.fc6.i386 => Package conflicts with: koffice-core - 1.5.1-2.fc6.i386 => Package conflicts with: koffice-karbon - 1.5.1-2.fc6.i386 => Package conflicts with: koffice-kchart - 1.5.1-2.fc6.i386 => Package conflicts with: koffice-krita - 1.5.1-2.fc6.i386 => Package conflicts with: koffice-kplato - 1.5.1-2.fc6.i386 x3270-text-3.3.4p7-2.fc6.i386.rpm File conflict with: /usr/share/man/man1/c3270.1.gz => Package conflicts with: x3270-x11 - 3.3.4p7-2.fc6.i386 koffice-kspread-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/libkdeinit_kspread.so => Package conflicts with: koffice-devel - 1.5.1-2.fc6.i386 synce-0.9.1-7.fc5.i386.rpm File conflict with: /usr/lib/libmimedir.so => Package conflicts with: synce-devel - 0.9.1-7.fc5.i386 synce-devel-0.9.1-7.fc5.i386.rpm File conflict with: /usr/lib/libmimedir.so => Package conflicts with: synce - 0.9.1-7.fc5.i386 koffice-krita-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/libkdeinit_krita.so => Package conflicts with: koffice-devel - 1.5.1-2.fc6.i386 koffice-kword-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/libkdeinit_kword.so => Package conflicts with: koffice-devel - 1.5.1-2.fc6.i386 koffice-core-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/libkdeinit_kformula.so File conflict with: /usr/lib/libkdeinit_koshell.so File conflict with: /usr/lib/libkdeinit_kthesaurus.so => Package conflicts with: koffice-devel - 1.5.1-2.fc6.i386 koffice-kplato-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/libkdeinit_kplato.so => Package conflicts with: koffice-devel - 1.5.1-2.fc6.i386 koffice-kivio-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/libkdeinit_kivio.so => Package conflicts with: koffice-devel - 1.5.1-2.fc6.i386 koffice-kchart-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/libkdeinit_kchart.so => Package conflicts with: koffice-devel - 1.5.1-2.fc6.i386 koffice-karbon-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/libkdeinit_karbon.so => Package conflicts with: koffice-devel - 1.5.1-2.fc6.i386 koffice-kugar-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/libkdeinit_kudesigner.so File conflict with: /usr/lib/libkdeinit_kugar.so File conflict with: /usr/lib/libkudesignercore.so => Package conflicts with: koffice-devel - 1.5.1-2.fc6.i386 koffice-kpresenter-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/kde3/kformula.la File conflict with: /usr/lib/kde3/kformula.so File conflict with: /usr/lib/libkdeinit_kpresenter.so => Package conflicts with: koffice-kformula - 1.5.1-2.fc6.i386 => Package conflicts with: koffice-devel - 1.5.1-2.fc6.i386 koffice-kexi-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/libkdeinit_kexi.so => Package conflicts with: koffice-devel - 1.5.1-2.fc6.i386 koffice-kformula-1.5.1-2.fc6.i386.rpm File conflict with: /usr/lib/kde3/kformula.la File conflict with: /usr/lib/kde3/kformula.so => Package conflicts with: koffice-kpresenter - 1.5.1-2.fc6.i386 uuid-devel-1.4.2-4.fc6.i386.rpm File conflict with: /usr/lib/libuuid.so File conflict with: /usr/lib/pkgconfig/uuid.pc File conflict with: /usr/share/man/man3/uuid.3.gz => Package conflicts with: e2fsprogs-devel - 1.39-2.i386 uw-imap-2004g-4.fc5.2.i386.rpm File conflict with: /etc/pam.d/imap File conflict with: /etc/pam.d/imap File conflict with: /etc/pam.d/pop File conflict with: /etc/pam.d/pop File conflict with: /usr/share/man/man8/imapd.8.gz => Package conflicts with: cyrus-imapd - 2.3.1-2.6.fc5.i386 uw-imap-devel-2004g-4.fc5.2.i386.rpm File conflict with: /usr/include/imap/c-client.h File conflict with: /usr/include/imap/dummy.h File conflict with: /usr/include/imap/env.h File conflict with: /usr/include/imap/env_unix.h File conflict with: /usr/include/imap/fdstring.h File conflict with: /usr/include/imap/flockcyg.h File conflict with: /usr/include/imap/flocksim.h File conflict with: /usr/include/imap/flstring.h File conflict with: /usr/include/imap/fs.h File conflict with: /usr/include/imap/ftl.h File conflict with: /usr/include/imap/imap4r1.h File conflict with: /usr/include/imap/linkage.c File conflict with: /usr/include/imap/linkage.h File conflict with: /usr/include/imap/mail.h File conflict with: /usr/include/imap/mbx.h File conflict with: /usr/include/imap/mh.h File conflict with: /usr/include/imap/misc.h File conflict with: /usr/include/imap/mx.h File conflict with: /usr/include/imap/netmsg.h File conflict with: /usr/include/imap/newsrc.h File conflict with: /usr/include/imap/nl.h File conflict with: /usr/include/imap/nntp.h File conflict with: /usr/include/imap/os_a32.h File conflict with: /usr/include/imap/os_a41.h File conflict with: /usr/include/imap/os_aix.h File conflict with: /usr/include/imap/os_aos.h File conflict with: /usr/include/imap/os_art.h File conflict with: /usr/include/imap/os_asv.h File conflict with: /usr/include/imap/os_aux.h File conflict with: /usr/include/imap/os_bsd.h File conflict with: /usr/include/imap/os_bsf.h File conflict with: /usr/include/imap/os_bsi.h File conflict with: /usr/include/imap/os_cvx.h File conflict with: /usr/include/imap/os_cyg.h File conflict with: /usr/include/imap/os_d-g.h File conflict with: /usr/include/imap/os_do4.h File conflict with: /usr/include/imap/os_drs.h File conflict with: /usr/include/imap/os_dyn.h File conflict with: /usr/include/imap/os_hpp.h File conflict with: /usr/include/imap/os_isc.h File conflict with: /usr/include/imap/os_lnx.h File conflict with: /usr/include/imap/os_lyn.h File conflict with: /usr/include/imap/os_mct.h File conflict with: /usr/include/imap/os_mnt.h File conflict with: /usr/include/imap/os_nto.h File conflict with: /usr/include/imap/os_nxt.h File conflict with: /usr/include/imap/os_os4.h File conflict with: /usr/include/imap/os_osf.h File conflict with: /usr/include/imap/os_osx.h File conflict with: /usr/include/imap/os_ptx.h File conflict with: /usr/include/imap/os_pyr.h File conflict with: /usr/include/imap/os_qnx.h File conflict with: /usr/include/imap/os_s40.h File conflict with: /usr/include/imap/os_sc5.h File conflict with: /usr/include/imap/os_sco.h File conflict with: /usr/include/imap/os_sgi.h File conflict with: /usr/include/imap/os_shp.h File conflict with: /usr/include/imap/os_slx.h File conflict with: /usr/include/imap/os_soln.h File conflict with: /usr/include/imap/os_solo.h File conflict with: /usr/include/imap/os_sos.h File conflict with: /usr/include/imap/os_sun.h File conflict with: /usr/include/imap/os_sv2.h File conflict with: /usr/include/imap/os_sv4.h File conflict with: /usr/include/imap/os_ult.h File conflict with: /usr/include/imap/os_vu2.h File conflict with: /usr/include/imap/osdep.h File conflict with: /usr/include/imap/pseudo.h File conflict with: /usr/include/imap/rfc822.h File conflict with: /usr/include/imap/shortsym.h File conflict with: /usr/include/imap/smtp.h File conflict with: /usr/include/imap/sslio.h File conflict with: /usr/include/imap/tcp.h File conflict with: /usr/include/imap/tcp_unix.h File conflict with: /usr/include/imap/unix.h File conflict with: /usr/include/imap/utf8.h File conflict with: /usr/lib/c-client.a File conflict with: /usr/lib/libc-client.a File conflict with: /usr/lib/libc-client.so => All file names in this package are found in the repository elsewhere! => Package conflicts with: libc-client-devel - 2004g-2.2.i386 wxPython-2.6.3.2-1.fc6.i386.rpm File conflict with: /usr/bin/pyalacarte File conflict with: /usr/bin/pyalacarte File conflict with: /usr/bin/pyalamode File conflict with: /usr/bin/pyalamode File conflict with: /usr/bin/pycrust File conflict with: /usr/bin/pycrust File conflict with: /usr/bin/pyshell File conflict with: /usr/bin/pyshell File conflict with: /usr/bin/pywrap File conflict with: /usr/bin/pywrap => Package conflicts with: compat-wxPythonGTK2 - 2.4.2.4-11.fc6.i386 syslog-ng-1.6.11-2.fc6.i386.rpm File conflict with: /etc/logrotate.d/syslog File conflict with: /etc/logrotate.d/syslog => Package conflicts with: sysklogd - 1.4.1-39.i386 munin-node-1.2.4-9.fc6.noarch.rpm File conflict with: /usr/share/doc/munin-1.2.4/COPYING => Package conflicts with: munin - 1.2.4-9.fc6.noarch munin-1.2.4-9.fc6.noarch.rpm File conflict with: /usr/share/doc/munin-1.2.4/COPYING => Package conflicts with: munin-node - 1.2.4-9.fc6.noarch libxfcegui4-4.2.3-5.fc6.i386.rpm File conflict with: /usr/lib/libxfcegui4.so => Package conflicts with: libxfcegui4-devel - 4.2.3-5.fc6.i386 libxfcegui4-devel-4.2.3-5.fc6.i386.rpm File conflict with: /usr/lib/libxfcegui4.so => Package conflicts with: libxfcegui4 - 4.2.3-5.fc6.i386 plt-scheme-350-1.fc6.i386.rpm File conflict with: /usr/bin/planet File conflict with: /usr/bin/planet => Package conflicts with: planet - 1.0-0.6.20060218pre.noarch allegro-4.2.0-15.fc6.i386.rpm File conflict with: /usr/lib/liballeg-4.2.0.so File conflict with: /usr/lib/liballeg.so.4.2 => Package conflicts with: allegro-devel - 4.2.0-15.fc6.i386 allegro-devel-4.2.0-15.fc6.i386.rpm File conflict with: /usr/lib/liballeg-4.2.0.so File conflict with: /usr/lib/liballeg.so.4.2 => Package conflicts with: allegro - 4.2.0-15.fc6.i386 From tibbs at math.uh.edu Tue Jul 11 15:24:51 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 11 Jul 2006 10:24:51 -0500 Subject: rpms/perl-Image-ExifTool/devel perl-Image-ExifTool-avoidtheworduse.patch, NONE, 1.1 perl-Image-ExifTool.spec, 1.5, 1.6 In-Reply-To: <200607111345.k6BDj3bv026866@cvs-int.fedora.redhat.com> (Tom Callaway's message of "Tue, 11 Jul 2006 06:45:01 -0700") References: <200607111345.k6BDj3bv026866@cvs-int.fedora.redhat.com> Message-ID: >>>>> "TC" == Tom Callaway <(spot) > writes: TC> Fix this package so it doesn't grab "perl(the)" as a false dep. Wow, by patching out every instance of the word "use" in the source. - } elsif ($format eq 'int16u') { # use the offset as the value + } elsif ($format eq 'int16u') { # choose the offset as the value Scary. Which brings up a couple of questions: *) Why not just use a dependency filter instead of hacking the source? That patch will have to be redone everytime the source changes. *) Are of these changes are really necessary? Surely the dependency generator skips PODs and comments. I'd be truly concerned if it doesn't. - J< From wart at kobold.org Tue Jul 11 15:33:57 2006 From: wart at kobold.org (Wart) Date: Tue, 11 Jul 2006 08:33:57 -0700 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20060711171508.2ba36dd1.bugs.michael@gmx.net> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> Message-ID: <44B3C4E5.2060806@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > No further comment at this point. > > [...] > > bsd-games-2.17-13.fc6.i386.rpm > File conflict with: /usr/share/man/man6/worm.6.gz > => Package conflicts with: xscreensaver-extras - 1:5.00-13.fc6.i386 This is a known issue. Bugs have been filed against both packages. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197465 > xscreensaver-extras-5.00-13.fc6.i386.rpm > File conflict with: /usr/share/man/man6/worm.6.gz > => Package conflicts with: bsd-games - 2.17-13.fc6.i386 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197741 - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEs8TjDeYlPfs40g8RApo2AJ4rkYqb7wDDEGLPhsWbHuXMR6DWOgCcCB98 aB2E+OrJgYJpnY8Bi6BOIWA= =LC8W -----END PGP SIGNATURE----- From rc040203 at freenet.de Tue Jul 11 15:48:23 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 11 Jul 2006 17:48:23 +0200 Subject: rpms/perl-Image-ExifTool/devel perl-Image-ExifTool-avoidtheworduse.patch, NONE, 1.1 perl-Image-ExifTool.spec, 1.5, 1.6 In-Reply-To: References: <200607111345.k6BDj3bv026866@cvs-int.fedora.redhat.com> Message-ID: <1152632903.4569.43.camel@mccallum.corsepiu.local> On Tue, 2006-07-11 at 10:24 -0500, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom Callaway <(spot) > writes: > > TC> Fix this package so it doesn't grab "perl(the)" as a false dep. > > Wow, by patching out every instance of the word "use" in the source. > > - } elsif ($format eq 'int16u') { # use the offset as the value > + } elsif ($format eq 'int16u') { # choose the offset as the value > > Scary. Which brings up a couple of questions: > > *) Why not just use a dependency filter instead of hacking the source? > That patch will have to be redone everytime the source changes. +1. This patch means playing with symptoms without providing a cure (fix rpm's dep generators) nor permanent relief (filtering) > *) Are of these changes are really necessary? AFAIS, nope: The culprit seems to be rpm is failing on one single file: --- lib/Image/ExifTool/MIE.pm~ 2006-07-11 17:31:15.000000000 +0200 +++ lib/Image/ExifTool/MIE.pm 2006-07-11 17:31:15.000000000 +0200 @@ -145,7 +145,7 @@ DNG, EPS, ERF, GIF, ICC, JNG, JP2, JPEG, MIE, MIFF, MNG, MOS, MOV, MP3, MP4, MPEG, MRW, NEF, ORF, PBM, PDF, PGM, PICT, PNG, PPM, PS, PSD, QTIF, RAF, RAW, RIFF, SR2, SRF, TIFF, WAV, WMA, WMV, X3F and XMP. Other types should simply - use the common file extension. + apply the common file extension. }, }, '1Directory' => { Name => 'SubfileDirectory' }, Ralf From jpo at lsd.di.uminho.pt Tue Jul 11 16:54:57 2006 From: jpo at lsd.di.uminho.pt (Jose Pedro Oliveira) Date: Tue, 11 Jul 2006 17:54:57 +0100 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20060711171508.2ba36dd1.bugs.michael@gmx.net> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> Message-ID: <44B3D7E1.4060008@lsd.di.uminho.pt> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > No further comment at this point. > > [...] > > syslog-ng-1.6.11-2.fc6.i386.rpm > File conflict with: /etc/logrotate.d/syslog > File conflict with: /etc/logrotate.d/syslog > => Package conflicts with: sysklogd - 1.4.1-39.i386 This is a false positive. The /etc/logrotate.d/syslog file shipped in syslog-ng is exactly the same as the one shipped in the core sysklogd package. The files having the same MD5 signature don't cause a conflict. Further information available in: https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00337.html jpo - -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEs9fhl0metZG9hRsRArlNAKDwFmhYZOxF8e031wHQz8Xr8/GoNQCgkbAM 16wEp+dYtp3HwJcDTl71OXs= =DrL9 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From fedora at leemhuis.info Tue Jul 11 16:06:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 11 Jul 2006 18:06:32 +0200 Subject: What do Extras contributors use the wiki for? In-Reply-To: <200607110151.40708.nman64@n-man.com> References: <200607091503.16790.nman64@n-man.com> <200607110104.58304.nman64@n-man.com> <44B34530.8000605@leemhuis.info> <200607110151.40708.nman64@n-man.com> Message-ID: <44B3CC88.6040706@leemhuis.info> Patrick W. Barnes schrieb: > On Tuesday 11 July 2006 01:29, Thorsten Leemhuis wrote: >> Patrick W. Barnes schrieb: >>> On Monday 10 July 2006 11:12, Michael Schwendt > wrote: >>>> On Sun, 9 Jul 2006 15:03:12 -0500, Patrick W. Barnes wrote: >>>> Why should the FCx Status pages, the User Registry, the Orphaned >>>> Packages List be opened up to non-Contributors? >>> The objective is to remove the EditGroup requirement, allowing Extras >>> contributors to work without having to obtain EditGroup membership. >> Just a note: I don't like that goal to much. I'd prefer if all Extras >> contributors get automatically access to the wiki (and used to edit it) >> so they are able to improve the Documentation around Extras if they want >> to (without having to take other hurdles first). > In this case, at least three things need to happen: [...] >[...] > If the Infrastructure team accomplishes all of its goals (which will take > time), then this entire issue will become obsolete, as wiki edit access would > be integrated with the Account System, and anyone who has completed the CLA > would automatically gain editing permissions. I think I prefer if it stays at it is -- it might take "some time" until the "Infrastructure team accomplishes all of its goals", but I think we can live with the current state. Or do other disagree? Then let's do what Patrick suggested. CU thl From steve at silug.org Tue Jul 11 16:32:35 2006 From: steve at silug.org (Steven Pritchard) Date: Tue, 11 Jul 2006 11:32:35 -0500 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20060711171508.2ba36dd1.bugs.michael@gmx.net> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> Message-ID: <20060711163235.GA8910@osiris.silug.org> On Tue, Jul 11, 2006 at 05:15:08PM +0200, Michael Schwendt wrote: > uuid-devel-1.4.2-4.fc6.i386.rpm > File conflict with: /usr/lib/libuuid.so > File conflict with: /usr/lib/pkgconfig/uuid.pc > File conflict with: /usr/share/man/man3/uuid.3.gz > => Package conflicts with: e2fsprogs-devel - 1.39-2.i386 Ugh. I can't imagine how I missed that. I opened #198520 as a reminder while I figure out a good way to fix that. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From cvwright at jhu.edu Tue Jul 11 17:06:45 2006 From: cvwright at jhu.edu (Charles V Wright) Date: Tue, 11 Jul 2006 13:06:45 -0400 Subject: VTK anyone? In-Reply-To: <44B27321.4060809@cora.nwra.com> References: <20060710144436.GB5455@free.fr> <44B27321.4060809@cora.nwra.com> Message-ID: <44B3DAA5.4050506@jhu.edu> Orion Poplawski wrote: > Gianluca Sforna wrote: >> On 7/10/06, Patrice Dumas wrote: >>> >>> Maybe you could have a look at paraview, allready included in fedora >>> extras >>> (and maintained by Orion) since it has an included version of vtk (last >>> time it seemed to be a more recent version than the current vtk, >>> that's why >>> I didn't block paraview although it included vtk as a private library). >> Yap, I found that while looking for references to vtk in bugzilla. >> The version I am working on is 5.0.0, I don't know if it's the same as >> paraview use, but there will be something to learn for sure... >> > > I've been slowly working on a version. Latest spec and srpm are at > http://www.cora.nwra.com/~orion/fedora/. I believe the problem I'm > having currently is getting some of the examples to compile. > > I'd be happy to let someone else maintain it though :-). > > > Fabrice Bellet has a pretty nice spec file for VTK 5. If you guys haven't seen it yet, it might be a good place to start from. The SRPM is ftp://fr2.rpmfind.net/linux/local/fedora/5/SRPMS/vtk-5.0.0-6.src.rpm It builds pretty happily in mock, has several subpackages for python, etc, and in general seems to work pretty well for me on FC5. I'd love to see VTK in extras, so if there's anything I can do to help, please let me know. -charles From duncan_j_ferguson at yahoo.co.uk Tue Jul 11 17:18:47 2006 From: duncan_j_ferguson at yahoo.co.uk (Duncan Ferguson) Date: Tue, 11 Jul 2006 18:18:47 +0100 Subject: Advice on desktop icons In-Reply-To: <1152558704.7269.42.camel@rousalka.dyndns.org> References: <1152552634.3123.2.camel@queeg> <44B29E35.80301@kobold.org> <1152557493.3123.7.camel@queeg> <1152558704.7269.42.camel@rousalka.dyndns.org> Message-ID: <1152638327.3123.9.camel@queeg> On Mon, 2006-07-10 at 21:11 +0200, Nicolas Mailhot wrote: > Le lundi 10 juillet 2006 ?? 19:51 +0100, Duncan Ferguson a ??crit : > Ideally you should : > > * provide the full size range array : > 16x16 22x22 24x24 32x32 36x36 48x48 64x64 72x72 96x96 128x128 192x192 > (and not auto-scaled stuff - if it's to scale bitmaps in the Gimp > without human intervention gtk can do it without your help thank you > very much. If you provide different sizes that means you actually did > some work so your scaled versions display better than auto-scaled ones) > > * and a scalable svg version > > * and do it for all the major icon themes (meaning you decline your icon > following the style of every one of these themes Ok, so if i want to provide more than one icon, how to i cater for that in the spec file? Thanks Duncs ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" ? The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html From ville.skytta at iki.fi Tue Jul 11 17:32:56 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 11 Jul 2006 20:32:56 +0300 Subject: File conflicts in Fedora Extras Development In-Reply-To: <44B3D7E1.4060008@lsd.di.uminho.pt> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <44B3D7E1.4060008@lsd.di.uminho.pt> Message-ID: <1152639176.2728.581.camel@localhost.localdomain> On Tue, 2006-07-11 at 17:54 +0100, Jose Pedro Oliveira wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael Schwendt wrote: > > No further comment at this point. :) > > [...] > > > > syslog-ng-1.6.11-2.fc6.i386.rpm > > File conflict with: /etc/logrotate.d/syslog > > File conflict with: /etc/logrotate.d/syslog > > => Package conflicts with: sysklogd - 1.4.1-39.i386 > > This is a false positive. Here's another one: > wine-tools-0.9.16-1.fc6.i386.rpm > File conflict with: /usr/bin/winedump > File conflict with: /usr/bin/winedump > File conflict with: /usr/bin/winemaker > File conflict with: /usr/bin/winemaker > => Package conflicts with: wine-devel - 0.9.16-1.fc6.i386 At least on FC5, there doesn't seem to be a conflict. Nevertheless, depending on the case (not referring to wine*), these false positives may indicate other packaging bugs/thinkos. From helge.hess at opengroupware.org Tue Jul 11 17:36:05 2006 From: helge.hess at opengroupware.org (Helge Hess) Date: Tue, 11 Jul 2006 19:36:05 +0200 Subject: opengroupware for FE In-Reply-To: <20060711114508.GG9010@neu.nirvana> References: <1152015375.30969.315.camel@xpc.home.erwinrol.com> <20060704124345.GB18364@neu.nirvana> <31CC21BD-B8A9-4A7B-96E7-1A6737656858@opengroupware.org> <20060705102330.GF1419@neu.nirvana> <1152096783.30969.328.camel@xpc.home.erwinrol.com> <20060705110040.GH1419@neu.nirvana> <20060711091520.GE9010@neu.nirvana> <20060711114508.GG9010@neu.nirvana> Message-ID: On Jul 11, 2006, at 13:45, Axel Thimm wrote: > OK, then how about having gnustep-make default to gnu-gnu-gnu, e.g. be > gnustepish and pass the gnu-fd-nil combo for the further builds? We > also got rid of libobjc-fd2, so we can make everybody happy. Fine for me if it actually works ;-) Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From tibbs at math.uh.edu Tue Jul 11 17:38:58 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 11 Jul 2006 12:38:58 -0500 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20060711163235.GA8910@osiris.silug.org> (Steven Pritchard's message of "Tue, 11 Jul 2006 11:32:35 -0500") References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <20060711163235.GA8910@osiris.silug.org> Message-ID: >>>>> "SP" == Steven Pritchard writes: SP> Ugh. I can't imagine how I missed that. Hmm, I wonder how this can be checked easily by a reviewer. I reviewed said package but had pretty much no chance of noticing this. - J< From duncan_j_ferguson at yahoo.co.uk Tue Jul 11 17:56:10 2006 From: duncan_j_ferguson at yahoo.co.uk (Duncan Ferguson) Date: Tue, 11 Jul 2006 18:56:10 +0100 Subject: Advice on desktop icons In-Reply-To: <1152638327.3123.9.camel@queeg> References: <1152552634.3123.2.camel@queeg> <44B29E35.80301@kobold.org> <1152557493.3123.7.camel@queeg> <1152558704.7269.42.camel@rousalka.dyndns.org> <1152638327.3123.9.camel@queeg> Message-ID: <1152640570.3123.13.camel@queeg> On Tue, 2006-07-11 at 18:18 +0100, Duncan Ferguson wrote: > Ok, so if i want to provide more than one icon, how to i cater for that > in the spec file? > > Thanks > > Duncs Following on from Michael's suggestion, can I modify it slightly and use a SourceX for each png and then use the following in the install section (assuming in this case that Source4= 48x48 and Source5= 32x32)? --- mkdir -p $RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/48x48/apps/ install -p -m 644 %{SOURCE4} \ $RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/48x48/apps/%{name}.png mkdir -p $RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/32x32/apps/ install -p -m 644 %{SOURCE5} \ $RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/32x32/apps/%{name}.png --- or is there another way? Thanks Duncs ___________________________________________________________ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html From wart at kobold.org Tue Jul 11 18:17:10 2006 From: wart at kobold.org (Michael Thomas) Date: Tue, 11 Jul 2006 11:17:10 -0700 Subject: Advice on desktop icons In-Reply-To: <1152640570.3123.13.camel@queeg> References: <1152552634.3123.2.camel@queeg> <44B29E35.80301@kobold.org> <1152557493.3123.7.camel@queeg> <1152558704.7269.42.camel@rousalka.dyndns.org> <1152638327.3123.9.camel@queeg> <1152640570.3123.13.camel@queeg> Message-ID: <44B3EB26.5020701@kobold.org> Duncan Ferguson wrote: > On Tue, 2006-07-11 at 18:18 +0100, Duncan Ferguson wrote: > >>Ok, so if i want to provide more than one icon, how to i cater for that >>in the spec file? >> >>Thanks >> >> Duncs > > > Following on from Michael's suggestion, can I modify it slightly and use > a SourceX for each png and then use the following in the install section > (assuming in this case that Source4= 48x48 and Source5= 32x32)? > > --- > mkdir -p $RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/48x48/apps/ > install -p -m 644 %{SOURCE4} \ > $RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/48x48/apps/%{name}.png > mkdir -p $RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/32x32/apps/ > install -p -m 644 %{SOURCE5} \ > $RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/32x32/apps/%{name}.png > --- > > or is there another way? That seems perfectly reasonable to me. --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From notting at redhat.com Tue Jul 11 18:46:16 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Jul 2006 14:46:16 -0400 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20060711171508.2ba36dd1.bugs.michael@gmx.net> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> Message-ID: <20060711184616.GC24154@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > gnumeric-1.6.3-2.fc6.i386.rpm > File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl > => Package conflicts with: gnumeric-devel - 1:1.6.3-2.fc6.i386 > > gnumeric-devel-1.6.3-2.fc6.i386.rpm > File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl > => All file names in this package are found in the repository elsewhere! > => Package conflicts with: gnumeric - 1:1.6.3-2.fc6.i386 How can it conflict with it's own *subpackage*? (See also, heartbeat.) Bill From mtasaka at ioa.s.u-tokyo.ac.jp Tue Jul 11 19:05:52 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 12 Jul 2006 04:05:52 +0900 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20060711184616.GC24154@nostromo.devel.redhat.com> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <20060711184616.GC24154@nostromo.devel.redhat.com> Message-ID: <44B3F690.6010105@ioa.s.u-tokyo.ac.jp> Bill Nottingham wrote: > Michael Schwendt (bugs.michael at gmx.net) said: >> gnumeric-1.6.3-2.fc6.i386.rpm >> File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl >> => Package conflicts with: gnumeric-devel - 1:1.6.3-2.fc6.i386 >> >> gnumeric-devel-1.6.3-2.fc6.i386.rpm >> File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl >> => All file names in this package are found in the repository elsewhere! >> => Package conflicts with: gnumeric - 1:1.6.3-2.fc6.i386 > > How can it conflict with it's own *subpackage*? (See also, heartbeat.) > > Bill > Seems strange, however, this (gnumeric) actually conflicts with gnumeric-devel. # rpm -qlp gnumeric-*rpm | sort | uniq -D /usr/share/gnumeric/1.6.3/idl /usr/share/gnumeric/1.6.3/idl /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl This is true for heartbeat. From ianburrell at gmail.com Tue Jul 11 19:12:42 2006 From: ianburrell at gmail.com (Ian Burrell) Date: Tue, 11 Jul 2006 12:12:42 -0700 Subject: gal and oaf for FE In-Reply-To: <1152564448.24981.7.camel@T7.Linux> References: <1152525036.16965.28.camel@mrwibble.mrwobble> <20060710125924.55b817b0.bugs.michael@gmx.net> <20060710191011.GC13423@nostromo.devel.redhat.com> <1152562780.5120.2.camel@laurel.intra.city-fan.org> <1152564448.24981.7.camel@T7.Linux> Message-ID: On 7/10/06, Paul wrote: > > As it happens, it turns out that gnome-build needs neither gal nor oaf > > anyway. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182320 > > True, but there are probably a few other apps that need them. The offer > is there... > I suspect apps that need the Gnome 1 libraries are pretty rare. The last one I know about is Gnucash which just released version 2.0.0 which uses Gnome 2 and will hopefully get into FC6. I would wait until somebody actually needs the packages. - Ian From bugs.michael at gmx.net Tue Jul 11 19:23:09 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 11 Jul 2006 21:23:09 +0200 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20060711184616.GC24154@nostromo.devel.redhat.com> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <20060711184616.GC24154@nostromo.devel.redhat.com> Message-ID: <20060711212309.b1f14137.bugs.michael@gmx.net> On Tue, 11 Jul 2006 14:46:16 -0400, Bill Nottingham wrote: > > gnumeric-1.6.3-2.fc6.i386.rpm > > File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl > > => Package conflicts with: gnumeric-devel - 1:1.6.3-2.fc6.i386 > > > > gnumeric-devel-1.6.3-2.fc6.i386.rpm > > File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl > > => All file names in this package are found in the repository elsewhere! > > => Package conflicts with: gnumeric - 1:1.6.3-2.fc6.i386 > > How can it conflict with it's own *subpackage*? (See also, heartbeat.) Sloppy packaging, creating a -devel sub-package for a file which is already included in the main package. Call it "soft conflict" if you like to. And wrt heartbeat/pils/stonith there are other forms of weird packaging going on in there, looks like an attempt at creating multiple alternative package sets without moving shared files into a "common" package. Food for the Packaging Group whether we want things like that in FE. From notting at redhat.com Tue Jul 11 19:30:22 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Jul 2006 15:30:22 -0400 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20060711212309.b1f14137.bugs.michael@gmx.net> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <20060711184616.GC24154@nostromo.devel.redhat.com> <20060711212309.b1f14137.bugs.michael@gmx.net> Message-ID: <20060711193022.GB24737@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > On Tue, 11 Jul 2006 14:46:16 -0400, Bill Nottingham wrote: > > > > gnumeric-1.6.3-2.fc6.i386.rpm > > > File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl > > > => Package conflicts with: gnumeric-devel - 1:1.6.3-2.fc6.i386 > > > > > > gnumeric-devel-1.6.3-2.fc6.i386.rpm > > > File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl > > > => All file names in this package are found in the repository elsewhere! > > > => Package conflicts with: gnumeric - 1:1.6.3-2.fc6.i386 > > > > How can it conflict with it's own *subpackage*? (See also, heartbeat.) > > Sloppy packaging, creating a -devel sub-package for a file which is > already included in the main package. > > Call it "soft conflict" if you like to. So these are common files, not necessarily 'file conflicts'? Bill From paul at city-fan.org Tue Jul 11 20:18:39 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 11 Jul 2006 21:18:39 +0100 Subject: gal and oaf for FE In-Reply-To: References: <1152525036.16965.28.camel@mrwibble.mrwobble> <20060710125924.55b817b0.bugs.michael@gmx.net> <20060710191011.GC13423@nostromo.devel.redhat.com> <1152562780.5120.2.camel@laurel.intra.city-fan.org> <1152564448.24981.7.camel@T7.Linux> Message-ID: <1152649119.3135.7.camel@laurel.intra.city-fan.org> On Tue, 2006-07-11 at 12:12 -0700, Ian Burrell wrote: > On 7/10/06, Paul wrote: > > > As it happens, it turns out that gnome-build needs neither gal nor oaf > > > anyway. > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182320 > > > > True, but there are probably a few other apps that need them. The offer > > is there... > > > > I suspect apps that need the Gnome 1 libraries are pretty rare. The > last one I know about is Gnucash which just released version 2.0.0 > which uses Gnome 2 and will hopefully get into FC6. That's quite likely: from today's rawhide report: gnucash-2.0.0-1 --------------- * Mon Jul 10 2006 Bill Nottingham - 2.0.0-1 - update to 2.0.0. Woo. > I would wait until somebody actually needs the packages. So would I. Paul. From bugs.michael at gmx.net Tue Jul 11 20:20:44 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 11 Jul 2006 22:20:44 +0200 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20060711193022.GB24737@nostromo.devel.redhat.com> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <20060711184616.GC24154@nostromo.devel.redhat.com> <20060711212309.b1f14137.bugs.michael@gmx.net> <20060711193022.GB24737@nostromo.devel.redhat.com> Message-ID: <20060711222044.b11ca5db.bugs.michael@gmx.net> On Tue, 11 Jul 2006 15:30:22 -0400, Bill Nottingham wrote: > > On Tue, 11 Jul 2006 14:46:16 -0400, Bill Nottingham wrote: > > > > > > gnumeric-1.6.3-2.fc6.i386.rpm > > > > File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl > > > > => Package conflicts with: gnumeric-devel - 1:1.6.3-2.fc6.i386 > > > > > > > > gnumeric-devel-1.6.3-2.fc6.i386.rpm > > > > File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl > > > > => All file names in this package are found in the repository elsewhere! > > > > => Package conflicts with: gnumeric - 1:1.6.3-2.fc6.i386 > > > > > > How can it conflict with it's own *subpackage*? (See also, heartbeat.) > > > > Sloppy packaging, creating a -devel sub-package for a file which is > > already included in the main package. > > > > Call it "soft conflict" if you like to. > > So these are common files, not necessarily 'file conflicts'? In the case of gnumeric/gnumeric-devel, yes. In other cases they are real conflicts. Whether the files are exactly the same (not just in checksum, but also in uid/gid and mode) will need more automation. From rdieter at math.unl.edu Tue Jul 11 20:42:50 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 11 Jul 2006 15:42:50 -0500 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20060711184616.GC24154@nostromo.devel.redhat.com> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <20060711184616.GC24154@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Michael Schwendt (bugs.michael at gmx.net) said: >> gnumeric-1.6.3-2.fc6.i386.rpm >> File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl >> => Package conflicts with: gnumeric-devel - 1:1.6.3-2.fc6.i386 >> >> gnumeric-devel-1.6.3-2.fc6.i386.rpm >> File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl >> => All file names in this package are found in the repository elsewhere! >> => Package conflicts with: gnumeric - 1:1.6.3-2.fc6.i386 > > How can it conflict with it's own *subpackage*? (See also, heartbeat.) Most likely the file is (inadvertantly or not) included in both the main pkg and subpkg. If that is the case, while it is technically not a conflict, it is likely a packaging error nevertheless. -- Rex From jkeating at redhat.com Tue Jul 11 20:54:35 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Jul 2006 16:54:35 -0400 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20060711222044.b11ca5db.bugs.michael@gmx.net> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <20060711193022.GB24737@nostromo.devel.redhat.com> <20060711222044.b11ca5db.bugs.michael@gmx.net> Message-ID: <200607111654.35616.jkeating@redhat.com> On Tuesday 11 July 2006 16:20, Michael Schwendt wrote: > Whether the files are exactly the same (not just in checksum, but also in > uid/gid and mode) will need more automation. Are you using Jeremy's script which detects the conflicts? The script he used to file all the bugs when we moved to using -devel packages to detect multilib ? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Tue Jul 11 21:18:43 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 11 Jul 2006 23:18:43 +0200 Subject: File conflicts in Fedora Extras Development In-Reply-To: <200607111654.35616.jkeating@redhat.com> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <20060711193022.GB24737@nostromo.devel.redhat.com> <20060711222044.b11ca5db.bugs.michael@gmx.net> <200607111654.35616.jkeating@redhat.com> Message-ID: <20060711231843.10e9c555.bugs.michael@gmx.net> On Tue, 11 Jul 2006 16:54:35 -0400, Jesse Keating wrote: > On Tuesday 11 July 2006 16:20, Michael Schwendt wrote: > > Whether the files are exactly the same (not just in checksum, but also in > > uid/gid and mode) will need more automation. > > Are you using Jeremy's script which detects the conflicts? The script he used > to file all the bugs when we moved to using -devel packages to detect > multilib ? No, it's a different one, partially ported from Perl. It uses one local tree and gets the other tree only via yum repomd. From giallu at gmail.com Tue Jul 11 21:24:19 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 11 Jul 2006 23:24:19 +0200 Subject: VTK anyone? In-Reply-To: <44B3DAA5.4050506@jhu.edu> References: <20060710144436.GB5455@free.fr> <44B27321.4060809@cora.nwra.com> <44B3DAA5.4050506@jhu.edu> Message-ID: On 7/11/06, Charles V Wright wrote: > Orion Poplawski wrote: > > Gianluca Sforna wrote: > >> On 7/10/06, Patrice Dumas wrote: > >>> > >>> Maybe you could have a look at paraview, allready included in fedora > >>> extras > >>> (and maintained by Orion) since it has an included version of vtk (last > >>> time it seemed to be a more recent version than the current vtk, > >>> that's why > >>> I didn't block paraview although it included vtk as a private library). > >> Yap, I found that while looking for references to vtk in bugzilla. > >> The version I am working on is 5.0.0, I don't know if it's the same as > >> paraview use, but there will be something to learn for sure... > >> > > > > I've been slowly working on a version. Latest spec and srpm are at > > http://www.cora.nwra.com/~orion/fedora/. I believe the problem I'm > > having currently is getting some of the examples to compile. > > > > I'd be happy to let someone else maintain it though :-). > > > > > > > > Fabrice Bellet has a pretty nice spec file for VTK 5. If you guys > haven't seen it yet, it might be a good place to start from. > > The SRPM is > ftp://fr2.rpmfind.net/linux/local/fedora/5/SRPMS/vtk-5.0.0-6.src.rpm > > It builds pretty happily in mock, has several subpackages for python, > etc, and in general seems to work pretty well for me on FC5. > > I'd love to see VTK in extras, so if there's anything I can do to help, > please let me know. Ok. Since I still need a package ACCEPTED for gaining Extras CVS access, I will try to do my best at this (of course, I still assume no-one else wants to do that instead...) I am going to have a look at all the spec files mentioned in this thread, then assemble something for you to have a look. Real users of the package will be real useful for testing the results, so if you are not subscribed to the pkg-review list I can write here again as soon as I have something workable. Thanks a lot for all the pointers. From mpeters at mac.com Wed Jul 12 01:19:26 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 11 Jul 2006 18:19:26 -0700 Subject: libvisual-plugins Message-ID: <1152667167.25076.25.camel@atlantis.mpeters.local> I am still having problems with the cert to upload the source tarball with libvisual-plugins, even with a new cert downloaded. The devel branch spec file should build, and should also work for FC5. The source tarball is http://easynews.dl.sourceforge.net/sourceforge/libvisual/libvisual-plugins-0.4.0.tar.gz Would someone mind uploading that to Extras and requesting a devel branch build while I try to figure out what is wrong with my ability to upload a source file? The devel branch spec file also needs to be replace the FC5 spec file and a build requested there as well. FC4 should be left alone. Thanks. From lutfi at rg.co.id Wed Jul 12 02:33:56 2006 From: lutfi at rg.co.id (Lutfi) Date: Wed, 12 Jul 2006 09:33:56 +0700 Subject: SELinux protect my squid using havp as parent proxy Message-ID: <44B45F94.40402@rg.co.id> An HTML attachment was scrubbed... URL: From paul at city-fan.org Wed Jul 12 07:29:53 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 12 Jul 2006 08:29:53 +0100 Subject: SELinux protect my squid using havp as parent proxy In-Reply-To: <44B45F94.40402@rg.co.id> References: <44B45F94.40402@rg.co.id> Message-ID: <1152689393.2873.5.camel@laurel.intra.city-fan.org> On Wed, 2006-07-12 at 09:33 +0700, Lutfi wrote: > After upgrade to FC5, my squid cannot using havp (localhost:8080) as > parent proxy anymore. The audit log msg is here: > > ===> /var/log/audit/audit.log > type=AVC msg=audit(1152671338.823:21775): avc: denied > { name_connect } for pid=2371 comm="squid" dest=8080 > scontext=system_u:system_r:squid_t:s0 > tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket > type=SYSCALL msg=audit(1152671338.823:21775): arch=40000003 > syscall=102 success=no exit=-13 a0=3 a1=bf9eb1a0 a2=52e1c4 a3=b7f1ca2c > items=0 pid=2371 auid=4294967295 uid=23 gid=23 euid=23 suid=0 fsuid=23 > egid=23 sgid=23 fsgid=23 tty=(none) comm="squid" exe="/usr/sbin/squid" > subj=system_u:system_r:squid_t:s0 > type=SOCKADDR msg=audit(1152671338.823:21775): > saddr=02001F907F0000010000000000000000 > type=SOCKETCALL msg=audit(1152671338.823:21775): nargs=3 a0=12 > a1=bbdd8f8 a2=10 > > How to fix this? Thx This is off-topic for fedora-extras-list. Please address any followups to fedora-selinux-list, where the right people will see it to get the problem fixed in the next selinux-policy update. I have fixed this problem here using a local policy module: policy_module(localmisc, 0.1.0) require { type squid_t; }; # Squid doing what comes naturally? WTF? corenet_tcp_connect_http_cache_port(squid_t) corenet_tcp_sendrecv_http_cache_port(squid_t) Paul. From Axel.Thimm at ATrpms.net Wed Jul 12 07:53:18 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 12 Jul 2006 09:53:18 +0200 Subject: VTK anyone? In-Reply-To: References: <20060710144436.GB5455@free.fr> <44B27321.4060809@cora.nwra.com> <44B3DAA5.4050506@jhu.edu> Message-ID: <20060712075318.GA1242@neu.nirvana> On Tue, Jul 11, 2006 at 11:24:19PM +0200, Gianluca Sforna wrote: > Ok. Since I still need a package ACCEPTED for gaining Extras CVS > access, I will try to do my best at this (of course, I still assume > no-one else wants to do that instead...) Well, I've already put quite some time into vtk packaging with the intend to push it to extras when it's done and I also need it for my (current) day job, so I'm interested in continuing maintenance. -- 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 giallu at gmail.com Wed Jul 12 08:23:19 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 12 Jul 2006 10:23:19 +0200 Subject: VTK anyone? In-Reply-To: <20060712075318.GA1242@neu.nirvana> References: <20060710144436.GB5455@free.fr> <44B27321.4060809@cora.nwra.com> <44B3DAA5.4050506@jhu.edu> <20060712075318.GA1242@neu.nirvana> Message-ID: On 7/12/06, Axel Thimm wrote: > On Tue, Jul 11, 2006 at 11:24:19PM +0200, Gianluca Sforna wrote: > > Ok. Since I still need a package ACCEPTED for gaining Extras CVS > > access, I will try to do my best at this (of course, I still assume > > no-one else wants to do that instead...) > > Well, I've already put quite some time into vtk packaging with the > intend to push it to extras when it's done and I also need it for my > (current) day job, so I'm interested in continuing maintenance. > -- Considering that, (1) I trust your packaging skills much more than mine and (2) it's stupid to waste our time, I will happily have a look it when you submit the spec for review. Thanks a lot PS. the current spec on the atrmps page is not suitable for Extras submission, is it? From panemade at gmail.com Wed Jul 12 10:08:30 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Wed, 12 Jul 2006 15:38:30 +0530 Subject: Is it possible to add pwc kernel module as Fedora Extras package? Message-ID: hi, I want to add pwc kernel module driver to fedora extras. Why it was discontinued from main kernel source code can be found at http://www.smcc.demon.nl/webcam/ and current homepage for latest source code is at http://www.saillard.org/linux/pwc/ Should i then add it for review? or still i need to ask author for publishable statement? Regards, Parag. From fedora at leemhuis.info Wed Jul 12 10:32:29 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 12 Jul 2006 12:32:29 +0200 Subject: Is it possible to add pwc kernel module as Fedora Extras package? In-Reply-To: References: Message-ID: <44B4CFBD.8070608@leemhuis.info> Parag N(????) schrieb: > I want to add pwc kernel module driver to fedora extras. Why it was > discontinued from main kernel source code [...] From: --- http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2b455db6d456ef2d44808a8377fd3bc832e08317 V4L/DVB (3835): [PATCH] update pwc driver Add v4l2 compatibility Include the decompressor (legal problem has been resolv by Alan Cox) Faster decoder and easier to maintain, optimize, ... Can export to userland compressed stream Support more cameras, lot of bugs are fixed. --- This should show up in 2.6.18. I would not call that "discontinued". CU thl From panemade at gmail.com Wed Jul 12 10:46:36 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Wed, 12 Jul 2006 16:16:36 +0530 Subject: Is it possible to add pwc kernel module as Fedora Extras package? In-Reply-To: <44B4CFBD.8070608@leemhuis.info> References: <44B4CFBD.8070608@leemhuis.info> Message-ID: Hi, On 7/12/06, Thorsten Leemhuis wrote: > > > Parag N(????) schrieb: > > I want to add pwc kernel module driver to fedora extras. Why it was > > discontinued from main kernel source code [...] > > From: > > --- > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2b455db6d456ef2d44808a8377fd3bc832e08317 > > V4L/DVB (3835): [PATCH] update pwc driver > > Add v4l2 compatibility > Include the decompressor (legal problem has been resolv by Alan Cox) > Faster decoder and easier to maintain, optimize, ... > Can export to userland compressed stream > Support more cameras, lot of bugs are fixed. > > --- > > This should show up in 2.6.18. I would not call that "discontinued". But can't we have pwc-10.0.11 version driver for any 2.6.16 kernels under FC5 extras? When i compared pwc-if.c file from 2.6.16 kernel to pwc-10.0.11 package's pwc-if.c, i found there are some differences and pwc-if.c file is old in 2.6.16. Regards, Parag. From mattdm at mattdm.org Wed Jul 12 10:56:03 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 12 Jul 2006 06:56:03 -0400 Subject: Is it possible to add pwc kernel module as Fedora Extras package? In-Reply-To: References: <44B4CFBD.8070608@leemhuis.info> Message-ID: <20060712105603.GA2746@jadzia.bu.edu> On Wed, Jul 12, 2006 at 04:16:36PM +0530, Parag N(????) wrote: > But can't we have pwc-10.0.11 version driver for any 2.6.16 > kernels under FC5 extras? When i compared pwc-if.c file from 2.6.16 > kernel to pwc-10.0.11 package's pwc-if.c, i found there are some > differences and pwc-if.c file is old in 2.6.16. > Regards, > Parag. I don't think Extras should get in the business of building new kernel modules for old kernels which have been replaced for security reasons. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From katzj at redhat.com Wed Jul 12 11:30:21 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 12 Jul 2006 07:30:21 -0400 Subject: File conflicts in Fedora Extras Development In-Reply-To: References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <20060711163235.GA8910@osiris.silug.org> Message-ID: <1152703821.2860.52.camel@aglarond.local> On Tue, 2006-07-11 at 12:38 -0500, Jason L Tibbitts III wrote: > >>>>> "SP" == Steven Pritchard writes: > SP> Ugh. I can't imagine how I missed that. > > Hmm, I wonder how this can be checked easily by a reviewer. I > reviewed said package but had pretty much no chance of noticing this. Nothing trivial springs to mind... possibly a yum-util that checks a package's filelist against the contents of the filelists for repos. But that can only say that both contain the same filename -- it won't do anything to find out if they really conflict[1] Jeremy [1] Since identically md5sum'd files don't conflict From panemade at gmail.com Wed Jul 12 11:46:30 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Wed, 12 Jul 2006 17:16:30 +0530 Subject: Is it possible to add pwc kernel module as Fedora Extras package? In-Reply-To: <20060712105603.GA2746@jadzia.bu.edu> References: <44B4CFBD.8070608@leemhuis.info> <20060712105603.GA2746@jadzia.bu.edu> Message-ID: Hi, On 7/12/06, Matthew Miller wrote: > On Wed, Jul 12, 2006 at 04:16:36PM +0530, Parag N(????) wrote: > > But can't we have pwc-10.0.11 version driver for any 2.6.16 > > kernels under FC5 extras? When i compared pwc-if.c file from 2.6.16 > > kernel to pwc-10.0.11 package's pwc-if.c, i found there are some > > differences and pwc-if.c file is old in 2.6.16. > > Regards, > > Parag. > > I don't think Extras should get in the business of building new kernel > modules for old kernels which have been replaced for security reasons. So can we say that PWC driver must be used from kernel inside and not installed externally and thus there will not be any need exist to have latest PWC kernel driver built for any older kernels in Fedora Extras? Regards, Parag. From bugs.michael at gmx.net Wed Jul 12 13:44:09 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 12 Jul 2006 15:44:09 +0200 Subject: File conflicts in Fedora Extras Development In-Reply-To: <1152703821.2860.52.camel@aglarond.local> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <20060711163235.GA8910@osiris.silug.org> <1152703821.2860.52.camel@aglarond.local> Message-ID: <20060712154409.302d1839.bugs.michael@gmx.net> On Wed, 12 Jul 2006 07:30:21 -0400, Jeremy Katz wrote: > > Hmm, I wonder how this can be checked easily by a reviewer. I > > reviewed said package but had pretty much no chance of noticing this. > > Nothing trivial springs to mind... possibly a yum-util that checks a > package's filelist against the contents of the filelists for repos. But > that can only say that both contain the same filename -- it won't do > anything to find out if they really conflict[1] > > Jeremy > > [1] Since identically md5sum'd files don't conflict Yes, but no reason to worry. In case identical file names have been found and provided that there are only a few packages which contain these files, they can be downloaded and checked more thoroughly. A simple form to display the checksums and more for easy parsing is: rpm -qp --qf '[%-10{filemodes:perms} %{filemd5s} %{filenames}\n]' package.rpm Some of rpm's query-tags can be used to give prettier output when listing packages during package review, e.g.: function rpmls { rpm -q --qf '[%-10{filemodes:perms} %{filenames}\n]' $1 $2 } function rpmlsv { rpm -qlv $1 $2 | awk -F\ '{ print $1,substr($3,0,8),substr($3,9,8),$4,sprin tf("%9d",$5),$9; }' } From dcbw at redhat.com Wed Jul 12 14:19:20 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 12 Jul 2006 10:19:20 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <7dd7ab490607101035m70d4a889gf8467d3ac01017b@mail.gmail.com> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> <44B26713.10200@fedoraproject.org> <20060710180001.09c7a5b7.bugs.michael@gmx.net> <44B28ECC.7000201@fedoraproject.org> <7dd7ab490607101035m70d4a889gf8467d3ac01017b@mail.gmail.com> Message-ID: <1152713960.2620.19.camel@localhost.localdomain> On Mon, 2006-07-10 at 10:35 -0700, Chris Weyl wrote: > On 7/10/06, Rahul wrote: > > Brew is not just the build system but Fedora Core's package management > > (tracking packages) system to produce a distribution too. This is esp > > important for something that is not pushed out as just rolling updates. > > Semi OT, but is brew available externally to redhat anywhere? Were it, I think we'd likely want to merge the stuff that's unique to plague into Brew, and use Brew for Fedora Extras instead. There are some fundamental differences [1], so it might take a while, but would likely be worth it in the end. Dan [1] no support for "active" builders where the builder contacts the server, no support for SSL connections between server<->builder (though I could be wrong here), and no support for SSL connections for the client (though I could also be wrong here) From katzj at redhat.com Wed Jul 12 14:42:13 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 12 Jul 2006 10:42:13 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <1152713960.2620.19.camel@localhost.localdomain> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> <44B26713.10200@fedoraproject.org> <20060710180001.09c7a5b7.bugs.michael@gmx.net> <44B28ECC.7000201@fedoraproject.org> <7dd7ab490607101035m70d4a889gf8467d3ac01017b@mail.gmail.com> <1152713960.2620.19.camel@localhost.localdomain> Message-ID: <1152715333.8319.1.camel@aglarond.local> On Wed, 2006-07-12 at 10:19 -0400, Dan Williams wrote: > [1] no support for "active" builders where the builder contacts the > server, Correct > no support for SSL connections between server<->builder (though > I could be wrong here), and no support for SSL connections for the > client (though I could also be wrong here) brew uses kerberos instead of SSL; so same idea, different implementation. I don't think that kerberos would really work for the needs of Extras, though Jeremy From skvidal at linux.duke.edu Wed Jul 12 14:55:05 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 12 Jul 2006 10:55:05 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <1152713960.2620.19.camel@localhost.localdomain> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> <44B26713.10200@fedoraproject.org> <20060710180001.09c7a5b7.bugs.michael@gmx.net> <44B28ECC.7000201@fedoraproject.org> <7dd7ab490607101035m70d4a889gf8467d3ac01017b@mail.gmail.com> <1152713960.2620.19.camel@localhost.localdomain> Message-ID: <1152716106.28994.6.camel@cutter> On Wed, 2006-07-12 at 10:19 -0400, Dan Williams wrote: > On Mon, 2006-07-10 at 10:35 -0700, Chris Weyl wrote: > > On 7/10/06, Rahul wrote: > > > Brew is not just the build system but Fedora Core's package management > > > (tracking packages) system to produce a distribution too. This is esp > > > important for something that is not pushed out as just rolling updates. > > > > Semi OT, but is brew available externally to redhat anywhere? > > Were it, I think we'd likely want to merge the stuff that's unique to > plague into Brew, and use Brew for Fedora Extras instead. There are > some fundamental differences [1], so it might take a while, but would > likely be worth it in the end. > contingent, of course, on brew being made open source. :) -sv From notting at redhat.com Wed Jul 12 14:56:31 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Jul 2006 10:56:31 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <1152716106.28994.6.camel@cutter> References: <44B107CB.9070104@leemhuis.info> <44B19294.1020106@fedoraproject.org> <44B264E4.30803@leemhuis.info> <44B26713.10200@fedoraproject.org> <20060710180001.09c7a5b7.bugs.michael@gmx.net> <44B28ECC.7000201@fedoraproject.org> <7dd7ab490607101035m70d4a889gf8467d3ac01017b@mail.gmail.com> <1152713960.2620.19.camel@localhost.localdomain> <1152716106.28994.6.camel@cutter> Message-ID: <20060712145631.GA28261@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > On Wed, 2006-07-12 at 10:19 -0400, Dan Williams wrote: > > On Mon, 2006-07-10 at 10:35 -0700, Chris Weyl wrote: > > > On 7/10/06, Rahul wrote: > > > > Brew is not just the build system but Fedora Core's package management > > > > (tracking packages) system to produce a distribution too. This is esp > > > > important for something that is not pushed out as just rolling updates. > > > > > > Semi OT, but is brew available externally to redhat anywhere? > > > > Were it, I think we'd likely want to merge the stuff that's unique to > > plague into Brew, and use Brew for Fedora Extras instead. There are > > some fundamental differences [1], so it might take a while, but would > > likely be worth it in the end. > > contingent, of course, on brew being made open source. :) Absolutely. Bill From rdieter at math.unl.edu Wed Jul 12 16:30:48 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 12 Jul 2006 11:30:48 -0500 Subject: File conflicts in Fedora Extras Development References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> Message-ID: Michael Schwendt wrote: > uw-imap-2004g-4.fc5.2.i386.rpm > File conflict with: /etc/pam.d/imap > File conflict with: /etc/pam.d/pop > File conflict with: /usr/share/man/man8/imapd.8.gz > => Package conflicts with: cyrus-imapd - 2.3.1-2.6.fc5.i386 Hmm... Not sure how best to fix this, probably rename the offending files to use a uw- prefix. I'd ask that cyrus-imapd do something similar. > uw-imap-devel-2004g-4.fc5.2.i386.rpm > => All file names in this package are found in the repository elsewhere! > => Package conflicts with: libc-client-devel - 2004g-2.2.i386 Known, which is why this package already includes: Conflicts: libc-client-devel A smarter version of this script could probably omit bits already marked with a Conflicts: tag. (: -- Rex From rdieter at math.unl.edu Wed Jul 12 16:40:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 12 Jul 2006 11:40:08 -0500 Subject: File conflicts in Fedora Extras Development References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> Message-ID: Rex Dieter wrote: > Michael Schwendt wrote: > >> uw-imap-2004g-4.fc5.2.i386.rpm >> File conflict with: /etc/pam.d/imap >> File conflict with: /etc/pam.d/pop >> File conflict with: /usr/share/man/man8/imapd.8.gz >> => Package conflicts with: cyrus-imapd - 2.3.1-2.6.fc5.i386 > > Hmm... Not sure how best to fix this, probably rename the offending files > to > use a uw- prefix. I'd ask that cyrus-imapd do something similar. Yuck, just realized the pam change(s) will require some patching... I'll just stick in a Conflicts: cyrus-imapd for now, until I have the time to peruse the code more. -- Rex From laurent.rineau__fedora_extras at normalesup.org Wed Jul 12 17:03:04 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Wed, 12 Jul 2006 19:03:04 +0200 Subject: File conflicts in Fedora Extras Development In-Reply-To: References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> Message-ID: <200607121903.04322@rineau.schtroumpfette> On Wednesday 12 July 2006 18:40, Rex Dieter wrote: > Rex Dieter wrote: > > Michael Schwendt wrote: > >> uw-imap-2004g-4.fc5.2.i386.rpm > >> File conflict with: /etc/pam.d/imap > >> File conflict with: /etc/pam.d/pop > >> File conflict with: /usr/share/man/man8/imapd.8.gz > >> => Package conflicts with: cyrus-imapd - 2.3.1-2.6.fc5.i386 > > > > Hmm... Not sure how best to fix this, probably rename the offending files > > to > > use a uw- prefix. I'd ask that cyrus-imapd do something similar. In that case, you could use the alternatives system of the package chkconfig, so that "man imapd" always display a man page. > Yuck, just realized the pam change(s) will require some patching... I'll > just stick in a > Conflicts: cyrus-imapd > for now, until I have the time to peruse the code more. As an alternative, you could also agree, with the owner of cyrus-imapd, jdennis at redhat.com, to have the same content for those two PAM config files. Sounds reasonnable, actually. From jkeating at redhat.com Wed Jul 12 17:07:37 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Jul 2006 13:07:37 -0400 Subject: Recapitulate the current state of Fedora Extras and some ideas to make it better In-Reply-To: <1152715333.8319.1.camel@aglarond.local> References: <44B107CB.9070104@leemhuis.info> <1152713960.2620.19.camel@localhost.localdomain> <1152715333.8319.1.camel@aglarond.local> Message-ID: <200607121307.40856.jkeating@redhat.com> On Wednesday 12 July 2006 10:42, Jeremy Katz wrote: > brew uses kerberos instead of SSL; so same idea, different > implementation. ?I don't think that kerberos would really work for the > needs of Extras, though The auth mechanism of Brew was written modularly so that it could be easily replaced with something like SSL. -- 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 nphilipp at redhat.com Wed Jul 12 17:09:03 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 12 Jul 2006 19:09:03 +0200 Subject: File conflicts in Fedora Extras Development In-Reply-To: References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> Message-ID: <1152724143.2946.35.camel@gibraltar.stuttgart.redhat.com> On Wed, 2006-07-12 at 11:30 -0500, Rex Dieter wrote: > Michael Schwendt wrote: > > uw-imap-devel-2004g-4.fc5.2.i386.rpm > > => All file names in this package are found in the repository elsewhere! > > => Package conflicts with: libc-client-devel - 2004g-2.2.i386 > > Known, which is why this package already includes: > Conflicts: libc-client-devel > A smarter version of this script could probably omit bits already marked > with a Conflicts: tag. (: Somehow this strikes me as wrong... Either uw-imap-devel supersedes libc-client-devel or vice versa (then one should also obsolete the other) or they are independent things (in which case the file conflicts should be solved, e.g. by using separate base directories for the files). 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 Jochen at herr-schmitt.de Wed Jul 12 17:17:00 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 12 Jul 2006 19:17:00 +0200 Subject: Comment to Extras/Contributors Message-ID: <20060712171700.GA16342@myhome> Hello, on http://www.fedoraproject.org/wiki/Extras/Contributors you find a nice step-by-step description how you will get a contributor for fedora Extras. Unfortunately, this page contrains a pitfall: On 'Request Additional Branches' you can read, that you can place requests for additonal branches on 'Extras/CVSSyncNeeded'. But for editing wiki pages you need a special wiki account. the procedure how you can get such a account isn't described on this page. I will suggest to extend this page for a paragraph which describe the neccessary procedure. Best Regards: Jochen Schmitt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From peter at thecodergeek.com Wed Jul 12 17:26:06 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 12 Jul 2006 10:26:06 -0700 (PDT) Subject: Comment to Extras/Contributors In-Reply-To: <20060712171700.GA16342@myhome> References: <20060712171700.GA16342@myhome> Message-ID: <51500.127.0.0.1.1152725166.squirrel@www.thecodergeek.com> Jochen Schmitt wrote: > Unfortunately, this page contrains a pitfall: > > On 'Request Additional Branches' you can read, that you can place requests for > additonal branches on 'Extras/CVSSyncNeeded'. > > But for editing wiki pages you need a special wiki account. the procedure how > you can get such a account isn't described on this page. > > I will suggest to extend this page for a paragraph which describe the > neccessary procedure. The Extras/CVSSyncNeeded page already has instructions to that effect: "Add CVS administrative requests by editing this wiki page. You must register a wiki account to edit this page, but you do not need to be a member of the EditGroup." -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From alcapcom at gmail.com Wed Jul 12 17:21:24 2006 From: alcapcom at gmail.com (alcapcom) Date: Wed, 12 Jul 2006 19:21:24 +0200 Subject: Howto add new sources files to mesa-source package. Message-ID: <4ccd9dcb0607121021p1e7e1a8aldf1fb74d4854b781@mail.gmail.com> Hello, The xgl package doesn't not build with last rawhide mesa because rbadaptors.c, rbadaptors.h, bitset.h files are not present in the mesa-source package. I have many idea to resolve this problem, but i ask you to have the best practice to do that. 1. Ask mesa maintainers to add these files to de current rawhide sources. 2. Make a patch to add these files to the sources, and create a new request on bugzilla. 3. Create a package (with dependencie on mesa-source) that add xgl requieres sources to the current mesa sources directory. ( i think, that's dirty way). I already posted this message on bugzilla but I did not have any answer. (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192436#c10) Does somebody have an idea, to solve the problem? ps: All cvs branches are concerned. Thanks Alphonse From notting at redhat.com Wed Jul 12 17:36:28 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Jul 2006 13:36:28 -0400 Subject: File conflicts in Fedora Extras Development In-Reply-To: <1152724143.2946.35.camel@gibraltar.stuttgart.redhat.com> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <1152724143.2946.35.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20060712173628.GB29653@nostromo.devel.redhat.com> Nils Philippsen (nphilipp at redhat.com) said: > > Known, which is why this package already includes: > > Conflicts: libc-client-devel > > A smarter version of this script could probably omit bits already marked > > with a Conflicts: tag. (: > > Somehow this strikes me as wrong... Either uw-imap-devel supersedes > libc-client-devel or vice versa (then one should also obsolete the > other) or they are independent things (in which case the file conflicts > should be solved, e.g. by using separate base directories for the > files). Consdering they come from the same code base... why would you use one and not the other? Bill From bugs.michael at gmx.net Wed Jul 12 17:38:49 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 12 Jul 2006 19:38:49 +0200 Subject: File conflicts in Fedora Extras Development In-Reply-To: References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> Message-ID: <20060712193849.19c96951.bugs.michael@gmx.net> On Wed, 12 Jul 2006 11:30:48 -0500, Rex Dieter wrote: > Michael Schwendt wrote: > > > uw-imap-2004g-4.fc5.2.i386.rpm > > File conflict with: /etc/pam.d/imap > > File conflict with: /etc/pam.d/pop > > File conflict with: /usr/share/man/man8/imapd.8.gz > > => Package conflicts with: cyrus-imapd - 2.3.1-2.6.fc5.i386 > > Hmm... Not sure how best to fix this, probably rename the offending files to > use a uw- prefix. I'd ask that cyrus-imapd do something similar. > > > uw-imap-devel-2004g-4.fc5.2.i386.rpm > > => All file names in this package are found in the repository elsewhere! > > => Package conflicts with: libc-client-devel - 2004g-2.2.i386 > > Known, which is why this package already includes: > Conflicts: libc-client-devel > A smarter version of this script could probably omit bits already marked > with a Conflicts: tag. (: At this point it would only confirm that there is an explicit Conflict in Extras. I'd rather see an official policy from the Packaging Group about Conflicts in general. From rdieter at math.unl.edu Wed Jul 12 17:53:09 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 12 Jul 2006 12:53:09 -0500 Subject: File conflicts in Fedora Extras Development References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <1152724143.2946.35.camel@gibraltar.stuttgart.redhat.com> <20060712173628.GB29653@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Nils Philippsen (nphilipp at redhat.com) said: >> > Known, which is why this package already includes: >> > Conflicts: libc-client-devel >> > A smarter version of this script could probably omit bits already >> > marked >> > with a Conflicts: tag. (: >> >> Somehow this strikes me as wrong... Either uw-imap-devel supersedes >> libc-client-devel or vice versa (then one should also obsolete the >> other) or they are independent things (in which case the file conflicts >> should be solved, e.g. by using separate base directories for the >> files). > > Consdering they come from the same code base... why would you use one > and not the other? Before fc6, the version uw-imap provided was newer than that of Core. As of fc6, they are the same. I had once asked the Core libc-client maintainer what to do about that, https://bugzilla.redhat.com/179017#c1 but they didn't respond. I didn't follow up on it. -- Rex From ifoox at redhat.com Wed Jul 12 18:43:27 2006 From: ifoox at redhat.com (Igor Foox) Date: Wed, 12 Jul 2006 14:43:27 -0400 Subject: rpmlint problem: Class-Path in manifest problem Message-ID: <1152729807.23870.17.camel@tool.toronto.redhat.com> Hi, I'm building the following src.rpm: http://people.redhat.com/ifoox/extras/ant-contrib-1.0-0.1.b2.src.rpm and I get this error from rpmlint: W: ant-contrib class-path-in-manifest /usr/share/java/ant-contrib-1.0.jar Does anybody know what this mean, and why it's considered bad? The manifest file contains this line, which is the culprit: Class-Path: ant-contrib.jar Thanks, Igor From jeremy at jeremysanders.net Wed Jul 12 18:43:03 2006 From: jeremy at jeremysanders.net (Jeremy Sanders) Date: Wed, 12 Jul 2006 19:43:03 +0100 (BST) Subject: Ghost pyo Message-ID: Hi - My python based package veusz works on FC5 and devel, but fails to build on FC4 because the %ghost globs cannot find the .pyo files, which are apparently not generated by FC4. What is the correct way of dealing with this? Should I remove the %ghost statements from the FC4 spec file, or somehow get the pyo files to be generated? Thanks Jeremy -- Jeremy Sanders http://www.jeremysanders.net/ Cambridge, UK Public Key Server PGP Key ID: E1AAE053 From toshio at tiki-lounge.com Wed Jul 12 18:59:58 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 12 Jul 2006 11:59:58 -0700 Subject: Ghost pyo In-Reply-To: References: Message-ID: <1152730798.3061.12.camel@localhost> On Wed, 2006-07-12 at 19:43 +0100, Jeremy Sanders wrote: > Hi - > > My python based package veusz works on FC5 and devel, but fails to build > on FC4 because the %ghost globs cannot find the .pyo files, which are > apparently not generated by FC4. > > What is the correct way of dealing with this? Should I remove the %ghost > statements from the FC4 spec file, or somehow get the pyo files to be > generated? > You need to generate the .pyo files. Instructions that may help can be found under the ".pyo files" section on this page:: http://www.fedoraproject.org/wiki/Packaging/Python -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 rdieter at math.unl.edu Wed Jul 12 19:16:12 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 12 Jul 2006 14:16:12 -0500 Subject: Ghost pyo References: Message-ID: Jeremy Sanders wrote: > Hi - > > My python based package veusz works on FC5 and devel, but fails to build > on FC4 because the %ghost globs cannot find the .pyo files, which are > apparently not generated by FC4. > > What is the correct way of dealing with this? Should I remove the %ghost > statements from the FC4 spec file, or somehow get the pyo files to be > generated? The former. Wrap the %ghost statements inside %if "%{?fedora}" > "4" %endif -- Rex From rdieter at math.unl.edu Wed Jul 12 19:18:15 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 12 Jul 2006 14:18:15 -0500 Subject: Ghost pyo References: Message-ID: Rex Dieter wrote: > Jeremy Sanders wrote: >> My python based package veusz works on FC5 and devel, but fails to build >> on FC4 because the %ghost globs cannot find the .pyo files, which are >> apparently not generated by FC4. >> >> What is the correct way of dealing with this? Should I remove the %ghost >> statements from the FC4 spec file, or somehow get the pyo files to be >> generated? > > The former. Nevermind, I defer and refer to http://www.fedoraproject.org/wiki/Packaging/Python -- Rex From Jochen at herr-schmitt.de Wed Jul 12 19:22:01 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 12 Jul 2006 21:22:01 +0200 Subject: Coment to the Extras/SponsorProcess Page Message-ID: <20060712192201.GA28639@myhome> Hello, I have read the page on http://www.fedoraproject.org/wiki/Extras/SponsorProcess AFAIK the submitting of review requests to the fedora-extras-list mailing list is outdated. Instead review requests are submitted on http://bugzilla.redhat.com. Bugzilla send a mail of the new review request in the fedora-package-review mailing list. The creater of the review request should write in the ticket that he/she need a sponsor. I thing the page should be updated to reflect the current status of the package review process. Best Regards: Jochen Schmitt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeremy at jeremysanders.net Wed Jul 12 19:38:22 2006 From: jeremy at jeremysanders.net (Jeremy Sanders) Date: Wed, 12 Jul 2006 20:38:22 +0100 (BST) Subject: Ghost pyo In-Reply-To: <1152730798.3061.12.camel@localhost> References: <1152730798.3061.12.camel@localhost> Message-ID: On Wed, 12 Jul 2006, Toshio Kuratomi wrote: > You need to generate the .pyo files. > > Instructions that may help can be found under the ".pyo files" section > on this page:: > http://www.fedoraproject.org/wiki/Packaging/Python Thanks. I missed that I needed a -O1 on the distutils install line. -- Jeremy Sanders http://www.jeremysanders.net/ Cambridge, UK Public Key Server PGP Key ID: E1AAE053 From tibbs at math.uh.edu Wed Jul 12 19:41:29 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 12 Jul 2006 14:41:29 -0500 Subject: Coment to the Extras/SponsorProcess Page In-Reply-To: <20060712192201.GA28639@myhome> (Jochen Schmitt's message of "Wed, 12 Jul 2006 21:22:01 +0200") References: <20060712192201.GA28639@myhome> Message-ID: >>>>> "JS" == Jochen Schmitt writes: JS> I thing the page should be updated to reflect the current status JS> of the package review process. It's a wiki, you know; you can make corrections there. If you're not in the edit group and would like to be, just let me know. - J< From tibbs at math.uh.edu Wed Jul 12 19:43:00 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 12 Jul 2006 14:43:00 -0500 Subject: rpmlint problem: Class-Path in manifest problem In-Reply-To: <1152729807.23870.17.camel@tool.toronto.redhat.com> (Igor Foox's message of "Wed, 12 Jul 2006 14:43:27 -0400") References: <1152729807.23870.17.camel@tool.toronto.redhat.com> Message-ID: >>>>> "IF" == Igor Foox writes: IF> Does anybody know what this mean, > rpmlint -I class-path-in-manifest class-path-in-manifest : The META-INF/MANIFEST file in the jar contains a hardcoded Class-Path. These entries do not work with older Java versions and even if they do work, they are inflexible and usually cause nasty surprises. IF> and why it's considered bad? I don't know enough about Java to say more. - J< From ifoox at redhat.com Wed Jul 12 19:53:50 2006 From: ifoox at redhat.com (Igor Foox) Date: Wed, 12 Jul 2006 15:53:50 -0400 Subject: rpmlint problem: Class-Path in manifest problem In-Reply-To: References: <1152729807.23870.17.camel@tool.toronto.redhat.com> Message-ID: <1152734030.23870.19.camel@tool.toronto.redhat.com> On Wed, 2006-07-12 at 14:43 -0500, Jason L Tibbitts III wrote: > >>>>> "IF" == Igor Foox writes: > > IF> Does anybody know what this mean, > > > rpmlint -I class-path-in-manifest > class-path-in-manifest : > The META-INF/MANIFEST file in the jar contains a hardcoded Class-Path. > These entries do not work with older Java versions and even if they do work, > they are inflexible and usually cause nasty surprises. > > IF> and why it's considered bad? > > I don't know enough about Java to say more. The jar file seems to refer itself in the Class-Path, but it is not an absolute path, just 'ant-contrib.jar'. I'm not sure why it's referring to itself in the first place, but I'm wondering if people have seen this problem before? Igor From notting at redhat.com Wed Jul 12 19:55:43 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 12 Jul 2006 15:55:43 -0400 Subject: File conflicts in Fedora Extras Development In-Reply-To: References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> <1152724143.2946.35.camel@gibraltar.stuttgart.redhat.com> <20060712173628.GB29653@nostromo.devel.redhat.com> Message-ID: <20060712195543.GB3323@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > Before fc6, the version uw-imap provided was newer than that of Core. As of > fc6, they are the same. I had once asked the Core libc-client maintainer > what to do about that, > https://bugzilla.redhat.com/179017#c1 > but they didn't respond. I didn't follow up on it. Why would someone conceivably need a newer c-client? Shouldn't they just be ported away from it? :) Bill From nicolas.mailhot at laposte.net Wed Jul 12 20:14:15 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 12 Jul 2006 22:14:15 +0200 Subject: rpmlint problem: Class-Path in manifest problem In-Reply-To: References: <1152729807.23870.17.camel@tool.toronto.redhat.com> Message-ID: <1152735255.10992.23.camel@rousalka.dyndns.org> Le mercredi 12 juillet 2006 ? 14:43 -0500, Jason L Tibbitts III a ?crit : > >>>>> "IF" == Igor Foox writes: > > IF> Does anybody know what this mean, > > > rpmlint -I class-path-in-manifest > class-path-in-manifest : > The META-INF/MANIFEST file in the jar contains a hardcoded Class-Path. > These entries do not work with older Java versions and even if they do work, > they are inflexible and usually cause nasty surprises. > > IF> and why it's considered bad? > > I don't know enough about Java to say more. Because the file will behave differently depending where it or its deps are in the filesystem, which leads to very unfunny debugging sessions to find out why an app suddenly broke. At lease when the classpath is in a script and not burried inside metadata you can understands what happens (plus scripts are a boatload more flexible than hardcoded absolute paths) -- 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 ville.skytta at iki.fi Wed Jul 12 20:23:14 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 12 Jul 2006 23:23:14 +0300 Subject: libvisual-plugins In-Reply-To: <1152667167.25076.25.camel@atlantis.mpeters.local> References: <1152667167.25076.25.camel@atlantis.mpeters.local> Message-ID: <1152735794.13013.65.camel@localhost.localdomain> On Tue, 2006-07-11 at 18:19 -0700, Michael A. Peters wrote: > http://easynews.dl.sourceforge.net/sourceforge/libvisual/libvisual-plugins-0.4.0.tar.gz > > Would someone mind uploading that to Extras and requesting a devel > branch build while I try to figure out what is wrong with my ability to > upload a source file? > > The devel branch spec file also needs to be replace the FC5 spec file > and a build requested there as well. FC4 should be left alone. Please prepare everything apart from the actual upload in all CVS branches (including the sources and .cvsignore files w/the md5sum) and I'll take care of the upload unless someone beats me to it. From gauret at free.fr Wed Jul 12 20:59:34 2006 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 12 Jul 2006 22:59:34 +0200 Subject: libvisual-plugins References: <1152667167.25076.25.camel@atlantis.mpeters.local> <1152735794.13013.65.camel@localhost.localdomain> Message-ID: > > Please prepare everything apart from the actual upload in all CVS > branches (including the sources and .cvsignore files w/the md5sum) and > I'll take care of the upload unless someone beats me to it. > You've just been beaten :) I've uploaded the tarball, with MD5SUM 4330e9287f9d6fae02f482f428a1e77b Please go ahead with the update. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Make everything as simple as possible, but not simpler." -- Albert Einstein From alcapcom at gmail.com Thu Jul 13 09:14:40 2006 From: alcapcom at gmail.com (alcapcom) Date: Thu, 13 Jul 2006 11:14:40 +0200 Subject: rpmlint problem: Class-Path in manifest problem In-Reply-To: <1152735255.10992.23.camel@rousalka.dyndns.org> References: <1152729807.23870.17.camel@tool.toronto.redhat.com> <1152735255.10992.23.camel@rousalka.dyndns.org> Message-ID: <4ccd9dcb0607130214x355def0bl9ce1802fa8c28027@mail.gmail.com> Hi, My 0.01 $ idea. 1) Remove the CLASSPATH entry from the jar file, copy the modify jar in /usr/share/java/ant/. 2) Crea in /etc/ant.d that contain its like that (oro example) oro ant/ant-apache-oro If the task depend on many jars: jar1 jar2 ant/task.jar file place in /etc/ant.d help Ant to load the jars files in the CLASSPATH. 3) If it work, create a patch to remove the classpath line in the manifest file, to do that at rpm build time. 4) Hope that Help you ;-) Cheers Alphonse 2006/7/12, Nicolas Mailhot : > Le mercredi 12 juillet 2006 ? 14:43 -0500, Jason L Tibbitts III a > ?crit : > > >>>>> "IF" == Igor Foox writes: > > > > IF> Does anybody know what this mean, > > > > > rpmlint -I class-path-in-manifest > > class-path-in-manifest : > > The META-INF/MANIFEST file in the jar contains a hardcoded Class-Path. > > These entries do not work with older Java versions and even if they do work, > > they are inflexible and usually cause nasty surprises. > > > > IF> and why it's considered bad? > > > > I don't know enough about Java to say more. > > Because the file will behave differently depending where it or its deps > are in the filesystem, which leads to very unfunny debugging sessions to > find out why an app suddenly broke. > At lease when the classpath is in a script and not burried inside > metadata you can understands what happens (plus scripts are a boatload > more flexible than hardcoded absolute paths) > > -- > Nicolas Mailhot > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.4 (GNU/Linux) > > iEYEABECAAYFAkS1WBcACgkQI2bVKDsp8g3d5ACfS++VksQrm/Jusn+bvYAl8ROa > /P4An3BgsFmlznSq0YYkgM8tNQ6y983r > =MjP4 > -----END PGP SIGNATURE----- > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > From buildsys at fedoraproject.org Thu Jul 13 09:42:26 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 13 Jul 2006 05:42:26 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-13 Message-ID: <20060713094226.3DBD6152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 33 bzflag-2.0.8-2.fc5 clips-6.24-18.fc5 freenx-0.5.0-2.fc5 ghdl-0.24-0.59svn.2.fc5 gtk-qt-engine-0.70-2.fc5 gxemul-0.4.0.1-3.fc5 kicad-2006.06.26-5.fc5 libtunepimp-0.4.2-3.fc5 lighttpd-1.4.11-1.fc5 mlton-20051202-8.fc5 monodoc-1.1.16-1.fc5 monotone-0.27-1.fc5 nx-2.0.0-1.fc5 pcb-0.20060422-6 perl-Contextual-Return-v0.1.0-1.fc5 perl-Email-Address-1.85-1.fc5 perl-Email-MessageID-1.35-1.fc5 perl-Email-Simple-1.94-1.fc5 perl-Error-0.16-1.fc5 perl-Expect-1.18-1.fc5 perl-HTML-Tree-3.20-2.fc5 perl-IO-Prompt-v0.99.4-1.fc5 perl-Image-ExifTool-6.26-2.fc5 perl-POE-Component-Child-1.39-1.fc5 perl-POE-Component-SimpleLog-1.03-1.fc5 perl-WWW-Myspace-0.50-1.fc5 pl-5.6.16-1.fc5.1 python-kiwi-1.9.8-1.fc5 sunifdef-2.1.1-1.fc5.1 veusz-0.10-8.fc5 veusz-0.10-9.fc5 wine-0.9.17-1.fc5 xpilot-ng-4.7.2-8.fc5 Packages built and released for Fedora Extras 4: 23 anthy-7900-1.fc4 bzflag-2.0.8-2.fc4 clips-6.24-15.fc4 gtk-qt-engine-0.70-2.fc4 gxemul-0.4.0.1-3.fc4 kicad-2006.06.26-5.fc4 libtunepimp-0.4.2-3.fc4 lighttpd-1.4.11-1.fc4 mlton-20051202-8.fc4 perl-Contextual-Return-v0.1.0-1.fc4 perl-Email-Address-1.85-1.fc4 perl-Email-MessageID-1.35-1.fc4 perl-Email-Simple-1.94-1.fc4 perl-HTML-Tree-3.20-2.fc4 perl-IO-Prompt-v0.99.4-1.fc4 perl-Image-ExifTool-6.26-2.fc4 perl-Mail-Mbox-MessageParser-1.4004-1.fc4 perl-POE-Component-Child-1.39-1.fc4 perl-WWW-Myspace-0.50-1.fc4 pl-5.6.16-1.fc4.1 sunifdef-2.1.1-1.fc4.1 veusz-0.10-9.fc4 xpilot-ng-4.7.2-7.fc4 Packages built and released for Fedora Extras 3: 2 dkms-2.0.13-1.fc3 gtk-qt-engine-0.70-2.fc3 Packages built and released for Fedora Extras development: 54 bzflag-2.0.8-2.fc6 clips-6.24-18.fc6 cmake-2.4.2-2.fc6 dejavu-fonts-2.8.0-0.2.rc1.fc6 easytag-1.99.12-2.fc6 facter-1.3.3-1.fc6 freenx-0.5.0-2.fc6 ghdl-0.24-0.59svn.2.fc6 gobby-0.4.0-6.rc2.fc6 gtk-qt-engine-0.70-2.fc6 gxemul-0.4.0.1-3.fc6 hexter-dssi-0.5.9-4.fc6 im-chooser-0.2.1-3.fc6 im-chooser-0.2.2-1.fc6 kicad-2006.06.26-5.fc6 libtunepimp-0.4.2-4.fc6 lighttpd-1.4.11-1.fc6 mlton-20051202-8.fc6 monodoc-1.1.16-1.fc6 nx-2.0.0-1.fc6 obby-0.4.0-4.rc2.fc6 obby-0.4.0-5.rc2.fc6 octave-2.9.6-2.fc6 octave-forge-2006.07.09-2.fc6 ooo2txt-0.0.6-1.fc6 pcb-0.20060422-7 perl-Email-Address-1.85-1.fc6 perl-Email-MessageID-1.35-1.fc6 perl-Email-Simple-1.94-1.fc6 perl-Error-0.16-1.fc6 perl-Expect-1.18-1.fc6 perl-HTML-Tree-3.20-2.fc6 perl-Image-ExifTool-6.26-2.fc6 perl-Mail-Mbox-MessageParser-1.4004-1.fc6 perl-Net-Jabber-2.0-6.fc6 perl-WWW-Myspace-0.50-1.fc6 pessulus-0.10.4-1.fc6 pl-5.6.16-1.fc6 poster-20060221-2 puppet-0.18.2-1.fc6 python-kiwi-1.9.8-1.fc6 python-ruledispatch-0.5a0-0.1.svnr2115.fc6 radiusclient-ng-0.5.2-3.fc6 ruby-sqlite3-1.1.0-5.fc6 scim-chinese-standard-0.0.1-1.fc6 scim-chinese-standard-0.0.1-3.fc6 sobby-0.4.0-3.rc1.fc6 sunifdef-2.1.1-1.fc6 tidy-0.99.0-10.20051025.fc6 veusz-0.10-8.fc6 veusz-0.10-9.fc6 wine-0.9.17-1.fc6 x3270-3.3.4p7-3.fc6 xpilot-ng-4.7.2-8.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Jul 13 09:42:49 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 13 Jul 2006 05:42:49 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-13 Message-ID: <20060713094249.A0308152160@buildsys.fedoraproject.org> alsa-lib: 5: 0:1.0.11-4.rc2 (FC5-updates) 6: 0:1.0.11-3.rc2.2.1 (FC6) amarok: 5: 0:1.4.1-2.fc5 (FE5) 6: 0:1.4.0-5.fc6 (FE6) anthy: 4: 0:7900-1.fc4 (FE4) 5: 0:7500b-1.fc5 (FC5-updates) 6: 0:7900-1.1.fc6 (FC6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.0.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) ecl: 4: 0:0.9i-1.1.fc4 (FE4) 5: 0:0.9i-1.fc5 (FE5) 6: 0:0.9i-1.fc6 (FE6) eclipse-changelog: 5: 1:2.1.0_fc-2 (FC5-updates) 6: 1:2.1.0_fc-1 (FC6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gnome-applet-vm: 5: 0:0.0.7-2 (FC5-updates) 6: 0:0.0.6-1.1 (FC6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libglade-java: 5: 0:2.12.4-0.FC5 (FC5-updates) 6: 0:2.12.4-0 (FC6) libgnome-java: 5: 0:2.12.3-0.FC5 (FC5-updates) 6: 0:2.12.3-0 (FC6) libgtk-java: 5: 0:2.8.5-0.FC5 (FC5-updates) 6: 0:2.8.5-0 (FC6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libvte-java: 5: 0:0.12.0-0.FC5 (FC5-updates) 6: 0:0.12.0-0 (FC6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-11.fc6 (FC6) monotone: 5: 0:0.27-1.fc5 (FE5) 6: 0:0.26-2.fc6 (FE6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-Mail-Mbox-MessageParser: 4: 0:1.4004-1.fc4 (FE4) 5: 0:1.4003-1.fc5 (FE5) 6: 0:1.4004-1.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) squid: 5: 7:2.5.STABLE14-2.FC5 (FC5-updates) 6: 7:2.5.STABLE14-2 (FC6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion: 5: 0:1.3.2-2.1 (FC5-updates) 6: 0:1.3.1-4 (FC6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) tcl: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) tk: 5: 0:8.4.13-1.1 (FC5-updates) 6: 0:8.4.13-1 (FC6) tzdata: 5: 0:2006g-1.fc5 (FC5-updates) 6: 0:2006g-1 (FC6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) wordpress: 4: 0:2.0.3-4.fc4 (FE4) 5: 0:2.0.3-3.fc5 (FE5) 6: 0:2.0.3-3.fc6 (FE6) From paul at city-fan.org Thu Jul 13 09:49:27 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 13 Jul 2006 10:49:27 +0100 Subject: rpms/driftnet/FC-5 driftnet.spec,1.3,1.4 In-Reply-To: <200607130941.k6D9fWYD032544@cvs-int.fedora.redhat.com> References: <200607130941.k6D9fWYD032544@cvs-int.fedora.redhat.com> Message-ID: <44B61727.6050108@city-fan.org> Bastien Nocera (hadess) wrote: > Index: driftnet.spec > =================================================================== > RCS file: /cvs/extras/rpms/driftnet/FC-5/driftnet.spec,v > retrieving revision 1.3 > retrieving revision 1.4 > diff -u -r1.3 -r1.4 > --- driftnet.spec 3 Apr 2006 13:10:33 -0000 1.3 > +++ driftnet.spec 13 Jul 2006 09:41:30 -0000 1.4 > @@ -2,7 +2,7 @@ > License: GPL > Group: Applications/Internet > Version: 0.1.6 > -Release: 9 > +Release: 9.%{dist} > Summary: Network image sniffer > URL: http://www.ex-parrot.com/~chris/driftnet/ > Source0: http://www.ex-parrot.com/~chris/driftnet/driftnet-0.1.6.tar.gz > @@ -12,7 +12,7 @@ > Patch1: driftnet-dont-use-tmpnam.patch > Patch2: driftnet-0.1.6-no-makedepend.patch > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > -BuildRequires: libpcap gtk2-devel libungif-devel libjpeg-devel > +BuildRequires: libpcap-devel gtk2-devel libungif-devel libjpeg-devel > Requires: %{_bindir}/consolehelper > > %description > @@ -55,6 +55,9 @@ > rm -rf $RPM_BUILD_ROOT > > %changelog > +* Thu Jul 13 2006 - Bastien Nocera - 0.1.6-9.fc5 > +- Build into FC5, build with libpcap-devel ? FC5 doesn't have libpcap-devel; the split happened post-FC5. Paul. From buildsys at fedoraproject.org Thu Jul 13 10:04:12 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 13 Jul 2006 10:04:12 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-13 Message-ID: <20060713100412.32325.81595@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) From buildsys at fedoraproject.org Thu Jul 13 10:04:12 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 13 Jul 2006 10:04:12 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-13 Message-ID: <20060713100412.32319.73984@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Thu Jul 13 10:04:12 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 13 Jul 2006 10:04:12 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-13 Message-ID: <20060713100412.32330.99597@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 gauret AT free.fr amarok-visualisation - 1.4.0-5.fc6.i386 amarok-visualisation - 1.4.0-5.fc6.ppc amarok-visualisation - 1.4.0-5.fc6.x86_64 icon AT fedoraproject.org python-kiwi-gazpacho - 1.9.8-1.fc6.noarch python-kiwi-gazpacho - 1.9.8-1.fc6.noarch python-kiwi-gazpacho - 1.9.8-1.fc6.noarch imlinux AT gmail.com nagios - 2.4-2.fc6.i386 nagios - 2.4-2.fc6.ppc nagios - 2.4-2.fc6.x86_64 matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 gfontview - 0.5.0-5.fc5.ppc gfontview - 0.5.0-5.fc5.x86_64 libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 pertusus AT free.fr cernlib - 2005-21.fc6.ppc cernlib-packlib - 2005-21.fc6.ppc patchy - 2005-21.fc6.ppc paw - 2005-21.fc6.ppc rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 libibverbs - 1.0.3-1.fc6.ppc libibverbs - 1.0.3-1.fc6.x86_64 libibverbs-utils - 1.0.3-1.fc6.i386 libibverbs-utils - 1.0.3-1.fc6.ppc libibverbs-utils - 1.0.3-1.fc6.x86_64 thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 directfb - 0.9.24-5.fc5.ppc directfb - 0.9.24-5.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.i386 requires libvisual.so.0 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 nagios-2.4-2.fc6.i386 requires libttf.so.2 python-kiwi-gazpacho-1.9.8-1.fc6.noarch requires gazpacho >= 0:0.6.6 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.ppc requires libvisual.so.0 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 nagios-2.4-2.fc6.ppc requires libttf.so.2 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 python-kiwi-gazpacho-1.9.8-1.fc6.noarch requires gazpacho >= 0:0.6.6 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.x86_64 requires libvisual.so.0()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) nagios-2.4-2.fc6.x86_64 requires libttf.so.2()(64bit) python-kiwi-gazpacho-1.9.8-1.fc6.noarch requires gazpacho >= 0:0.6.6 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: cweyl AT alumni.drew.edu package: gaim-gaym - 0.96-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: gaim < 1:2.0.0 package: gaim-gaym - 0.96-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: gaim < 1:2.0.0 package: gaim-gaym - 0.96-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: gaim < 1:2.0.0 ====================================================================== New report for: byte AT fedoraproject.org package: gaim-guifications - 2.12-3.fc5.i386 from fedora-extras-development-i386 unresolved deps: gaim < 1:2 package: gaim-guifications - 2.12-3.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: gaim < 1:2 package: gaim-guifications - 2.12-3.fc5.ppc from fedora-extras-development-ppc unresolved deps: gaim < 1:2 ====================================================================== New report for: icon AT fedoraproject.org package: python-kiwi-gazpacho - 1.9.8-1.fc6.noarch from fedora-extras-development-i386 unresolved deps: gazpacho >= 0:0.6.6 package: python-kiwi-gazpacho - 1.9.8-1.fc6.noarch from fedora-extras-development-x86_64 unresolved deps: gazpacho >= 0:0.6.6 package: python-kiwi-gazpacho - 1.9.8-1.fc6.noarch from fedora-extras-development-ppc unresolved deps: gazpacho >= 0:0.6.6 ====================================================================== New report for: pertusus AT free.fr package: cernlib-packlib - 2005-21.fc6.ppc from fedora-extras-development-ppc unresolved deps: libg2c.so.0 package: patchy - 2005-21.fc6.ppc from fedora-extras-development-ppc unresolved deps: libg2c.so.0 package: cernlib - 2005-21.fc6.ppc from fedora-extras-development-ppc unresolved deps: libg2c.so.0 package: paw - 2005-21.fc6.ppc from fedora-extras-development-ppc unresolved deps: libg2c.so.0 ====================================================================== New report for: caillon AT redhat.com package: banshee - 0.10.8-1.i386 from fedora-extras-development-i386 unresolved deps: libnautilus-burn.so.3 package: banshee - 0.10.8-1.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnautilus-burn.so.3()(64bit) package: banshee - 0.10.8-1.ppc from fedora-extras-development-ppc unresolved deps: libnautilus-burn.so.3 ====================================================================== New report for: matthias AT rpmforge.net package: gtktalog - 1.0.4-7.fc5.i386 from fedora-extras-development-i386 unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 package: gtktalog - 1.0.4-7.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) gnome-libs >= 0:1.2 libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: diradmin - 1.7.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgnomesupport.so.0()(64bit) libart_lgpl.so.2()(64bit) libgnome.so.32()(64bit) libgnomeui.so.32()(64bit) package: gtktalog - 1.0.4-7.fc5.ppc from fedora-extras-development-ppc unresolved deps: libart_lgpl.so.2 gnome-libs >= 0:1.2 libgnomesupport.so.0 libgnome.so.32 libgnomeui.so.32 package: diradmin - 1.7.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgnomesupport.so.0 libart_lgpl.so.2 libgnome.so.32 libgnomeui.so.32 From buildsys at fedoraproject.org Thu Jul 13 10:04:12 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 13 Jul 2006 10:04:12 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-13 Message-ID: <20060713100412.32327.77643@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- icon AT fedoraproject.org python-kiwi-gazpacho - 1.9.8-1.fc5.noarch python-kiwi-gazpacho - 1.9.8-1.fc5.noarch python-kiwi-gazpacho - 1.9.8-1.fc5.noarch mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-kiwi-gazpacho-1.9.8-1.fc5.noarch requires gazpacho >= 0:0.6.6 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-kiwi-gazpacho-1.9.8-1.fc5.noarch requires gazpacho >= 0:0.6.6 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-kiwi-gazpacho-1.9.8-1.fc5.noarch requires gazpacho >= 0:0.6.6 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: icon AT fedoraproject.org package: python-kiwi-gazpacho - 1.9.8-1.fc5.noarch from fedora-extras-5-i386 unresolved deps: gazpacho >= 0:0.6.6 package: python-kiwi-gazpacho - 1.9.8-1.fc5.noarch from fedora-extras-5-x86_64 unresolved deps: gazpacho >= 0:0.6.6 package: python-kiwi-gazpacho - 1.9.8-1.fc5.noarch from fedora-extras-5-ppc unresolved deps: gazpacho >= 0:0.6.6 From pertusus at free.fr Thu Jul 13 10:42:21 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 13 Jul 2006 12:42:21 +0200 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-13 In-Reply-To: <20060713100412.32330.99597@extras64.linux.duke.edu> References: <20060713100412.32330.99597@extras64.linux.duke.edu> Message-ID: <20060713104221.GD2570@free.fr> On Thu, Jul 13, 2006 at 10:04:12AM -0000, Fedora Extras repoclosure wrote: > pertusus AT free.fr > cernlib - 2005-21.fc6.ppc > cernlib-packlib - 2005-21.fc6.ppc > patchy - 2005-21.fc6.ppc > paw - 2005-21.fc6.ppc > > Summary of broken packages in fedora-extras-development-ppc: > ---------------------------------------------------------------------- > cernlib-2005-21.fc6.ppc requires libg2c.so.0 > cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 > paw-2005-21.fc6.ppc requires libg2c.so.0 Anybody knows what happened on ppc? Should I rebuild? -- Pat From alcapcom at gmail.com Thu Jul 13 11:24:11 2006 From: alcapcom at gmail.com (alcapcom) Date: Thu, 13 Jul 2006 13:24:11 +0200 Subject: rpmlint problem: Class-Path in manifest problem In-Reply-To: <4ccd9dcb0607130214x355def0bl9ce1802fa8c28027@mail.gmail.com> References: <1152729807.23870.17.camel@tool.toronto.redhat.com> <1152735255.10992.23.camel@rousalka.dyndns.org> <4ccd9dcb0607130214x355def0bl9ce1802fa8c28027@mail.gmail.com> Message-ID: <4ccd9dcb0607130424q6d39c25bh8befcbf7fb7f9bd9@mail.gmail.com> Oops, after second reading? is necessary to replace "Crea..." by "Create a file?" in the preceding message. Now i go to the pub (outside pub naturaly) for drinking a good blue Chimay to position my idea back ;) ps: IMHO Chimay with bleu label is the best Belgian Beer, if you have the occasion to taste this delicious drink, do not hesitate one second :) From andy at smile.org.ua Thu Jul 13 13:37:53 2006 From: andy at smile.org.ua (Andy Shevchenko) Date: Thu, 13 Jul 2006 16:37:53 +0300 Subject: rpms/driftnet/FC-5 driftnet.spec,1.3,1.4 In-Reply-To: <44B61727.6050108@city-fan.org> References: <200607130941.k6D9fWYD032544@cvs-int.fedora.redhat.com> <44B61727.6050108@city-fan.org> Message-ID: <44B64CB1.7070900@smile.org.ua> Paul Howarth ?????: >> +++ driftnet.spec 13 Jul 2006 09:41:30 -0000 1.4 >> -Release: 9 >> +Release: 9.%{dist} Sorry Paul, I have not seen original post and I write here. Release tag should be smth like Release: 9%{?dist} -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From paul at city-fan.org Thu Jul 13 13:52:05 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 13 Jul 2006 14:52:05 +0100 Subject: rpms/driftnet/FC-5 driftnet.spec,1.3,1.4 In-Reply-To: <44B64CB1.7070900@smile.org.ua> References: <200607130941.k6D9fWYD032544@cvs-int.fedora.redhat.com> <44B61727.6050108@city-fan.org> <44B64CB1.7070900@smile.org.ua> Message-ID: <44B65005.9040709@city-fan.org> Andy Shevchenko wrote: > Paul Howarth ?????: >>> +++ driftnet.spec 13 Jul 2006 09:41:30 -0000 1.4 >>> -Release: 9 >>> +Release: 9.%{dist} > Sorry Paul, I have not seen original post and I write here. > Release tag should be smth like > Release: 9%{?dist} Yes, it should. The original post was from fedora-extras-commits, which has reply-to set to this list. Paul. From enrico.scholz at informatik.tu-chemnitz.de Thu Jul 13 19:30:45 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 13 Jul 2006 21:30:45 +0200 Subject: Wiki not editable? In-Reply-To: <87r70wjjyh.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Sat, 08 Jul 2006 15:37:58 +0200") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> Message-ID: <878xmxnvyy.fsf@kosh.bigo.ensc.de> enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) writes: > Ditto, I am not able to edit the > > http://fedoraproject.org/wiki/Packaging/UserCreation Ping. I still do not have permissions to edit this page. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From tibbs at math.uh.edu Thu Jul 13 20:08:10 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 13 Jul 2006 15:08:10 -0500 Subject: Wiki not editable? In-Reply-To: <878xmxnvyy.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Thu, 13 Jul 2006 21:30:45 +0200") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <878xmxnvyy.fsf@kosh.bigo.ensc.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> Ping. I still do not have permissions to edit this page. I have moved the page to http://fedoraproject.org/wiki/PackageDrafts/UserCreation. You should be able to edit that page; if not, please let me know. - J< From enrico.scholz at informatik.tu-chemnitz.de Thu Jul 13 20:32:38 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 13 Jul 2006 22:32:38 +0200 Subject: Wiki not editable? In-Reply-To: (Jason L. Tibbitts, III's message of "Thu, 13 Jul 2006 15:08:10 -0500") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <878xmxnvyy.fsf@kosh.bigo.ensc.de> Message-ID: <874pxlnt3t.fsf@kosh.bigo.ensc.de> tibbs at math.uh.edu (Jason L Tibbitts III) writes: > ES> Ping. I still do not have permissions to edit this page. > > I have moved the page to > http://fedoraproject.org/wiki/PackageDrafts/UserCreation. You should > be able to edit that page; if not, please let me know. thanks; works now. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Thu Jul 13 21:30:07 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 13 Jul 2006 23:30:07 +0200 Subject: Wiki not editable? In-Reply-To: <874pxlnt3t.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Thu, 13 Jul 2006 22:32:38 +0200") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <878xmxnvyy.fsf@kosh.bigo.ensc.de> <874pxlnt3t.fsf@kosh.bigo.ensc.de> Message-ID: <87zmfdmbvk.fsf@kosh.bigo.ensc.de> enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) writes: >> I have moved the page to >> http://fedoraproject.org/wiki/PackageDrafts/UserCreation. You should >> be able to edit that page; if not, please let me know. > > thanks; works now. ok... just fyi: I moved the page back to its original location mentioned in the fedora-usermgmt package too. This page does not belong into a "Drafts" category because it is not a draft but documentation about an existing package where I was too lazy to create an official project homepage about. I thought that Wiki would be a good place to maintain this documentation but I can move it into the package as %doc when requested. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From wart at kobold.org Thu Jul 13 22:01:20 2006 From: wart at kobold.org (Wart) Date: Thu, 13 Jul 2006 15:01:20 -0700 Subject: release tags during review Message-ID: <44B6C2B0.7010508@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is it allowed to use 0.n release tags during a package review, only to change it to '1' once the package has been approved and imported? - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEtsKvDeYlPfs40g8RAkv/AJ9pu2e5wmwSDC8T55B9rPtpam1CDgCeIrOt 2dVZ7rHc03C10KxJp+mu1og= =T419 -----END PGP SIGNATURE----- From tibbs at math.uh.edu Thu Jul 13 22:19:39 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 13 Jul 2006 17:19:39 -0500 Subject: release tags during review In-Reply-To: <44B6C2B0.7010508@kobold.org> (wart@kobold.org's message of "Thu, 13 Jul 2006 15:01:20 -0700") References: <44B6C2B0.7010508@kobold.org> Message-ID: >>>>> "w" == wart writes: w> Is it allowed to use 0.n release tags during a package review, only w> to change it to '1' once the package has been approved and w> imported? It is commonly done by a couple of people. It violates the naming guidelines, and if I didn't trust the packager I would want to see a package that meets the naming guidelines before approving. I wouldn't really recommend it. Is there some reason why the package imported into extras has to start with release 1? - J< From wart at kobold.org Thu Jul 13 22:26:09 2006 From: wart at kobold.org (Wart) Date: Thu, 13 Jul 2006 15:26:09 -0700 Subject: release tags during review In-Reply-To: References: <44B6C2B0.7010508@kobold.org> Message-ID: <44B6C881.1010007@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason L Tibbitts III wrote: >>>>>>"w" == wart writes: > > > w> Is it allowed to use 0.n release tags during a package review, only > w> to change it to '1' once the package has been approved and > w> imported? > > It is commonly done by a couple of people. It violates the naming > guidelines, and if I didn't trust the packager I would want to see a > package that meets the naming guidelines before approving. > > I wouldn't really recommend it. Is there some reason why the package > imported into extras has to start with release 1? No particular reason, other than I have a handful of packages ready for review that are already using 0.n. It might make it a little easier to distinguish changes made during the review from change made after the review in the changelog entries, but that's not very important. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEtsh/DeYlPfs40g8RAhKFAJ9WnM6jwNg4nTY5pJS1QbUHrVLRAQCcCzJV prSADgz8fAN+aMP2voBNisY= =lNKE -----END PGP SIGNATURE----- From mattdm at mattdm.org Thu Jul 13 23:52:48 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 13 Jul 2006 19:52:48 -0400 Subject: release tags during review In-Reply-To: References: <44B6C2B0.7010508@kobold.org> Message-ID: <20060713235248.GA27828@jadzia.bu.edu> On Thu, Jul 13, 2006 at 05:19:39PM -0500, Jason L Tibbitts III wrote: > w> Is it allowed to use 0.n release tags during a package review, only > w> to change it to '1' once the package has been approved and > w> imported? > It is commonly done by a couple of people. It violates the naming > guidelines, and if I didn't trust the packager I would want to see a > package that meets the naming guidelines before approving. I kind of like it because it signifies "this isn't the final package" if it "leaks" somewhere. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From zipsonic at gmail.com Fri Jul 14 00:13:31 2006 From: zipsonic at gmail.com (Rick Stout) Date: Thu, 13 Jul 2006 17:13:31 -0700 Subject: release tags during review In-Reply-To: <20060713235248.GA27828@jadzia.bu.edu> References: <44B6C2B0.7010508@kobold.org> <20060713235248.GA27828@jadzia.bu.edu> Message-ID: <44B6E1AB.2020104@gmail.com> > > I kind of like it because it signifies "this isn't the final package" if > it "leaks" somewhere. > Isn't it really supposed to be used only to signify a beta package? For example Foo 1.0 RC2 foo-1.0-0.RC2.fc5 then when 1.0 is released foo-1.0-1.fc5 Rick From rdieter at math.unl.edu Fri Jul 14 00:34:15 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 13 Jul 2006 19:34:15 -0500 Subject: release tags during review In-Reply-To: <44B6C2B0.7010508@kobold.org> References: <44B6C2B0.7010508@kobold.org> Message-ID: Wart wrote: > Is it allowed to use 0.n release tags during a package review, only to > change it to '1' once the package has been approved and imported? The short/official answer is no. Reviewers should insist that the reviewed package follow the packaging guidelines. -- Rex From toshio at tiki-lounge.com Fri Jul 14 05:04:27 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 13 Jul 2006 22:04:27 -0700 Subject: FESCo Meeting 2006 July 13 Minutes Message-ID: <1152853467.2701.4.camel@localhost> 2006 July, 13 FESCo Meeting =========================== Meeting Summaries are posted on the wiki at: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings Attending --------- * thl (Chair) * scop * jwb * spot * tibbs * abadger1999 * rdieter * c4chris * dgilmore Summary ------- * Josh Bowyer is the new FESCo VP. The VP's first task is being a backup if the chair cannot attend a meeting. * Mass rebuilds - We should rebuild after FC5t2 when glibc changes have settled in and we've confirmed that the buildsystem is using the reduced package set. - Add a file to the CVS tree to each package to mark that it hasn't been rebuilt for FC6 yet. The maintainer removes this when they rebuild the package or tells why it doesn't need rebuilding in the cvs log. * Election - thl will mail abadger1999 with some questions to look into. abadger1999 will do some research and report back to FECo. + One piece is election model. This time we used bloc voting. Should we have range voting, approval voting, or something else instead? * Ctrl-C Problem - scop will test the fix and see if the issue still exists. * Encourage Extras Reviews: - tibbs reports there are some new people doing reviews. - The wiki was unclear that all people sponsored are eligible to do reviews. - Will also mention that fedorabugs is needed to do reviews. - tibbs will modify the wiki to fix these. * Comaintainers - Needs someone to drive the issue and organize it into short term and long term goals. + short term: Fix bugzilla auto-CC in owners.list + long term: Items listed in thl's email. * These may tie into the new VCS, accounts, and package databases. * Getting new contributers via comaintainership. * Perhaps reviewers could automatically be made temporary comaintainers of the packages they review so they see that the packager is doing the right things to get it to build in the build system for the first time, etc. * SIGs can help comaintain where applicable. * Should comaintainers be mandatory? General feeling was they should be encouraged but not mandatory. * Security sensitive things should all have comaintainers. * AWOL Policy - http://www.fedoraproject.org/wiki/MikeKnox/AWOL_Policy - Changes: + Mention the Vacation Page. + Made expectations for an unsponsored packager taking over an existing package more realistic (They still need to prove their knowledge to a sponsor). + Add appropriate links to NewSponsorProccess, ReviewGuidelines, etc. - Policy approved with those changes. * Packaging Committee Report - Honoring $RPM_OPT_FLAGS added for arch specific packages. + Changed to say never for kmods. - New ChangeLog format is a must item. - It is permissible to have Release: [INT]%{?dist}.[INT] (period integer after the dist tag.) - dist tag harcoding was discussed and voted down (existing rules against continue to apply). - jpackage guidelines discussed and not voted on. - packages in Fedora SHOULD have ipv6 support and if they do not, the packager SHOULD open a bug in Red Hat Bugzilla that blocks an ipv6 tracker. They should also notify upstream. + This was vetoed. Resolution: * Clarify that this does not have to be tested. If it is *known* not to work then the bug is opened. * Put into a separate document: Recommendations for Software Packaged in Fedora instead of the Guidelines. The intention is that this document will be for software features rather than packaging. * The Packaging Committee is responsible for this document as well. * thl's recent email listing projects within FE is being maintained on the wiki: http://www.fedoraproject.org/wiki/ThorstenLeemhuis/RecapitulateStateOfExtras - Schedule time to look parel out ideas from there for people to work on. - Share some ideas with Infrastructure to keep things moving there. IRC Log ------- :: (10:00:22) thl has changed the topic to: FESCo meeting in progress -- init (10:00:29) thl: who's around from fesco? (10:00:30) ***scop boots (10:00:36) jwb: me me me (10:00:40) ***spot is here (10:00:41) tibbs: I'm around. (10:00:48) abadger1999: 3/4 here (10:00:52) rdieter: here (10:00:54) spot: gimme a minute to make the notes from FP (10:01:08) ***c4chris_ waves (10:01:15) thl: spot, we'll do that after we're gone trough all topics with priority "1" (10:01:26) thl: well, then let's start slowly (10:01:35) spot: ok (10:01:35) thl has changed the topic to: FESCo meeting in progress -- VP (10:01:50) thl: okay, so who want's the job now? (10:02:05) jwb: i said i would take it if nobody else wanted to (10:02:09) thl: "frearless leader backup" (10:02:25) ***jima loves the "fearless leader" line ;) (10:02:45) thl: any other (self?) nominations? (10:02:58) c4chris_: we like jwb :) (10:03:02) thl: seems no (10:03:09) ***dgilmore is here (10:03:11) thl: so jwb for vp get a +1 from me (10:03:17) c4chris_: +1 (10:03:17) scop: +1 (10:03:21) abadger1999: +1 (10:03:23) jima: +1 (rabble) (10:03:26) rdieter: jwb++ (10:03:31) tibbs: +1 (10:03:38) dgilmore: +1 (10:03:45) jima: jwb = screwed (10:03:47) thl: okay, seems we're in agreement (10:03:49) jwb: heh (10:03:53) thl: jwb, you lost ;-) (10:04:07) jwb: that's ok. i'm used to running meetings ;) (10:04:17) thl: okay, so let's move on (10:04:31) thl has changed the topic to: FESCo meeting in progress -- Mess-Rebuild for FC6 (10:04:38) thl: I added that to the topic (10:04:46) thl: we should slowly plan what to do (10:04:49) c4chris_: intended type? (10:04:54) thl: we don't need decisions today (10:04:58) dgilmore: it needs to be done earlier than it was in fc5 i think (10:05:04) c4chris_: s/type/typo/ doh (10:05:26) jwb: dgilmore, i agree (10:05:30) thl: c4chris_, which typo (me often does typos....) (10:05:41) c4chris_: s/Mess/Mass/... (10:05:42) jima: c4chris_: ssshhh, you could have pretended that was ironic. (10:05:45) thl: ping jeremy, f13, warren (10:05:50) thl: c4chris_, ohhhh :) (10:06:03) thl: no, not intended, but a nice one :) (10:06:10) c4chris_: yup :) (10:06:13) thl has changed the topic to: FESCo meeting in progress -- Mass-Rebuild for FC6 (10:06:33) jwb: perhaps start rebuilding after test2 releases (10:06:35) thl: jeremy, f13, warren, when can we start rebuilding Extras for FC6? (10:06:48) thl: I suppose when the current mass-rebuild is done? (10:06:48) c4chris_: I think a rebuild is a good thing (10:06:52) scop: I have mixed feelings about it (10:06:58) thl: e.g. after FC6T2? (10:07:06) dgilmore: jwb: probably best time. I hope that our big glibc change will have settled down by then (10:07:17) scop: all packages for which it makes sense need to be rebuilt (10:07:29) jwb: scop, meaning all non-noarch? (10:07:37) scop: not necessarily (10:07:57) scop: think eg. versioned dirs (10:07:57) thl: scop, "--verbose" ? (10:08:37) scop: the other side of the "mix" is that a mass rebuild is a lost opportnity for catching awol maintainers (10:08:54) c4chris_: in cases where maintainer doesn't want to rebuild, I'd like to at least see a message stating "no rebuild for foo.." (10:09:06) wart-cellphone [n=upirc] entered the room. (10:09:06) scop: regarding versioned dirs, think eg. a perl 5.8.x -> perl 6.x upgrade (10:09:08) ***thl likes catching awol maintainers with a manual mass rebuild as we did for FC5 (10:09:26) jwb: thl, yeah that was a good point (10:09:28) scop: I like that too (10:09:32) jima: i agree with it being manual (10:09:42) warren: huh!? (10:09:42) jwb: c4chris, and maybe _why_ they don't want to rebuild (10:09:46) warren: we went to perl 6.x? (10:09:50) jima: now's a great time to find the AWOL people (10:09:51) thl: c4chris_, could a tag in cvs be used? (10:09:55) tibbs: Who doesn't love to stress test the build system? (10:10:02) scop: warren, it was just a hypothetical example, don't worry ;) (10:10:12) _wart_ left the room (quit: "Download Gaim: http://gaim.sourceforge.net/"). (10:10:15) thl: btw, regarding the mass-rebuild (10:10:16) c4chris_: thl: ? (10:10:37) warren: If we want to catch AWOL maintainers, the best way to do that is to ask the maintainers themselves to launch the rebuilds of their own packages. (10:10:39) thl: do the builders use the reduced package set yet? (10:11:00) c4chris_: jwb: that would be good, yes (10:11:04) tibbs: thl: do you mean, check in a file to CVS that the maintainer removes when they rebuild? (10:11:14) dgilmore: warren: thats the way it was done for fc5 (10:11:20) ***jwb steps away for 2 seconds (10:11:23) thl: c4chris_, regarding: 'I'd like to at least see a message stating "no rebuild for foo.."' -- maybe we could use cvs for it (10:11:26) dgilmore: thl: we should make sure that is the case (10:11:33) thl: dgilmore, agreed (10:11:42) c4chris_: thl: ah, ok (10:11:56) c4chris_: thl: why not. (10:12:01) thl: tibbs, mmmm, yes, that could work, but it's probably a lot of noise (10:12:21) scop: use dead.package for the marker? ;) (10:12:32) c4chris_: scop: :) (10:12:50) c4chris_: commatose ? (10:12:50) thl: or a file "rebuild.me" ;-) (10:13:07) ***jwb is back (10:13:41) c4chris_: that might get quite noisy on the ml, though... (10:13:54) thl: warren, who is our contact for the buildsys atm? (10:14:03) warren: thl, good question... (10:14:05) scop: I think the idea of using a file in CVS is worth trying (10:14:09) thl: warren, the infrastructure group? skvidal? dcbw? (10:14:25) jwb: file to mark for rebuild or no rebuild though? (10:14:29) thl: warren, we should soon switch to the reduced package set in the default buildroot (10:14:35) scop: the commit message can then explain stuff if a rebuild is not needed (10:14:43) dgilmore: thl it would be the infrustructure team (10:15:01) dgilmore: thl i can bring it up in the fedora-admin meeting this afternoon (10:15:09) thl: dgilmore, great, thx (10:15:18) scop: no file (cvs rm'd) means "done, rebuilt" (10:15:27) scop: or "done, does not need to be rebuilt" (10:15:27) thl: dgilmore, what about plague? does it need a update, too? (10:15:36) thl: I lost track on the diffferent plague versions (10:15:39) c4chris_: scop: I like the idea (10:15:46) warren: thl, kind of skvidal (10:15:51) jwb: scop, and who puts the file there in the first place? (10:15:51) dgilmore: thl: plague wont need an update but its mock configs might (10:15:55) warren: thl, infrastructure group is capable of helping (10:16:12) scop: jwb, whoever, for example I can volunteer for that (10:16:18) thl: dgilmore, you you handle that task? poke skvidal if he needs to do something? (10:16:23) jwb: scop, ok just checking (10:16:28) dgilmore: thl: sure (10:16:32) thl: dgilmore, tia (10:16:50) jwb: i like the rebuild.me file in CVS as well (10:17:20) ***thl likes rebuild.me file in CVS as well (10:17:32) scop: it should probably be added after CVS is branched for FC-6, right? (10:17:33) thl: but we need to define which arch packages really need a rebuild (10:17:41) abadger1999: jwb: As in a file that asks some automated process to rebuild it? (10:17:46) thl: scop, why? (10:17:56) c4chris_: abadger1999, no: asks the maintainer (10:18:03) thl: scop, we normally branch when FC6 ships -- that a bit late for a mass rebuild (10:18:06) jwb: abadger1999, no as in a file that maintainers remove when they rebuild (or say why they aren't) (10:18:07) abadger1999: Okay. that's fine. (10:18:16) scop: thl, okay, that would be too late indeed, then (10:18:33) c4chris_: why not branch sooner ? (10:18:43) thl: c4chris_, why should we? (10:18:48) jwb: c4chris_, coordination with Core is best (10:18:51) thl: is there any need? (10:18:53) thl: jwb, +1 (10:19:11) jwb: i say the rebuild starts after FC6T2 (10:19:17) c4chris_: oh, I thought core did a kind of frozen branch already... (10:19:17) thl: jwb, I (10:19:29) thl: jwb, I'd like to have a ACk from Jeremy first (10:19:33) skvidal: thl: what am I being poked for? (10:19:35) jwb: thl, sure (10:19:43) c4chris_: I agree we should not branch before Core (10:19:47) thl: skvidal, nothing (yet) (10:19:52) dgilmore: skvidal: minimal buildroots if needed (10:20:04) skvidal: dgilmore: okay - just for anything infrastructure-related (10:20:14) skvidal: email admin at fedoraproject.org or file a ticket in otrs (10:20:26) skvidal: that way things don't block on me (10:20:26) dgilmore: skvidal:will do if we need you (10:20:33) skvidal: okie doke (10:20:35) thl: okay; then let's stop here now (10:20:36) ***skvidal goes back to hiding (10:20:47) scop: skvidal, what's the role of "fedora infrastructure" in bugzilla? (10:20:48) thl: and proceed next week (10:21:03) skvidal: scop: in bugzilla? (10:21:08) c4chris_: thl, k (10:21:10) thl: someone should own this task -- e.g. poke jeremy for informations and mail to the list (10:21:17) thl: any volunteers? (10:21:28) dgilmore: thl: Ill do it (10:21:33) scop: skvidal, grep for infrastructure at https://bugzilla.redhat.com/bugzilla/enter_bug.cgi (10:21:35) thl: we also need to know which packages really need a rebuild (and which one not) (10:21:44) thl: dgilmore, k (10:21:55) skvidal: scop: oh - I dunno - we still get those - I think we've been pushing more things to otrs (10:22:12) ***thl will move on soon (10:22:17) scop: skvidal, ok (10:22:27) scop: it's not too prominent I think, though (10:22:31) thl has changed the topic to: FESCo meeting in progress -- Next FESCo future/election (10:22:41) thl: someone should own this task, too (10:22:42) skvidal: scop: it just started being used (10:22:51) skvidal: scop: give it a bit more time (10:22:56) thl: e.g. analyse the last election (10:23:03) thl: write down how we did it (10:23:10) thl: when the next one is planed (10:23:13) ***spot starts to burn his stuffed ballots (10:23:13) thl: and all that stuff (10:23:22) thl: any volunteers? (10:23:39) jwb: i think abadger1999 and spot are the logical choices. they did most of the work :) (10:23:47) ***scop aims spot with a bucketful (10:23:53) spot: abadger1999 did most of the work. :) (10:23:54) abadger1999: Sure, I'm up for it. (10:24:04) thl: abadger1999, thx (10:24:05) spot: most of my code was thrown away (and rightfully so) (10:24:13) thl: abadger1999, there is no need to hurry (10:24:17) abadger1999: What sorts of things do we want to know/do? (10:24:39) abadger1999: How to make the app better? (10:24:39) thl: but I'd like to get this done until end of august? that okay? (10:24:44) abadger1999: How to publicise more? (10:25:05) thl: the app worked fine afaics (10:25:11) scop: who voted for himself ;) (10:25:37) thl: abadger1999, but do we need another vote-model next time (don#t know if that's the proper describtion) (10:25:44) spot: i voted for pat buchanan by mistake. the ballot was confusing. ;) (10:25:57) skvidal: spot: I want to hang chad (10:26:01) thl: e.g. a model more like "you can vote for as many members as you like and those with the most votes get in?" (10:26:07) abadger1999: The database is designed for reuse, the app needs to be modified to do that. (10:26:22) abadger1999: thl: Oops. Misundertood the question. (10:26:22) thl: I don't know if that would be better (10:26:41) abadger1999: ... But it has the same answer. (10:26:47) thl: :) (10:26:55) jwb: we have to decided how many seats are up for re-election too. still 1/2? or all? (10:27:07) thl: abadger1999, I'll send you a main in private with some of my thoughts (10:27:13) thl: let's stop here for today (10:27:22) abadger1999: thl: Sounds good. (10:27:28) thl has changed the topic to: FESCo meeting in progress -- CTRL-C problem (10:27:31) scop: (all++) (10:27:42) thl: well, it should be fixed (or a lot harder to trigger) (10:27:49) warren: Only requires testing (10:27:53) thl: but no one tested it yet (10:28:13) c4chris_: did Hans try again (10:28:18) thl: any volunteer? or do we trust Sopwith that he did the right thing (10:28:28) scop: I'll do some testing (10:28:47) thl: hans triggered it only once accidentally -- he didn#t want to try it again (10:28:52) thl: scop, thx (10:28:55) c4chris_: oh (10:28:56) tibbs: Hans is on vacation; I never could make it happen myself. (10:28:58) ***thl will move on (10:29:14) thl has changed the topic to: FESCo meeting in progress -- Encourage Extras reviews (10:29:21) thl: standing item... (10:29:29) tibbs: We have had a couple of new reviewers lately, which is good. (10:29:42) thl: I think we can skip this for today if no one disagrees? (10:29:51) thl: or are there any new magic ideas how to make it better? (10:29:54) scop: ++ (10:29:57) tibbs: No objection from me. (10:29:58) scop: (skip) (10:29:59) c4chris_: fine with me (10:30:00) thl: ohh, well, there is one thing (10:30:17) ***dgilmore has no new ideas (10:30:21) thl: tibbs, it seems it's not cleanly documented that all sponsored people can review packages (10:30:34) thl: tibbs, at least one rh guy didn't know that (10:30:45) tibbs: Really? Where should that be documented? (10:30:48) thl: tibbs, could you please check if that in the proper places in the wiki? (10:31:06) thl: and if not: could you please add it on a public place? (10:31:13) thl: tibbs, don't know (10:31:18) tibbs: You need to get fedorabugs before you can actually do anything, correct? (10:31:19) c4chris_: where did the rh guy not find it ? (10:31:27) scop: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines#head-e1a114b2 3499786e13113ebf072d03a8f8d02094 (10:31:36) RTLM [n=RTLM] entered the room. (10:31:57) tibbs: PackagingGuidelines and ReviewGuidelines are all conflated at the moment. (10:32:07) nphilipp left the room (quit: "Leaving"). (10:32:12) thl: it happend here: https://www.redhat.com/archives/fedora-music-list/2006-July/msg00012.h tml (10:32:13) c4chris_: tibbs, to assign tickets, yes (10:32:42) tibbs: And fedorabugs doesn't come with cvsextras, so technically all sponsored folks can't do reviews. (10:33:07) thl: tibbs, maybe the docs can be improved a bit? (10:33:16) tibbs: They have to ask for one more thing. I wonder why fedorabugs pending members don't generate a daily mail like cvsextras pending sponsorships? (10:33:28) tibbs: thl: no kidding. (10:33:29) thl: tibbs, Sopwith should know (10:33:35) c4chris_: tibbs, I think you're right... One more thing for the Grand Unified Access thingy (10:33:52) _wart_ [n=wart] entered the room. (10:34:01) tibbs: I'll try to at least add another step to the 9-million step contributor process document. (10:34:14) thl: tibbs, thx (10:34:21) ***thl will move on (10:34:36) thl has changed the topic to: FESCo meeting in progress -- Co-maintainership (10:34:43) thl: has no owner (10:35:05) tibbs: Isn't everything in place except for the "bugzilla auto-CC's folks" thing? (10:35:05) thl: and is a major task that should be spitted into short term goals (10:35:11) thl: and long term goals (10:35:20) thl: short term: fix "bugzilla auto-CC's folks" (10:35:24) scop: https://bugzilla.redhat.com/198109 (10:35:37) scop: --> Sopwith (10:35:50) thl: long term: the things I mentioned in my "Recapitulate the current state..." mail (10:35:50) nim-nim [n=nim-nim] entered the room. (10:36:09) tibbs: We do have to decide if co-maintainers are mandatory or not. (10:36:27) dgilmore: thl: i think its part of the review infrustructure is doing of accounts system. and VCS (10:36:33) rdieter: mandatory-- (10:36:38) abadger1999: I'd say no to mandatory. (10:36:38) scop: mandatory-- (10:36:44) dgilmore: one VCS goal is stricter permissions on the whole VCS tree (10:36:55) thl: I's say 90% of the packages should have co-maintainers (10:37:06) rdieter: why? (10:37:06) thl: but mandatory probably won't work (10:37:11) dgilmore: - to manadatory (10:37:20) dgilmore: + to would be nice to have (10:37:22) c4chris_: encourage, but not mandatory (10:37:25) abadger1999: It might be nice if reviewers were something like comaintainers. (10:37:29) thl: rdieter, people are on vacation, people are offline (10:37:37) abadger1999: Perhaps for a limited time. (10:37:45) rdieter: you're right "should" is always nice. (10:37:56) tibbs: abadger1999: reviewers or sponsors. (10:38:18) abadger1999: I was thinking reviewers. (10:38:33) thl: abadger1999, yeah, I thing getting new contributors via co-maintainership might be a good idea in the longer term (10:38:35) tibbs: But as a reviewer I often know very little about a package. I'm just checking the form, whether it installs and maybe if I can make it do something. (10:38:59) thl: I also think people with more then 20 packages should hand over some of their packages to new contributors (10:39:01) rdieter: tibbs: right, it won't work for everyone, but it's a good place to start. (10:39:09) abadger1999: True, but you know more about it than the packager's sponsor. (10:39:30) tibbs: abadger1999: That's a reasonable point. (10:39:33) ChitleshGoorah left the room (quit: Remote closed the connection). (10:39:46) abadger1999: And it could be good to automatically be watching the new package as it takes its first steps of import and first few passes through the build system. (10:39:54) tibbs: Ideally everyone involved would help out anyway. (10:40:35) abadger1999: tibbs: You're correct there. (10:40:43) tibbs: So now we have this big nebulous idea of cosponsorship. (10:40:56) c4chris_: maybe a dating wiki page... (10:41:26) tibbs: Everyone involved in getting the package in can help, but really the reviewer and sponsor aren't going to be able to do much by next year. (10:41:53) c4chris_: thl, do you have a list of packages you'd really like to see co-maintained? (10:41:58) tibbs: SIG members can help for those packages where SIGs apply. (10:42:24) thl: c4chris_, no, I think that co-maintaining packages is a good idea per se (10:43:03) tibbs: I'd like to see security-sensitive things have co-maintainers as soon as is reasonable. (10:43:04) thl: maybe I should write up all my thoughs on this and post them to the list (10:43:13) tibbs: Internet-facing daemons and web apps and such. (10:43:53) thl: let's stop here for today (10:44:07) thl: it remains on the shedule and won't get lost ;-) (10:44:22) thl has changed the topic to: FESCo meeting in progress -- AWOL Policy (10:44:34) thl: http://www.fedoraproject.org/wiki/MikeKnox/AWOL_Policy to be precise (10:44:53) thl: so, what do we do with it? do we like it? any proposed modifications? (10:44:57) jwb: i liked it (10:45:33) jwb: i used something quite similar to it for one of the packagers i sponsored and it worked well (10:45:52) tibbs: I like it too, but it needs to mention the Vacation page or have some way for folks to indicate that they're going to be away. (10:46:08) jwb: true (10:46:12) tibbs: I know I can be out of pocket for three weeks or more if I go out of the country. (10:46:30) thl: what about the "- If you are a not an existing Extras contributor, you can still take over..." para? (10:46:32) scop: the only slight problem I have with it is the new contributor stuff (10:46:34) thl: do we want that? (10:46:51) thl: or do we let that out for now? (10:46:53) jwb: why not? it has to go through a full review (10:46:57) c4chris_: thl, yes, that's my main gripe about the proposition (10:47:08) scop: but then again, we already must trust our sponsors to be able to judge who they consider worth sponsoring (10:47:08) tibbs: But there's the sponsorship angle as well. (10:47:13) c4chris_: jwb, but it's already in good shape from the start (10:47:27) jwb: c4chris, so? (10:47:40) tibbs: The problem is that taking over a package is going to give the sponsors absolutely zero to go on. (10:47:50) scop: just resubmitting it doesn't show whether the resubmitter possesses "enough" clue (10:48:02) jwb: i see it as being no different from a brand new package that is in good shape (10:48:03) c4chris_: jwb, how do you know the submitter knows the packaging rules? (10:48:18) abadger1999: I think we take it out. (10:48:23) jwb: c4chris_, and how do you know the submitter knows the packaging rules for a brand new package? (10:48:36) c4chris_: jwb, true (10:48:42) abadger1999: jwb: In this case we _know_ that the new packager was able to crib from an existing package. (10:48:46) tibbs: jwb: You see how they react to review comments. (10:48:57) jwb: one can take a package from DAG, put it up for review and have _no_ issues with it (10:48:58) c4chris_: but then, I noticed many sponsors wait for a couple more packages... (10:49:10) tibbs: jwb: That's a rather optimistic statement. (10:49:12) scop: jwb, unlikely ;) (10:49:22) c4chris_: and it's not too hadr to check whether good specs are already available or not (10:49:23) jwb: ok, poor example but you know what i mean :) (10:49:55) ***thl would not sponsor someone that only took over an old package from Extras where the maintainer is MIA/AWOL (10:50:01) jwb: i'm not opposed to ommitting it. i just don't think it's necessary to (10:50:07) ***scop already tried it once and won't try again (10:50:31) thl: we can leave that para in (10:50:32) abadger1999: I think we should have a policy for unsponsored packagers to take over packages but it should be a general part of becoming a new packager rather than the AWOL policy. (10:50:36) thl: and see if it works (10:50:42) tibbs: The sponsorship thing is never going to be perfect, but in this case I think the takeover request would just sit around waiting for a sponsor forever, which wouldn't improve the situation at all. (10:50:45) thl: and change it later if it doesn't (10:51:00) c4chris_: thl, k (10:51:13) rdieter: thl++ (10:51:13) thl: abadger1999, I think co-maintaing is the way to get that realized (10:51:16) dgregor left the room (quit: "Leaving"). (10:51:25) c4chris_: we need to trust the sponsors (10:51:27) abadger1999: thl: I agree. (10:51:27) dgilmore: every so often ill be out of the country for 2-3 weeks (10:51:35) abadger1999: (with comaintainership) (10:51:36) scop: c4chris_++ (10:51:36) thl: so, okay, just to be sure (10:51:42) thl: do we agree on http://www.fedoraproject.org/wiki/MikeKnox/AWOL_Policy (10:51:48) thl: it get's a +1 from me (10:51:48) jwb: +1 (10:51:52) rdieter: +1 (10:51:52) c4chris_: +1 (10:51:56) abadger1999: I don't think we should leave the woding of the AWOL policy the way it is. (10:52:06) scop: I would like "the process should be swift" removed (10:52:11) abadger1999: too optimistic for the unsponsored packager. (10:52:17) abadger1999: scop: Yes. (10:52:33) thl: scop, agreed (10:52:38) jwb: sure (10:52:39) ***thl removes it (10:53:14) thl: removed (10:53:16) abadger1999: Maybe mention that normal sponsorship rules apply? (10:53:16) wart-cellphone left the room (quit: Connection timed out). (10:53:51) thl: abadger1999, "This will allow the normal review process to happen. " is the last sentence atm (10:54:00) thl: what means "that normal sponsorship rules apply" afaics (10:54:07) thl: or not? (10:54:34) abadger1999: "...including finding a sponsor that believes you understand the packaging rules." (10:54:36) scop: s|review process|review/sponsorship process| (10:54:38) tibbs: Might be nice to assume they don't have a photographic memory of the process and include some links. (10:54:40) abadger1999: Append something like that? (10:54:52) thl: abadger1999, okay for me (10:54:56) c4chris_: abadger1999, yes (10:54:59) thl: other opinions? (10:55:06) jwb: fine with me (10:55:24) tibbs: Seems good to me after those changes. (10:55:35) abadger1999: +1 with those changes. (10:56:34) jwb: btw, who's doing the minutes this week? (10:56:38) thl: okay, committed (10:56:45) tibbs: Seems to only be five votes. (10:56:55) thl: so, once again (10:57:04) thl: everyone satisfied with http://www.fedoraproject.org/wiki/MikeKnox/AWOL_Policy now? (10:57:09) scop: "...that believes you understand what is expected from FE package maintainers" (10:57:09) tibbs: +1 (10:57:10) thl: get's a +1 from me (10:57:10) c4chris_: +1 (10:57:12) jwb: +1 (10:57:12) rdieter: +1 (10:57:30) jwb: abadger1999, ? (10:57:37) abadger1999: +1 (10:57:38) ***thl needs to leave in 5 - 10 minutes (10:57:43) abadger1999: (slow reader) (10:57:44) scop: +1 (10:57:54) thl: scop, we can add that later if we need to (10:58:02) jwb: that's 7 (10:58:08) scop: yep, I'm just thinking aloud (10:58:09) thl: we don#t need to discuss such minor details now IMHO (10:58:20) thl: scop, and that's a good thing ;-) (10:58:43) tibbs: Packaging committee summary? (10:58:46) thl: okay, settled (10:58:54) jwb: tibbs, yeah. spot? (10:58:59) thl: hehe (10:59:05) spot: ok (10:59:06) thl: I'm doing the meeting here ;-) (10:59:14) spot: are you ready for me? :) (10:59:18) thl: IPv6 Support in Extras is on the schedule (10:59:19) tibbs: Sorry, I'm lagging badly at the moment. (10:59:28) thl: but I'd like to skip that because we run late (10:59:30) jwb: thl, i'll take it and ask it to be deferred to next week (10:59:31) thl: okay? (10:59:40) scop: thl, that was covered in the packaging committee meeting too (10:59:43) abadger1999: [spot enters stage right] (10:59:53) jwb: scop, it's more than just packaging IMHO though (10:59:58) thl has changed the topic to: FESCo meeting in progress -- Packaging Committee Report (11:00:02) scop: jwb, yes, definitely (11:00:03) thl: spot, shoot (11:00:10) spot: from todays FP meeting (11:00:23) spot: - Honoring of $RPM_OPT_FLAGS (for arch specific packages) will be explicitly mentioned in packaging/review guidelines (11:00:34) spot: - PackagingDrafts/Changelog is a MUST (11:00:48) spot: - all packages in Fedora SHOULD have ipv6 support, if they do not, the maintainer SHOULD open a bug in red hat bugzilla and notify upstream. this bug should block an ipv6 bug. (11:01:07) spot: - %{?dist}. is permitted for single dist updates (11:01:12) ***thl likes to add that kmod's should *not* honor $RPM_OPT_FLAGS (at least iirc) (11:01:23) spot: thl: good point (11:01:27) scop: kmods MUST not honor them (11:01:29) spot: - No changes to the dist tag rules were made, thus hardcoding dist in a spec is still not permitted. (11:01:43) spot: - Jpackage changes to existing guidelines were deferred for more discussion before a vote (11:01:47) jwb: spot, that's somewhat contentious (11:01:55) jwb: (the dist tag thing) (11:02:00) thl: I'd like to veto "SHOULD have ipv6 support" for now (11:02:12) thl: I'm not sure that should be in the packaging guidelines (11:02:22) thl: doesn't that open the door for a lot of other rules? (11:02:27) jwb: thl, i agree (11:02:32) _wart_: thl +1 (11:02:33) scop: like UTF-8 support? (11:02:40) thl: scop, for example (11:02:42) c4chris_: thl, I don't like it that much either (11:02:50) thl: I agree that both things are good in general (11:03:01) thl: but the guidelines get longer and longer and move complicated (11:03:03) _wart_: But if the ipv6 rule is adopted, I'd like to see a detailed page describing how to setup and test a package for ipv6 support. (11:03:03) rdieter: I see nothing wrong with documenting lack of utf-8 support either. (11:03:05) scop: but you don't think UTF-8 support is a SHOULD??? (11:03:08) thl: I'd like to keep such things out (11:03:18) spot: jwb: the dist tag rules have _always_ said that you cannot hardcode dist. (11:03:33) spot: jwb: the committee felt that there was no reason to alter this (11:03:39) rdieter: The proposed guideline doesn't say you have to test for ipv6 support, only to document known non-working. (11:03:39) thl: scop, sure it's a should -- but does it to be defined in the packaging guidelines? (11:03:40) jwb: spot, i misread that. ignore me (11:04:05) scop: thl, I don't care which guidelines it's in, but it should definitely be somewhere (11:04:07) _wart_: rdieter: so if you don't know if it works or not, you don't have to document anything? (11:04:08) jwb: rdieter, and how does one know without testing? (11:04:13) scop: "feature guidelines"? (11:04:18) rdieter: _wart_: right. (11:04:23) thl: "package guidelines" (11:04:29) thl: but not "packaging guidelines" (11:04:30) jwb: scop, yes that is what i was going to propose. or a SIG (11:04:36) rdieter: Jwb: you don't. (11:04:37) jwb: or both (11:04:40) scop: okay, I'm fine with that (11:05:00) dgilmore: id like to +1 ipv6 support (11:05:07) jwb: basically i think this isn't a _packaging_ issue at all, but a feature issue (11:05:21) thl: spot, would "package guidelines" be okay for you? (11:05:26) spot: thl: sure. (11:05:30) jwb: thl, sure (11:05:39) scop: "package" and "packaging" are too close, confusing (11:05:45) c4chris_: thl, I like that much better (11:05:45) abadger1999: scop: ++ (11:05:47) thl: scop, yeah... (11:05:47) tibbs: "Best practices for Fedora Packages"? (11:06:05) ndim: "Debian Policy" :) (11:06:06) thl: "Best practices for Software packaged in Fedora"? (11:06:15) jwb: yeah (11:06:16) scop: it's not a practice... (11:06:35) ***scop parrots "feature" (11:06:35) c4chris_: Recommendations (11:06:37) nacc_home left the room. (11:06:54) thl: "Recommendations for Software packaged in Fedora" (11:07:00) thl: spot, that okay for you? (11:07:01) scop: works4me (11:07:05) jwb: i like that (11:07:09) spot: sure. (11:07:26) jwb: spot, so you'll take this back to the PC and ask that to be removed? (11:07:27) tibbs: Now the question remains: is this still in the packaging committee's baliwick? (11:08:01) ***scop looks up baliwick (11:08:02) ***thl thinks the packaging comitte should also maintain the "Recommendations for Software packaged in Fedora" (11:08:08) rdieter: imo, yes. (11:08:15) spot: i think the packaging committee can handle it (11:08:17) jwb: i'm fine with that (11:08:25) c4chris_: fine (11:08:28) tibbs: scop: don't bother; I can't even spell it correctly. (11:08:33) jwb: as long as they're 2 separate docs (11:08:36) scop: tibbs, I noticed ;) (11:08:44) spot: jwb: yup. (11:09:05) thl: k, anything else from the packaging committee? (11:09:29) thl: seems not... (11:09:31) thl has changed the topic to: FESCo meeting in progress -- Weekly sponsorship nomination (11:09:35) thl: any nominations (11:09:40) thl: you have 30 seconds (11:09:41) scop: one more related thing to the previous (11:10:00) tibbs: No nominations from me.... (11:10:09) scop: was there an official annoucement about the FPC role/process anywhere as discussed on fab-list? (11:10:25) jwb: scop, not outside of that list afaics (11:10:49) scop: okay, it should be posted somewhere more prominent (11:10:57) jwb: -maintainers? (11:11:24) scop: that'd be better, yes. can you poke jeremy about it? (11:11:49) jwb: sure (11:11:50) thl: k, no nominations (11:12:01) thl has changed the topic to: FESCo meeting in progress -- free discussion (11:12:13) thl: anything else we should discuss today? (11:12:14) ***c4chris_ needs to run soonish... (11:12:25) jwb: FYI, i'll be out the next 2 weeks (11:12:32) jwb: vacation (sister is getting married) (11:12:36) c4chris_: update Vacations page ? (11:12:43) jwb: c4chris_, will do (11:12:55) c4chris_: have a good one! (11:12:59) jwb: thx :) (11:13:18) thl: btw, I maintain a slightly enhanced variant of my "Recapitulate the current state of Fedora Extras..." mail at http://www.fedoraproject.org/wiki/ThorstenLeemhuis/RecapitulateStateOf Extras (11:13:28) thl: maybe we should go though it somewhen (11:13:40) thl: and discuss on what points we want to work (11:13:45) skvidal: thl: do you mean capitulate? (11:13:48) thl: and which ones we want to ignore (11:13:58) thl: skvidal, :) (11:14:05) skvidal: http://dictionary.reference.com/browse/capitulate (11:14:18) skvidal: b/c to recapitulate means to surrender, again (11:14:35) skvidal: ah, wait (11:14:37) scop: and summarize? (11:14:37) skvidal: it does not (11:14:40) skvidal: and summarize (11:14:41) skvidal: weird (11:14:46) ***skvidal loathes english sometimes (11:14:56) c4chris_: skvidal, :-) (11:14:59) skvidal: I'd only ever heard it used as 'surrender' (11:15:25) thl: maybe my dictionary drove me into the wrong direction (11:15:27) thl: sorry (11:15:34) skvidal: thl: no, you're completely correct (11:15:40) skvidal: just not the usage I'm familiar with (11:15:44) ***skvidal goes back to being quiet (11:15:47) thl: the dictionary was correct (11:16:08) c4chris_: ah well, might come from the french side... (11:16:29) ***thl afk for two minutes (11:17:29) nim-nim: Recapitulate comes from the french word "capitulations" (11:17:45) nim-nim: the list of conditions two parties agreed before one surrendered (11:18:03) tibbs: So has anyone seen any package submitters who they think should be sponsored? (11:18:07) nim-nim: capitulate has inherited the surrender part (11:18:20) abadger1999: thl: Nice link. I think we need to push some of those up to Infrastructure. (11:18:21) nim-nim: recapitulated has inherited the listing part (11:18:39) nim-nim: and no one remembers what capitulations are anymore (11:18:41) ***thl back (11:18:46) scop: http://www.m-w.com/dictionary/capitulate (11:18:49) scop: http://www.m-w.com/dictionary/recapitulate (11:19:12) thl: abadger1999, yes, we need a lot of help from the Infrastructure group (11:19:31) thl: anyway (11:19:36) thl: let's stop here for today (11:19:40) thl: and close the meeting (11:19:49) ***thl will close the meeting in 30 (11:19:58) thl: btw, who writes the summary? (11:20:11) abadger1999: I'll write the summary. (11:20:18) thl: abadger1999, tia (11:20:20) scop: do I remember abad... never mind ;) (11:20:34) ***thl will close the meeting in 10 (11:20:44) ***c4chris_ goes for dinner now. See ya all later :) (11:20:45) thl: MARK -- Meeting end (11:20:50) thl: thx everyone (11:20:55) tibbs: Off to lunch.... (11:20:55) c4chris_: thx (11:21:07) ***scop goes practice some Ctrl+C's (11:21:22) thl has changed the topic to: "This is the Fedora Extras channel, home of the FESCo meetings and general Extras discussion. | http://fedoraproject.org/wiki/Extras | Next FESCo Meeting: 2006-07-20 1700 UTC" (11:21:37) thl: scop, have fun :) (11:21:45) ***thl afk now (11:22:22) scop left the room ("Leaving"). -------------- 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 at knox.net.nz Fri Jul 14 05:22:41 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 14 Jul 2006 17:22:41 +1200 Subject: FESCo Meeting 2006 July 13 Minutes In-Reply-To: <1152853467.2701.4.camel@localhost> References: <1152853467.2701.4.camel@localhost> Message-ID: <44B72A21.8070901@knox.net.nz> Toshio Kuratomi wrote: > 2006 July, 13 FESCo Meeting > =========================== [snip] > * AWOL Policy > > - http://www.fedoraproject.org/wiki/MikeKnox/AWOL_Policy > - Changes: > > + Mention the Vacation Page. > + Made expectations for an unsponsored packager taking over an > existing package more realistic (They still need to prove their > knowledge to a sponsor). > + Add appropriate links to NewSponsorProccess, ReviewGuidelines, > etc. > > - Policy approved with those changes. > Sweet! Thanks everyone that helped out with this. After making the requested changes, where will the policy live? I guess under http://fedoraproject.org/wiki/Extras some place? Michael From panemade at gmail.com Fri Jul 14 06:05:28 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 14 Jul 2006 11:35:28 +0530 Subject: error: XML::Parser perl module is required for intltool Message-ID: Hi, While reviewing some packages i am getting following errors in mock build for rawhide repository checking for intltool >= 0.18... 0.34.1 found checking for perl... /usr/bin/perl checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool error: Bad exit status from /var/tmp/rpm-tmp.20633 (%build) What am i missing that leads mock build to fail? I am doing mock build using local rawhide mirror repository. Regards, Parag. From michael at knox.net.nz Fri Jul 14 06:17:21 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 14 Jul 2006 18:17:21 +1200 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: References: Message-ID: <44B736F1.5060203@knox.net.nz> Parag N(????) wrote: > Hi, > While reviewing some packages i am getting following errors in mock > build for rawhide repository > > checking for intltool >= 0.18... 0.34.1 found > checking for perl... /usr/bin/perl > checking for XML::Parser... configure: error: XML::Parser perl module > is required for intltool > error: Bad exit status from /var/tmp/rpm-tmp.20633 (%build) > > What am i missing that leads mock build to fail? I am doing mock build > using local rawhide mirror repository. You need: BuildRequires: perl-XML-Parser Michael From rc040203 at freenet.de Fri Jul 14 06:52:53 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 14 Jul 2006 08:52:53 +0200 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <44B736F1.5060203@knox.net.nz> References: <44B736F1.5060203@knox.net.nz> Message-ID: <1152859974.4569.264.camel@mccallum.corsepiu.local> On Fri, 2006-07-14 at 18:17 +1200, Michael J. Knox wrote: > Parag N(????) wrote: > > Hi, > > While reviewing some packages i am getting following errors in mock > > build for rawhide repository > > > > checking for intltool >= 0.18... 0.34.1 found > > checking for perl... /usr/bin/perl > > checking for XML::Parser... configure: error: XML::Parser perl module > > is required for intltool > > error: Bad exit status from /var/tmp/rpm-tmp.20633 (%build) > > > > What am i missing that leads mock build to fail? I am doing mock build > > using local rawhide mirror repository. > > You need: > > BuildRequires: perl-XML-Parser Nope. 1. If a package wants the XML::Parser module, it should BuildRequires: perl(XML::Parser) 2. At least on FC5, intltool requires perl-XML-Parser, i.e. this already is supposed to pull in perl(XML::Parser). => A "BuildRequires: intltool" alone is supposed to work. If it doesn't work, something else is broken. Ralf From michael at knox.net.nz Fri Jul 14 06:57:37 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 14 Jul 2006 18:57:37 +1200 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <1152859974.4569.264.camel@mccallum.corsepiu.local> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> Message-ID: <44B74061.1010303@knox.net.nz> Ralf Corsepius wrote: > On Fri, 2006-07-14 at 18:17 +1200, Michael J. Knox wrote: >> Parag N(????) wrote: >>> Hi, >>> While reviewing some packages i am getting following errors in mock >>> build for rawhide repository >>> >>> checking for intltool >= 0.18... 0.34.1 found >>> checking for perl... /usr/bin/perl >>> checking for XML::Parser... configure: error: XML::Parser perl module >>> is required for intltool >>> error: Bad exit status from /var/tmp/rpm-tmp.20633 (%build) >>> >>> What am i missing that leads mock build to fail? I am doing mock build >>> using local rawhide mirror repository. >> You need: >> >> BuildRequires: perl-XML-Parser > Nope. > > 1. If a package wants the XML::Parser module, it should > BuildRequires: perl(XML::Parser) > Well, I have seen it done both ways and there has not been people saying different. Oh well. Michael From paul at city-fan.org Fri Jul 14 07:14:19 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 14 Jul 2006 08:14:19 +0100 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <44B74061.1010303@knox.net.nz> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> Message-ID: <1152861259.14587.8.camel@laurel.intra.city-fan.org> On Fri, 2006-07-14 at 18:57 +1200, Michael J. Knox wrote: > Ralf Corsepius wrote: > > On Fri, 2006-07-14 at 18:17 +1200, Michael J. Knox wrote: > >> Parag N(????) wrote: > >>> Hi, > >>> While reviewing some packages i am getting following errors in mock > >>> build for rawhide repository > >>> > >>> checking for intltool >= 0.18... 0.34.1 found > >>> checking for perl... /usr/bin/perl > >>> checking for XML::Parser... configure: error: XML::Parser perl module > >>> is required for intltool > >>> error: Bad exit status from /var/tmp/rpm-tmp.20633 (%build) > >>> > >>> What am i missing that leads mock build to fail? I am doing mock build > >>> using local rawhide mirror repository. > >> You need: > >> > >> BuildRequires: perl-XML-Parser > > Nope. > > > > 1. If a package wants the XML::Parser module, it should > > BuildRequires: perl(XML::Parser) > > > > > Well, I have seen it done both ways and there has not been people saying > different. Oh well. The XML::Parser module might some day get swallowed up into the main perl package. If that happens, packages buildrequiring perl(XML::Parser) will continue to build OK, and packages buildrequiring perl-XML-Parser will not (the main perl package would provide the former but not the latter). In virtually all of these cases, the right thing to add as a buildreq is actually intltool really, since XML::Parser is being checked for in the configure script to ensure that intltool will work. Adding intltool as a buildreq will automatically pull in XML::Parser. Paul. From panemade at gmail.com Fri Jul 14 07:20:38 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 14 Jul 2006 12:50:38 +0530 Subject: libtool problem Message-ID: Hi, While mock building my package, i got errors at %install section as libtool: install: `%RPM_BUILD_ROOT/usr/lib' must be an absolute directory name Try `libtool --help --mode=install' for more information. make[3]: *** [install-libLTLIBRARIES] Error 1 I know .la must not be specified in SPEC file but under %files section i used all wild cards. The upstream tarball used libtool to install .la files under /usr/bin. How can i solve this problem? Regards, Parag. From fedora at leemhuis.info Fri Jul 14 07:39:05 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 14 Jul 2006 09:39:05 +0200 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <1152861259.14587.8.camel@laurel.intra.city-fan.org> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> <1152861259.14587.8.camel@laurel.intra.city-fan.org> Message-ID: <44B74A19.2040006@leemhuis.info> Not that it matters much, but: Paul Howarth schrieb: > On Fri, 2006-07-14 at 18:57 +1200, Michael J. Knox wrote: >> Ralf Corsepius wrote: > In virtually all of these cases, the right thing to add as a buildreq is > actually intltool really, since XML::Parser is being checked for in the > configure script to ensure that intltool will work. Yes. But intltool is included in some (a lot of?) packages so... > Adding intltool as a > buildreq will automatically pull in XML::Parser. ...will add a package as buildreq that's not used at all during build. CU thl From paul at city-fan.org Fri Jul 14 07:43:41 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 14 Jul 2006 08:43:41 +0100 Subject: libtool problem In-Reply-To: References: Message-ID: <1152863021.14587.18.camel@laurel.intra.city-fan.org> On Fri, 2006-07-14 at 12:50 +0530, Parag N(????) wrote: > Hi, > While mock building my package, i got errors at %install section as > libtool: install: `%RPM_BUILD_ROOT/usr/lib' must be an absolute directory name > Try `libtool --help --mode=install' for more information. > make[3]: *** [install-libLTLIBRARIES] Error 1 > > I know .la must not be specified in SPEC file but under %files section > i used all wild cards. The upstream tarball used libtool to install > .la files under /usr/bin. How can i solve this problem? Use either $RPM_BUILD_ROOT or %{buildroot} %RPM_BUILD_ROOT is wrong. Paul. From rc040203 at freenet.de Fri Jul 14 08:36:28 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 14 Jul 2006 10:36:28 +0200 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <44B74A19.2040006@leemhuis.info> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> <1152861259.14587.8.camel@laurel.intra.city-fan.org> <44B74A19.2040006@leemhuis.info> Message-ID: <1152866189.4569.286.camel@mccallum.corsepiu.local> On Fri, 2006-07-14 at 09:39 +0200, Thorsten Leemhuis wrote: > Not that it matters much, but: > > Paul Howarth schrieb: > > On Fri, 2006-07-14 at 18:57 +1200, Michael J. Knox wrote: > >> Ralf Corsepius wrote: > > In virtually all of these cases, the right thing to add as a buildreq is > > actually intltool really, since XML::Parser is being checked for in the > > configure script to ensure that intltool will work. > > Yes. But intltool is included in some (a lot of?) packages so... > > > Adding intltool as a > > buildreq will automatically pull in XML::Parser. > > ...will add a package as buildreq that's not used at all during build. >From the OP's original posting: .. checking for intltool >= 0.18... 0.34.1 found .. # rpm -ql intltool | xargs grep XML | grep require /usr/bin/intltool-extract: my $ret = eval 'require XML::Parser'; /usr/bin/intltool-merge: my $ret = eval 'require XML::Parser'; /usr/bin/intltool-merge: my $ret = eval 'require XML::Parser'; /usr/bin/intltool-update:"xml(?:\\.in)*|". # http://www.w3.org/XML/ (Note: .in is not required) /usr/share/aclocal/intltool.m4: if `$INTLTOOL_PERL -e "require XML::Parser" 2>/dev/null`; then /usr/share/aclocal/intltool.m4: AC_MSG_ERROR([XML::Parser perl module is required for intltool]) /usr/share/doc/intltool-0.34.2/ChangeLog: of intltool that require the XML::Parser perl module /usr/share/doc/intltool-0.34.2/ChangeLog: needed to merge XML files, so do not require it when building /usr/share/intltool/intltool-extract.in: my $ret = eval 'require XML::Parser'; /usr/share/intltool/intltool-merge.in: my $ret = eval 'require XML::Parser'; /usr/share/intltool/intltool-merge.in: my $ret = eval 'require XML::Parser'; /usr/share/intltool/intltool-update.in:"xml(?:\\.in)*|". # http://www.w3.org/XML/ (Note: .in is not required) => intltool uses perl(XML::Parser) as a mandatory plugin all over the place (Note the AC_MSG_ERROR). Ralf From fedora at leemhuis.info Fri Jul 14 09:00:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 14 Jul 2006 11:00:32 +0200 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <1152866189.4569.286.camel@mccallum.corsepiu.local> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> <1152861259.14587.8.camel@laurel.intra.city-fan.org> <44B74A19.2040006@leemhuis.info> <1152866189.4569.286.camel@mccallum.corsepiu.local> Message-ID: <44B75D30.1060600@leemhuis.info> Ralf Corsepius schrieb: > On Fri, 2006-07-14 at 09:39 +0200, Thorsten Leemhuis wrote: >> Not that it matters much, but: >> >> Paul Howarth schrieb: >>> On Fri, 2006-07-14 at 18:57 +1200, Michael J. Knox wrote: >>>> Ralf Corsepius wrote: >>> In virtually all of these cases, the right thing to add as a buildreq is >>> actually intltool really, since XML::Parser is being checked for in the >>> configure script to ensure that intltool will work. >> Yes. But intltool is included in some (a lot of?) packages so... >>> Adding intltool as a >>> buildreq will automatically pull in XML::Parser. >> ...will add a package as buildreq that's not used at all during build. Maybe I should have mentioned here... "So adding BuildRequires: perl(XML::Parser) is IMHO the better solution" ...because I fail to understand what you want to tell me with: >>From the OP's original posting: > .. > checking for intltool >= 0.18... 0.34.1 found > .. > > # rpm -ql intltool | xargs grep XML | grep require > /usr/bin/intltool-extract: my $ret = eval 'require XML::Parser'; > /usr/bin/intltool-merge: my $ret = eval 'require XML::Parser'; > /usr/bin/intltool-merge: my $ret = eval 'require XML::Parser'; > /usr/bin/intltool-update:"xml(?:\\.in)*|". # http://www.w3.org/XML/ (Note: .in is not required) > /usr/share/aclocal/intltool.m4: if `$INTLTOOL_PERL -e "require XML::Parser" 2>/dev/null`; then > /usr/share/aclocal/intltool.m4: AC_MSG_ERROR([XML::Parser perl module is required for intltool]) > /usr/share/doc/intltool-0.34.2/ChangeLog: of intltool that require the XML::Parser perl module > /usr/share/doc/intltool-0.34.2/ChangeLog: needed to merge XML files, so do not require it when building > /usr/share/intltool/intltool-extract.in: my $ret = eval 'require XML::Parser'; > /usr/share/intltool/intltool-merge.in: my $ret = eval 'require XML::Parser'; > /usr/share/intltool/intltool-merge.in: my $ret = eval 'require XML::Parser'; > /usr/share/intltool/intltool-update.in:"xml(?:\\.in)*|". # http://www.w3.org/XML/ (Note: .in is not required) > > => intltool uses perl(XML::Parser) as a mandatory plugin all over the > place (Note the AC_MSG_ERROR). CU thl From panemade at gmail.com Fri Jul 14 09:10:06 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 14 Jul 2006 14:40:06 +0530 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <1152866189.4569.286.camel@mccallum.corsepiu.local> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> <1152861259.14587.8.camel@laurel.intra.city-fan.org> <44B74A19.2040006@leemhuis.info> <1152866189.4569.286.camel@mccallum.corsepiu.local> Message-ID: Hi, On 7/14/06, Ralf Corsepius wrote: > On Fri, 2006-07-14 at 09:39 +0200, Thorsten Leemhuis wrote: > > Not that it matters much, but: > > > > Paul Howarth schrieb: > > > On Fri, 2006-07-14 at 18:57 +1200, Michael J. Knox wrote: > > >> Ralf Corsepius wrote: > > > In virtually all of these cases, the right thing to add as a buildreq is > > > actually intltool really, since XML::Parser is being checked for in the > > > configure script to ensure that intltool will work. > > > > Yes. But intltool is included in some (a lot of?) packages so... > > > > > Adding intltool as a > > > buildreq will automatically pull in XML::Parser. > > > > ...will add a package as buildreq that's not used at all during build. > > >From the OP's original posting: > .. > checking for intltool >= 0.18... 0.34.1 found > .. > > # rpm -ql intltool | xargs grep XML | grep require > /usr/bin/intltool-extract: my $ret = eval 'require XML::Parser'; > /usr/bin/intltool-merge: my $ret = eval 'require XML::Parser'; > /usr/bin/intltool-merge: my $ret = eval 'require XML::Parser'; > /usr/bin/intltool-update:"xml(?:\\.in)*|". # http://www.w3.org/XML/ (Note: .in is not required) > /usr/share/aclocal/intltool.m4: if `$INTLTOOL_PERL -e "require XML::Parser" 2>/dev/null`; then > /usr/share/aclocal/intltool.m4: AC_MSG_ERROR([XML::Parser perl module is required for intltool]) > /usr/share/doc/intltool-0.34.2/ChangeLog: of intltool that require the XML::Parser perl module > /usr/share/doc/intltool-0.34.2/ChangeLog: needed to merge XML files, so do not require it when building > /usr/share/intltool/intltool-extract.in: my $ret = eval 'require XML::Parser'; > /usr/share/intltool/intltool-merge.in: my $ret = eval 'require XML::Parser'; > /usr/share/intltool/intltool-merge.in: my $ret = eval 'require XML::Parser'; > /usr/share/intltool/intltool-update.in:"xml(?:\\.in)*|". # http://www.w3.org/XML/ (Note: .in is not required) > > => intltool uses perl(XML::Parser) as a mandatory plugin all over the > place (Note the AC_MSG_ERROR). > Thanks to all for replying. Don't know how but error solved this time by adding BuildRequires: perl-XML-Parser which i did similarly for some packages last week while doing their reviews but besides that they failed. I have reported this problem in one of BUG to Paul Howarth (dont remember BUG number). Anyway if i face again that problem will report back here. Regards, Parag. From michael at knox.net.nz Fri Jul 14 09:10:37 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 14 Jul 2006 21:10:37 +1200 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <44B75D30.1060600@leemhuis.info> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> <1152861259.14587.8.camel@laurel.intra.city-fan.org> <44B74A19.2040006@leemhuis.info> <1152866189.4569.286.camel@mccallum.corsepiu.local> <44B75D30.1060600@leemhuis.info> Message-ID: <44B75F8D.3080909@knox.net.nz> Thorsten Leemhuis wrote: > Ralf Corsepius schrieb: >> On Fri, 2006-07-14 at 09:39 +0200, Thorsten Leemhuis wrote: >>> Not that it matters much, but: >>> >>> Paul Howarth schrieb: >>>> On Fri, 2006-07-14 at 18:57 +1200, Michael J. Knox wrote: >>>>> Ralf Corsepius wrote: >>>> In virtually all of these cases, the right thing to add as a >>>> buildreq is >>>> actually intltool really, since XML::Parser is being checked for in the >>>> configure script to ensure that intltool will work. >>> Yes. But intltool is included in some (a lot of?) packages so... >>>> Adding intltool as a >>>> buildreq will automatically pull in XML::Parser. >>> ...will add a package as buildreq that's not used at all during build. > > Maybe I should have mentioned here... > > "So adding > BuildRequires: perl(XML::Parser) > is IMHO the better solution" Ok, I will keep this in mind for future packaging. However, the "threat" of an external perl module being pulled into perl itself would be possible for any perl module... so are all perl related BuildRequires: to be perl(Something::Whatever) ? Michael From paul at city-fan.org Fri Jul 14 09:13:24 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 14 Jul 2006 10:13:24 +0100 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <44B75F8D.3080909@knox.net.nz> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> <1152861259.14587.8.camel@laurel.intra.city-fan.org> <44B74A19.2040006@leemhuis.info> <1152866189.4569.286.camel@mccallum.corsepiu.local> <44B75D30.1060600@leemhuis.info> <44B75F8D.3080909@knox.net.nz> Message-ID: <44B76034.40407@city-fan.org> Michael J. Knox wrote: > Thorsten Leemhuis wrote: >> Ralf Corsepius schrieb: >>> On Fri, 2006-07-14 at 09:39 +0200, Thorsten Leemhuis wrote: >>>> Not that it matters much, but: >>>> >>>> Paul Howarth schrieb: >>>>> On Fri, 2006-07-14 at 18:57 +1200, Michael J. Knox wrote: >>>>>> Ralf Corsepius wrote: >>>>> In virtually all of these cases, the right thing to add as a >>>>> buildreq is >>>>> actually intltool really, since XML::Parser is being checked for in >>>>> the >>>>> configure script to ensure that intltool will work. >>>> Yes. But intltool is included in some (a lot of?) packages so... >>>>> Adding intltool as a >>>>> buildreq will automatically pull in XML::Parser. >>>> ...will add a package as buildreq that's not used at all during build. >> >> Maybe I should have mentioned here... >> >> "So adding >> BuildRequires: perl(XML::Parser) >> is IMHO the better solution" > > Ok, I will keep this in mind for future packaging. However, the "threat" > of an external perl module being pulled into perl itself would be > possible for any perl module... so are all perl related BuildRequires: > to be perl(Something::Whatever) ? Yes. This is what you'll find in just about every perl module oackage in Extras that depends on other modules. Paul. From michael at knox.net.nz Fri Jul 14 09:15:17 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 14 Jul 2006 21:15:17 +1200 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <44B76034.40407@city-fan.org> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> <1152861259.14587.8.camel@laurel.intra.city-fan.org> <44B74A19.2040006@leemhuis.info> <1152866189.4569.286.camel@mccallum.corsepiu.local> <44B75D30.1060600@leemhuis.info> <44B75F8D.3080909@knox.net.nz> <44B76034.40407@city-fan.org> Message-ID: <44B760A5.7040507@knox.net.nz> Paul Howarth wrote: > Michael J. Knox wrote: >> Thorsten Leemhuis wrote: >>> Ralf Corsepius schrieb: >>>> On Fri, 2006-07-14 at 09:39 +0200, Thorsten Leemhuis wrote: >>>>> Not that it matters much, but: >>>>> >>>>> Paul Howarth schrieb: >>>>>> On Fri, 2006-07-14 at 18:57 +1200, Michael J. Knox wrote: >>>>>>> Ralf Corsepius wrote: >>>>>> In virtually all of these cases, the right thing to add as a >>>>>> buildreq is >>>>>> actually intltool really, since XML::Parser is being checked for >>>>>> in the >>>>>> configure script to ensure that intltool will work. >>>>> Yes. But intltool is included in some (a lot of?) packages so... >>>>>> Adding intltool as a >>>>>> buildreq will automatically pull in XML::Parser. >>>>> ...will add a package as buildreq that's not used at all during build. >>> >>> Maybe I should have mentioned here... >>> >>> "So adding >>> BuildRequires: perl(XML::Parser) >>> is IMHO the better solution" >> >> Ok, I will keep this in mind for future packaging. However, the >> "threat" of an external perl module being pulled into perl itself >> would be possible for any perl module... so are all perl related >> BuildRequires: to be perl(Something::Whatever) ? > > Yes. This is what you'll find in just about every perl module oackage in > Extras that depends on other modules. > Cool, thanks :) Michael From rc040203 at freenet.de Fri Jul 14 09:15:45 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 14 Jul 2006 11:15:45 +0200 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <44B75D30.1060600@leemhuis.info> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> <1152861259.14587.8.camel@laurel.intra.city-fan.org> <44B74A19.2040006@leemhuis.info> <1152866189.4569.286.camel@mccallum.corsepiu.local> <44B75D30.1060600@leemhuis.info> Message-ID: <1152868545.4569.294.camel@mccallum.corsepiu.local> On Fri, 2006-07-14 at 11:00 +0200, Thorsten Leemhuis wrote: > Ralf Corsepius schrieb: > > On Fri, 2006-07-14 at 09:39 +0200, Thorsten Leemhuis wrote: > >> Not that it matters much, but: > >> > >> Paul Howarth schrieb: > >>> On Fri, 2006-07-14 at 18:57 +1200, Michael J. Knox wrote: > >>>> Ralf Corsepius wrote: > >>> In virtually all of these cases, the right thing to add as a buildreq is > >>> actually intltool really, since XML::Parser is being checked for in the > >>> configure script to ensure that intltool will work. > >> Yes. But intltool is included in some (a lot of?) packages so... > >>> Adding intltool as a > >>> buildreq will automatically pull in XML::Parser. > >> ...will add a package as buildreq that's not used at all during build. > > Maybe I should have mentioned here... > > "So adding > BuildRequires: perl(XML::Parser) > is IMHO the better solution" > > ...because I fail to understand what you want to tell me with: I and tell you: Adding BuildRequires: perl(XML::Parser) to packages using intltool is non-sense, because BuildRequires: intltool must already pull in perl(XML::Parser). If this doesn't work, intltool's packaging is broken. Ralf From bugs.michael at gmx.net Fri Jul 14 09:26:51 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 14 Jul 2006 11:26:51 +0200 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: References: Message-ID: <20060714112651.76c01264.bugs.michael@gmx.net> On Fri, 14 Jul 2006 11:35:28 +0530, Parag N(????) wrote: > Hi, > While reviewing some packages i am getting following errors in mock > build for rawhide repository > > checking for intltool >= 0.18... 0.34.1 found Is this the one that is included with the package or the system one? Do you have BR intltool? > checking for perl... /usr/bin/perl > checking for XML::Parser... configure: error: XML::Parser perl module > is required for intltool > error: Bad exit status from /var/tmp/rpm-tmp.20633 (%build) > > What am i missing that leads mock build to fail? I am doing mock build > using local rawhide mirror repository. > Regards, > Parag. > From paul at city-fan.org Fri Jul 14 09:34:01 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 14 Jul 2006 10:34:01 +0100 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> <1152861259.14587.8.camel@laurel.intra.city-fan.org> <44B74A19.2040006@leemhuis.info> <1152866189.4569.286.camel@mccallum.corsepiu.local> Message-ID: <44B76509.6090007@city-fan.org> Parag N(????) wrote: > Hi, > On 7/14/06, Ralf Corsepius wrote: >> On Fri, 2006-07-14 at 09:39 +0200, Thorsten Leemhuis wrote: >> > Not that it matters much, but: >> > >> > Paul Howarth schrieb: >> > > On Fri, 2006-07-14 at 18:57 +1200, Michael J. Knox wrote: >> > >> Ralf Corsepius wrote: >> > > In virtually all of these cases, the right thing to add as a >> buildreq is >> > > actually intltool really, since XML::Parser is being checked for >> in the >> > > configure script to ensure that intltool will work. >> > >> > Yes. But intltool is included in some (a lot of?) packages so... >> > >> > > Adding intltool as a >> > > buildreq will automatically pull in XML::Parser. >> > >> > ...will add a package as buildreq that's not used at all during build. >> >> >From the OP's original posting: >> .. >> checking for intltool >= 0.18... 0.34.1 found >> .. >> >> # rpm -ql intltool | xargs grep XML | grep require >> /usr/bin/intltool-extract: my $ret = eval 'require XML::Parser'; >> /usr/bin/intltool-merge: my $ret = eval 'require XML::Parser'; >> /usr/bin/intltool-merge: my $ret = eval 'require XML::Parser'; >> /usr/bin/intltool-update:"xml(?:\\.in)*|". # >> http://www.w3.org/XML/ (Note: .in is not required) >> /usr/share/aclocal/intltool.m4: if `$INTLTOOL_PERL -e "require >> XML::Parser" 2>/dev/null`; then >> /usr/share/aclocal/intltool.m4: AC_MSG_ERROR([XML::Parser perl >> module is required for intltool]) >> /usr/share/doc/intltool-0.34.2/ChangeLog: of intltool that >> require the XML::Parser perl module >> /usr/share/doc/intltool-0.34.2/ChangeLog: needed to merge XML >> files, so do not require it when building >> /usr/share/intltool/intltool-extract.in: my $ret = eval 'require >> XML::Parser'; >> /usr/share/intltool/intltool-merge.in: my $ret = eval 'require >> XML::Parser'; >> /usr/share/intltool/intltool-merge.in: my $ret = eval 'require >> XML::Parser'; >> /usr/share/intltool/intltool-update.in:"xml(?:\\.in)*|". # >> http://www.w3.org/XML/ (Note: .in is not required) >> >> => intltool uses perl(XML::Parser) as a mandatory plugin all over the >> place (Note the AC_MSG_ERROR). >> > Thanks to all for replying. Don't know how but error solved this > time by adding > BuildRequires: perl-XML-Parser > which i did similarly for some packages last week while doing their > reviews but besides that they failed. I have reported this problem in > one of BUG to Paul Howarth (dont remember BUG number). Anyway if i > face again that problem will report back here. Please note that the buildreq should be perl(XML::Parser) rather than perl-XML-Parser as discussed earlier in this thread. Paul. From panemade at gmail.com Fri Jul 14 09:36:33 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 14 Jul 2006 15:06:33 +0530 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <20060714112651.76c01264.bugs.michael@gmx.net> References: <20060714112651.76c01264.bugs.michael@gmx.net> Message-ID: Hi, On 7/14/06, Michael Schwendt wrote: > On Fri, 14 Jul 2006 11:35:28 +0530, Parag N(????) wrote: > > > Hi, > > While reviewing some packages i am getting following errors in mock > > build for rawhide repository > > > > checking for intltool >= 0.18... 0.34.1 found > > Is this the one that is included with the package or the system one? > Do you have BR intltool? No its not included at all in package SPEC. What is BR intltool? As i said i am using rawhide and intltool version is 0.35.0-1 > > > checking for perl... /usr/bin/perl > > checking for XML::Parser... configure: error: XML::Parser perl module > > is required for intltool > > error: Bad exit status from /var/tmp/rpm-tmp.20633 (%build) > > > > What am i missing that leads mock build to fail? I am doing mock build > > using local rawhide mirror repository. > > Regards, > > Parag. > > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From panemade at gmail.com Fri Jul 14 09:50:40 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 14 Jul 2006 15:20:40 +0530 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <44B76509.6090007@city-fan.org> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> <1152861259.14587.8.camel@laurel.intra.city-fan.org> <44B74A19.2040006@leemhuis.info> <1152866189.4569.286.camel@mccallum.corsepiu.local> <44B76509.6090007@city-fan.org> Message-ID: On 7/14/06, Paul Howarth wrote: > Parag N(????) wrote: > > Hi, > > On 7/14/06, Ralf Corsepius wrote: > >> On Fri, 2006-07-14 at 09:39 +0200, Thorsten Leemhuis wrote: > >> > Not that it matters much, but: > >> > > >> > Paul Howarth schrieb: > >> > > On Fri, 2006-07-14 at 18:57 +1200, Michael J. Knox wrote: > >> > >> Ralf Corsepius wrote: > >> > > In virtually all of these cases, the right thing to add as a > >> buildreq is > >> > > actually intltool really, since XML::Parser is being checked for > >> in the > >> > > configure script to ensure that intltool will work. > >> > > >> > Yes. But intltool is included in some (a lot of?) packages so... > >> > > >> > > Adding intltool as a > >> > > buildreq will automatically pull in XML::Parser. > >> > > >> > ...will add a package as buildreq that's not used at all during build. > >> > >> >From the OP's original posting: > >> .. > >> checking for intltool >= 0.18... 0.34.1 found > >> .. > >> > >> # rpm -ql intltool | xargs grep XML | grep require > >> /usr/bin/intltool-extract: my $ret = eval 'require XML::Parser'; > >> /usr/bin/intltool-merge: my $ret = eval 'require XML::Parser'; > >> /usr/bin/intltool-merge: my $ret = eval 'require XML::Parser'; > >> /usr/bin/intltool-update:"xml(?:\\.in)*|". # > >> http://www.w3.org/XML/ (Note: .in is not required) > >> /usr/share/aclocal/intltool.m4: if `$INTLTOOL_PERL -e "require > >> XML::Parser" 2>/dev/null`; then > >> /usr/share/aclocal/intltool.m4: AC_MSG_ERROR([XML::Parser perl > >> module is required for intltool]) > >> /usr/share/doc/intltool-0.34.2/ChangeLog: of intltool that > >> require the XML::Parser perl module > >> /usr/share/doc/intltool-0.34.2/ChangeLog: needed to merge XML > >> files, so do not require it when building > >> /usr/share/intltool/intltool-extract.in: my $ret = eval 'require > >> XML::Parser'; > >> /usr/share/intltool/intltool-merge.in: my $ret = eval 'require > >> XML::Parser'; > >> /usr/share/intltool/intltool-merge.in: my $ret = eval 'require > >> XML::Parser'; > >> /usr/share/intltool/intltool-update.in:"xml(?:\\.in)*|". # > >> http://www.w3.org/XML/ (Note: .in is not required) > >> > >> => intltool uses perl(XML::Parser) as a mandatory plugin all over the > >> place (Note the AC_MSG_ERROR). > >> > > Thanks to all for replying. Don't know how but error solved this > > time by adding > > BuildRequires: perl-XML-Parser > > which i did similarly for some packages last week while doing their > > reviews but besides that they failed. I have reported this problem in > > one of BUG to Paul Howarth (dont remember BUG number). Anyway if i > > face again that problem will report back here. > > Please note that the buildreq should be perl(XML::Parser) rather than > perl-XML-Parser as discussed earlier in this thread. > Yes BuildRequires: perl(XML::Parser) also worked without any problem. I will keep in mind that if got ${SUBJECT} error again then i must to add BuildRequires: perl(XML::Parser) rather than BuildRequires: perl-XML-Parser though both are working fine. > Paul. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From fedora at leemhuis.info Fri Jul 14 09:54:55 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 14 Jul 2006 11:54:55 +0200 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <1152868545.4569.294.camel@mccallum.corsepiu.local> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> <1152861259.14587.8.camel@laurel.intra.city-fan.org> <44B74A19.2040006@leemhuis.info> <1152866189.4569.286.camel@mccallum.corsepiu.local> <44B75D30.1060600@leemhuis.info> <1152868545.4569.294.camel@mccallum.corsepiu.local> Message-ID: <44B769EF.5030100@leemhuis.info> Ralf Corsepius schrieb: > On Fri, 2006-07-14 at 11:00 +0200, Thorsten Leemhuis wrote: >> Ralf Corsepius schrieb: >>> On Fri, 2006-07-14 at 09:39 +0200, Thorsten Leemhuis wrote: >>>> Not that it matters much, but: >>>> >>>> Paul Howarth schrieb: >>>>> On Fri, 2006-07-14 at 18:57 +1200, Michael J. Knox wrote: >>>>>> Ralf Corsepius wrote: >>>>> In virtually all of these cases, the right thing to add as a buildreq is >>>>> actually intltool really, since XML::Parser is being checked for in the >>>>> configure script to ensure that intltool will work. >>>> Yes. But intltool is included in some (a lot of?) packages so... >>>>> Adding intltool as a >>>>> buildreq will automatically pull in XML::Parser. >>>> ...will add a package as buildreq that's not used at all during build. >> Maybe I should have mentioned here... >> >> "So adding >> BuildRequires: perl(XML::Parser) >> is IMHO the better solution" >> >> ...because I fail to understand what you want to tell me with: > I and tell you: Seems you didn't get what I was up to. Seems I didn't explain it well. This... > Adding BuildRequires: perl(XML::Parser) to packages using intltool is > non-sense, because BuildRequires: intltool must already pull in > perl(XML::Parser). If this doesn't work, intltool's packaging is broken. ...of course is correct if the external intltool is used. But if the packages includes intltool already then BuildRequires: perl(XML::Parser) avoids the installation of one unnecessary BR (because the systems intltool is unnecessary in this case). But as I said: It doesn't matter that much. So let's stop this thread here. CU thl From bugs.michael at gmx.net Fri Jul 14 10:14:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 14 Jul 2006 12:14:24 +0200 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: References: <20060714112651.76c01264.bugs.michael@gmx.net> Message-ID: <20060714121424.ef7288d4.bugs.michael@gmx.net> On Fri, 14 Jul 2006 15:06:33 +0530, Parag N(????) wrote: > > On Fri, 14 Jul 2006 11:35:28 +0530, Parag N(????) wrote: > > > > > Hi, > > > While reviewing some packages i am getting following errors in mock > > > build for rawhide repository > > > > > > checking for intltool >= 0.18... 0.34.1 found > > > > Is this the one that is included with the package or the system one? > > Do you have BR intltool? > No its not included at all in package SPEC. What is BR intltool? BR is jargon for BuildRequires > As i said i am using rawhide and intltool version is 0.35.0-1 And 0.34.1 is found, so it _is_ the one included with the package and not rawhide's. Look for files 'intltool-*' in the tarball. From panemade at gmail.com Fri Jul 14 10:27:10 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 14 Jul 2006 15:57:10 +0530 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <20060714121424.ef7288d4.bugs.michael@gmx.net> References: <20060714112651.76c01264.bugs.michael@gmx.net> <20060714121424.ef7288d4.bugs.michael@gmx.net> Message-ID: hi, On 7/14/06, Michael Schwendt wrote: > On Fri, 14 Jul 2006 15:06:33 +0530, Parag N(????) wrote: > > > > On Fri, 14 Jul 2006 11:35:28 +0530, Parag N(????) wrote: > > > > > > > Hi, > > > > While reviewing some packages i am getting following errors in mock > > > > build for rawhide repository > > > > > > > > checking for intltool >= 0.18... 0.34.1 found > > > > > > Is this the one that is included with the package or the system one? > > > Do you have BR intltool? > > No its not included at all in package SPEC. What is BR intltool? > > BR is jargon for BuildRequires > > > As i said i am using rawhide and intltool version is 0.35.0-1 > > And 0.34.1 is found, so it _is_ the one included with the package > and not rawhide's. Look for files 'intltool-*' in the tarball. Yes you are very correct. I found intltool-extract.in, intltool-merge.in, intltool-update.in anf there is 0.34.1 is written. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From ville.skytta at iki.fi Fri Jul 14 14:59:48 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 14 Jul 2006 17:59:48 +0300 Subject: error: XML::Parser perl module is required for intltool In-Reply-To: <44B76034.40407@city-fan.org> References: <44B736F1.5060203@knox.net.nz> <1152859974.4569.264.camel@mccallum.corsepiu.local> <44B74061.1010303@knox.net.nz> <1152861259.14587.8.camel@laurel.intra.city-fan.org> <44B74A19.2040006@leemhuis.info> <1152866189.4569.286.camel@mccallum.corsepiu.local> <44B75D30.1060600@leemhuis.info> <44B75F8D.3080909@knox.net.nz> <44B76034.40407@city-fan.org> Message-ID: <1152889188.6622.50.camel@localhost.localdomain> On Fri, 2006-07-14 at 10:13 +0100, Paul Howarth wrote: > Michael J. Knox wrote: > > > > Ok, I will keep this in mind for future packaging. However, the "threat" > > of an external perl module being pulled into perl itself would be > > possible for any perl module... so are all perl related BuildRequires: > > to be perl(Something::Whatever) ? > > Yes. This is what you'll find in just about every perl module oackage in > Extras that depends on other modules. That's correct, and it's not only about modules being swallowed in core perl but being moved around packages, upstream splits etc. One case where I think it's better to use the package name (+ EVR!) instead/additionally is if there's a versioned dependency involved and the target package doesn't provide a versioned perl(Foo::Bar) that could be used to specify it. From j.w.r.degoede at hhs.nl Fri Jul 14 20:50:21 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 14 Jul 2006 22:50:21 +0200 Subject: File conflicts in Fedora Extras Development In-Reply-To: <20060711171508.2ba36dd1.bugs.michael@gmx.net> References: <20060711171508.2ba36dd1.bugs.michael@gmx.net> Message-ID: <44B8038D.4080700@hhs.nl> Hi, Thanks for another great script! Although as always email-addresses and / or names of the maintainer would make finding ones packages easier. Michael Schwendt wrote: > gnumeric-1.6.3-2.fc6.i386.rpm > File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl > => Package conflicts with: gnumeric-devel - 1:1.6.3-2.fc6.i386 > > gnumeric-devel-1.6.3-2.fc6.i386.rpm > File conflict with: /usr/share/gnumeric/1.6.3/idl/GNOME_Gnumeric.idl > => All file names in this package are found in the repository elsewhere! > => Package conflicts with: gnumeric - 1:1.6.3-2.fc6.i386 > Fixed, but only for the devel branch as its harmless. > allegro-4.2.0-15.fc6.i386.rpm > File conflict with: /usr/lib/liballeg-4.2.0.so > File conflict with: /usr/lib/liballeg.so.4.2 > => Package conflicts with: allegro-devel - 4.2.0-15.fc6.i386 > > allegro-devel-4.2.0-15.fc6.i386.rpm > File conflict with: /usr/lib/liballeg-4.2.0.so > File conflict with: /usr/lib/liballeg.so.4.2 > => Package conflicts with: allegro - 4.2.0-15.fc6.i386 > Fixed, but only for the devel branch as its harmless. Regards, Hans From ville.skytta at iki.fi Fri Jul 14 21:12:53 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 15 Jul 2006 00:12:53 +0300 Subject: Planning next version of rpmdevtools Message-ID: <1152911573.2696.49.camel@localhost.localdomain> I'm thinking about pushing the next version of rpmdevtools out soonish. It's tentatively versioned 5.0 to coincide with the oldest version of FC (and incidentally RHEL) it's meant to work with. The major thing I'm planning for in this release is dropping hardcoded "fedora-" prefix everywhere, including from the package name. Very few things in the package are actually Fedora specific, at least after the changes I'm planning, see below. And it's just annoying in executables and looks kind of silly. I've done some research and haven't found things that would conflict with the renaming plan. The other significant thing is to clean up pre-FC5 stuff from the existing spec templates (IIRC python only needs that?) because there have been and will be some new templates added (ruby, php-*) that won't work with older distro versions anyway. This new version would be pushed to FC5+ only. Action items below, comments welcome. --- Package rename (with appropriate Provides/Obsoletes for a while): * fedora-rpmdevtools -> rpmdevtools General layout: * /etc/fedora -> /etc/rpmdevtools * /usr/share/fedora -> /usr/share/rpmdevtools Rename scripts (with appropriate backwards compat symlinks for a while): * fedora-buildrpmtree -> buildrpmtree * fedora-diffarchive -> diffarchive * fedora-extract -> extractarchive * fedora-md5 -> rpmmd5 * fedora-newrpmspec -> newrpmspec * fedora-rmdevelrpms -> rmdevelrpms * fedora-rpmchecksig -> rpmchecksig * fedora-rpminfo -> rpminfo * fedora-rpmvercmp -> rpmvercmp * fedora-wipebuildtree -> wiperpmtree Move: * spec templates to /etc/rpmdevtools (+ mark as %config (TBD: not noreplace?)) * emacs/fedora-init.el -> rpmdevtools-init.el (drop emacs/) * TBD: template.init as %doc to /usr/share/doc/rpmdevtools-*/ (it's not being used by any scripts that I know of) Drop: * fedora-installdevkeys, all GPG keys * fedora-kmodhelper Package: * Migrate rmdevelrpms.conf in %post to new location if it exists when upgrading (TBD: and has changed?) Clean up: * Pre-FC5 compat from python spec template Code: * Refer to renamed things, not backwards compat links everywhere From sundaram at fedoraproject.org Fri Jul 14 21:57:10 2006 From: sundaram at fedoraproject.org (Rahul) Date: Sat, 15 Jul 2006 03:27:10 +0530 Subject: Planning next version of rpmdevtools In-Reply-To: <1152911573.2696.49.camel@localhost.localdomain> References: <1152911573.2696.49.camel@localhost.localdomain> Message-ID: <44B81336.9020408@fedoraproject.org> Ville Skytt? wrote: > I'm thinking about pushing the next version of rpmdevtools out soonish. > It's tentatively versioned 5.0 to coincide with the oldest version of FC > (and incidentally RHEL) it's meant to work with. This tool is referenced in the release notes. Appreciate if you can file a report with the changes when it hits FC6 branch. Rahul From Christian.Iseli at licr.org Fri Jul 14 22:22:55 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Sat, 15 Jul 2006 00:22:55 +0200 Subject: FE Package Status of Jul 15, 2006 Message-ID: <200607142222.k6EMMt6U018784@mx1.redhat.com> Hi folks, The (more or less) weekly report... The count of FE-ACCEPT jumped from 991 to 1041 whee :-) Maybe we should have some fireworks for the 1000th FE-ACCEPT'd package... Following some suggestions from tibbs, I have linked the package count of all the top 25-ers with the list of corresponding BZ tickets. I have also fixed the report so that it displays packages dropped from core between FC5 and devel. Comments welcome... Cheers, Christian ---- FE Package Status of Jul 15, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 1983 packages - 38 orphans - 25 packages not available in extras devel or release Fedora at FamilleCollet dot com php-pecl-zip Fedora at FamilleCollet dot com php-pear-HTTP cgoorah at yahoo dot com dot au kadischi davidhart at tqmcube dot com leafnode frank-buettner at gmx dot net nas fredrik at dolda2000 dot com icmpdn ghenry at suretecsystems dot com gnome-applet-netmon ivazquez at ivazquez dot net gpredict jpo at di dot uminho dot pt perl-Test-Builder-Tester jvdias at redhat dot com webmin matteo dot ricchetti at libero dot it ss5 matthias at rpmforge dot net fillets-ng-data-cs nicolas dot mailhot at laposte dot net zoo notting at redhat dot com comps oliver at linux-kernel dot at squidGuard peter at thecodergeek dot com obconf tcallawa at redhat dot com R-RScaLAPACK tcallawa at redhat dot com libgdamm tcallawa at redhat dot com R-hdf5 tcallawa at redhat dot com opendap toniw at iki dot fi silky toniw at iki dot fi libmatchbox toshio at tiki-lounge dot com hula wolters dot liste at gmx dot net ktorrent wtogami at redhat dot com iiimf-le-simplehangul - 5 packages not available in extras devel but present in release andreas at bawue dot net echoping andreas at bawue dot net mboxgrep ivazquez at ivazquez dot net gnome-applet-rhythmbox noa at resare dot com vorbisgain steve at silug dot org perl-DateTime-Format-Strptime - 2 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=187818,189375 ktorrent wolters.liste at gmx.net Maelstrom notting at redhat.com - 2 packages present in the development repo which have no owners entry ooo2txt perl-SVK - 2 orphaned packages, yet available in extras devel gtkglarea2 soundtracker - 42 packages that moved to core Packages appearing both in Core and Extras: - 3 packages duplicated for devel: jpo at di dot uminho dot pt perl-Socket6 petersen at redhat dot com scim-bridge tagoh at redhat dot com paps FE-ACCEPT packages stats: - 1041 accepted, closed package reviews - 6 accepted, closed package reviews not in repo - 9 accepted, open package reviews older than 4 weeks; - 7 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 105 open tickets - 24 tickets with no activity in eight weeks - 18 tickets with no activity in four weeks - 3 closed tickets FE-NEW packages stats: - 196 open tickets - 28 tickets with no activity in eight weeks - 34 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 37 open tickets - 7 tickets with no activity in eight weeks - 4 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets OPEN-BUGS packages stats: - 240 open tickets - 149 tickets with no activity in eight weeks - 18 tickets with no activity in four weeks CVS stats: - 1956 packages with a devel directory - 6 packages with no owners entry initng muse ooo2txt perl-Maypole perl-SVK php-apc - 4 packages in CVS devel *and* Core libevent pam_pkcs11 paps perl-Socket6 - 103 packages were dropped from extras Maintainers stats: - 209 maintainers - 21 inactive maintainers with open bugs - 26 inactive maintainers Dropped FC packages: - 268 packages were dropped from core since FC 1 From peter at thecodergeek.com Sat Jul 15 00:19:11 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 14 Jul 2006 17:19:11 -0700 Subject: FE Package Status of Jul 15, 2006 In-Reply-To: <200607142222.k6EMMt6U018784@mx1.redhat.com> References: <200607142222.k6EMMt6U018784@mx1.redhat.com> Message-ID: <44B8347F.40709@thecodergeek.com> Christian.Iseli at licr.org wrote: > [...] > peter at thecodergeek dot com obconf Does this report include stuff in needsign status? I built obconf on for devel yesterday[1], but it hasn't been pushed into the repository yet due to this. Thanks. [1] http://buildsys.fedoraproject.org/build-status/job.psp?uid=12588 -- 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: 251 bytes Desc: OpenPGP digital signature URL: From Christian.Iseli at licr.org Sat Jul 15 00:37:34 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Sat, 15 Jul 2006 02:37:34 +0200 Subject: FE Package Status of Jul 15, 2006 In-Reply-To: Your message of "Fri, 14 Jul 2006 17:19:11 PDT." <44B8347F.40709@thecodergeek.com> Message-ID: <200607150037.k6F0bc6S013533@mx1.redhat.com> peter at thecodergeek.com said: > Does this report include stuff in needsign status? No, it does not. The script complains if there is an entry in owners.list but no corresponding package in the repo... Cheers, Christian From peter at thecodergeek.com Sat Jul 15 00:42:35 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Fri, 14 Jul 2006 17:42:35 -0700 Subject: FE Package Status of Jul 15, 2006 In-Reply-To: <200607150037.k6F0bc6S013533@mx1.redhat.com> References: <200607150037.k6F0bc6S013533@mx1.redhat.com> Message-ID: <44B839FB.3000706@thecodergeek.com> Christian.Iseli at licr.org wrote: > peter at thecodergeek.com said: >> Does this report include stuff in needsign status? > > No, it does not. The script complains if there is an entry in owners.list > but no corresponding package in the repo... > Ah, I see. Thank you for the clarification. -- 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: 251 bytes Desc: OpenPGP digital signature URL: From nman64 at n-man.com Sat Jul 15 04:48:49 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Fri, 14 Jul 2006 23:48:49 -0500 Subject: Wiki not editable? In-Reply-To: <87zmfdmbvk.fsf@kosh.bigo.ensc.de> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <874pxlnt3t.fsf@kosh.bigo.ensc.de> <87zmfdmbvk.fsf@kosh.bigo.ensc.de> Message-ID: <200607142348.52337.nman64@n-man.com> On Thursday 13 July 2006 16:30, Enrico Scholz wrote: > enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) writes: > >> I have moved the page to > >> http://fedoraproject.org/wiki/PackageDrafts/UserCreation. You should > >> be able to edit that page; if not, please let me know. > > > > thanks; works now. > > ok... just fyi: I moved the page back to its original location mentioned > in the fedora-usermgmt package too. This page does not belong into a > "Drafts" category because it is not a draft but documentation about an > existing package where I was too lazy to create an official project > homepage about. > > I thought that Wiki would be a good place to maintain this documentation > but I can move it into the package as %doc when requested. > The PackagingDrafts/ hierarchy is an appropriate location for any page that will be part of the guidelines for packaging. All final versions should be kept within the Packaging/ hierarchy. You aren't able to edit pages within that section because editing of that section has been restricted to the Packaging Committee. You must contact them if you need edit permissions in that section. You should not have moved the document out of the PackageDrafts hierarchy. It will need to be moved back. Once the document is finalized, it will be kept in the Packaging/ section. In the future, please work with the Packaging Committee when making changes to any document that will represent packaging policy or procedure. http://fedoraproject.org/wiki/Packaging/Committee -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Sat Jul 15 06:17:32 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 15 Jul 2006 01:17:32 -0500 Subject: How to deal with undefined-non-weak-symbol Message-ID: I've found that running rpmlint on an installed package can turn up the undefined-non-weak-symbol warning while running it on the binary package doesn't Unfortunately I have absolutely no idea what to do about it, or how to tell if it's actually a problem. Is there any general technique for making them go away? - J< From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 15 07:32:26 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 15 Jul 2006 09:32:26 +0200 Subject: Wiki not editable? In-Reply-To: <200607142348.52337.nman64@n-man.com> (Patrick W. Barnes's message of "Fri, 14 Jul 2006 23:48:49 -0500") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <874pxlnt3t.fsf@kosh.bigo.ensc.de> <87zmfdmbvk.fsf@kosh.bigo.ensc.de> <200607142348.52337.nman64@n-man.com> Message-ID: <87wtafiar9.fsf@kosh.bigo.ensc.de> nman64 at n-man.com ("Patrick W. Barnes") writes: >> >> http://fedoraproject.org/wiki/PackageDrafts/UserCreation. You should >> >> be able to edit that page; if not, please let me know. >> > >> > thanks; works now. >> >> ok... just fyi: I moved the page back to its original location mentioned >> in the fedora-usermgmt package too. This page does not belong into a >> "Drafts" category because it is not a draft but documentation about an >> existing package where I was too lazy to create an official project >> homepage about. >> >> I thought that Wiki would be a good place to maintain this documentation >> but I can move it into the package as %doc when requested. >> > > The PackagingDrafts/ hierarchy is an appropriate location for any page that > will be part of the guidelines for packaging. fedora-usermgmt will never be part of the guidelines because endless flamewars without results showed that we can not find an agreement about it. Therefore, it is in an as-is and not in an it-should state. > All final versions should be kept within the Packaging/ hierarchy. > > You aren't able to edit pages within that section because editing of that > section has been restricted to the Packaging Committee. You must contact > them if you need edit permissions in that section. > > You should not have moved the document out of the PackageDrafts > hierarchy. Again, the page is documentation not a draft and does not belong into a Drafts section. I will remove the page completely and make it a %doc of fedora-usermgmt. > It will need to be moved back. No; please remove it completely or move it out of Drafts. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From joost at soeterbroek.com Sat Jul 15 10:21:29 2006 From: joost at soeterbroek.com (Joost Soeterbroek) Date: Sat, 15 Jul 2006 12:21:29 +0200 Subject: rebuilding heartbeat for new upstream fails in mock Message-ID: <44B8C1A9.3020806@soeterbroek.com> Hi, I am re-building heartbeat package for upstream 2.0.6 version for FE development. Local build on fc5 works fine, building in mock (both fc5 and devel) produces and error (see below). The fact that it builds on local and not in mock suggests a missing BuildReq, but the error does not give me any clues. Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/12606-heartbeat-2.0.6-1.fc6/ crm_mon.c: In function 'main': crm_mon.c:217: warning: implicit declaration of function 'initscr' crm_mon.c:218: warning: implicit declaration of function 'cbreak' crm_mon.c:219: warning: implicit declaration of function 'noecho' crm_mon.c:242: warning: implicit declaration of function 'echo' crm_mon.c:243: warning: implicit declaration of function 'nocbreak' crm_mon.c:244: warning: implicit declaration of function 'endwin' /bin/sh ../../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wwrite-strings -Wcast-qual -Wcast-align -Wbad-function-cast -Winline -Wmissing-format-attribute -Wformat=2 -Wformat-security -Wformat-nonliteral -Wno-long-long -Wno-strict-aliasing -ggdb3 -funsigned-char -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wwrite-strings -Wcast-qual -Wcast-align -Wbad-function-cast -Winline -Wmissing-format-attribute -Wformat=2 -Wformat-security -Wformat-nonliteral -Wno-long-long -Wno-strict-aliasing -ggdb3 -funsigned-char -o crm_mon crm_mon-crm_mon.o ../../lib/clplumbing/libplumb.la ../../lib/pils/libpils.la ../../lib/crm/common/libcrmcommon.la ../../lib/crm/cib/libcib.la ../../lib/apphb/libapphb.la ../../lib/hbclient/libhbclient.la -L/lib -lglib-2.0 ../../lib/crm/pengine/libpe_status.la -lbz2 -lz -lc -luuid -lrt -ldl -lltdl gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wwrite-strings -Wcast-qual -Wcast-align -Wbad-function-cast -Winline -Wmissing-format-attribute -Wformat=2 -Wformat-security -Wformat-nonliteral -Wno-long-long -Wno-strict-aliasing -ggdb3 -funsigned-char -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wwrite-strings -Wcast-qual -Wcast-align -Wbad-function-cast -Winline -Wmissing-format-attribute -Wformat=2 -Wformat-security -Wformat-nonliteral -Wno-long-long -Wno-strict-aliasing -ggdb3 -funsigned-char -o .libs/crm_mon crm_mon-crm_mon.o ../../lib/clplumbing/.libs/libplumb.so /buildd ir/build/BUILD/heartbeat-2.0.6/lib/pils/.libs/libpils.so -L/lib ../../lib/pils/.libs/libpils.so ../../lib/crm/common/.libs/libcrmcommon.so ../../lib/crm/cib/.libs/libcib.so ../../lib/apphb/.libs/libapphb.so ../../lib/hbclient/.libs/libhbclient.so -lglib-2.0 ../../lib/crm/pengine/.libs/libpe_status.so -lbz2 -lz -lc -luuid -lrt /usr/lib/libltdl.so -ldl crm_mon-crm_mon.o: In function `main': /builddir/build/BUILD/heartbeat-2.0.6/crm/admin/crm_mon.c:242: undefined reference to `echo' /builddir/build/BUILD/heartbeat-2.0.6/crm/admin/crm_mon.c:243: undefined reference to `nocbreak' /builddir/build/BUILD/heartbeat-2.0.6/crm/admin/crm_mon.c:244: undefined reference to `endwin' /builddir/build/BUILD/heartbeat-2.0.6/crm/admin/crm_mon.c:217: undefined reference to `initscr' /builddir/build/BUILD/heartbeat-2.0.6/crm/admin/crm_mon.c:218: undefined reference to `cbreak' /builddir/build/BUILD/heartbeat-2.0.6/crm/admin/crm_mon.c:219: undefined reference to `noecho' collect2: ld returned 1 exit status gmake[2]: *** [crm_mon] Error 1 gmake[2]: Leaving directory `/builddir/build/BUILD/heartbeat-2.0.6/crm/admin' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/builddir/build/BUILD/heartbeat-2.0.6/crm' make: *** [all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.52013 (%build) -- Joost Soeterbroek From mtasaka at ioa.s.u-tokyo.ac.jp Sat Jul 15 10:39:15 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 15 Jul 2006 19:39:15 +0900 Subject: rebuilding heartbeat for new upstream fails in mock In-Reply-To: <44B8C1A9.3020806@soeterbroek.com> References: <44B8C1A9.3020806@soeterbroek.com> Message-ID: <44B8C5D3.8000807@ioa.s.u-tokyo.ac.jp> Joost Soeterbroek wrote: > Hi, > > I am re-building heartbeat package for upstream 2.0.6 version for FE > development. Local build on fc5 works fine, building in mock (both fc5 > and devel) produces and error (see below). The fact that it builds on > local and not in mock suggests a missing BuildReq, but the error does > not give me any clues. > > crm_mon.c: In function 'main': > crm_mon.c:217: warning: implicit declaration of function 'initscr' > crm_mon.c:218: warning: implicit declaration of function 'cbreak' > crm_mon.c:219: warning: implicit declaration of function 'noecho' > crm_mon.c:242: warning: implicit declaration of function 'echo' > crm_mon.c:243: warning: implicit declaration of function 'nocbreak' > crm_mon.c:244: warning: implicit declaration of function 'endwin' > crm_mon-crm_mon.o: In function `main': > /builddir/build/BUILD/heartbeat-2.0.6/crm/admin/crm_mon.c:242: undefined > reference to `echo' > /builddir/build/BUILD/heartbeat-2.0.6/crm/admin/crm_mon.c:243: undefined > reference to `nocbreak' > /builddir/build/BUILD/heartbeat-2.0.6/crm/admin/crm_mon.c:244: undefined > reference to `endwin' > /builddir/build/BUILD/heartbeat-2.0.6/crm/admin/crm_mon.c:217: undefined > reference to `initscr' > /builddir/build/BUILD/heartbeat-2.0.6/crm/admin/crm_mon.c:218: undefined > reference to `cbreak' > /builddir/build/BUILD/heartbeat-2.0.6/crm/admin/crm_mon.c:219: undefined > reference to `noecho' > collect2: ld returned 1 exit status > gmake[2]: *** [crm_mon] Error 1 > gmake[2]: Leaving directory > `/builddir/build/BUILD/heartbeat-2.0.6/crm/admin' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/builddir/build/BUILD/heartbeat-2.0.6/crm' > make: *** [all-recursive] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.52013 (%build) > I have not yet checked this by mock, however, perhaps ncurses-devel is missing for BR. [tasaka1 at localhost ~]$ grep -r nocbreak /usr/include 2>/dev/null /usr/include/ncurses/ncurses.h:extern NCURSES_EXPORT(int) nocbreak (void); /* implemented */ /usr/include/ncurses/ncurses.h:#define nocrmode() nocbreak() /usr/include/ncurses/curses.h:extern NCURSES_EXPORT(int) nocbreak (void); /* implemented */ /usr/include/ncurses/curses.h:#define nocrmode() nocbreak() ......... [tasaka1 at localhost ~]$ rpm -qf /usr/include/ncurses/ncurses.h ncurses-devel-5.5-21 From mtasaka at ioa.s.u-tokyo.ac.jp Sat Jul 15 11:10:33 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 15 Jul 2006 20:10:33 +0900 Subject: rebuilding heartbeat for new upstream fails in mock In-Reply-To: <44B8C5D3.8000807@ioa.s.u-tokyo.ac.jp> References: <44B8C1A9.3020806@soeterbroek.com> <44B8C5D3.8000807@ioa.s.u-tokyo.ac.jp> Message-ID: <44B8CD29.2050307@ioa.s.u-tokyo.ac.jp> Mamoru Tasaka wrote: > Joost Soeterbroek wrote: >> Hi, >> >> I am re-building heartbeat package for upstream 2.0.6 version for FE >> development. Local build on fc5 works fine, building in mock (both fc5 >> and devel) produces and error (see below). The fact that it builds on >> local and not in mock suggests a missing BuildReq, but the error does >> not give me any clues. >> > > I have not yet checked this by mock, however, perhaps ncurses-devel is > missing > for BR. > After adding ncurses-devel to BR, I succeeded in rebuilding heartbeat 2.0.6 in mock. Please go ahead. From ville.skytta at iki.fi Sat Jul 15 12:36:33 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 15 Jul 2006 15:36:33 +0300 Subject: How to deal with undefined-non-weak-symbol In-Reply-To: References: Message-ID: <1152966993.2696.123.camel@localhost.localdomain> On Sat, 2006-07-15 at 01:17 -0500, Jason L Tibbitts III wrote: > I've found that running rpmlint on an installed package can turn up > the undefined-non-weak-symbol warning while running it on the binary > package doesn't This is because checking them makes sense only when all dependencies of that package are installed, and that can be "guaranteed" only when the package itself is installed, not when invoking rpmlint on a random uninstalled one. Doing it to the latter would result in a lot of false positives. > Unfortunately I have absolutely no idea what to do > about it, or how to tell if it's actually a problem. If I understand correctly, undefined non-weak symbols *in shared libraries* are generally frowned upon because it causes the need to take care of satisfying them in things that use those libs, which is particularly bad when dlopening them. It's kind of similar to the situation where one ships foo-config, *.la or *.pc files in a -devel package, but fails to add appropriate Requires corresponding to the -lfoo things emitted by those when used. On the other hand, sometimes, but I think pretty rarely, undefined non-weak symbols in shared libraries are desired. This is why it's a warning, not an error from rpmlint. One (only?) example is when there are multiple alternative things available on the target system that provide those symbols and it adds value to leave the choice between them open due to implementation differences. Note that the above applies mostly to shared libs only; with other shared objects which are installed somewhere else than in the dynamic linker's default search path and are intended to be loaded under known circumstances and by specific apps only which satisfy the dependencies for their modules, things are different. This is why rpmlint tries to restrict this check only to shared libs installed in system lib paths. > Is there any general technique for making them go away? In general, link the shared library with all its non-weak dependencies, ie. libraries providing those symbols. "ldd -d -r" can be used to show undefined non-weak symbols, and "nm -D" to list the symbols from others when looking for candidates. Hm, I guess I could add some of this to rpmlint's explanation of the message. Some pointers to further info and example cases: http://www.google.com/search?q=undefined+non-weak http://sources.redhat.com/ml/libc-alpha/2003-05/msg00034.html http://sources.redhat.com/ml/libc-alpha/2003-05/msg00164.html From buildsys at fedoraproject.org Sat Jul 15 13:14:06 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 15 Jul 2006 09:14:06 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-15 Message-ID: <20060715131406.A5B80152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 28 blam-1.8.2-6.fc5 cpanspec-1.67-1.fc5 driftnet-0.1.6-9..fc5.2 eggdrop-1.6.18-1.fc5 facter-1.3.3-1.fc5 gazpacho-0.6.6-1.fc5 gc-6.8-1.fc5.1 lash-0.5.1-6.fc5 nagios-2.5-1.fc5 nas-1.8-6.fc5 nx-2.0.0-3.fc5 octave-2.9.6-1.fc5 octave-forge-2006.07.09-2.fc5 openalpp-20060405-10.fc5 perl-DateTime-Event-ICal-0.09-1.fc5 perl-DateTime-Event-Recurrence-0.16-2.fc5 perl-DateTime-Format-ICal-0.08-2.fc5 perl-Email-MIME-1.85-1.fc5 perl-Email-MIME-Modifier-1.43-1.fc5 perl-Error-0.17-1.fc5 perl-Mail-Mbox-MessageParser-1.4004-1.fc5 perl-OpenFrame-3.05-4.fc5 plone-2.5-1.fc5 puppet-0.18.3-1.fc5 pybliographer-1.2.9-1.fc5 python-ruledispatch-0.5a0-0.1.svnr2115.fc5 radiusclient-ng-0.5.2-3.fc5 ruby-sqlite3-1.1.0-5.fc5 Packages built and released for Fedora Extras 4: 19 cpanspec-1.67-1.fc4 eggdrop-1.6.18-1.fc4 facter-1.3.3-1.fc4 gc-6.8-1.fc4 nagios-2.5-1.fc4 octave-2.9.6-1.fc4 octave-forge-2006.07.09-2.fc4 openalpp-20060405-10.fc4 perl-DateTime-Event-ICal-0.09-1.fc4 perl-DateTime-Event-Recurrence-0.16-2.fc4 perl-DateTime-Format-ICal-0.08-2.fc4 perl-Email-MIME-1.85-1.fc4 perl-Email-MIME-Modifier-1.43-1.fc4 perl-OpenFrame-3.05-4.fc4 puppet-0.18.3-1.fc4 pybliographer-1.2.9-1.fc4 python-ruledispatch-0.5a0-0.1.svnr2115.fc4 radiusclient-ng-0.5.2-3.fc4 ruby-sqlite3-1.1.0-5.fc4 Packages built and released for Fedora Extras 3: 1 nagios-2.5-1.fc3 Packages built and released for Fedora Extras development: 28 allegro-4.2.0-16.fc6 blam-1.8.2-6.fc6 cpanspec-1.67-1.fc6 driftnet-0.1.6-10 eggdrop-1.6.18-1.fc6 gazpacho-0.6.6-1.fc6 gc-6.8-1.fc6 gtk-xfce-engine-2.2.8-3.fc6 kinput2-v3.1-28.fc6 lash-0.5.1-6.fc6 nagios-2.5-1.fc6 nas-1.8-6.fc6 nx-2.0.0-3.fc6 obconf-1.6-2.fc6 openalpp-20060405-10.fc6 perl-DateTime-0.31-2.fc6 perl-DateTime-Format-Strptime-1.0700-1.fc6 perl-Email-MIME-1.85-1.fc6 perl-Email-MIME-Modifier-1.43-1.fc6 perl-Error-0.17-1.fc6 perl-Statistics-Descriptive-2.6-1.fc6 plone-2.5-1.fc6 puppet-0.18.3-1.fc6 pybliographer-1.2.9-1.fc6 python-cheetah-2.0-0.1.rc7.fc6 python-cherrypy-2.2.1-2.fc6 scim-chinese-standard-0.0.2-3.fc6 yasm-0.5.0-1.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Jul 15 13:14:31 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 15 Jul 2006 09:14:31 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-15 Message-ID: <20060715131431.8DF2D152160@buildsys.fedoraproject.org> alsa-lib: 5: 0:1.0.11-4.rc2 (FC5-updates) 6: 0:1.0.11-3.rc2.2.1 (FC6) amarok: 5: 0:1.4.1-2.fc5 (FE5) 6: 0:1.4.0-5.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) ecl: 4: 0:0.9i-1.1.fc4 (FE4) 5: 0:0.9i-1.fc5 (FE5) 6: 0:0.9i-1.fc6 (FE6) eclipse-changelog: 5: 1:2.1.0_fc-2 (FC5-updates) 6: 1:2.1.0_fc-1 (FC6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flex: 5: 0:2.5.4a-39.fc5 (FC5-updates) 6: 0:2.5.4a-38.1 (FC6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gnome-applet-vm: 5: 0:0.0.7-2 (FC5-updates) 6: 0:0.0.6-1.1 (FC6) gwget: 5: 0:0.97-3.fc5 (FE5) 6: 0:0.97-2.fc5 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libraw1394: 5: 0:1.2.1-1.fc5 (FC5-updates) 6: 0:1.2.0-3.fc5.2.1 (FC6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2.1 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-12.fc6 (FC6) monotone: 5: 0:0.27-1.fc5 (FE5) 6: 0:0.26-2.fc6 (FE6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) readahead: 5: 1:1.2-2 (FC5-updates) 6: 1:1.2-1.27 (FC6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) wordpress: 4: 0:2.0.3-4.fc4 (FE4) 5: 0:2.0.3-3.fc5 (FE5) 6: 0:2.0.3-3.fc6 (FE6) From buildsys at fedoraproject.org Sat Jul 15 13:36:26 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 15 Jul 2006 13:36:26 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-15 Message-ID: <20060715133626.31235.16822@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.ppc requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.x86_64 requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) ====================================================================== New report for: lmacken AT redhat.com package: python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 from fedora-extras-4-i386 unresolved deps: python-protocols >= 0:1.0 package: python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: python-protocols >= 0:1.0 package: python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc from fedora-extras-4-ppc unresolved deps: python-protocols >= 0:1.0 From buildsys at fedoraproject.org Sat Jul 15 13:36:26 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 15 Jul 2006 13:36:26 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-15 Message-ID: <20060715133626.31228.75193@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Sat Jul 15 13:36:26 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 15 Jul 2006 13:36:26 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-15 Message-ID: <20060715133626.31239.21250@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.i386 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.ppc requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc5.x86_64 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: lmacken AT redhat.com package: python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 from fedora-extras-5-i386 unresolved deps: python-protocols >= 0:1.0 package: python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: python-protocols >= 0:1.0 package: python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc from fedora-extras-5-ppc unresolved deps: python-protocols >= 0:1.0 From buildsys at fedoraproject.org Sat Jul 15 13:36:26 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 15 Jul 2006 13:36:26 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-15 Message-ID: <20060715133626.31242.82600@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 dmitry AT butskoy.name gnome-translate - 0.99-7.fc6.i386 gnome-translate - 0.99-7.fc6.ppc gnome-translate - 0.99-7.fc6.x86_64 fedora AT leemhuis.info ghex - 2.8.1-4.fc5.i386 ghex - 2.8.1-4.fc5.ppc ghex - 2.8.1-4.fc5.x86_64 gsynaptics - 0.9.8-1.fc6.ppc mail-notification - 3.0-2.fc6.i386 mail-notification - 3.0-2.fc6.ppc mail-notification - 3.0-2.fc6.x86_64 gauret AT free.fr amarok-visualisation - 1.4.0-5.fc6.i386 amarok-visualisation - 1.4.0-5.fc6.ppc amarok-visualisation - 1.4.0-5.fc6.x86_64 ivazquez AT ivazquez.net gnome-applet-music - 0.9.0-1.fc6.i386 gnome-applet-music - 0.9.0-1.fc6.ppc gnome-applet-music - 0.9.0-1.fc6.x86_64 nautilus-search-tool - 0.2-1.fc5.i386 nautilus-search-tool - 0.2-1.fc5.ppc nautilus-search-tool - 0.2-1.fc5.x86_64 matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 gfontview - 0.5.0-5.fc5.ppc gfontview - 0.5.0-5.fc5.x86_64 gtkhtml36 - 3.6.2-5.fc6.i386 gtkhtml36 - 3.6.2-5.fc6.ppc gtkhtml36 - 3.6.2-5.fc6.x86_64 libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 pertusus AT free.fr cernlib - 2005-21.fc6.ppc cernlib-packlib - 2005-21.fc6.ppc patchy - 2005-21.fc6.ppc paw - 2005-21.fc6.ppc rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 libibverbs - 1.0.3-1.fc6.ppc libibverbs - 1.0.3-1.fc6.x86_64 libibverbs-utils - 1.0.3-1.fc6.i386 libibverbs-utils - 1.0.3-1.fc6.ppc libibverbs-utils - 1.0.3-1.fc6.x86_64 thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 directfb - 0.9.24-5.fc5.ppc directfb - 0.9.24-5.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.i386 requires libvisual.so.0 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 ghex-2.8.1-4.fc5.i386 requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.i386 requires libgailutil.so.17 gnome-translate-0.99-7.fc6.i386 requires libgailutil.so.17 gtkhtml36-3.6.2-5.fc6.i386 requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 mail-notification-3.0-2.fc6.i386 requires libgailutil.so.17 nautilus-search-tool-0.2-1.fc5.i386 requires libgailutil.so.17 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.ppc requires libvisual.so.0 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 ghex-2.8.1-4.fc5.ppc requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.ppc requires libgailutil.so.17 gnome-translate-0.99-7.fc6.ppc requires libgailutil.so.17 gsynaptics-0.9.8-1.fc6.ppc requires synaptics gtkhtml36-3.6.2-5.fc6.ppc requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 mail-notification-3.0-2.fc6.ppc requires libgailutil.so.17 nautilus-search-tool-0.2-1.fc5.ppc requires libgailutil.so.17 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.x86_64 requires libvisual.so.0()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) ghex-2.8.1-4.fc5.x86_64 requires libgailutil.so.17()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libgailutil.so.17()(64bit) gnome-translate-0.99-7.fc6.x86_64 requires libgailutil.so.17()(64bit) gtkhtml36-3.6.2-5.fc6.x86_64 requires libgailutil.so.17()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) mail-notification-3.0-2.fc6.x86_64 requires libgailutil.so.17()(64bit) nautilus-search-tool-0.2-1.fc5.x86_64 requires libgailutil.so.17()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: mpeters AT mac.com package: gtkhtml36 - 3.6.2-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgailutil.so.17 package: gtkhtml36 - 3.6.2-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgailutil.so.17()(64bit) package: gtkhtml36 - 3.6.2-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgailutil.so.17 ====================================================================== New report for: ivazquez AT ivazquez.net package: gnome-applet-music - 0.9.0-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgailutil.so.17 package: nautilus-search-tool - 0.2-1.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgailutil.so.17 package: gnome-applet-music - 0.9.0-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgailutil.so.17()(64bit) package: nautilus-search-tool - 0.2-1.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgailutil.so.17()(64bit) package: gnome-applet-music - 0.9.0-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgailutil.so.17 package: nautilus-search-tool - 0.2-1.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgailutil.so.17 ====================================================================== New report for: dmitry AT butskoy.name package: gnome-translate - 0.99-7.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgailutil.so.17 package: gnome-translate - 0.99-7.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgailutil.so.17()(64bit) package: gnome-translate - 0.99-7.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgailutil.so.17 ====================================================================== New report for: fedora AT leemhuis.info package: ghex - 2.8.1-4.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgailutil.so.17 package: mail-notification - 3.0-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgailutil.so.17 package: ghex - 2.8.1-4.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgailutil.so.17()(64bit) package: mail-notification - 3.0-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgailutil.so.17()(64bit) package: ghex - 2.8.1-4.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgailutil.so.17 package: gsynaptics - 0.9.8-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: synaptics package: mail-notification - 3.0-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgailutil.so.17 From tibbs at math.uh.edu Sat Jul 15 14:47:10 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 15 Jul 2006 09:47:10 -0500 Subject: How to deal with undefined-non-weak-symbol In-Reply-To: <1152966993.2696.123.camel@localhost.localdomain> (Ville Skytt's message of "Sat, 15 Jul 2006 15:36:33 +0300") References: <1152966993.2696.123.camel@localhost.localdomain> Message-ID: >>>>> "VS" == Ville Skytt writes: VS> If I understand correctly, undefined non-weak symbols *in shared VS> libraries* are generally frowned upon because it causes the need VS> to take care of satisfying them in things that use those libs, VS> which is particularly bad when dlopening them. Yep, these are in %_libdir. The package installs a dozen libraries and causes over 3500 of these undefined-non-weak-symbol warnings. And sadly I wouldn't have noticed if not for some new testing bits that installs the packages into the mock chroot and runs a proper rpmlint after building. So I guess what has to be done is to run nm and grep through to find the library that provides the missing symbol and add that to the link line. But I'm not even sure if it's reasonable to do that; the libraries are built independently in separate directories. Looks like I'm going to be stuck with the aplus-fsf package forever. - J< From Liste at FamilleCollet.com Sat Jul 15 14:36:22 2006 From: Liste at FamilleCollet.com (Remi Collet) Date: Sat, 15 Jul 2006 16:36:22 +0200 Subject: FE Package Status of Jul 15, 2006 In-Reply-To: <200607142222.k6EMMt6U018784@mx1.redhat.com> References: <200607142222.k6EMMt6U018784@mx1.redhat.com> Message-ID: <44B8FD66.3010200@FamilleCollet.com> Christian.Iseli at licr.org a ?crit : > - 25 packages not available in extras devel or release > Fedora at FamilleCollet dot com php-pecl-zip > Fedora at FamilleCollet dot com php-pear-HTTP > Still waiting for the PHP Guidelines approvement. Remi. From rtlm10 at gmail.com Sat Jul 15 16:59:57 2006 From: rtlm10 at gmail.com (Russell Harrison) Date: Sat, 15 Jul 2006 12:59:57 -0400 Subject: Planning next version of rpmdevtools In-Reply-To: <1152911573.2696.49.camel@localhost.localdomain> References: <1152911573.2696.49.camel@localhost.localdomain> Message-ID: <1ed4a0130607150959x46eb690en86312649f0d8745c@mail.gmail.com> On 7/14/06, Ville Skytt? wrote: > > I'm thinking about pushing the next version of rpmdevtools out soonish. > It's tentatively versioned 5.0 to coincide with the oldest version of FC > (and incidentally RHEL) it's meant to work with. > > The major thing I'm planning for in this release is dropping hardcoded > "fedora-" prefix everywhere, including from the package name. Very few > things in the package are actually Fedora specific, at least after the > changes I'm planning, see below. And it's just annoying in executables > and looks kind of silly. I've done some research and haven't found > things that would conflict with the renaming plan. I'm thrilled to hear about this. I've already been creating my rpms using the fedora tools and then modifying them back to RHEL 4. It will be a delight to use the exact same tools for both Fedora and RHEL in the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 15 17:05:48 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 15 Jul 2006 19:05:48 +0200 Subject: Wiki not editable? In-Reply-To: <200607142348.52337.nman64@n-man.com> (Patrick W. Barnes's message of "Fri, 14 Jul 2006 23:48:49 -0500") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <874pxlnt3t.fsf@kosh.bigo.ensc.de> <87zmfdmbvk.fsf@kosh.bigo.ensc.de> <200607142348.52337.nman64@n-man.com> Message-ID: <87sll2iys3.fsf@kosh.bigo.ensc.de> nman64 at n-man.com ("Patrick W. Barnes") writes: > You should not have moved the document out of the PackageDrafts > hierarchy. It will need to be moved back. Please respect my rights as author of this page and keep it at is new/original location (new license terms should forbid moving into PackageDrafts). > In the future, please work with the Packaging Committee In the future, please contact me before doing arbitrary and distorting changes of my documents. Thanks Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From tibbs at math.uh.edu Sat Jul 15 17:29:24 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 15 Jul 2006 12:29:24 -0500 Subject: Wiki not editable? In-Reply-To: <87sll2iys3.fsf@kosh.bigo.ensc.de> (Enrico Scholz's message of "Sat, 15 Jul 2006 19:05:48 +0200") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <874pxlnt3t.fsf@kosh.bigo.ensc.de> <87zmfdmbvk.fsf@kosh.bigo.ensc.de> <200607142348.52337.nman64@n-man.com> <87sll2iys3.fsf@kosh.bigo.ensc.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> Please respect my rights as author of this page and keep it at is ES> new/original location (new license terms should forbid moving into ES> PackageDrafts). New license terms? Didn't you sign the CLA? You may have just created an issue that the lawyer folks have to look into. I honestly suggest that everyone discuss this in a reasonable fashion rather than continue down this path. - J< From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 15 17:49:36 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 15 Jul 2006 19:49:36 +0200 Subject: Wiki not editable? In-Reply-To: (Jason L. Tibbitts, III's message of "Sat, 15 Jul 2006 12:29:24 -0500") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <874pxlnt3t.fsf@kosh.bigo.ensc.de> <87zmfdmbvk.fsf@kosh.bigo.ensc.de> <200607142348.52337.nman64@n-man.com> <87sll2iys3.fsf@kosh.bigo.ensc.de> Message-ID: <87odvqiwr3.fsf@kosh.bigo.ensc.de> tibbs at math.uh.edu (Jason L Tibbitts III) writes: > ES> Please respect my rights as author of this page and keep it at is > ES> new/original location (new license terms should forbid moving into > ES> PackageDrafts). > > New license terms? Didn't you sign the CLA? I am not a lawyer but I do not see how placing under the FDL and adding an "invariant section" would violate the CLA. > I honestly suggest that everyone discuss this in a reasonable fashion > rather than continue down this path. "This path" began when parts of the Wiki (inclusive my pages) were made uneditable. Such inadvertent things can happen but should be solved when responsible people are noticed about it. I am thankful for your action to move the old, protected page to a place where I could edit it again. But "this path" continued when completely unrelated people did distorting changes to my documents without asking me first. When ACLs (which are unavailable for me) are required to protect pages, then I can use licenses to protect my copyright. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Sat Jul 15 19:39:45 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 15 Jul 2006 14:39:45 -0500 Subject: Wiki not editable? In-Reply-To: <87odvqiwr3.fsf@kosh.bigo.ensc.de> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <874pxlnt3t.fsf@kosh.bigo.ensc.de> <87zmfdmbvk.fsf@kosh.bigo.ensc.de> <200607142348.52337.nman64@n-man.com> <87sll2iys3.fsf@kosh.bigo.ensc.de> <87odvqiwr3.fsf@kosh.bigo.ensc.de> Message-ID: <1152992385.12401.9.camel@vader.jdub.homelinux.org> On Sat, 2006-07-15 at 19:49 +0200, Enrico Scholz wrote: > > But "this path" continued when completely unrelated people did distorting > changes to my documents without asking me first. When ACLs (which are > unavailable for me) are required to protect pages, then I can use licenses > to protect my copyright. Enrico, it's a wiki. A friggin wiki. The whole idea is that people can edit pages. It's both a blessing and a curse. Now obviously it is polite to discuss changes with the original author, but there is nothing requiring that to be done. If you don't want people making changes to pages _you_ write, then I suggest putting them under your own user page in the wiki. josh From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 15 20:03:25 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 15 Jul 2006 22:03:25 +0200 Subject: Wiki not editable? In-Reply-To: <1152992385.12401.9.camel@vader.jdub.homelinux.org> (Josh Boyer's message of "Sat, 15 Jul 2006 14:39:45 -0500") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <874pxlnt3t.fsf@kosh.bigo.ensc.de> <87zmfdmbvk.fsf@kosh.bigo.ensc.de> <200607142348.52337.nman64@n-man.com> <87sll2iys3.fsf@kosh.bigo.ensc.de> <87odvqiwr3.fsf@kosh.bigo.ensc.de> <1152992385.12401.9.camel@vader.jdub.homelinux.org> Message-ID: <87k66eiqk2.fsf@kosh.bigo.ensc.de> jwboyer at jdub.homelinux.org (Josh Boyer) writes: >> But "this path" continued when completely unrelated people did >> distorting changes to my documents without asking me first. When >> ACLs (which are unavailable for me) are required to protect pages, >> then I can use licenses to protect my copyright. > > Enrico, it's a wiki. A friggin wiki. The whole idea is that people > can edit pages. This whole sh^Wissue started because the Fedora Wiki admins think different... ;) > Now obviously it is polite to discuss changes with the original author, > but there is nothing requiring that to be done. If you don't want > people making changes to pages _you_ write, then I suggest putting them > under your own user page in the wiki. I do not have problems when other people change/enhance this page. But I hate it when people (who never wrote a single char in this page before) are violating my obvious will. Because I do not want to waste more time in restoring my pages (it is not trivial and such actions destroy the complete edit-history) I went the license-way. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From skvidal at linux.duke.edu Sat Jul 15 20:13:29 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 15 Jul 2006 16:13:29 -0400 Subject: Wiki not editable? In-Reply-To: <87k66eiqk2.fsf@kosh.bigo.ensc.de> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <874pxlnt3t.fsf@kosh.bigo.ensc.de> <87zmfdmbvk.fsf@kosh.bigo.ensc.de> <200607142348.52337.nman64@n-man.com> <87sll2iys3.fsf@kosh.bigo.ensc.de> <87odvqiwr3.fsf@kosh.bigo.ensc.de> <1152992385.12401.9.camel@vader.jdub.homelinux.org> <87k66eiqk2.fsf@kosh.bigo.ensc.de> Message-ID: <1152994409.5388.10.camel@cutter> On Sat, 2006-07-15 at 22:03 +0200, Enrico Scholz wrote: > jwboyer at jdub.homelinux.org (Josh Boyer) writes: > > >> But "this path" continued when completely unrelated people did > >> distorting changes to my documents without asking me first. When > >> ACLs (which are unavailable for me) are required to protect pages, > >> then I can use licenses to protect my copyright. > > > > Enrico, it's a wiki. A friggin wiki. The whole idea is that people > > can edit pages. > > This whole sh^Wissue started because the Fedora Wiki admins think > different... ;) > not true. This fedora wiki admins was asked to make the packaging tree of the wiki restricted so spot could work on it. It was supported by Thorsten and I made the change. I've never been asked to undo it. So it was not how we thought different it just what was done. quit trying to add malice to this where there is none. -sv From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 15 20:37:02 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 15 Jul 2006 22:37:02 +0200 Subject: Wiki not editable? In-Reply-To: <1152994409.5388.10.camel@cutter> (seth vidal's message of "Sat, 15 Jul 2006 16:13:29 -0400") References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <874pxlnt3t.fsf@kosh.bigo.ensc.de> <87zmfdmbvk.fsf@kosh.bigo.ensc.de> <200607142348.52337.nman64@n-man.com> <87sll2iys3.fsf@kosh.bigo.ensc.de> <87odvqiwr3.fsf@kosh.bigo.ensc.de> <1152992385.12401.9.camel@vader.jdub.homelinux.org> <87k66eiqk2.fsf@kosh.bigo.ensc.de> <1152994409.5388.10.camel@cutter> Message-ID: <87fyh2ip01.fsf@kosh.bigo.ensc.de> skvidal at linux.duke.edu (seth vidal) writes: >> > Enrico, it's a wiki. A friggin wiki. The whole idea is that >> > people can edit pages. >> >> This whole sh^Wissue started because the Fedora Wiki admins think >> different... ;) > > not true. This fedora wiki admins was asked sorry; please s!admins!commanders! > to make the packaging tree of the wiki restricted so spot could work > on it. When I interpret statements in this thread correctly, this "so ... could work on it" became a "forever" :( Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From cweyl at alumni.drew.edu Sat Jul 15 20:54:23 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sat, 15 Jul 2006 13:54:23 -0700 Subject: Conditionals in spec files to determine where it's building? Message-ID: <7dd7ab490607151354u20164036n47459e7efdb9c6b3@mail.gmail.com> Hey all -- I'm running into a situation where software I'm running has tests that require network access. Is there a conditional the buildsys defines that I could use to depend on the non-existence of to run the tests, such that builds outside mock/buildsys do run the tests? I could just "--define" from the command line when building it manually... But it's easier to have the machine do it :) -Chris -- Chris Weyl Ex astris, scientia From j.w.r.degoede at hhs.nl Sat Jul 15 21:00:36 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 15 Jul 2006 23:00:36 +0200 Subject: freetds suitable for extras Message-ID: <44B95774.3080305@hhs.nl> Hi, I was wondering if freetds, an LGPL MS-SQL server client-library: http://www.freetds.org/ Is suitable for inclusion into Extra's. If it is I might package it since libgnomedb would benefit from it. Regards, Hans From yaneti at declera.com Sat Jul 15 22:25:50 2006 From: yaneti at declera.com (Yanko Kaneti) Date: Sun, 16 Jul 2006 01:25:50 +0300 Subject: freetds suitable for extras In-Reply-To: <44B95774.3080305@hhs.nl> References: <44B95774.3080305@hhs.nl> Message-ID: <1153002350.4614.2.camel@indigo.declera.com> On Sat, 2006-07-15 at 23:00 +0200, Hans de Goede wrote: > I was wondering if freetds, an LGPL MS-SQL server client-library: > http://www.freetds.org/ > > Is suitable for inclusion into Extra's. If it is I might package it > since libgnomedb would benefit from it. Probably not suitable. https://www.redhat.com/archives/fedora-extras-list/2005-September/msg01164.html From Christian.Iseli at licr.org Sat Jul 15 23:22:59 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Sun, 16 Jul 2006 01:22:59 +0200 Subject: FE Package Status of Jul 15, 2006 In-Reply-To: Your message of "Sat, 15 Jul 2006 16:36:22 +0200." <44B8FD66.3010200@FamilleCollet.com> Message-ID: <200607152323.k6FNN5ON018061@mx1.redhat.com> Liste at FamilleCollet.com said: > Still waiting for the PHP Guidelines approvement. Sure, no worries. It should happen RSN I hope :-) Christian From nman64 at n-man.com Sun Jul 16 00:25:49 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sat, 15 Jul 2006 19:25:49 -0500 Subject: Wiki not editable? In-Reply-To: <87fyh2ip01.fsf@kosh.bigo.ensc.de> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <1152994409.5388.10.camel@cutter> <87fyh2ip01.fsf@kosh.bigo.ensc.de> Message-ID: <200607151925.52580.nman64@n-man.com> On Saturday 15 July 2006 15:37, Enrico Scholz wrote: > skvidal at linux.duke.edu (seth vidal) writes: > >> > Enrico, it's a wiki. A friggin wiki. The whole idea is that > >> > people can edit pages. > >> > >> This whole sh^Wissue started because the Fedora Wiki admins think > >> different... ;) > > > > not true. This fedora wiki admins was asked > > sorry; please s!admins!commanders! > > > to make the packaging tree of the wiki restricted so spot could work > > on it. > > When I interpret statements in this thread correctly, this "so ... could > work on it" became a "forever" :( > We aren't trying to violate your rights, but we do need to maintain organization on the wiki, and that's what prompted the movement of your page. Your insistence upon keeping it in a non-conformant location is what made this a real problem. We told you in the beginning why the Packaging/ hierarchy had restricted ACLs and what your options were to work around it. We told you why the page was placed in the PackagingDrafts/ hierarchy. We aren't trying to violate your will with regard to the purposes of the document, but we must have your cooperation in maintaining organization. If you take the time to look at the organization of other, similar pages, our reasons and practices might become more clear. It also wouldn't hurt for you to communicate with the Packaging Committee. You also need to clearly understand the CLA and its purpose. Rather than attempt to summarize anything, I'll recommend that you look over the Legal section of the wiki carefully. You should know that signing the CLA and submitting it to the wiki licenses it under the terms of the OPL without options. It also grants an irrevocable copyright license to the Fedora Project. While you are free to offer it under other licenses, you also cannot restrict the usage of the document in any way beyond the OPL. Among other things, this means that you cannot prevent it from being moved or organized in a different manner, whether you agree with it or not. If you want to apply such restrictions, you shouldn't submit your documents to the Fedora Project. It isn't in the spirit of FOSS to restrict your documents in that manner, and we won't support it. The responsible thing to do when there's something you disagree with is to bring the issue up to the appropriate group or committee. In this case, you could be talking to FESCo, the Packaging Committee and the Websites team. Even though this page represents an optional method of package management, it applies globally to the Fedora Project when the packager chooses to use it. The UserRegistry page also has global applications, but it can't be moved without ACL adjustment, as packagers must have write access to it. The end goal is to get all pages related to packaging policy and practices under the Packaging/ hierarchy. The ACLs will be loosened over the full hierarchy and tightened only on specific pages as needed after the content in that hierarchy matures. At that point, it will be perfectly safe to keep the UserRegistry and UserCreation pages within that hierarchy. The only reason we had been keeping UserCreation in the Drafts hierarchy is to allow you (and other editors) to continue working on it until that point. That's why the redirects have also been maintained. Knowing this, do you have any other compelling reasons to keep the UserCreation and UserRegistry pages out of the Packaging/ hierarchy? If it will make you feel better, we can temporarily override the ACLs to move your pages to the permanent locations under Packaging/ and maintain the current permissions. Personally, I'd rather leave the UserRegistry page where it is and put the UserCreation page back in Drafts until the ACLs over the rest of Packaging/ can be adjusted, but I'm willing to meet you half-way on this and assume that the Packaging Committee won't object to that. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Sun Jul 16 00:29:07 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 15 Jul 2006 17:29:07 -0700 Subject: Wiki not editable? In-Reply-To: <87wtafiar9.fsf@kosh.bigo.ensc.de> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <874pxlnt3t.fsf@kosh.bigo.ensc.de> <87zmfdmbvk.fsf@kosh.bigo.ensc.de> <200607142348.52337.nman64@n-man.com> <87wtafiar9.fsf@kosh.bigo.ensc.de> Message-ID: <1153009747.3030.30.camel@localhost> On Sat, 2006-07-15 at 09:32 +0200, Enrico Scholz wrote: > nman64 at n-man.com ("Patrick W. Barnes") writes: > > >> >> http://fedoraproject.org/wiki/PackageDrafts/UserCreation. You should > >> >> be able to edit that page; if not, please let me know. > >> > > >> > thanks; works now. > >> > >> ok... just fyi: I moved the page back to its original location mentioned > >> in the fedora-usermgmt package too. This page does not belong into a > >> "Drafts" category because it is not a draft but documentation about an > >> existing package where I was too lazy to create an official project > >> homepage about. > >> > >> I thought that Wiki would be a good place to maintain this documentation > >> but I can move it into the package as %doc when requested. > >> > > > > The PackagingDrafts/ hierarchy is an appropriate location for any page that > > will be part of the guidelines for packaging. > > fedora-usermgmt will never be part of the guidelines because endless > flamewars without results showed that we can not find an agreement about > it. Therefore, it is in an as-is and not in an it-should state. > Never say never :-) But there have certainly been a lot of flamewars surrounding it by people who have different views on the issue. I don't know of anyone who is prepared to advocate it for inclusion right now so if you (the author of the document) want to consider it documentation for fedora-usermgmt instead of a potential draft for someone to pick up for the guidelines down the road, that's fine. > > > All final versions should be kept within the Packaging/ hierarchy. > > > > You aren't able to edit pages within that section because editing of that > > section has been restricted to the Packaging Committee. You must contact > > them if you need edit permissions in that section. > > I'm sorry, this is all a misunderstanding. The usermgmt documentation was placed in the Packaging Hierarchy before spot requested that hierarchy be ACL'd to him (and subsequently to the Packaging Committee). The document is not a guideline (It isn't a MUST or SHOULD for packaging or even something everyone has agreed is a best practice.) so it doesn't belong in the hierarchy. Enrico is the primary owner and so we needed to move it somewhere that he could edit it. A few people on the Packaging Committee discussed where we should move it so Enrico could edit it and we thought it _could_ be a useful guideline at some point so we might as well move it to the Drafts area. As there is no one to push the draft forward at this point and Enrico is opposed to the current version becoming a Guideline (or at least, doesn't want to push it either) and because the reason it was moved to the PackagingDrafts hierarchy was to place it somewhere that Enrico could edit it, it's perfectly reasonable for Enrico to want to move it elsewhere. I would like to emphasize that we discussed whether to place the document in the PackagingDrafts hierarchy or elsewhere and decided on PackagingDrafts because of its potential to be a guideline, not because anyone is actively working on making it a guideline at the moment. If Enrico can best work on it without the pressure of people fearing it will become a guideline we are perfectly happy for him to move it. > > You should not have moved the document out of the PackageDrafts > > hierarchy. > > Again, the page is documentation not a draft and does not belong into a > Drafts section. I will remove the page completely and make it a %doc of > fedora-usermgmt. > FWIW, I liked having the page updated on the wiki. When I reviewed a package that created a user, I would look at the page to see if the package would have any of the problems described. > > > It will need to be moved back. > > No; please remove it completely or move it out of Drafts. Please allow Enrico to keep the UserCreation page where he sees fit. Thank you, Toshio Kuratomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Sun Jul 16 01:19:58 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 15 Jul 2006 20:19:58 -0500 Subject: Wiki not editable? In-Reply-To: <200607151925.52580.nman64@n-man.com> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <1152994409.5388.10.camel@cutter> <87fyh2ip01.fsf@kosh.bigo.ensc.de> <200607151925.52580.nman64@n-man.com> Message-ID: <1153012799.12401.15.camel@vader.jdub.homelinux.org> On Sat, 2006-07-15 at 19:25 -0500, Patrick W. Barnes wrote: > > You also need to clearly understand the CLA and its purpose. Rather than > attempt to summarize anything, I'll recommend that you look over the Legal > section of the wiki carefully. You should know that signing the CLA and > submitting it to the wiki licenses it under the terms of the OPL without > options. It also grants an irrevocable copyright license to the Fedora It says "Texts contributed after 2006-02-19 or by members of the EditGroup are the licensed under the terms of the Open Publication License v1.0 without options, unless otherwise noted." And it does not say _who_ can otherwise note. While I don't personally agree with this specific instance, I also don't see where licensing a page under a different license is not allowed. The wording is a bit ambiguous. IANAL. josh From nman64 at n-man.com Sun Jul 16 01:59:34 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sat, 15 Jul 2006 20:59:34 -0500 Subject: Wiki not editable? In-Reply-To: <1153012799.12401.15.camel@vader.jdub.homelinux.org> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <200607151925.52580.nman64@n-man.com> <1153012799.12401.15.camel@vader.jdub.homelinux.org> Message-ID: <200607152059.36339.nman64@n-man.com> On Saturday 15 July 2006 20:19, Josh Boyer wrote: > On Sat, 2006-07-15 at 19:25 -0500, Patrick W. Barnes wrote: > > You also need to clearly understand the CLA and its purpose. Rather than > > attempt to summarize anything, I'll recommend that you look over the > > Legal section of the wiki carefully. You should know that signing the > > CLA and submitting it to the wiki licenses it under the terms of the OPL > > without options. It also grants an irrevocable copyright license to the > > Fedora > > It says "Texts contributed after 2006-02-19 or by members of the > EditGroup are the licensed under the terms of the Open Publication > License v1.0 without options, unless otherwise noted." And it does not > say _who_ can otherwise note. While I don't personally agree with this > specific instance, I also don't see where licensing a page under a > different license is not allowed. The wording is a bit ambiguous. > The "unless otherwise noted" is intended to allow the Board, assorted committees, etc. to handle special cases where the OPL cannot apply, such as pages where the ACLs have been loosened to allow anyone to contribute without granting a copyright license. It is not a manner for contributors to circumvent our licensing requirements. The Fedora Project holds a copyright license for anything that is submitted by a contributor with a signed CLA. Using the power of that copyright license, the Fedora Project applies the OPL without options to documentation and website contributions. That right is not revocable. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Sun Jul 16 02:23:34 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 15 Jul 2006 22:23:34 -0400 Subject: Wiki not editable? In-Reply-To: <200607152059.36339.nman64@n-man.com> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <200607151925.52580.nman64@n-man.com> <1153012799.12401.15.camel@vader.jdub.homelinux.org> <200607152059.36339.nman64@n-man.com> Message-ID: <20060716022334.GA4694@jadzia.bu.edu> On Sat, Jul 15, 2006 at 08:59:34PM -0500, Patrick W. Barnes wrote: > > It says "Texts contributed after 2006-02-19 or by members of the > > EditGroup are the licensed under the terms of the Open Publication > > License v1.0 without options, unless otherwise noted." And it does not > > say _who_ can otherwise note. While I don't personally agree with this > > specific instance, I also don't see where licensing a page under a > > different license is not allowed. The wording is a bit ambiguous. > The "unless otherwise noted" is intended to allow the Board, assorted > committees, etc. to handle special cases where the OPL cannot apply, such > as pages where the ACLs have been loosened to allow anyone to contribute > without granting a copyright license. It is not a manner for contributors > to circumvent our licensing requirements. The Fedora Project holds a You must admit it is ambiguous. Or actually, I'm inclined to say "doesn't seem ambigous at all, but rather clearly states that some content may be licensed differently". > copyright license for anything that is submitted by a contributor with a > signed CLA. Using the power of that copyright license, the Fedora Project > applies the OPL without options to documentation and website > contributions. That right is not revocable. Unless I'm misunderstanding, the copyright license wording is not so broad as that. Specifically, it says: 2. Contributor Grant of License. You hereby grant to Red Hat, Inc., on behalf of the Project, and to recipients of software distributed by the Project: (a) a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your Contribution and such derivative works; and, [... other, patent-related stuff ...] While Red Hat can sublicense under this grant, it doesn't seem to say "may completely relicense". As a bystander here, it really seems like you are taking an unnecessarily antagonistic tone in this conversation. Rather than being so declarative, can't maybe something be worked out in a civilized way? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jwboyer at jdub.homelinux.org Sun Jul 16 02:48:58 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 15 Jul 2006 21:48:58 -0500 Subject: Wiki not editable? In-Reply-To: <20060716022334.GA4694@jadzia.bu.edu> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <200607151925.52580.nman64@n-man.com> <1153012799.12401.15.camel@vader.jdub.homelinux.org> <200607152059.36339.nman64@n-man.com> <20060716022334.GA4694@jadzia.bu.edu> Message-ID: <1153018138.12401.21.camel@vader.jdub.homelinux.org> On Sat, 2006-07-15 at 22:23 -0400, Matthew Miller wrote: > On Sat, Jul 15, 2006 at 08:59:34PM -0500, Patrick W. Barnes wrote: > > > It says "Texts contributed after 2006-02-19 or by members of the > > > EditGroup are the licensed under the terms of the Open Publication > > > License v1.0 without options, unless otherwise noted." And it does not > > > say _who_ can otherwise note. While I don't personally agree with this > > > specific instance, I also don't see where licensing a page under a > > > different license is not allowed. The wording is a bit ambiguous. > > The "unless otherwise noted" is intended to allow the Board, assorted > > committees, etc. to handle special cases where the OPL cannot apply, such > > as pages where the ACLs have been loosened to allow anyone to contribute > > without granting a copyright license. It is not a manner for contributors > > to circumvent our licensing requirements. The Fedora Project holds a > > You must admit it is ambiguous. Or actually, I'm inclined to say "doesn't > seem ambigous at all, but rather clearly states that some content may be > licensed differently". Yes, I tend to agree. While I'm certainly aware of the intention of those words, they are indeed ambiguous. IMHO, the "unless otherwise noted" part either needs to be removed or otherwise clarified. > > > copyright license for anything that is submitted by a contributor with a > > signed CLA. Using the power of that copyright license, the Fedora Project > > applies the OPL without options to documentation and website > > contributions. That right is not revocable. > > Unless I'm misunderstanding, the copyright license wording is not so broad > as that. Specifically, it says: > > 2. Contributor Grant of License. You hereby grant to Red Hat, Inc., on > behalf of the Project, and to recipients of software distributed by the > Project: > > (a) a perpetual, non-exclusive, worldwide, fully paid-up, royalty > free, irrevocable copyright license to reproduce, prepare derivative > works of, publicly display, publicly perform, sublicense, and > distribute your Contribution and such derivative works; and, > > [... other, patent-related stuff ...] > > While Red Hat can sublicense under this grant, it doesn't seem to say "may > completely relicense". I also agree with that. My intentions here are not to be inflammatory. Rather they are to highlight a potential problem that should be resolved sooner rather than later. The issue has been forwarded to Max and the Board. I look forward to their leadership on this issue and hope things can be clarified soon. josh From nman64 at n-man.com Sun Jul 16 03:00:15 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sat, 15 Jul 2006 22:00:15 -0500 Subject: Wiki not editable? In-Reply-To: <200607152059.36339.nman64@n-man.com> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <1153012799.12401.15.camel@vader.jdub.homelinux.org> <200607152059.36339.nman64@n-man.com> Message-ID: <200607152200.17647.nman64@n-man.com> On Saturday 15 July 2006 20:59, "Patrick W. Barnes" wrote: > > The "unless otherwise noted" is intended to allow the Board, assorted > committees, etc. to handle special cases where the OPL cannot apply, such > as pages where the ACLs have been loosened to allow anyone to contribute > without granting a copyright license. It is not a manner for contributors > to circumvent our licensing requirements. The Fedora Project holds a > copyright license for anything that is submitted by a contributor with a > signed CLA. Using the power of that copyright license, the Fedora Project > applies the OPL without options to documentation and website contributions. > That right is not revocable. > I'd like to further elaborate after talking with Toshio on IRC. It seems there are some questions about what the CLA does and the processes for licensing on the wiki. IANAL, just a person who understands this stuff. This does not constitute legal advice. ;-) 1. Changing Licenses Once content has been submitted to the Fedora Project, the Fedora Project has copyright privileges that cannot be provoked. The licensing for that content cannot be changed by the original contributor. That power rests with the Fedora Project, and the decision can be handled through the same chain of command as any other. Stipulations on the license are also not possible after the contribution has been made. 2. Forks After content has been submitted to the Project, the Project has the power to accept or reject any further changes that are licensed differently. The standing decision is to reject such changes. Any unauthorized changes can be reverted or thrown out, but those reversions must be made in whole and not selectively. For example, if someone modifies a wiki page and adds an alternative licensing clause, the Project can remove all of the changes and the licensing clause but cannot remove the licensing clause without removing all of the changes. The Project can forbid wiki submissions under alternative licenses and can revoke the editing privileges of someone who violates that decision with or without notice. If a fork is authorized, it must be clearly labelled, and the pre-fork version will remain under the original license. Since the original author and the Fedora Project hold copyright privileges, neither is bound by any copyright license applied to the pre-fork version. 3. Revocation of Copyright Privileges The copyright license awarded to the Fedora Project under the terms of the CLA cannot be revoked. Once a contribution has been submitted, it cannot be withdrawn. The Fedora Project does have the ability to discard any contribution. 4. Original Contributions Original contributions under alternative licenses (or not licensed for redistribution) must be clearly marked when they are submitted. The contribution must be labelled with licensing restrictions and details. The Fedora Project has the right to refuse any contribution for any reason. Again, the Project can forbid such submissions through the wiki and can revoke the editing privileges of someone who violates that decision with or without notice. 5. Additional Rules In addition to any legal restrictions, the Fedora Project can establish rules to disallow different types of submissions and to deal with violations. Rules can be published on the wiki, in mailing list descriptions, in IRC topics, etc. to notify potential contributors of the policies. Wiki editing privileges can be revoked, mailing list subscriptions can be removed, IRC channels can set bans, etc. to deal with violators. Again, this message does not constitute legal advice and is therefore completely worthless. I hope this clarifies a few things. ;-) -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nman64 at n-man.com Sun Jul 16 03:10:49 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sat, 15 Jul 2006 22:10:49 -0500 Subject: Wiki not editable? In-Reply-To: <1153018138.12401.21.camel@vader.jdub.homelinux.org> References: <87r70wjjyh.fsf@kosh.bigo.ensc.de> <20060716022334.GA4694@jadzia.bu.edu> <1153018138.12401.21.camel@vader.jdub.homelinux.org> Message-ID: <200607152210.52341.nman64@n-man.com> On Saturday 15 July 2006 21:48, Josh Boyer wrote: > On Sat, 2006-07-15 at 22:23 -0400, Matthew Miller wrote: > > On Sat, Jul 15, 2006 at 08:59:34PM -0500, Patrick W. Barnes wrote: > > > > It says "Texts contributed after 2006-02-19 or by members of the > > > > EditGroup are the licensed under the terms of the Open Publication > > > > License v1.0 without options, unless otherwise noted." And it does > > > > not say _who_ can otherwise note. While I don't personally agree > > > > with this specific instance, I also don't see where licensing a page > > > > under a different license is not allowed. The wording is a bit > > > > ambiguous. > > > > > > The "unless otherwise noted" is intended to allow the Board, assorted > > > committees, etc. to handle special cases where the OPL cannot apply, > > > such as pages where the ACLs have been loosened to allow anyone to > > > contribute without granting a copyright license. It is not a manner for > > > contributors to circumvent our licensing requirements. The Fedora > > > Project holds a > > > > You must admit it is ambiguous. Or actually, I'm inclined to say "doesn't > > seem ambigous at all, but rather clearly states that some content may be > > licensed differently". > > Yes, I tend to agree. While I'm certainly aware of the intention of > those words, they are indeed ambiguous. IMHO, the "unless otherwise > noted" part either needs to be removed or otherwise clarified. > That isn't the place to add clarification. That's the difference between licensing text and policy pages. It's up to the Board to establish a policy about who can name exceptions. Obvious exceptions include pages that aren't covered by the CLA, like the CVSSyncNeeded page. > > > copyright license for anything that is submitted by a contributor with > > > a signed CLA. Using the power of that copyright license, the Fedora > > > Project applies the OPL without options to documentation and website > > > contributions. That right is not revocable. > > > > Unless I'm misunderstanding, the copyright license wording is not so > > broad as that. Specifically, it says: > > > > 2. Contributor Grant of License. You hereby grant to Red Hat, Inc., on > > behalf of the Project, and to recipients of software distributed by > > the Project: > > > > (a) a perpetual, non-exclusive, worldwide, fully paid-up, royalty > > free, irrevocable copyright license to reproduce, prepare > > derivative works of, publicly display, publicly perform, sublicense, and > > distribute your Contribution and such derivative works; and, > > > > [... other, patent-related stuff ...] > > > > While Red Hat can sublicense under this grant, it doesn't seem to say > > "may completely relicense". > > I also agree with that. There is no usage case in copyright law that isn't included in those rights. Red Hat and the Fedora Project can license contributions in any manner that does not extend beyond those rights. The combination of those two facts basically means that Red Hat and the Fedora Project can do anything with the contributions. The CLA stops short of copyright assignment because the author retains the same privileges. Copyright assignment is also not possible in some parts of the world. > > My intentions here are not to be inflammatory. Rather they are to > highlight a potential problem that should be resolved sooner rather than > later. I also don't mean to be antagonistic. I'm just trying to make the facts clear. I'm not on any side with regard to the legal aspects. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- 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 16 06:30:34 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 16 Jul 2006 08:30:34 +0200 Subject: freetds suitable for extras In-Reply-To: <1153002350.4614.2.camel@indigo.declera.com> References: <44B95774.3080305@hhs.nl> <1153002350.4614.2.camel@indigo.declera.com> Message-ID: <44B9DD0A.7090803@hhs.nl> Yanko Kaneti wrote: > On Sat, 2006-07-15 at 23:00 +0200, Hans de Goede wrote: >> I was wondering if freetds, an LGPL MS-SQL server client-library: >> http://www.freetds.org/ >> >> Is suitable for inclusion into Extra's. If it is I might package it >> since libgnomedb would benefit from it. > > Probably not suitable. > https://www.redhat.com/archives/fedora-extras-list/2005-September/msg01164.html > > Most definetly not suitable with the patent stuff, thanks for the pointer! Regards, Hans From buildsys at fedoraproject.org Sun Jul 16 19:16:04 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 16 Jul 2006 15:16:04 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-16 Message-ID: <20060716191604.97E58152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 13 abiword-2.4.5-2.fc5 coldet-1.1-3.fc5 dejavu-fonts-2.8.0-1.fc5 dssi-0.9.1-7.fc5 gwget-0.97-4.fc5 heartbeat-2.0.6-2.fc5 hexter-dssi-0.5.9-4.fc5 libsx-2.05-9.fc5 ogre-1.2.1-2.fc5 perl-Module-ScanDeps-0.62-1.fc5 qgit-1.4-2.fc5 qt4-4.1.4-6.fc5 xwrits-2.24-1.fc5 Packages built and released for Fedora Extras 4: 6 abiword-2.4.5-2.fc4 dejavu-fonts-2.8.0-1.fc4 gwget-0.96-5.fc4 heartbeat-2.0.6-2.fc4 perl-Module-ScanDeps-0.62-1.fc4 qgit-1.4-2.fc4 Packages built and released for Fedora Extras 3: 1 abiword-2.4.5-1.fc3 Packages built and released for Fedora Extras development: 21 bmp-0.9.7.1-5.fc6 dejavu-fonts-2.8.0-1.fc6 fluidsynth-1.0.7-5.a.fc6 ghex-2.8.2-1.fc6 gnome-translate-0.99-8.fc6 gnumeric-1.6.3-3.fc6 gwget-0.97-6.fc6 heartbeat-2.0.6-2.fc6 libchmxx-0.1-3.fc6 libnfnetlink-0.0.16-1.fc6 libsx-2.05-9.fc6 mail-notification-3.0-3.fc6 perl-Cairo-0.90-1.fc6 perl-Config-Tiny-2.08-1.fc6 perl-Image-Info-1.22-1.fc6 perl-Module-ScanDeps-0.62-1.fc6 perl-POE-Component-Client-DNS-0.99-1.fc6 prboom-2.4.2-1.fc6 qgit-1.4-2.fc6 svgalib-1.9.25-1.fc6 xwrits-2.24-1.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Jul 16 19:16:29 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 16 Jul 2006 15:16:29 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-16 Message-ID: <20060716191629.86994152160@buildsys.fedoraproject.org> abiword: 5: 1:2.4.5-2.fc5 (FE5) 6: 1:2.4.5-1.fc6 (FE6) alsa-lib: 5: 0:1.0.11-4.rc2 (FC5-updates) 6: 0:1.0.11-3.rc2.2.1 (FC6) amarok: 5: 0:1.4.1-2.fc5 (FE5) 6: 0:1.4.0-5.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) ecl: 4: 0:0.9i-1.1.fc4 (FE4) 5: 0:0.9i-1.fc5 (FE5) 6: 0:0.9i-1.fc6 (FE6) eclipse-changelog: 5: 1:2.1.0_fc-2 (FC5-updates) 6: 1:2.1.0_fc-1 (FC6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flex: 5: 0:2.5.4a-39.fc5 (FC5-updates) 6: 0:2.5.4a-39 (FC6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gnome-applet-vm: 5: 0:0.0.7-2 (FC5-updates) 6: 0:0.0.6-1.1 (FC6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libraw1394: 5: 0:1.2.1-1.fc5 (FC5-updates) 6: 0:1.2.0-3.fc5.2.1 (FC6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2.1 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-12.fc6 (FC6) monotone: 5: 0:0.27-1.fc5 (FE5) 6: 0:0.26-2.fc6 (FE6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) qt4: 5: 0:4.1.4-6.fc5 (FE5) 6: 0:4.1.4-5.fc6 (FE6) readahead: 5: 1:1.2-2 (FC5-updates) 6: 1:1.2-1.27 (FC6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) wordpress: 4: 0:2.0.3-4.fc4 (FE4) 5: 0:2.0.3-3.fc5 (FE5) 6: 0:2.0.3-3.fc6 (FE6) From buildsys at fedoraproject.org Sun Jul 16 19:34:27 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 16 Jul 2006 19:34:27 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-16 Message-ID: <20060716193427.26408.27022@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.i386 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.ppc requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc5.x86_64 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From buildsys at fedoraproject.org Sun Jul 16 19:34:27 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 16 Jul 2006 19:34:27 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-16 Message-ID: <20060716193427.26406.33537@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.ppc requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.x86_64 requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) From buildsys at fedoraproject.org Sun Jul 16 19:34:27 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 16 Jul 2006 19:34:27 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-16 Message-ID: <20060716193427.26398.96408@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Sun Jul 16 19:34:27 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 16 Jul 2006 19:34:27 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-16 Message-ID: <20060716193427.26410.93278@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 fedora AT leemhuis.info gsynaptics - 0.9.8-1.fc6.ppc gauret AT free.fr amarok-visualisation - 1.4.0-5.fc6.i386 amarok-visualisation - 1.4.0-5.fc6.ppc amarok-visualisation - 1.4.0-5.fc6.x86_64 i AT stingr.net libnetfilter_conntrack - 0.0.30-2.fc6.i386 libnetfilter_conntrack - 0.0.30-2.fc6.ppc libnetfilter_conntrack - 0.0.30-2.fc6.x86_64 ivazquez AT ivazquez.net gnome-applet-music - 0.9.0-1.fc6.i386 gnome-applet-music - 0.9.0-1.fc6.ppc gnome-applet-music - 0.9.0-1.fc6.x86_64 nautilus-search-tool - 0.2-1.fc5.i386 nautilus-search-tool - 0.2-1.fc5.ppc nautilus-search-tool - 0.2-1.fc5.x86_64 matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 gfontview - 0.5.0-5.fc5.ppc gfontview - 0.5.0-5.fc5.x86_64 gtkhtml36 - 3.6.2-5.fc6.i386 gtkhtml36 - 3.6.2-5.fc6.ppc gtkhtml36 - 3.6.2-5.fc6.x86_64 libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 pertusus AT free.fr cernlib - 2005-21.fc6.ppc cernlib-packlib - 2005-21.fc6.ppc patchy - 2005-21.fc6.ppc paw - 2005-21.fc6.ppc rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 libibverbs - 1.0.3-1.fc6.ppc libibverbs - 1.0.3-1.fc6.x86_64 libibverbs-utils - 1.0.3-1.fc6.i386 libibverbs-utils - 1.0.3-1.fc6.ppc libibverbs-utils - 1.0.3-1.fc6.x86_64 thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 directfb - 0.9.24-5.fc5.ppc directfb - 0.9.24-5.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.i386 requires libvisual.so.0 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.i386 requires libgailutil.so.17 gtkhtml36-3.6.2-5.fc6.i386 requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libnetfilter_conntrack-0.0.30-2.fc6.i386 requires libnfnetlink.so.0 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.i386 requires libgailutil.so.17 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.ppc requires libvisual.so.0 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.ppc requires libgailutil.so.17 gsynaptics-0.9.8-1.fc6.ppc requires synaptics gtkhtml36-3.6.2-5.fc6.ppc requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libnetfilter_conntrack-0.0.30-2.fc6.ppc requires libnfnetlink.so.0 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.ppc requires libgailutil.so.17 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.x86_64 requires libvisual.so.0()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libgailutil.so.17()(64bit) gtkhtml36-3.6.2-5.fc6.x86_64 requires libgailutil.so.17()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libnetfilter_conntrack-0.0.30-2.fc6.x86_64 requires libnfnetlink.so.0()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) nautilus-search-tool-0.2-1.fc5.x86_64 requires libgailutil.so.17()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: i AT stingr.net package: libnetfilter_conntrack - 0.0.30-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libnfnetlink.so.0 package: libnetfilter_conntrack - 0.0.30-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnfnetlink.so.0()(64bit) package: libnetfilter_conntrack - 0.0.30-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libnfnetlink.so.0 From davidswaty at gmail.com Mon Jul 17 01:41:04 2006 From: davidswaty at gmail.com (David Swaty) Date: Sun, 16 Jul 2006 20:41:04 -0500 Subject: Cancle Fedora Listings - Thank You Message-ID: <87c8c03f0607161841p4329f2b0xfe882478ddfd5eb5@mail.gmail.com> please remove me from all Fedora llistings Thank You -------------- next part -------------- An HTML attachment was scrubbed... URL: From grinnz at gmail.com Mon Jul 17 03:44:40 2006 From: grinnz at gmail.com (Dan) Date: Sun, 16 Jul 2006 23:44:40 -0400 Subject: Cancle Fedora Listings - Thank You In-Reply-To: <87c8c03f0607161841p4329f2b0xfe882478ddfd5eb5@mail.gmail.com> References: <87c8c03f0607161841p4329f2b0xfe882478ddfd5eb5@mail.gmail.com> Message-ID: <44BB07A8.40609@gmail.com> David Swaty wrote: > please remove me from all Fedora llistings > Thank You This is not how you unsubscribe. See this link. ( https://www.redhat.com/mailman/listinfo/ for all Redhat/Fedora lists) | | \/ From laurent.rineau__fedora_extras at normalesup.org Sun Jul 16 21:03:11 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Sun, 16 Jul 2006 23:03:11 +0200 Subject: release tags during review In-Reply-To: <44B6E1AB.2020104@gmail.com> References: <44B6C2B0.7010508@kobold.org> <20060713235248.GA27828@jadzia.bu.edu> <44B6E1AB.2020104@gmail.com> Message-ID: <200607162303.11289@rineau.schtroumpfette> On Friday 14 July 2006 02:13, Rick Stout wrote: > > I kind of like it because it signifies "this isn't the final package" if > > it "leaks" somewhere. > > Isn't it really supposed to be used only to signify a beta package? For > example Foo 1.0 RC2 > > foo-1.0-0.RC2.fc5 I hope you mean foo-1.0-0.1.RC2.fc5 You need a incrementable number, after the first "0." of your release tag. From buildsys at fedoraproject.org Mon Jul 17 18:29:33 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 17 Jul 2006 14:29:33 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-17 Message-ID: <20060717182933.3EDE2152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 7 gtkwave-3.0.6-1.fc5 ircd-hybrid-7.2.2-1.fc5 lash-0.5.1-6.fc5 pam_abl-0.2.3-1.fc5 rrdtool-1.2.15-1.fc5 scorched3d-40-1.fc5 svgalib-1.9.25-2.fc5 Packages built and released for Fedora Extras 4: 5 gtkwave-3.0.6-1.fc4 ircd-hybrid-7.2.2-1.fc4 pam_abl-0.2.3-1.fc4 rrdtool-1.2.15-1.fc4 svgalib-1.9.25-2.fc4 Packages built and released for Fedora Extras 3: 1 ircd-hybrid-7.2.2-1.fc3 Packages built and released for Fedora Extras development: 11 audacious-1.1.0-0.2.dr2.fc6 bochs-2.3-0.1.pre2.fc6 gtkwave-3.0.6-1.fc6 ircd-hybrid-7.2.2-1.fc6 lash-0.5.1-6.fc6 pam_abl-0.2.3-1.fc6 rrdtool-1.2.15-1.fc6 scorched3d-40-1.fc6 ss5-3.5.9-1 svgalib-1.9.25-2.fc6 xscreensaver-5.00-14.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Jul 17 18:30:14 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 17 Jul 2006 14:30:14 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-17 Message-ID: <20060717183014.7AFEC152160@buildsys.fedoraproject.org> abiword: 5: 1:2.4.5-2.fc5 (FE5) 6: 1:2.4.5-1.fc6 (FE6) alsa-lib: 5: 0:1.0.11-4.rc2 (FC5-updates) 6: 0:1.0.11-3.rc2.2.1 (FC6) amarok: 5: 0:1.4.1-2.fc5 (FE5) 6: 0:1.4.0-5.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) ecl: 4: 0:0.9i-1.1.fc4 (FE4) 5: 0:0.9i-1.fc5 (FE5) 6: 0:0.9i-1.fc6 (FE6) eclipse-changelog: 5: 1:2.1.0_fc-2 (FC5-updates) 6: 1:2.1.0_fc-1 (FC6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flex: 5: 0:2.5.4a-39.fc5 (FC5-updates) 6: 0:2.5.4a-39 (FC6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gnome-applet-vm: 5: 0:0.0.7-2 (FC5-updates) 6: 0:0.0.6-1.1 (FC6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libraw1394: 5: 0:1.2.1-1.fc5 (FC5-updates) 6: 0:1.2.0-3.fc5.2.1 (FC6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2.1 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-12.fc6 (FC6) monotone: 5: 0:0.27-1.fc5 (FE5) 6: 0:0.26-2.fc6 (FE6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) postgresql: 5: 0:8.1.4-1.FC5.1 (FC5-updates) 6: 0:8.1.4-1 (FC6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) qt4: 5: 0:4.1.4-6.fc5 (FE5) 6: 0:4.1.4-5.fc6 (FE6) readahead: 5: 1:1.2-2 (FC5-updates) 6: 1:1.2-1.27 (FC6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) wordpress: 4: 0:2.0.3-4.fc4 (FE4) 5: 0:2.0.3-3.fc5 (FE5) 6: 0:2.0.3-3.fc6 (FE6) From buildsys at fedoraproject.org Mon Jul 17 18:47:57 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 17 Jul 2006 18:47:57 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-17 Message-ID: <20060717184757.26536.68820@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: fluxbox - 0.9.15.1-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: pyxdg package: fluxbox - 0.9.15.1-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: pyxdg From buildsys at fedoraproject.org Mon Jul 17 18:47:57 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 17 Jul 2006 18:47:57 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-17 Message-ID: <20060717184757.26549.46538@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.i386 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.ppc requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc5.x86_64 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: oliver AT linux-kernel.at package: syck-php - 0.55-7.fc5.i386 from fedora-extras-5-i386 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: php = 0:5.1.2 package: syck-php - 0.55-7.fc5.ppc from fedora-extras-5-ppc unresolved deps: php = 0:5.1.2 From buildsys at fedoraproject.org Mon Jul 17 18:47:57 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 17 Jul 2006 18:47:57 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-17 Message-ID: <20060717184757.26547.51016@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.ppc requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.x86_64 requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) From buildsys at fedoraproject.org Mon Jul 17 18:47:57 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 17 Jul 2006 18:47:57 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-17 Message-ID: <20060717184757.26552.1868@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 fedora AT leemhuis.info gsynaptics - 0.9.8-1.fc6.ppc gauret AT free.fr amarok-visualisation - 1.4.0-5.fc6.i386 amarok-visualisation - 1.4.0-5.fc6.ppc amarok-visualisation - 1.4.0-5.fc6.x86_64 i AT stingr.net libnetfilter_conntrack - 0.0.30-2.fc6.i386 libnetfilter_conntrack - 0.0.30-2.fc6.ppc libnetfilter_conntrack - 0.0.30-2.fc6.x86_64 ivazquez AT ivazquez.net gnome-applet-music - 0.9.0-1.fc6.i386 gnome-applet-music - 0.9.0-1.fc6.ppc gnome-applet-music - 0.9.0-1.fc6.x86_64 nautilus-search-tool - 0.2-1.fc5.i386 nautilus-search-tool - 0.2-1.fc5.ppc nautilus-search-tool - 0.2-1.fc5.x86_64 matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 gfontview - 0.5.0-5.fc5.ppc gfontview - 0.5.0-5.fc5.x86_64 gtkhtml36 - 3.6.2-5.fc6.i386 gtkhtml36 - 3.6.2-5.fc6.ppc gtkhtml36 - 3.6.2-5.fc6.x86_64 libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 pertusus AT free.fr cernlib - 2005-21.fc6.ppc cernlib-packlib - 2005-21.fc6.ppc patchy - 2005-21.fc6.ppc paw - 2005-21.fc6.ppc rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 libibverbs - 1.0.3-1.fc6.ppc libibverbs - 1.0.3-1.fc6.x86_64 libibverbs-utils - 1.0.3-1.fc6.i386 libibverbs-utils - 1.0.3-1.fc6.ppc libibverbs-utils - 1.0.3-1.fc6.x86_64 thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 directfb - 0.9.24-5.fc5.ppc directfb - 0.9.24-5.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.i386 requires libvisual.so.0 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.i386 requires libgailutil.so.17 gtkhtml36-3.6.2-5.fc6.i386 requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libnetfilter_conntrack-0.0.30-2.fc6.i386 requires libnfnetlink.so.0 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.i386 requires libgailutil.so.17 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.ppc requires libvisual.so.0 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.ppc requires libgailutil.so.17 gsynaptics-0.9.8-1.fc6.ppc requires synaptics gtkhtml36-3.6.2-5.fc6.ppc requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libnetfilter_conntrack-0.0.30-2.fc6.ppc requires libnfnetlink.so.0 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.ppc requires libgailutil.so.17 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.x86_64 requires libvisual.so.0()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libgailutil.so.17()(64bit) gtkhtml36-3.6.2-5.fc6.x86_64 requires libgailutil.so.17()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libnetfilter_conntrack-0.0.30-2.fc6.x86_64 requires libnfnetlink.so.0()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) nautilus-search-tool-0.2-1.fc5.x86_64 requires libgailutil.so.17()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From rc040203 at freenet.de Tue Jul 18 04:45:48 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 18 Jul 2006 06:45:48 +0200 Subject: rpms/skstream/devel skstream.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200607172305.k6HN5FS8016483@cvs-int.fedora.redhat.com> References: <200607172305.k6HN5FS8016483@cvs-int.fedora.redhat.com> Message-ID: <1153197948.4569.520.camel@mccallum.corsepiu.local> On Mon, 2006-07-17 at 16:05 -0700, Michael Thomas wrote: > Author: wart > > Update of /cvs/extras/rpms/skstream/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16445/devel > --- NEW FILE skstream.spec --- > %description > skstream is an isotream C++ socket library and is recommended for use as a isotream, I guess you mean iostream? > %check > make check || : Why the ||: ? We want to see things fail if they fail. Ralf From panemade at gmail.com Tue Jul 18 07:20:06 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Tue, 18 Jul 2006 12:50:06 +0530 Subject: Can i Obsoletes core packages from extras package? Message-ID: Hi, I am planning to add Gutenprint package to Fedora-extras. Gutenprint was formerly called Gimp-Print. So once this package is in Fedora-extras it needs first to remove following packages gimp-print gimp-print-cups gimp-print-devel gimp-print-plugin gimp-print-utils But is it allowed to do that? I have opened a review request for this package. You can check it at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199108 Thanks & Regards, Parag Nemade. From kevin.kofler at chello.at Tue Jul 18 10:58:35 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 18 Jul 2006 10:58:35 +0000 (UTC) Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-17 References: <20060717184757.26549.46538@extras64.linux.duke.edu> Message-ID: Fedora Extras repoclosure writes: > oliver AT linux-kernel.at > syck-php - 0.55-7.fc5.i386 > syck-php - 0.55-7.fc5.ppc > syck-php - 0.55-7.fc5.x86_64 What about this one? This has been broken for weeks. I filed a bug report (#192798) about it, it has been completely ignored, as have the regular repoclosure nagmails. There's also an old RFE requesting a version upgrade which has not been acted on (nor has a reason been given why the upgrade is not desirable). Looks like the classical AWOL packager. Note that I'm NOT offering to take up this package, I don't even know what it is for. :-) I'm only noticing it because it keep showing up in the repoclosure reports. Kevin Kofler From skvidal at linux.duke.edu Tue Jul 18 12:03:47 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 18 Jul 2006 08:03:47 -0400 Subject: Can i Obsoletes core packages from extras package? In-Reply-To: References: Message-ID: <1153224227.4234.45.camel@cutter> On Tue, 2006-07-18 at 12:50 +0530, Parag N(????) wrote: > Hi, > I am planning to add Gutenprint package to Fedora-extras. Gutenprint > was formerly called Gimp-Print. So once this package is in > Fedora-extras it needs first to remove following packages > gimp-print > gimp-print-cups > gimp-print-devel > gimp-print-plugin > gimp-print-utils > But is it allowed to do that? > I have opened a review request for this package. You can check it at > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199108 > No. Absolutely not. Extras packages are not allowed to obsolete or explicitly conflict with core. -sv From paul at city-fan.org Tue Jul 18 12:08:30 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 18 Jul 2006 13:08:30 +0100 Subject: Can i Obsoletes core packages from extras package? In-Reply-To: <1153224227.4234.45.camel@cutter> References: <1153224227.4234.45.camel@cutter> Message-ID: <44BCCF3E.5010900@city-fan.org> seth vidal wrote: > On Tue, 2006-07-18 at 12:50 +0530, Parag N(????) wrote: >> Hi, >> I am planning to add Gutenprint package to Fedora-extras. Gutenprint >> was formerly called Gimp-Print. So once this package is in >> Fedora-extras it needs first to remove following packages >> gimp-print >> gimp-print-cups >> gimp-print-devel >> gimp-print-plugin >> gimp-print-utils >> But is it allowed to do that? >> I have opened a review request for this package. You can check it at >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199108 >> > > No. Absolutely not. > > Extras packages are not allowed to obsolete or explicitly conflict with > core. I was pretty sure this was the case, but I can't seem to find it documented anywhere in the packaging guidelines. Did I miss somewhere? Paul. From Matt_Domsch at dell.com Tue Jul 18 12:20:52 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 18 Jul 2006 07:20:52 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-07-18 Message-ID: <20060718122052.GC26349@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Tue Jul 18 00:46:41 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: argus-2.0.6.fixes.1-11.fc6 197215 NEW bidiv-1.5-3.fc5 197224 NEW Number failed to build: 114 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 113 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 93 ---------------------------------- azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com cal3d-0.11.0-1.fc6.1 chris.stone at gmail.com camstream-0.26.3-9.fc5 nomis80 at nomis80.org contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net ddskk-12.2.0-7.fc5 petersen at redhat.com diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com ecl-0.9i-1.fc6 gemi at bluewin.ch epiphany-extensions-2.14.1-1 caillon at redhat.com exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com flim-1.14.7-3 petersen at redhat.com gc-6.8-1.fc6 rdieter at math.unl.edu ghdl-0.24-0.59svn.2.fc6 t.sailer at alumni.ethz.ch gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de gnumeric-1.6.3-3.fc6 j.w.r.degoede at hhs.nl gobby-0.4.0-6.rc2.fc6 lmacken at redhat.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org GtkAda-2.4.0-11.fc5 gemi at bluewin.ch Hermes-1.3.3-7 thomas at apestaart.org ifplugd-0.24-6 aaron.bennett at olin.edu john-1.6-4 ghenry at suretecsystems.com kanatest-0.3.6-4.fc5 robert at marcanoonline.com kdissert-1.0.5-1.1.fc5 icon at fedoraproject.org kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu kover-2.9.6-5 adrian at lisas.de ladspa-1.12-5 thomas at apestaart.org leafpad-0.8.9-1.fc6 ivazquez at ivazquez.net libchmxx-0.1-3.fc6 pertusus at free.fr librx-1.5-6.fc5 tcallawa at redhat.com libtabe-0.2.6-14 llch at redhat.com libtomoe-gtk-0.1.0-5.fc5 ryo-dairiki at users.sourceforge.net licq-1.3.2-8 pvrabec at redhat.com linkchecker-3.3-3 redhat at flyn.org logjam-4.5.3-4.fc6 tcallawa at redhat.com lucidlife-0.9-8.fc6 peter at thecodergeek.com MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mfstools-2.0-9.snapshot050221.fc5 tcallawa at redhat.com monodoc-1.1.16-1.fc6 paul at all-the-johnsons.co.uk multisync-0.90.18-5.fc5 andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 dennis at ausil.us nas-1.8-6.fc6 frank-buettner at gmx.net nautilus-search-tool-0.2-1.fc5 ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 andreas.bierfert at lowlatency.de NetworkManager-vpnc-0.7.0-0.cvs20060529.fc6 davidz at redhat.com ngrep-1.44-4.fc5 oliver at linux-kernel.at ogre-1.2.1-2.fc6 j.w.r.degoede at hhs.nl openal-0.0.9-0.5.20060204cvs.fc5 andreas.bierfert at lowlatency.de openalpp-20060405-10.fc6 chris.stone at gmail.com opencv-0.9.7-15.fc5 nomis80 at nomis80.org orange-0.3-1.cvs20051118.fc6 andreas.bierfert at lowlatency.de osgcal-0.1.40-3.fc6 chris.stone at gmail.com pam_keyring-0.0.7-2 redhat at flyn.org perl-Test-WWW-Mechanize-1.12-1.fc6 jpo at di.uminho.pt pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.16-1.fc6 gemi at bluewin.ch powerman-1.0.24-1.fc6 jwilson at redhat.com pybliographer-1.2.9-1.fc6 z.kota at gmx.net python-goopy-0.1-1 pjones at redhat.com python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net qalculate-kde-0.9.4-1.fc6 dakingun at gmail.com quarry-0.1.16-2.fc5 michel.salim at gmail.com radiusclient-ng-0.5.2-3.fc6 jeff at ollie.clive.ia.us raidem-0.3.1-3.fc6 j.w.r.degoede at hhs.nl rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rss-glx-0.8.1.p-3.fc6 nphilipp at redhat.com rssowl-1.2-12.fc6 green at redhat.com sabayon-2.12.3-3 markmc at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at scmxx-0.8.2-1.fc5 andreas at bawue.net SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-6.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net sloccount-2.26-4 bnocera at redhat.com stratagus-2.1-5.fc6 lemenkov at newmail.ru syck-0.55-7.fc5 oliver at linux-kernel.at sylpheed-claws-plugins-2.3.0-2.fc6 andreas.bierfert at lowlatency.de synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com tidy-0.99.0-10.20051025.fc6 rdieter at math.unl.edu WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xcompmgr-1.1.3-4.fc6 dakingun at gmail.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com xsupplicant-1.2.6-1.fc6 tcallawa at redhat.com yasm-0.5.0-1.fc6 matthias at rpmforge.net With bugs filed: 20 ---------------------------------- alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com ccrtp-1.3.7-1.fc6 ['197362 NEW'] andreas at bawue.net cowbell-0.2.7.1-2.fc6 ['197366 CLOSED'] foolish at guezz.net dillo-0.8.6-2.fc6 ['197370 CLOSED'] andreas.bierfert at lowlatency.de drgeo-1.1.0-10.fc6 ['197614 CLOSED'] eric.tanguy at univ-nantes.fr erlang-R11B-0.2.fc6 ['197696 CLOSED'] gemi at bluewin.ch fish-1.12.0-1.fc5 ['179296 NEW'] oliver at linux-kernel.at flow-tools-0.68-10.fc6 ['197706 NEW'] i at stingr.net gdesklets-0.35.3-8.fc6 ['197799 NEW'] luya256 at yahoo.com gnomad2-2.8.6-1.fc6 ['197920 NEW'] triad at df.lth.se gnome-applet-music-0.9.0-1.fc6 ['197924 NEW'] ivazquez at ivazquez.net gnome-schedule-1.0.0-1 ['197927 NEW'] frank at scirocco-5v-turbo.de grads-1.9b4-12.fc6 ['197942 CLOSED'] pertusus at free.fr grhino-0.15.0-5.fc5 ['197950 NEW'] michel.salim at gmail.com gtktalog-1.0.4-7.fc5 ['198897 NEW'] matthias at rpmforge.net jam-2.5-3.fc5 ['198924 NEW'] tcallawa at redhat.com nco-3.1.2-1.fc6 ['193541 NEW'] ed at eh3.com xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Tue Jul 18 12:21:41 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 18 Jul 2006 07:21:41 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-18 Message-ID: <20060718122141.GD26349@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Tue Jul 18 00:42:36 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: argus-2.0.6.fixes.1-11.fc6 197215 NEW bidiv-1.5-3.fc5 197224 NEW Number failed to build: 139 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 128 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 108 ---------------------------------- atitvout-0.4-5 andreas.bierfert at lowlatency.de azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com cal3d-0.11.0-1.fc6.1 chris.stone at gmail.com camstream-0.26.3-9.fc5 nomis80 at nomis80.org contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net ddskk-12.2.0-7.fc5 petersen at redhat.com diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com ecl-0.9i-1.fc6 gemi at bluewin.ch epiphany-extensions-2.14.1-1 caillon at redhat.com exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com flim-1.14.7-3 petersen at redhat.com foobillard-3.0a-4 mitr at redhat.com freenx-0.5.0-2.fc6 zipsonic at gmail.com gambas-1.0.14-2.fc5 tcallawa at redhat.com gc-6.8-1.fc6 rdieter at math.unl.edu ghdl-0.24-0.59svn.2.fc6 t.sailer at alumni.ethz.ch gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de gnumeric-1.6.3-3.fc6 j.w.r.degoede at hhs.nl gobby-0.4.0-6.rc2.fc6 lmacken at redhat.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org GtkAda-2.4.0-11.fc5 gemi at bluewin.ch ifplugd-0.24-6 aaron.bennett at olin.edu john-1.6-4 ghenry at suretecsystems.com kanatest-0.3.6-4.fc5 robert at marcanoonline.com kdissert-1.0.5-1.1.fc5 icon at fedoraproject.org kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu kover-2.9.6-5 adrian at lisas.de ladspa-1.12-5 thomas at apestaart.org leafpad-0.8.9-1.fc6 ivazquez at ivazquez.net libchmxx-0.1-3.fc6 pertusus at free.fr libhugetlbfs-0.20060706-1.fc6 drfickle at k-lug.org libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libtabe-0.2.6-14 llch at redhat.com libtomoe-gtk-0.1.0-5.fc5 ryo-dairiki at users.sourceforge.net licq-1.3.2-8 pvrabec at redhat.com linkchecker-3.3-3 redhat at flyn.org logjam-4.5.3-4.fc6 tcallawa at redhat.com lucidlife-0.9-8.fc6 peter at thecodergeek.com Macaulay2-0.9.8-0.3.cvs20060327.fc6 rdieter at math.unl.edu MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mhonarc-2.6.16-1.fc6 gauret at free.fr mlton-20051202-8.fc6 adam at spicenitz.org monodoc-1.1.16-1.fc6 paul at all-the-johnsons.co.uk multisync-0.90.18-5.fc5 andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 dennis at ausil.us nas-1.8-6.fc6 frank-buettner at gmx.net nautilus-search-tool-0.2-1.fc5 ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 andreas.bierfert at lowlatency.de NetworkManager-vpnc-0.7.0-0.cvs20060529.fc6 davidz at redhat.com new-1.3.7-2 redhat at flyn.org ngrep-1.44-4.fc5 oliver at linux-kernel.at nx-2.0.0-3.fc6 zipsonic at gmail.com ogre-1.2.1-2.fc6 j.w.r.degoede at hhs.nl openal-0.0.9-0.5.20060204cvs.fc5 andreas.bierfert at lowlatency.de openalpp-20060405-10.fc6 chris.stone at gmail.com opencv-0.9.7-15.fc5 nomis80 at nomis80.org osgcal-0.1.40-3.fc6 chris.stone at gmail.com pam_keyring-0.0.7-2 redhat at flyn.org perl-Unicode-Map8-0.12-8.fc5 gauret at free.fr perl-Unicode-MapUTF8-1.09-6.fc5 gauret at free.fr php-pear-DB-1.7.6-6 rpm at timj.co.uk pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.16-1.fc6 gemi at bluewin.ch powerman-1.0.24-1.fc6 jwilson at redhat.com pybliographer-1.2.9-1.fc6 z.kota at gmx.net python-cheetah-2.0-0.1.rc7.fc6 mikeb at redhat.com python-dateutil-1.1-2.fc5 orion at cora.nwra.com python-goopy-0.1-1 pjones at redhat.com python-reportlab-1.20-5.fc5 bdpepple at ameritech.net python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net q-7.1-2.fc6 gemi at bluewin.ch qalculate-kde-0.9.4-1.fc6 dakingun at gmail.com quarry-0.1.16-2.fc5 michel.salim at gmail.com radiusclient-ng-0.5.2-3.fc6 jeff at ollie.clive.ia.us raidem-0.3.1-3.fc6 j.w.r.degoede at hhs.nl rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rss-glx-0.8.1.p-3.fc6 nphilipp at redhat.com rssowl-1.2-12.fc6 green at redhat.com sabayon-2.12.3-3 markmc at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at scmxx-0.8.2-1.fc5 andreas at bawue.net SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-6.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net sloccount-2.26-4 bnocera at redhat.com stratagus-2.1-5.fc6 lemenkov at newmail.ru sylpheed-claws-plugins-2.3.0-2.fc6 andreas.bierfert at lowlatency.de synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com tidy-0.99.0-10.20051025.fc6 rdieter at math.unl.edu uqm-0.5.0-1.fc5 icon at fedoraproject.org WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xcompmgr-1.1.3-4.fc6 dakingun at gmail.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com xsp-1.1.15-6.fc6 paul at all-the-johnsons.co.uk xsupplicant-1.2.6-1.fc6 tcallawa at redhat.com yasm-0.5.0-1.fc6 matthias at rpmforge.net z88dk-1.6-8.fc5 paul at all-the-johnsons.co.uk With bugs filed: 20 ---------------------------------- alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com ccrtp-1.3.7-1.fc6 ['197362 NEW'] andreas at bawue.net cowbell-0.2.7.1-2.fc6 ['197366 CLOSED'] foolish at guezz.net dillo-0.8.6-2.fc6 ['197370 CLOSED'] andreas.bierfert at lowlatency.de drgeo-1.1.0-10.fc6 ['197614 CLOSED'] eric.tanguy at univ-nantes.fr erlang-R11B-0.2.fc6 ['197696 CLOSED'] gemi at bluewin.ch fish-1.12.0-1.fc5 ['179296 NEW'] oliver at linux-kernel.at flow-tools-0.68-10.fc6 ['197706 NEW'] i at stingr.net gdesklets-0.35.3-8.fc6 ['197799 NEW'] luya256 at yahoo.com gnomad2-2.8.6-1.fc6 ['197920 NEW'] triad at df.lth.se gnome-applet-music-0.9.0-1.fc6 ['197924 NEW'] ivazquez at ivazquez.net gnome-schedule-1.0.0-1 ['197927 NEW'] frank at scirocco-5v-turbo.de grads-1.9b4-12.fc6 ['197942 CLOSED'] pertusus at free.fr grhino-0.15.0-5.fc5 ['197950 NEW'] michel.salim at gmail.com gtktalog-1.0.4-7.fc5 ['198897 NEW'] matthias at rpmforge.net jam-2.5-3.fc5 ['198924 NEW'] tcallawa at redhat.com nco-3.1.2-1.fc6 ['193541 NEW'] ed at eh3.com xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jwboyer at jdub.homelinux.org Tue Jul 18 12:24:08 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 18 Jul 2006 07:24:08 -0500 Subject: Can i Obsoletes core packages from extras package? In-Reply-To: <44BCCF3E.5010900@city-fan.org> References: <1153224227.4234.45.camel@cutter> <44BCCF3E.5010900@city-fan.org> Message-ID: <1153225448.31703.24.camel@weaponx.rchland.ibm.com> On Tue, 2006-07-18 at 13:08 +0100, Paul Howarth wrote: > seth vidal wrote: > > On Tue, 2006-07-18 at 12:50 +0530, Parag N(????) wrote: > >> Hi, > >> I am planning to add Gutenprint package to Fedora-extras. Gutenprint > >> was formerly called Gimp-Print. So once this package is in > >> Fedora-extras it needs first to remove following packages > >> gimp-print > >> gimp-print-cups > >> gimp-print-devel > >> gimp-print-plugin > >> gimp-print-utils > >> But is it allowed to do that? > >> I have opened a review request for this package. You can check it at > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199108 > >> > > > > No. Absolutely not. > > > > Extras packages are not allowed to obsolete or explicitly conflict with > > core. > > I was pretty sure this was the case, but I can't seem to find it > documented anywhere in the packaging guidelines. Did I miss somewhere? I can't find it anywhere either. I'm pretty sure that was an explicit thing mentioned in the past. Perhaps when Core adopted Extras packaging guidelines that part got removed. It should be added somewhere again. josh From wart at kobold.org Tue Jul 18 15:03:19 2006 From: wart at kobold.org (Wart) Date: Tue, 18 Jul 2006 08:03:19 -0700 Subject: rpms/skstream/devel skstream.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <1153197948.4569.520.camel@mccallum.corsepiu.local> References: <200607172305.k6HN5FS8016483@cvs-int.fedora.redhat.com> <1153197948.4569.520.camel@mccallum.corsepiu.local> Message-ID: <44BCF837.7040501@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Corsepius wrote: > On Mon, 2006-07-17 at 16:05 -0700, Michael Thomas wrote: > >>Author: wart >> >>Update of /cvs/extras/rpms/skstream/devel >>In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16445/devel > > >>--- NEW FILE skstream.spec --- > > >>%description >>skstream is an isotream C++ socket library and is recommended for use as a > > isotream, I guess you mean iostream? Yes, my bad. > >>%check >>make check || : > > Why the ||: ? > > We want to see things fail if they fail. - From the review request (BZ #198832): "==== NOTES ==== - - make check has some failures, but these are okay, they require the echo service to be enabled or be run as root. I enabled echo on my system and ran make check as root and these tests pass." Without the ||:, then this package would never build in the build system due to the test failures. Unfortunately, this means that I will have to check the test output in the build logs manually. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEvPg2DeYlPfs40g8RAt7lAJ9I4NDwBdYGHgJ4gxj7YbT+Y+FVhQCfS2fd zMk4FREU5yEOyq9LJRD3zuc= =NWxB -----END PGP SIGNATURE----- From denis at poolshark.org Tue Jul 18 16:22:35 2006 From: denis at poolshark.org (Denis Leroy) Date: Tue, 18 Jul 2006 18:22:35 +0200 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-17 In-Reply-To: <20060717184757.26547.51016@extras64.linux.duke.edu> References: <20060717184757.26547.51016@extras64.linux.duke.edu> Message-ID: <44BD0ACB.50304@poolshark.org> Fedora Extras repoclosure wrote: > Summary of broken packages (by owner): > ---------------------------------------------------------------------- > ivazquez AT ivazquez.net > wp_tray - 0.5.1-1.fc4.i386 > wp_tray - 0.5.1-1.fc4.ppc > wp_tray - 0.5.1-1.fc4.x86_64 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196911 It's been 2 1/2 weeks. As per the Wiki process, does anyone know what happened to Ignacio ? I'd like to take over ownership to be able to fix this before FC-4 goes over to Legacy... From Axel.Thimm at ATrpms.net Tue Jul 18 17:37:22 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 18 Jul 2006 19:37:22 +0200 Subject: Can i Obsoletes core packages from extras package? In-Reply-To: <1153225448.31703.24.camel@weaponx.rchland.ibm.com> References: <1153224227.4234.45.camel@cutter> <44BCCF3E.5010900@city-fan.org> <1153225448.31703.24.camel@weaponx.rchland.ibm.com> Message-ID: <20060718173722.GG5874@neu.nirvana> On Tue, Jul 18, 2006 at 07:24:08AM -0500, Josh Boyer wrote: > On Tue, 2006-07-18 at 13:08 +0100, Paul Howarth wrote: > > seth vidal wrote: > > > On Tue, 2006-07-18 at 12:50 +0530, Parag N(????) wrote: > > >> Hi, > > >> I am planning to add Gutenprint package to Fedora-extras. Gutenprint > > >> was formerly called Gimp-Print. So once this package is in > > >> Fedora-extras it needs first to remove following packages > > >> gimp-print > > >> gimp-print-cups > > >> gimp-print-devel > > >> gimp-print-plugin > > >> gimp-print-utils > > >> But is it allowed to do that? > > >> I have opened a review request for this package. You can check it at > > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199108 > > >> > > > > > > No. Absolutely not. > > > > > > Extras packages are not allowed to obsolete or explicitly conflict with > > > core. > > > > I was pretty sure this was the case, but I can't seem to find it > > documented anywhere in the packaging guidelines. Did I miss somewhere? > > I can't find it anywhere either. I'm pretty sure that was an explicit > thing mentioned in the past. Perhaps when Core adopted Extras packaging > guidelines that part got removed. > > It should be added somewhere again. It wasn't in any packaging guidelines but in the definition of Fedora Extras on fedora.redhat.com. Maybe a new definition is needeexplaining also other (non-)differences of Core and Extras? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Jul 18 17:38:50 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 18 Jul 2006 19:38:50 +0200 Subject: VTK anyone? In-Reply-To: References: <20060710144436.GB5455@free.fr> <44B27321.4060809@cora.nwra.com> <44B3DAA5.4050506@jhu.edu> <20060712075318.GA1242@neu.nirvana> Message-ID: <20060718173850.GH5874@neu.nirvana> On Wed, Jul 12, 2006 at 10:23:19AM +0200, Gianluca Sforna wrote: > On 7/12/06, Axel Thimm wrote: > >On Tue, Jul 11, 2006 at 11:24:19PM +0200, Gianluca Sforna wrote: > >> Ok. Since I still need a package ACCEPTED for gaining Extras CVS > >> access, I will try to do my best at this (of course, I still assume > >> no-one else wants to do that instead...) > > > >Well, I've already put quite some time into vtk packaging with the > >intend to push it to extras when it's done and I also need it for my > >(current) day job, so I'm interested in continuing maintenance. > >-- > > Considering that, (1) I trust your packaging skills much more than > mine and (2) it's stupid to waste our time, I will happily have a look > it when you submit the spec for review. > > Thanks a lot > > PS. the current spec on the atrmps page is not suitable for Extras > submission, is it? It should be by now. There was a longer fight with rpath and I had to use sinister methods. Give it a try, I'll start submitting it and required dependencies, soon. -- 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 chris.stone at gmail.com Tue Jul 18 19:07:54 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 18 Jul 2006 12:07:54 -0700 Subject: Extras i386 rawhide rebuild in mock status 2006-07-18 In-Reply-To: <20060718122052.GC26349@lists.us.dell.com> References: <20060718122052.GC26349@lists.us.dell.com> Message-ID: On 7/18/06, Matt Domsch wrote: > Extras Rawhide-in-Mock Build Results for i386 Tue Jul 18 00:46:41 CDT 2006 > > cal3d-0.11.0-1.fc6.1 chris.stone at gmail.com This is what I got from the root.log: Transaction Check Error: file /usr/share/info/dir from install of m4-1.4.5-1 conflicts with file from package info-4.8-11.1 This obviously is not a cal3d problem... From cweyl at alumni.drew.edu Tue Jul 18 19:43:13 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 18 Jul 2006 12:43:13 -0700 Subject: add-to-owners helper script... Message-ID: <7dd7ab490607181243l50969d13ld3056b72663a8196@mail.gmail.com> Hey all -- I have a very simple script I've been using to add entries to the owners.list, by pulling information from ~/.plague-client.cfg, and the rpm itself (either a file or the rpmdb). It generates the line, adds it (sorted) to owners.list, then prompts with a diff for review before checking it in. It doesn't do anything aside from that, nor was it designed to. http://home.comcast.net/~ckweyl/add-to-owners Thoughts, comments? Would this be useful to have in cvs, in the owners module also? -Chris -- Chris Weyl Ex astris, scientia From chris.stone at gmail.com Tue Jul 18 19:45:46 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 18 Jul 2006 12:45:46 -0700 Subject: add-to-owners helper script... In-Reply-To: <7dd7ab490607181243l50969d13ld3056b72663a8196@mail.gmail.com> References: <7dd7ab490607181243l50969d13ld3056b72663a8196@mail.gmail.com> Message-ID: On 7/18/06, Chris Weyl wrote: > Hey all -- > > I have a very simple script I've been using to add entries to the > owners.list, by pulling information from ~/.plague-client.cfg, and the > rpm itself (either a file or the rpmdb). It generates the line, adds > it (sorted) to owners.list, then prompts with a diff for review before > checking it in. It doesn't do anything aside from that, nor was it > designed to. > > http://home.comcast.net/~ckweyl/add-to-owners > > Thoughts, comments? Would this be useful to have in cvs, in the > owners module also? Cool, can this handle adding emails in the cc list as well? and can it auto add cc emails like for the case of perl packages? From steve at silug.org Tue Jul 18 19:59:42 2006 From: steve at silug.org (Steven Pritchard) Date: Tue, 18 Jul 2006 14:59:42 -0500 Subject: add-to-owners helper script... In-Reply-To: References: <7dd7ab490607181243l50969d13ld3056b72663a8196@mail.gmail.com> Message-ID: <20060718195942.GA14424@osiris.silug.org> On Tue, Jul 18, 2006 at 12:45:46PM -0700, Christopher Stone wrote: > Cool, can this handle adding emails in the cc list as well? and can it > auto add cc emails like for the case of perl packages? This can: http://fedoraproject.org/wiki/Extras/UsefulScripts#head-b001e04919bf8e5d77d52665f1cb8aac8b09a8df Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From paul at city-fan.org Tue Jul 18 20:07:47 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 18 Jul 2006 21:07:47 +0100 Subject: Extras i386 rawhide rebuild in mock status 2006-07-18 In-Reply-To: References: <20060718122052.GC26349@lists.us.dell.com> Message-ID: <1153253267.10279.0.camel@laurel.intra.city-fan.org> On Tue, 2006-07-18 at 12:07 -0700, Christopher Stone wrote: > On 7/18/06, Matt Domsch wrote: > > Extras Rawhide-in-Mock Build Results for i386 Tue Jul 18 00:46:41 CDT 2006 > > > > cal3d-0.11.0-1.fc6.1 chris.stone at gmail.com > > This is what I got from the root.log: > > Transaction Check Error: file /usr/share/info/dir from install of > m4-1.4.5-1 conflicts with file from package info-4.8-11.1 > > This obviously is not a cal3d problem... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199081 Paul. From cweyl at alumni.drew.edu Tue Jul 18 21:00:21 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 18 Jul 2006 14:00:21 -0700 Subject: add-to-owners helper script... In-Reply-To: References: <7dd7ab490607181243l50969d13ld3056b72663a8196@mail.gmail.com> Message-ID: <7dd7ab490607181400u4cd80489qe753082acde56e8d@mail.gmail.com> On 7/18/06, Christopher Stone wrote: > Cool, can this handle adding emails in the cc list as well? and can it > auto add cc emails like for the case of perl packages? It does already, based on a regexp match. Adding others (that I'm not currently aware of) should be a matter of a line or two more... -Chris -- Chris Weyl Ex astris, scientia From chris.stone at gmail.com Wed Jul 19 02:52:40 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 18 Jul 2006 19:52:40 -0700 Subject: add-to-owners helper script... In-Reply-To: <7dd7ab490607181400u4cd80489qe753082acde56e8d@mail.gmail.com> References: <7dd7ab490607181243l50969d13ld3056b72663a8196@mail.gmail.com> <7dd7ab490607181400u4cd80489qe753082acde56e8d@mail.gmail.com> Message-ID: On 7/18/06, Chris Weyl wrote: > On 7/18/06, Christopher Stone wrote: > > Cool, can this handle adding emails in the cc list as well? and can it > > auto add cc emails like for the case of perl packages? > > It does already, based on a regexp match. Adding others (that I'm not > currently aware of) should be a matter of a line or two more... There should be a way to add any CC you want from the command line From cweyl at alumni.drew.edu Wed Jul 19 03:48:45 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 18 Jul 2006 20:48:45 -0700 Subject: add-to-owners helper script... In-Reply-To: References: <7dd7ab490607181243l50969d13ld3056b72663a8196@mail.gmail.com> <7dd7ab490607181400u4cd80489qe753082acde56e8d@mail.gmail.com> Message-ID: <7dd7ab490607182048u33e286d3s3057ca0c1e5fd4b9@mail.gmail.com> On 7/18/06, Christopher Stone wrote: > There should be a way to add any CC you want from the command line Ask, and ye shall receive. (Same URL.) However, I think that pretty much uses up the script's "simple" quota. -Chris -- Chris Weyl Ex astris, scientia From buildsys at fedoraproject.org Wed Jul 19 09:55:40 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 19 Jul 2006 05:55:40 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-19 Message-ID: <20060719095540.5BD02152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 15 blender-2.42-3.fc5 cegui-0.4.1-9.fc5 chess-1.0-1.fc5 clisp-2.39-1.fc5 mew-5.1-1.fc5 perl-IO-Tty-1.06-1.fc5 perl-Image-Info-1.22-1.fc5 perl-POE-Component-Client-DNS-0.99-1.fc5 perl-SOAP-Lite-0.68-1.fc5 pexpect-2.1-1.fc5 qa-assistant-0.4.90.5-1.fc5 renrot-0.22-1.0.fc5 rsnapshot-1.2.9-2.fc5 rxvt-unicode-7.8-1.fc5 xpilot-ng-4.7.2-9.fc5 Packages built and released for Fedora Extras 4: 12 cegui-0.4.1-9.fc4 clisp-2.39-1.fc4 mew-5.1-1.fc4 ode-0.6-2.fc4 perl-IO-Tty-1.06-1.fc4 perl-SOAP-Lite-0.68-1.fc4 pexpect-2.1-1.fc4 renrot-0.22-1.0.fc4 rsnapshot-1.2.9-4.fc4 rxvt-unicode-7.8-1.fc4 scorched3d-40-1.fc4 xpilot-ng-4.7.2-8.fc4 Packages built and released for Fedora Extras 3: 2 pam_abl-0.2.3-1.fc3 rxvt-unicode-7.8-1.fc3 Packages built and released for Fedora Extras development: 22 atlascpp-0.6.0-2.fc6 blender-2.42-3.fc6 cegui-0.4.1-9.fc6 clisp-2.39-1.fc6 libnetfilter_conntrack-0.0.31-2.fc6 lucidlife-0.9-9.fc6 mew-5.1-1.fc6 ogre-1.2.1-3.fc6 perl-Expect-1.19-1.fc6 perl-IO-Tty-1.06-1.fc6 perl-Module-Pluggable-3.10-1.fc6 perl-POE-Filter-IRCD-1.7-1.fc6 perl-SOAP-Lite-0.68-1.fc6 perl-eperl-2.2.14-2.fc6 pexpect-2.1-1.fc6 qa-assistant-0.4.90.5-1.fc6.1 raidem-0.3.1-4.fc6 renrot-0.22-1.0.fc6 rxvt-unicode-7.8-1.fc6 skstream-0.3.5-2.fc6 wesnoth-1.0.2-3.fc6 xpilot-ng-4.7.2-9.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Jul 19 09:56:06 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 19 Jul 2006 05:56:06 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-19 Message-ID: <20060719095606.30D99152169@buildsys.fedoraproject.org> abiword: 5: 1:2.4.5-2.fc5 (FE5) 6: 1:2.4.5-1.fc6 (FE6) alsa-lib: 5: 0:1.0.11-4.rc2 (FC5-updates) 6: 0:1.0.11-3.rc2.2.1 (FC6) amarok: 5: 0:1.4.1-2.fc5 (FE5) 6: 0:1.4.0-5.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) ecl: 4: 0:0.9i-1.1.fc4 (FE4) 5: 0:0.9i-1.fc5 (FE5) 6: 0:0.9i-1.fc6 (FE6) eclipse-changelog: 5: 1:2.1.0_fc-2 (FC5-updates) 6: 1:2.1.0_fc-1 (FC6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gnome-applet-vm: 5: 0:0.0.7-2 (FC5-updates) 6: 0:0.0.6-1.1 (FC6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) libraw1394: 5: 0:1.2.1-1.fc5 (FC5-updates) 6: 0:1.2.0-3.fc5.2.1 (FC6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2.1 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-13.fc6 (FC6) mailcap: 5: 0:2.1.21-1.fc5 (FC5-updates) 6: 0:2.1.20-1.1 (FC6) monotone: 5: 0:0.27-1.fc5 (FE5) 6: 0:0.26-2.fc6 (FE6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) qt4: 5: 0:4.1.4-6.fc5 (FE5) 6: 0:4.1.4-5.fc6 (FE6) readahead: 5: 1:1.2-2 (FC5-updates) 6: 1:1.2-1.27 (FC6) rsnapshot: 4: 0:1.2.9-4.fc4 (FE4) 5: 0:1.2.9-2.fc5 (FE5) 6: 0:1.2.9-2.fc6 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) subversion-api-docs: 5: 0:1.3.2-1.fc5 (FE5) 6: 0:1.3.1-1.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) wordpress: 4: 0:2.0.3-4.fc4 (FE4) 5: 0:2.0.3-3.fc5 (FE5) 6: 0:2.0.3-3.fc6 (FE6) From buildsys at fedoraproject.org Wed Jul 19 10:17:18 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 19 Jul 2006 10:17:18 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-19 Message-ID: <20060719101718.17111.73935@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 wp_tray - 0.5.1-1.fc4.ppc wp_tray - 0.5.1-1.fc4.x86_64 lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.ppc requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.x86_64 requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) From buildsys at fedoraproject.org Wed Jul 19 10:17:18 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 19 Jul 2006 10:17:18 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-19 Message-ID: <20060719101718.17113.42911@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.i386 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.ppc requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc5.x86_64 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From buildsys at fedoraproject.org Wed Jul 19 10:17:18 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 19 Jul 2006 10:17:18 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-19 Message-ID: <20060719101718.17115.86447@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 fedora AT leemhuis.info gsynaptics - 0.9.8-1.fc6.ppc gauret AT free.fr amarok-visualisation - 1.4.0-5.fc6.i386 amarok-visualisation - 1.4.0-5.fc6.ppc amarok-visualisation - 1.4.0-5.fc6.x86_64 ivazquez AT ivazquez.net gnome-applet-music - 0.9.0-1.fc6.i386 gnome-applet-music - 0.9.0-1.fc6.ppc gnome-applet-music - 0.9.0-1.fc6.x86_64 nautilus-search-tool - 0.2-1.fc5.i386 nautilus-search-tool - 0.2-1.fc5.ppc nautilus-search-tool - 0.2-1.fc5.x86_64 matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 gfontview - 0.5.0-5.fc5.ppc gfontview - 0.5.0-5.fc5.x86_64 gtkhtml36 - 3.6.2-5.fc6.i386 gtkhtml36 - 3.6.2-5.fc6.ppc gtkhtml36 - 3.6.2-5.fc6.x86_64 libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 pertusus AT free.fr cernlib - 2005-21.fc6.ppc cernlib-packlib - 2005-21.fc6.ppc patchy - 2005-21.fc6.ppc paw - 2005-21.fc6.ppc rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 libibverbs - 1.0.3-1.fc6.ppc libibverbs - 1.0.3-1.fc6.x86_64 libibverbs-utils - 1.0.3-1.fc6.i386 libibverbs-utils - 1.0.3-1.fc6.ppc libibverbs-utils - 1.0.3-1.fc6.x86_64 thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 directfb - 0.9.24-5.fc5.ppc directfb - 0.9.24-5.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.i386 requires libvisual.so.0 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.i386 requires libgailutil.so.17 gtkhtml36-3.6.2-5.fc6.i386 requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.i386 requires libgailutil.so.17 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.ppc requires libvisual.so.0 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.ppc requires libgailutil.so.17 gsynaptics-0.9.8-1.fc6.ppc requires synaptics gtkhtml36-3.6.2-5.fc6.ppc requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.ppc requires libgailutil.so.17 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- amarok-visualisation-1.4.0-5.fc6.x86_64 requires libvisual.so.0()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libgailutil.so.17()(64bit) gtkhtml36-3.6.2-5.fc6.x86_64 requires libgailutil.so.17()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) nautilus-search-tool-0.2-1.fc5.x86_64 requires libgailutil.so.17()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From buildsys at fedoraproject.org Wed Jul 19 10:17:18 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 19 Jul 2006 10:17:18 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-19 Message-ID: <20060719101718.17101.3156@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 fluxbox - 0.9.15.1-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From s.mako at gmx.net Wed Jul 19 11:12:15 2006 From: s.mako at gmx.net (Zoltan Kota) Date: Wed, 19 Jul 2006 13:12:15 +0200 (CEST) Subject: Extras i386 rawhide rebuild in mock status 2006-07-18 In-Reply-To: <20060718122052.GC26349@lists.us.dell.com> References: <20060718122052.GC26349@lists.us.dell.com> Message-ID: Hi, On Tue, 18 Jul 2006, Matt Domsch wrote: > Of those expected to have worked... > Without a bug filed: 93 > ---------------------------------- ... > pybliographer-1.2.9-1.fc6 z.kota at gmx.net Some days ago pybliographer was built succefully in the buildsys.fedoraproject. Here it fails. config.log shows: configure:1688: checking python requirements WARNING: could not open display Fatal Python error: could not import gnomevfs configure:1715: result: no configure:1717: error: Without cleaning the mock buildroot I chrooted to the buildroot and tried to check things manually (I don't know how reliable this method is). In terminal: bash-3.1# python Python 2.4.3 (#1, Jul 17 2006, 10:29:41) [GCC 4.1.1 20060711 (Red Hat 4.1.1-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gnome >>> import gnome.ui Fatal Python error: could not import gnomevfs Aborted bash-3.1# python Python 2.4.3 (#1, Jul 17 2006, 10:29:41) [GCC 4.1.1 20060711 (Red Hat 4.1.1-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gnomevfs Traceback (most recent call last): File "", line 1, in ? ImportError: /usr/lib/python2.4/site-packages/gtk-2.0/gnomevfs.so: undefined symbol: gnome_vfs_mime_get_all_components gnome-python2-gnomevfs is there. Do you have any idea what the problem is? What should I look for? What is the difference between the "buildsys.fedoraproject" and "buildsys.linux.dell" so that happens? Zoltan From fedora at camperquake.de Wed Jul 19 12:04:31 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 19 Jul 2006 14:04:31 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-07-18 In-Reply-To: References: <20060718122052.GC26349@lists.us.dell.com> Message-ID: <20060719140431.3e814125@sisko.addix.net> Hi. On Wed, 19 Jul 2006 13:12:15 +0200 (CEST), Zoltan Kota wrote: > Fatal Python error: could not import gnomevfs Funny, I get exactly the same error message when trying to start system-config-network on my rawhide system. gnome-python2-gnomevfs is installed. I wager rawhide is broken somewhere. From cweyl at alumni.drew.edu Wed Jul 19 15:24:27 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 19 Jul 2006 08:24:27 -0700 Subject: Can i Obsoletes core packages from extras package? In-Reply-To: <1153225448.31703.24.camel@weaponx.rchland.ibm.com> References: <1153224227.4234.45.camel@cutter> <44BCCF3E.5010900@city-fan.org> <1153225448.31703.24.camel@weaponx.rchland.ibm.com> Message-ID: <7dd7ab490607190824j5ca4c6c7w4280078cf2934d25@mail.gmail.com> On 7/18/06, Josh Boyer wrote: > I can't find it anywhere either. I'm pretty sure that was an explicit > thing mentioned in the past. Perhaps when Core adopted Extras packaging > guidelines that part got removed. > > It should be added somewhere again. +1. It should be explicit. -Chris -- Chris Weyl Ex astris, scientia From lmacken at redhat.com Wed Jul 19 16:13:50 2006 From: lmacken at redhat.com (Luke Macken) Date: Wed, 19 Jul 2006 12:13:50 -0400 Subject: add-to-owners helper script... In-Reply-To: References: <7dd7ab490607181243l50969d13ld3056b72663a8196@mail.gmail.com> Message-ID: <20060719161350.GA3926@crow.rdu.redhat.com> On Tue, Jul 18, 2006 at 12:45:46PM -0700, Christopher Stone wrote: > On 7/18/06, Chris Weyl wrote: > >Hey all -- > > > >I have a very simple script I've been using to add entries to the > >owners.list, by pulling information from ~/.plague-client.cfg, and the > >rpm itself (either a file or the rpmdb). It generates the line, adds > >it (sorted) to owners.list, then prompts with a diff for review before > >checking it in. It doesn't do anything aside from that, nor was it > >designed to. > > > >http://home.comcast.net/~ckweyl/add-to-owners > > > >Thoughts, comments? Would this be useful to have in cvs, in the > >owners module also? > > Cool, can this handle adding emails in the cc list as well? and can it > auto add cc emails like for the case of perl packages? Grabbing the CC list can easily be automated using Bugzilla's xmlrpc API. Here is an example in python: import xmlrpclib server = xmlrpclib.Server('https://bugzilla.redhat.com/bugzilla/xmlrpc.cgi') server.bugzilla.getBug(BUG_NUMBER)['cc'] Now that I think about it, all you really need for a script like this is the Bug #. From there, you could just parse the comments for the SPEC file url, then parse the spec for the package name and summary. luke From cweyl at alumni.drew.edu Wed Jul 19 16:55:36 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 19 Jul 2006 09:55:36 -0700 Subject: add-to-owners helper script... In-Reply-To: <20060719161350.GA3926@crow.rdu.redhat.com> References: <7dd7ab490607181243l50969d13ld3056b72663a8196@mail.gmail.com> <20060719161350.GA3926@crow.rdu.redhat.com> Message-ID: <7dd7ab490607190955h1fe6b373j2025529e5b0b5aba@mail.gmail.com> On 7/19/06, Luke Macken wrote: > Grabbing the CC list can easily be automated using Bugzilla's xmlrpc > API. Here is an example in python: > > import xmlrpclib > server = xmlrpclib.Server('https://bugzilla.redhat.com/bugzilla/xmlrpc.cgi') > server.bugzilla.getBug(BUG_NUMBER)['cc'] > > Now that I think about it, all you really need for a script like this is > the Bug #. From there, you could just parse the comments for the SPEC > file url, then parse the spec for the package name and summary. Good idea, but I think we've left the realm of "simple" with this one :) Plus there's no guarantee the cc list on the review bug will be the same as the ongoing cc list; and the person executing this ought to be the packager -- who will hopefully either have it installed already or a rpm somewhere on their system. This is just aimed at being an extremely limited, one-function tool, to do the initial add to owners.list. For anything more, Steve's owners-maint is much more appropriate. -Chris -- Chris Weyl Ex astris, scientia From Matt_Domsch at dell.com Wed Jul 19 17:05:15 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 19 Jul 2006 12:05:15 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-07-18 In-Reply-To: References: <20060718122052.GC26349@lists.us.dell.com> Message-ID: <20060719170515.GA21497@lists.us.dell.com> On Wed, Jul 19, 2006 at 01:12:15PM +0200, Zoltan Kota wrote: > Type "help", "copyright", "credits" or "license" for more information. > >>> import gnomevfs > Traceback (most recent call last): > File "", line 1, in ? > ImportError: /usr/lib/python2.4/site-packages/gtk-2.0/gnomevfs.so: > undefined symbol: gnome_vfs_mime_get_all_components > > gnome-python2-gnomevfs is there. Do you have any idea what the problem is? > What should I look for? What is the difference between the > "buildsys.fedoraproject" and "buildsys.linux.dell" so that happens? buildsys.fedoraproject isn't yet using the reduced package set in the chroot; buildsys.linux.dell is. So things will succeed on the live site that will fail on mine, but mine is just a predictor of failures that will start soon... That said, there does appear to be a bug in gnomevfs that will affect a number of builds. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From michael at knox.net.nz Wed Jul 19 20:12:09 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 20 Jul 2006 08:12:09 +1200 Subject: package submission take over question. Message-ID: <44BE9219.7090308@knox.net.nz> Hey all. I started the review of a package, but sadly the submitter seems to have vanished. Nearly 3 months has passed and I have decided that I will submit this package instead. Now... best practice question. Should I close the review and open a new one? or Should I remove myself as the assignee and place the package back in FE-NEW with a post stating I am the new submitter? Which would people prefer or is there another way it could be handled? Thanks! Michael From rdieter at math.unl.edu Wed Jul 19 22:26:38 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 19 Jul 2006 17:26:38 -0500 Subject: package submission take over question. In-Reply-To: <44BE9219.7090308@knox.net.nz> References: <44BE9219.7090308@knox.net.nz> Message-ID: Michael J. Knox wrote: > Hey all. > > I started the review of a package, but sadly the submitter seems to have > vanished. Nearly 3 months has passed and I have decided that I will > submit this package instead. > > Now... best practice question. > > Should I close the review and open a new one? IMO, bingo. -- Rex From toshio at tiki-lounge.com Thu Jul 20 00:50:07 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 19 Jul 2006 17:50:07 -0700 Subject: package submission take over question. In-Reply-To: References: <44BE9219.7090308@knox.net.nz> Message-ID: <1153356608.3015.9.camel@localhost> On Wed, 2006-07-19 at 17:26 -0500, Rex Dieter wrote: > Michael J. Knox wrote: > > Hey all. > > > > I started the review of a package, but sadly the submitter seems to have > > vanished. Nearly 3 months has passed and I have decided that I will > > submit this package instead. > > > > Now... best practice question. > > > > Should I close the review and open a new one? > > IMO, bingo. I agree with this option unless there a lot of controversial changes in the package. If that's the case it might be better to reassign the old bug so the new reviewer can easily see why things are the way they are. -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 sundaram at fedoraproject.org Thu Jul 20 01:05:26 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 20 Jul 2006 06:35:26 +0530 Subject: Slab menu panel applet Message-ID: <44BED6D6.2050404@fedoraproject.org> Hi https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197907 If anyone wants to take a look at packaging this applet in Fedora Extras, that would be great. It might require relatively minor modifications to fit into Fedora better. Rahul From michael at knox.net.nz Thu Jul 20 01:27:32 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 20 Jul 2006 13:27:32 +1200 Subject: package submission take over question. In-Reply-To: <1153356608.3015.9.camel@localhost> References: <44BE9219.7090308@knox.net.nz> <1153356608.3015.9.camel@localhost> Message-ID: <44BEDC04.6020305@knox.net.nz> Toshio Kuratomi wrote: > On Wed, 2006-07-19 at 17:26 -0500, Rex Dieter wrote: > >>Michael J. Knox wrote: >> >>>Hey all. >>> >>>I started the review of a package, but sadly the submitter seems to have >>>vanished. Nearly 3 months has passed and I have decided that I will >>>submit this package instead. >>> >>>Now... best practice question. >>> >>>Should I close the review and open a new one? >> >>IMO, bingo. > > > I agree with this option unless there a lot of controversial changes in > the package. If that's the case it might be better to reassign the old > bug so the new reviewer can easily see why things are the way they are. > Sounds good. I will proceed with option one :) Thanks for your input Rex and Toshio. Michael From michael at knox.net.nz Thu Jul 20 01:45:05 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 20 Jul 2006 13:45:05 +1200 Subject: FE Package Status of Jul 20, 2006 Message-ID: <44BEE021.9080605@knox.net.nz> Hello all, New report. A big "Holy Crap!" to Jason Tibbitts for hitting 200 reviews! Well done. Keep up all the hard work everyone! Michael FE Package Status of Jul 20, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 2000 packages - 38 orphans - 32 packages not available in extras devel or release Fedora at FamilleCollet dot com php-pecl-zip Fedora at FamilleCollet dot com php-pear-HTTP cgoorah at yahoo dot com dot au kadischi davidhart at tqmcube dot com leafnode fredrik at dolda2000 dot com icmpdn ghenry at suretecsystems dot com gnome-applet-netmon green at redhat dot com mxml ivazquez at ivazquez dot net gpredict j dot w dot r dot degoede at hhs dot nl gkrellm-wifi jpo at di dot uminho dot pt perl-Test-Builder-Tester jvdias at redhat dot com webmin lmacken at redhat dot com python-paste lmacken at redhat dot com python-configobj matthias at rpmforge dot net fillets-ng-data-cs matthias at rpmforge dot net php-mmcache nicolas dot mailhot at laposte dot net zoo nomis80 at nomis80 dot org juk notting at redhat dot com aqhbci-qt-tools notting at redhat dot com comps oliver at linux-kernel dot at squidGuard rcritten at redhat dot com mod_nss seg at haxxed dot com rosegarden4 tcallawa at redhat dot com R-RScaLAPACK tcallawa at redhat dot com libgdamm tcallawa at redhat dot com R-hdf5 tcallawa at redhat dot com opendap toniw at iki dot fi silky toniw at iki dot fi libmatchbox toshio at tiki-lounge dot com hula wart at kobold dot org eris wolters dot liste at gmx dot net ktorrent wtogami at redhat dot com iiimf-le-simplehangul - 5 packages not available in extras devel but present in release andreas at bawue dot net echoping andreas at bawue dot net mboxgrep dakingun at gmail dot com baobab ivazquez at ivazquez dot net gnome-applet-rhythmbox noa at resare dot com vorbisgain - 2 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=187818,189375 ktorrent wolters.liste at gmx.net Maelstrom notting at redhat.com - 1 packages present in the development repo which have no owners entry perl-SVK - 2 orphaned packages, yet available in extras devel gtkglarea2 soundtracker - 43 packages that moved to core Packages appearing both in Core and Extras: - 5 packages duplicated for devel: jpo at di dot uminho dot pt perl-Net-SSLeay jpo at di dot uminho dot pt perl-IO-Socket-SSL jpo at di dot uminho dot pt perl-Socket6 petersen at redhat dot com scim-bridge tagoh at redhat dot com paps FE-ACCEPT packages stats: - 1056 accepted, closed package reviews - 7 accepted, closed package reviews not in repo - 2 accepted, closed package reviews not in owners - 10 accepted, open package reviews older than 4 weeks; - 8 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 103 open tickets - 23 tickets with no activity in eight weeks - 22 tickets with no activity in four weeks - 2 closed tickets FE-NEW packages stats: - 196 open tickets - 31 tickets with no activity in eight weeks - 39 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 40 open tickets - 7 tickets with no activity in eight weeks - 5 tickets with no activity in four weeks FE-LEGAL packages stats: - 2 open tickets OPEN-BUGS packages stats: - 246 open tickets - 148 tickets with no activity in eight weeks - 19 tickets with no activity in four weeks CVS stats: - 2007 packages with a devel directory - 26 packages with no owners entry gpasman grandr_applet gsview initng k3b-ape kernel-module-thinkpad libexif muse nethack-falconseye perl-Convert-ASN1 perl-DateManip perl-GD-SVG perl-Graph perl-Heap perl-Maypole perl-RPM-Specfile perl-SVG perl-SVK perl-Text-Shellwords perl-XML-LibXML-Common perl-XML-NamespaceSupport perl-XML-SAX perl-XML-Writer perl-bioperl php-apc python-ldap - 4 packages in CVS devel *and* Core gkrellm libevent pam_pkcs11 paps - 87 packages were dropped from extras Maintainers stats: - 210 maintainers - 20 inactive maintainers with open bugs - 25 inactive maintainers Dropped FC packages: - 268 packages were dropped from core since FC 1 From dennis at ausil.us Thu Jul 20 01:54:14 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 19 Jul 2006 20:54:14 -0500 Subject: FE Package Status of Jul 20, 2006 In-Reply-To: <44BEE021.9080605@knox.net.nz> References: <44BEE021.9080605@knox.net.nz> Message-ID: <200607192054.15000.dennis@ausil.us> On Wednesday 19 July 2006 8:45 pm, Michael J. Knox wrote: > jvdias at redhat dot com webmin webmin has never been approved https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184080 > - 2 packages which have not yet been FE-APPROVE'd... > https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=187818,189375 > ktorrent wolters.liste at gmx.net > Maelstrom notting at redhat.com > - 1 packages present in the development repo which have no owners entry > perl-SVK > - 2 orphaned packages, yet available in extras devel > gtkglarea2 soundtracker > - 43 packages that moved to core -- Dennis Gilmore, RHCE Proud Australian From michael at knox.net.nz Thu Jul 20 01:59:36 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 20 Jul 2006 13:59:36 +1200 Subject: FE Package Status of Jul 20, 2006 In-Reply-To: <200607192054.15000.dennis@ausil.us> References: <44BEE021.9080605@knox.net.nz> <200607192054.15000.dennis@ausil.us> Message-ID: <44BEE388.7020602@knox.net.nz> Dennis Gilmore wrote: > On Wednesday 19 July 2006 8:45 pm, Michael J. Knox wrote: > > >> jvdias at redhat dot com webmin > > webmin has never been approved > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184080 > The report doesn't say that it was approved. Its only reporting that its found in the owners list and nowhere else. The BZ report is closed, so I will remove it form the owners list. Michael From paul at city-fan.org Thu Jul 20 07:14:22 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 20 Jul 2006 08:14:22 +0100 Subject: package submission take over question. In-Reply-To: References: <44BE9219.7090308@knox.net.nz> Message-ID: <1153379662.18480.1.camel@laurel.intra.city-fan.org> On Wed, 2006-07-19 at 17:26 -0500, Rex Dieter wrote: > Michael J. Knox wrote: > > Hey all. > > > > I started the review of a package, but sadly the submitter seems to have > > vanished. Nearly 3 months has passed and I have decided that I will > > submit this package instead. > > > > Now... best practice question. > > > > Should I close the review and open a new one? > > IMO, bingo. That's what I did with milter-regex when the same situation happened there: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173522 Paul. From j.w.r.degoede at hhs.nl Thu Jul 20 08:10:01 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 20 Jul 2006 10:10:01 +0200 Subject: package submission take over question. In-Reply-To: <1153379662.18480.1.camel@laurel.intra.city-fan.org> References: <44BE9219.7090308@knox.net.nz> <1153379662.18480.1.camel@laurel.intra.city-fan.org> Message-ID: <44BF3A59.9050400@hhs.nl> Paul Howarth wrote: > On Wed, 2006-07-19 at 17:26 -0500, Rex Dieter wrote: >> Michael J. Knox wrote: >>> Hey all. >>> >>> I started the review of a package, but sadly the submitter seems to have >>> vanished. Nearly 3 months has passed and I have decided that I will >>> submit this package instead. >>> >>> Now... best practice question. >>> >>> Should I close the review and open a new one? >> IMO, bingo. > > That's what I did with milter-regex when the same situation happened > there: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173522 > > Paul. > I've had (as reviewer) a similar issue and solved it by just recycling the review ticket with the new submitter. I believe closing it and opening a new one is better though. We should document this somewhere, as it seems this happens more then once. Regards, hans From michael at knox.net.nz Fri Jul 21 08:09:19 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 21 Jul 2006 20:09:19 +1200 Subject: package submission take over question. In-Reply-To: <44BF3A59.9050400@hhs.nl> References: <44BE9219.7090308@knox.net.nz> <1153379662.18480.1.camel@laurel.intra.city-fan.org> <44BF3A59.9050400@hhs.nl> Message-ID: <44C08BAF.90207@knox.net.nz> Hans de Goede wrote: > > Paul Howarth wrote: >> On Wed, 2006-07-19 at 17:26 -0500, Rex Dieter wrote: >>> Michael J. Knox wrote: >>>> Hey all. >>>> >>>> I started the review of a package, but sadly the submitter seems to have >>>> vanished. Nearly 3 months has passed and I have decided that I will >>>> submit this package instead. >>>> >>>> Now... best practice question. >>>> >>>> Should I close the review and open a new one? >>> IMO, bingo. >> That's what I did with milter-regex when the same situation happened >> there: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173522 >> >> Paul. >> > > I've had (as reviewer) a similar issue and solved it by just recycling > the review ticket with the new submitter. I believe closing it and > opening a new one is better though. > > We should document this somewhere, as it seems this happens more then once. > I agree.. some addition to the AWOL/MIA policy perhaps? Michael From paul at city-fan.org Thu Jul 20 08:10:14 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 20 Jul 2006 09:10:14 +0100 Subject: package submission take over question. In-Reply-To: <44BF3A59.9050400@hhs.nl> References: <44BE9219.7090308@knox.net.nz> <1153379662.18480.1.camel@laurel.intra.city-fan.org> <44BF3A59.9050400@hhs.nl> Message-ID: <1153383015.18480.10.camel@laurel.intra.city-fan.org> On Thu, 2006-07-20 at 10:10 +0200, Hans de Goede wrote: > > Paul Howarth wrote: > > On Wed, 2006-07-19 at 17:26 -0500, Rex Dieter wrote: > >> Michael J. Knox wrote: > >>> Hey all. > >>> > >>> I started the review of a package, but sadly the submitter seems to have > >>> vanished. Nearly 3 months has passed and I have decided that I will > >>> submit this package instead. > >>> > >>> Now... best practice question. > >>> > >>> Should I close the review and open a new one? > >> IMO, bingo. > > > > That's what I did with milter-regex when the same situation happened > > there: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173522 > > > > Paul. > > > > I've had (as reviewer) a similar issue and solved it by just recycling > the review ticket with the new submitter. I believe closing it and > opening a new one is better though. Particularly in cases like these where the new submitter is the old reviewer, who is no longer eligible to review the package. > We should document this somewhere, as it seems this happens more then once. That would be good, yes. One for the packaging committee. Paul. From laurent.rineau__fedora_extras at normalesup.org Thu Jul 20 10:10:33 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Thu, 20 Jul 2006 12:10:33 +0200 Subject: FE Package Status of Jul 20, 2006 In-Reply-To: <44BEE021.9080605@knox.net.nz> References: <44BEE021.9080605@knox.net.nz> Message-ID: <200607201210.33305@rineau.schtroumpfette> On Thursday 20 July 2006 03:45, Michael J. Knox wrote: > FE Package Status of Jul 20, 2006 > > The full report can be found here: > http://fedoraproject.org/wiki/Extras/PackageStatus The page at the URL quoted above mentions me twice: ===================QUOTE================== *Potential problems* We have 7 accepted, closed packages where I'm unable to find the package in the development repo: [snip lines] laurent dot rineaufedora_extras at normalesup dot org The [WWW] 191208 Review Request: The Ipe extensible drawing editor ==============END==QUOTE================== and: ===================QUOTE================== We have 2 accepted, closed packages where I'm unable to find the package in the owners file: [snip 1?line] laurent dot rineaufedora_extras at normalesup dot org The [WWW] 191208 Review Request: The Ipe extensible drawing editor ==============END==QUOTE================== Well, ipe aka "The ipe extensible drawing editor", is in FC-4, FC-5 and devel, and does have an entry in the owners file. Do I have to do something?! From buildsys at fedoraproject.org Thu Jul 20 12:04:36 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 20 Jul 2006 08:04:36 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-20 Message-ID: <20060720120436.34C8C152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 10 amarok-1.4.1-3.fc5 driftnet-0.1.6-9.fc5.3 gnofract4d-2.14-3.fc5 mxml-2.2.2-4.fc5 perl-File-Flat-0.96-2.fc5 perl-POE-Filter-IRCD-1.7-1.fc5 perl-Text-Glob-0.07-1.fc5 rosegarden4-1.2.3-3.fc5 sextractor-2.5.0-1.fc5 xpa-2.1.6-5.fc5 Packages built and released for Fedora Extras 4: 6 gnofract4d-2.14-3.fc4 perl-File-Flat-0.96-2.fc4 perl-POE-Filter-IRCD-1.7-1.fc4 perl-Text-Glob-0.07-1.fc4 sextractor-2.5.0-1.fc4 xpa-2.1.6-5.fc4 Packages built and released for Fedora Extras 3: 2 perl-File-Flat-0.96-2.fc3 perl-Text-Glob-0.07-1.fc3 Packages built and released for Fedora Extras development: 15 amarok-1.4.1-3.fc6 gkrellm-2.2.9-7.fc6 gkrellm-wifi-0.9.12-2.fc6 gnofract4d-2.14-3.fc6 kawa-1.8-6.fc6 mxml-2.2.2-4.fc6 nant-0.85-6.fc6 perl-File-Flat-0.96-2.fc6 perl-Text-Glob-0.07-1.fc6 python-configobj-4.3.2-2.fc6 python-paste-0.9.3-4.fc6 rosegarden4-1.2.3-3.fc6 sextractor-2.5.0-1.fc6 subversion-api-docs-1.3.2-1.fc6 xpa-2.1.6-5.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Jul 20 12:05:00 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 20 Jul 2006 08:05:00 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-20 Message-ID: <20060720120500.E23C6152160@buildsys.fedoraproject.org> abiword: 5: 1:2.4.5-2.fc5 (FE5) 6: 1:2.4.5-1.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) ecl: 4: 0:0.9i-1.1.fc4 (FE4) 5: 0:0.9i-1.fc5 (FE5) 6: 0:0.9i-1.fc6 (FE6) eclipse-changelog: 5: 1:2.1.0_fc-2 (FC5-updates) 6: 1:2.1.0_fc-1 (FC6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2.1 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-13.fc6 (FC6) monotone: 5: 0:0.27-1.fc5 (FE5) 6: 0:0.26-2.fc6 (FE6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) qt4: 5: 0:4.1.4-6.fc5 (FE5) 6: 0:4.1.4-5.fc6 (FE6) rsnapshot: 4: 0:1.2.9-4.fc4 (FE4) 5: 0:1.2.9-2.fc5 (FE5) 6: 0:1.2.9-2.fc6 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) system-config-bind: 5: 0:4.0.0-42_FC5 (FC5-updates) 6: 0:4.0.0-41_FC6 (FC6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) wordpress: 4: 0:2.0.3-4.fc4 (FE4) 5: 0:2.0.3-3.fc5 (FE5) 6: 0:2.0.3-3.fc6 (FE6) From Christian.Iseli at licr.org Thu Jul 20 12:15:48 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 20 Jul 2006 14:15:48 +0200 Subject: FE Package Status of Jul 20, 2006 In-Reply-To: Your message of "Thu, 20 Jul 2006 12:10:33 +0200." <200607201210.33305@rineau.schtroumpfette> Message-ID: <200607201215.k6KCFm1e030430@ludwig-alpha.unil.ch> Hi Laurent, laurent.rineau__fedora_extras at normalesup.org said: > Well, ipe aka "The ipe extensible drawing editor", is in FC-4, FC-5 and > devel, and does have an entry in the owners file. > Do I have to do something?! The script that generates this page is not too smart: it expects the Summary of the BZ ticket to be written like: "Review Request: " It got confused when parsing your review ticket, and thought "The" was the name of the package. I have slightly modified the Summary now, and the script should be quiet next time it is run... Cheers, Christian From buildsys at fedoraproject.org Thu Jul 20 12:26:13 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 20 Jul 2006 12:26:13 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-20 Message-ID: <20060720122613.21720.7379@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 (105 days) fluxbox - 0.9.15.1-1.fc3.x86_64 (105 days) Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Thu Jul 20 12:26:13 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 20 Jul 2006 12:26:13 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-20 Message-ID: <20060720122613.21732.62358@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 (5 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc (5 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 (5 days) mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (64 days) syck-php - 0.55-7.fc5.ppc (64 days) syck-php - 0.55-7.fc5.x86_64 (64 days) Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.i386 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.ppc requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc5.x86_64 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From buildsys at fedoraproject.org Thu Jul 20 12:26:13 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 20 Jul 2006 12:26:13 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-20 Message-ID: <20060720122613.21729.66089@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 (23 days) wp_tray - 0.5.1-1.fc4.ppc (23 days) wp_tray - 0.5.1-1.fc4.x86_64 (23 days) lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 (5 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc (5 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 (5 days) Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.ppc requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.x86_64 requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) From buildsys at fedoraproject.org Thu Jul 20 12:26:13 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 20 Jul 2006 12:26:13 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-20 Message-ID: <20060720122613.21734.41934@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- bdpepple AT ameritech.net galago-daemon - 0.5.0-3.fc6.i386 galago-daemon - 0.5.0-3.fc6.ppc galago-daemon - 0.5.0-3.fc6.x86_64 gossip - 0.11.2-3.fc6.i386 gossip - 0.11.2-3.fc6.ppc gossip - 0.11.2-3.fc6.x86_64 libgalago - 0.5.1-4.fc6.i386 libgalago - 0.5.1-4.fc6.ppc libgalago - 0.5.1-4.fc6.x86_64 liferea - 1.0.16-3.fc6.i386 liferea - 1.0.16-3.fc6.ppc liferea - 1.0.16-3.fc6.x86_64 xchat-gnome - 0.12-2.fc6.i386 xchat-gnome - 0.12-2.fc6.ppc xchat-gnome - 0.12-2.fc6.x86_64 byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 gaim-guifications - 2.12-3.fc5.ppc gaim-guifications - 2.12-3.fc5.x86_64 caillon AT redhat.com banshee - 0.10.8-1.i386 banshee - 0.10.8-1.ppc banshee - 0.10.8-1.x86_64 libipoddevice - 0.4.5-1.fc6.i386 libipoddevice - 0.4.5-1.fc6.ppc libipoddevice - 0.4.5-1.fc6.x86_64 cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 gaim-gaym - 0.96-2.fc6.ppc gaim-gaym - 0.96-2.fc6.x86_64 davidz AT redhat.com NetworkManager-vpnc - 0.7.0-0.cvs20060529.fc6.i386 NetworkManager-vpnc - 0.7.0-0.cvs20060529.fc6.ppc NetworkManager-vpnc - 0.7.0-0.cvs20060529.fc6.x86_64 dennis AT ausil.us knetworkmanager - 0.1-0.3.svn20060625.fc6.i386 knetworkmanager - 0.1-0.3.svn20060625.fc6.ppc knetworkmanager - 0.1-0.3.svn20060625.fc6.x86_64 fedora AT leemhuis.info gsynaptics - 0.9.8-1.fc6.ppc foolish AT guezz.net muine - 0.8.5-1.fc6.i386 muine - 0.8.5-1.fc6.ppc muine - 0.8.5-1.fc6.x86_64 ivazquez AT ivazquez.net gnome-applet-music - 0.9.0-1.fc6.i386 gnome-applet-music - 0.9.0-1.fc6.ppc gnome-applet-music - 0.9.0-1.fc6.x86_64 nautilus-search-tool - 0.2-1.fc5.i386 nautilus-search-tool - 0.2-1.fc5.ppc nautilus-search-tool - 0.2-1.fc5.x86_64 jima AT beer.tclug.org dnsmasq - 2.32-1.fc6.i386 dnsmasq - 2.32-1.fc6.ppc dnsmasq - 2.32-1.fc6.x86_64 matt AT truch.net gpsd - 2.32-5.fc6.i386 gpsd - 2.32-5.fc6.ppc gpsd - 2.32-5.fc6.x86_64 gpsd-clients - 2.32-5.fc6.i386 gpsd-clients - 2.32-5.fc6.ppc gpsd-clients - 2.32-5.fc6.x86_64 matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 diradmin - 1.7.1-4.fc5.ppc diradmin - 1.7.1-4.fc5.x86_64 gtktalog - 1.0.4-7.fc5.i386 gtktalog - 1.0.4-7.fc5.ppc gtktalog - 1.0.4-7.fc5.x86_64 michael AT knox.net.nz screem - 0.16.1-1.fc6.i386 screem - 0.16.1-1.fc6.ppc screem - 0.16.1-1.fc6.x86_64 mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 gfontview - 0.5.0-5.fc5.ppc gfontview - 0.5.0-5.fc5.x86_64 gtkhtml36 - 3.6.2-5.fc6.i386 gtkhtml36 - 3.6.2-5.fc6.ppc gtkhtml36 - 3.6.2-5.fc6.x86_64 libvisual-plugins - 0.2.0-3.fc5.i386 libvisual-plugins - 0.2.0-3.fc5.ppc libvisual-plugins - 0.2.0-3.fc5.x86_64 nalin AT redhat.com oddjob - 0.26-4.i386 oddjob - 0.26-4.ppc oddjob - 0.26-4.x86_64 oddjob-libs - 0.26-4.i386 oddjob-libs - 0.26-4.ppc oddjob-libs - 0.26-4.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 syck-php - 0.55-7.fc5.ppc syck-php - 0.55-7.fc5.x86_64 pertusus AT free.fr cernlib - 2005-21.fc6.ppc cernlib-packlib - 2005-21.fc6.ppc patchy - 2005-21.fc6.ppc paw - 2005-21.fc6.ppc rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 libibverbs - 1.0.3-1.fc6.ppc libibverbs - 1.0.3-1.fc6.x86_64 libibverbs-utils - 1.0.3-1.fc6.i386 libibverbs-utils - 1.0.3-1.fc6.ppc libibverbs-utils - 1.0.3-1.fc6.x86_64 thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 directfb - 0.9.24-5.fc5.ppc directfb - 0.9.24-5.fc5.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- NetworkManager-vpnc-0.7.0-0.cvs20060529.fc6.i386 requires libdbus-1.so.2 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 banshee-0.10.8-1.i386 requires mono(dbus-sharp) = 0:0.60.0.0 banshee-0.10.8-1.i386 requires libdbus-1.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 dnsmasq-2.32-1.fc6.i386 requires libdbus-1.so.2 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 galago-daemon-0.5.0-3.fc6.i386 requires libdbus-1.so.2 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.i386 requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.i386 requires libdbus-1.so.2 gossip-0.11.2-3.fc6.i386 requires libdbus-1.so.2 gpsd-2.32-5.fc6.i386 requires libdbus-1.so.2 gpsd-clients-2.32-5.fc6.i386 requires libdbus-1.so.2 gtkhtml36-3.6.2-5.fc6.i386 requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-qt-1.so.1 libgalago-0.5.1-4.fc6.i386 requires libdbus-1.so.2 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.i386 requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 liferea-1.0.16-3.fc6.i386 requires libdbus-1.so.2 muine-0.8.5-1.fc6.i386 requires mono(dbus-sharp) = 0:0.60.0.0 muine-0.8.5-1.fc6.i386 requires dbus-sharp >= 0:0.50 nautilus-search-tool-0.2-1.fc5.i386 requires libgailutil.so.17 oddjob-0.26-4.i386 requires libdbus-1.so.2 oddjob-libs-0.26-4.i386 requires libdbus-1.so.2 screem-0.16.1-1.fc6.i386 requires libdbus-1.so.2 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 xchat-gnome-0.12-2.fc6.i386 requires libdbus-1.so.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- NetworkManager-vpnc-0.7.0-0.cvs20060529.fc6.ppc requires libdbus-1.so.2 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 banshee-0.10.8-1.ppc requires mono(dbus-sharp) = 0:0.60.0.0 banshee-0.10.8-1.ppc requires libdbus-1.so.2 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 dnsmasq-2.32-1.fc6.ppc requires libdbus-1.so.2 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 galago-daemon-0.5.0-3.fc6.ppc requires libdbus-1.so.2 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.ppc requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.ppc requires libdbus-1.so.2 gossip-0.11.2-3.fc6.ppc requires libdbus-1.so.2 gpsd-2.32-5.fc6.ppc requires libdbus-1.so.2 gpsd-clients-2.32-5.fc6.ppc requires libdbus-1.so.2 gsynaptics-0.9.8-1.fc6.ppc requires synaptics gtkhtml36-3.6.2-5.fc6.ppc requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-qt-1.so.1 libgalago-0.5.1-4.fc6.ppc requires libdbus-1.so.2 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.ppc requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 liferea-1.0.16-3.fc6.ppc requires libdbus-1.so.2 muine-0.8.5-1.fc6.ppc requires mono(dbus-sharp) = 0:0.60.0.0 muine-0.8.5-1.fc6.ppc requires dbus-sharp >= 0:0.50 nautilus-search-tool-0.2-1.fc5.ppc requires libgailutil.so.17 oddjob-0.26-4.ppc requires libdbus-1.so.2 oddjob-libs-0.26-4.ppc requires libdbus-1.so.2 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 screem-0.16.1-1.fc6.ppc requires libdbus-1.so.2 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 xchat-gnome-0.12-2.fc6.ppc requires libdbus-1.so.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- NetworkManager-vpnc-0.7.0-0.cvs20060529.fc6.x86_64 requires libdbus-1.so.2()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) banshee-0.10.8-1.x86_64 requires mono(dbus-sharp) = 0:0.60.0.0 banshee-0.10.8-1.x86_64 requires libdbus-1.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) dnsmasq-2.32-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 galago-daemon-0.5.0-3.fc6.x86_64 requires libdbus-1.so.2()(64bit) gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libgailutil.so.17()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) gossip-0.11.2-3.fc6.x86_64 requires libdbus-1.so.2()(64bit) gpsd-2.32-5.fc6.x86_64 requires libdbus-1.so.2()(64bit) gpsd-clients-2.32-5.fc6.x86_64 requires libdbus-1.so.2()(64bit) gtkhtml36-3.6.2-5.fc6.x86_64 requires libgailutil.so.17()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-qt-1.so.1()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-1.so.2()(64bit) libgalago-0.5.1-4.fc6.x86_64 requires libdbus-1.so.2()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libipoddevice-0.4.5-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) liferea-1.0.16-3.fc6.x86_64 requires libdbus-1.so.2()(64bit) muine-0.8.5-1.fc6.x86_64 requires mono(dbus-sharp) = 0:0.60.0.0 muine-0.8.5-1.fc6.x86_64 requires dbus-sharp >= 0:0.50 nautilus-search-tool-0.2-1.fc5.x86_64 requires libgailutil.so.17()(64bit) oddjob-0.26-4.x86_64 requires libdbus-1.so.2()(64bit) oddjob-libs-0.26-4.x86_64 requires libdbus-1.so.2()(64bit) screem-0.16.1-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 xchat-gnome-0.12-2.fc6.x86_64 requires libdbus-1.so.2()(64bit) ====================================================================== New report for: michael AT knox.net.nz package: screem - 0.16.1-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: screem - 0.16.1-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: screem - 0.16.1-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 ====================================================================== New report for: jima AT beer.tclug.org package: dnsmasq - 2.32-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: dnsmasq - 2.32-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: dnsmasq - 2.32-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 ====================================================================== New report for: matt AT truch.net package: gpsd - 2.32-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: gpsd-clients - 2.32-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: gpsd - 2.32-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: gpsd-clients - 2.32-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: gpsd - 2.32-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 package: gpsd-clients - 2.32-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 ====================================================================== New report for: dennis AT ausil.us package: knetworkmanager - 0.1-0.3.svn20060625.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 libdbus-qt-1.so.1 package: knetworkmanager - 0.1-0.3.svn20060625.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-qt-1.so.1()(64bit) libdbus-1.so.2()(64bit) package: knetworkmanager - 0.1-0.3.svn20060625.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 libdbus-qt-1.so.1 ====================================================================== New report for: caillon AT redhat.com package: libipoddevice - 0.4.5-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: libipoddevice - 0.4.5-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: libipoddevice - 0.4.5-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 ====================================================================== New report for: foolish AT guezz.net package: muine - 0.8.5-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: mono(dbus-sharp) = 0:0.60.0.0 dbus-sharp >= 0:0.50 package: muine - 0.8.5-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: mono(dbus-sharp) = 0:0.60.0.0 dbus-sharp >= 0:0.50 package: muine - 0.8.5-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: mono(dbus-sharp) = 0:0.60.0.0 dbus-sharp >= 0:0.50 ====================================================================== New report for: davidz AT redhat.com package: NetworkManager-vpnc - 0.7.0-0.cvs20060529.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: NetworkManager-vpnc - 0.7.0-0.cvs20060529.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: NetworkManager-vpnc - 0.7.0-0.cvs20060529.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 ====================================================================== New report for: nalin AT redhat.com package: oddjob-libs - 0.26-4.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: oddjob - 0.26-4.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: oddjob-libs - 0.26-4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: oddjob - 0.26-4.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: oddjob - 0.26-4.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 package: oddjob-libs - 0.26-4.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 ====================================================================== New report for: bdpepple AT ameritech.net package: galago-daemon - 0.5.0-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: gossip - 0.11.2-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: libgalago - 0.5.1-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: liferea - 1.0.16-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: xchat-gnome - 0.12-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdbus-1.so.2 package: libgalago - 0.5.1-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: gossip - 0.11.2-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: xchat-gnome - 0.12-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: liferea - 1.0.16-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: galago-daemon - 0.5.0-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdbus-1.so.2()(64bit) package: liferea - 1.0.16-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 package: xchat-gnome - 0.12-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 package: galago-daemon - 0.5.0-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 package: libgalago - 0.5.1-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 package: gossip - 0.11.2-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdbus-1.so.2 From Jochen at herr-schmitt.de Thu Jul 20 16:39:42 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 20 Jul 2006 18:39:42 +0200 Subject: Sugg: Expiring of failed build on the buildsystem Message-ID: <20060720163942.GA31691@myhome> Hello, I have got a look on the jobs assigned to me on the buildsys. So I have found a failed job submitted on October of the last year. I think it make no sense to keep a job longer then 2 or 3 month even if it was failed. So I want to suggest, that all jobs older than three month should be deleted. Best Regards: Jochen Schmitt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From s.mako at gmx.net Fri Jul 21 07:33:01 2006 From: s.mako at gmx.net (Zoltan Kota) Date: Fri, 21 Jul 2006 09:33:01 +0200 (CEST) Subject: FE devel rebuild? Message-ID: Hi, I will be completely without internet access in the next two weeks. When can we expect to start and finish rebuilding FE packages for FC6? Is it still enough after Aug 6? Or someone else should make a build request in these two weeks for my packages? Zoltan From gauret at free.fr Fri Jul 21 12:21:49 2006 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 21 Jul 2006 14:21:49 +0200 Subject: Renaming in CVS Message-ID: Hey, One of my packages was renamed upstream. There's a section here: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-581c3fb3ff1c6ef7404e8b288b59cd5280d75ad6 explaining what to do in the spec file, but how should it be dealt with in CVS ? Do I require a manual rename on http://fedoraproject.org/wiki/Extras/CVSSyncNeeded ? Should I create a new srpm and cvs-import.sh it ? Thanks Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr A: Because we read from top to bottom, left to right. Q: Why should i start my reply below the quoted text ? From rdieter at math.unl.edu Fri Jul 21 13:27:01 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 21 Jul 2006 08:27:01 -0500 Subject: Renaming in CVS References: Message-ID: Aurelien Bompard wrote: > Hey, > > One of my packages was renamed upstream. There's a section here: > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-581c3fb3ff1c6ef7404e8b288b59cd5280d75ad6 > explaining what to do in the spec file, but how should it be dealt with in > CVS ? > Do I require a manual rename on > http://fedoraproject.org/wiki/Extras/CVSSyncNeeded ? > Should I create a new srpm and cvs-import.sh it ? That's what I did when kimdaba was renamed to kphotoalbum. Make sure to mark the old package deprecated by adding a dead.package file in cvs. -- Rex From tibbs at math.uh.edu Fri Jul 21 16:04:27 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 21 Jul 2006 11:04:27 -0500 Subject: rpms/nas/FC-4 nas.spec,1.4,1.5 In-Reply-To: <200607211524.k6LFOPUM016792@cvs-int.fedora.redhat.com> (Frank =?iso-8859-1?q?B=FCttner's?= message of "Fri, 21 Jul 2006 08:24:23 -0700") References: <200607211524.k6LFOPUM016792@cvs-int.fedora.redhat.com> Message-ID: >>>>> "FB" == Frank B?ttner <(frankb) > writes: FB> %changelog FB> * Fri Jul 21 2006 Frank B?ttner - 1.8-7%{?dist} FB> - disable build for EMT64 on FC4 Hmm, %{?dist} shouldn't end up in changelog entries. I wonder if some tool is generating this. I know that the Emacs spec mode can be confused by the dist tag, but I've not seen it include it verbatim. - J< From rdieter at math.unl.edu Fri Jul 21 16:38:04 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 21 Jul 2006 11:38:04 -0500 Subject: rpms/nas/devel nas.spec,1.2,1.3 References: <200607211544.k6LFiY3k017039@cvs-int.fedora.redhat.com> Message-ID: Frank B?ttner (frankb) wrote: > Author: frankb > > Update of /cvs/extras/rpms/nas/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv17002/devel > > Modified Files: > nas.spec > Log Message: > disable build for EMT64 on FC4 Frank, Don't forget to open a bugzilla documenting the failed x86_64 build. -- Rex From fedora at leemhuis.info Fri Jul 21 18:26:08 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 21 Jul 2006 20:26:08 +0200 Subject: FE devel rebuild? In-Reply-To: References: Message-ID: <44C11C40.6060807@leemhuis.info> Zoltan Kota schrieb: > I will be completely without internet access in the next two weeks. > When can we expect to start and finish rebuilding FE packages for FC6? Is > it still enough after Aug 6? Or someone else should make a build request > in these two weeks for my packages? The current plan is to start rebuilding around FC6T3 -- that would mean end of August. Maybe we can start a bit earlier, but definitely not before Aug 6 ;-) CU thl From j.w.r.degoede at hhs.nl Fri Jul 21 18:31:57 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 21 Jul 2006 20:31:57 +0200 Subject: FE devel rebuild? In-Reply-To: <44C11C40.6060807@leemhuis.info> References: <44C11C40.6060807@leemhuis.info> Message-ID: <44C11D9D.4010105@hhs.nl> Thorsten Leemhuis wrote: > > Zoltan Kota schrieb: >> I will be completely without internet access in the next two weeks. >> When can we expect to start and finish rebuilding FE packages for FC6? Is >> it still enough after Aug 6? Or someone else should make a build request >> in these two weeks for my packages? > > The current plan is to start rebuilding around FC6T3 -- that would mean > end of August. Maybe we can start a bit earlier, but definitely not > before Aug 6 ;-) > > CU > thl > Talking about rebuilding, I currently own around 50 packages and I'm not looking forward to having to rebuild these all by hand has anyone got a script I can run in a dir with all the cvs-checkouts of my packages which bumps the releases of all of them, adds a changelog entry, commits tags and builds? Regards, Hans From fedora at leemhuis.info Fri Jul 21 18:40:18 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 21 Jul 2006 20:40:18 +0200 Subject: Renaming in CVS In-Reply-To: References: Message-ID: <44C11F92.2030301@leemhuis.info> Rex Dieter schrieb: > Aurelien Bompard wrote: >> One of my packages was renamed upstream. There's a section here: >> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-581c3fb3ff1c6ef7404e8b288b59cd5280d75ad6 >> explaining what to do in the spec file, but how should it be dealt with in >> CVS ? >> Do I require a manual rename on >> http://fedoraproject.org/wiki/Extras/CVSSyncNeeded ? >> Should I create a new srpm and cvs-import.sh it ? > That's what I did when kimdaba was renamed to kphotoalbum. Make sure to > mark the old package deprecated by adding a dead.package file in cvs. +1 -- Maybe there should be a small note or pointer to the old name in the initial cvs-commit of the new package (or in the changelog in the specfile). But that's not the reason for this mail. Rex or Aurelien, could one of you two add this solution to the wiki somewhere? tia! CU thl From Axel.Thimm at ATrpms.net Fri Jul 21 18:40:12 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 21 Jul 2006 20:40:12 +0200 Subject: FE devel rebuild? In-Reply-To: <44C11D9D.4010105@hhs.nl> References: <44C11C40.6060807@leemhuis.info> <44C11D9D.4010105@hhs.nl> Message-ID: <20060721184012.GD16006@neu.nirvana> On Fri, Jul 21, 2006 at 08:31:57PM +0200, Hans de Goede wrote: > > > Thorsten Leemhuis wrote: > > > > Zoltan Kota schrieb: > >> I will be completely without internet access in the next two weeks. > >> When can we expect to start and finish rebuilding FE packages for FC6? Is > >> it still enough after Aug 6? Or someone else should make a build request > >> in these two weeks for my packages? > > > > The current plan is to start rebuilding around FC6T3 -- that would mean > > end of August. Maybe we can start a bit earlier, but definitely not > > before Aug 6 ;-) > > > > CU > > thl > > > > Talking about rebuilding, I currently own around 50 packages and I'm not > looking forward to having to rebuild these all by hand has anyone got a > script I can run in a dir with all the cvs-checkouts of my packages > which bumps the releases of all of them, adds a changelog entry, commits > tags and builds? Maybe it's a good idea to have the buildsystem do that for all packages? It wouldn't be the last mass rebuild in rawhide ever, so it's something that will come handy later, too. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lmacken at redhat.com Fri Jul 21 18:55:04 2006 From: lmacken at redhat.com (Luke Macken) Date: Fri, 21 Jul 2006 14:55:04 -0400 Subject: Python submodule naming Message-ID: <20060721185504.GA4410@crow.rdu.redhat.com> I'm currently working on getting Paste{,Deploy,Script} though the review process, and Patrice Dumas asks a good naming question in the bug[0]: I don't know if the name should be python-paste-deploy or python-pastedeploy. The guidelines don't cover the case of python submodules. If it is "This makes a package name format of python-$NAME" it seems to be python-pastedeploy, but if one follow "use the name of the module that you type to import it in a script" it should be python-paste-deploy. The second naming convention is also consistent with perl modules naming. Anyone have any insight into this ? luke [0]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198288#c2 From fedora at leemhuis.info Fri Jul 21 18:59:26 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 21 Jul 2006 20:59:26 +0200 Subject: FE devel rebuild? In-Reply-To: <20060721184012.GD16006@neu.nirvana> References: <44C11C40.6060807@leemhuis.info> <44C11D9D.4010105@hhs.nl> <20060721184012.GD16006@neu.nirvana> Message-ID: <44C1240E.2070307@leemhuis.info> Axel Thimm schrieb: > On Fri, Jul 21, 2006 at 08:31:57PM +0200, Hans de Goede wrote: >> >> Thorsten Leemhuis wrote: >>> Zoltan Kota schrieb: >>>> I will be completely without internet access in the next two weeks. >>>> When can we expect to start and finish rebuilding FE packages for FC6? Is >>>> it still enough after Aug 6? Or someone else should make a build request >>>> in these two weeks for my packages? >>> The current plan is to start rebuilding around FC6T3 -- that would mean >>> end of August. Maybe we can start a bit earlier, but definitely not >>> before Aug 6 ;-) >> Talking about rebuilding, I currently own around 50 packages and I'm not >> looking forward to having to rebuild these all by hand has anyone got a >> script I can run in a dir with all the cvs-checkouts of my packages >> which bumps the releases of all of them, adds a changelog entry, commits >> tags and builds? > Maybe it's a good idea to have the buildsystem do that for all > packages? I prefer a manual rebuild for two reasons: - A lot of people don't want everything rebuild because it requires a lot of downloads for users -- noarch packages for example don't require a rebuild this time afaik - A (really) nice side effect of a manual rebuild by maintainer: we find orphaned packages and AWOL maintainers this way and clean everything up before FC6 gets shipped But yes, a script like the one Hans asked for might be helpful. f13 probably has one ;-) CU thl From fedora at camperquake.de Fri Jul 21 19:06:25 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 21 Jul 2006 21:06:25 +0200 Subject: FE devel rebuild? In-Reply-To: <44C1240E.2070307@leemhuis.info> References: <44C11C40.6060807@leemhuis.info> <44C11D9D.4010105@hhs.nl> <20060721184012.GD16006@neu.nirvana> <44C1240E.2070307@leemhuis.info> Message-ID: <20060721210625.4ca8a2bb@nausicaa.camperquake.de> Hi. Thorsten Leemhuis wrote: > But yes, a script like the one Hans asked for might be helpful. f13 > probably has one ;-) Another thing possibly needed is a tree of dependencies, so that packages that other packages depend on are rebuild first. -- My Uncle Larry has a saying, "Never play proctologist with an unwilling goose." Okay, so Uncle Larry drinks a bit. -- Yobaval From rc040203 at freenet.de Fri Jul 21 19:09:40 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 21 Jul 2006 21:09:40 +0200 Subject: rpms/sextractor/FC-4 sextractor.spec,1.2,1.3 In-Reply-To: <200607211724.k6LHO3Z8023012@cvs-int.fedora.redhat.com> References: <200607211724.k6LHO3Z8023012@cvs-int.fedora.redhat.com> Message-ID: <1153508980.18981.125.camel@mccallum.corsepiu.local> On Fri, 2006-07-21 at 10:24 -0700, Sergio Pascual wrote: > Author: sergiopr > @@ -17,10 +17,11 @@ > > %prep > %setup -q > -%{__chmod} -x src/fits/fitsconv.c > > %build > -%configure > +%configure CFLAGS="${CFLAGS} -funroll-loops -fomit-frame-pointer -O1 REVERT this change IMMEDIATELY. You are breaking debug infos. Ralf From toshio at tiki-lounge.com Fri Jul 21 19:10:18 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 21 Jul 2006 12:10:18 -0700 Subject: Python submodule naming In-Reply-To: <20060721185504.GA4410@crow.rdu.redhat.com> References: <20060721185504.GA4410@crow.rdu.redhat.com> Message-ID: <1153509018.23589.14.camel@localhost> On Fri, 2006-07-21 at 14:55 -0400, Luke Macken wrote: > I'm currently working on getting Paste{,Deploy,Script} though the review > process, and Patrice Dumas asks a good naming question in the bug[0]: > > I don't know if the name should be python-paste-deploy or > python-pastedeploy. The guidelines don't cover the case of python > submodules. If it is "This makes a package name format of python-$NAME" > it seems to be python-pastedeploy, but if one follow "use the name of the > module that you type to import it in a script" it should be > python-paste-deploy. The second naming convention is also consistent > with perl modules naming. > I'd follow the second line of reasoning: If it's "import paste.deploy" name it "python-paste-deploy". I don't recall this ever being discussed before, though. > > [0]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198288#c2 -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 toshio at tiki-lounge.com Fri Jul 21 19:59:51 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 21 Jul 2006 12:59:51 -0700 Subject: FESCo Meeting Minutes for 2006-07-20 Message-ID: <1153511991.3471.2.camel@localhost> 2006 July, 20 FESCo Meeting =========================== Meeting Summaries are posted on the wiki at: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings Attending --------- * thl (Chair) * bpepple * tibbs * scop * dgilmore * spot * rdieter * abadger1999 * warren Summary ------- * Mass Rebuild will start around FC6T3. - Minimal buildroots will be in place by then. - check-rpaths (warning only) and check-buildroot will be additional checks incorporated into the buildsystem. - dgilmore put in charge of coordinating these changes. * Future Election - deferred for a week. Discussion will start on extras-list. * Ctrl-C problem. Still a problem. OTRS ticket updated and infrastructure people poked. * Encourage Extras Reviews - Starting to have a backlog of bugs blocking FE-NEEDSPONSORS. + Most packagers there appear to only have one package and no reviews. So no one is willing to sponsor until they show more knowledge. + Mentorship is a possible solution, where someone is sponsored with the idea that the mentor will help them learn rather than they know what to do right off the bat. * Comaintainership: thl is preparing an email but it still needs someone to drive it forward. * AWOL Maintainer Policy. Completed and available at http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers * Comps updating. FC6's installer will allow additional repos but needs entries into comps otherwise a package won't be available. - _wart_ volunteered to spearhead writing a cron script to regenerate comps from the comps.xml.in file. - thl will contact c4chris about scripting a report that lists packages not in comps. * IPv6 - deferred jwb on vacation * Packaging Committee Report: - perl module template was updated to indicate which items are not necessary for noarch packages. * Approve KMods - Vote to allow kernel modules are okay to be reviewed for Extras as per the KMod guidelines. - Approve em8300 at https://bugzilla.redhat.com/189400 - Approve iscsitarget, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197867 - Others in Extras: None have a statement as to why it's not in the upstream kernel which is a minimum for voting to approve. * Some discussion of the merits of the kabi standard http://www.kerneldrivers.org but no resolution. Log --- :: (09:06:30) The topic for #fedora-extras is: "This is the Fedora Extras channel, home of the FESCo meetings and general Extras discussion. | http://fedoraproject.org/wiki/Extras | Next FESCo Meeting: 2006-07-20 1700 UTC" (10:00:16) thl has changed the topic to: FESCo meeting in progress (10:00:23) thl: Hi everybody! (10:00:28) bpepple: hey. (10:00:30) thl: Who's around? (10:00:36) tibbs: I'm here. (10:00:37) ***bpepple is around. (10:00:37) ***jima sits back and watches (10:00:51) ***scop is here (10:01:17) ***dgilmore is here (10:01:37) thl: k, then let's start slowly (10:01:43) thl has changed the topic to: FESCo meeting in progress -- (10:01:54) spot: i'm here now. (10:01:58) thl has changed the topic to: FESCo meeting in progress -- M{ae}ss-Rebuild (10:02:07) thl: just FYI (10:02:27) thl: f13 told me taht we should start some time around the release of FC6T3 (10:02:34) ***rdieter is here (10:02:37) thl: that leaved some weeks for dicussions and plaing (10:02:40) thl: planing (10:02:52) dgilmore: thl and we will have the minimal buildroots in place before then i hope (10:02:56) thl: but we should hurry up to get everything sorted out in time (10:03:14) thl: dgilmore, we IMHO must have them in place before then (10:03:24) dgilmore: thl: i think we must (10:03:27) scop: it would be really nice to have check-rpaths and especially check-buildroot deployed in the builders before that (10:03:34) dgilmore: but it looks like we will need to rebuild the builders (10:03:48) rdieter: rebuild as in re-install? (10:03:48) thl: scop, check-buildroot ACK (10:03:58) dgilmore: rdieter: yep (10:04:00) ***abadger1999 shows up (10:04:03) rdieter: fun. (10:04:11) thl: scop, check-rpaths -> not sure (10:04:17) ***cweyl is here (rabble) (10:04:20) thl: scop, it will break a lot of x86_64 packages (10:04:26) dgilmore: the hammers are currently running fc3, ppc1 fc4 ppc2 rhel4 (10:04:34) thl: scop, that will probably a lot of work to fix... (10:04:43) f13: thl: FWIW the gcc changes look pretty good. The C++ visibility stuff is hitting things like KDE though, and code changes are necessary (10:05:03) thl: f13, k, thx (10:05:10) scop: thl, a stopgap could be to have QA_RPATHS=0x0001 set in the environment (10:05:29) scop: so it would be just logged (10:05:36) thl: scop, okay, that might be an idea (10:06:12) thl: who wants to make sure the stuff gets used on the builders? (10:06:19) thl: any volunteers? (10:06:28) thl: or does anyone don't like taht idea? (10:07:04) rdieter: stuff as in the "check-*" stuff? imo, good idea. (10:07:16) thl: rdieter, yes, stuff as in the "check-*" stuff? (10:07:23) ***warren here (10:07:30) scop: is anyone here knowledgeable enough about plague/mock to have a clue what would it take technically? (10:07:32) dgilmore: thl: i can do that. i am going to get things started for rebuilding the builder machines in the infrastructure meeting this arvo, so i can make sure its something that gets done then (10:07:43) scop: dgilmore, thanks (10:07:46) thl: dgilmore, k, thx (10:07:54) thl: btw, just FYI again (10:08:07) tibbs: Can someone also supply documentation on getting those checks into our local mock configs? (10:08:21) thl: when mock get's updated the minimal buildroots for FC{345} also change (10:08:41) scop: I know how to do that in mach, but not mock... (10:08:58) thl: so things there might break in stable distros due to missing BuildRequires (10:09:51) tibbs: After all of the Dell guy's rebuilds, things deserve to break at this point if they haven't been fixed yet. (10:09:57) jima: those ought to crop up the next time the maintainer tries to build, i imagine. (10:09:59) tibbs: (sorry, I've forgotten his name( (10:10:06) jima: mdomsch (10:10:06) scop: Matt Domsch (10:10:26) thl: jima, yes, normally (10:10:42) thl: k, is there anything else we nned to discuss for the rebuild? (10:10:51) thl: scop, what packages really need a rebuild? (10:10:58) tibbs: Did we agree to use a "needs.rebuild" flag file? (10:10:59) scop: dgilmore, let me know if you need any help with the check-* stuff (10:11:11) scop: tibbs, I think so, yes (10:11:18) abadger1999: I believe we voted yes on that. (10:11:32) dgilmore: scop: will do, ill most likely need some pointers (10:11:33) scop: and I volunteered and will take care of it when it's time (10:12:05) dgilmore: scop: Ill set it up in one of my local build systems first (10:12:29) scop: dgilmore, ok, BTW don't pull in the whole (fedora-)rpmdevtools package (10:12:47) scop: it might add something that is not specified to be there in minimal buildroots (10:13:42) dgilmore: scop: :) ok, want to email me what exactly we need to make sure is in the build roots or chat latter on irc about it? (10:13:59) thl: back to the "what needs rebuilding" question. All arch packages? what about noarch packages? (10:14:19) scop: dgilmore, let's chat a bit after this meeting, ok? (10:14:27) rdieter: imo, noarch can probably be left alone (by default) (10:14:31) dgilmore: scop: sounds good (10:14:35) f13: thl: only arch specific. Stuff compiled by gcc (10:14:48) thl: rdieter, well, they should get a "needs.rebuild", too (10:14:54) tibbs: Are any of the scripting languages getting a bump for FC6? (10:14:55) f13: thl: for Extras, you only need to rebuild stuff that is built by gcc to pick up gnu.hash tables. (10:14:58) thl: so maintainers have to delete them (10:15:02) scop: everything is going to get a "needs.rebuild" flag (10:15:14) jima: you don't need to bump the release for this rebuild, right? (10:15:19) f13: tibbs: I think a new python is out there, but no word yet of making it the default python (10:15:34) f13: jima: I don't understand that question. (10:15:52) tibbs: The release needs to change when you rebuild. (10:16:07) thl: jima, you need to bumo the release (10:16:40) thl: bump (10:16:54) jima: ah, ok (10:17:16) thl: seems we discussed everything for today (10:17:22) thl: regarding that topic (10:17:40) thl has changed the topic to: FESCo meeting in progress -- Next FESCo future/election (10:17:54) thl: abadger1999, got my mail? was it helpful? (10:18:49) abadger1999: thl: Yes it was. But I haven't had time to think about it this week :-( (10:19:02) abadger1999: I should have time over the weekend. (10:19:10) thl: abadger1999, no need to hurry (10:19:21) thl: I'll move that down in the schedule (10:19:31) abadger1999: I'll start by sending an email out with some ideas and we can discuss next week. (10:19:47) thl: abadger1999, target date: End of august ? (10:19:57) abadger1999: Sounds good. (10:20:07) abadger1999: I'll get the ball rolling this weekend. (10:20:17) thl: abadger1999, k, thx (10:20:19) thl: moving on (10:20:23) abadger1999: FESCO list or extras list the better place to discuss this? (10:20:37) thl: #topic FESCo meeting in progress -- CTRL-C problem (10:20:43) thl: abadger1999, extras-list (10:20:46) abadger1999: 'kay (10:20:52) thl has changed the topic to: FESCo meeting in progress -- CTRL-C problem (10:21:17) thl: scop, did you hear anything from Sopwith or the infrastructure group again? (10:21:18) scop: yep, I tested it, and it's still a problem (10:21:25) scop: no word from anyone (10:22:07) thl: scop, maybe we should update the OTRS ticket and poke people directly (10:22:44) thl: scop, ticket is here: https://admin.fedoraproject.org/tickets/customer.pl?Action=CustomerTicketZoom&TicketID=34 (10:22:46) ***mmcgrath looks in (10:22:54) scop: unfortunately from where I live, poking folks more directly than personal mail would be a bit hard, or expensive :) (10:22:56) mmcgrath: I thought someone worked on that already? (10:23:09) thl: scop, can you add some more infos there? (10:23:09) scop: mmcgrath, it was not fixed though (10:23:17) thl: scop, then I'll poke people (10:23:23) mmcgrath: k, I'll make sure to bring it up at the meeting today. (10:23:30) thl: mmcgrath, thx (10:23:55) scop: I get a red "No Permission!" when trying to look at that ticket (10:24:12) ***rdieter nods, glad not to be the only one. (10:24:28) thl: mmcgrath ? (10:24:44) mmcgrath: thats on the list of todo too. (10:24:49) rdieter: maybe otrs only lets you view your own tickets. (10:24:58) thl: rdieter, seems so :-/ (10:25:11) mmcgrath: thats the default. there's a "company tickets" section that we're working to enable. (10:25:21) scop: the problem description is at https://www.redhat.com/mailman/private/fedora-extras-steering/2006-July/msg00019.html (10:25:38) scop: (private archive though) (10:25:40) thl: scop, k, I'll add that to the ticket (10:25:44) thl: so let's move on (10:25:58) thl has changed the topic to: FESCo meeting in progress -- Encourage Extras reviews (10:26:11) tibbs: Pretty much the same as last week; (10:26:17) thl: tibbs, that still on the schedule as "Priority 1 -- Look at it in every meeting" (10:26:35) tibbs: I'm seeing some folks doing additional reviews, which is good, but there are a lot of things blocked on guidelines. (10:26:36) thl: tibbs, shall I move it to "Priority 2"? (10:26:55) tibbs: thl: I think that would be best. I'm still paying attention to it constantly (10:27:03) tibbs: but there's not all that much that I can do at this point. (10:27:17) tibbs: We are starting to see things pile up on FE-NEEDSPONSOR (10:27:25) tibbs: that's going to be the big bottleneck moving forward. (10:27:41) thl: hmmmm (10:27:51) thl: seems we need more or more active sponsors (10:28:14) thl: but we can't make everyone a sponsor :-/ (10:28:24) tibbs: Or reduce the threshold for sponsorship. (10:28:33) thl: tibbs, how? (10:28:42) tibbs: thl: I don't know. (10:28:52) tibbs: It's rare to see those folks doing reviews. (10:29:09) bpepple: tibbs: Have we identified why there are so many FE-NEEDSPONSOR? Last time I looked, it was mainly due to the submitters only having 1 package, which isn't a good indicator of knowledge. (10:29:39) tibbs: bpepple: I could probably add up some stats by hand; c4chris might have something more automated he can do. (10:29:51) tibbs: Most of it does seem to be only one package. (10:29:56) bpepple: Adding more sponsors might not solve the problem. (10:30:42) tibbs: I don't know what will. Perhaps turning sponsorship into more of a mentoring thing, (10:31:04) tibbs: where instead of demonstrating your knowledge up front, you work with someone who will eventually decide you're ready. (10:31:32) abadger1999: tibbs: I like that idea. (10:31:37) tibbs: That's sort of happening already, (10:31:47) bpepple: And have the mentor be a co-maintainer. (10:31:58) tibbs: some folks are saying "we'll look over your packages, and one of us will approve you when we agree that you're ready". (10:32:20) cweyl: maybe a two-tier sponsorship system? the "normal" process for people who intend to become regular, general contributors, and a "one-off" process where people who only have interest in getting one particular package in extras? (I know some @redhat seeking sponsorship for bits just like that right now) (10:33:13) warren: Oh. I intended on dealing with the @redhat people one-on-one myself. (10:33:17) ***cweyl is just brainstorming (10:34:03) thl: I like the idea with co-maintaining (10:34:09) thl: but let's stop here (10:34:10) tibbs: warren: You approved one guy I was intending to sponsor; we weren't sure if you were going to comment on his review ticket. (10:34:25) thl: and move on, otherwise we'll run late again (10:34:33) warren: tibbs, sorry about that confusion. (10:34:36) tibbs: I'm fine with moving on; we can discuss forther on extras-list. (10:34:41) thl: k (10:34:43) bpepple: tibbs: Cool. (10:34:53) thl has changed the topic to: FESCo meeting in progress -- Co-maintainership (10:34:57) thl: just FYI (10:35:05) tibbs: Nice segue there. (10:35:05) thl: I'm preparing a mail on that (10:35:24) thl: might still take some days to finish... (10:35:32) thl: so let's ignore that for today (10:36:00) jcollie[work] [n=jcollie] entered the room. (10:36:08) thl has changed the topic to: FESCo meeting in progress -- AWOL Policy (10:36:16) thl: this is in a proper place now (10:36:19) tibbs: http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers?highlight=% 28Extras%2FPolicy%29 (10:36:44) thl: anything else that needs work there? (10:36:45) tibbs: Crap, just http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers (10:36:53) thl: or can I remove it from the schedule for now? (10:36:57) tibbs: I created the Extras/Policy hierarchy for things like this. (10:37:00) thl: we can fine tune it later (10:37:06) thl: tibbs, thx for that (10:37:25) tibbs: I made the requested changes to point to the vacation page and process documents. (10:37:42) tibbs: Anyone should feel free to fix my crap wiki formatting. (10:37:49) f13: thl: ping (10:37:54) abadger1999: tibbs: Thanks! (10:37:59) thl: f13, pong (10:38:00) f13: thl: subject that should be discussed: Comps updating (10:38:24) f13: FC6's installer now allows you to add repos at install time, such as Extras. It uses comps in the repo to sort packages into groups. If the package isn't in comps, its not available at install time. (10:38:40) thl: hmmm (10:38:40) f13: so as we get closer to release, the Extras comps should really be beat into shape and missing packages should be dealt with. (10:38:54) thl has changed the topic to: FESCo meeting in progress -- Comps updating (10:39:03) tibbs: Perhaps we need another report indicating packages not yet in comps. (10:39:07) ***dgilmore needs to add my packages to comps (10:39:17) thl: tibbs, that was my first though aswell (10:39:25) spot: +1 to tibbs. (10:39:27) thl: we probably should ask c4chris for help (10:39:36) tibbs: I'm not sure how to add my packages to comps; I edited the files but the package never showed up. (10:39:38) rdieter: tibbs++ (10:40:05) rdieter: stupid question: is this comps updating business documented anywhere? (10:40:26) thl: anyone who is interested in driving this foward? e.g. ask c4chris for help or create a script? (10:40:58) thl: rdieter, probably somewhere, but the wiki sometimes is a great mess.. (10:41:07) thl: rdieter, http://fedoraproject.org/wiki/Extras/Schedule/ExtrasCompsXml (10:41:12) f13: rdieter: tibbs: so the comps.in file gets updated, but I think jeremy or somebody has to 'make' it to do the translations. (10:41:19) f13: that happens irregularly (10:41:42) tibbs: Perhaps our friend cron could help us? (10:41:43) thl: scop, could that be integrated into the push scripts? (10:41:56) tibbs: I recall that one problem was making sure the file was well-formed. (10:42:00) thl: yeah, cron might be a good idea, too (10:42:16) scop: cron++ (10:42:25) tibbs: Is a pass through xmlwf sufficient? (10:42:34) scop: (and repoview should really be cron'd as well...) (10:42:57) dgilmore: cron ++ with a check so it only gets updated if changed (10:43:15) dgilmore: repoview is part of the push scripts right? (10:43:18) jima: dgilmore: yeah, else the mirrors are all going to be continually updating it. (10:43:25) dgilmore: thats where it should stay (10:44:17) thl: well, one step at a time (10:44:45) thl: who want's to look after a cron job for the comps updateing? (10:45:14) thl: nor all at once please :) (10:45:38) thl: k, so nobody today (10:45:43) tibbs: I have no access to do anything like that. (10:45:50) thl: abadger1999, be sure to mention it in the report (10:45:58) green_ [n=green] entered the room. (10:45:59) thl: maybe someone outside of fesco is interested (10:46:05) _wart_: thl: I'll volunteer (10:46:13) _wart_: I'd really like to see it fixed. (10:46:23) jorge__ [n=jorge] entered the room. (10:46:26) thl: _wart_, k, thx (10:46:42) thl: _wart_, do you have access to the servers? (10:46:47) _wart_: Nope. (10:46:50) thl: who has? scop? (10:47:11) scop: if I have, all other signers do too (10:47:23) scop: I don't even know where comps is hosted, never used it... (10:47:39) thl: _wart_, seems it's a hard job :) (10:47:55) dgilmore: _wart_: you can always write a scipt to do it and contact the infrastructure people to implement (10:47:59) thl: _wart_, please feel free to poke around and ask people how to get access (or who has access) (10:47:59) _wart_: thl: I'll still volunteer to do whatever I can to help fix it. (10:48:25) thl: _wart_, I'll put it on the schedule (10:48:37) thl: _wart_, if you get stuck or need help ping me (10:48:40) _wart_: I'll start by contacting Jeremy, who has been managing it by hand so far. (10:48:47) thl: _wart_, good plan (10:48:51) thl: k, let's move on (10:49:16) thl: ehh, no (10:49:35) thl: I'll contact c4chris and ask him to enhance his scripts (10:49:45) thl: so they check if all packages are listed in comps (10:49:48) thl has changed the topic to: FESCo meeting in progress -- IPv6 Support in Extras (10:49:59) thl: jwb not around (10:50:03) thl: was his topic iitc (10:50:04) thl: iirc (10:50:11) bpepple: thl: On vacation. (10:50:18) ***thl will skip it (10:50:18) dgilmore: _wart_: if you need help to get a script put in place ping me and ill poke people (10:50:26) _wart_: dgilmore: Thx. (10:50:27) f13: hrm (10:50:31) thl has changed the topic to: FESCo meeting in progress -- spot, Packaging Committee Report (10:50:32) f13: we talked about this in the packaging meeting (10:50:42) scop: one thing from outside the agenda which was already forgotten last week: kmod approval(s?) (10:50:47) scop: eg https://bugzilla.redhat.com/189400 (10:51:01) thl: scop, I added it to the schedule some minutes ago ;-) (10:51:01) f13: and we thought (un voted) that in reviews we should ask if the software supports ipv6, and if it doesn't, the packager should contact upstream about it. (10:51:09) f13: other than that, we'd be hands off on the subject (10:51:21) scop: thl, sneaky :) (10:51:27) spot: the only item to report from this weeks packaging meeting: Comments will be added to the perl template to more clearly indicate items in the template that are not necessary for noarch packages. (10:51:49) scop: already done in rpmdevtools CVS, will be in 5.0 (10:52:01) thl: scop, spot, k, thx (10:52:12) thl has changed the topic to: FESCo meeting in progress -- Weekly sponsorship nomination (10:52:17) thl: any nominations? (10:52:35) scop: btw dir ownership and Group tags were also discussed in the packaging committee meeting, with no resolution yet (10:53:03) thl: BTW and FYI: you can always nominate new sponsors by mail, too; just send me the name, nich, e-mail adress and I'll forward it to fesco-list and/or sponsors-list (10:53:20) ***spot goes afk, starving (10:53:24) giallu left the room (quit: "Leaving"). (10:53:30) ***thl will move on in 15 seconds (10:53:49) thl has changed the topic to: FESCo meeting in progress -- approve kmod's (10:54:06) thl: k, there are two kmod maintainers asked for approval (10:54:22) thl: scop, em8300 at https://bugzilla.redhat.com/189400 (10:54:47) thl: seems okay for me (10:54:49) thl: so +1 (10:55:03) ***scop probably shouldn't vote :) (10:55:28) thl: maybe we should lay down why this proceedure is needed to the new fesco members (10:55:35) tibbs: As much as I understand the criteria, it seems fine to me. (10:55:40) thl: actually, it's new to everyone (10:55:52) thl: we didn#t run into the situation yet (10:56:09) dgilmore: any patenet issues in regards to mpeg ? (10:56:12) thl: but this "specific approval" mostly is to avoid conflicts (10:56:32) thl: and to poke people and upstream to get their stuff into the vanilla kernel (10:56:51) thl: and to avoid stupid kmod's in extras in general (10:57:00) scop: the hollywood+/dxr3 is a hardware mpeg decoder (10:57:18) scop: there is no mpeg stuff in the em8300* packages (10:57:28) scop: it's really like what dvb modules are for dvb cards (10:57:37) thl: dgilmore, there are probably other kmod in the vanilla kernel already (iirc) (10:58:00) thl: (for similar devices) (10:58:05) rdieter: looks good, +1 (10:58:07) thl: so it's probably okay (10:58:13) dgilmore: thl: i realise that (10:58:24) bpepple: I don't see any problems. +1 (10:58:40) thl: k, I consider it approved then (10:58:41) tibbs: +1 (10:58:46) abadger1999: +1 (10:58:49) thl: the other module is (10:59:08) dgilmore: +1 (10:59:20) thl: iscsitarget, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197867 (10:59:20) tibbs: Don't we need seven votes? (10:59:49) scop: is there a vote count in effect in the first place in fesco? (11:00:06) thl: scop, not that I'm aware off (11:00:18) scop: I'm not aware of that either (11:00:20) thl: scop, we just follow common sense mostly (11:00:36) cweyl: thl: the "if no one screams" rule? :) (11:00:51) rdieter: aaahhhh!!! (11:00:52) thl: cweyl, yes, that probably describes it well ;-) (11:01:15) thl: buuuuuu !!! (11:01:41) thl: tibbs, do we want to get that stuff more formalized? (11:01:46) rdieter: I'm ok with bz197867 too, +1 (11:02:04) thl: btw, O'm okay with #197867, so a +1 from me (11:02:06) tibbs: thl: I don't want to make waves; I was just wondering what accepted criteria for approval are. (11:02:20) tibbs: I'm concerned about the ISCSI target. (11:02:32) tibbs: If it's not acceptable for upstream, are we sure we want it? (11:02:48) thl: "at least seven votes" would mean that we can't run meetings without six members or less (11:02:55) thl: and in the past we ofter were six or less (11:03:05) f13: hrm, somebody was asking about that today (11:03:12) thl: tibbs, your concers are valid imho (11:03:17) f13: since we support iSCSI targets in anaconda now, to test we need some target software (11:03:30) thl: tibbs, but from all I can see it seems they are working on something better to get upstream (11:03:47) tibbs: If someone relies on it, though, and the upstream kernel does eventually get the "better" support, where does that leave us? (11:03:53) thl: tibbs, but it seems some people are still interested in iscsitarget (11:04:40) tibbs: I guess if everything is well-disclaimered it's OK. The maintainer has indicated he'd do that. (11:04:44) thl: f13, is the iSCSI stuff in RHEL? (11:05:05) f13: thl: -EUNKNOWN (11:05:31) f13: thl: I don't think so, since RHEL5 right now is mostly just FC6 bits. I don't see an iscsi package for 5E (11:05:50) scop: I'd be inclined accept it now, and when there's a distro version whose all kernels provide "better" things, drop it from that distro version onwards (11:06:10) thl: scop, sound like a good plan (11:06:12) f13: worksforme (11:06:15) tibbs: I agree, as long as users know this. (11:06:17) thl: so still a +1 from me (11:06:20) tibbs: +1 (11:06:24) scop: +1 (11:06:24) bpepple: scop: sounds good. (11:06:35) rdieter: +1 (still) (11:06:39) bpepple: +1 (11:06:43) warren: +1 (doesn't hurt anyone except users) (11:06:48) abadger1999: +1 (11:06:55) thl: k, accepted (11:07:23) thl: does anyone want to discuss any Priority 2 or Priority 3 items? (11:07:42) mdomsch [n=mdomsch] entered the room. (11:07:53) thl has changed the topic to: FESCo meeting in progress -- free discussion around Extras (11:07:55) tibbs: We only talk about kernel modules after a reviewer has approved them, right? (11:08:07) thl: tibbs, no, before the review starts (11:08:25) thl: to avoid that people have work in the first place in case it's not accepted (11:08:32) thl: em8300 was a sepcial case (11:08:34) tibbs: Did the committee already discuss sysprof-kmod and the asterisk thing? (11:08:41) tibbs: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191745 (11:08:43) thl: tibbs, nope (11:08:54) tibbs: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177583 (11:09:04) thl: tibbs, is there a statement yet why the stuff is not upstream? (11:09:11) tibbs: zaptel-kmod (the latter) is already being reviewed. (11:09:25) thl: without such a statement I'm not going to approve kmod's (11:09:36) rdieter: thl++ (11:09:49) scop: ack (11:09:50) tibbs: I'll ping on those bugs and make sure they have the necessary info in them. (11:09:56) scop: one more thing about kmods (11:10:12) scop: what do people think about shipping them in devel? (11:10:27) thl: tibbs, fyi, from http://www.fedoraproject.org/wiki/Packaging/KernelModules (11:10:36) thl: "Besides rules around the packaging there is one additional *before* you start packaging a kernel module for Fedora Extras: Open a Review bug in [WWW] http://bugzilla.redhat.com and ask FESCo via fedoraleemhuisinfo for permission if this module is allowed for Extras. This requires that you give at least the following informations:" (11:10:49) thl: tibbs, point them there (11:10:51) rdieter: why not in devel? I'd say it's up to the maintainer. (11:10:55) scop: following rawhide kernels there would be a non-trivial amount of work (11:11:01) Sopwith [n=sopwith] entered the room. (11:11:16) scop: and I'm afraid that they'll end up as frequent visitors in the devel broken deps reports (11:11:17) ***thl wonders if we need a FE-KMODNEEDSAPPROV blocker bug (11:11:32) thl: scop, I think we don#t need them atm (11:11:39) f13: the kmod stuff, I wouldn't want to see any of that get approved / voted on until the kabi stuff gets worked in. (11:11:44) thl: scop, we should have them when plague supports automatic rebuilding (11:11:46) tibbs: thl: I'll set it up if folks think so, but I don't think it's needed. (11:11:47) cweyl: thl: +1 (rabble). we block everything else to track them (11:11:48) f13: that could really change the aspect of kernel module packaging. (11:11:53) dgilmore: im 90% sure that the zaptel-kmod submitter was asked for a reason its not upstream (11:12:46) thl: f13, we mostly ignore the kabi stuff for extras atm afaics (11:12:59) tibbs: dgilmore: You're correct. He got a "read" on their intentions but no direct statement. (11:12:59) thl: f13, the fedora-kernels don#t provide a stable abi in any case (11:13:19) thl: f13, there was some discussion about that in earlier meetings and on the list (11:13:47) scop: I think we already have enough barriers for kmods (11:13:47) thl: f13, any if something changes we can follow that (11:13:54) thl: scop, agreed (11:14:04) thl: and we waited very long already (11:14:07) tibbs: Any good reference for kabi? (11:14:09) thl: we should start with them (11:14:26) thl: tibbs, http://www.kerneldrivers.org/ (11:14:50) ***thl looks at his watch (11:14:53) thl: quite late already (11:15:03) scop: note also that kmods are already "sandboxed" within their respective kernel versions, so changing things shouldn't be much of a problem (11:15:40) thl: anything else on this topic? (11:15:44) thl: any other topics? (11:15:52) thl: otherwise I'm going to close the meeting soon (11:16:13) ***thl will close the meeting in 30 seconds (11:16:35) ***thl will close the meeting in 10 seconds (11:16:46) thl: -- MARK -- Meeting End (11:16:52) thl: thx everybody (11:16:54) tibbs: Who will move AWOL policy to the completed issues? (11:17:03) thl: tibbs, I'll do that (11:17:11) tibbs: Cool, actual progress! (11:17:19) scop: :) (11:17:54) thl has changed the topic to: This is the Fedora Extras channel, home of the FESCo meetings and general Extras discussion. | http://fedoraproject.org/wiki/Extras | Next FESCo Meeting: 2006-07-27 1700 UTC (11:18:04) bpepple left the room. (11:18:31) thl: btw, the list of priority 1 task is a bit shorter now (11:18:43) thl: hopefully the next meetings are a bit less hectic (11:19:12) f13: thl: the Fedora kernel is providing a KABI now (11:19:24) thl: f13, I know (11:19:25) f13: thl: and rpm knows about it. (11:19:41) thl: f13, but davej is not going to maintain a stable abi afaik (11:19:48) f13: so, if we're going to approve any kernel packaging guidelines, it should be with that abi in mind. (11:20:03) f13: thl: the ABI is at a subdir level. SOme things change a lot less than others across updates (11:20:38) f13: thl: while we're not going to make an effort to maintain a stable ABI, some stableness will be achieved anyway. And there is no reason that we shouldn't try to use the kabi for what it is. (11:20:55) f13: its not like we'd have to rebuild any more than doing it for each and every kernel spin. (11:21:18) thl: f13, we probably should discuss this on the list again (11:21:39) f13: thl: and wait for Jon Masters to get back from OLS so that he can participate (11:21:51) thl: f13, but when this kabi stuff came up the people were not that glad about the idea for fedora afaics (11:22:15) thl: f13, especially spot seemed to not like it that much (11:22:27) thl: but if it works and we actually see how it works (11:22:31) thl: it might be something different (11:22:48) tibbs: I don't really see what the problem is. (11:22:49) thl: f13, I simply had no real time or interest to look into it (11:23:05) f13: I sat through a Lunch and Learn JCM did here in Westford, and now I understand it a lot better (11:23:10) f13: it does make a lot of sense. (11:23:19) f13: and jcm is very very motiviated to make it work. (11:23:28) tibbs: We're seeing kernels come out with one-line fixes in them; it shouldn't hurt to say that the ABI doesn't change when that happens. (11:23:34) thl: (and I'm not in the packaging comittee, so kmod decisions probably should now be handled by someone else) (11:24:06) f13: tibbs: the abi is figured out automagically by looking at the ksysms table and checksumming at a directory level (11:24:06) thl: f13, I think I understand the general direction (11:24:13) tibbs: The kmod thing seems to be for Extras benefit, though. Or are there plans to use it for Core? (11:24:18) thl: f13, and I actually tend to like it (11:24:35) thl: f13, but I had no time to really dig into it (11:24:40) f13: tibbs: there aren't any more Core packages that are kernel modules, but it could hit RHEL (11:25:04) thl: tibbs, yeah, an some hardware verndors might release driver updates this way -------------- 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 Fri Jul 21 20:07:17 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 21 Jul 2006 15:07:17 -0500 Subject: rpms/sextractor/FC-4 sextractor.spec,1.2,1.3 In-Reply-To: <1153508980.18981.125.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri, 21 Jul 2006 21:09:40 +0200") References: <200607211724.k6LHO3Z8023012@cvs-int.fedora.redhat.com> <1153508980.18981.125.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> On Fri, 2006-07-21 at 10:24 -0700, Sergio Pascual wrote: >> %build -%configure +%configure CFLAGS="${CFLAGS} -funroll-loops >> -fomit-frame-pointer -O1 RC> REVERT this change IMMEDIATELY. RC> You are breaking debug infos. Yes, this is not good. For reference, the bug which prompted this is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199700 The problem is that the code simply does not function with the default Fedora optimization flags. I am not familiar with the software and have no idea whether this points to a GCC problem or just poorly written code. Someone should investigate the minimum change to the stock Fedora cflags which permit this software to work properly, and then investigate why the behavior differs. Is there a standard method for overriding a single flag in %{optflags}? - J< From tibbs at math.uh.edu Fri Jul 21 20:12:02 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 21 Jul 2006 15:12:02 -0500 Subject: rpms/sextractor/FC-4 sextractor.spec,1.2,1.3 In-Reply-To: <1153508980.18981.125.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri, 21 Jul 2006 21:09:40 +0200") References: <200607211724.k6LHO3Z8023012@cvs-int.fedora.redhat.com> <1153508980.18981.125.camel@mccallum.corsepiu.local> Message-ID: My apologies; I'm resending this because I mistyped the address of the SExtractor maintainer. >>>>> "RC" == Ralf Corsepius writes: RC> On Fri, 2006-07-21 at 10:24 -0700, Sergio Pascual wrote: >> %build -%configure +%configure CFLAGS="${CFLAGS} -funroll-loops >> -fomit-frame-pointer -O1 RC> REVERT this change IMMEDIATELY. RC> You are breaking debug infos. Yes, this is not good. For reference, the bug which prompted this is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199700 The problem is that the code simply does not function with the default Fedora optimization flags. I am not familiar with the software and have no idea whether this points to a GCC problem or just poorly written code. Someone should investigate the minimum change to the stock Fedora cflags which permit this software to work properly, and then investigate why the behavior differs. Is there a standard method for overriding a single flag in %{optflags}? - J< From j.w.r.degoede at hhs.nl Fri Jul 21 20:46:30 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 21 Jul 2006 22:46:30 +0200 Subject: FE devel rebuild? In-Reply-To: <20060721210625.4ca8a2bb@nausicaa.camperquake.de> References: <44C11C40.6060807@leemhuis.info> <44C11D9D.4010105@hhs.nl> <20060721184012.GD16006@neu.nirvana> <44C1240E.2070307@leemhuis.info> <20060721210625.4ca8a2bb@nausicaa.camperquake.de> Message-ID: <44C13D26.7090605@hhs.nl> Ralf Ertzinger wrote: > Hi. > > Thorsten Leemhuis wrote: > >> But yes, a script like the one Hans asked for might be helpful. f13 >> probably has one ;-) > > Another thing possibly needed is a tree of dependencies, so that > packages that other packages depend on are rebuild first. > I wouldn't mind doing that myself / manually. The main thing I want to be able todo is just make the specfile editing, commit, tag and build happen in one magic command (say make rebuild). The tricky part is automating the specfile editing. Regards, Hans From bugzilla at redhat.com Fri Jul 21 20:48:25 2006 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 21 Jul 2006 16:48:25 -0400 Subject: [Bug 173035] Review Request: chmlib - Library for dealing with ITSS/CHM format files In-Reply-To: Message-ID: <200607212048.k6LKmPAE031648@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: chmlib - Library for dealing with ITSS/CHM format files https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173035 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com ------- Additional Comments From pertusus at free.fr 2006-07-21 16:39 EST ------- John, you should assign that bug to yourself. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From tibbs at math.uh.edu Fri Jul 21 22:26:25 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 21 Jul 2006 17:26:25 -0500 Subject: FE devel rebuild? In-Reply-To: <44C13D26.7090605@hhs.nl> (Hans de Goede's message of "Fri, 21 Jul 2006 22:46:30 +0200") References: <44C11C40.6060807@leemhuis.info> <44C11D9D.4010105@hhs.nl> <20060721184012.GD16006@neu.nirvana> <44C1240E.2070307@leemhuis.info> <20060721210625.4ca8a2bb@nausicaa.camperquake.de> <44C13D26.7090605@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> I wouldn't mind doing that myself / manually. The main thing I HdG> want to be able todo is just make the specfile editing, commit, HdG> tag and build happen in one magic command (say make rebuild). The HdG> tricky part is automating the specfile editing. There's a gross hack at http://www.math.uh.edu/~tibbs/specbump that will unpack an srpm, bump the release in the specfile and drop you into an editor to complete the changelog entry, then drop you into a shell to look around, and then build a fresh srpm when you exit. Maybe you can do something with it. (Hmm, just noticed the created changelog entries aren't in the proper format.) - J< From rc040203 at freenet.de Sat Jul 22 03:04:35 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 22 Jul 2006 05:04:35 +0200 Subject: rpms/sextractor/FC-4 sextractor.spec,1.2,1.3 In-Reply-To: References: <200607211724.k6LHO3Z8023012@cvs-int.fedora.redhat.com> <1153508980.18981.125.camel@mccallum.corsepiu.local> Message-ID: <1153537475.18981.150.camel@mccallum.corsepiu.local> On Fri, 2006-07-21 at 15:12 -0500, Jason L Tibbitts III wrote: > My apologies; I'm resending this because I mistyped the address of the > SExtractor maintainer. > > >>>>> "RC" == Ralf Corsepius writes: > > RC> On Fri, 2006-07-21 at 10:24 -0700, Sergio Pascual wrote: > >> %build -%configure +%configure CFLAGS="${CFLAGS} -funroll-loops > >> -fomit-frame-pointer -O1 > RC> REVERT this change IMMEDIATELY. > > RC> You are breaking debug infos. > > Yes, this is not good. During a review, this would be a BLOCKER and would cause a package not to be accepted. I am not willing to let maintainers get away with such stuff post-review. > For reference, the bug which prompted this is > here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199700 > > The problem is that the code simply does not function with the default > Fedora optimization flags. I am not familiar with the software and > have no idea whether this points to a GCC problem or just poorly > written code. Someone should investigate the minimum change to the > stock Fedora cflags which permit this software to work properly, and > then investigate why the behavior differs. > > Is there a standard method for overriding a single flag in > %{optflags}? The way he does it is the way how things are supposed to work. The problem is what he does: -fomit-frame-pointer Ralf From jamatos at fc.up.pt Sat Jul 22 07:17:50 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Sat, 22 Jul 2006 08:17:50 +0100 Subject: FE devel rebuild? In-Reply-To: <44C1240E.2070307@leemhuis.info> References: <20060721184012.GD16006@neu.nirvana> <44C1240E.2070307@leemhuis.info> Message-ID: <200607220817.51068.jamatos@fc.up.pt> On Friday 21 July 2006 19:59, Thorsten Leemhuis wrote: > I prefer a manual rebuild for two reasons: > > - A lot of people don't want everything rebuild because it requires a > lot of downloads for users -- noarch packages for example don't require > a rebuild this time afaik This is non-issue. We are talking about the same people who are testing development, so "a lot of downloads" means peanuts when compared with Core. ;-) -- Jos? Ab?lio From fedora at leemhuis.info Sat Jul 22 08:10:19 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 22 Jul 2006 10:10:19 +0200 Subject: FE devel rebuild? In-Reply-To: <200607220817.51068.jamatos@fc.up.pt> References: <20060721184012.GD16006@neu.nirvana> <44C1240E.2070307@leemhuis.info> <200607220817.51068.jamatos@fc.up.pt> Message-ID: <44C1DD6B.1030100@leemhuis.info> Jose' Matos schrieb: > On Friday 21 July 2006 19:59, Thorsten Leemhuis wrote: >> I prefer a manual rebuild for two reasons: >> - A lot of people don't want everything rebuild because it requires a >> lot of downloads for users -- noarch packages for example don't require >> a rebuild this time afaik > This is non-issue. We are talking about the same people who are testing > development, so "a lot of downloads" means peanuts when compared with > Core. ;-) Actually this is my opinion somewhat, too. With a "everything" rebuild we would make sure that all packages still builds in general with FC6 and with the new reduced set of default packages in the buildroot. And we would get rid of all ".fc5 tags, too. But on the other hand a "everything" rebuild means that all those updating from FC5 to FC6 later have a lot of downloads without a real reason, too. CU thl From fedora at leemhuis.info Sat Jul 22 08:26:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 22 Jul 2006 10:26:28 +0200 Subject: FE devel rebuild? In-Reply-To: <20060721210625.4ca8a2bb@nausicaa.camperquake.de> References: <44C11C40.6060807@leemhuis.info> <44C11D9D.4010105@hhs.nl> <20060721184012.GD16006@neu.nirvana> <44C1240E.2070307@leemhuis.info> <20060721210625.4ca8a2bb@nausicaa.camperquake.de> Message-ID: <44C1E134.8010500@leemhuis.info> Ralf Ertzinger schrieb: > Thorsten Leemhuis wrote: >> But yes, a script like the one Hans asked for might be helpful. f13 >> probably has one ;-) > Another thing possibly needed is a tree of dependencies, so that > packages that other packages depend on are rebuild first. Well, some people suggested that the build-order is not that important and can be ignored (Core ignores it also afaics). Other people think it's important and make manually sure taht everything is build mostly in the correct order... CU thl From jamatos at fc.up.pt Sat Jul 22 08:46:15 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Sat, 22 Jul 2006 09:46:15 +0100 Subject: FE devel rebuild? In-Reply-To: <44C1DD6B.1030100@leemhuis.info> References: <200607220817.51068.jamatos@fc.up.pt> <44C1DD6B.1030100@leemhuis.info> Message-ID: <200607220946.16154.jamatos@fc.up.pt> On Saturday 22 July 2006 09:10, Thorsten Leemhuis wrote: > But on the other hand a "everything" rebuild means that all those > updating from FC5 to FC6 later have a lot of downloads without a real > reason, too. Then what is the problem with "all but noarch"? > CU > thl -- Jos? Ab?lio From fedora at leemhuis.info Sat Jul 22 09:54:58 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 22 Jul 2006 11:54:58 +0200 Subject: FE devel rebuild? In-Reply-To: <200607220946.16154.jamatos@fc.up.pt> References: <200607220817.51068.jamatos@fc.up.pt> <44C1DD6B.1030100@leemhuis.info> <200607220946.16154.jamatos@fc.up.pt> Message-ID: <44C1F5F2.6010106@leemhuis.info> Jose' Matos schrieb: > On Saturday 22 July 2006 09:10, Thorsten Leemhuis wrote: >> But on the other hand a "everything" rebuild means that all those >> updating from FC5 to FC6 later have a lot of downloads without a real >> reason, too. > Then what is the problem with "all but noarch"? Nothing -- I just explained the most important reasons for both sides in case people want to discuss this stuff again ;-) CU thl From mr.ecik at gmail.com Sat Jul 22 11:25:22 2006 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sat, 22 Jul 2006 13:25:22 +0200 Subject: Question about doc subpackage Message-ID: <668bb39a0607220425l13ed9603qb3e20b585d4be749@mail.gmail.com> Hi! I have a question about doc subpackage. Packaging Guidelines doesn't say anything about it, but I think that doc subpackages should be noarch, because they aren't architecture dependent. But when I write "BuildArch: noarch" to subpackage, RPM gives an error. It extracts debug info, but not create debuginfo package. It treats whole package as noarch. Is there an option to get doc subpackage on other buildarch than main package? From paul at city-fan.org Sat Jul 22 12:27:06 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 22 Jul 2006 13:27:06 +0100 Subject: rpms/sextractor/FC-4 sextractor.spec,1.2,1.3 In-Reply-To: <1153537475.18981.150.camel@mccallum.corsepiu.local> References: <200607211724.k6LHO3Z8023012@cvs-int.fedora.redhat.com> <1153508980.18981.125.camel@mccallum.corsepiu.local> <1153537475.18981.150.camel@mccallum.corsepiu.local> Message-ID: <1153571226.30083.31.camel@laurel.intra.city-fan.org> On Sat, 2006-07-22 at 05:04 +0200, Ralf Corsepius wrote: > On Fri, 2006-07-21 at 15:12 -0500, Jason L Tibbitts III wrote: > > My apologies; I'm resending this because I mistyped the address of the > > SExtractor maintainer. > > > > >>>>> "RC" == Ralf Corsepius writes: > > > > RC> On Fri, 2006-07-21 at 10:24 -0700, Sergio Pascual wrote: > > >> %build -%configure +%configure CFLAGS="${CFLAGS} -funroll-loops > > >> -fomit-frame-pointer -O1 > > RC> REVERT this change IMMEDIATELY. > > > > RC> You are breaking debug infos. > > > > Yes, this is not good. > During a review, this would be a BLOCKER and would cause a package not > to be accepted. > > I am not willing to let maintainers get away with such stuff > post-review. > > > For reference, the bug which prompted this is > > here: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199700 > > > > The problem is that the code simply does not function with the default > > Fedora optimization flags. I am not familiar with the software and > > have no idea whether this points to a GCC problem or just poorly > > written code. Someone should investigate the minimum change to the > > stock Fedora cflags which permit this software to work properly, and > > then investigate why the behavior differs. > > > > Is there a standard method for overriding a single flag in > > %{optflags}? > > The way he does it is the way how things are supposed to work. A similar approach is used is openais: (http://cvs.fedora.redhat.com/viewcvs/devel/openais/openais.spec?view=markup) # -O3 required for performance reasons CFLAGS="$(echo '%{optflags}' | sed -e 's/-O[0-9]*//') -O3" make CFLAGS="$CFLAGS" Paul. From paul at city-fan.org Sat Jul 22 12:29:14 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 22 Jul 2006 13:29:14 +0100 Subject: Question about doc subpackage In-Reply-To: <668bb39a0607220425l13ed9603qb3e20b585d4be749@mail.gmail.com> References: <668bb39a0607220425l13ed9603qb3e20b585d4be749@mail.gmail.com> Message-ID: <1153571354.30083.33.camel@laurel.intra.city-fan.org> On Sat, 2006-07-22 at 13:25 +0200, Micha? Bentkowski wrote: > Hi! I have a question about doc subpackage. Packaging Guidelines > doesn't say anything about it, but I think that doc subpackages should > be noarch, because they aren't architecture dependent. But when I > write "BuildArch: noarch" to subpackage, RPM gives an error. It > extracts debug info, but not create debuginfo package. It treats whole > package as noarch. Is there an option to get doc subpackage on other > buildarch than main package? No. There is no support in rpm to do this. Paul. From Matt_Domsch at dell.com Sat Jul 22 13:50:09 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 22 Jul 2006 08:50:09 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-07-22 Message-ID: <20060722135009.GC9662@lists.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Sat Jul 22 02:25:06 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: argus-2.0.6.fixes.1-11.fc6 197215 NEW bidiv-1.5-3.fc5 197224 NEW gazpacho-0.6.6-1.fc6 197793 NEW Number failed to build: 94 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 93 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 77 ---------------------------------- azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com camstream-0.26.3-9.fc5 nomis80 at nomis80.org contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net ddskk-12.2.0-7.fc5 petersen at redhat.com diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org dnsmasq-2.32-2.fc6 jima at beer.tclug.org ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com epiphany-extensions-2.14.1-1 caillon at redhat.com exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com flim-1.14.7-3 petersen at redhat.com gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de gobby-0.4.0-6.rc2.fc6 lmacken at redhat.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org GtkAda-2.4.0-11.fc5 gemi at bluewin.ch Hermes-1.3.3-7 thomas at apestaart.org ifplugd-0.24-6 aaron.bennett at olin.edu john-1.6-4 ghenry at suretecsystems.com kanatest-0.3.6-4.fc5 robert at marcanoonline.com kdissert-1.0.5-1.1.fc5 icon at fedoraproject.org kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu kover-2.9.6-5 adrian at lisas.de ladspa-1.12-5 thomas at apestaart.org leafpad-0.8.9-1.fc6 ivazquez at ivazquez.net libchmxx-0.1-3.fc6 pertusus at free.fr librx-1.5-6.fc5 tcallawa at redhat.com libtabe-0.2.6-14 llch at redhat.com libtomoe-gtk-0.1.0-5.fc5 ryo-dairiki at users.sourceforge.net licq-1.3.2-8 pvrabec at redhat.com linkchecker-3.3-3 redhat at flyn.org logjam-4.5.3-4.fc6 tcallawa at redhat.com lucidlife-0.9-9.fc6 peter at thecodergeek.com MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mfstools-2.0-9.snapshot050221.fc5 tcallawa at redhat.com multisync-0.90.18-5.fc5 andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 dennis at ausil.us nautilus-search-tool-0.2-1.fc5 ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 andreas.bierfert at lowlatency.de NetworkManager-vpnc-0.7.0-0.cvs20060529.1.fc6 davidz at redhat.com ngrep-1.44-4.fc5 oliver at linux-kernel.at openal-0.0.9-0.5.20060204cvs.fc5 andreas.bierfert at lowlatency.de opencv-0.9.7-15.fc5 nomis80 at nomis80.org orange-0.3-1.cvs20051118.fc6 andreas.bierfert at lowlatency.de pam_keyring-0.0.7-2 redhat at flyn.org pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.16-1.fc6 gemi at bluewin.ch powerman-1.0.24-1.fc6 jwilson at redhat.com python-goopy-0.1-1 pjones at redhat.com python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net qalculate-kde-0.9.4-1.fc6 dakingun at gmail.com quarry-0.1.16-2.fc5 michel.salim at gmail.com rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rss-glx-0.8.1.p-3.fc6 nphilipp at redhat.com rssowl-1.2-12.fc6 green at redhat.com sabayon-2.12.3-3 markmc at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at scmxx-0.8.2-1.fc5 andreas at bawue.net SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-6.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net sloccount-2.26-4 bnocera at redhat.com stratagus-2.1-5.fc6 lemenkov at newmail.ru syck-0.55-7.fc5 oliver at linux-kernel.at synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xcompmgr-1.1.3-4.fc6 dakingun at gmail.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com xsupplicant-1.2.6-1.fc6 tcallawa at redhat.com With bugs filed: 16 ---------------------------------- alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com ccrtp-1.3.7-1.fc6 ['197362 NEW'] andreas at bawue.net cowbell-0.2.7.1-2.fc6 ['197366 CLOSED'] foolish at guezz.net dillo-0.8.6-2.fc6 ['197370 CLOSED'] andreas.bierfert at lowlatency.de fish-1.12.0-1.fc5 ['179296 NEW'] oliver at linux-kernel.at gdesklets-0.35.3-8.fc6 ['197799 NEW'] luya256 at yahoo.com gnomad2-2.8.6-1.fc6 ['197920 NEW'] triad at df.lth.se gnome-applet-music-0.9.0-1.fc6 ['197924 NEW'] ivazquez at ivazquez.net gnome-schedule-1.0.0-1 ['197927 NEW'] frank at scirocco-5v-turbo.de grhino-0.15.0-5.fc5 ['197950 NEW'] michel.salim at gmail.com gtktalog-1.0.4-7.fc5 ['198897 NEW'] matthias at rpmforge.net jam-2.5-3.fc5 ['198924 NEW'] tcallawa at redhat.com nco-3.1.2-1.fc6 ['193541 NEW'] ed at eh3.com xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Sat Jul 22 13:58:34 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 22 Jul 2006 08:58:34 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 Message-ID: <20060722135834.GD9662@lists.us.dell.com> I'm Bcc'ing everyone whose email shows up for a package below this time, as the time for manditory package fixing is drawing near, per the note to fedora-maintainers. If you haven't looked at your packages in a while, and they fail to build in the reduced chroot, now would be a good time to take a look. Thanks, Matt Extras Rawhide-in-Mock Build Results for x86_64 Sat Jul 22 02:21:07 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: argus-2.0.6.fixes.1-11.fc6 197215 NEW bidiv-1.5-3.fc5 197224 NEW gazpacho-0.6.6-1.fc6 197793 NEW Number failed to build: 175 Number expected to fail due to ExclusiveArch or ExcludeArch: 2 Leaving: 173 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 153 ---------------------------------- atitvout-0.4-5 andreas.bierfert at lowlatency.de azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com blender-2.42-3.fc6 Jochen at herr-schmitt.de camstream-0.26.3-9.fc5 nomis80 at nomis80.org cegui-0.4.1-9.fc6 packages at amiga-hardware.com chrpath-0.13-1.fc6 Axel.Thimm at ATrpms.net clisp-2.39-1.fc6 gemi at bluewin.ch cmucl-19c-4.fc5 rdieter at math.unl.edu contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net ddskk-12.2.0-7.fc5 petersen at redhat.com diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org dnsmasq-2.32-2.fc6 jima at beer.tclug.org ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com ecl-0.9i-1.fc6 gemi at bluewin.ch epiphany-extensions-2.14.1-1 caillon at redhat.com exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com flim-1.14.7-3 petersen at redhat.com foobillard-3.0a-4 mitr at redhat.com freenx-0.5.0-2.fc6 zipsonic at gmail.com gambas-1.0.14-2.fc5 tcallawa at redhat.com gc-6.8-1.fc6 rdieter at math.unl.edu ghdl-0.24-0.59svn.2.fc6 t.sailer at alumni.ethz.ch gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de gkrellm-2.2.9-7.fc6 j.w.r.degoede at hhs.nl gkrellm-wifi-0.9.12-2.fc6 j.w.r.degoede at hhs.nl gnofract4d-2.14-3.fc6 michael at knox.net.nz gnumeric-1.6.3-3.fc6 j.w.r.degoede at hhs.nl gobby-0.4.0-6.rc2.fc6 lmacken at redhat.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org GtkAda-2.4.0-11.fc5 gemi at bluewin.ch i8kutils-1.25-10.fc6 matthias at rpmforge.net ifplugd-0.24-6 aaron.bennett at olin.edu jogl-1.1.1-14.fc5 green at redhat.com john-1.6-4 ghenry at suretecsystems.com kanatest-0.3.6-4.fc5 robert at marcanoonline.com kawa-1.8-6.fc6 green at redhat.com kdissert-1.0.5-1.1.fc5 icon at fedoraproject.org kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu kover-2.9.6-5 adrian at lisas.de ladspa-1.12-5 thomas at apestaart.org leafpad-0.8.9-1.fc6 ivazquez at ivazquez.net libchmxx-0.1-3.fc6 pertusus at free.fr libhugetlbfs-0.20060706-1.fc6 drfickle at k-lug.org libnetfilter_conntrack-0.0.31-2.fc6 i at stingr.net libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libsigsegv-2.4-1.fc6 rdieter at math.unl.edu libtabe-0.2.6-14 llch at redhat.com libtomoe-gtk-0.1.0-5.fc5 ryo-dairiki at users.sourceforge.net licq-1.3.2-8 pvrabec at redhat.com lightning-1.2-3.fc6 Jochen at herr-schmitt.de linkchecker-3.3-3 redhat at flyn.org logjam-4.5.3-4.fc6 tcallawa at redhat.com lrmi-0.10-1.fc5 kevin-redhat-bugzilla at tummy.com lucidlife-0.9-9.fc6 peter at thecodergeek.com Macaulay2-0.9.8-0.3.cvs20060327.fc6 rdieter at math.unl.edu MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mew-5.1-1.fc6 tagoh at redhat.com mhonarc-2.6.16-1.fc6 gauret at free.fr mlton-20051202-8.fc6 adam at spicenitz.org mod_nss-1.0.3-1.fc6 rcritten at redhat.com monodoc-1.1.16-1.fc6 paul at all-the-johnsons.co.uk multisync-0.90.18-5.fc5 andreas.bierfert at lowlatency.de mxml-2.2.2-4.fc6 green at redhat.com mysql-administrator-1.1.10-1.fc6 dennis at ausil.us nant-0.85-6.fc6 paul at all-the-johnsons.co.uk nas-1.8-6.fc6 frank-buettner at gmx.net nautilus-search-tool-0.2-1.fc5 ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 andreas.bierfert at lowlatency.de NetworkManager-vpnc-0.7.0-0.cvs20060529.1.fc6 davidz at redhat.com new-1.3.7-2 redhat at flyn.org ngrep-1.44-4.fc5 oliver at linux-kernel.at nx-2.0.0-3.fc6 zipsonic at gmail.com ogre-1.2.1-3.fc6 j.w.r.degoede at hhs.nl openal-0.0.9-0.5.20060204cvs.fc5 andreas.bierfert at lowlatency.de openalpp-20060405-10.fc6 chris.stone at gmail.com opencv-0.9.7-15.fc5 nomis80 at nomis80.org osgcal-0.1.40-3.fc6 chris.stone at gmail.com pam_keyring-0.0.7-2 redhat at flyn.org perl-eperl-2.2.14-2.fc6 steve at silug.org perl-Expect-1.19-1.fc6 jpo at di.uminho.pt perl-File-Flat-0.96-2.fc6 rc040203 at freenet.de perl-IO-Tty-1.06-1.fc6 jpo at di.uminho.pt perl-Module-Pluggable-3.10-1.fc6 steve at silug.org perl-PAR-Dist-0.11-1.fc6 ville.skytta at iki.fi perl-POE-Filter-IRCD-1.7-1.fc6 cweyl at alumni.drew.edu perl-SOAP-Lite-0.68-1.fc6 imlinux at gmail.com perl-Unicode-Map8-0.12-8.fc5 gauret at free.fr perl-Unicode-MapUTF8-1.09-6.fc5 gauret at free.fr pexpect-2.1-1.fc6 toshio at tiki-lounge.com php-pear-DB-1.7.6-6 rpm at timj.co.uk pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.16-1.fc6 gemi at bluewin.ch powerman-1.0.24-1.fc6 jwilson at redhat.com pybliographer-1.2.9-1.fc6 z.kota at gmx.net python-cheetah-2.0-0.1.rc7.fc6 mikeb at redhat.com python-configobj-4.3.2-2.fc6 lmacken at redhat.com python-dateutil-1.1-2.fc5 orion at cora.nwra.com python-goopy-0.1-1 pjones at redhat.com python-paste-0.9.3-4.fc6 lmacken at redhat.com python-psyco-1.5.1-2.fc6 shahms at shahms.com python-reportlab-1.20-5.fc5 bdpepple at ameritech.net python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net q-7.1-2.fc6 gemi at bluewin.ch qa-assistant-0.4.90.5-1.fc6.1 toshio at tiki-lounge.com qalculate-kde-0.9.4-1.fc6 dakingun at gmail.com qt4-4.1.4-7.fc6 rdieter at math.unl.edu quarry-0.1.16-2.fc5 michel.salim at gmail.com radiusclient-ng-0.5.2-3.fc6 jeff at ollie.clive.ia.us raidem-0.3.1-4.fc6 j.w.r.degoede at hhs.nl renrot-0.22-1.0.fc6 andy at smile.org.ua rosegarden4-1.2.3-3.fc6 seg at haxxed.com rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rss-glx-0.8.1.p-3.fc6 nphilipp at redhat.com rssowl-1.2-12.fc6 green at redhat.com rxvt-unicode-7.8-1.fc6 andreas.bierfert at lowlatency.de sabayon-2.12.3-3 markmc at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at scmxx-0.8.2-1.fc5 andreas at bawue.net SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-6.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net sextractor-2.5.0-1.fc6 spr at astrax.fis.ucm.es skstream-0.3.5-2.fc6 wart at kobold.org sloccount-2.26-4 bnocera at redhat.com spicctrl-1.9-4.fc6 roozbeh at farsiweb.info stratagus-2.1-5.fc6 lemenkov at newmail.ru subversion-api-docs-1.3.2-1.fc6 bojan at rexursive.com sylpheed-claws-plugins-2.3.0-2.fc6 andreas.bierfert at lowlatency.de synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com tidy-0.99.0-10.20051025.fc6 rdieter at math.unl.edu tpb-0.6.4-4.fc6 kevin-redhat-bugzilla at tummy.com uqm-0.5.0-1.fc5 icon at fedoraproject.org wesnoth-1.0.2-3.fc6 bdpepple at ameritech.net WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wine-0.9.17-1.fc6 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xcompmgr-1.1.3-4.fc6 dakingun at gmail.com xpa-2.1.6-5.fc6 spr at astrax.fis.ucm.es xpilot-ng-4.7.2-9.fc6 wart at kobold.org xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com xsp-1.1.15-6.fc6 paul at all-the-johnsons.co.uk xsupplicant-1.2.6-1.fc6 tcallawa at redhat.com yasm-0.5.0-1.fc6 matthias at rpmforge.net z88dk-1.6-8.fc5 paul at all-the-johnsons.co.uk With bugs filed: 20 ---------------------------------- alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com ccrtp-1.3.7-1.fc6 ['197362 NEW'] andreas at bawue.net cowbell-0.2.7.1-2.fc6 ['197366 CLOSED'] foolish at guezz.net dillo-0.8.6-2.fc6 ['197370 CLOSED'] andreas.bierfert at lowlatency.de drgeo-1.1.0-10.fc6 ['197614 CLOSED'] eric.tanguy at univ-nantes.fr erlang-R11B-0.2.fc6 ['197696 CLOSED'] gemi at bluewin.ch fish-1.12.0-1.fc5 ['179296 NEW'] oliver at linux-kernel.at flow-tools-0.68-10.fc6 ['197706 NEW'] i at stingr.net gdesklets-0.35.3-8.fc6 ['197799 NEW'] luya256 at yahoo.com gnomad2-2.8.6-1.fc6 ['197920 NEW'] triad at df.lth.se gnome-applet-music-0.9.0-1.fc6 ['197924 NEW'] ivazquez at ivazquez.net gnome-schedule-1.0.0-1 ['197927 NEW'] frank at scirocco-5v-turbo.de grads-1.9b4-12.fc6 ['197942 CLOSED'] pertusus at free.fr grhino-0.15.0-5.fc5 ['197950 NEW'] michel.salim at gmail.com gtktalog-1.0.4-7.fc5 ['198897 NEW'] matthias at rpmforge.net jam-2.5-3.fc5 ['198924 NEW'] tcallawa at redhat.com nco-3.1.2-1.fc6 ['193541 NEW'] ed at eh3.com xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jkeating at redhat.com Sat Jul 22 14:28:20 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Jul 2006 10:28:20 -0400 Subject: FE devel rebuild? In-Reply-To: <44C1240E.2070307@leemhuis.info> References: <20060721184012.GD16006@neu.nirvana> <44C1240E.2070307@leemhuis.info> Message-ID: <200607221028.20182.jkeating@redhat.com> On Friday 21 July 2006 14:59, Thorsten Leemhuis wrote: > But yes, a script like the one Hans asked for might be helpful. f13 > probably has one ;-) It doesn't work all that well. It could use replacing. You basically need something that reads in the spec, figures out what int to bump (pre or post %{?dist} tag, or somewhere else), adds a coherent changelog entry, then does the simple commit -m 'bump' && make tag 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 wart at kobold.org Sat Jul 22 19:24:06 2006 From: wart at kobold.org (Wart) Date: Sat, 22 Jul 2006 12:24:06 -0700 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <20060722135834.GD9662@lists.us.dell.com> References: <20060722135834.GD9662@lists.us.dell.com> Message-ID: <44C27B56.4020801@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Domsch wrote: > I'm Bcc'ing everyone whose email shows up for a package below this > time, as the time for manditory package fixing is drawing near, per > the note to fedora-maintainers. If you haven't looked at your > packages in a while, and they fail to build in the reduced chroot, now > would be a good time to take a look. > Thanks, > Matt > > xpilot-ng-4.7.2-9.fc6 wart at kobold.org The build logs for this are empty? - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEwntTDeYlPfs40g8RAq9lAJ0Zd+Pb3QfharyZOdIAju/MwPNGZQCfQ8fE se0BtSHbMlHFAFhdMs7F2kM= =EYdP -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Sat Jul 22 19:39:11 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 22 Jul 2006 21:39:11 +0200 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <44C27B56.4020801@kobold.org> References: <20060722135834.GD9662@lists.us.dell.com> <44C27B56.4020801@kobold.org> Message-ID: <44C27EDF.8090003@hhs.nl> Wart wrote: > Matt Domsch wrote: >>> I'm Bcc'ing everyone whose email shows up for a package below this >>> time, as the time for manditory package fixing is drawing near, per >>> the note to fedora-maintainers. If you haven't looked at your >>> packages in a while, and they fail to build in the reduced chroot, now >>> would be a good time to take a look. >>> Thanks, >>> Matt >>> > >>> xpilot-ng-4.7.2-9.fc6 wart at kobold.org > > The build logs for this are empty? > so are they for all my packages with reported build failures, most of which have been build successfully very very recently. Regards, Hans From Matt_Domsch at dell.com Sat Jul 22 19:42:07 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 22 Jul 2006 14:42:07 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <44C27B56.4020801@kobold.org> References: <20060722135834.GD9662@lists.us.dell.com> <44C27B56.4020801@kobold.org> Message-ID: <20060722194207.GE9662@lists.us.dell.com> On Sat, Jul 22, 2006 at 12:24:06PM -0700, Wart wrote: > > xpilot-ng-4.7.2-9.fc6 wart at kobold.org > > The build logs for this are empty? One of the builders lost its NIS groups file, so mock failed on several packages through no fault of the package. I need to handle this failure mode better I see. I'm restarting the build, which should clear that up. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From buildsys at fedoraproject.org Sat Jul 22 21:58:38 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 22 Jul 2006 17:58:38 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-22 Message-ID: <20060722215838.7FC05152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 34 aspell-mi-0.50-2.fc5 blender-2.42-4.fc5 chrpath-0.13-1.fc5 cpanspec-1.68-1.fc5 fluidsynth-1.0.7-5.a.fc5 gpsd-2.33-1.fc5 gtkwave-3.0.7-1.fc5 ipe-6.0-0.9.pre26.fc5 kdemultimedia-extras-3.5.3-2.fc5 kdetoys-3.5.3-1.fc5 kdissert-1.0.6-1.fc5 kmobiletools-0.4.3.3-2.fc5 libhugetlbfs-0.20060706-1.fc5.1 libsigsegv-2.4-1.fc5 mod_nss-1.0.3-1.fc5 nas-1.8-7.fc5 oddjob-0.27-4 perl-Email-Address-1.86-1.fc5 perl-Expect-1.20-1.fc5 perl-IO-Tty-1.07-1.fc5 perl-Log-Log4perl-1.06-1.fc5 perl-PAR-Dist-0.11-1.fc5 perl-POE-Component-IRC-4.96-3.fc5 perl-Statistics-Descriptive-2.6-1.fc5 perl-Test-Pod-1.26-1.fc5 perl-eperl-2.2.14-2.fc5 perltidy-20060719-1.fc5 python-paste-0.9.3-4.fc5 python-setuptools-0.6c1-1.fc5 qt4-4.1.4-7.fc5 qt4-4.1.4-8.fc5 sextractor-2.5.0-2.fc5 tetex-IEEEtran-1.6c-3.fc5 xmoto-0.1.16-1.fc5 Packages built and released for Fedora Extras 4: 29 chrpath-0.13-1.fc4 cpanspec-1.68-1.fc4 dssi-0.9.1-7.fc4 fluidsynth-1.0.7-5.a.fc4 gpsd-2.33-2.fc4 gtkwave-3.0.7-1.fc4 hexter-dssi-0.5.9-4.fc4 ipe-6.0-0.9.pre26.fc4 kdemultimedia-extras-3.5.3-2.fc4 kdetoys-3.5.3-1.fc4 kdissert-1.0.6-1.fc4 kmobiletools-0.4.3.3-2.fc4 lash-0.5.1-6.fc4 liblo-0.23-6.fc4 liblrdf-0.4.0-7.fc4 libsigsegv-2.4-1.fc4 nas-1.8-7.fc4 oddjob-0.27-3 perl-Email-Address-1.86-1.fc4 perl-File-RsyncP-0.62-2.fc4 perl-IO-Tty-1.07-1.fc4 perl-Log-Log4perl-1.06-1.fc4 perl-eperl-2.2.14-2.fc4 python-setuptools-0.6c1-1.fc4 rosegarden4-1.2.3-3.fc4 sextractor-2.5.0-2.fc4 swh-plugins-0.4.14-6.fc4 tetex-IEEEtran-1.6c-3.fc4 xmoto-0.1.16-1.fc4 Packages built and released for Fedora Extras 3: 2 libsigsegv-2.4-1.fc3 oddjob-0.27-1 Packages built and released for Fedora Extras development: 52 NetworkManager-vpnc-0.7.0-0.cvs20060529.1.fc6 ORBit-0.5.17-18.fc6 akode-2.0-1.fc6.2 aspell-mi-0.50-2.fc6 audacious-1.1.0-1.fc6 blender-2.42-4.fc6 chrpath-0.13-1.fc6 cpanspec-1.68-1.fc6 dap-freeform_handler-3.7.1-2.fc6 dap-netcdf_handler-3.7.1-1.fc6 dnsmasq-2.32-2.fc6 dnsmasq-2.32-3.fc6 geomview-1.8.2-0.10.rc3.fc6 gpsd-2.33-3.fc6 grads-1.9b4-14.fc6 gtkwave-3.0.7-1.fc6 ipe-6.0-0.9.pre26.fc6 kdemultimedia-extras-3.5.3-2.fc6 kdetoys-3.5.3-1.fc6 kmobiletools-0.4.3.3-2.fc6 libapreq2-2.08-0.rc4.1.fc6 libchmxx-0.1-4.fc6 libdap-3.7.0-1.fc6 libhugetlbfs-0.20060706-2.fc6 libnc-dap-3.6.0-4.fc6 libsigsegv-2.4-1.fc6 lucidlife-0.9-10.fc6 mod_nss-1.0.3-1.fc6 monotone-0.27-1.fc6 nas-1.8-7.fc6 nuttcp-5.3.1-1 oddjob-0.27-5 perl-Email-Address-1.86-1.fc6 perl-Email-Simple-1.95-1.fc6 perl-Expect-1.20-1.fc6 perl-File-RsyncP-0.62-2.fc6 perl-IO-Tty-1.07-1.fc6 perl-Log-Log4perl-1.06-1.fc6 perl-PAR-Dist-0.11-1.fc6 perl-POE-Component-IRC-4.96-3.fc6 perl-Test-Pod-1.26-1.fc6 perltidy-20060719-1.fc6 python-setuptools-0.6c1-1.fc6 qt4-4.1.4-7.fc6 qt4-4.1.4-8.fc6 rt3-3.6.0-4.fc6 sextractor-2.5.0-2.fc6 sturmbahnfahrer-1.1-2.fc6 tetex-IEEEtran-1.6c-3.fc6 varconf-0.6.4-3.fc6 xchm-1.9-1.fc6 xmoto-0.1.16-1.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Jul 22 21:59:03 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 22 Jul 2006 17:59:03 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-22 Message-ID: <20060722215903.6AFB3152160@buildsys.fedoraproject.org> abiword: 5: 1:2.4.5-2.fc5 (FE5) 6: 1:2.4.5-1.fc6 (FE6) azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) ecl: 4: 0:0.9i-1.1.fc4 (FE4) 5: 0:0.9i-1.fc5 (FE5) 6: 0:0.9i-1.fc6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gpsd: 4: 0:2.33-2.fc4 (FE4) 5: 0:2.33-1.fc5 (FE5) 6: 0:2.33-3.fc6 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) kdissert: 5: 0:1.0.6-1.fc5 (FE5) 6: 0:1.0.5-1.1.fc5 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2.1 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-13.fc6 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) quagga: 4: 0:0.98.6-1.fc4 (FC4-updates) 5: 0:0.98.6-1.FC5 (FC5-updates) 6: 0:0.98.6-2.1 (FC6) rsnapshot: 4: 0:1.2.9-4.fc4 (FE4) 5: 0:1.2.9-2.fc5 (FE5) 6: 0:1.2.9-2.fc6 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) wordpress: 4: 0:2.0.3-4.fc4 (FE4) 5: 0:2.0.3-3.fc5 (FE5) 6: 0:2.0.3-3.fc6 (FE6) From mr.ecik at gmail.com Sat Jul 22 22:43:31 2006 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 23 Jul 2006 00:43:31 +0200 Subject: Question about WTFPL Message-ID: <668bb39a0607221543l683dd7b1x4a682f7890c63861@mail.gmail.com> Hi! User Ian Chapman on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199611 placed a review request to package with WTFPL license. And my question is simple: is it permissible in Extras? More information about it is here: http://sam.zoy.org/wtfpl/ From peter at thecodergeek.com Sat Jul 22 22:48:34 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 22 Jul 2006 15:48:34 -0700 Subject: Question about WTFPL In-Reply-To: <668bb39a0607221543l683dd7b1x4a682f7890c63861@mail.gmail.com> References: <668bb39a0607221543l683dd7b1x4a682f7890c63861@mail.gmail.com> Message-ID: <44C2AB42.2070507@thecodergeek.com> ? wrote: > Hi! > User Ian Chapman on > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199611 placed a > review request to package with WTFPL license. And my question is > simple: is it permissible in Extras? > More information about it is here: http://sam.zoy.org/wtfpl/ > Well, Bradley Kuhn of the FSF agreed (and laughed) on debian-legal at one point that this is in fact a valid Free Software license [1], so I'd say it's probably okay to submit to Extras. [1] http://lists.debian.org/debian-legal/2002/09/msg00032.html -- 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: 251 bytes Desc: OpenPGP digital signature URL: From peter at thecodergeek.com Sat Jul 22 22:57:58 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 22 Jul 2006 15:57:58 -0700 Subject: Question about WTFPL In-Reply-To: <44C2AB42.2070507@thecodergeek.com> References: <668bb39a0607221543l683dd7b1x4a682f7890c63861@mail.gmail.com> <44C2AB42.2070507@thecodergeek.com> Message-ID: <44C2AD76.7050102@thecodergeek.com> Peter Gordon wrote: > Well, Bradley Kuhn of the FSF agreed (and laughed) on debian-legal at > one point that this is in fact a valid Free Software license [1], so I'd > say it's probably okay to submit to Extras. > > [1] http://lists.debian.org/debian-legal/2002/09/msg00032.html > Correction: He was mentioned as such, but was not the one to post it to debian-legal. Sorry for any misunderstandings. -- 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: 251 bytes Desc: OpenPGP digital signature URL: From mr.ecik at gmail.com Sat Jul 22 23:12:10 2006 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 23 Jul 2006 01:12:10 +0200 Subject: Question about WAV Message-ID: <668bb39a0607221612g6e6a2d26o4c7ad54a27397bf8@mail.gmail.com> Another question connected with monsterz package (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199611). It uses .wav sound files. Packaging Guidelines says that content mustn't be patented, and the question is: is wave files patented? From skvidal at linux.duke.edu Sat Jul 22 23:13:36 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 22 Jul 2006 19:13:36 -0400 Subject: Question about WTFPL In-Reply-To: <668bb39a0607221543l683dd7b1x4a682f7890c63861@mail.gmail.com> References: <668bb39a0607221543l683dd7b1x4a682f7890c63861@mail.gmail.com> Message-ID: <1153610016.13330.9.camel@cutter> On Sun, 2006-07-23 at 00:43 +0200, Micha? Bentkowski wrote: > Hi! > User Ian Chapman on > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199611 placed a > review request to package with WTFPL license. And my question is > simple: is it permissible in Extras? > More information about it is here: http://sam.zoy.org/wtfpl/ I've forwarded this to the fedora legal contact. Thanks, -sv From rdieter at math.unl.edu Sat Jul 22 23:28:40 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 22 Jul 2006 18:28:40 -0500 Subject: Question about WAV In-Reply-To: <668bb39a0607221612g6e6a2d26o4c7ad54a27397bf8@mail.gmail.com> References: <668bb39a0607221612g6e6a2d26o4c7ad54a27397bf8@mail.gmail.com> Message-ID: Micha? Bentkowski wrote: > Another question connected with monsterz package > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199611). It uses > .wav sound files. Packaging Guidelines says that content mustn't be > patented, and the question is: is wave files patented? afaik, no. -- Rex From nman64 at n-man.com Sun Jul 23 00:06:18 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sat, 22 Jul 2006 19:06:18 -0500 Subject: Question about WAV In-Reply-To: References: <668bb39a0607221612g6e6a2d26o4c7ad54a27397bf8@mail.gmail.com> Message-ID: <200607221906.21126.nman64@n-man.com> On Saturday 22 July 2006 18:28, Rex Dieter wrote: > Micha? Bentkowski wrote: > > Another question connected with monsterz package > > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199611). It uses > > .wav sound files. Packaging Guidelines says that content mustn't be > > patented, and the question is: is wave files patented? > > afaik, no. > Even if there were patents on the format, they would have already expired. Keep in mind that this is actually a container format, and codecs used to prepare audio data could potentially be patented. The codecs most often used are, like the container format, old enough that any patents would have expired. As long as the program isn't using anything obscure, you should be safe from any legal issues with this format. Note that the format is widely supported in other Fedora Core and Fedora Extras packages. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Sun Jul 23 02:46:50 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 23 Jul 2006 04:46:50 +0200 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <20060722135834.GD9662@lists.us.dell.com> References: <20060722135834.GD9662@lists.us.dell.com> Message-ID: <1153622810.5125.8.camel@mccallum.corsepiu.local> On Sat, 2006-07-22 at 08:58 -0500, Matt Domsch wrote: > I'm Bcc'ing everyone whose email shows up for a package below this > time, as the time for manditory package fixing is drawing near, per > the note to fedora-maintainers. If you haven't looked at your > packages in a while, and they fail to build in the reduced chroot, now > would be a good time to take a look. > Thanks, > Matt > > Extras Rawhide-in-Mock Build Results for x86_64 Sat Jul 22 02:21:07 CDT 2006 > > Note: This is using a reduced set of packages in the build chroot as > compared to the standard Fedora Extras build system before FC6test1. See > http://fedoraproject.org/wiki/QA/FixBuildRequires for more > information, including the list of packages removed from the > default build chroot. > perl-File-Flat-0.96-2.fc6 rc040203 at freenet.de Looks like a false positive to me. I can't spot any failure. > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Ralf From rc040203 at freenet.de Sun Jul 23 03:03:02 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 23 Jul 2006 05:03:02 +0200 Subject: rpms/sextractor/FC-4 sextractor.spec,1.2,1.3 In-Reply-To: <1153571226.30083.31.camel@laurel.intra.city-fan.org> References: <200607211724.k6LHO3Z8023012@cvs-int.fedora.redhat.com> <1153508980.18981.125.camel@mccallum.corsepiu.local> <1153537475.18981.150.camel@mccallum.corsepiu.local> <1153571226.30083.31.camel@laurel.intra.city-fan.org> Message-ID: <1153623782.5125.13.camel@mccallum.corsepiu.local> On Sat, 2006-07-22 at 13:27 +0100, Paul Howarth wrote: > On Sat, 2006-07-22 at 05:04 +0200, Ralf Corsepius wrote: > > On Fri, 2006-07-21 at 15:12 -0500, Jason L Tibbitts III wrote: > > > My apologies; I'm resending this because I mistyped the address of the > > > SExtractor maintainer. > > > > > > >>>>> "RC" == Ralf Corsepius writes: > > > > > > RC> On Fri, 2006-07-21 at 10:24 -0700, Sergio Pascual wrote: > > > >> %build -%configure +%configure CFLAGS="${CFLAGS} -funroll-loops > > > >> -fomit-frame-pointer -O1 > > > RC> REVERT this change IMMEDIATELY. > > > > > > RC> You are breaking debug infos. > > > > > > Yes, this is not good. > > During a review, this would be a BLOCKER and would cause a package not > > to be accepted. > > > > I am not willing to let maintainers get away with such stuff > > post-review. > > > > > For reference, the bug which prompted this is > > > here: > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199700 > > > > > > The problem is that the code simply does not function with the default > > > Fedora optimization flags. I am not familiar with the software and > > > have no idea whether this points to a GCC problem or just poorly > > > written code. Someone should investigate the minimum change to the > > > stock Fedora cflags which permit this software to work properly, and > > > then investigate why the behavior differs. > > > > > > Is there a standard method for overriding a single flag in > > > %{optflags}? > > > > The way he does it is the way how things are supposed to work. > > A similar approach is used is openais: > (http://cvs.fedora.redhat.com/viewcvs/devel/openais/openais.spec?view=markup) > > # -O3 required for performance reasons > CFLAGS="$(echo '%{optflags}' | sed -e 's/-O[0-9]*//') -O3" > make CFLAGS="$CFLAGS" Bummer. This is even worse. Again, the way this package's maintainer set CFLAGS is OK, but what he does is embarrassing. Seems as if he doesn't know what he is doing. I am going to file a request to packaging committee to ban -O3 and -fomit-frame-pointer Ralf From j.w.r.degoede at hhs.nl Sun Jul 23 06:56:20 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 23 Jul 2006 08:56:20 +0200 Subject: Question about WTFPL In-Reply-To: <1153610016.13330.9.camel@cutter> References: <668bb39a0607221543l683dd7b1x4a682f7890c63861@mail.gmail.com> <1153610016.13330.9.camel@cutter> Message-ID: <44C31D94.9070805@hhs.nl> seth vidal wrote: > On Sun, 2006-07-23 at 00:43 +0200, Micha? Bentkowski wrote: >> Hi! >> User Ian Chapman on >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199611 placed a >> review request to package with WTFPL license. And my question is >> simple: is it permissible in Extras? >> More information about it is here: http://sam.zoy.org/wtfpl/ > > > I've forwarded this to the fedora legal contact. > Why? Licenses don't get much free-er then this, I thought we only needed to contact legal if we had questions about a license? Thanks & Regards, Hans From Axel.Thimm at ATrpms.net Sun Jul 23 10:23:46 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Jul 2006 12:23:46 +0200 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <20060722135834.GD9662@lists.us.dell.com> References: <20060722135834.GD9662@lists.us.dell.com> Message-ID: <20060723102346.GA17325@neu.nirvana> On Sat, Jul 22, 2006 at 08:58:34AM -0500, Matt Domsch wrote: > I'm Bcc'ing everyone whose email shows up for a package below this > time, as the time for manditory package fixing is drawing near, per > the note to fedora-maintainers. If you haven't looked at your > packages in a while, and they fail to build in the reduced chroot, now > would be a good time to take a look. > Number failed to build: 175 > Number expected to fail due to ExclusiveArch or ExcludeArch: 2 > Leaving: 173 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 153 > ---------------------------------- > [...] > chrpath-0.13-1.fc6 Axel.Thimm at ATrpms.net > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ I checked your logs but can't find what is wrong with this package (it seems to build and the status is "done"), could you point me to its issue? 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 buildsys at fedoraproject.org Sun Jul 23 11:14:28 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 23 Jul 2006 07:14:28 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-23 Message-ID: <20060723111428.3EA07152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 12 aalib-1.4.0-0.8.rc5.fc5 em8300-0.15.3-4.fc5 em8300-kmod-0.15.3-6.2.6.17_1.2157_FC5 imlib2-1.2.1-6.fc5 libcddb-1.2.1-3.fc5 libmatroska-0.8.0-3.fc5 obconf-1.6-2.fc5 perl-PAR-Dist-0.14-1.fc5 python-mutagen-1.5.1-5.fc5 qjackctl-0.2.20-5.fc5 scim-skk-0.5.2-7.fc5 sturmbahnfahrer-1.1-2.fc5 Packages built and released for Fedora Extras 4: 2 obconf-1.6-2.fc4.1 scim-skk-0.5.2-7.fc4 Packages built and released for Fedora Extras 3: 1 scim-skk-0.5.2-7.fc3 Packages built and released for Fedora Extras development: 12 aalib-1.4.0-0.8.rc5.fc6 abiword-2.4.5-2.fc6 gossip-0.11.2-4.fc6 imlib2-1.2.2-1.fc6 kchmviewer-2.6-1.fc6 libcddb-1.2.1-3.fc6 libmatroska-0.8.0-3.fc6 liferea-1.0.16-4.fc6 metamonitor-0.4.5-2.fc6 perl-PAR-Dist-0.14-1.fc6 python-mutagen-1.5.1-5.fc6 scim-skk-0.5.2-7.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Jul 23 11:14:52 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 23 Jul 2006 07:14:52 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-23 Message-ID: <20060723111452.A2FB3152160@buildsys.fedoraproject.org> azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) ecl: 4: 0:0.9i-1.1.fc4 (FE4) 5: 0:0.9i-1.fc5 (FE5) 6: 0:0.9i-1.fc6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) gnomad2: 3: 0:2.8.6-2.fc3 (FE3) 4: 0:2.8.6-1.fc4 (FE4) 5: 0:2.8.5-1.fc5 (FE5) 6: 0:2.8.6-1.fc6 (FE6) gpsd: 4: 0:2.33-2.fc4 (FE4) 5: 0:2.33-1.fc5 (FE5) 6: 0:2.33-3.fc6 (FE6) Hermes: 4: 0:1.3.3-9.fc4 (FE4) 5: 0:1.3.3-7 (FE5) 6: 0:1.3.3-7 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) kdissert: 5: 0:1.0.6-1.fc5 (FE5) 6: 0:1.0.5-1.1.fc5 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2.1 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-13.fc6 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) quagga: 4: 0:0.98.6-1.fc4 (FC4-updates) 5: 0:0.98.6-1.FC5 (FC5-updates) 6: 0:0.98.6-2.1 (FC6) rsnapshot: 4: 0:1.2.9-4.fc4 (FE4) 5: 0:1.2.9-2.fc5 (FE5) 6: 0:1.2.9-2.fc6 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) wordpress: 4: 0:2.0.3-4.fc4 (FE4) 5: 0:2.0.3-3.fc5 (FE5) 6: 0:2.0.3-3.fc6 (FE6) From buildsys at fedoraproject.org Sun Jul 23 11:32:22 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 23 Jul 2006 11:32:22 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-23 Message-ID: <20060723113222.17202.697@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- ivazquez AT ivazquez.net wp_tray - 0.5.1-1.fc4.i386 (26 days) wp_tray - 0.5.1-1.fc4.ppc (26 days) wp_tray - 0.5.1-1.fc4.x86_64 (26 days) lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 (8 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc (8 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 (8 days) Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.i386 requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.ppc requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.ppc requires libatkmm-1.6.so.1 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.x86_64 requires python-protocols >= 0:1.0 wp_tray-0.5.1-1.fc4.x86_64 requires libatkmm-1.6.so.1()(64bit) From buildsys at fedoraproject.org Sun Jul 23 11:32:22 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 23 Jul 2006 11:32:22 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-23 Message-ID: <20060723113222.17204.30747@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 (8 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc (8 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 (8 days) mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 (4 days) libvisual-plugins - 0.2.0-3.fc5.ppc (4 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (4 days) oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (67 days) syck-php - 0.55-7.fc5.ppc (67 days) syck-php - 0.55-7.fc5.x86_64 (67 days) Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.i386 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.ppc requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc5.x86_64 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From buildsys at fedoraproject.org Sun Jul 23 11:32:22 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 23 Jul 2006 11:32:22 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-23 Message-ID: <20060723113222.17193.36370@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 (108 days) fluxbox - 0.9.15.1-1.fc3.x86_64 (108 days) Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Sun Jul 23 11:32:22 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 23 Jul 2006 11:32:22 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-23 Message-ID: <20060723113222.17206.47352@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- bdpepple AT ameritech.net galago-daemon - 0.5.0-3.fc6.i386 (3 days) galago-daemon - 0.5.0-3.fc6.ppc (3 days) galago-daemon - 0.5.0-3.fc6.x86_64 (3 days) libgalago - 0.5.1-4.fc6.i386 (3 days) libgalago - 0.5.1-4.fc6.ppc (3 days) libgalago - 0.5.1-4.fc6.x86_64 (3 days) xchat-gnome - 0.12-2.fc6.i386 (3 days) xchat-gnome - 0.12-2.fc6.ppc (3 days) xchat-gnome - 0.12-2.fc6.x86_64 (3 days) byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 (4 days) gaim-guifications - 2.12-3.fc5.ppc (4 days) gaim-guifications - 2.12-3.fc5.x86_64 (4 days) caillon AT redhat.com banshee - 0.10.8-1.i386 (4 days) banshee - 0.10.8-1.ppc (4 days) banshee - 0.10.8-1.x86_64 (4 days) libipoddevice - 0.4.5-1.fc6.i386 (3 days) libipoddevice - 0.4.5-1.fc6.ppc (3 days) libipoddevice - 0.4.5-1.fc6.x86_64 (3 days) cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 (4 days) gaim-gaym - 0.96-2.fc6.ppc (4 days) gaim-gaym - 0.96-2.fc6.x86_64 (4 days) dennis AT ausil.us knetworkmanager - 0.1-0.3.svn20060625.fc6.i386 (3 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.ppc (3 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.x86_64 (3 days) fedora AT leemhuis.info gsynaptics - 0.9.8-1.fc6.ppc (4 days) green AT redhat.com jogl - 1.1.1-14.fc5.i386 jogl - 1.1.1-14.fc5.ppc ivazquez AT ivazquez.net gnome-applet-music - 0.9.0-1.fc6.i386 (4 days) gnome-applet-music - 0.9.0-1.fc6.ppc (4 days) gnome-applet-music - 0.9.0-1.fc6.x86_64 (4 days) nautilus-search-tool - 0.2-1.fc5.i386 (4 days) nautilus-search-tool - 0.2-1.fc5.ppc (4 days) nautilus-search-tool - 0.2-1.fc5.x86_64 (4 days) matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 (4 days) diradmin - 1.7.1-4.fc5.ppc (4 days) diradmin - 1.7.1-4.fc5.x86_64 (4 days) gtktalog - 1.0.4-7.fc5.i386 (4 days) gtktalog - 1.0.4-7.fc5.ppc (4 days) gtktalog - 1.0.4-7.fc5.x86_64 (4 days) michael AT knox.net.nz screem - 0.16.1-1.fc6.i386 (3 days) screem - 0.16.1-1.fc6.ppc (3 days) screem - 0.16.1-1.fc6.x86_64 (3 days) mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 (4 days) gfontview - 0.5.0-5.fc5.ppc (4 days) gfontview - 0.5.0-5.fc5.x86_64 (4 days) gtkhtml36 - 3.6.2-5.fc6.i386 (4 days) gtkhtml36 - 3.6.2-5.fc6.ppc (4 days) gtkhtml36 - 3.6.2-5.fc6.x86_64 (4 days) libvisual-plugins - 0.2.0-3.fc5.i386 (4 days) libvisual-plugins - 0.2.0-3.fc5.ppc (4 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (4 days) oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (4 days) syck-php - 0.55-7.fc5.ppc (4 days) syck-php - 0.55-7.fc5.x86_64 (4 days) pertusus AT free.fr cernlib - 2005-21.fc6.ppc (4 days) cernlib-packlib - 2005-21.fc6.ppc (4 days) dap-hdf4_handler - 3.6.0-3.fc5.i386 dap-hdf4_handler - 3.6.0-3.fc5.ppc dap-hdf4_handler - 3.6.0-3.fc5.x86_64 dap-server - 3.6.1-2.fc6.i386 dap-server - 3.6.1-2.fc6.ppc dap-server - 3.6.1-2.fc6.x86_64 patchy - 2005-21.fc6.ppc (4 days) paw - 2005-21.fc6.ppc (4 days) qspencer AT ieee.org octave-forge - 2006.07.09-2.fc6.i386 octave-forge - 2006.07.09-2.fc6.ppc octave-forge - 2006.07.09-2.fc6.x86_64 rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 (4 days) libibverbs - 1.0.3-1.fc6.ppc (4 days) libibverbs - 1.0.3-1.fc6.x86_64 (4 days) libibverbs-utils - 1.0.3-1.fc6.i386 (4 days) libibverbs-utils - 1.0.3-1.fc6.ppc (4 days) libibverbs-utils - 1.0.3-1.fc6.x86_64 (4 days) thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 (4 days) directfb - 0.9.24-5.fc5.ppc (4 days) directfb - 0.9.24-5.fc5.x86_64 (4 days) Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 banshee-0.10.8-1.i386 requires libdbus-1.so.2 dap-hdf4_handler-3.6.0-3.fc5.i386 requires libdap.so.4 dap-server-3.6.1-2.fc6.i386 requires libdap.so.4 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 galago-daemon-0.5.0-3.fc6.i386 requires libdbus-1.so.2 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.i386 requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.i386 requires libdbus-1.so.2 gtkhtml36-3.6.2-5.fc6.i386 requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 jogl-1.1.1-14.fc5.i386 requires libjawt.so knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-qt-1.so.1 libgalago-0.5.1-4.fc6.i386 requires libdbus-1.so.2 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.i386 requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.i386 requires libgailutil.so.17 octave-forge-2006.07.09-2.fc6.i386 requires libdap.so.4 screem-0.16.1-1.fc6.i386 requires libdbus-1.so.2 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 xchat-gnome-0.12-2.fc6.i386 requires libdbus-1.so.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 banshee-0.10.8-1.ppc requires libdbus-1.so.2 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 dap-hdf4_handler-3.6.0-3.fc5.ppc requires libdap.so.4 dap-server-3.6.1-2.fc6.ppc requires libdap.so.4 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 galago-daemon-0.5.0-3.fc6.ppc requires libdbus-1.so.2 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.ppc requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.ppc requires libdbus-1.so.2 gsynaptics-0.9.8-1.fc6.ppc requires synaptics gtkhtml36-3.6.2-5.fc6.ppc requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 jogl-1.1.1-14.fc5.ppc requires libjawt.so knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-qt-1.so.1 libgalago-0.5.1-4.fc6.ppc requires libdbus-1.so.2 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.ppc requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.ppc requires libgailutil.so.17 octave-forge-2006.07.09-2.fc6.ppc requires libdap.so.4 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 screem-0.16.1-1.fc6.ppc requires libdbus-1.so.2 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 xchat-gnome-0.12-2.fc6.ppc requires libdbus-1.so.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) banshee-0.10.8-1.x86_64 requires libdbus-1.so.2()(64bit) dap-hdf4_handler-3.6.0-3.fc5.x86_64 requires libdap.so.4()(64bit) dap-server-3.6.1-2.fc6.x86_64 requires libdap.so.4()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 galago-daemon-0.5.0-3.fc6.x86_64 requires libdbus-1.so.2()(64bit) gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libgailutil.so.17()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) gtkhtml36-3.6.2-5.fc6.x86_64 requires libgailutil.so.17()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-qt-1.so.1()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-1.so.2()(64bit) libgalago-0.5.1-4.fc6.x86_64 requires libdbus-1.so.2()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libipoddevice-0.4.5-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) nautilus-search-tool-0.2-1.fc5.x86_64 requires libgailutil.so.17()(64bit) octave-forge-2006.07.09-2.fc6.x86_64 requires libdap.so.4()(64bit) screem-0.16.1-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 xchat-gnome-0.12-2.fc6.x86_64 requires libdbus-1.so.2()(64bit) ====================================================================== New report for: pertusus AT free.fr package: dap-server - 3.6.1-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdap.so.4 package: dap-hdf4_handler - 3.6.0-3.fc5.i386 from fedora-extras-development-i386 unresolved deps: libdap.so.4 package: dap-hdf4_handler - 3.6.0-3.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdap.so.4()(64bit) package: dap-server - 3.6.1-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdap.so.4()(64bit) package: dap-hdf4_handler - 3.6.0-3.fc5.ppc from fedora-extras-development-ppc unresolved deps: libdap.so.4 package: dap-server - 3.6.1-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdap.so.4 ====================================================================== New report for: green AT redhat.com package: jogl - 1.1.1-14.fc5.i386 from fedora-extras-development-i386 unresolved deps: libjawt.so package: jogl - 1.1.1-14.fc5.ppc from fedora-extras-development-ppc unresolved deps: libjawt.so ====================================================================== New report for: qspencer AT ieee.org package: octave-forge - 2006.07.09-2.fc6.i386 from fedora-extras-development-i386 unresolved deps: libdap.so.4 package: octave-forge - 2006.07.09-2.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libdap.so.4()(64bit) package: octave-forge - 2006.07.09-2.fc6.ppc from fedora-extras-development-ppc unresolved deps: libdap.so.4 From dwmw2 at infradead.org Sun Jul 23 12:15:18 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 23 Jul 2006 08:15:18 -0400 Subject: Cross-compilers. Message-ID: <1153656919.29989.74.camel@shinybook.infradead.org> How much interest would there be in getting a bunch of cross-compilers into Extras? Stuff like crosstool makes it relatively simple, but it's still slow -- I'd really like to be able to easily and quickly install cross-compiler packages for random architectures like ARM, MIPS, i386, etc. I'd like to ship a multi-arch capable binutils like Debian's 'binutils-multi' and a set of cross-compilers -- preferably the same versions of each as the one in Core. It'd be particularly nice if we could install native -devel packages into each toolchain's sysroot -- we could avoid having to rebuild glibc etc. for architectures which are in rawhide, for example. But that isn't imperative. Does anyone else care? Other than the full set of rawhide architectures, what others would we include? Alpha, SPARC{64,}, ARM, MIPS, SH I assume? Would anyone volunteer to maintain each of those toolchains? I wouldn't really feel happy doing it myself, since when it comes to GCC I would only ever be a package-monkey, and not a proper _maintainer_. -- dwmw2 From michael at knox.net.nz Sun Jul 23 12:57:40 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 24 Jul 2006 00:57:40 +1200 Subject: Cross-compilers. In-Reply-To: <1153656919.29989.74.camel@shinybook.infradead.org> References: <1153656919.29989.74.camel@shinybook.infradead.org> Message-ID: <44C37244.9090406@knox.net.nz> I think some cross compilers would be a good idea. I already use arm regularly and will shortly have a need for nesC and some AVR cross tools. If they are candidates for extras, I don't know. I do now there was some discuss, which remains unresolved, as to the naming convention to use for cross tool chain packages. Michael David Woodhouse wrote: > How much interest would there be in getting a bunch of cross-compilers > into Extras? > > Stuff like crosstool makes it relatively simple, but it's still slow -- > I'd really like to be able to easily and quickly install cross-compiler > packages for random architectures like ARM, MIPS, i386, etc. > > I'd like to ship a multi-arch capable binutils like Debian's > 'binutils-multi' and a set of cross-compilers -- preferably the same > versions of each as the one in Core. > > It'd be particularly nice if we could install native -devel packages > into each toolchain's sysroot -- we could avoid having to rebuild glibc > etc. for architectures which are in rawhide, for example. But that isn't > imperative. > > Does anyone else care? Other than the full set of rawhide architectures, > what others would we include? Alpha, SPARC{64,}, ARM, MIPS, SH I assume? > Would anyone volunteer to maintain each of those toolchains? I wouldn't > really feel happy doing it myself, since when it comes to GCC I would > only ever be a package-monkey, and not a proper _maintainer_. > From stickster at gmail.com Sun Jul 23 13:04:40 2006 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 23 Jul 2006 09:04:40 -0400 Subject: Question about WTFPL In-Reply-To: <44C31D94.9070805@hhs.nl> References: <668bb39a0607221543l683dd7b1x4a682f7890c63861@mail.gmail.com> <1153610016.13330.9.camel@cutter> <44C31D94.9070805@hhs.nl> Message-ID: <1153659880.22412.96.camel@localhost.localdomain> On Sun, 2006-07-23 at 08:56 +0200, Hans de Goede wrote: > > seth vidal wrote: > > On Sun, 2006-07-23 at 00:43 +0200, Micha? Bentkowski wrote: > >> Hi! > >> User Ian Chapman on > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199611 placed a > >> review request to package with WTFPL license. And my question is > >> simple: is it permissible in Extras? > >> More information about it is here: http://sam.zoy.org/wtfpl/ > > > > > > I've forwarded this to the fedora legal contact. > > > > Why? Licenses don't get much free-er then this, I thought we only needed > to contact legal if we had questions about a license? Because the legal department needs a good chuckle every now and again. ;-) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Sun Jul 23 13:16:21 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 23 Jul 2006 09:16:21 -0400 Subject: Cross-compilers. In-Reply-To: <44C37244.9090406@knox.net.nz> References: <1153656919.29989.74.camel@shinybook.infradead.org> <44C37244.9090406@knox.net.nz> Message-ID: <1153660582.29989.91.camel@shinybook.infradead.org> On Mon, 2006-07-24 at 00:57 +1200, Michael J. Knox wrote: > I think some cross compilers would be a good idea. I already use arm > regularly and will shortly have a need for nesC and some AVR cross > tools. If they are candidates for extras, I don't know. I don't really see why not. > I do now there was some discuss, which remains unresolved, as to the > naming convention to use for cross tool chain packages. Does it matter? Far too much masturbation goes on around here. > David Woodhouse wrote: > > Stuff like crosstool makes it relatively simple, but it's still slow -- I take that back, btw -- I've been fighting crosstool for a while this morning and I still haven't managed to build a simple ppc->i686 crosscompiler. And I don't even want glibc -- I _only_ want to build kernels. Not that that seems to be an option. The whole incestuous gcc/libgcc/libc thing needs to be fixed up and made relatively sane -- but that's outside the scope of this discussion, I suppose. -- dwmw2 From mattdm at mattdm.org Sun Jul 23 13:29:43 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 23 Jul 2006 09:29:43 -0400 Subject: Cross-compilers. In-Reply-To: <1153656919.29989.74.camel@shinybook.infradead.org> References: <1153656919.29989.74.camel@shinybook.infradead.org> Message-ID: <20060723132942.GA12360@jadzia.bu.edu> On Sun, Jul 23, 2006 at 08:15:18AM -0400, David Woodhouse wrote: > How much interest would there be in getting a bunch of cross-compilers > into Extras? I would like to see MinGW + SDL. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From frank-buettner at gmx.net Sun Jul 23 13:31:55 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Sun, 23 Jul 2006 15:31:55 +0200 Subject: Cross-compilers. In-Reply-To: <1153660582.29989.91.camel@shinybook.infradead.org> References: <1153656919.29989.74.camel@shinybook.infradead.org> <44C37244.9090406@knox.net.nz> <1153660582.29989.91.camel@shinybook.infradead.org> Message-ID: <44C37A4B.10503@gmx.net> It is an really good idea to do this, but the problem is, that the targets are extreme different. So it must be extreme modular. Then it can be also used for build tool chains for embedded systems. And it can also be used to test compiling RPM packages for other systems like compile for EMT64 on an x86:) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature URL: From rc040203 at freenet.de Sun Jul 23 13:56:25 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 23 Jul 2006 15:56:25 +0200 Subject: Cross-compilers. In-Reply-To: <1153656919.29989.74.camel@shinybook.infradead.org> References: <1153656919.29989.74.camel@shinybook.infradead.org> Message-ID: <1153662985.22104.13.camel@mccallum.corsepiu.local> On Sun, 2006-07-23 at 08:15 -0400, David Woodhouse wrote: > How much interest would there be in getting a bunch of cross-compilers > into Extras? > > Stuff like crosstool makes it relatively simple, but it's still slow -- Crosstool doesn't support newlib based targets. > I'd really like to be able to easily and quickly install cross-compiler > packages for random architectures like ARM, MIPS, i386, etc. These are still linux/glibc based variants. > I'd like to ship a multi-arch capable binutils like Debian's > 'binutils-multi' and a set of cross-compilers -- preferably the same > versions of each as the one in Core. I am not a friend of this mult-targeted binutils. For a user, they are a PITA, because each and every tiny arch-specific bug-fix touches all arches and because RH's sources are not usable for other OSes. > It'd be particularly nice if we could install native -devel packages > into each toolchain's sysroot -- we could avoid having to rebuild glibc > etc. for architectures which are in rawhide, for example. But that isn't > imperative. glibc .. you are talking about linux. > Does anyone else care? Other than the full set of rawhide architectures, > what others would we include? Alpha, SPARC{64,}, ARM, MIPS, SH I assume? > Would anyone volunteer to maintain each of those toolchains? I wouldn't > really feel happy doing it myself, since when it comes to GCC I would > only ever be a package-monkey, and not a proper _maintainer_. I have ca. 15 cross compiler toolchains at hand. ca. 9 RTEMS toolchains, mingw, cygwin, different freebsds and solaris (Non distributable). I.e. probably exactly those cases you don't have. Ralf From fedora at leemhuis.info Sun Jul 23 14:00:49 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 23 Jul 2006 16:00:49 +0200 Subject: Cross-compilers. In-Reply-To: <44C37244.9090406@knox.net.nz> References: <1153656919.29989.74.camel@shinybook.infradead.org> <44C37244.9090406@knox.net.nz> Message-ID: <44C38111.3010209@leemhuis.info> Michael J. Knox schrieb: > David Woodhouse wrote: >> How much interest would there be in getting a bunch of >> cross-compilers into Extras? > I think some cross compilers would be a good idea. Agreed. FYI: The packaging committee currently has this on its schedule ( http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo ): cross compilation | JasonTibbitts | not urgent | Naming and proper file locations for cross compilers need to be worked out Help probably appreciated and will probably accelerate the process of getting rules in place. CU thl From dhowells at redhat.com Sun Jul 23 14:04:26 2006 From: dhowells at redhat.com (David Howells) Date: Sun, 23 Jul 2006 15:04:26 +0100 Subject: Cross-compilers. In-Reply-To: <1153656919.29989.74.camel@shinybook.infradead.org> References: <1153656919.29989.74.camel@shinybook.infradead.org> Message-ID: <17618.1153663466@warthog.cambridge.redhat.com> David Woodhouse wrote: > How much interest would there be in getting a bunch of cross-compilers > into Extras? RH has customers with their own embedded CPUs that we supply regular toolchain drops for. They might be interested in this. David From skvidal at linux.duke.edu Sun Jul 23 14:10:40 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 23 Jul 2006 10:10:40 -0400 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> Message-ID: <1153663841.13330.15.camel@cutter> On Sat, 2006-07-22 at 05:31 -0700, Michael Schwendt wrote: > Author: mschwendt > > Update of /cvs/extras/rpms/seahorse/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26556/seahorse/devel > > Modified Files: > seahorse.spec > Log Message: > replace bad %{dist} usage with %{?dist} Michael, Any reason why you made this change to my package rather than just filing a bug about it? -sv From skvidal at linux.duke.edu Sun Jul 23 14:12:19 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 23 Jul 2006 10:12:19 -0400 Subject: Question about WTFPL In-Reply-To: <44C31D94.9070805@hhs.nl> References: <668bb39a0607221543l683dd7b1x4a682f7890c63861@mail.gmail.com> <1153610016.13330.9.camel@cutter> <44C31D94.9070805@hhs.nl> Message-ID: <1153663939.13330.17.camel@cutter> On Sun, 2006-07-23 at 08:56 +0200, Hans de Goede wrote: > > seth vidal wrote: > > On Sun, 2006-07-23 at 00:43 +0200, Micha? Bentkowski wrote: > >> Hi! > >> User Ian Chapman on > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199611 placed a > >> review request to package with WTFPL license. And my question is > >> simple: is it permissible in Extras? > >> More information about it is here: http://sam.zoy.org/wtfpl/ > > > > > > I've forwarded this to the fedora legal contact. > > > > Why? Licenses don't get much free-er then this, I thought we only needed > to contact legal if we had questions about a license? > Lots of things are free - but sometimes their unenforceable or otherwise problematic. I've learned that it is best to NOT make legal decisions w/o the advice of a lawyer. -sv From enrico.scholz at informatik.tu-chemnitz.de Sun Jul 23 14:57:27 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 23 Jul 2006 16:57:27 +0200 Subject: Cross-compilers. In-Reply-To: <1153656919.29989.74.camel@shinybook.infradead.org> (David Woodhouse's message of "Sun, 23 Jul 2006 08:15:18 -0400") References: <1153656919.29989.74.camel@shinybook.infradead.org> Message-ID: <87mzb0mkrs.fsf@kosh.bigo.ensc.de> dwmw2 at infradead.org (David Woodhouse) writes: > > Stuff like crosstool makes it relatively simple, but it's still slow -- > I'd really like to be able to easily and quickly install cross-compiler > packages for random architectures like ARM, MIPS, i386, etc. > > I'd like to ship a multi-arch capable binutils like Debian's > 'binutils-multi' I see the following problems with such a '--enable-targets=all' binutils package: * it slows down linker/assembler on some platforms (see [1]) * the '--with-sysroot=...' switch would not work with such a multi-arch package > and a set of cross-compilers -- preferably the same versions of each > as the one in Core. This will create a huge amount of variations: * soft-float/hard-float * little/big-endianess * cpu optimized libs (e.g. ARM XScale, EP9301, Thumb/non-thumb); multi-lib support would be probably too much overkill for embedded platforms and I run into heavy inter-package dependency problems when experimenting with this * used libc (GNU Libc, uclibc) * X11-based/non-X11 based Some of this options can/are encoded in the arch string (e.g. 'arm-xscale-linux-gnu', 'armb-xscale_softfloat-linux-uclibc') but things like X11-support not. Then: rpm must be enhanced to create proper Provides:/Requires:. E.g. it would be bad when a ARM package contains. | Provides: libc.so.6 which might be installed instead of the host glibc. I hacked around this problem by using custom find-requires/provides scripts so that | Provides: libc.so.6(arm-xscale-linux-gnu) are generated. But it requires | %define _use_internal_dependency_generator 0 which is discouraged. Enrico Footnotes: [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=63618 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rc040203 at freenet.de Sun Jul 23 15:27:55 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 23 Jul 2006 17:27:55 +0200 Subject: Cross-compilers. In-Reply-To: <87mzb0mkrs.fsf@kosh.bigo.ensc.de> References: <1153656919.29989.74.camel@shinybook.infradead.org> <87mzb0mkrs.fsf@kosh.bigo.ensc.de> Message-ID: <1153668476.22104.23.camel@mccallum.corsepiu.local> On Sun, 2006-07-23 at 16:57 +0200, Enrico Scholz wrote: > dwmw2 at infradead.org (David Woodhouse) writes: > > and a set of cross-compilers -- preferably the same versions of each > > as the one in Core. > > This will create a huge amount of variations: > > * soft-float/hard-float > * little/big-endianess > * cpu optimized libs (e.g. ARM XScale, EP9301, Thumb/non-thumb); multi-lib > support would be probably too much overkill for embedded platforms The contrary is true. Multilibs initially have been invented for embedded targets and have a long history there, predating using them on "non-embedded" OSes. The rationale is quite simple: On embedded targets "squeezing the max" is much more of importance than on "non-embedded OSes", because embedded systems often are based on low-end CPUs with very limited resources. Ralf From bugs.michael at gmx.net Sun Jul 23 15:30:31 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 23 Jul 2006 17:30:31 +0200 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <1153663841.13330.15.camel@cutter> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> <1153663841.13330.15.camel@cutter> Message-ID: <20060723173031.cec6f457.bugs.michael@gmx.net> On Sun, 23 Jul 2006 10:10:40 -0400, seth vidal wrote: > On Sat, 2006-07-22 at 05:31 -0700, Michael Schwendt wrote: > > Author: mschwendt > > > > Update of /cvs/extras/rpms/seahorse/devel > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26556/seahorse/devel > > > > Modified Files: > > seahorse.spec > > Log Message: > > replace bad %{dist} usage with %{?dist} > > Michael, > Any reason why you made this change to my package rather than just > filing a bug about it? Punish me if you think it was a bad thing. From rc040203 at freenet.de Sun Jul 23 15:33:22 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 23 Jul 2006 17:33:22 +0200 Subject: Cross-compilers. In-Reply-To: <44C37244.9090406@knox.net.nz> References: <1153656919.29989.74.camel@shinybook.infradead.org> <44C37244.9090406@knox.net.nz> Message-ID: <1153668802.22104.25.camel@mccallum.corsepiu.local> On Mon, 2006-07-24 at 00:57 +1200, Michael J. Knox wrote: > I think some cross compilers would be a good idea. I already use arm > regularly and will shortly have a need for nesC and some AVR cross > tools. The avr is yet another special case: The avr guys are using a custom libc, which isn't either glibc nor newlib. Ralf From icon at fedoraproject.org Sun Jul 23 15:40:35 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Sun, 23 Jul 2006 11:40:35 -0400 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <20060722135834.GD9662@lists.us.dell.com> References: <20060722135834.GD9662@lists.us.dell.com> Message-ID: On 7/22/06, Matt Domsch wrote: > I'm Bcc'ing everyone whose email shows up for a package below this > time, as the time for manditory package fixing is drawing near, per > the note to fedora-maintainers. If you haven't looked at your > packages in a while, and they fail to build in the reduced chroot, now > would be a good time to take a look. > uqm-0.5.0-1.fc5 icon at fedoraproject.org uqm-0.5 is known not to work on 64-bit archs. The specfile specifically says so, and the error seen is expected: (from http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/x86_64/uqm-0.5.0-1.fc5.src.rpm/result/build.log) error: Architecture is excluded: x86_64 I think you should modify your script so it doesn't try to build packages that specifically exclude the platform you're testing. Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From enrico.scholz at informatik.tu-chemnitz.de Sun Jul 23 15:44:32 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 23 Jul 2006 17:44:32 +0200 Subject: Cross-compilers. In-Reply-To: <1153668476.22104.23.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Sun, 23 Jul 2006 17:27:55 +0200") References: <1153656919.29989.74.camel@shinybook.infradead.org> <87mzb0mkrs.fsf@kosh.bigo.ensc.de> <1153668476.22104.23.camel@mccallum.corsepiu.local> Message-ID: <87irlomilb.fsf@kosh.bigo.ensc.de> rc040203 at freenet.de (Ralf Corsepius) writes: >> This will create a huge amount of variations: >> >> * soft-float/hard-float >> * little/big-endianess >> * cpu optimized libs (e.g. ARM XScale, EP9301, Thumb/non-thumb); multi-lib >> support would be probably too much overkill for embedded platforms > The contrary is true. Multilibs initially have been invented for > embedded targets and have a long history there, predating using them on > "non-embedded" OSes. I do not see sense for multilib here because binary packages must be built per architecture (e.g. soft/hard-float are ABI incompatible, kernel assumes a certain endianess, optimized programs should be used on embedded platforms due to the limited resources). Enabling the multilib bits adds just unneeded complexity (both in packaging, bootstrapping and performance+size aspects). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From jkeating at redhat.com Sun Jul 23 16:01:53 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 23 Jul 2006 12:01:53 -0400 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <20060723173031.cec6f457.bugs.michael@gmx.net> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> <1153663841.13330.15.camel@cutter> <20060723173031.cec6f457.bugs.michael@gmx.net> Message-ID: <200607231201.53479.jkeating@redhat.com> On Sunday 23 July 2006 11:30, Michael Schwendt wrote: > > Michael, > > ?Any reason why you made this change to my package rather than just > > filing a bug about it? > > Punish me if you think it was a bad thing. Its the curtious thing to do. File a bug, allow the maintainer to fix it him/herself. Changing somebody else's package should only be done as a last resort when the maintainer is AWOL. -- 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 gauret at free.fr Sun Jul 23 16:07:23 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 23 Jul 2006 18:07:23 +0200 Subject: Renaming in CVS References: <44C11F92.2030301@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > But that's not the reason for this mail. Rex or Aurelien, could one of > you two add this solution to the wiki somewhere? tia! I'd love to, but the page is marked "immutable". Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc From skvidal at linux.duke.edu Sun Jul 23 16:21:43 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 23 Jul 2006 12:21:43 -0400 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <20060723173031.cec6f457.bugs.michael@gmx.net> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> <1153663841.13330.15.camel@cutter> <20060723173031.cec6f457.bugs.michael@gmx.net> Message-ID: <1153671703.13330.29.camel@cutter> On Sun, 2006-07-23 at 17:30 +0200, Michael Schwendt wrote: > On Sun, 23 Jul 2006 10:10:40 -0400, seth vidal wrote: > > > On Sat, 2006-07-22 at 05:31 -0700, Michael Schwendt wrote: > > > Author: mschwendt > > > > > > Update of /cvs/extras/rpms/seahorse/devel > > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26556/seahorse/devel > > > > > > Modified Files: > > > seahorse.spec > > > Log Message: > > > replace bad %{dist} usage with %{?dist} > > > > Michael, > > Any reason why you made this change to my package rather than just > > filing a bug about it? > > Punish me if you think it was a bad thing. Why are you taking this attitude? I didn't accuse you of anything. I just didn't understand why you didn't just ask me to fix it - considering it is my package. -sv From sailer at sailer.dynip.lugs.ch Sun Jul 23 16:39:39 2006 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Sun, 23 Jul 2006 18:39:39 +0200 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <20060722135834.GD9662@lists.us.dell.com> References: <20060722135834.GD9662@lists.us.dell.com> Message-ID: <1153672780.3081.8.camel@unreal> On Sat, 2006-07-22 at 08:58 -0500, Matt Domsch wrote: > ghdl-0.24-0.59svn.2.fc6 t.sailer at alumni.ethz.ch Sorry, I can't see what the problem is... according to your logs and results directory, it did build on i386 and x86_64... Tom From fedora at leemhuis.info Sun Jul 23 16:42:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 23 Jul 2006 18:42:32 +0200 Subject: Renaming in CVS In-Reply-To: References: <44C11F92.2030301@leemhuis.info> Message-ID: <44C3A6F8.1050207@leemhuis.info> Aurelien Bompard schrieb: > Thorsten Leemhuis wrote: >> But that's not the reason for this mail. Rex or Aurelien, could one of >> you two add this solution to the wiki somewhere? tia! > I'd love to, but the page is marked "immutable". "--verbose" please. Which page? Are you logged in? Are all pages marked "immutable"? CU thl From bugs.michael at gmx.net Sun Jul 23 16:59:08 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 23 Jul 2006 18:59:08 +0200 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <200607231201.53479.jkeating@redhat.com> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> <1153663841.13330.15.camel@cutter> <20060723173031.cec6f457.bugs.michael@gmx.net> <200607231201.53479.jkeating@redhat.com> Message-ID: <20060723185908.e8aa5d75.bugs.michael@gmx.net> On Sun, 23 Jul 2006 12:01:53 -0400, Jesse Keating wrote: > On Sunday 23 July 2006 11:30, Michael Schwendt wrote: > > > Michael, > > > ?Any reason why you made this change to my package rather than just > > > filing a bug about it? > > > > Punish me if you think it was a bad thing. > > Its the curtious thing to do. File a bug, allow the maintainer to fix it > him/herself. Changing somebody else's package should only be done as a last > resort when the maintainer is AWOL. In the general case, yes, but not in this special case. Maybe you just didn't pay attention to the diff. It is a big surprise to me that somebody complains about such a change at all. From fedora at leemhuis.info Sun Jul 23 17:03:51 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 23 Jul 2006 19:03:51 +0200 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <200607231201.53479.jkeating@redhat.com> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> <1153663841.13330.15.camel@cutter> <20060723173031.cec6f457.bugs.michael@gmx.net> <200607231201.53479.jkeating@redhat.com> Message-ID: <44C3ABF7.3050001@leemhuis.info> Jesse Keating schrieb: > On Sunday 23 July 2006 11:30, Michael Schwendt wrote: >>> Michael, >>> Any reason why you made this change to my package rather than just >>> filing a bug about it? >> Punish me if you think it was a bad thing. > Its the curtious thing to do. File a bug, allow the maintainer to fix it > him/herself. Changing somebody else's package should only be done as a last > resort when the maintainer is AWOL. I think what Michael did is acceptable and actually a good thing Especially for such minor changes and when done by someone who has shown that he understands packaging and the packaging guidelines well (e.g. is a Sponsor). Further: I think a slightly more Wiki-style-approach would be a good thing for Extras. Two reasons for this opinion: - %{dist} vs. %{?dist} and similar small errors: Fixing them in cvs is often quick and easy, opening bugs for small errors like that often takes a lot of time and sometimes is painful. Result with the "only maintainer may touch a package" scheme: Small things often don't get fixed because no one files bugs for them. - in the early days of Fedora Extras there were a lot of packages that didn't build on x86_64 (maybe 10% of the packages were missing for x86_64 -- I can't remember the exact numbers). I and some others fixed a lot of those directly in CVS. I tried to file bugs in the beginning, but they often got ignored, patches ignored and bugzilla was frustrating as always. I had two ways to go forward: -- proceed with the painful and frustrating bugzilla work -- fix it directly in CVS I did the latter mostly (big intrusive changes still got discussed first in bugzilla or via mail). Nearly nobody complained and we had a mostly complete FE for x86_64 after some weeks/months. It would have taken much longer via bugzilla. I think it was the right thing to do. Just my 2 cent. CU thl From bugs.michael at gmx.net Sun Jul 23 17:13:48 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 23 Jul 2006 19:13:48 +0200 Subject: Renaming in CVS In-Reply-To: <44C3A6F8.1050207@leemhuis.info> References: <44C11F92.2030301@leemhuis.info> <44C3A6F8.1050207@leemhuis.info> Message-ID: <20060723191348.b10fc701.bugs.michael@gmx.net> On Sun, 23 Jul 2006 18:42:32 +0200, Thorsten Leemhuis wrote: > > > Aurelien Bompard schrieb: > > Thorsten Leemhuis wrote: > >> But that's not the reason for this mail. Rex or Aurelien, could one of > >> you two add this solution to the wiki somewhere? tia! > > I'd love to, but the page is marked "immutable". > > "--verbose" please. Which page? Are you logged in? Are all pages marked > "immutable"? > > CU > thl Pages below "Packaging" have different ACLs and are assigned to spot. This has been a controversial topic before. From jkeating at redhat.com Sun Jul 23 17:14:57 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 23 Jul 2006 13:14:57 -0400 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <20060723185908.e8aa5d75.bugs.michael@gmx.net> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> <200607231201.53479.jkeating@redhat.com> <20060723185908.e8aa5d75.bugs.michael@gmx.net> Message-ID: <200607231314.57766.jkeating@redhat.com> On Sunday 23 July 2006 12:59, Michael Schwendt wrote: > In the general case, yes, but not in this special case. Maybe you just > didn't pay attention to the diff. > > It is a big surprise to me that somebody complains about such a change > at all. It wasn't a complaint about the content of the change, it was a curiosity as to why you felt it necessary to make a change at all w/out contacting Seth. Seth is very reachable and responsive, it would have been perfectly easy to drop him an email or a quick ping on IRC. Seth could have changed it and maybe taken the opportunity to do some other work with the package. I know that I would REALLY prefer somebody checked with me first before making a change to my packages. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sun Jul 23 17:21:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 23 Jul 2006 19:21:32 +0200 Subject: Renaming in CVS In-Reply-To: <20060723191348.b10fc701.bugs.michael@gmx.net> References: <44C11F92.2030301@leemhuis.info> <44C3A6F8.1050207@leemhuis.info> <20060723191348.b10fc701.bugs.michael@gmx.net> Message-ID: <44C3B01C.2080605@leemhuis.info> Michael Schwendt schrieb: > On Sun, 23 Jul 2006 18:42:32 +0200, Thorsten Leemhuis wrote: >> Aurelien Bompard schrieb: >>> Thorsten Leemhuis wrote: >>>> But that's not the reason for this mail. Rex or Aurelien, could one of >>>> you two add this solution to the wiki somewhere? tia! >>> I'd love to, but the page is marked "immutable". >> "--verbose" please. Which page? Are you logged in? Are all pages marked >> "immutable"? > Pages below "Packaging" have different ACLs and are assigned > to spot. This has been a controversial topic before. Well, this is AFAICS completely Extras specific and therefor should live in the Extras/ namespace in the wiki where such restrictions don't exist AFAIK. CU thl From rc040203 at freenet.de Sun Jul 23 17:38:16 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 23 Jul 2006 19:38:16 +0200 Subject: Cross-compilers. In-Reply-To: <87irlomilb.fsf@kosh.bigo.ensc.de> References: <1153656919.29989.74.camel@shinybook.infradead.org> <87mzb0mkrs.fsf@kosh.bigo.ensc.de> <1153668476.22104.23.camel@mccallum.corsepiu.local> <87irlomilb.fsf@kosh.bigo.ensc.de> Message-ID: <1153676296.22104.30.camel@mccallum.corsepiu.local> On Sun, 2006-07-23 at 17:44 +0200, Enrico Scholz wrote: > rc040203 at freenet.de (Ralf Corsepius) writes: > > >> This will create a huge amount of variations: > >> > >> * soft-float/hard-float > >> * little/big-endianess > >> * cpu optimized libs (e.g. ARM XScale, EP9301, Thumb/non-thumb); multi-lib > >> support would be probably too much overkill for embedded platforms > > The contrary is true. Multilibs initially have been invented for > > embedded targets and have a long history there, predating using them on > > "non-embedded" OSes. > > I do not see sense for multilib here because binary packages must be > built per architecture (e.g. soft/hard-float are ABI incompatible, > kernel assumes a certain endianess, optimized programs should be used > on embedded platforms due to the limited resources). => multilib'ed kernels/OS runtime libs. > Enabling the multilib bits adds just unneeded complexity (both in > packaging, bootstrapping and performance+size aspects). Yes, they impact bootstrapping + size and toolchain size, but the rest isn't. >From a user's perspective, multilibs are very convenient. For example they enable you to switch the HW without having to recompile the toolchain/OS. All you need to recompile is your application with different flags. Ralf From bruno at wolff.to Sun Jul 23 17:53:59 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 23 Jul 2006 12:53:59 -0500 Subject: Cross-compilers. In-Reply-To: <1153656919.29989.74.camel@shinybook.infradead.org> References: <1153656919.29989.74.camel@shinybook.infradead.org> Message-ID: <20060723175359.GA17242@wolff.to> On Sun, Jul 23, 2006 at 08:15:18 -0400, David Woodhouse wrote: > How much interest would there be in getting a bunch of cross-compilers > into Extras? I would like to be able to build Wesnoth for Windows using a cross compiler. So I would give such a package a try. From bugs.michael at gmx.net Sun Jul 23 18:07:55 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 23 Jul 2006 20:07:55 +0200 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <200607231314.57766.jkeating@redhat.com> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> <200607231201.53479.jkeating@redhat.com> <20060723185908.e8aa5d75.bugs.michael@gmx.net> <200607231314.57766.jkeating@redhat.com> Message-ID: <20060723200755.f4eead23.bugs.michael@gmx.net> On Sun, 23 Jul 2006 13:14:57 -0400, Jesse Keating wrote: > On Sunday 23 July 2006 12:59, Michael Schwendt wrote: > > In the general case, yes, but not in this special case. Maybe you just > > didn't pay attention to the diff. > > > > It is a big surprise to me that somebody complains about such a change > > at all. > > It wasn't a complaint about the content of the change, it was a curiosity as > to why you felt it necessary to make a change at all w/out contacting Seth. > Seth is very reachable and responsive, it would have been perfectly easy to > drop him an email or a quick ping on IRC. Seth could have changed it and > maybe taken the opportunity to do some other work with the package. I know > that I would REALLY prefer somebody checked with me first before making a > change to my packages. With this comment, it is clear to me that you do not know what I've done. What "opportunity"? This was in CVS, only in CVS. No tag, no rebuild, no damage, nothing that justifies that you jump the bandwagon and criticise me the way you do with such a general slap in the face. And seriously, this has not been an emergency situation where something like hanging around on IRC and occupying other people would have been justified. I've found a couple of packages with the same tiny mistake/typo, and without querying owners.list I've fixed it quickly instead of wasting time in bugzilla. The majority of package owners would be glad about it--and in case they would revert the change with their next cvs-import, no harm would be done either-and about the saved time, since submitting, loading and closing tickets in bugzilla takes extra time. So, be so kind, take a look at the diff, and if you then are still in a mood to attack me, oh my... From bugs.michael at gmx.net Sun Jul 23 18:08:38 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 23 Jul 2006 20:08:38 +0200 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <1153671703.13330.29.camel@cutter> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> <1153663841.13330.15.camel@cutter> <20060723173031.cec6f457.bugs.michael@gmx.net> <1153671703.13330.29.camel@cutter> Message-ID: <20060723200838.6b4a0a9d.bugs.michael@gmx.net> On Sun, 23 Jul 2006 12:21:43 -0400, seth vidal wrote: > > > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26556/seahorse/devel > > > > > > > > Modified Files: > > > > seahorse.spec > > > > Log Message: > > > > replace bad %{dist} usage with %{?dist} > > > > > > Michael, > > > Any reason why you made this change to my package rather than just > > > filing a bug about it? > > > > Punish me if you think it was a bad thing. > > Why are you taking this attitude? I didn't accuse you of anything. I > just didn't understand why you didn't just ask me to fix it - > considering it is my package. Ah, come on, not this again. :( I'm serious. Really. How else is your mail to this list supposed to be understood? It is a complaint, isn't it? A big fuss without real reason. You think I've done something nasty which justifies a big thread on a public mailing-list. You do agree with the change, don't you? Do you really believe I would change other's [and your] packages in fundamental ways without prior communication? I would understand your mail if I had changed the package in a different way, probably in a questionable way. From bugs.michael at gmx.net Sun Jul 23 18:34:06 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 23 Jul 2006 20:34:06 +0200 Subject: [Fedora Project Wiki] Update of "Extras/UsingCvsFaq" by ChrisPetersen In-Reply-To: <20060723182515.31824.62450@fedora.linux.duke.edu> References: <20060723182515.31824.62450@fedora.linux.duke.edu> Message-ID: <20060723203406.3602fa63.bugs.michael@gmx.net> On Sun, 23 Jul 2006 18:25:15 -0000, fedorawiki-noreply at fedoraproject.org wrote: > The following page has been changed by ChrisPetersen: > http://fedoraproject.org/wiki/Extras/UsingCvsFaq > > The comment on the change is: > add info about how to revert a tag if it was added incorrectly > > ------------------------------------------------------------------------------ > > Please write to accounts at fedora.redhat.com and include all details. There has not been any IP address ACL anymore for months now, so your problem is likely a client configuration issue, private/public key mismatch, or some network problem. > > + === I ran `make tag` without checking in my files, how do I revert so I can check them in? === > + > + Until someone fixes plague so that `make tag` fails when there are files waiting to be checked in, you can use the following to revert the incorrect new tag: > + > + {{{ > + cvs tag -F -c > + }}} > + If you insist on moving an existing cvs tag, please do prefer TAG_OPTS=-F make tag since with it you don't need to find out and construct the tag yourself. From skvidal at linux.duke.edu Sun Jul 23 18:45:00 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 23 Jul 2006 14:45:00 -0400 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <44C3ABF7.3050001@leemhuis.info> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> <1153663841.13330.15.camel@cutter> <20060723173031.cec6f457.bugs.michael@gmx.net> <200607231201.53479.jkeating@redhat.com> <44C3ABF7.3050001@leemhuis.info> Message-ID: <1153680300.13330.32.camel@cutter> On Sun, 2006-07-23 at 19:03 +0200, Thorsten Leemhuis wrote: > Jesse Keating schrieb: > > On Sunday 23 July 2006 11:30, Michael Schwendt wrote: > >>> Michael, > >>> Any reason why you made this change to my package rather than just > >>> filing a bug about it? > >> Punish me if you think it was a bad thing. > > Its the curtious thing to do. File a bug, allow the maintainer to fix it > > him/herself. Changing somebody else's package should only be done as a last > > resort when the maintainer is AWOL. > > I think what Michael did is acceptable and actually a good thing > Especially for such minor changes and when done by someone who has shown > that he understands packaging and the packaging guidelines well (e.g. is > a Sponsor). Just to be clear. I'm not pissed about the change. I asked him why he didn't ask me to do it. His response was snide for no obvious reason. And it didn't even have a smiley in it. sheesh. -sv From skvidal at linux.duke.edu Sun Jul 23 18:46:31 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 23 Jul 2006 14:46:31 -0400 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <20060723200838.6b4a0a9d.bugs.michael@gmx.net> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> <1153663841.13330.15.camel@cutter> <20060723173031.cec6f457.bugs.michael@gmx.net> <1153671703.13330.29.camel@cutter> <20060723200838.6b4a0a9d.bugs.michael@gmx.net> Message-ID: <1153680392.13330.35.camel@cutter> On Sun, 2006-07-23 at 20:08 +0200, Michael Schwendt wrote: > Ah, come on, not this again. :( > > I'm serious. Really. How else is your mail to this list supposed to be > understood? It is a complaint, isn't it? A big fuss without real reason. No it wasn't a complaint. It was a question. You can notice the questions b/c they have these nifty little ? at the end of the sentences. It wasn't even a rhetorical question. If you had said "I was going through and fixing this for a bunch of packages and so I fixed yours, too." I would have been fine with it. Instead you decided to be a smart ass. -sv From j.w.r.degoede at hhs.nl Sun Jul 23 18:51:36 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 23 Jul 2006 20:51:36 +0200 Subject: libtar users headsup Message-ID: <44C3C538.3090008@hhs.nl> Hi, As some of you may have noticed from my CVS commits, I'm taking over a bunch of packages from Anvil, because Anvil has other priorities then FE ATM. One of these packages is libtar. Before taking over I've done a quick QA check of all the packages which involved amongst other stuff running rpmlint. rpmlint on libtar gave some spurious messages because libtar normally only build a static (.a) lib. The buildsys has just completed building a new libtar for devel which contains a proper .so file, with soname, 100% PIC etc. So I would like to ask all maintainers who maintain a package which uses libtar to build and then test it against the new libtar in devel. Thanks, Hans From fedora at camperquake.de Sun Jul 23 19:00:57 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 23 Jul 2006 21:00:57 +0200 Subject: rpms/sextractor/FC-4 sextractor.spec,1.2,1.3 In-Reply-To: <1153623782.5125.13.camel@mccallum.corsepiu.local> References: <200607211724.k6LHO3Z8023012@cvs-int.fedora.redhat.com> <1153508980.18981.125.camel@mccallum.corsepiu.local> <1153537475.18981.150.camel@mccallum.corsepiu.local> <1153571226.30083.31.camel@laurel.intra.city-fan.org> <1153623782.5125.13.camel@mccallum.corsepiu.local> Message-ID: <20060723210057.30fef5b0@nausicaa.camperquake.de> Hi. Ralf Corsepius wrote: > I am going to file a request to packaging committee to ban -O3 and > -fomit-frame-pointer What has the one to do with the other? -- When you smell an odourless gas, it is probably carbon monoxide. From rc040203 at freenet.de Sun Jul 23 19:06:51 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 23 Jul 2006 21:06:51 +0200 Subject: rpms/sextractor/FC-4 sextractor.spec,1.2,1.3 In-Reply-To: <20060723210057.30fef5b0@nausicaa.camperquake.de> References: <200607211724.k6LHO3Z8023012@cvs-int.fedora.redhat.com> <1153508980.18981.125.camel@mccallum.corsepiu.local> <1153537475.18981.150.camel@mccallum.corsepiu.local> <1153571226.30083.31.camel@laurel.intra.city-fan.org> <1153623782.5125.13.camel@mccallum.corsepiu.local> <20060723210057.30fef5b0@nausicaa.camperquake.de> Message-ID: <1153681611.22104.44.camel@mccallum.corsepiu.local> On Sun, 2006-07-23 at 21:00 +0200, Ralf Ertzinger wrote: > Hi. > > Ralf Corsepius wrote: > > > I am going to file a request to packaging committee to ban -O3 and > > -fomit-frame-pointer > > What has the one to do with the other? Both affect code-generation. -fomit-frame-pointer implies rendering debugging worthless -O3 means entering muddy/untested ground on GCC's behaviour and introducing unreliability/unstability to rpms. Using both are equally stupid. Ralf From bugs.michael at gmx.net Sun Jul 23 19:31:13 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 23 Jul 2006 21:31:13 +0200 Subject: libtar users headsup In-Reply-To: <44C3C538.3090008@hhs.nl> References: <44C3C538.3090008@hhs.nl> Message-ID: <20060723213113.71685afe.bugs.michael@gmx.net> On Sun, 23 Jul 2006 20:51:36 +0200, Hans de Goede wrote: > Hi, > > As some of you may have noticed from my CVS commits, I'm taking over a > bunch of packages from Anvil, because Anvil has other priorities then FE > ATM. > > One of these packages is libtar. Before taking over I've done a quick QA > check of all the packages which involved amongst other stuff running > rpmlint. rpmlint on libtar gave some spurious messages because libtar > normally only build a static (.a) lib. > > The buildsys has just completed building a new libtar for devel which > contains a proper .so file, with soname, 100% PIC etc. So I would like > to ask all maintainers who maintain a package which uses libtar to build > and then test it against the new libtar in devel. There are zero packages in FE which BR libtar or libtar-devel From bugs.michael at gmx.net Sun Jul 23 19:27:59 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 23 Jul 2006 21:27:59 +0200 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <1153680392.13330.35.camel@cutter> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> <1153663841.13330.15.camel@cutter> <20060723173031.cec6f457.bugs.michael@gmx.net> <1153671703.13330.29.camel@cutter> <20060723200838.6b4a0a9d.bugs.michael@gmx.net> <1153680392.13330.35.camel@cutter> Message-ID: <20060723212759.29f7d9df.bugs.michael@gmx.net> On Sun, 23 Jul 2006 14:46:31 -0400, seth vidal wrote: > On Sun, 2006-07-23 at 20:08 +0200, Michael Schwendt wrote: > > Ah, come on, not this again. :( > > > > I'm serious. Really. How else is your mail to this list supposed to be > > understood? It is a complaint, isn't it? A big fuss without real reason. > > > No it wasn't a complaint. It was a question. You can notice the > questions b/c they have these nifty little ? at the end of the > sentences. ? > It wasn't even a rhetorical question. > > If you had said "I was going through and fixing this for a bunch of > packages and so I fixed yours, too." I would have been fine with it. You've received the commit mail. You've even noticed the mail probably because you're filtering correctly (as should be done by every package owner). The next scripted check would find 20 packages with the same typo or spelling mistake, and I would need to send 20 private mails or file 20 tickets for that when commit mails are automated anyway? To quote you: "sheesh." > Instead you decided to be a smart ass. No, see above. I was serious in my reply, because I couldn't believe my eyes that you really took that commit message to the list. And I still find it very strange that you felt the need to create a public topic about it. File a formal Fedora Extras CVS abuse complaint if _you_ are serious about making a big fuss with no real reason. From skvidal at linux.duke.edu Sun Jul 23 19:38:32 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 23 Jul 2006 15:38:32 -0400 Subject: rpms/seahorse/devel seahorse.spec,1.18,1.19 In-Reply-To: <20060723212759.29f7d9df.bugs.michael@gmx.net> References: <200607221231.k6MCV54p026637@cvs-int.fedora.redhat.com> <1153663841.13330.15.camel@cutter> <20060723173031.cec6f457.bugs.michael@gmx.net> <1153671703.13330.29.camel@cutter> <20060723200838.6b4a0a9d.bugs.michael@gmx.net> <1153680392.13330.35.camel@cutter> <20060723212759.29f7d9df.bugs.michael@gmx.net> Message-ID: <1153683512.13330.44.camel@cutter> On Sun, 2006-07-23 at 21:27 +0200, Michael Schwendt wrote: > You've received the commit mail. You've even noticed the mail probably > because you're filtering correctly (as should be done by every package > owner). The next scripted check would find 20 packages with the same typo > or spelling mistake, and I would need to send 20 private mails or file 20 > tickets for that when commit mails are automated anyway? To quote you: > "sheesh." yes, I do filter my mail to my packages. I saw one change and only to that package. That's why I asked. > > Instead you decided to be a smart ass. > > No, see above. I was serious in my reply, because I couldn't believe my > eyes that you really took that commit message to the list. And I still > find it very strange that you felt the need to create a public topic > about it. File a formal Fedora Extras CVS abuse complaint if _you_ are > serious about making a big fuss with no real reason. I hit the reply button in my mail client. The reply-to is set to this list. There was no malice, I just typed in a question. -sv From ville.skytta at iki.fi Sun Jul 23 20:02:56 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 23 Jul 2006 23:02:56 +0300 Subject: [Fedora Project Wiki] Update of "Extras/UsingCvsFaq" by ChrisPetersen In-Reply-To: <20060723203406.3602fa63.bugs.michael@gmx.net> References: <20060723182515.31824.62450@fedora.linux.duke.edu> <20060723203406.3602fa63.bugs.michael@gmx.net> Message-ID: <1153684976.2769.120.camel@localhost.localdomain> > On Sun, 23 Jul 2006 18:25:15 -0000, fedorawiki-noreply at fedoraproject.org wrote: > > > + === I ran `make tag` without checking in my files, how do I revert so I can check them in? === Blah, again running out of integers, are we :) ? Simpler and safer general answer: don't even try rewriting the history. Just check the missing files in, bump the release (while paying attention to upgrade paths, there are recipes for doing that properly and the packager must think about and understand it anyway), and tag and build again as usual. > > + Until someone fixes plague so that `make tag` fails when there are files waiting to be checked in There's nothing plague can do about this. The tag target in common/Makefile.common could be modified to check that the output of "cvs -q up 2>/dev/null" is empty and that the command executes successfully before attempting to tag, but some could find that annoying. (FWIW, even if I would, I think I wouldn't object to it.) From pertusus at free.fr Sun Jul 23 21:22:02 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 23 Jul 2006 23:22:02 +0200 Subject: Any takers for perl modules RSS related? Message-ID: <20060723212202.GA2445@free.fr> Hello, I would like to submit http://exo.org.uk/code/rss2mail/, it depends on many perl modules that are not in fedora extras. Before I submit them, I let other more interested in these modules a chance to pick them up. So if you're interested, I have packaged them and I intend to submit those without taker: http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-Cache.spec http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-Cache-2.04-1.src.rpm http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-DateTime-Format-Mail.spec http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-DateTime-Format-Mail-0.2901-1.src.rpm http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-DateTime-Format-W3CDTF.spec http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-DateTime-Format-W3CDTF-0.04-1.src.rpm http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-Feed-Find.spec http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-Feed-Find-0.06-1.src.rpm http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-File-NFSLock.spec http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-File-NFSLock-1.20-1.src.rpm http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-Heap.spec http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-Heap-0.71-1.src.rpm http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-HTML-FormatText-WithLinks.spec http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-HTML-FormatText-WithLinks-0.06-1.src.rpm http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-LWP-Authen-Wsse.spec http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-LWP-Authen-Wsse-0.05-1.src.rpm http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-URI-Fetch.spec http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-URI-Fetch-0.071-1.src.rpm http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-XML-Atom.spec http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-XML-Atom-0.21-1.src.rpm http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-XML-Feed.spec http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-XML-Feed-0.10-1.src.rpm -- Pat From tibbs at math.uh.edu Mon Jul 24 01:54:18 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sun, 23 Jul 2006 20:54:18 -0500 Subject: Cross-compilers. In-Reply-To: <1153660582.29989.91.camel@shinybook.infradead.org> (David Woodhouse's message of "Sun, 23 Jul 2006 09:16:21 -0400") References: <1153656919.29989.74.camel@shinybook.infradead.org> <44C37244.9090406@knox.net.nz> <1153660582.29989.91.camel@shinybook.infradead.org> Message-ID: >>>>> "DW" == David Woodhouse writes: DW> On Mon, 2006-07-24 at 00:57 +1200, Michael J. Knox wrote: >> I do now there was some discuss, which remains unresolved, as to >> the naming convention to use for cross tool chain packages. DW> Does it matter? Far too much masturbation goes on around here. Yes, it matters. It would be bad for end users and for consistency in the distribution if different packagers chose different naming conventions. It that's masturbation, then so be it. At this point I don't personally care what gets chosen, but a choice needs to be made. The same goes for the naming of executables and the location of libraries and such. And if this is all completely obvious to everyone who is packaging up cross-compilation tools and you're all already using the same conventions then it shouldn't take more than ten minutes to write that down somewhere. - J< From Matt_Domsch at dell.com Mon Jul 24 02:14:34 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 23 Jul 2006 21:14:34 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <1153672780.3081.8.camel@unreal> References: <20060722135834.GD9662@lists.us.dell.com> <1153672780.3081.8.camel@unreal> Message-ID: <20060724021434.GA5157@lists.us.dell.com> On Sun, Jul 23, 2006 at 06:39:39PM +0200, Thomas Sailer wrote: > On Sat, 2006-07-22 at 08:58 -0500, Matt Domsch wrote: > > > ghdl-0.24-0.59svn.2.fc6 t.sailer at alumni.ethz.ch > > Sorry, I can't see what the problem is... according to your logs and > results directory, it did build on i386 and x86_64... yes, this was one of Friday's false positives, since fixed in my builder. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From cweyl at alumni.drew.edu Mon Jul 24 03:48:35 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sun, 23 Jul 2006 20:48:35 -0700 Subject: Any takers for perl modules RSS related? In-Reply-To: <20060723212202.GA2445@free.fr> References: <20060723212202.GA2445@free.fr> Message-ID: <7dd7ab490607232048n4867a4c2qff83077adaf1f953@mail.gmail.com> On 7/23/06, Patrice Dumas wrote: > Hello, > > I would like to submit http://exo.org.uk/code/rss2mail/, it depends on > many perl modules that are not in fedora extras. Before I submit them, > I let other more interested in these modules a chance to pick them up. > So if you're interested, I have packaged them and I intend to submit > those without taker: I can't commit to ownership, but I'll certainly help review them if submitted. -Chris -- Chris Weyl Ex astris, scientia From paul at city-fan.org Mon Jul 24 07:38:56 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 24 Jul 2006 08:38:56 +0100 Subject: rpms/gtksourceview-sharp/devel gtksourceview-sharp-libdir.patch, NONE, 1.1 gtksourceview-sharp.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200607231350.k6NDoBH6016940@cvs-int.fedora.redhat.com> References: <200607231350.k6NDoBH6016940@cvs-int.fedora.redhat.com> Message-ID: <1153726736.30083.46.camel@laurel.intra.city-fan.org> On Sun, 2006-07-23 at 06:50 -0700, Paul F. Johnson wrote: > Author: pfj > > Update of /cvs/extras/rpms/gtksourceview-sharp/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16899/devel > > Modified Files: > .cvsignore sources > Added Files: > gtksourceview-sharp-libdir.patch gtksourceview-sharp.spec > Log Message: > auto-import gtksourceview-sharp-2.0-13 on branch devel from gtksourceview-sharp-2.0-13.src.rpm > ... > --- NEW FILE gtksourceview-sharp.spec --- ... > %configure --target=sparc86x Why is sparc86x still here? Paul. From hap10 at tycho.ncsc.mil Mon Jul 24 16:49:29 2006 From: hap10 at tycho.ncsc.mil (Chris) Date: Mon, 24 Jul 2006 12:49:29 -0400 Subject: Package Signing/GPG Key Management Questions Message-ID: <44C4FA19.3030908@tycho.ncsc.mil> Could someone shed light on the process for GPG signing of packages in the Extras repository? I briefly searched the archives, but found only an inconclusive argument about its usefulness. How does the Extras package signing process differ from Base/Updates? I know RPM-GPG-KEY-fedora-extras sits alongside RPM-GPG-KEY-fedora, but who has control of the Extras signing key? Is checking for a CLA on file the extent of vetting done to submitted packages (assuming they meet all other packaging criteria outlined in the Wiki)? It would be most helpful to have a sketch of what the ultimate signer (a RH employee?) does before he/she decides it's OK to sign the package with the official fedora-extras key. Many thanks, Chris From jwilson at redhat.com Mon Jul 24 17:55:08 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 24 Jul 2006 13:55:08 -0400 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <20060722135834.GD9662@lists.us.dell.com> References: <20060722135834.GD9662@lists.us.dell.com> Message-ID: <1153763709.12377.2.camel@xavier.boston.redhat.com> On Sat, 2006-07-22 at 08:58 -0500, Matt Domsch wrote: > I'm Bcc'ing everyone whose email shows up for a package below this > time, as the time for manditory package fixing is drawing near, per > the note to fedora-maintainers. If you haven't looked at your > packages in a while, and they fail to build in the reduced chroot, now > would be a good time to take a look. > Thanks, > Matt > > Extras Rawhide-in-Mock Build Results for x86_64 Sat Jul 22 02:21:07 CDT 2006 > > Note: This is using a reduced set of packages in the build chroot as > compared to the standard Fedora Extras build system before FC6test1. See > http://fedoraproject.org/wiki/QA/FixBuildRequires for more > information, including the list of packages removed from the > default build chroot. [...] > Number failed to build: 175 > Number expected to fail due to ExclusiveArch or ExcludeArch: 2 > Leaving: 173 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 153 > ---------------------------------- [...] > powerman-1.0.24-1.fc6 jwilson at redhat.com [...] Fixed, just built 1.0.24-2.fc6. (Needed BR: flex and bison) -- Jarod Wilson jwilson at redhat.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 toshio at tiki-lounge.com Mon Jul 24 17:57:24 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 24 Jul 2006 10:57:24 -0700 Subject: Future FESCo Elections Message-ID: <1153763844.3209.13.camel@localhost> =============== FESCo Elections =============== The recent FESCo election was a success in the sense that we ran it without technical difficulties, mudslinging by candidates, or charges of corruption. There remains much that we could do better in the next election cycle. Let's discuss the issues now so we have time to implement them before the next election. The following are some of the recognized issues and some possible solutions. Voter Turnout ============= Not a lot of the eligible voters actually cast ballots. Is this a problem or just an indication that all the candidates were acceptable to most people? One thing to try would be to incorporate a nag message into the next election. When the election opens, all eligible voters are emailed directly that they can vote. When voting is about to close, those who haven't voted get a new message reminding them that the election is about to end. Election schedule ================= When should elections be held? Tieing it to Fedora Core releases seems to make sense. In that case, would it be better to put half the seats up every election? Or to put every seat up for election after two Core releases? The first leads to elections roughly every 6 months and assures that some old blood is around after every election. The second method depends on former FESCo members deciding to renominate in order to keep continuity but has the benefit of having less elections for us to administer and for Extras members to have to remember to go and vote for. Comments on which plan is more appealing is highly appreciated. Formulation of the Ballot ========================= Contingent Nominations ---------------------- "Contingent nominations" were confusing. Here's my proposal for next election: If there are enough candidates to fill the ballot (See next paragraph for how many this is) without the contingent nominations they will not be added. If they are needed to fill the ballot, they will all be added as regular candidates. There will be no official after-the-election turning down of positions so other people can be on FESCo (We can't stop unofficial resignations, only enforce this through tradition). If contingent nominees want to do something like that, they should have their names taken off before the election starts. Number of Candidates Required for Elections ------------------------------------------- Having choices on a ballot is essential for making it worthwhile to vote. How many people are enough to fill out a slate of candidates? Should we hold off on starting an election until we have number of seats +1 candidate? Number of seats +X? Number of open seats + 25%? I would like to see us hold the start of elections for up to one week to try to get number of seats + 25% (For a 13 member FESCo with half the seats up for election, this equates to number of seats +2). After that, we just have to live with however many people are on the ballot. Lack of Candidates ------------------ Assuming that our cycle of elections will be terms of every 2 Core releases with elections for half after every release I propose we deal with not having enough candidates to fill all the seats this way: FESCo will run with less members for that Core release. The seats will be added to the next election. The lowest vote getters in that election will get the FESCo seats until the next core release, at which time the seats will be open for election again (so we maintain elections of roughly half the seats each time.) Term Limits ----------- Should there be term limits for FESCo in general? For the chair in particular? My personal feeling is that we're enough of a meritocracy that term limits for FESCo membership don't make sense. If someone feels they can best help the project by being on FESCo and the voters agree, then they should remain on FESCo. Defining how long a FESCo member can be the chair would be advantageous for rotating the duties and responsibilities of the position. No chair need feel guilty for giving up the position if it's written into the bylaws that they have to to yield the position after a certain time limit. Is a year the appropriate time span? Resignations and Election System ================================ What happens if someone resigns? Do we automatically go to the people previously up for election? Do we hold a special election? In the interests of efficiency and avoiding voter burnout, I would like to avoid special elections between Core releases. Instead, I propose selecting the runner-up candidate from the previous election to serve out the term (no matter if the remainder of the term is one Core release or two). Regarding this, there was some discussion about the GNOME Board[1]_ recently where the bloc voting method (there are 13 open seats, vote for at most 13 people, the 13 with the most votes will get in) was shown to be unfair when dealing with resignations. Basically, bloc voting gives you 13 votes to distribute among candidates. If one of those candidates resigns, one of your votes that could have gone to someone else has become irrelevant. If we change our model, what are our criteria for a new system? My criteria are: 1) it should be to something simple and easy explain to the voters, 2) it should not require complex calculations to determine the winner, and 3) should address the issue of votes being wasted if someone resigns. Approval voting (Vote for as many candidates as you like. The 13 with the most votes will get in) and range voting (There are X candidates, assign each of them from 0 to Y points. The 13 with the most points will get in.) Would both satisfy these criteria. I favor range voting where for 13 seats you can assign from 0 to 13 points to each of the candidates as this allows you to simply tally the votes at the end to see who the winners are, express your feelings as simple approval (13 for approvals, 0 for disapprovals) or in simple ranking if you are inclined. [1]_: http://blogs.gnome.org/view/jamesh/2006/06/06/0 Voting App ========== The voting application we used for this election was simple but effective. There are a number of enhancements that would be nice in the future. It would be nice to expose the results of past elections. It would also be nice to combine ballots with the Fedora Board when their elections come up so you don't have to go to two URLs to vote. I'd like to see an introductory screen that lists which elections are currently in progress, past elections, and upcoming elections. The voter can click on the past elections to see the results. Current elections asks the voter to login. Once logged in, they are given the ballots for each election they are allowed to vote in. Should voters be able to see current positions on in progress elections? As long as the voting model is simple, it shouldn't be too hard to display the current standings. We will soon have Turbo Gears available for Fedora web apps. The voting application could use this framework if it makes it easier to enhance. Are there other people interested in working on the voting application or am I going to continue to be the primary mover of this project? Feedback ======== Let's discuss these proposals and any other problems people observed with the election process! I'll start a draft of elections policy for FESCo to review and vote on based on the discussion that takes place here. -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 dan at danny.cz Mon Jul 24 18:12:27 2006 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 24 Jul 2006 20:12:27 +0200 Subject: Build Error (Job 13056): tinyerp-3_3_0-2_fc6 on fedora-development-extras In-Reply-To: <20060724174355.AE919152160@buildsys.fedoraproject.org> References: <20060724174355.AE919152160@buildsys.fedoraproject.org> Message-ID: <1153764747.7663.1.camel@eagle.danny.cz> buildsys at fedoraproject.org p??e v Po 24. 07. 2006 v 13:43 -0400: > Job failed on arch noarch: couldn't download result files from builder 'https://ppc1.fedora.redhat.com:8888'. > Please contact the build system administrator. > > Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/13056-tinyerp-3.3.0-2.fc6/ > > Please, can someone look at this? Dan From drfickle at k-lug.org Mon Jul 24 18:14:39 2006 From: drfickle at k-lug.org (Steve Fox) Date: Mon, 24 Jul 2006 13:14:39 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <20060722135834.GD9662@lists.us.dell.com> References: <20060722135834.GD9662@lists.us.dell.com> Message-ID: <1153764879.2749.17.camel@flooterbu> On Sat, 2006-07-22 at 08:58 -0500, Matt Domsch wrote: > libhugetlbfs-0.20060706-1.fc6 drfickle at k-lug.org I've seen libhugetlbfs randomly fail to build, then work on the next attempt without any changes. So there must be some kind of race condition in the build process, however I'm having a difficult time trying to recreate it. If you try to build again does it work? If you can find any way to reliably recreate this I'd really appreciate it. -- Steve Fox http://k-lug.org From sopwith at redhat.com Mon Jul 24 18:22:21 2006 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 24 Jul 2006 14:22:21 -0400 Subject: Future FESCo Elections In-Reply-To: <1153763844.3209.13.camel@localhost> References: <1153763844.3209.13.camel@localhost> Message-ID: <393CBCCB-FBF2-476A-B9D2-A32BB3204F6C@redhat.com> I agree with a lot of the points made, but I think it's important to look at this in perspective: The main reason for having elections is to pick managers & leaders (the two are not the same). The Fedora Extras project is much smaller than, say, a country :) So the elections should be much less of a deal. In a perfect world we would only have elections when the current FESCO was not doing a good job. In this real world, there is still no need to have an election if there are not more non-contingent candidates than there are positions to fill. When you have a project as full of smart people as Fedora is, the differences between candidates will be very minor, so the incentive for people to vote and take part will be very small. There's also probably the perception (correct or not) that not much is at stake in the FESCO election, which also minimizes the incentive to participate. In particular, we should make it clearer why people would choose to vote for one candidate versus another. If it doesn't matter which one you vote for, there's no point in having an election, and we are just all running around trying to play model UN. :) Here are the things that could be done: . Do better messaging around the election. Tell voters and potential candidates why participating matters - what's at stake? . Don't hold elections too often - it sucks time away from more important stuff . Maybe only hold elections when . Focus on recruiting & retaining people as Fedora Extras contributors, because poor election turnout may be a sign of generally bad project health. (Or a healthy project that is too dependant on a few key contributors...) Best, -- Elliot From toshio at tiki-lounge.com Mon Jul 24 19:12:35 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 24 Jul 2006 12:12:35 -0700 Subject: Future FESCo Elections In-Reply-To: <393CBCCB-FBF2-476A-B9D2-A32BB3204F6C@redhat.com> References: <1153763844.3209.13.camel@localhost> <393CBCCB-FBF2-476A-B9D2-A32BB3204F6C@redhat.com> Message-ID: <1153768355.3209.48.camel@localhost> On Mon, 2006-07-24 at 14:22 -0400, Elliot Lee wrote: > I agree with a lot of the points made, but I think it's important to > look at this in perspective: > > The main reason for having elections is to pick managers & leaders > (the two are not the same). > The Fedora Extras project is much smaller than, say, a country :) So > the elections should be much less of a deal. > In a perfect world we would only have elections when the current > FESCO was not doing a good job. > In this real world, there is still no need to have an election if > there are not more non-contingent candidates than there are positions > to fill. > Very true. however, there is one other reason to hold elections -- to legitimize the regime^H^H^H^H^H^H governing body :-) I think in the wake of the decision that the Fedora Foundation was going to cause too many fiscal and legal problems, this was the strongest reason motivating non-FESCo members to ask for an election. To reafirm the community aspect of the Fedora Project. My impression is also that the strongest reason from within FESCo was the feeling that FESCo could be doing more things with new members that had a fresh outlook and more time and energy to devote to pushing projects. So in this case the perfect world needs and the political needs of the community coincided. A new question would then be: how do we balance voter burnout (why do we vote all the time?) with feeling of community control (why haven't we voted in a long time?) and the efficiency of FESCo (replace people too often and they spend all their time trying to get elected rather than running the project) with burnout (replace them infrequently and they begin to have more important things to work on and stop participating.) > When you have a project as full of smart people as Fedora is, the > differences between candidates will be > very minor, so the incentive for people to vote and take part will > be very small. There's also probably the perception > (correct or not) that not much is at stake in the FESCO election, > which also minimizes the incentive to participate. > In particular, we should make it clearer why people would choose to > vote for one candidate versus another. If it > doesn't matter which one you vote for, there's no point in having an > election, and we are just all running around > trying to play model UN. :) Yeah -- I definitely see this. OTOH, having scheduled elections as the traditional method of changing FESCo membership means that when there are larger issues, there is an established method for effecting change. So maybe we should have elections on a non-disruptive timescale and not worry about low voter turn-out; it just means we're making choices that the voters generally agree with. > Here are the things that could be done: > . Do better messaging around the election. Tell voters and potential > candidates why participating matters - what's at stake? What is at stake? In general, elections will make sure the community has a voice and get fresh participants to drive forward new issues in FESCo. In particular, an election is probably about the issues that concern the individual candidates as their the ones who will be driving proposals forward. > . Don't hold elections too often - it sucks time away from more > important stuff Would yearly elections where all seats are up for grabs be better? Having 6 month elections means people have to interrupt their workflow twice a year even if their seat isn't up for election. > . Maybe only hold elections when > . Focus on recruiting & retaining people as Fedora Extras > contributors, because poor election turnout may be a sign of > generally bad project health. (Or a healthy project that is too > dependant on a few key contributors...) That would be worrisome. The question is can we tell this from the election results? Maybe it is a separate issue. Or maybe having elections is an attempt to retain contributors by giving them a voioce in the decision making process. -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 lmacken at redhat.com Mon Jul 24 19:16:18 2006 From: lmacken at redhat.com (Luke Macken) Date: Mon, 24 Jul 2006 15:16:18 -0400 Subject: Future FESCo Elections In-Reply-To: <1153763844.3209.13.camel@localhost> References: <1153763844.3209.13.camel@localhost> Message-ID: <20060724191618.GB2573@localhost.localdomain> On Mon, Jul 24, 2006 at 10:57:24AM -0700, Toshio Kuratomi wrote: [...] > We will soon have Turbo Gears available for Fedora web apps. The voting > application could use this framework if it makes it easier to enhance. The latest stable release of TurboGears (0.8.9) is in extras. I'm currently in the process[0] of shoving the latest alpha 0.9a8, and all of it's deps into the devel branch. luke [0]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189338 From giallu at gmail.com Mon Jul 24 20:43:57 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 24 Jul 2006 22:43:57 +0200 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <1153764879.2749.17.camel@flooterbu> References: <20060722135834.GD9662@lists.us.dell.com> <1153764879.2749.17.camel@flooterbu> Message-ID: On 7/24/06, Steve Fox wrote: > On Sat, 2006-07-22 at 08:58 -0500, Matt Domsch wrote: > > libhugetlbfs-0.20060706-1.fc6 drfickle at k-lug.org > > I've seen libhugetlbfs randomly fail to build, then work on the next > attempt without any changes. So there must be some kind of race > condition in the build process, however I'm having a difficult time > trying to recreate it. If you try to build again does it work? If you > can find any way to reliably recreate this I'd really appreciate it. > Could this be related to smp_mflags? From drfickle at k-lug.org Mon Jul 24 20:57:25 2006 From: drfickle at k-lug.org (Steve Fox) Date: Mon, 24 Jul 2006 15:57:25 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: References: <20060722135834.GD9662@lists.us.dell.com> <1153764879.2749.17.camel@flooterbu> Message-ID: <1153774645.2749.38.camel@flooterbu> On Mon, 2006-07-24 at 22:43 +0200, Gianluca Sforna wrote: > On 7/24/06, Steve Fox wrote: > > On Sat, 2006-07-22 at 08:58 -0500, Matt Domsch wrote: > > > libhugetlbfs-0.20060706-1.fc6 drfickle at k-lug.org > > > > I've seen libhugetlbfs randomly fail to build, then work on the next > > attempt without any changes. So there must be some kind of race > > condition in the build process, however I'm having a difficult time > > trying to recreate it. If you try to build again does it work? If you > > can find any way to reliably recreate this I'd really appreciate it. > > > > Could this be related to smp_mflags? I've tried recreating with 'make -j' for unlimited simultaneous jobs and I still can't make it fail at will. -- Steve Fox http://k-lug.org From bugs.michael at gmx.net Mon Jul 24 21:07:29 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 24 Jul 2006 23:07:29 +0200 Subject: FE devel rebuild? In-Reply-To: <200607221028.20182.jkeating@redhat.com> References: <20060721184012.GD16006@neu.nirvana> <44C1240E.2070307@leemhuis.info> <200607221028.20182.jkeating@redhat.com> Message-ID: <20060724230729.e2f19e25.bugs.michael@gmx.net> On Sat, 22 Jul 2006 10:28:20 -0400, Jesse Keating wrote: > On Friday 21 July 2006 14:59, Thorsten Leemhuis wrote: > > But yes, a script like the one Hans asked for might be helpful. f13 > > probably has one ;-) > > It doesn't work all that well. It could use replacing. You basically need > something that reads in the spec, figures out what int to bump (pre or > post %{?dist} tag, or somewhere else), adds a coherent changelog entry, then > does the simple commit -m 'bump' && make tag build. Attached script can do that for the majority of spec files in FE and FC. The first one takes a string (for the User Name part in the %changelog), a spec file, increments the release number (recognising several different types of setting "Release") and adds a changelog entry. I seem to have forgotten who created the original 'bumpspecfile.py' script which I chose to enhance with the stuff in my Perl version. Elliot Lee probably was the origin, if memory serves correctly. Use the 2nd script at your own risk! It works within FE CVS devel branch, checks out the given packages and can do automated commit/tag/build for multiple packages at once: rebuildrpms.py pkg1 pkg2 pkg3 pkg4 pkg5 -------------- next part -------------- A non-text attachment was scrubbed... Name: bumpspecfile.py Type: application/octet-stream Size: 3684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rebuildrpms.py Type: application/octet-stream Size: 1105 bytes Desc: not available URL: From wtogami at redhat.com Mon Jul 24 21:16:21 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 24 Jul 2006 17:16:21 -0400 Subject: agave review? Message-ID: <44C538A5.6060207@redhat.com> FC-5 FC-4 agave This package was imported into Extras CVS and requested for branching, but I am unable to find the review when searching for "agave" in the subject headers. Where is this review? Please re-request branching when you have supplied this information, for now I am removing the request. Thanks, Warren Togami wtogami at redhat.com From jamatos at fc.up.pt Mon Jul 24 21:30:43 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Mon, 24 Jul 2006 22:30:43 +0100 Subject: agave review? In-Reply-To: <44C538A5.6060207@redhat.com> References: <44C538A5.6060207@redhat.com> Message-ID: <200607242230.44594.jamatos@fc.up.pt> On Monday 24 July 2006 22:16, Warren Togami wrote: > FC-5 FC-4 agave > > This package was imported into Extras CVS and requested for branching, > but I am unable to find the review when searching for "agave" in the > subject headers. Where is this review? As far as I understand from the different messages it seems that agave is the new name of colorscheme. So it is an existing package and not a new package. > Please re-request branching when you have supplied this information, for > now I am removing the request. > > Thanks, > Warren Togami > wtogami at redhat.com -- Jos? Ab?lio From bugs.michael at gmx.net Mon Jul 24 21:39:47 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 24 Jul 2006 23:39:47 +0200 Subject: agave review? In-Reply-To: <44C538A5.6060207@redhat.com> References: <44C538A5.6060207@redhat.com> Message-ID: <20060724233947.2edc2dae.bugs.michael@gmx.net> On Mon, 24 Jul 2006 17:16:21 -0400, Warren Togami wrote: > FC-5 FC-4 agave > > This package was imported into Extras CVS and requested for branching, > but I am unable to find the review when searching for "agave" in the > subject headers. Where is this review? > > Please re-request branching when you have supplied this information, for > now I am removing the request. It is a rename: colorscheme -> agave From gauret at free.fr Mon Jul 24 21:40:35 2006 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jul 2006 23:40:35 +0200 Subject: agave review? In-Reply-To: <44C538A5.6060207@redhat.com> References: <44C538A5.6060207@redhat.com> Message-ID: <200607242340.37961.gauret@free.fr> > This package was imported into Extras CVS and requested for branching, > but I am unable to find the review when searching for "agave" in the > subject headers. Where is this review? It is just a rename of colorscheme (renamed upstream). It is stated in the %changelog and in the cvs log entry for the owners.list commit. > Please re-request branching when you have supplied this information, for > now I am removing the request. OK, I'm re-requesting it. Thanks for your attention, next time I'll specify it in the cvssyncneeded entry too. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Matt_Domsch at dell.com Mon Jul 24 21:54:45 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 24 Jul 2006 16:54:45 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-07-24 Message-ID: <20060724215445.GG1157@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Mon Jul 24 16:18:07 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: argus-2.0.6.fixes.1-11.fc6 197215 NEW bidiv-1.5-3.fc5 197224 NEW flow-tools-0.68-10.fc6 197706 NEW gazpacho-0.6.6-1.fc6 197793 NEW Number failed to build: 92 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 91 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 75 ---------------------------------- azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com camstream-0.26.3-9.fc5 nomis80 at nomis80.org contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net ddskk-12.2.0-7.fc5 petersen at redhat.com diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com epiphany-extensions-2.14.1-1 caillon at redhat.com exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com flim-1.14.7-3 petersen at redhat.com gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de gobby-0.4.0-6.rc2.fc6 lmacken at redhat.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org GtkAda-2.4.0-11.fc5 gemi at bluewin.ch Hermes-1.3.3-7 j.w.r.degoede at hhs.nl ifplugd-0.24-6 aaron.bennett at olin.edu john-1.6-4 ghenry at suretecsystems.com kanatest-0.3.6-4.fc5 robert at marcanoonline.com kdissert-1.0.5-1.1.fc5 icon at fedoraproject.org kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu kover-2.9.6-5 adrian at lisas.de ladspa-1.12-5 thomas at apestaart.org leafpad-0.8.9-1.fc6 ivazquez at ivazquez.net libhugetlbfs-0.20060706-2.fc6 drfickle at k-lug.org librx-1.5-6.fc5 tcallawa at redhat.com libtabe-0.2.6-14 llch at redhat.com libtomoe-gtk-0.1.0-5.fc5 ryo-dairiki at users.sourceforge.net licq-1.3.2-8 pvrabec at redhat.com linkchecker-3.3-3 redhat at flyn.org logjam-4.5.3-4.fc6 tcallawa at redhat.com MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mfstools-2.0-9.snapshot050221.fc5 tcallawa at redhat.com multisync-0.90.18-5.fc5 andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 dennis at ausil.us nautilus-search-tool-0.2-1.fc5 ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 andreas.bierfert at lowlatency.de NetworkManager-vpnc-0.7.0-0.cvs20060529.1.fc6 davidz at redhat.com ngrep-1.44-4.fc5 oliver at linux-kernel.at openal-0.0.9-0.5.20060204cvs.fc5 andreas.bierfert at lowlatency.de opencv-0.9.7-15.fc5 nomis80 at nomis80.org orange-0.3-1.cvs20051118.fc6 andreas.bierfert at lowlatency.de pam_keyring-0.0.7-2 redhat at flyn.org pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.16-1.fc6 gemi at bluewin.ch powerman-1.0.24-1.fc6 jwilson at redhat.com python-goopy-0.1-1 pjones at redhat.com python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net qalculate-kde-0.9.4-1.fc6 dakingun at gmail.com quarry-0.1.16-2.fc5 michel.salim at gmail.com rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rss-glx-0.8.1.p-3.fc6 nphilipp at redhat.com rssowl-1.2-12.fc6 green at redhat.com sabayon-2.12.3-3 markmc at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at scmxx-0.8.2-1.fc5 andreas at bawue.net SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-6.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net sloccount-2.26-4 bnocera at redhat.com stratagus-2.1-5.fc6 lemenkov at newmail.ru syck-0.55-7.fc5 oliver at linux-kernel.at synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xcompmgr-1.1.3-4.fc6 dakingun at gmail.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com xsupplicant-1.2.6-1.fc6 tcallawa at redhat.com With bugs filed: 16 ---------------------------------- alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com ccrtp-1.3.7-1.fc6 ['197362 CLOSED'] andreas at bawue.net cowbell-0.2.7.1-2.fc6 ['197366 CLOSED'] foolish at guezz.net dillo-0.8.6-2.fc6 ['197370 CLOSED'] andreas.bierfert at lowlatency.de fish-1.12.0-1.fc5 ['179296 NEW'] oliver at linux-kernel.at gdesklets-0.35.3-8.fc6 ['197799 NEW'] luya256 at yahoo.com gnomad2-2.8.6-1.fc6 ['197920 NEW'] triad at df.lth.se gnome-applet-music-0.9.0-1.fc6 ['197924 NEW'] ivazquez at ivazquez.net gnome-schedule-1.0.0-1 ['197927 NEW'] frank at scirocco-5v-turbo.de grhino-0.15.0-5.fc5 ['197950 NEW'] michel.salim at gmail.com gtktalog-1.0.4-7.fc5 ['198897 NEW'] matthias at rpmforge.net jam-2.5-3.fc5 ['198924 NEW'] tcallawa at redhat.com nco-3.1.2-1.fc6 ['193541 NEW'] ed at eh3.com xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Mon Jul 24 21:56:15 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 24 Jul 2006 16:56:15 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-24 Message-ID: <20060724215615.GH1157@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Mon Jul 24 16:13:52 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: argus-2.0.6.fixes.1-11.fc6 197215 NEW bidiv-1.5-3.fc5 197224 NEW flow-tools-0.68-10.fc6 197706 NEW gazpacho-0.6.6-1.fc6 197793 NEW Number failed to build: 116 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 105 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 89 ---------------------------------- atitvout-0.4-5 andreas.bierfert at lowlatency.de azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com camstream-0.26.3-9.fc5 nomis80 at nomis80.org contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net ddskk-12.2.0-7.fc5 petersen at redhat.com diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com epiphany-extensions-2.14.1-1 caillon at redhat.com exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com flim-1.14.7-3 petersen at redhat.com foobillard-3.0a-4 mitr at redhat.com freenx-0.5.0-2.fc6 zipsonic at gmail.com gambas-1.0.14-2.fc5 tcallawa at redhat.com gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de gobby-0.4.0-6.rc2.fc6 lmacken at redhat.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org GtkAda-2.4.0-11.fc5 gemi at bluewin.ch ifplugd-0.24-6 aaron.bennett at olin.edu john-1.6-4 ghenry at suretecsystems.com kanatest-0.3.6-4.fc5 robert at marcanoonline.com kdissert-1.0.5-1.1.fc5 icon at fedoraproject.org kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu kover-2.9.6-5 adrian at lisas.de ladspa-1.12-5 thomas at apestaart.org leafpad-0.8.9-1.fc6 ivazquez at ivazquez.net libhugetlbfs-0.20060706-2.fc6 drfickle at k-lug.org libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libtabe-0.2.6-14 llch at redhat.com libtomoe-gtk-0.1.0-5.fc5 ryo-dairiki at users.sourceforge.net licq-1.3.2-8 pvrabec at redhat.com linkchecker-3.3-3 redhat at flyn.org logjam-4.5.3-4.fc6 tcallawa at redhat.com Macaulay2-0.9.8-0.3.cvs20060327.fc6 rdieter at math.unl.edu MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mhonarc-2.6.16-1.fc6 gauret at free.fr mlton-20051202-8.fc6 adam at spicenitz.org multisync-0.90.18-5.fc5 andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 dennis at ausil.us nautilus-search-tool-0.2-1.fc5 ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 andreas.bierfert at lowlatency.de NetworkManager-vpnc-0.7.0-0.cvs20060529.1.fc6 davidz at redhat.com new-1.3.7-2 redhat at flyn.org ngrep-1.44-4.fc5 oliver at linux-kernel.at nx-2.0.0-3.fc6 zipsonic at gmail.com openal-0.0.9-0.5.20060204cvs.fc5 andreas.bierfert at lowlatency.de opencv-0.9.7-15.fc5 nomis80 at nomis80.org pam_keyring-0.0.7-2 redhat at flyn.org perl-Unicode-Map8-0.12-8.fc5 gauret at free.fr perl-Unicode-MapUTF8-1.09-6.fc5 gauret at free.fr php-pear-DB-1.7.6-6 rpm at timj.co.uk pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.16-1.fc6 gemi at bluewin.ch powerman-1.0.24-1.fc6 jwilson at redhat.com python-dateutil-1.1-2.fc5 orion at cora.nwra.com python-goopy-0.1-1 pjones at redhat.com python-reportlab-1.20-5.fc5 bdpepple at ameritech.net python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net q-7.1-2.fc6 gemi at bluewin.ch qalculate-kde-0.9.4-1.fc6 dakingun at gmail.com quarry-0.1.16-2.fc5 michel.salim at gmail.com rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rss-glx-0.8.1.p-3.fc6 nphilipp at redhat.com rssowl-1.2-12.fc6 green at redhat.com sabayon-2.12.3-3 markmc at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at scmxx-0.8.2-1.fc5 andreas at bawue.net SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-6.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net sloccount-2.26-4 bnocera at redhat.com stratagus-2.1-5.fc6 lemenkov at newmail.ru synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com uqm-0.5.0-1.fc5 icon at fedoraproject.org WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xcompmgr-1.1.3-4.fc6 dakingun at gmail.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com xsp-1.1.15-6.fc6 paul at all-the-johnsons.co.uk xsupplicant-1.2.6-1.fc6 tcallawa at redhat.com z88dk-1.6-8.fc5 paul at all-the-johnsons.co.uk With bugs filed: 16 ---------------------------------- alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com ccrtp-1.3.7-1.fc6 ['197362 CLOSED'] andreas at bawue.net cowbell-0.2.7.1-2.fc6 ['197366 CLOSED'] foolish at guezz.net dillo-0.8.6-2.fc6 ['197370 CLOSED'] andreas.bierfert at lowlatency.de fish-1.12.0-1.fc5 ['179296 NEW'] oliver at linux-kernel.at gdesklets-0.35.3-8.fc6 ['197799 NEW'] luya256 at yahoo.com gnomad2-2.8.6-1.fc6 ['197920 NEW'] triad at df.lth.se gnome-applet-music-0.9.0-1.fc6 ['197924 NEW'] ivazquez at ivazquez.net gnome-schedule-1.0.0-1 ['197927 NEW'] frank at scirocco-5v-turbo.de grhino-0.15.0-5.fc5 ['197950 NEW'] michel.salim at gmail.com gtktalog-1.0.4-7.fc5 ['198897 NEW'] matthias at rpmforge.net jam-2.5-3.fc5 ['198924 NEW'] tcallawa at redhat.com nco-3.1.2-1.fc6 ['193541 NEW'] ed at eh3.com xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From pertusus at free.fr Mon Jul 24 22:08:33 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 25 Jul 2006 00:08:33 +0200 Subject: hard time finding packages really for review Message-ID: <20060724220833.GA2691@free.fr> Hello, I have seen floating around the idea that there was a need for reviewers for old reviews. So I started with the packages in FE-NEW with no activity in eight weeks: http://fedoraproject.org/wiki/Extras/PackageStatus?highlight=%28package%29#head-6ebf09953da14bdd17d75280dba5b4cffb941077-3 but I had a hard time to find a package really waiting for a review. In the end I ended up looking at all of them, and here are the statistics (I removed kmobiletools, accepted closed): 7 packages are stuck in review for various reasons 11 packages are stuck because they are waiting for submitters 10 packages were stuck with a need of a reviewer So we have only 10 packages for 28 (about 1/3) that are really waiting for a review. This makes searching for a really open review quite painfull. So I think we should do something to be able to discriminate the packages * stuck for various reasons except needsponsor, including because of packaging guidelines blocking the review like recently some php reviews. * the packages stuck because the submitter has to take an action but hasn't moved for, say, one month. * leave the other packages under review as is. a possible proposal could be along blocking special bugs that would change the background color in the trees like https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-NEW&hide_resolved=1 to a given color. These colors could take precedence over the status (like NEW, ASSIGNED...). It would be nice if it could also be seen on top of the bugreport, but if it is only in Bug xxxxx blocks FE-SUBMITTER-ASLEEP FE-NEW it would be right too. I don't think it should be a must, but something nice to have. some members of the fedora QA team, or anybody else, could for example look from time to time on old reviews and make the blocks. I don't care about that proposal, it is just an idea thrown, it might not be feasible, but I think something should be done to help find where reviewer can really act. Lastly, there could be a procedure for AWOL/MIA submitters similar than the one for AWOL/MIA maintainers, to allow submitters to replace AWOL/MIA submitters and restart a review. This is allready done on a case by case basis, but I think a policy wouldn't hurt here, and having a classification of review stuck by submitter could help to find the AWOL/MIA submitters. Here are the details if you don't trust my numbers :) Review stuck 6: disagreament: fnord freedt licence issue: acx-kmod acx-kmod-common wondering about whether it is a good idea to include in extras or not: alsa-oss phpBB needsponsor 1: gq waiting for submitter 11: smixer smokeping sparse gitweb mondo lurker libpri magic socat fxload kdiff3 Waiting for review 10: xmms-musepack transconnect ardour pyscript Wcl linux-wlan-ng gpc vdr-osdteletext vdr-subtitles sqlgrey -- Pat From tibbs at math.uh.edu Mon Jul 24 22:14:39 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 24 Jul 2006 17:14:39 -0500 Subject: agave review? In-Reply-To: <44C538A5.6060207@redhat.com> (Warren Togami's message of "Mon, 24 Jul 2006 17:16:21 -0400") References: <44C538A5.6060207@redhat.com> Message-ID: >>>>> "WT" == Warren Togami writes: WT> FC-5 FC-4 agave This package was imported into Extras CVS and WT> requested for branching, but I am unable to find the review when WT> searching for "agave" in the subject headers. Where is this WT> review? Would it be reasonable to extend cvs-import.sh to prompt for or somehow accept the URL of the review ticket? That way it could make it into the cvs commit messages and perhaps some other useful location. - J< From pertusus at free.fr Mon Jul 24 22:14:06 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 25 Jul 2006 00:14:06 +0200 Subject: Python submodule naming In-Reply-To: <1153509018.23589.14.camel@localhost> References: <20060721185504.GA4410@crow.rdu.redhat.com> <1153509018.23589.14.camel@localhost> Message-ID: <20060724221406.GB2691@free.fr> > I'd follow the second line of reasoning: If it's "import paste.deploy" > name it "python-paste-deploy". I don't recall this ever being discussed > before, though. Could it be discussed by those who should and added to the packaging guidelines, please? -- Pat From michael at knox.net.nz Mon Jul 24 22:57:49 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 25 Jul 2006 10:57:49 +1200 Subject: hard time finding packages really for review In-Reply-To: <20060724220833.GA2691@free.fr> References: <20060724220833.GA2691@free.fr> Message-ID: <44C5506D.6030002@knox.net.nz> top posting, sorry.. What I find hard about reviewing is figuring out if a package is actually under review or not. I see a metric shit load of comments, suggestions and discussions on some FE-NEW submissions, but they remain unassigned amd in FE-NEW. Sometimes I will skip over a package simply becuase I don't know whats going on. Some folks do the right thing and clearly state they are not reviewing the package, which is great. The package status script would not be able to help in these cases. If people used bug blockers properly, then the script could help. Michael Patrice Dumas wrote: > Hello, > > I have seen floating around the idea that there was a need for reviewers > for old reviews. So I started with the packages in FE-NEW with no activity > in eight weeks: > http://fedoraproject.org/wiki/Extras/PackageStatus?highlight=%28package%29#head-6ebf09953da14bdd17d75280dba5b4cffb941077-3 > but I had a hard time to find a package really waiting for a review. In > the end I ended up looking at all of them, and here are the statistics > (I removed kmobiletools, accepted closed): > > 7 packages are stuck in review for various reasons > 11 packages are stuck because they are waiting for submitters > 10 packages were stuck with a need of a reviewer > > So we have only 10 packages for 28 (about 1/3) that are really waiting > for a review. This makes searching for a really open review quite > painfull. So I think we should do something to be able to discriminate > the packages > > * stuck for various reasons except needsponsor, including > because of packaging guidelines blocking the review like recently some > php reviews. > * the packages stuck because the submitter has to take an action > but hasn't moved for, say, one month. > * leave the other packages under review as is. > > a possible proposal could be along blocking special bugs that would > change the background color in the trees like > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-NEW&hide_resolved=1 > to a given color. These colors could take precedence over the status > (like NEW, ASSIGNED...). It would be nice if it could also be seen on > top of the bugreport, but if it is only in > Bug xxxxx blocks FE-SUBMITTER-ASLEEP FE-NEW > it would be right too. > > I don't think it should be a must, but something nice to have. some > members of the fedora QA team, or anybody else, could for example look > from time to time on old reviews and make the blocks. > > I don't care about that proposal, it is just an idea thrown, it might > not be feasible, but I think something should be done to help find > where reviewer can really act. > > Lastly, there could be a procedure for AWOL/MIA submitters similar than > the one for AWOL/MIA maintainers, to allow submitters to replace > AWOL/MIA submitters and restart a review. This is allready done on a > case by case basis, but I think a policy wouldn't hurt here, and having > a classification of review stuck by submitter could help to find the > AWOL/MIA submitters. > > > > > > Here are the details if you don't trust my numbers :) > > Review stuck 6: > disagreament: > fnord freedt > > licence issue: > acx-kmod acx-kmod-common > > wondering about whether it is a good idea to include in extras or not: > alsa-oss phpBB > > needsponsor 1: > gq > > waiting for submitter 11: > smixer smokeping sparse gitweb mondo lurker libpri magic socat > fxload kdiff3 > > Waiting for review 10: > xmms-musepack transconnect ardour pyscript Wcl linux-wlan-ng gpc > vdr-osdteletext vdr-subtitles sqlgrey > > -- > Pat > From wart at kobold.org Mon Jul 24 23:07:11 2006 From: wart at kobold.org (Michael Thomas) Date: Mon, 24 Jul 2006 16:07:11 -0700 Subject: hard time finding packages really for review In-Reply-To: <44C5506D.6030002@knox.net.nz> References: <20060724220833.GA2691@free.fr> <44C5506D.6030002@knox.net.nz> Message-ID: <44C5529F.9080409@kobold.org> Michael J. Knox wrote: > top posting, sorry.. > > What I find hard about reviewing is figuring out if a package is > actually under review or not. I see a metric shit load of comments, > suggestions and discussions on some FE-NEW submissions, but they remain > unassigned amd in FE-NEW. > Sometimes I will skip over a package simply becuase I don't know whats > going on. Some folks do the right thing and clearly state they are not > reviewing the package, which is great. If the bug has not been assigned to a real person, then it's up for grabs. It's not uncommon for people to jump into a review just to offer criticism/advice/feedback without wanting to commit to a full review. > The package status script would not be able to help in these cases. If > people used bug blockers properly, then the script could help. IMHO, we need look no further than the 'Assigned To' field. --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From bugs.michael at gmx.net Mon Jul 24 23:12:13 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 25 Jul 2006 01:12:13 +0200 Subject: agave review? In-Reply-To: References: <44C538A5.6060207@redhat.com> Message-ID: <20060725011213.257d9dda.bugs.michael@gmx.net> On Mon, 24 Jul 2006 17:14:39 -0500, Jason L Tibbitts III wrote: > Would it be reasonable to extend cvs-import.sh to prompt for or > somehow accept the URL of the review ticket? That way it could make > it into the cvs commit messages and perhaps some other useful > location. That script offers option -m 'message' already. From michael at knox.net.nz Mon Jul 24 23:10:25 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Tue, 25 Jul 2006 11:10:25 +1200 Subject: hard time finding packages really for review In-Reply-To: <44C5529F.9080409@kobold.org> References: <20060724220833.GA2691@free.fr> <44C5506D.6030002@knox.net.nz> <44C5529F.9080409@kobold.org> Message-ID: <44C55361.7030000@knox.net.nz> Michael Thomas wrote: > Michael J. Knox wrote: > >>top posting, sorry.. >> >>What I find hard about reviewing is figuring out if a package is >>actually under review or not. I see a metric shit load of comments, >>suggestions and discussions on some FE-NEW submissions, but they remain >>unassigned amd in FE-NEW. > > >>Sometimes I will skip over a package simply becuase I don't know whats >>going on. Some folks do the right thing and clearly state they are not >>reviewing the package, which is great. > > > If the bug has not been assigned to a real person, then it's up for > grabs. It's not uncommon for people to jump into a review just to offer > criticism/advice/feedback without wanting to commit to a full review. Which is what I figured.. fair game for unclaimed submissions. However, I would still prefer to see some indication if they are reviewing or not. Michael From wart at kobold.org Mon Jul 24 23:17:14 2006 From: wart at kobold.org (Michael Thomas) Date: Mon, 24 Jul 2006 16:17:14 -0700 Subject: hard time finding packages really for review In-Reply-To: <44C55361.7030000@knox.net.nz> References: <20060724220833.GA2691@free.fr> <44C5506D.6030002@knox.net.nz> <44C5529F.9080409@kobold.org> <44C55361.7030000@knox.net.nz> Message-ID: <44C554FA.1070203@kobold.org> Michael J. Knox wrote: > Michael Thomas wrote: > >> Michael J. Knox wrote: >> >>> top posting, sorry.. >>> >>> What I find hard about reviewing is figuring out if a package is >>> actually under review or not. I see a metric shit load of comments, >>> suggestions and discussions on some FE-NEW submissions, but they remain >>> unassigned amd in FE-NEW. >> >> >> >>> Sometimes I will skip over a package simply becuase I don't know whats >>> going on. Some folks do the right thing and clearly state they are not >>> reviewing the package, which is great. >> >> >> >> If the bug has not been assigned to a real person, then it's up for >> grabs. It's not uncommon for people to jump into a review just to offer >> criticism/advice/feedback without wanting to commit to a full review. > > > Which is what I figured.. fair game for unclaimed submissions. However, > I would still prefer to see some indication if they are reviewing or not. This indication should come in the form of setting the 'Assigned To' field. If someone is reviewing a package, or planning on doing a full review, then this field should be set accordingly. Note that you have to look at 'Assigned To', not for 'Status: ASSIGNED' to see if the review is really assigned. If someone decides to unassign themselves, they can set the 'Assigned To' field back to the bugzilla-sink owner, but it's not possible to reset the 'Status' field back to 'NEW'. --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From denis at poolshark.org Mon Jul 24 23:15:48 2006 From: denis at poolshark.org (Denis Leroy) Date: Tue, 25 Jul 2006 01:15:48 +0200 Subject: hard time finding packages really for review In-Reply-To: <44C55361.7030000@knox.net.nz> References: <20060724220833.GA2691@free.fr> <44C5506D.6030002@knox.net.nz> <44C5529F.9080409@kobold.org> <44C55361.7030000@knox.net.nz> Message-ID: <44C554A4.5030107@poolshark.org> Michael J. Knox wrote: > Which is what I figured.. fair game for unclaimed submissions. However, > I would still prefer to see some indication if they are reviewing or not. How do you know if a submission is unclaimed ? It looks like all new submissions are assigned to Thorsten by default... -denis From wart at kobold.org Mon Jul 24 23:21:20 2006 From: wart at kobold.org (Michael Thomas) Date: Mon, 24 Jul 2006 16:21:20 -0700 Subject: hard time finding packages really for review In-Reply-To: <44C554A4.5030107@poolshark.org> References: <20060724220833.GA2691@free.fr> <44C5506D.6030002@knox.net.nz> <44C5529F.9080409@kobold.org> <44C55361.7030000@knox.net.nz> <44C554A4.5030107@poolshark.org> Message-ID: <44C555F0.2000603@kobold.org> Denis Leroy wrote: > Michael J. Knox wrote: > >> Which is what I figured.. fair game for unclaimed submissions. >> However, I would still prefer to see some indication if they are >> reviewing or not. > > > How do you know if a submission is unclaimed ? It looks like all new > submissions are assigned to Thorsten by default... The user 'bugzilla-sing at leemhuis.info' is the default 'unclaimed' user. Anything assigned to that name is fair game. Maybe we should set up something more obvious, such as 'unassigned at fedoraproject.org'? --Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3820 bytes Desc: S/MIME Cryptographic Signature URL: From Christian.Iseli at licr.org Mon Jul 24 22:44:56 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 25 Jul 2006 00:44:56 +0200 Subject: agave review? In-Reply-To: Your message of "Mon, 24 Jul 2006 17:14:39 CDT." Message-ID: <200607242344.k6ONid42024020@mx3.redhat.com> tibbs at math.uh.edu said: > Would it be reasonable to extend cvs-import.sh to prompt for or somehow > accept the URL of the review ticket? That way it could make it into the cvs > commit messages and perhaps some other useful location. I rather like this idea... +1 Christian From tibbs at math.uh.edu Tue Jul 25 02:10:05 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 24 Jul 2006 21:10:05 -0500 Subject: hard time finding packages really for review In-Reply-To: <44C5529F.9080409@kobold.org> (Michael Thomas's message of "Mon, 24 Jul 2006 16:07:11 -0700") References: <20060724220833.GA2691@free.fr> <44C5506D.6030002@knox.net.nz> <44C5529F.9080409@kobold.org> Message-ID: >>>>> "MT" == Michael Thomas writes: MT> IMHO, we need look no further than the 'Assigned To' field. I don't even see why you would care about that. If the bug blocks FE-NEW, it's not under review. The only exceptions I can think of are those that block FE-GUIDELINES, and of course the FE-NEEDSPONSOR bugs that require a sponsor to do the review. If someone takes the bug, they should block FE-REVIEW instead to note that the bug is under review. You'll note that I often ping people to ensure that they do this. I also regularly go through the old tickets and try to make something happen. I pretty much constantly trawl through https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=163776 to find things to work on. That shows dependencies, but you'll also note that some of the non-child bugs are assigned to folks. Some of these cases are bugs that were assigned to someone by mistake; it's not possible to unassign a bug once it's been assigned. Others are simply improperly blocking FE-NEW when they should be blocking FE-REVIEW. - J< From rc040203 at freenet.de Tue Jul 25 05:28:30 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 25 Jul 2006 07:28:30 +0200 Subject: Cross-compilers. In-Reply-To: <20060724191721.GA14927@redhat.com> References: <1153656919.29989.74.camel@shinybook.infradead.org> <20060724191721.GA14927@redhat.com> Message-ID: <1153805310.22104.153.camel@mccallum.corsepiu.local> On Mon, 2006-07-24 at 15:17 -0400, John W. Linville wrote: > On Sun, Jul 23, 2006 at 08:15:18AM -0400, David Woodhouse wrote: > > > Does anyone else care? Other than the full set of rawhide architectures, > > what others would we include? Alpha, SPARC{64,}, ARM, MIPS, SH I assume? > > Would anyone volunteer to maintain each of those toolchains? I wouldn't > > really feel happy doing it myself, since when it comes to GCC I would > > only ever be a package-monkey, and not a proper _maintainer_. > > I think it would be great that have this, for a wide range of arches. /me thinks there is a common misunderstanding. A cross-toolchain doesn't target an "arch" - it targets a "target-system". Such a "target-system" typically consists of an architecture, a libc and and parts of the OS/kernel (sometimes plus further target run-time libraries). E.g. an i386-linux -> mips-linux cross toolchain is a completely different toolchain than a i386-pc-linux -> mips- toolchain. I.e. building a cross-toolchain basically condenses to building and packaging the works the target system maintainers do, and not to develop on the target system (or target arch). > As for maintainance, I'm in the same situation as you. But, if you > can get things rolling I'd be happy to help maintain MIPS and/or > maybe some others. As I tried to express above, arch-specific development is an almost negligible part in building cross-toolchains. The focus is on system-integration. Ralf From dwmw2 at infradead.org Tue Jul 25 05:39:51 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 25 Jul 2006 13:39:51 +0800 Subject: Cross-compilers. In-Reply-To: <1153805310.22104.153.camel@mccallum.corsepiu.local> References: <1153656919.29989.74.camel@shinybook.infradead.org> <20060724191721.GA14927@redhat.com> <1153805310.22104.153.camel@mccallum.corsepiu.local> Message-ID: <1153805992.29119.45.camel@shinybook.infradead.org> On Tue, 2006-07-25 at 07:28 +0200, Ralf Corsepius wrote: > E.g. an i386-linux -> mips-linux cross toolchain is a completely > different toolchain than a i386-pc-linux -> mips- > toolchain. Personally I meant $ARCH-linux-glibc toolchains, but I don't care too much. Multilib is your friend, and it's irrelevant for kernel builds anyway. -- dwmw2 From sundaram at fedoraproject.org Tue Jul 25 08:20:31 2006 From: sundaram at fedoraproject.org (Rahul) Date: Tue, 25 Jul 2006 13:50:31 +0530 Subject: hard time finding packages really for review In-Reply-To: <44C555F0.2000603@kobold.org> References: <20060724220833.GA2691@free.fr> <44C5506D.6030002@knox.net.nz> <44C5529F.9080409@kobold.org> <44C55361.7030000@knox.net.nz> <44C554A4.5030107@poolshark.org> <44C555F0.2000603@kobold.org> Message-ID: <44C5D44F.5070105@fedoraproject.org> Michael Thomas wrote: > Denis Leroy wrote: >> Michael J. Knox wrote: >> >>> Which is what I figured.. fair game for unclaimed submissions. >>> However, I would still prefer to see some indication if they are >>> reviewing or not. >> >> How do you know if a submission is unclaimed ? It looks like all new >> submissions are assigned to Thorsten by default... > > The user 'bugzilla-sing at leemhuis.info' is the default 'unclaimed' user. > Anything assigned to that name is fair game. Maybe we should set up > something more obvious, such as 'unassigned at fedoraproject.org'? > Copying to DKL to make this happen. Rahul From fedora at camperquake.de Tue Jul 25 08:36:09 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 25 Jul 2006 10:36:09 +0200 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <1153774645.2749.38.camel@flooterbu> References: <20060722135834.GD9662@lists.us.dell.com> <1153764879.2749.17.camel@flooterbu> <1153774645.2749.38.camel@flooterbu> Message-ID: <20060725103609.5cb97eff@sisko.addix.net> Hi. On Mon, 24 Jul 2006 15:57:25 -0500, Steve Fox wrote: > I've tried recreating with 'make -j' for unlimited simultaneous jobs > and I still can't make it fail at will. The more important question is: does it fail when using make in non-parallel mode, too? From panemade at gmail.com Tue Jul 25 09:37:48 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Tue, 25 Jul 2006 15:07:48 +0530 Subject: do we have gnomesu command on Fedora? Message-ID: Hi all, I need help in packaging gnome-main-menu package. For more information on my problem you can check https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199681. Regards, Parag. From paul at city-fan.org Tue Jul 25 09:46:06 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 25 Jul 2006 10:46:06 +0100 Subject: do we have gnomesu command on Fedora? In-Reply-To: References: Message-ID: <44C5E85E.6070900@city-fan.org> Parag N(????) wrote: > Hi all, > I need help in packaging gnome-main-menu package. For more > information on my problem you can check > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199681. It's normal practice to use consolehelper in Fedora instead. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/s1-access-console-enable.html Paul. From panemade at gmail.com Tue Jul 25 09:59:30 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Tue, 25 Jul 2006 15:29:30 +0530 Subject: do we have gnomesu command on Fedora? In-Reply-To: <44C5E85E.6070900@city-fan.org> References: <44C5E85E.6070900@city-fan.org> Message-ID: Hi, On 7/25/06, Paul Howarth wrote: > Parag N(????) wrote: > > Hi all, > > I need help in packaging gnome-main-menu package. For more > > information on my problem you can check > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199681. > > It's normal practice to use consolehelper in Fedora instead. > > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/s1-access-console-enable.html Will look at it. But other problem as mentioned in bugzilla is that using main-menu desktop file. Any hints what should we make to execute main-menu desktop file? Anybody have any suggestions what should i do to have third application(main-menu) from gnome-main-menu(currently it is a slab package name) to have working executable as per shown in https://wiki.ubuntu.com/Slab. Regards, Parag. From drfickle at k-lug.org Tue Jul 25 13:18:26 2006 From: drfickle at k-lug.org (Steve Fox) Date: Tue, 25 Jul 2006 08:18:26 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <20060725103609.5cb97eff@sisko.addix.net> References: <20060722135834.GD9662@lists.us.dell.com> <1153764879.2749.17.camel@flooterbu> <1153774645.2749.38.camel@flooterbu> <20060725103609.5cb97eff@sisko.addix.net> Message-ID: <1153833506.2749.43.camel@flooterbu> On Tue, 2006-07-25 at 10:36 +0200, Ralf Ertzinger wrote: > The more important question is: does it fail when using make > in non-parallel mode, too? No, there are no problems building that way. Actually, I don't recall it ever failing to build in non-parallel mode. -- Steve Fox http://k-lug.org From dwmw2 at infradead.org Tue Jul 25 13:35:49 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 25 Jul 2006 21:35:49 +0800 Subject: Cross-compilers. In-Reply-To: <20060725132755.GA30645@redhat.com> References: <1153656919.29989.74.camel@shinybook.infradead.org> <20060724191721.GA14927@redhat.com> <1153805310.22104.153.camel@mccallum.corsepiu.local> <20060725132755.GA30645@redhat.com> Message-ID: <1153834549.29119.97.camel@shinybook.infradead.org> On Tue, 2006-07-25 at 09:27 -0400, John W. Linville wrote: > I was, of course, presuming that the audience of this list would > be interested in targeting linux. Please do forgive me for being so > pertinent. I even presumed that stating "MIPS" might cover both "mips" > (or "mipseb") and "mipsel" -- how sloppy of me. Damn right it does. That's the -EB and -EL options are for. S'not sloppy at all. As I said, multilib is your friend. -- dwmw2 From fedora at camperquake.de Tue Jul 25 13:41:08 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 25 Jul 2006 15:41:08 +0200 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <1153833506.2749.43.camel@flooterbu> References: <20060722135834.GD9662@lists.us.dell.com> <1153764879.2749.17.camel@flooterbu> <1153774645.2749.38.camel@flooterbu> <20060725103609.5cb97eff@sisko.addix.net> <1153833506.2749.43.camel@flooterbu> Message-ID: <20060725154108.1d9f91cb@sisko.addix.net> Hi. On Tue, 25 Jul 2006 08:18:26 -0500, Steve Fox wrote: > No, there are no problems building that way. Actually, I don't recall > it ever failing to build in non-parallel mode. Then just drop the smp_flags from the make call in your spec file (and add a comment, maybe, stating that parallel builds do not work). Parallel builds are a nice extra, but sometimes they do not work due to undefined dependencies in the makefiles, giving raise to the spurious fails you see. From rc040203 at freenet.de Tue Jul 25 13:51:52 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 25 Jul 2006 15:51:52 +0200 Subject: Cross-compilers. In-Reply-To: <20060725132755.GA30645@redhat.com> References: <1153656919.29989.74.camel@shinybook.infradead.org> <20060724191721.GA14927@redhat.com> <1153805310.22104.153.camel@mccallum.corsepiu.local> <20060725132755.GA30645@redhat.com> Message-ID: <1153835512.22104.239.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 09:27 -0400, John W. Linville wrote: > On Tue, Jul 25, 2006 at 07:28:30AM +0200, Ralf Corsepius wrote: > > On Mon, 2006-07-24 at 15:17 -0400, John W. Linville wrote: > > > On Sun, Jul 23, 2006 at 08:15:18AM -0400, David Woodhouse wrote: > > > > > > > Does anyone else care? Other than the full set of rawhide architectures, > > > > what others would we include? Alpha, SPARC{64,}, ARM, MIPS, SH I assume? > > > > Would anyone volunteer to maintain each of those toolchains? I wouldn't > > > > really feel happy doing it myself, since when it comes to GCC I would > > > > only ever be a package-monkey, and not a proper _maintainer_. > > > > > > I think it would be great that have this, for a wide range of arches. > > > > /me thinks there is a common misunderstanding. > > /me thinks what we seem to lack is a common context... > > > A cross-toolchain doesn't target an "arch" - it targets a > > "target-system". > > > > Such a "target-system" typically consists of an architecture, a libc and > > and parts of the OS/kernel (sometimes plus further target run-time > > libraries). > > Thank you so much for your pedantic nit-picking. > I was, of course, presuming that the audience of this list would > be interested in targeting linux. Well, people had been referring to uclinux, avr/avr-libc, mingw32/msys, cygwin/newlib, rtems/newlib, bare metal and ... linux/glibc targets. .. so I am probably not alone with my perception. > But, at least I provided you an opportunity to show how much smarter > you are than the rest of us -- you're welcome. It's just that cross-compilers is a subject I work on for almost a decade and am feel embarrassed when people start talking about "mips" compilers when they actually mean "mips-linux", "mipsel-linux" or "mipseb-linux" targets. Ralf From linville at redhat.com Tue Jul 25 14:00:47 2006 From: linville at redhat.com (John W. Linville) Date: Tue, 25 Jul 2006 10:00:47 -0400 Subject: Cross-compilers. In-Reply-To: <1153835512.22104.239.camel@mccallum.corsepiu.local> References: <1153656919.29989.74.camel@shinybook.infradead.org> <20060724191721.GA14927@redhat.com> <1153805310.22104.153.camel@mccallum.corsepiu.local> <20060725132755.GA30645@redhat.com> <1153835512.22104.239.camel@mccallum.corsepiu.local> Message-ID: <20060725140047.GD30645@redhat.com> On Tue, Jul 25, 2006 at 03:51:52PM +0200, Ralf Corsepius wrote: > On Tue, 2006-07-25 at 09:27 -0400, John W. Linville wrote: > > I was, of course, presuming that the audience of this list would > > be interested in targeting linux. > Well, people had been referring to uclinux, avr/avr-libc, mingw32/msys, > cygwin/newlib, rtems/newlib, bare metal and ... linux/glibc targets. > > .. so I am probably not alone with my perception. Well, perhaps you are right. I apologize if I reacted too harshly. For the record...unless explicitly stated otherwise, by referring only to a processor arch in this discussion I am implying linux and glibc for the target. Allowing for other targets seems worthwhile as well, FWIW... Thanks, John -- John W. Linville linville at redhat.com From rdieter at math.unl.edu Tue Jul 25 14:06:16 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 09:06:16 -0500 Subject: Python submodule naming References: <20060721185504.GA4410@crow.rdu.redhat.com> <1153509018.23589.14.camel@localhost> <20060724221406.GB2691@free.fr> Message-ID: Patrice Dumas wrote: >> I'd follow the second line of reasoning: If it's "import paste.deploy" >> name it "python-paste-deploy". I don't recall this ever being discussed >> before, though. > > Could it be discussed by those who should and added to the packaging > guidelines, please? It *is* currently under discussion. Hopefully it'll get sorted out soon. -- Rex From drfickle at k-lug.org Tue Jul 25 14:11:26 2006 From: drfickle at k-lug.org (Steve Fox) Date: Tue, 25 Jul 2006 09:11:26 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-22 In-Reply-To: <20060725154108.1d9f91cb@sisko.addix.net> References: <20060722135834.GD9662@lists.us.dell.com> <1153764879.2749.17.camel@flooterbu> <1153774645.2749.38.camel@flooterbu> <20060725103609.5cb97eff@sisko.addix.net> <1153833506.2749.43.camel@flooterbu> <20060725154108.1d9f91cb@sisko.addix.net> Message-ID: <1153836687.2749.47.camel@flooterbu> On Tue, 2006-07-25 at 15:41 +0200, Ralf Ertzinger wrote: > Then just drop the smp_flags from the make call in your spec file > (and add a comment, maybe, stating that parallel builds do not > work). Parallel builds are a nice extra, but sometimes they do not work > due to undefined dependencies in the makefiles, giving raise to the > spurious fails you see. Ok, I've done that. Thanks. -- Steve Fox http://k-lug.org From rdieter at math.unl.edu Tue Jul 25 14:20:36 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 09:20:36 -0500 Subject: Python submodule naming References: <20060721185504.GA4410@crow.rdu.redhat.com> <1153509018.23589.14.camel@localhost> <20060724221406.GB2691@free.fr> Message-ID: Rex Dieter wrote: > Patrice Dumas wrote: > >>> I'd follow the second line of reasoning: If it's "import paste.deploy" >>> name it "python-paste-deploy". I don't recall this ever being discussed >>> before, though. >> >> Could it be discussed by those who should and added to the packaging >> guidelines, please? > > It *is* currently under discussion. Hopefully it'll get sorted out soon. See also: http://fedoraproject.org/wiki/Packaging/GuidelinesTodo -- Rex From dimitris at glezos.com Tue Jul 25 14:55:11 2006 From: dimitris at glezos.com (Dimitris Glezos) Date: Tue, 25 Jul 2006 15:55:11 +0100 Subject: do we have gnomesu command on Fedora? In-Reply-To: <44C5E85E.6070900@city-fan.org> References: <44C5E85E.6070900@city-fan.org> Message-ID: <44C630CF.2090709@glezos.com> O/H Paul Howarth ??????: > Parag N(????) wrote: >> Hi all, >> I need help in packaging gnome-main-menu package. For more >> information on my problem you can check >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199681. > > It's normal practice to use consolehelper in Fedora instead. There are many environments, like personal workstations at universities and work, that a user is not given the root password and is only included in the sudoers file to manage his workstation. Thus, he can't use the current consolehelper method that requires a root password. One approach to start a root-needing application is: $ xhost +localhost $ sudo system-config-mouse && xhost -localhost Are there *no* plans to find a solution to this security hazard and totally user unfriently workaround? I understand that consolehelper is a much better option, but it just doesn't work for *many* users. And the above workaround is far worse in security than gnomesu et al. -dim > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/s1-access-console-enable.html > > > Paul. > -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From pertusus at free.fr Tue Jul 25 14:58:20 2006 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 25 Jul 2006 16:58:20 +0200 Subject: Is the guidelines BuildRoot preferred? Message-ID: <20060725145820.GA2489@free.fr> Hello, In the Guidelines, there is The preferred value for the BuildRoot tag is ..... What dose is means exactly? I was under the impression that this was a MUST item. But Enrico and Matthias disagree in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189662 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188461 What is the exact status of the BuildRoot tag and if it isn't a must what are the acceptable values? -- Pat From dimitris at glezos.com Tue Jul 25 15:03:00 2006 From: dimitris at glezos.com (Dimitris Glezos) Date: Tue, 25 Jul 2006 16:03:00 +0100 Subject: do we have gnomesu command on Fedora? In-Reply-To: <44C5E85E.6070900@city-fan.org> References: <44C5E85E.6070900@city-fan.org> Message-ID: <44C632A4.9090008@glezos.com> O/H Paul Howarth ??????: > Parag N(????) wrote: >> Hi all, >> I need help in packaging gnome-main-menu package. For more >> information on my problem you can check >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199681. > > It's normal practice to use consolehelper in Fedora instead. See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185517 -dim (sorry for the double msg) > > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/s1-access-console-enable.html > > > Paul. > -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From sundaram at fedoraproject.org Tue Jul 25 15:08:16 2006 From: sundaram at fedoraproject.org (Rahul) Date: Tue, 25 Jul 2006 20:38:16 +0530 Subject: do we have gnomesu command on Fedora? In-Reply-To: <44C630CF.2090709@glezos.com> References: <44C5E85E.6070900@city-fan.org> <44C630CF.2090709@glezos.com> Message-ID: <44C633E0.5050702@fedoraproject.org> Dimitris Glezos wrote: > O/H Paul Howarth ??????: >> Parag N(????) wrote: >>> Hi all, >>> I need help in packaging gnome-main-menu package. For more >>> information on my problem you can check >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199681. >> It's normal practice to use consolehelper in Fedora instead. > > There are many environments, like personal workstations at universities > and work, that a user is not given the root password and is only > included in the sudoers file to manage his workstation. Thus, he can't > use the current consolehelper method that requires a root password. > > One approach to start a root-needing application is: > > $ xhost +localhost > $ sudo system-config-mouse && xhost -localhost > > Are there *no* plans to find a solution to this security hazard and > totally user unfriently workaround? > > I understand that consolehelper is a much better option, but it just > doesn't work for *many* users. And the above workaround is far worse in > security than gnomesu et al. > This thread shouldnt really be hijacked to discuss this but since you asked, the long term plan is PolicyKit http://lists.freedesktop.org/archives/hal/2006-March/004770.html http://lists.freedesktop.org/archives/hal/2006-January/004377.html http://blog.fubar.dk/?p=66 http://searchopensource.techtarget.com/tip/1,289483,sid39_gci1173575,00.html http://people.freedesktop.org/~david/talks/system-integration-and-gnome-guadec2006-davidz.pdf Rahul From dcbw at redhat.com Tue Jul 25 15:11:04 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 25 Jul 2006 10:11:04 -0500 Subject: Build Error (Job 13056): tinyerp-3_3_0-2_fc6 on fedora-development-extras In-Reply-To: <1153764747.7663.1.camel@eagle.danny.cz> References: <20060724174355.AE919152160@buildsys.fedoraproject.org> <1153764747.7663.1.camel@eagle.danny.cz> Message-ID: <1153840264.2628.0.camel@localhost.localdomain> On Mon, 2006-07-24 at 20:12 +0200, Dan Hor?k wrote: > buildsys at fedoraproject.org p??e v Po 24. 07. 2006 v 13:43 -0400: > > Job failed on arch noarch: couldn't download result files from builder 'https://ppc1.fedora.redhat.com:8888'. > > Please contact the build system administrator. > > > > Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/13056-tinyerp-3.3.0-2.fc6/ > > > > > > Please, can someone look at this? Requeue the build with 'plague-client requeue '. It's likely a transient error. Dan From fedora at leemhuis.info Tue Jul 25 15:30:40 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 25 Jul 2006 17:30:40 +0200 Subject: hard time finding packages really for review In-Reply-To: <44C5D44F.5070105@fedoraproject.org> References: <20060724220833.GA2691@free.fr> <44C5506D.6030002@knox.net.nz> <44C5529F.9080409@kobold.org> <44C55361.7030000@knox.net.nz> <44C554A4.5030107@poolshark.org> <44C555F0.2000603@kobold.org> <44C5D44F.5070105@fedoraproject.org> Message-ID: <44C63920.2010808@leemhuis.info> Rahul schrieb: > Michael Thomas wrote: >> Denis Leroy wrote: >>> Michael J. Knox wrote: >>>> Which is what I figured.. fair game for unclaimed submissions. >>>> However, I would still prefer to see some indication if they are >>>> reviewing or not. >>> How do you know if a submission is unclaimed ? It looks like all new >>> submissions are assigned to Thorsten by default... >> The user 'bugzilla-sing at leemhuis.info' >> is the default 'unclaimed' user. "sink" actually -- that mailbox also has the comment "ignored mailbox" to indicate that it ignored ;-) >> Anything assigned to that name is fair game. Maybe we should set up >> something more obvious, such as 'unassigned at fedoraproject.org'? > Copying to DKL to make this happen. Well, yes, that might be better. But we first should make sure that such an email address at least exists. So I assume the infrastructure group or skvidal are those that have to do the first step. Does anyone want to poke them? BTW and just FYI: bugzilla-sink at leemhuis.info seems to be an interesting user -- he does not exist, but he did 13 reviews already according to http://www.fedoraproject.org/wiki/Extras/PackageStatus and https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=179904,180068,181013,183097,183694,185407,186327,190949,191208,195692,196635,197753,197796 ;-) CU thl From dimitris at glezos.com Tue Jul 25 15:30:13 2006 From: dimitris at glezos.com (Dimitris Glezos) Date: Tue, 25 Jul 2006 16:30:13 +0100 Subject: do we have gnomesu command on Fedora? In-Reply-To: <44C633E0.5050702@fedoraproject.org> References: <44C5E85E.6070900@city-fan.org> <44C630CF.2090709@glezos.com> <44C633E0.5050702@fedoraproject.org> Message-ID: <44C63905.8080603@glezos.com> O/H Rahul ??????: > Dimitris Glezos wrote: >> Are there *no* plans to find a solution to this security hazard and >> totally user unfriently workaround? > This thread shouldnt really be hijacked to discuss this but since you > asked, the long term plan is PolicyKit So there *are* plans. Great then! :) Thanks for the references. -dim > http://lists.freedesktop.org/archives/hal/2006-March/004770.html > http://lists.freedesktop.org/archives/hal/2006-January/004377.html > http://blog.fubar.dk/?p=66 > http://searchopensource.techtarget.com/tip/1,289483,sid39_gci1173575,00.html > > http://people.freedesktop.org/~david/talks/system-integration-and-gnome-guadec2006-davidz.pdf > > > Rahul -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From Christian.Iseli at licr.org Tue Jul 25 15:32:49 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Tue, 25 Jul 2006 17:32:49 +0200 Subject: hard time finding packages really for review In-Reply-To: Your message of "Tue, 25 Jul 2006 17:30:40 +0200." <44C63920.2010808@leemhuis.info> Message-ID: <200607251532.k6PFWndD000595@ludwig-alpha.unil.ch> fedora at leemhuis.info said: > BTW and just FYI: bugzilla-sink at leemhuis.info seems to be an interesting user > -- he does not exist, but he did 13 reviews already according to http:// > www.fedoraproject.org/wiki/Extras/PackageStatus and https://bugzilla.redhat.co > m/bugzilla/buglist.cgi?bug_id=179904,180068,181013,183097,183694,185407,186327 > ,190949,191208,195692,196635,197753,197796 Yea, time to get him to be a sponsor :-D Anyway, while on the topic: I wanted to properly assign those bugs the other day, but it seems impossible unless they are re-opened ? Or am I missing something ? Christian From mattdm at mattdm.org Tue Jul 25 15:59:31 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 25 Jul 2006 11:59:31 -0400 Subject: Cross-compilers. In-Reply-To: <20060725132755.GA30645@redhat.com> References: <1153656919.29989.74.camel@shinybook.infradead.org> <20060724191721.GA14927@redhat.com> <1153805310.22104.153.camel@mccallum.corsepiu.local> <20060725132755.GA30645@redhat.com> Message-ID: <20060725155931.GA13486@jadzia.bu.edu> On Tue, Jul 25, 2006 at 09:27:56AM -0400, John W. Linville wrote: > I was, of course, presuming that the audience of this list would > be interested in targeting linux. Please do forgive me for being so Well, I am, but I'm also interested in Linux as a platform for cross-OS development. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at leemhuis.info Tue Jul 25 16:05:29 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 25 Jul 2006 18:05:29 +0200 Subject: Future FESCo Elections In-Reply-To: <393CBCCB-FBF2-476A-B9D2-A32BB3204F6C@redhat.com> References: <1153763844.3209.13.camel@localhost> <393CBCCB-FBF2-476A-B9D2-A32BB3204F6C@redhat.com> Message-ID: <44C64149.70100@leemhuis.info> Elliot Lee schrieb: > I agree with a lot of the points made, +1 > but I think it's important to > look at this in perspective: > [...] > In a perfect world we would only have elections when the current > FESCO was not doing a good job. I disagree with that statement. I think it is really important to get new people into FESCo now and then (and the old ones out without to much hassle if they are inactive) because the new ones often come with new enthusiasm and fresh ideas. >[...] > . Don't hold elections too often - it sucks time away from more > important stuff I'm unsure about this one. Yes, it might consume some time to perform the election, but with the voting app in place now it's relative easy to organize the election. And the voting itself is easy, too, and performed in one or two minutes. CU thl From fedora at leemhuis.info Tue Jul 25 16:12:39 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 25 Jul 2006 18:12:39 +0200 Subject: Future FESCo Elections In-Reply-To: <1153768355.3209.48.camel@localhost> References: <1153763844.3209.13.camel@localhost> <393CBCCB-FBF2-476A-B9D2-A32BB3204F6C@redhat.com> <1153768355.3209.48.camel@localhost> Message-ID: <44C642F7.2070003@leemhuis.info> Toshio Kuratomi schrieb: > On Mon, 2006-07-24 at 14:22 -0400, Elliot Lee wrote: >> . Don't hold elections too often - it sucks time away from more >> important stuff > > Would yearly elections where all seats are up for grabs be better? > Having 6 month elections means people have to interrupt their workflow > twice a year even if their seat isn't up for election. Why do they have to interrupt their workflow? Everyone can contribute to Extras. I really dislike the "FESCo-members must do all the work" attitude. I'd really would like to see more non-FESCo-Members get involved into Extras work e.g. write proposals and help getting stuff done. In other words: If your seat is up for election and you don't get elected anew just finish your work together with the new FESCo and everyone is happy. CU thl From rdieter at math.unl.edu Tue Jul 25 16:11:06 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 11:11:06 -0500 Subject: Is the guidelines BuildRoot preferred? References: <20060725145820.GA2489@free.fr> Message-ID: Patrice Dumas wrote: > Hello, > > In the Guidelines, there is > > The preferred value for the BuildRoot tag is > ..... > > What dose is means exactly? I was under the impression that this was > a MUST item. If the Guidelines don't *say* MUST, it isn't. So, no. -- Rex From seg at haxxed.com Tue Jul 25 16:28:38 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 25 Jul 2006 11:28:38 -0500 Subject: rpms/sextractor/FC-4 sextractor.spec,1.2,1.3 In-Reply-To: <1153623782.5125.13.camel@mccallum.corsepiu.local> References: <200607211724.k6LHO3Z8023012@cvs-int.fedora.redhat.com> <1153508980.18981.125.camel@mccallum.corsepiu.local> <1153537475.18981.150.camel@mccallum.corsepiu.local> <1153571226.30083.31.camel@laurel.intra.city-fan.org> <1153623782.5125.13.camel@mccallum.corsepiu.local> Message-ID: <1153844918.19749.5.camel@localhost> On Sun, 2006-07-23 at 05:03 +0200, Ralf Corsepius wrote: > > # -O3 required for performance reasons > > CFLAGS="$(echo '%{optflags}' | sed -e 's/-O[0-9]*//') -O3" > > make CFLAGS="$CFLAGS" > > Bummer. This is even worse. > > Again, the way this package's maintainer set CFLAGS is OK, but what he > does is embarrassing. Seems as if he doesn't know what he is doing. > > I am going to file a request to packaging committee to ban -O3 and > -fomit-frame-pointer You should be able to just put the -O3 or whatever on the end. From the gcc manual: "If you use multiple `-O' options, with or without level numbers, the last such option is the one that is effective." Also from the gcc manual: "`-O' also turns on `-fomit-frame-pointer' on machines where doing so does not interfere with debugging." So banning -fomit-frame-pointer makes sense, as optimization will already turn it on if it doesn't break debugging. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue Jul 25 16:52:40 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 25 Jul 2006 11:52:40 -0500 Subject: Question about WAV In-Reply-To: <200607221906.21126.nman64@n-man.com> References: <668bb39a0607221612g6e6a2d26o4c7ad54a27397bf8@mail.gmail.com> <200607221906.21126.nman64@n-man.com> Message-ID: <1153846361.19749.17.camel@localhost> On Sat, 2006-07-22 at 19:06 -0500, Patrick W. Barnes wrote: > Even if there were patents on the format, they would have already expired. I don't thing RIFF/WAV is quite that old, (RIFF came about in 1991 according to wikipedia) but they're just a direct ripoff of IFF from the Amiga, so Electronic Arts would have had prior art. EA introduced IFF in 1985 according to wikipedia so had they patented it then, it would have just expired last year. http://en.wikipedia.org/wiki/RIFF http://en.wikipedia.org/wiki/Interchange_File_Format This is exactly why the ASF format exists, so that Microsoft could get a patent on it: http://en.wikipedia.org/wiki/Advanced_Systems_Format (this has been another useless fact) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue Jul 25 17:01:37 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 25 Jul 2006 12:01:37 -0500 Subject: Cross-compilers. In-Reply-To: <20060725155931.GA13486@jadzia.bu.edu> References: <1153656919.29989.74.camel@shinybook.infradead.org> <20060724191721.GA14927@redhat.com> <1153805310.22104.153.camel@mccallum.corsepiu.local> <20060725132755.GA30645@redhat.com> <20060725155931.GA13486@jadzia.bu.edu> Message-ID: <1153846897.19749.21.camel@localhost> One thing to look keep in mind, is if distcc ever makes it in, it would be quite handy for, say, my old iMac 266mhz to farm out building to a cross compiler on my 2ghz Athlon64... -------------- 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 orion at cora.nwra.com Tue Jul 25 17:20:03 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 25 Jul 2006 11:20:03 -0600 Subject: Need help with python noarch package Message-ID: <44C652C3.4090600@cora.nwra.com> I have a noarch python package (python-dateutil) that doesn't build properly on x86_64. The setup is: PYTHONLIB = join(get_python_lib(standard_lib=1, prefix=''), 'site-packages') ZONEINFO = join("dateutil", "zoneinfo") setup(name="python-dateutil", version = "1.1", description = "Extensions to the standard python 2.3+ datetime module", author = "Gustavo Niemeyer", author_email = "gustavo at niemeyer.net", url = "http://labix.org/python-dateutil", license = "PSF License", long_description = """\ The dateutil module provides powerful extensions to the standard datetime module, available in Python 2.3+. """, packages = ["dateutil", "dateutil.zoneinfo"], data_files = [(join(PYTHONLIB, ZONEINFO), glob.glob(join(ZONEINFO, "zoneinfo*.tar.*")))], ) but the files specified in data_files (zoneinfo-2005q.tar.gz) end up going into /usr/lib64/python2.4/site-packages/... rather than /usr/lib/python2.4/... Is this expected? The rest of the package gets installed in /usr/lib. What should be used to get the data file installed in /usr/lib as well? Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From peter at thecodergeek.com Tue Jul 25 17:51:23 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 25 Jul 2006 10:51:23 -0700 (PDT) Subject: Is the guidelines BuildRoot preferred? In-Reply-To: References: <20060725145820.GA2489@free.fr> Message-ID: <53445.127.0.0.1.1153849883.squirrel@www.thecodergeek.com> Rex Dieter wrote: > Patrice Dumas wrote: [...] >> In the Guidelines, there is >> >> The preferred value for the BuildRoot tag is >> ..... >> >> What [does it] means exactly? I was under the impression that this was >> a MUST item. > > If the Guidelines don't *say* MUST, it isn't. So, no. Well, alot of the Guidelines don't explicitly require a strict convention. However, for the sake of clarity and because this is generally a blocker on review requests, I believe it best for this guideline to be considered a MUST. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From peter at thecodergeek.com Tue Jul 25 18:08:22 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 25 Jul 2006 11:08:22 -0700 (PDT) Subject: Need help with python noarch package In-Reply-To: <44C652C3.4090600@cora.nwra.com> References: <44C652C3.4090600@cora.nwra.com> Message-ID: <54342.127.0.0.1.1153850902.squirrel@www.thecodergeek.com> Orion Poplawski wrote: [...] > but the files specified in data_files (zoneinfo-2005q.tar.gz) end up > going into /usr/lib64/python2.4/site-packages/... rather than > /usr/lib/python2.4/... > > Is this expected? The rest of the package gets installed in /usr/lib. > What should be used to get the data file installed in /usr/lib as well? Have you ensured that you have the proper %python_sitelib and %python_sitearch macros defined? You can get these from the Packaging/Python page on the Wiki: http://fedoraproject.org/wiki/Packaging/Python Hope that helps. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From rdieter at math.unl.edu Tue Jul 25 18:15:03 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 13:15:03 -0500 Subject: Is the guidelines BuildRoot preferred? References: <20060725145820.GA2489@free.fr> <53445.127.0.0.1.1153849883.squirrel@www.thecodergeek.com> Message-ID: Peter Gordon wrote: > Rex Dieter wrote: >> Patrice Dumas wrote: > [...] >>> In the Guidelines, there is >>> The preferred value for the BuildRoot tag is >>> ..... >>> What [does it] means exactly? I was under the impression that this was >>> a MUST item. >> If the Guidelines don't *say* MUST, it isn't. So, no. > Well, alot of the Guidelines don't explicitly require a strict convention. > However, for the sake of clarity and because this is generally a blocker > on review requests, I believe it best for this guideline to be considered > a MUST. Some members of the packaging committee (me, at least) disagree making this a MUST. Of course, it's a reviewers' prerogative how seriously to treat non-MUST items. IMO, in this case, since it is not a MUST item, non-broken BuildRoots (that don't match the "preferred" value) shouldn't be blocker. -- Rex From mattdm at mattdm.org Tue Jul 25 18:15:32 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 25 Jul 2006 14:15:32 -0400 Subject: do we have gnomesu command on Fedora? In-Reply-To: <44C630CF.2090709@glezos.com> References: <44C5E85E.6070900@city-fan.org> <44C630CF.2090709@glezos.com> Message-ID: <20060725181532.GA17143@jadzia.bu.edu> On Tue, Jul 25, 2006 at 03:55:11PM +0100, Dimitris Glezos wrote: > There are many environments, like personal workstations at universities > and work, that a user is not given the root password and is only > included in the sudoers file to manage his workstation. Thus, he can't > use the current consolehelper method that requires a root password. Put the user in the group "wheel". Put "UGROUPS=wheel" in the corresponding consolehelper config file. Presto -- sudo-like behavior. (But the policykit approach is the best for the future -- running GUI apps as root is just asking for trouble.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rc040203 at freenet.de Tue Jul 25 18:23:50 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 25 Jul 2006 20:23:50 +0200 Subject: Is the guidelines BuildRoot preferred? In-Reply-To: References: <20060725145820.GA2489@free.fr> <53445.127.0.0.1.1153849883.squirrel@www.thecodergeek.com> Message-ID: <1153851830.22104.330.camel@mccallum.corsepiu.local> On Tue, 2006-07-25 at 13:15 -0500, Rex Dieter wrote: > Peter Gordon wrote: > > > Rex Dieter wrote: > >> Patrice Dumas wrote: > > [...] > >>> In the Guidelines, there is > >>> The preferred value for the BuildRoot tag is > >>> ..... > > >>> What [does it] means exactly? I was under the impression that this was > >>> a MUST item. > > >> If the Guidelines don't *say* MUST, it isn't. So, no. > > > Well, alot of the Guidelines don't explicitly require a strict convention. > > However, for the sake of clarity and because this is generally a blocker > > on review requests, I believe it best for this guideline to be considered > > a MUST. > > Some members of the packaging committee (me, at least) disagree making this > a MUST. And some members (me, at least) disagree on this disagreement. Ralf From rdieter at math.unl.edu Tue Jul 25 18:34:45 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 13:34:45 -0500 Subject: Is the guidelines BuildRoot preferred? References: <20060725145820.GA2489@free.fr> <53445.127.0.0.1.1153849883.squirrel@www.thecodergeek.com> <1153851830.22104.330.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > On Tue, 2006-07-25 at 13:15 -0500, Rex Dieter wrote: >> Peter Gordon wrote: >> >> > Rex Dieter wrote: >> >> Patrice Dumas wrote: >> > [...] >> >>> In the Guidelines, there is >> >>> The preferred value for the BuildRoot tag is >> >>> ..... >> >> >>> What [does it] means exactly? I was under the impression that this >> >>> was a MUST item. >> >> >> If the Guidelines don't *say* MUST, it isn't. So, no. >> >> > Well, alot of the Guidelines don't explicitly require a strict >> > convention. However, for the sake of clarity and because this is >> > generally a blocker on review requests, I believe it best for this >> > guideline to be considered a MUST. >> >> Some members of the packaging committee (me, at least) disagree making >> this a MUST. > And some members (me, at least) disagree on this disagreement. Hence, why the current guidelines don't say this is a MUST item. (: -- Rex From rdieter at math.unl.edu Tue Jul 25 18:36:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 13:36:17 -0500 Subject: do we have gnomesu command on Fedora? References: <44C5E85E.6070900@city-fan.org> Message-ID: Paul Howarth wrote: > Parag N(????) wrote: >> Hi all, >> I need help in packaging gnome-main-menu package. For more >> information on my problem you can check >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199681. > > It's normal practice to use consolehelper in Fedora instead. Unfortunately, consolehelper only seems to work for local/console logins, and not for remote ones. It least, it's never worked for me when using remote logins (whereas kdesu *does* work, for example). -- Rex From cweyl at alumni.drew.edu Tue Jul 25 19:55:24 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 25 Jul 2006 12:55:24 -0700 Subject: rpms/sextractor/FC-4 sextractor.spec,1.2,1.3 In-Reply-To: <1153623782.5125.13.camel@mccallum.corsepiu.local> References: <200607211724.k6LHO3Z8023012@cvs-int.fedora.redhat.com> <1153508980.18981.125.camel@mccallum.corsepiu.local> <1153537475.18981.150.camel@mccallum.corsepiu.local> <1153571226.30083.31.camel@laurel.intra.city-fan.org> <1153623782.5125.13.camel@mccallum.corsepiu.local> Message-ID: <7dd7ab490607251255q77e36151p7a468380ca5acd38@mail.gmail.com> On 7/22/06, Ralf Corsepius wrote: > I am going to file a request to packaging committee to ban -O3 and > -fomit-frame-pointer Erm, not to pour gasoline on a fire, but this brings up some very interesting questions. What is the scope/purview of the packaging committee, and is it defined anywhere? Regardless of the merits of this issue, does something like this -- how to actually _build_ software for extras -- more properly fall under, say, FESCo's jurisdiction? I don't have a vested interest one way or the other. I'm just curious :) -Chris -- Chris Weyl Ex astris, scientia From jkeating at redhat.com Tue Jul 25 20:00:31 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 25 Jul 2006 16:00:31 -0400 Subject: rpms/sextractor/FC-4 sextractor.spec,1.2,1.3 In-Reply-To: <7dd7ab490607251255q77e36151p7a468380ca5acd38@mail.gmail.com> References: <200607211724.k6LHO3Z8023012@cvs-int.fedora.redhat.com> <1153623782.5125.13.camel@mccallum.corsepiu.local> <7dd7ab490607251255q77e36151p7a468380ca5acd38@mail.gmail.com> Message-ID: <200607251600.34414.jkeating@redhat.com> On Tuesday 25 July 2006 15:55, Chris Weyl wrote: > Erm, not to pour gasoline on a fire, but this brings up some very > interesting questions. ?What is the scope/purview of the packaging > committee, and is it defined anywhere? ?Regardless of the merits of > this issue, does something like this -- how to actually _build_ > software for extras -- more properly fall under, say, FESCo's > jurisdiction? The packaging committee covers guidelines for both Core and Extras (and RHEL5 too if you want to know), so there are more than just FESCO that have vested interest. In reality, the Fedora Board has jurisdiction and has appointed the packaging committee to oversee it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mr.ecik at gmail.com Tue Jul 25 20:27:19 2006 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Tue, 25 Jul 2006 22:27:19 +0200 Subject: Something wrong in buildsys? Message-ID: <668bb39a0607251327t2f532a7di64a81bda9f57d756@mail.gmail.com> When I took a look on buildsys site today, I saw one package is building for over one day. Does that mean that there is something wrong with build system? Isn't it blocking the system? Maybe there is need to explicitly kill these builds. I don't believe that the build will end at any time. Also, I noticed that yesterday, I didn't recieve buildys package build report. Isn't it related to these unbuilt packages? From rdieter at math.unl.edu Tue Jul 25 20:49:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jul 2006 15:49:17 -0500 Subject: Something wrong in buildsys? References: <668bb39a0607251327t2f532a7di64a81bda9f57d756@mail.gmail.com> Message-ID: Micha? Bentkowski wrote: > When I took a look on buildsys site today, I saw one package is > building for over one day. I already reported it to http://admin.fedoraproject.org/tickets/ this morning. -- Rex From Axel.Thimm at ATrpms.net Tue Jul 25 21:20:02 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jul 2006 23:20:02 +0200 Subject: Is the guidelines BuildRoot preferred? In-Reply-To: <1153851830.22104.330.camel@mccallum.corsepiu.local> References: <20060725145820.GA2489@free.fr> <53445.127.0.0.1.1153849883.squirrel@www.thecodergeek.com> <1153851830.22104.330.camel@mccallum.corsepiu.local> Message-ID: <20060725212002.GQ1164@neu.nirvana> On Tue, Jul 25, 2006 at 08:23:50PM +0200, Ralf Corsepius wrote: > On Tue, 2006-07-25 at 13:15 -0500, Rex Dieter wrote: > > Some members of the packaging committee (me, at least) disagree making this > > a MUST. > And some members (me, at least) disagree on this disagreement. And even other members (me, at least) disagree on the disagreement of this disagreement. goto 1: --- It happens that this item was brought up independently three time now within a week and the wording in the guidelines will be fixed on Thursday - hopefully removing id_u from the guidelines, of course ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Tue Jul 25 21:51:43 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 25 Jul 2006 23:51:43 +0200 Subject: Something wrong in buildsys? In-Reply-To: References: <668bb39a0607251327t2f532a7di64a81bda9f57d756@mail.gmail.com> Message-ID: <20060725235143.b47dd11c.bugs.michael@gmx.net> On Tue, 25 Jul 2006 15:49:17 -0500, Rex Dieter wrote: > Micha? Bentkowski wrote: > > > When I took a look on buildsys site today, I saw one package is > > building for over one day. > > I already reported it to http://admin.fedoraproject.org/tickets/ this > morning. So, would anyone please give a short introduction on when this ticketing system ought to be used instead of bugzilla? I've seen it being mentioned before. What I'm still missing is the announcement for everyone. Which system do we use when? From ville.skytta at iki.fi Tue Jul 25 22:04:36 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 26 Jul 2006 01:04:36 +0300 Subject: Need help with python noarch package In-Reply-To: <44C652C3.4090600@cora.nwra.com> References: <44C652C3.4090600@cora.nwra.com> Message-ID: <1153865076.2769.525.camel@localhost.localdomain> On Tue, 2006-07-25 at 11:20 -0600, Orion Poplawski wrote: > I have a noarch python package (python-dateutil) that doesn't build > properly on x86_64. The setup is: > > PYTHONLIB = join(get_python_lib(standard_lib=1, prefix=''), 'site-packages') If the stuff is really noarch, one probably wants to add plat_specific=0 to the arguments to get_python_lib(). On the other hand, it could be better off defined just as: PYTHONLIB = get_python_lib(prefix='') From mattdm at mattdm.org Tue Jul 25 23:53:14 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 25 Jul 2006 19:53:14 -0400 Subject: do we have gnomesu command on Fedora? In-Reply-To: References: <44C5E85E.6070900@city-fan.org> Message-ID: <20060725235314.GA31229@jadzia.bu.edu> On Tue, Jul 25, 2006 at 01:36:17PM -0500, Rex Dieter wrote: > Unfortunately, consolehelper only seems to work for local/console logins, > and not for remote ones. It least, it's never worked for me when using > remote logins (whereas kdesu *does* work, for example). Works for me.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dcbw at redhat.com Wed Jul 26 00:32:17 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 25 Jul 2006 19:32:17 -0500 Subject: Something wrong in buildsys? In-Reply-To: <668bb39a0607251327t2f532a7di64a81bda9f57d756@mail.gmail.com> References: <668bb39a0607251327t2f532a7di64a81bda9f57d756@mail.gmail.com> Message-ID: <1153873937.1154.0.camel@localhost.localdomain> On Tue, 2006-07-25 at 22:27 +0200, Micha? Bentkowski wrote: > When I took a look on buildsys site today, I saw one package is > building for over one day. Does that mean that there is something > wrong with build system? Isn't it blocking the system? Maybe there is > need to explicitly kill these builds. I don't believe that the build > will end at any time. > Also, I noticed that yesterday, I didn't recieve buildys package build > report. Isn't it related to these unbuilt packages? Server kicked, I think it's due to all the builder dropouts (whatever it is that's making them drop out). Dan From steve at silug.org Wed Jul 26 01:25:54 2006 From: steve at silug.org (Steven Pritchard) Date: Tue, 25 Jul 2006 20:25:54 -0500 Subject: Any takers for perl modules RSS related? In-Reply-To: <20060723212202.GA2445@free.fr> References: <20060723212202.GA2445@free.fr> Message-ID: <20060726012554.GA2331@osiris.silug.org> On Sun, Jul 23, 2006 at 11:22:02PM +0200, Patrice Dumas wrote: > http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-DateTime-Format-Mail.spec > http://www.environnement.ens.fr/perso/dumas/fc-srpms/perl-DateTime-Format-W3CDTF.spec I seem to maintain all of the other DateTime modules at the moment, so I guess a couple more wouldn't hurt anything... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From buildsys at fedoraproject.org Wed Jul 26 11:44:03 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 26 Jul 2006 07:44:03 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-26 Message-ID: <20060726114403.5985C152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 35 ClanLib-0.8.0-0.5.RC2.fc5 ClanLib06-0.6.5-5.fc5 Hermes-1.3.3-11.fc5 adplug-2.0.1-1.fc5.1 clisp-2.39-2.fc5 diction-1.10-0.1.rc4.fc5 ecl-0.9i-2.fc5 gnomad2-2.8.6-3.fc5 gpa-0.7.4-1.fc5 gpsd-2.33-2.fc5 kadu-0.5.0-0.4.20060716svn.fc5 kchmviewer-2.6-1.fc5 libhugetlbfs-0.20060706-2.fc5 libnfnetlink-0.0.16-1.fc5 libsamplerate-0.1.2-5.fc5 libtomoe-gtk-0.1.0-6.fc5 lilypond-doc-2.8.4-1.fc5 lyx-1.4.2-2.fc5 lzo-1.08-7.fc5 metamonitor-0.4.5-2.fc5 nagios-plugins-1.4.3-14.fc5 nas-1.8-8.fc5 perl-File-RsyncP-0.62-2.fc5 perl-POE-Component-IRC-4.97-1.fc5 plt-scheme-351-1.fc5 python-kid-0.9.3-1.fc5 python-smbpasswd-1.0.1-3.fc5 qsynth-0.2.5-5.fc5 rosegarden4-1.2.3-4.fc5 rsnapshot-1.2.9-4.fc5 sextractor-2.5.0-3.fc5 steghide-0.5.1-1.fc5 sturmbahnfahrer-1.1-3.fc5 sunifdef-2.1.2-1.fc5 wordpress-2.0.3-4.fc5 Packages built and released for Fedora Extras 4: 34 adplug-2.0.1-1.fc4.1 clisp-2.39-2.fc4 diction-1.10-0.1.rc4.fc4 dvdisaster-0.70-1.fc4 ecl-0.9i-2.fc4 gcdmaster-1.2.1-5.fc4 gconfmm26-2.10.0-4 gnomad2-2.8.6-3.fc4 gpa-0.7.4-1.fc4 gparted-0.0.9-5.fc4 gtkmm24-2.6.10-2.fc4 inkscape-0.44-3.fc4 libglademm24-2.6.0-3 libgnomecanvasmm26-2.10.0-3 libgnomemm26-2.10.0-3 libgnomeuimm26-2.10.0-3 libtomoe-gtk-0.1.0-6.fc4 lyx-1.4.2-2.fc4 lzo-1.08-7.fc4 metamonitor-0.4.5-2.fc4 mysql-administrator-1.1.10-1.fc4.2 nagios-plugins-1.4.3-14.fc4 nas-1.8-8.fc4 perl-File-RsyncP-0.62-2.fc4 plt-scheme-351-1.fc4 python-kid-0.9.3-1.fc4 python-smbpasswd-1.0.1-3.fc4 qjackctl-0.2.20-5.fc4 qsynth-0.2.5-5.fc4 qt4-4.1.4-8.fc4 regexxer-0.8-5.fc4 rosegarden4-1.2.3-4.fc4 sextractor-2.5.0-3.fc4 sunifdef-2.1.2-1.fc4 Packages built and released for Fedora Extras 3: 4 clisp-2.39-2.fc3 gnomad2-2.8.6-3.fc3 libtomoe-gtk-0.1.0-6.fc3 plt-scheme-351-1.fc3 Packages built and released for Fedora Extras development: 69 ClanLib-0.8.0-0.5.RC2.fc6 ClanLib06-0.6.5-5.fc6 Hermes-1.3.3-11.fc6 PyKDE-3.15.2-0.5.20060422.fc6 adplug-2.0.1-1.fc6 boo-0.7.6.2237-6.fc6 ccrtp-1.3.7-2.fc6 clanbomber-1.05-2.fc6 clisp-2.39-2.fc6 conntrack-1.0-0.1.beta2.fc6 ctapi-cyberjack-2.0.10-6.fc6 dap-server-3.6.1-3.fc6 diction-1.10-0.1.rc4.fc6 dvdisaster-0.70-1.fc6 ecl-0.9i-2.fc6 factory-2.0.5-8.fc6 freeglut-2.4.0-9.fc6 geomview-1.8.2-0.11.rc4.fc6 glpk-4.11-1.fc6 gnomad2-2.8.6-3.fc6 gnonlin-0.10.5-1 gpa-0.7.4-1.fc6 gtksourceview-sharp-2.0-13.fc6 jakarta-commons-cli-1.0-6jpp_8.fc6 js-1.5-5.fc6 kadu-0.5.0-0.4.20060716svn.fc6 kawa-1.8-7.fc6 kdegraphics-extras-3.5.4-1.fc6 kdetoys-3.5.4-1.fc6 kdissert-1.0.6-1.fc6 kover-2.9.6-6 libfac-2.0.5-5.fc6 libhugetlbfs-0.20060706-4.fc6 libsamplerate-0.1.2-5.fc6 libtar-1.2.11-7.fc6 libtomoe-gtk-0.1.0-6.fc6 licq-1.3.2-9 lyx-1.4.2-2.fc6 lzo-1.08-7.fc6 mercurial-0.9.1-1.fc6 nagios-plugins-1.4.3-14.fc6 nas-1.8-8.fc6 ntl-5.4-3.fc6 perl-POE-Component-Client-Keepalive-0.0801-2.fc6 perl-POE-Component-IRC-4.97-1.fc6 pingus-0.7.0-0.2.20060721.fc6 plt-scheme-351-1.fc6 powerman-1.0.24-2.fc6 prboom-2.4.3-2.fc6 python-feedparser-4.1-1.fc6 python-kid-0.9.3-1.fc6 python-smbpasswd-1.0.1-3.fc6 qalculate-kde-0.9.4-2.fc6 rosegarden4-1.2.3-4.fc6 rsnapshot-1.2.9-4.fc6 rss-glx-0.8.1.p-4.fc6 sabayon-2.12.3-5 scmxx-0.8.2-2.fc6 ser-0.9.6-7.fc6 sextractor-2.5.0-3.fc6 sloccount-2.26-5 steghide-0.5.1-1.fc6 sturmbahnfahrer-1.1-3.fc6 subversion-api-docs-1.3.2-2.fc6 sunifdef-2.1.2-1.fc6 uim-1.1.1-2.fc6 wordpress-2.0.3-4.fc6 xcompmgr-1.1.3-5.fc6 zziplib-0.13.45-3.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Jul 26 11:44:25 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 26 Jul 2006 07:44:25 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-26 Message-ID: <20060726114425.A1ACD152160@buildsys.fedoraproject.org> azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) dvdisaster: 4: 0:0.70-1.fc4 (FE4) 5: 0:0.66-2.fc5 (FE5) 6: 0:0.70-1.fc6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gcdmaster: 4: 0:1.2.1-5.fc4 (FE4) 5: 0:1.2.1-4.fc5 (FE5) 6: 0:1.2.1-4.fc5 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) inkscape: 4: 0:0.44-3.fc4 (FE4) 5: 0:0.44-2.fc5 (FE5) 6: 0:0.44-2.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2.1 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-14.fc6 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) quagga: 4: 0:0.98.6-1.fc4 (FC4-updates) 5: 0:0.98.6-1.FC5 (FC5-updates) 6: 0:0.98.6-2.1 (FC6) regexxer: 4: 0:0.8-5.fc4 (FE4) 5: 0:0.8-4.fc5 (FE5) 6: 0:0.8-4.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) From buildsys at fedoraproject.org Wed Jul 26 12:02:11 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 26 Jul 2006 12:02:11 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-26 Message-ID: <20060726120211.9089.59718@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- i AT stingr.net libnetfilter_conntrack - 0.0.30-2.fc5.i386 libnetfilter_conntrack - 0.0.30-2.fc5.ppc libnetfilter_conntrack - 0.0.30-2.fc5.x86_64 lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 (11 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc (11 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 (11 days) mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 (7 days) libvisual-plugins - 0.2.0-3.fc5.ppc (7 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (7 days) oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (70 days) syck-php - 0.55-7.fc5.ppc (70 days) syck-php - 0.55-7.fc5.x86_64 (70 days) triad AT df.lth.se adplay - 1.5-1.fc5.i386 adplay - 1.5-1.fc5.ppc adplay - 1.5-1.fc5.x86_64 xmms-adplug - 1.2-1.fc5.i386 xmms-adplug - 1.2-1.fc5.ppc xmms-adplug - 1.2-1.fc5.x86_64 Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- adplay-1.5-1.fc5.i386 requires libadplug-2.0.so.0 libnetfilter_conntrack-0.0.30-2.fc5.i386 requires libnfnetlink.so.0 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.i386 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 xmms-adplug-1.2-1.fc5.i386 requires libadplug-2.0.so.0 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- adplay-1.5-1.fc5.ppc requires libadplug-2.0.so.0 libnetfilter_conntrack-0.0.30-2.fc5.ppc requires libnfnetlink.so.0 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.ppc requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 xmms-adplug-1.2-1.fc5.ppc requires libadplug-2.0.so.0 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- adplay-1.5-1.fc5.x86_64 requires libadplug-2.0.so.0()(64bit) libnetfilter_conntrack-0.0.30-2.fc5.x86_64 requires libnfnetlink.so.0()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc5.x86_64 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 xmms-adplug-1.2-1.fc5.x86_64 requires libadplug-2.0.so.0()(64bit) ====================================================================== New report for: i AT stingr.net package: libnetfilter_conntrack - 0.0.30-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: libnfnetlink.so.0 package: libnetfilter_conntrack - 0.0.30-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libnfnetlink.so.0()(64bit) package: libnetfilter_conntrack - 0.0.30-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: libnfnetlink.so.0 ====================================================================== New report for: triad AT df.lth.se package: adplay - 1.5-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: libadplug-2.0.so.0 package: xmms-adplug - 1.2-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: libadplug-2.0.so.0 package: xmms-adplug - 1.2-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libadplug-2.0.so.0()(64bit) package: adplay - 1.5-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libadplug-2.0.so.0()(64bit) package: xmms-adplug - 1.2-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: libadplug-2.0.so.0 package: adplay - 1.5-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: libadplug-2.0.so.0 From buildsys at fedoraproject.org Wed Jul 26 12:02:12 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 26 Jul 2006 12:02:12 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-26 Message-ID: <20060726120212.9093.89443@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de pdftk - 1.12-6.fc5.i386 pdftk - 1.12-6.fc5.ppc pdftk - 1.12-6.fc5.x86_64 andreas.bierfert AT lowlatency.de wine-core - 0.9.17-1.fc6.i386 bdpepple AT ameritech.net galago-daemon - 0.5.0-3.fc6.i386 (6 days) galago-daemon - 0.5.0-3.fc6.ppc (6 days) galago-daemon - 0.5.0-3.fc6.x86_64 (6 days) libgalago - 0.5.1-4.fc6.i386 (6 days) libgalago - 0.5.1-4.fc6.ppc (6 days) libgalago - 0.5.1-4.fc6.x86_64 (6 days) xchat-gnome - 0.12-2.fc6.i386 (6 days) xchat-gnome - 0.12-2.fc6.ppc (6 days) xchat-gnome - 0.12-2.fc6.x86_64 (6 days) byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 (7 days) gaim-guifications - 2.12-3.fc5.ppc (7 days) gaim-guifications - 2.12-3.fc5.x86_64 (7 days) caillon AT redhat.com banshee - 0.10.8-1.i386 (7 days) banshee - 0.10.8-1.ppc (7 days) banshee - 0.10.8-1.x86_64 (7 days) libipoddevice - 0.4.5-1.fc6.i386 (6 days) libipoddevice - 0.4.5-1.fc6.ppc (6 days) libipoddevice - 0.4.5-1.fc6.x86_64 (6 days) cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 (7 days) gaim-gaym - 0.96-2.fc6.ppc (7 days) gaim-gaym - 0.96-2.fc6.x86_64 (7 days) dennis AT ausil.us knetworkmanager - 0.1-0.3.svn20060625.fc6.i386 (6 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.ppc (6 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.x86_64 (6 days) fedora AT leemhuis.info gsynaptics - 0.9.8-1.fc6.ppc (7 days) green AT redhat.com azureus - 2.4.0.3-0.20060328cvs_5.fc6.i386 azureus - 2.4.0.3-0.20060328cvs_5.fc6.ppc azureus - 2.4.0.3-0.20060328cvs_5.fc6.x86_64 itext - 1.3-1jpp_8.fc5.i386 itext - 1.3-1jpp_8.fc5.ppc itext - 1.3-1jpp_8.fc5.x86_64 jogl - 1.1.1-14.fc5.i386 (3 days) jogl - 1.1.1-14.fc5.ppc (3 days) rssowl - 1.2-12.fc6.i386 rssowl - 1.2-12.fc6.ppc rssowl - 1.2-12.fc6.x86_64 ivazquez AT ivazquez.net gnome-applet-music - 0.9.0-1.fc6.i386 (7 days) gnome-applet-music - 0.9.0-1.fc6.ppc (7 days) gnome-applet-music - 0.9.0-1.fc6.x86_64 (7 days) nautilus-search-tool - 0.2-1.fc5.i386 (7 days) nautilus-search-tool - 0.2-1.fc5.ppc (7 days) nautilus-search-tool - 0.2-1.fc5.x86_64 (7 days) matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 (7 days) diradmin - 1.7.1-4.fc5.ppc (7 days) diradmin - 1.7.1-4.fc5.x86_64 (7 days) gtktalog - 1.0.4-7.fc5.i386 (7 days) gtktalog - 1.0.4-7.fc5.ppc (7 days) gtktalog - 1.0.4-7.fc5.x86_64 (7 days) michael AT knox.net.nz doctorj - 5.0.0-5.fc6.i386 doctorj - 5.0.0-5.fc6.ppc doctorj - 5.0.0-5.fc6.x86_64 screem - 0.16.1-1.fc6.i386 (6 days) screem - 0.16.1-1.fc6.ppc (6 days) screem - 0.16.1-1.fc6.x86_64 (6 days) mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 (7 days) gfontview - 0.5.0-5.fc5.ppc (7 days) gfontview - 0.5.0-5.fc5.x86_64 (7 days) gtkhtml36 - 3.6.2-5.fc6.i386 (7 days) gtkhtml36 - 3.6.2-5.fc6.ppc (7 days) gtkhtml36 - 3.6.2-5.fc6.x86_64 (7 days) libvisual-plugins - 0.2.0-3.fc5.i386 (7 days) libvisual-plugins - 0.2.0-3.fc5.ppc (7 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (7 days) oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (7 days) syck-php - 0.55-7.fc5.ppc (7 days) syck-php - 0.55-7.fc5.x86_64 (7 days) pertusus AT free.fr cernlib - 2005-21.fc6.ppc (7 days) cernlib-packlib - 2005-21.fc6.ppc (7 days) dap-hdf4_handler - 3.6.0-3.fc5.i386 (3 days) dap-hdf4_handler - 3.6.0-3.fc5.ppc (3 days) dap-hdf4_handler - 3.6.0-3.fc5.x86_64 (3 days) patchy - 2005-21.fc6.ppc (7 days) paw - 2005-21.fc6.ppc (7 days) qspencer AT ieee.org octave-forge - 2006.07.09-2.fc6.i386 (3 days) octave-forge - 2006.07.09-2.fc6.ppc (3 days) octave-forge - 2006.07.09-2.fc6.x86_64 (3 days) robert AT marcanoonline.com ganymed-ssh2 - 209-4.fc6.i386 ganymed-ssh2 - 209-4.fc6.ppc ganymed-ssh2 - 209-4.fc6.x86_64 javasvn - 1.0.6-1.fc6.i386 javasvn - 1.0.6-1.fc6.ppc javasvn - 1.0.6-1.fc6.x86_64 rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 (7 days) libibverbs - 1.0.3-1.fc6.ppc (7 days) libibverbs - 1.0.3-1.fc6.x86_64 (7 days) libibverbs-utils - 1.0.3-1.fc6.i386 (7 days) libibverbs-utils - 1.0.3-1.fc6.ppc (7 days) libibverbs-utils - 1.0.3-1.fc6.x86_64 (7 days) thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 (7 days) directfb - 0.9.24-5.fc5.ppc (7 days) directfb - 0.9.24-5.fc5.x86_64 (7 days) triad AT df.lth.se adplay - 1.5-1.fc6.i386 adplay - 1.5-1.fc6.ppc adplay - 1.5-1.fc6.x86_64 xmms-adplug - 1.2-1.fc6.i386 xmms-adplug - 1.2-1.fc6.ppc xmms-adplug - 1.2-1.fc6.x86_64 Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- adplay-1.5-1.fc6.i386 requires libadplug-2.0.so.0 azureus-2.4.0.3-0.20060328cvs_5.fc6.i386 requires libgcj.so.7 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 banshee-0.10.8-1.i386 requires libdbus-1.so.2 dap-hdf4_handler-3.6.0-3.fc5.i386 requires libdap.so.4 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 doctorj-5.0.0-5.fc6.i386 requires libgcj.so.7 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 galago-daemon-0.5.0-3.fc6.i386 requires libdbus-1.so.2 ganymed-ssh2-209-4.fc6.i386 requires libgcj.so.7 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.i386 requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.i386 requires libdbus-1.so.2 gtkhtml36-3.6.2-5.fc6.i386 requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 itext-1.3-1jpp_8.fc5.i386 requires libgcj.so.7 javasvn-1.0.6-1.fc6.i386 requires libgcj.so.7 jogl-1.1.1-14.fc5.i386 requires libgcj.so.7 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-qt-1.so.1 libgalago-0.5.1-4.fc6.i386 requires libdbus-1.so.2 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.i386 requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.i386 requires libgailutil.so.17 octave-forge-2006.07.09-2.fc6.i386 requires libdap.so.4 pdftk-1.12-6.fc5.i386 requires libgcj.so.7 rssowl-1.2-12.fc6.i386 requires libgcj.so.7 screem-0.16.1-1.fc6.i386 requires libdbus-1.so.2 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 xchat-gnome-0.12-2.fc6.i386 requires libdbus-1.so.2 xmms-adplug-1.2-1.fc6.i386 requires libadplug-2.0.so.0 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- adplay-1.5-1.fc6.ppc requires libadplug-2.0.so.0 azureus-2.4.0.3-0.20060328cvs_5.fc6.ppc requires libgcj.so.7 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 banshee-0.10.8-1.ppc requires libdbus-1.so.2 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 dap-hdf4_handler-3.6.0-3.fc5.ppc requires libdap.so.4 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 doctorj-5.0.0-5.fc6.ppc requires libgcj.so.7 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 galago-daemon-0.5.0-3.fc6.ppc requires libdbus-1.so.2 ganymed-ssh2-209-4.fc6.ppc requires libgcj.so.7 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.ppc requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.ppc requires libdbus-1.so.2 gsynaptics-0.9.8-1.fc6.ppc requires synaptics gtkhtml36-3.6.2-5.fc6.ppc requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 itext-1.3-1jpp_8.fc5.ppc requires libgcj.so.7 javasvn-1.0.6-1.fc6.ppc requires libgcj.so.7 jogl-1.1.1-14.fc5.ppc requires libgcj.so.7 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-qt-1.so.1 libgalago-0.5.1-4.fc6.ppc requires libdbus-1.so.2 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.ppc requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.ppc requires libgailutil.so.17 octave-forge-2006.07.09-2.fc6.ppc requires libdap.so.4 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 pdftk-1.12-6.fc5.ppc requires libgcj.so.7 rssowl-1.2-12.fc6.ppc requires libgcj.so.7 screem-0.16.1-1.fc6.ppc requires libdbus-1.so.2 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 xchat-gnome-0.12-2.fc6.ppc requires libdbus-1.so.2 xmms-adplug-1.2-1.fc6.ppc requires libadplug-2.0.so.0 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- adplay-1.5-1.fc6.x86_64 requires libadplug-2.0.so.0()(64bit) azureus-2.4.0.3-0.20060328cvs_5.fc6.x86_64 requires libgcj.so.7()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) banshee-0.10.8-1.x86_64 requires libdbus-1.so.2()(64bit) dap-hdf4_handler-3.6.0-3.fc5.x86_64 requires libdap.so.4()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) doctorj-5.0.0-5.fc6.x86_64 requires libgcj.so.7()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 galago-daemon-0.5.0-3.fc6.x86_64 requires libdbus-1.so.2()(64bit) ganymed-ssh2-209-4.fc6.x86_64 requires libgcj.so.7()(64bit) gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libgailutil.so.17()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) gtkhtml36-3.6.2-5.fc6.x86_64 requires libgailutil.so.17()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) itext-1.3-1jpp_8.fc5.x86_64 requires libgcj.so.7()(64bit) javasvn-1.0.6-1.fc6.x86_64 requires libgcj.so.7()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-qt-1.so.1()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-1.so.2()(64bit) libgalago-0.5.1-4.fc6.x86_64 requires libdbus-1.so.2()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libipoddevice-0.4.5-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) nautilus-search-tool-0.2-1.fc5.x86_64 requires libgailutil.so.17()(64bit) octave-forge-2006.07.09-2.fc6.x86_64 requires libdap.so.4()(64bit) pdftk-1.12-6.fc5.x86_64 requires libgcj.so.7()(64bit) rssowl-1.2-12.fc6.x86_64 requires libgcj.so.7()(64bit) screem-0.16.1-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 wine-core-0.9.17-1.fc6.i386 requires libglut.so.3 xchat-gnome-0.12-2.fc6.x86_64 requires libdbus-1.so.2()(64bit) xmms-adplug-1.2-1.fc6.x86_64 requires libadplug-2.0.so.0()(64bit) ====================================================================== New report for: michael AT knox.net.nz package: doctorj - 5.0.0-5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgcj.so.7 package: doctorj - 5.0.0-5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgcj.so.7()(64bit) package: doctorj - 5.0.0-5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgcj.so.7 ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: wine-core - 0.9.17-1.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libglut.so.3 ====================================================================== New report for: triad AT df.lth.se package: xmms-adplug - 1.2-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libadplug-2.0.so.0 package: adplay - 1.5-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libadplug-2.0.so.0 package: adplay - 1.5-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libadplug-2.0.so.0()(64bit) package: xmms-adplug - 1.2-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libadplug-2.0.so.0()(64bit) package: xmms-adplug - 1.2-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libadplug-2.0.so.0 package: adplay - 1.5-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libadplug-2.0.so.0 ====================================================================== New report for: robert AT marcanoonline.com package: ganymed-ssh2 - 209-4.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgcj.so.7 package: javasvn - 1.0.6-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgcj.so.7 package: javasvn - 1.0.6-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgcj.so.7()(64bit) package: ganymed-ssh2 - 209-4.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgcj.so.7()(64bit) package: ganymed-ssh2 - 209-4.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgcj.so.7 package: javasvn - 1.0.6-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgcj.so.7 ====================================================================== New report for: Jochen AT herr-schmitt.de package: pdftk - 1.12-6.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgcj.so.7 package: pdftk - 1.12-6.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgcj.so.7()(64bit) package: pdftk - 1.12-6.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgcj.so.7 ====================================================================== New report for: green AT redhat.com package: rssowl - 1.2-12.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgcj.so.7 package: itext - 1.3-1jpp_8.fc5.i386 from fedora-extras-development-i386 unresolved deps: libgcj.so.7 package: azureus - 2.4.0.3-0.20060328cvs_5.fc6.i386 from fedora-extras-development-i386 unresolved deps: libgcj.so.7 package: rssowl - 1.2-12.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgcj.so.7()(64bit) package: azureus - 2.4.0.3-0.20060328cvs_5.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgcj.so.7()(64bit) package: itext - 1.3-1jpp_8.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: libgcj.so.7()(64bit) package: itext - 1.3-1jpp_8.fc5.ppc from fedora-extras-development-ppc unresolved deps: libgcj.so.7 package: azureus - 2.4.0.3-0.20060328cvs_5.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgcj.so.7 package: rssowl - 1.2-12.fc6.ppc from fedora-extras-development-ppc unresolved deps: libgcj.so.7 From buildsys at fedoraproject.org Wed Jul 26 12:02:11 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 26 Jul 2006 12:02:11 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-26 Message-ID: <20060726120211.9076.1523@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 (111 days) fluxbox - 0.9.15.1-1.fc3.x86_64 (111 days) Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Wed Jul 26 12:02:11 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 26 Jul 2006 12:02:11 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-26 Message-ID: <20060726120211.9086.95124@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 (11 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc (11 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 (11 days) triad AT df.lth.se adplay - 1.5-1.fc4.i386 adplay - 1.5-1.fc4.ppc adplay - 1.5-1.fc4.x86_64 xmms-adplug - 1.2-1.fc4.i386 xmms-adplug - 1.2-1.fc4.ppc xmms-adplug - 1.2-1.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- adplay-1.5-1.fc4.i386 requires libadplug-2.0.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 xmms-adplug-1.2-1.fc4.i386 requires libadplug-2.0.so.0 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- adplay-1.5-1.fc4.ppc requires libadplug-2.0.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc4.ppc requires python-protocols >= 0:1.0 xmms-adplug-1.2-1.fc4.ppc requires libadplug-2.0.so.0 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- adplay-1.5-1.fc4.x86_64 requires libadplug-2.0.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc4.x86_64 requires python-protocols >= 0:1.0 xmms-adplug-1.2-1.fc4.x86_64 requires libadplug-2.0.so.0()(64bit) ====================================================================== New report for: triad AT df.lth.se package: xmms-adplug - 1.2-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: libadplug-2.0.so.0 package: adplay - 1.5-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: libadplug-2.0.so.0 package: adplay - 1.5-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libadplug-2.0.so.0()(64bit) package: xmms-adplug - 1.2-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: libadplug-2.0.so.0()(64bit) package: xmms-adplug - 1.2-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: libadplug-2.0.so.0 package: adplay - 1.5-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: libadplug-2.0.so.0 From ad+lists at uni-x.org Wed Jul 26 12:25:46 2006 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Wed, 26 Jul 2006 14:25:46 +0200 Subject: rpms/lzo/devel lzo-2.02-configure.patch, NONE, 1.1 .cvsignore, 1.2, 1.3 lzo.spec, 1.11, 1.12 sources, 1.2, 1.3 lzo-1.08-asm.patch, 1.1, NONE lzo-1.08-noexecstack.patch, 1.1, NONE In-Reply-To: <200607261058.k6QAwcM8005278@cvs-int.fedora.redhat.com> References: <200607261058.k6QAwcM8005278@cvs-int.fedora.redhat.com> Message-ID: <44C75F4A.80809@uni-x.org> Hans de Goede (jwrdegoede) schrieb: >Author: jwrdegoede > >Update of /cvs/extras/rpms/lzo/devel >In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv5254 > >Modified Files: > .cvsignore lzo.spec sources >Added Files: > lzo-2.02-configure.patch >Removed Files: > lzo-1.08-asm.patch lzo-1.08-noexecstack.patch >Log Message: >* Wed Jul 26 2006 Hans de Goede 2.02-1 >- New upstream release 2.02, soname change! > [ ... ] > %files > %defattr(-,root,root,-) > %doc AUTHORS COPYING THANKS NEWS >-%{_libdir}/liblzo.so.* >+%{_libdir}/liblzo2.so.* > Attention! That breaks applications compiled against lzo 1.08, like OpenVPN. Alexander From paul at city-fan.org Wed Jul 26 13:25:50 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 26 Jul 2006 14:25:50 +0100 Subject: rpms/lzo/devel lzo-2.02-configure.patch, NONE, 1.1 .cvsignore, 1.2, 1.3 lzo.spec, 1.11, 1.12 sources, 1.2, 1.3 lzo-1.08-asm.patch, 1.1, NONE lzo-1.08-noexecstack.patch, 1.1, NONE In-Reply-To: <44C75F4A.80809@uni-x.org> References: <200607261058.k6QAwcM8005278@cvs-int.fedora.redhat.com> <44C75F4A.80809@uni-x.org> Message-ID: <44C76D5E.6090809@city-fan.org> Alexander Dalloz wrote: > Hans de Goede (jwrdegoede) schrieb: > >> Author: jwrdegoede >> >> Update of /cvs/extras/rpms/lzo/devel >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv5254 >> >> Modified Files: >> .cvsignore lzo.spec sources Added Files: >> lzo-2.02-configure.patch Removed Files: >> lzo-1.08-asm.patch lzo-1.08-noexecstack.patch Log Message: >> * Wed Jul 26 2006 Hans de Goede 2.02-1 >> - New upstream release 2.02, soname change! >> > [ ... ] > >> %files >> %defattr(-,root,root,-) >> %doc AUTHORS COPYING THANKS NEWS >> -%{_libdir}/liblzo.so.* >> +%{_libdir}/liblzo2.so.* >> > Attention! That breaks applications compiled against lzo 1.08, like > OpenVPN. Known issue: http://www.redhat.com/archives/fedora-maintainers/2006-July/msg00397.html Paul. From jwilson at redhat.com Wed Jul 26 14:40:37 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 26 Jul 2006 10:40:37 -0400 Subject: hard time finding packages really for review In-Reply-To: <20060724220833.GA2691@free.fr> References: <20060724220833.GA2691@free.fr> Message-ID: <1153924837.17099.6.camel@xavier.boston.redhat.com> On Tue, 2006-07-25 at 00:08 +0200, Patrice Dumas wrote: > Hello, > > I have seen floating around the idea that there was a need for reviewers > for old reviews. So I started with the packages in FE-NEW with no activity > in eight weeks: > http://fedoraproject.org/wiki/Extras/PackageStatus?highlight=%28package%29#head-6ebf09953da14bdd17d75280dba5b4cffb941077-3 > but I had a hard time to find a package really waiting for a review. In > the end I ended up looking at all of them, and here are the statistics > (I removed kmobiletools, accepted closed): > > 7 packages are stuck in review for various reasons > 11 packages are stuck because they are waiting for submitters > 10 packages were stuck with a need of a reviewer [...] > Here are the details if you don't trust my numbers :) > > Review stuck 6: > disagreament: > fnord freedt > > licence issue: > acx-kmod acx-kmod-common > > wondering about whether it is a good idea to include in extras or not: > alsa-oss phpBB > > needsponsor 1: > gq > > waiting for submitter 11: > smixer smokeping sparse gitweb mondo lurker libpri magic socat > fxload kdiff3 > > Waiting for review 10: > xmms-musepack transconnect ardour pyscript Wcl linux-wlan-ng gpc > vdr-osdteletext vdr-subtitles sqlgrey Oddly enough, the three packages I've recently submitted for review, which are all still sitting in state FE-NEW, are not listed in any of the above groups... zabbix - 198562 ip6sic - 198586 dircproxy - 197740 If anyone wants something to review, I'd certainly welcome feedback on the above. :) -- Jarod Wilson jwilson at redhat.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 triad at df.lth.se Wed Jul 26 16:07:31 2006 From: triad at df.lth.se (Linus Walleij) Date: Wed, 26 Jul 2006 18:07:31 +0200 (CEST) Subject: Cross-compilers. In-Reply-To: <1153656919.29989.74.camel@shinybook.infradead.org> References: <1153656919.29989.74.camel@shinybook.infradead.org> Message-ID: On Sun, 23 Jul 2006, David Woodhouse wrote: > How much interest would there be in getting a bunch of cross-compilers > into Extras? With so many people using them for embedded development, and so many making their own local builds of it, it's of course the *nix way to to things in one place and do it good. And the place is FE, so go ahead. Linus From rdieter at math.unl.edu Wed Jul 26 16:07:25 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Jul 2006 11:07:25 -0500 Subject: do we have gnomesu command on Fedora? References: <44C5E85E.6070900@city-fan.org> <20060725235314.GA31229@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > On Tue, Jul 25, 2006 at 01:36:17PM -0500, Rex Dieter wrote: >> Unfortunately, consolehelper only seems to work for local/console logins, >> and not for remote ones. It least, it's never worked for me when using >> remote logins (whereas kdesu *does* work, for example). > > Works for me.... Not me. $ ssh -X remote_host $ system-config-printer (I get a console-helper password dialog... enter password). X11 connection rejected because of wrong authentication. The application 'system-config-printer' lost its connection to the display localhost:10.0; most likely the X server was shut down or you killed/destroyed the application. -- Rex From laurent.rineau__fedora_extras at normalesup.org Wed Jul 26 16:09:25 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Wed, 26 Jul 2006 18:09:25 +0200 Subject: hard time finding packages really for review In-Reply-To: <1153924837.17099.6.camel@xavier.boston.redhat.com> References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> Message-ID: <200607261809.25478@rineau.schtroumpfette> On Wednesday 26 July 2006 16:40, Jarod Wilson wrote: > On Tue, 2006-07-25 at 00:08 +0200, Patrice Dumas wrote: > > I have seen floating around the idea that there was a need for reviewers > > for old reviews. So I started with the packages in FE-NEW with no > > activity in eight weeks > Oddly enough, the three packages I've recently submitted for review, > which are all still sitting in state FE-NEW, are not listed in any of > the above groups... As quoted above, Patrice has limited his research area to requests without any recent activity (more than height weeks). From laurent.rineau__fedora_extras at normalesup.org Wed Jul 26 16:15:40 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Wed, 26 Jul 2006 18:15:40 +0200 Subject: hard time finding packages really for review In-Reply-To: <1153924837.17099.6.camel@xavier.boston.redhat.com> References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> Message-ID: <200607261815.40064@rineau.schtroumpfette> On Wednesday 26 July 2006 16:40, Jarod Wilson wrote: > On Tue, 2006-07-25 at 00:08 +0200, Patrice Dumas wrote: > > I have seen floating around the idea that there was a need for reviewers > > for old reviews. So I started with the packages in FE-NEW with no > > activity in eight weeks > Oddly enough, the three packages I've recently submitted for review, > which are all still sitting in state FE-NEW, are not listed in any of > the above groups... As quoted above, Patrice has limited his research area to requests without any recent activity (more than height weeks). From pertusus at free.fr Wed Jul 26 16:21:43 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 26 Jul 2006 18:21:43 +0200 Subject: hard time finding packages really for review In-Reply-To: <200607261809.25478@rineau.schtroumpfette> References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> <200607261809.25478@rineau.schtroumpfette> Message-ID: <20060726162143.GC2398@free.fr> > As quoted above, Patrice has limited his research area to requests without any > recent activity (more than height weeks). And the purpose is not pointing at some package, but giving numbers that reveal an issue, here that there should be a way to mark review waiting for a reviewer. -- Pat From cweyl at alumni.drew.edu Wed Jul 26 16:37:22 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 26 Jul 2006 09:37:22 -0700 Subject: hard time finding packages really for review In-Reply-To: <1153924837.17099.6.camel@xavier.boston.redhat.com> References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> Message-ID: <7dd7ab490607260937k18394674ycb88e0fb010a06fb@mail.gmail.com> On 7/26/06, Jarod Wilson wrote: > Oddly enough, the three packages I've recently submitted for review, > which are all still sitting in state FE-NEW, are not listed in any of > the above groups... > > zabbix - 198562 > ip6sic - 198586 > dircproxy - 197740 Add to that: hfsplus-tools - 197764 915resolution - 194566 I think an 8-week no-activity period for determining an "old review" might be a bit much... Perhaps anything in FE-NEW/unassigned older than 2-3 weeks, activity/comments notwithstanding. -Chris -- Chris Weyl Ex astris, scientia From Christian.Iseli at licr.org Wed Jul 26 16:37:32 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Wed, 26 Jul 2006 18:37:32 +0200 Subject: FE Package Status of Jul 26, 2006 Message-ID: <200607261637.k6QGbWeC019543@ludwig-alpha.unil.ch> Hi folks, Here's this weeks report, hot from the script... A couple new things: - a count of tickets blocked in FE-GUIDELINES - a first stab at checking comps.xml files I checked the .xml.in files... The .xml seem a bit out of sync. I'm happy to sync them, but I'd like a go ahead first... The comps.xml seems in pretty poor shape ATM... Also, some things are not completely clear to me: - should only the SRPM name go into comps ? - should all subpackages be mentioned in comps ? - are there packages that should not appear in comps ? Cheers, Christian ---- FE Package Status of Jul 26, 2006 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 2031 packages - 39 orphans - 26 packages not available in extras devel or release Fedora at FamilleCollet dot com php-pecl-zip Fedora at FamilleCollet dot com php-pear-HTTP cgoorah at yahoo dot com dot au kadischi coldwell at redhat dot com lsscsi davidhart at tqmcube dot com leafnode fredrik at dolda2000 dot com icmpdn gauret at free dot fr agave ghenry at suretecsystems dot com gnome-applet-netmon ivazquez at ivazquez dot net gpredict jpo at di dot uminho dot pt perl-Test-Builder-Tester matthias at rpmforge dot net fillets-ng-data-cs nicolas dot mailhot at laposte dot net zoo notting at redhat dot com comps oliver at linux-kernel dot at squidGuard paul at city-fan dot org libpng10 tcallawa at redhat dot com R-RScaLAPACK tcallawa at redhat dot com libgdamm tcallawa at redhat dot com R-hdf5 tcallawa at redhat dot com opendap toniw at iki dot fi silky toniw at iki dot fi libmatchbox toshio at tiki-lounge dot com hula wart at kobold dot org eris wart at kobold dot org wfmath wolters dot liste at gmx dot net ktorrent wtogami at redhat dot com iiimf-le-simplehangul - 8 packages not available in extras devel but present in release andreas at bawue dot net echoping andreas at bawue dot net mboxgrep ivazquez at ivazquez dot net gnome-applet-rhythmbox nando at ccrma dot stanford dot edu qjackctl nando at ccrma dot stanford dot edu qsynth noa at resare dot com vorbisgain ville dot skytta at iki dot fi em8300 ville dot skytta at iki dot fi em8300-kmod - 2 packages which have not yet been FE-APPROVE'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=187818,189375 ktorrent wolters.liste at gmx.net Maelstrom notting at redhat.com - 2 packages present in the development repo which have no owners entry perl-SVK xchm - 3 orphaned packages, yet available in extras devel dxpc gtkglarea2 soundtracker - 43 packages that moved to core Packages appearing both in Core and Extras: - 6 packages duplicated for devel: jpo at di dot uminho dot pt perl-Net-SSLeay jpo at di dot uminho dot pt perl-IO-Socket-SSL jpo at di dot uminho dot pt perl-Socket6 michael at knox dot net dot nz freeglut petersen at redhat dot com scim-bridge tagoh at redhat dot com paps FE-ACCEPT packages stats: - 1085 accepted, closed package reviews - 5 accepted, closed package reviews not in repo - 1 accepted, closed package reviews not in owners - 8 accepted, open package reviews older than 4 weeks; - 5 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 113 open tickets - 24 tickets with no activity in eight weeks - 20 tickets with no activity in four weeks - 3 closed tickets FE-NEW packages stats: - 178 open tickets - 27 tickets with no activity in eight weeks - 36 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 38 open tickets - 6 tickets with no activity in eight weeks - 6 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets FE-GUIDELINES packages stats: - 13 open tickets OPEN-BUGS packages stats: - 241 open tickets - 138 tickets with no activity in eight weeks - 22 tickets with no activity in four weeks CVS stats: - 2006 packages with a devel directory - 7 packages with no owners entry initng mercator muse perl-Maypole perl-SVK php-apc xchm - 4 packages in CVS devel *and* Core freeglut libevent pam_pkcs11 paps - 105 packages were dropped from extras Maintainers stats: - 213 maintainers - 19 inactive maintainers with open bugs - 24 inactive maintainers Dropped FC packages: - 267 packages were dropped from core since FC 1 Comps.xml files stats: - 435 packages in comps-fe6 file - 1503 packages missing from comps-fe6 file - 47 packages in comps-fe6 but not in repo - 434 packages in comps-fe5 file - 1469 packages missing from comps-fe5 file - 44 packages in comps-fe5 but not in repo From pertusus at free.fr Wed Jul 26 16:50:05 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 26 Jul 2006 18:50:05 +0200 Subject: hard time finding packages really for review In-Reply-To: <7dd7ab490607260937k18394674ycb88e0fb010a06fb@mail.gmail.com> References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> <7dd7ab490607260937k18394674ycb88e0fb010a06fb@mail.gmail.com> Message-ID: <20060726165005.GD2398@free.fr> > Add to that: > > hfsplus-tools - 197764 > 915resolution - 194566 > > I think an 8-week no-activity period for determining an "old review" > might be a bit much... Perhaps anything in FE-NEW/unassigned older > than 2-3 weeks, activity/comments notwithstanding. I will be happy if somebody could collect more numbers, as it is allready rather painfull to look at 29 reviews to collect their status... However, while having more numbers about reviews waiting for reviewer may be interesting, what I am more interested in is to have the ratio of review waiting for reviewer to the total number of review. Basing the statistic on "anything in FE-NEW/unassigned than 2-3 weeks, activity/comments notwithstanding" means looking at all the reviews falling in that category to classify them... Anybody volunteering? -- Pat From jwilson at redhat.com Wed Jul 26 17:05:31 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 26 Jul 2006 13:05:31 -0400 Subject: hard time finding packages really for review In-Reply-To: <200607261815.40064@rineau.schtroumpfette> References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> <200607261815.40064@rineau.schtroumpfette> Message-ID: <1153933531.17099.18.camel@xavier.boston.redhat.com> On Wed, 2006-07-26 at 18:15 +0200, Laurent Rineau wrote: > On Wednesday 26 July 2006 16:40, Jarod Wilson wrote: > > On Tue, 2006-07-25 at 00:08 +0200, Patrice Dumas wrote: > > > I have seen floating around the idea that there was a need for reviewers > > > for old reviews. So I started with the packages in FE-NEW with no > > > activity in eight weeks > > > Oddly enough, the three packages I've recently submitted for review, > > which are all still sitting in state FE-NEW, are not listed in any of > > the above groups... > > As quoted above, Patrice has limited his research area to requests without any > recent activity (more than height weeks). D'oh. I'll shut up now. -- Jarod Wilson jwilson at redhat.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 tibbs at math.uh.edu Wed Jul 26 17:22:58 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 26 Jul 2006 12:22:58 -0500 Subject: hard time finding packages really for review In-Reply-To: <20060726162143.GC2398@free.fr> (Patrice Dumas's message of "Wed, 26 Jul 2006 18:21:43 +0200") References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> <200607261809.25478@rineau.schtroumpfette> <20060726162143.GC2398@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> And the purpose is not pointing at some package, but giving PD> numbers that reveal an issue, here that there should be a way to PD> mark review waiting for a reviewer. Isn't that what FE-NEW means, though? - J< From tibbs at math.uh.edu Wed Jul 26 17:25:32 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 26 Jul 2006 12:25:32 -0500 Subject: hard time finding packages really for review In-Reply-To: <20060726165005.GD2398@free.fr> (Patrice Dumas's message of "Wed, 26 Jul 2006 18:50:05 +0200") References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> <7dd7ab490607260937k18394674ycb88e0fb010a06fb@mail.gmail.com> <20060726165005.GD2398@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> Basing the statistic on "anything in FE-NEW/unassigned than 2-3 PD> weeks, activity/comments notwithstanding" means looking at all the PD> reviews falling in that category to classify them... Anybody PD> volunteering? I simply can't see the need. If you're reviewing something, set the blocker to FE-REVIEW. If the blocker is at FE-NEW, anyone can come along and take the package for review. Nothing else should matter. - J< From fedora at leemhuis.info Wed Jul 26 17:30:46 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 26 Jul 2006 19:30:46 +0200 Subject: do we have gnomesu command on Fedora? In-Reply-To: References: <44C5E85E.6070900@city-fan.org> <20060725235314.GA31229@jadzia.bu.edu> Message-ID: <44C7A6C6.6030906@leemhuis.info> Rex Dieter schrieb: > Matthew Miller wrote: > >> On Tue, Jul 25, 2006 at 01:36:17PM -0500, Rex Dieter wrote: >>> Unfortunately, consolehelper only seems to work for local/console logins, >>> and not for remote ones. It least, it's never worked for me when using >>> remote logins (whereas kdesu *does* work, for example). >> Works for me.... > Not me. > $ ssh -X remote_host > $ system-config-printer > (I get a console-helper password dialog... enter password). > X11 connection rejected because of wrong authentication. > The application 'system-config-printer' lost its connection to the display > localhost:10.0; > most likely the X server was shut down or you killed/destroyed > the application. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142648 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164671 CU thl From rdieter at math.unl.edu Wed Jul 26 18:06:36 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Jul 2006 13:06:36 -0500 Subject: do we have gnomesu command on Fedora? References: <44C5E85E.6070900@city-fan.org> <20060725235314.GA31229@jadzia.bu.edu> <44C7A6C6.6030906@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > > > Rex Dieter schrieb: >> Matthew Miller wrote: >> >>> On Tue, Jul 25, 2006 at 01:36:17PM -0500, Rex Dieter wrote: >>>> Unfortunately, consolehelper only seems to work for local/console >>>> logins, >>>> and not for remote ones. It least, it's never worked for me when using >>>> remote logins (whereas kdesu *does* work, for example). >>> Works for me.... >> Not me. >> $ ssh -X remote_host >> $ system-config-printer >> (I get a console-helper password dialog... enter password). >> X11 connection rejected because of wrong authentication. >> The application 'system-config-printer' lost its connection to the >> display localhost:10.0; >> most likely the X server was shut down or you killed/destroyed >> the application. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142648 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164671 So, from what I gather, it doesn't work, and it's been marked WONTFIX. Lovely. I guess you can take your consolehelper and stick it... well you know. (: -- Rex From mattdm at mattdm.org Wed Jul 26 18:19:03 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 26 Jul 2006 14:19:03 -0400 Subject: do we have gnomesu command on Fedora? In-Reply-To: References: <44C5E85E.6070900@city-fan.org> <20060725235314.GA31229@jadzia.bu.edu> <44C7A6C6.6030906@leemhuis.info> Message-ID: <20060726181903.GA4249@jadzia.bu.edu> On Wed, Jul 26, 2006 at 01:06:36PM -0500, Rex Dieter wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142648 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164671 > So, from what I gather, it doesn't work, and it's been marked WONTFIX. > Lovely. I guess you can take your consolehelper and stick it... well you > know. (: Aaah. When I follow the steps in the bug, I get the same problem. However, if I do any of these, it works fine: 1. Just run "system-config-date" without sudo. (As previously noted, you can set up consolehelper to make this prompt authorized users to authenticate with their own password.) 2. Run sudo /usr/share/system-config-date/system-config-date.py 3. Build sudo with "--with-secure-path=/usr/sbin:/sbin:/usr/bin:/bin"; run "sudo system-config-date". The whole "bring up a gnome-terminal running as root (and not just the shell, the whole app!)" thing seems like a subversion of the major benefits of sudo anyway. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rdieter at math.unl.edu Wed Jul 26 18:40:43 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Jul 2006 13:40:43 -0500 Subject: do we have gnomesu command on Fedora? References: <44C5E85E.6070900@city-fan.org> <20060725235314.GA31229@jadzia.bu.edu> <44C7A6C6.6030906@leemhuis.info> <20060726181903.GA4249@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > On Wed, Jul 26, 2006 at 01:06:36PM -0500, Rex Dieter wrote: >> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142648 >> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164671 >> So, from what I gather, it doesn't work, and it's been marked WONTFIX. >> Lovely. I guess you can take your consolehelper and stick it... well you >> know. (: > > Aaah. When I follow the steps in the bug, I get the same problem. However, > if I do any of these, it works fine: > > 1. Just run "system-config-date" without sudo. (As previously noted, you > can set up consolehelper to make this prompt authorized users to > authenticate with their own password.) That's exactly what doesn't work (when used in a remote ssh session), at least not on my RHEL4 box, which is what prompted my whole rant against consolehelper in the first place. Every other app I can think of works as expected, including the aforementioned kdesu. -- Rex From pertusus at free.fr Wed Jul 26 18:51:36 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 26 Jul 2006 20:51:36 +0200 Subject: hard time finding packages really for review In-Reply-To: References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> <7dd7ab490607260937k18394674ycb88e0fb010a06fb@mail.gmail.com> <20060726165005.GD2398@free.fr> Message-ID: <20060726185136.GE2398@free.fr> On Wed, Jul 26, 2006 at 12:25:32PM -0500, Jason L Tibbitts III wrote: > >>>>> "PD" == Patrice Dumas writes: > > PD> Basing the statistic on "anything in FE-NEW/unassigned than 2-3 > PD> weeks, activity/comments notwithstanding" means looking at all the > PD> reviews falling in that category to classify them... Anybody > PD> volunteering? > > I simply can't see the need. If you're reviewing something, set the > blocker to FE-REVIEW. If the blocker is at FE-NEW, anyone can come > along and take the package for review. Nothing else should matter. Indeed, FE-NEW is an important information, but my point is that it is not enough. Because under FE-NEW there are (simplifying) reviews in 3 states: 1) waiting for a reviewer input 2) waiting for the submitter to proceed 3) stuck for another reason (disagreement on packaging practice, discussion on wether it is a good idea to package it in extras or not...) >From the point of view of a reviewer wanting to do reviews, only the first one is interesting. In the mail that started the thread, I explained how I classified the FE-NEW package that were in the group of the packages in FE-NEW state with no change in 8 weeks, and I obtained that only about 1 package for 3 was in the state 1), waiting for reviewer input. So I think that it could be nice to have the possibility to add more information to submitted packages, such that potential reviewers don't spend too much time searching were they could be usefull. -- Pat From mattdm at mattdm.org Wed Jul 26 18:58:26 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 26 Jul 2006 14:58:26 -0400 Subject: do we have gnomesu command on Fedora? In-Reply-To: References: <44C5E85E.6070900@city-fan.org> <20060725235314.GA31229@jadzia.bu.edu> <44C7A6C6.6030906@leemhuis.info> <20060726181903.GA4249@jadzia.bu.edu> Message-ID: <20060726185826.GA6590@jadzia.bu.edu> On Wed, Jul 26, 2006 at 01:40:43PM -0500, Rex Dieter wrote: > > Aaah. When I follow the steps in the bug, I get the same problem. However, > > if I do any of these, it works fine: > > 1. Just run "system-config-date" without sudo. (As previously noted, you > > can set up consolehelper to make this prompt authorized users to > > authenticate with their own password.) > That's exactly what doesn't work (when used in a remote ssh session), at > least not on my RHEL4 box, which is what prompted my whole rant against > consolehelper in the first place. > Every other app I can think of works as expected, including the > aforementioned kdesu. Hmmm. Well, it may be something we've customized that's making it work; not sure exactly. But it does work for me. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tibbs at math.uh.edu Wed Jul 26 20:47:15 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 26 Jul 2006 15:47:15 -0500 Subject: hard time finding packages really for review In-Reply-To: <20060726185136.GE2398@free.fr> (Patrice Dumas's message of "Wed, 26 Jul 2006 20:51:36 +0200") References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> <7dd7ab490607260937k18394674ycb88e0fb010a06fb@mail.gmail.com> <20060726165005.GD2398@free.fr> <20060726185136.GE2398@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> So I think that it could be nice to have the possibility to add PD> more information to submitted packages, such that potential PD> reviewers don't spend too much time searching were they could be PD> usefull. Well, first there's FE-GUIDELINES to indicate packages which are blocked on guidelines; a couple of the oldest packages are blocking that right now. Lately people have been using NEEDINFO_REPORTER which seems to work well to indicate that the package is waiting on the submitter to do something (and has the added benefit of showing up in the dependency tree query). Some of us have gone through and closed bugs that are obviously stalled out. You're of course welcome to do that as well. What other information would you want that you can't just add in a comment? If you really want additional formalism, I suppose you can write up a proposal but I'm not sure that making things any more complicated would actually help in any way. Personally I haven't seen the need for much more than FE-NEW and looking at the last comment to see what's up. - J< From pertusus at free.fr Wed Jul 26 21:04:50 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 26 Jul 2006 23:04:50 +0200 Subject: hard time finding packages really for review In-Reply-To: References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> <7dd7ab490607260937k18394674ycb88e0fb010a06fb@mail.gmail.com> <20060726165005.GD2398@free.fr> <20060726185136.GE2398@free.fr> Message-ID: <20060726210450.GB2432@free.fr> > Lately people have been using NEEDINFO_REPORTER which seems to work > well to indicate that the package is waiting on the submitter to do That's a good idea. Somehow what I was searching for. I'll go through some reviews to set them to NEEDINFO_REPORTER. > tree query). Some of us have gone through and closed bugs that are > obviously stalled out. You're of course welcome to do that as well. I may be too formal, but I think a policy on that could be a good idea. > What other information would you want that you can't just add in a > comment? If you really want additional formalism, I suppose you can > write up a proposal but I'm not sure that making things any more > complicated would actually help in any way. Personally I haven't seen > the need for much more than FE-NEW and looking at the last comment to > see what's up. Sometimes it's not so simple because there is some disagreement, or questionning about the opportunity to package the soft. But with some review closed, some NEEDINFO_REPORTER, maybe there is no need to add more complication, indeed. -- Pat From buildsys at fedoraproject.org Wed Jul 26 22:09:07 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 26 Jul 2006 18:09:07 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-26 Message-ID: <20060726220907.2AFA2152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 14 ClanLib-0.8.0-0.6.RC2.fc5 adplay-1.5-2.fc5 blender-2.42-5.fc5 dvdisaster-0.70-1.fc5 gcfilms-6.4-1.fc5 gossip-0.12-2.fc5 libnetfilter_conntrack-0.0.31-2.fc5 perl-POE-Component-Client-Keepalive-0.0801-2.fc5 pingus-0.7.0-0.2.20060721.fc5 sextractor-2.5.0-4.fc5 tinyerp-3.3.0-2.fc5 wcstools-3.6.5-1.fc5 xchat-gnome-0.13-1.fc5 xmms-adplug-1.2-2.fc5 Packages built and released for Fedora Extras 4: 5 adplay-1.5-2.fc4 gcfilms-6.4-1.fc4 tinyerp-3.3.0-2.fc4 wcstools-3.6.5-1.fc4 xmms-adplug-1.2-2.fc4 Packages built and released for Fedora Extras 3: 1 tinyerp-3.3.0-2.fc3 Packages built and released for Fedora Extras development: 16 ClanLib-0.8.0-0.6.RC2.fc6 adplay-1.5-2.fc6 blender-2.42-5.fc6 boo-0.7.6.2237-7.fc6 doctorj-5.0.0-6.fc6 gcfilms-6.4-1.fc6 geomview-1.8.2-0.12.rc6.fc6 gossip-0.12-3.fc6 hping3-0.0.20051105-3.fc6 lsscsi-0.17-2 screem-0.16.1-2.fc6 sextractor-2.5.0-4.fc6 tinyerp-3.3.0-2.fc6 wcstools-3.6.5-1.fc6 xchat-gnome-0.13-2.fc6 xmms-adplug-1.2-2.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Jul 26 22:09:32 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 26 Jul 2006 18:09:32 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-26 Message-ID: <20060726220932.20D30152169@buildsys.fedoraproject.org> azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gcdmaster: 4: 0:1.2.1-5.fc4 (FE4) 5: 0:1.2.1-4.fc5 (FE5) 6: 0:1.2.1-4.fc5 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) inkscape: 4: 0:0.44-3.fc4 (FE4) 5: 0:0.44-2.fc5 (FE5) 6: 0:0.44-2.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2.1 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-14.fc6 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) quagga: 4: 0:0.98.6-1.fc4 (FC4-updates) 5: 0:0.98.6-1.FC5 (FC5-updates) 6: 0:0.98.6-2.1 (FC6) regexxer: 4: 0:0.8-5.fc4 (FE4) 5: 0:0.8-4.fc5 (FE5) 6: 0:0.8-4.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) udftools: 5: 0:1.0.0b3-5.fc5 (FE5) 6: 0:1.0.0b3-4.fc5 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) From buildsys at fedoraproject.org Wed Jul 26 22:29:00 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 26 Jul 2006 22:29:00 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-26 Message-ID: <20060726222900.25967.33128@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 (111 days) fluxbox - 0.9.15.1-1.fc3.x86_64 (111 days) Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Wed Jul 26 22:29:00 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 26 Jul 2006 22:29:00 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-26 Message-ID: <20060726222900.25975.57916@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 (11 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc (11 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 (11 days) Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.ppc requires python-protocols >= 0:1.0 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.x86_64 requires python-protocols >= 0:1.0 From buildsys at fedoraproject.org Wed Jul 26 22:29:00 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 26 Jul 2006 22:29:00 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-26 Message-ID: <20060726222900.25977.86350@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 (11 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc (11 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 (11 days) mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 (7 days) libvisual-plugins - 0.2.0-3.fc5.ppc (7 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (7 days) oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (70 days) syck-php - 0.55-7.fc5.ppc (70 days) syck-php - 0.55-7.fc5.x86_64 (70 days) Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.i386 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.ppc requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc5.x86_64 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From buildsys at fedoraproject.org Wed Jul 26 22:29:00 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 26 Jul 2006 22:29:00 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-26 Message-ID: <20060726222900.25979.79125@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de pdftk - 1.12-6.fc5.i386 pdftk - 1.12-6.fc5.ppc pdftk - 1.12-6.fc5.x86_64 andreas.bierfert AT lowlatency.de wine-core - 0.9.17-1.fc6.i386 bdpepple AT ameritech.net galago-daemon - 0.5.0-3.fc6.i386 (6 days) galago-daemon - 0.5.0-3.fc6.ppc (6 days) galago-daemon - 0.5.0-3.fc6.x86_64 (6 days) libgalago - 0.5.1-4.fc6.i386 (6 days) libgalago - 0.5.1-4.fc6.ppc (6 days) libgalago - 0.5.1-4.fc6.x86_64 (6 days) byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 (7 days) gaim-guifications - 2.12-3.fc5.ppc (7 days) gaim-guifications - 2.12-3.fc5.x86_64 (7 days) caillon AT redhat.com banshee - 0.10.8-1.i386 (7 days) banshee - 0.10.8-1.ppc (7 days) banshee - 0.10.8-1.x86_64 (7 days) libipoddevice - 0.4.5-1.fc6.i386 (6 days) libipoddevice - 0.4.5-1.fc6.ppc (6 days) libipoddevice - 0.4.5-1.fc6.x86_64 (6 days) cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 (7 days) gaim-gaym - 0.96-2.fc6.ppc (7 days) gaim-gaym - 0.96-2.fc6.x86_64 (7 days) dennis AT ausil.us knetworkmanager - 0.1-0.3.svn20060625.fc6.i386 (6 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.ppc (6 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.x86_64 (6 days) fedora AT leemhuis.info gsynaptics - 0.9.8-1.fc6.ppc (7 days) green AT redhat.com azureus - 2.4.0.3-0.20060328cvs_5.fc6.i386 azureus - 2.4.0.3-0.20060328cvs_5.fc6.ppc azureus - 2.4.0.3-0.20060328cvs_5.fc6.x86_64 itext - 1.3-1jpp_8.fc5.i386 itext - 1.3-1jpp_8.fc5.ppc itext - 1.3-1jpp_8.fc5.x86_64 jogl - 1.1.1-14.fc5.i386 (3 days) jogl - 1.1.1-14.fc5.ppc (3 days) rssowl - 1.2-12.fc6.i386 rssowl - 1.2-12.fc6.ppc rssowl - 1.2-12.fc6.x86_64 ivazquez AT ivazquez.net gnome-applet-music - 0.9.0-1.fc6.i386 (7 days) gnome-applet-music - 0.9.0-1.fc6.ppc (7 days) gnome-applet-music - 0.9.0-1.fc6.x86_64 (7 days) nautilus-search-tool - 0.2-1.fc5.i386 (7 days) nautilus-search-tool - 0.2-1.fc5.ppc (7 days) nautilus-search-tool - 0.2-1.fc5.x86_64 (7 days) matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 (7 days) diradmin - 1.7.1-4.fc5.ppc (7 days) diradmin - 1.7.1-4.fc5.x86_64 (7 days) gtktalog - 1.0.4-7.fc5.i386 (7 days) gtktalog - 1.0.4-7.fc5.ppc (7 days) gtktalog - 1.0.4-7.fc5.x86_64 (7 days) mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 (7 days) gfontview - 0.5.0-5.fc5.ppc (7 days) gfontview - 0.5.0-5.fc5.x86_64 (7 days) gtkhtml36 - 3.6.2-5.fc6.i386 (7 days) gtkhtml36 - 3.6.2-5.fc6.ppc (7 days) gtkhtml36 - 3.6.2-5.fc6.x86_64 (7 days) libvisual-plugins - 0.2.0-3.fc5.i386 (7 days) libvisual-plugins - 0.2.0-3.fc5.ppc (7 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (7 days) oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (7 days) syck-php - 0.55-7.fc5.ppc (7 days) syck-php - 0.55-7.fc5.x86_64 (7 days) pertusus AT free.fr cernlib - 2005-21.fc6.ppc (7 days) cernlib-packlib - 2005-21.fc6.ppc (7 days) dap-hdf4_handler - 3.6.0-3.fc5.i386 (3 days) dap-hdf4_handler - 3.6.0-3.fc5.ppc (3 days) dap-hdf4_handler - 3.6.0-3.fc5.x86_64 (3 days) patchy - 2005-21.fc6.ppc (7 days) paw - 2005-21.fc6.ppc (7 days) qspencer AT ieee.org octave-forge - 2006.07.09-2.fc6.i386 (3 days) octave-forge - 2006.07.09-2.fc6.ppc (3 days) octave-forge - 2006.07.09-2.fc6.x86_64 (3 days) robert AT marcanoonline.com ganymed-ssh2 - 209-4.fc6.i386 ganymed-ssh2 - 209-4.fc6.ppc ganymed-ssh2 - 209-4.fc6.x86_64 javasvn - 1.0.6-1.fc6.i386 javasvn - 1.0.6-1.fc6.ppc javasvn - 1.0.6-1.fc6.x86_64 rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 (7 days) libibverbs - 1.0.3-1.fc6.ppc (7 days) libibverbs - 1.0.3-1.fc6.x86_64 (7 days) libibverbs-utils - 1.0.3-1.fc6.i386 (7 days) libibverbs-utils - 1.0.3-1.fc6.ppc (7 days) libibverbs-utils - 1.0.3-1.fc6.x86_64 (7 days) thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 (7 days) directfb - 0.9.24-5.fc5.ppc (7 days) directfb - 0.9.24-5.fc5.x86_64 (7 days) Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- azureus-2.4.0.3-0.20060328cvs_5.fc6.i386 requires libgcj.so.7 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 banshee-0.10.8-1.i386 requires libdbus-1.so.2 dap-hdf4_handler-3.6.0-3.fc5.i386 requires libdap.so.4 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 galago-daemon-0.5.0-3.fc6.i386 requires libdbus-1.so.2 ganymed-ssh2-209-4.fc6.i386 requires libgcj.so.7 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.i386 requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.i386 requires libdbus-1.so.2 gtkhtml36-3.6.2-5.fc6.i386 requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 itext-1.3-1jpp_8.fc5.i386 requires libgcj.so.7 javasvn-1.0.6-1.fc6.i386 requires libgcj.so.7 jogl-1.1.1-14.fc5.i386 requires libgcj.so.7 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-qt-1.so.1 libgalago-0.5.1-4.fc6.i386 requires libdbus-1.so.2 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.i386 requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.i386 requires libgailutil.so.17 octave-forge-2006.07.09-2.fc6.i386 requires libdap.so.4 pdftk-1.12-6.fc5.i386 requires libgcj.so.7 rssowl-1.2-12.fc6.i386 requires libgcj.so.7 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- azureus-2.4.0.3-0.20060328cvs_5.fc6.ppc requires libgcj.so.7 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 banshee-0.10.8-1.ppc requires libdbus-1.so.2 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 dap-hdf4_handler-3.6.0-3.fc5.ppc requires libdap.so.4 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 galago-daemon-0.5.0-3.fc6.ppc requires libdbus-1.so.2 ganymed-ssh2-209-4.fc6.ppc requires libgcj.so.7 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.ppc requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.ppc requires libdbus-1.so.2 gsynaptics-0.9.8-1.fc6.ppc requires synaptics gtkhtml36-3.6.2-5.fc6.ppc requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 itext-1.3-1jpp_8.fc5.ppc requires libgcj.so.7 javasvn-1.0.6-1.fc6.ppc requires libgcj.so.7 jogl-1.1.1-14.fc5.ppc requires libgcj.so.7 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-qt-1.so.1 libgalago-0.5.1-4.fc6.ppc requires libdbus-1.so.2 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.ppc requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.ppc requires libgailutil.so.17 octave-forge-2006.07.09-2.fc6.ppc requires libdap.so.4 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 pdftk-1.12-6.fc5.ppc requires libgcj.so.7 rssowl-1.2-12.fc6.ppc requires libgcj.so.7 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- azureus-2.4.0.3-0.20060328cvs_5.fc6.x86_64 requires libgcj.so.7()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) banshee-0.10.8-1.x86_64 requires libdbus-1.so.2()(64bit) dap-hdf4_handler-3.6.0-3.fc5.x86_64 requires libdap.so.4()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 galago-daemon-0.5.0-3.fc6.x86_64 requires libdbus-1.so.2()(64bit) ganymed-ssh2-209-4.fc6.x86_64 requires libgcj.so.7()(64bit) gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libgailutil.so.17()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) gtkhtml36-3.6.2-5.fc6.x86_64 requires libgailutil.so.17()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) itext-1.3-1jpp_8.fc5.x86_64 requires libgcj.so.7()(64bit) javasvn-1.0.6-1.fc6.x86_64 requires libgcj.so.7()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-qt-1.so.1()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-1.so.2()(64bit) libgalago-0.5.1-4.fc6.x86_64 requires libdbus-1.so.2()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libipoddevice-0.4.5-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) nautilus-search-tool-0.2-1.fc5.x86_64 requires libgailutil.so.17()(64bit) octave-forge-2006.07.09-2.fc6.x86_64 requires libdap.so.4()(64bit) pdftk-1.12-6.fc5.x86_64 requires libgcj.so.7()(64bit) rssowl-1.2-12.fc6.x86_64 requires libgcj.so.7()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 wine-core-0.9.17-1.fc6.i386 requires libglut.so.3 From pertusus at free.fr Wed Jul 26 22:37:05 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 27 Jul 2006 00:37:05 +0200 Subject: hard time finding packages really for review In-Reply-To: <20060726210450.GB2432@free.fr> References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> <7dd7ab490607260937k18394674ycb88e0fb010a06fb@mail.gmail.com> <20060726165005.GD2398@free.fr> <20060726185136.GE2398@free.fr> <20060726210450.GB2432@free.fr> Message-ID: <20060726223705.GE2432@free.fr> On Wed, Jul 26, 2006 at 11:04:50PM +0200, Patrice Dumas wrote: > > Lately people have been using NEEDINFO_REPORTER which seems to work > > well to indicate that the package is waiting on the submitter to do > > That's a good idea. Somehow what I was searching for. I'll go through > some reviews to set them to NEEDINFO_REPORTER. Oups... One cannot revert to NEW after setting to NEEDINFO_REPORTER :/. Is it a bugzilla deficiency or something expected? -- Pat From tibbs at math.uh.edu Thu Jul 27 01:28:16 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 26 Jul 2006 20:28:16 -0500 Subject: hard time finding packages really for review In-Reply-To: <20060726210450.GB2432@free.fr> (Patrice Dumas's message of "Wed, 26 Jul 2006 23:04:50 +0200") References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> <7dd7ab490607260937k18394674ycb88e0fb010a06fb@mail.gmail.com> <20060726165005.GD2398@free.fr> <20060726185136.GE2398@free.fr> <20060726210450.GB2432@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> I may be too formal, but I think a policy on that could be a good PD> idea. I think most of us have been waiting for a month of inactivity, pinging and closing after a week of no response. The worse thing that can happen is that the bug gets reopened or the package gets resubmitted. I'll write up a basic "dead package reviews" policy and see if FESCo has a chance to talk about it tomorrow. PD> Sometimes it's not so simple because there is some disagreement, PD> or questionning about the opportunity to package the soft. Well, sure, there are always going to be some problem issues, some submitter going on vacation or something of the sort. But common courtesy will take care of most issues, and if a closed bug gets reopened occasionally then so be it. - J< From tibbs at math.uh.edu Thu Jul 27 01:29:01 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 26 Jul 2006 20:29:01 -0500 Subject: hard time finding packages really for review In-Reply-To: <20060726223705.GE2432@free.fr> (Patrice Dumas's message of "Thu, 27 Jul 2006 00:37:05 +0200") References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> <7dd7ab490607260937k18394674ycb88e0fb010a06fb@mail.gmail.com> <20060726165005.GD2398@free.fr> <20060726185136.GE2398@free.fr> <20060726210450.GB2432@free.fr> <20060726223705.GE2432@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> Oups... One cannot revert to NEW after setting to PD> NEEDINFO_REPORTER :/. Yes, you can't go back to new from any other state, unfortunately. Assigned to the "default" bug owner is the best you can do as far as I can tell. - J< From tibbs at math.uh.edu Thu Jul 27 01:38:04 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 26 Jul 2006 20:38:04 -0500 Subject: hard time finding packages really for review In-Reply-To: (Jason L. Tibbitts, III's message of "Wed, 26 Jul 2006 20:29:01 -0500") References: <20060724220833.GA2691@free.fr> <1153924837.17099.6.camel@xavier.boston.redhat.com> <7dd7ab490607260937k18394674ycb88e0fb010a06fb@mail.gmail.com> <20060726165005.GD2398@free.fr> <20060726185136.GE2398@free.fr> <20060726210450.GB2432@free.fr> <20060726223705.GE2432@free.fr> Message-ID: >>>>> "JLT" == Jason L Tibbitts, writes: JLT> Yes, you can't go back to new from any other state, JLT> unfortunately. I'll see if I can get get someone in power to consider an UNASSIGNED state. I'd propose that we just use NEEDINFO for now. - J< From michael at knox.net.nz Thu Jul 27 08:32:41 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 27 Jul 2006 20:32:41 +1200 Subject: sponsor requirements. Message-ID: <44C87A29.8020800@knox.net.nz> mainly directed at fesco members, but what are the requirements of someone to be able to sponsor people into extras? Michael From paul at all-the-johnsons.co.uk Thu Jul 27 08:56:24 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 27 Jul 2006 09:56:24 +0100 Subject: sponsor requirements. In-Reply-To: <44C87A29.8020800@knox.net.nz> References: <44C87A29.8020800@knox.net.nz> Message-ID: <1153990584.2905.3.camel@localhost.localdomain> Hi. FWIU > mainly directed at fesco members, but what are the requirements of > someone to be able to sponsor people into extras? You need to be on the bugzilla-new list (you are), have to submit and review packages (you do) and be on the sponsors list (this is considered by the FESCo people when they meet should you want to put your name forward - you can nominate yourself - which is handy!). TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From Christian.Iseli at licr.org Thu Jul 27 09:05:46 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 27 Jul 2006 11:05:46 +0200 Subject: sponsor requirements. In-Reply-To: Your message of "Thu, 27 Jul 2006 20:32:41 +1200." <44C87A29.8020800@knox.net.nz> Message-ID: <200607270905.k6R95kZn032014@ludwig-alpha.unil.ch> michael at knox.net.nz said: > mainly directed at fesco members, but what are the requirements of someone > to be able to sponsor people into extras? Basically what it says here: http://fedoraproject.org/wiki/Extras/SponsorProcess If you so wish, I can nominate you at tomorrow's meeting. You seem to have participated in the review of 32 packages: https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&product=Fedora+Extras&component=Package+Review&emailassigned_to1=1&emaillongdesc1=1&emailtype1=exact&email1=michael%40knox.net.nz&emailreporter2=1&emailtype2=notregexp&email2=michael%40knox.net.nz Cheers, Christian From michael at knox.net.nz Thu Jul 27 09:08:08 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 27 Jul 2006 21:08:08 +1200 Subject: sponsor requirements. In-Reply-To: <200607270905.k6R95kZn032014@ludwig-alpha.unil.ch> References: <200607270905.k6R95kZn032014@ludwig-alpha.unil.ch> Message-ID: <44C88278.4050804@knox.net.nz> Christian.Iseli at licr.org wrote: > michael at knox.net.nz said: >> mainly directed at fesco members, but what are the requirements of someone >> to be able to sponsor people into extras? > > Basically what it says here: > http://fedoraproject.org/wiki/Extras/SponsorProcess > > If you so wish, I can nominate you at tomorrow's > meeting. Cool! I would appreciate that :) Michael > You seem to have participated in the review of 32 packages: > https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&product=Fedora+Extras&component=Package+Review&emailassigned_to1=1&emaillongdesc1=1&emailtype1=exact&email1=michael%40knox.net.nz&emailreporter2=1&emailtype2=notregexp&email2=michael%40knox.net.nz > > Cheers, > Christian > > From Christian.Iseli at licr.org Thu Jul 27 09:12:51 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 27 Jul 2006 11:12:51 +0200 Subject: sponsor requirements. In-Reply-To: Your message of "Thu, 27 Jul 2006 21:08:08 +1200." <44C88278.4050804@knox.net.nz> Message-ID: <200607270912.k6R9Cpx7032162@ludwig-alpha.unil.ch> Hmm, I said: > If you so wish, I can nominate you at tomorrow's meeting. Actually, the meeting is today... :-) Need some coffee quick. michael at knox.net.nz said: > Cool! I would appreciate that :) k. Deal. Christian From paul at all-the-johnsons.co.uk Thu Jul 27 09:18:20 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 27 Jul 2006 10:18:20 +0100 Subject: sponsor requirements. In-Reply-To: <200607270912.k6R9Cpx7032162@ludwig-alpha.unil.ch> References: <200607270912.k6R9Cpx7032162@ludwig-alpha.unil.ch> Message-ID: <1153991900.2905.23.camel@localhost.localdomain> Hi, On Thu, 2006-07-27 at 11:12 +0200, Christian.Iseli at licr.org wrote: > Need some coffee quick. Two willing lambs to the slaughter in one week! Quick, pass me some of your coffee! TTFN Paul (the other lamb!) -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From pertusus at free.fr Thu Jul 27 09:18:20 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 27 Jul 2006 11:18:20 +0200 Subject: FE Package Status of Jul 26, 2006 In-Reply-To: <200607261637.k6QGbWeC019543@ludwig-alpha.unil.ch> References: <200607261637.k6QGbWeC019543@ludwig-alpha.unil.ch> Message-ID: <20060727091820.GC2535@free.fr> On Wed, Jul 26, 2006 at 06:37:32PM +0200, Christian.Iseli at licr.org wrote: > Hi folks, > > I checked the .xml.in files... The .xml seem a bit out of sync. > I'm happy to sync them, but I'd like a go ahead first... > > The comps.xml seems in pretty poor shape ATM... Also, some things are not > completely clear to me: I searched in the wiki, but I didn't found anything relevant, however I remember that once a message was sent to a list explaining what should go in comps. Maybe this should be added to the wiki. What I remember is that package and subpackages goes into comps, not SRPM names. In comps there should only appear packages that are directly usefull, so no library, no perl or python module (except when they are associated with a usefull script). There seems to be exceptions to these exceptions since devel packages appears in Development groups, and there are libs in 'Engineering and Scientific'. -- Pat From Christian.Iseli at licr.org Thu Jul 27 09:26:04 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 27 Jul 2006 11:26:04 +0200 Subject: sponsor requirements. In-Reply-To: Your message of "Thu, 27 Jul 2006 10:18:20 BST." <1153991900.2905.23.camel@localhost.localdomain> Message-ID: <200607270926.k6R9Q4PY032410@ludwig-alpha.unil.ch> paul at all-the-johnsons.co.uk said: > Quick, pass me some of your coffee! Here you go :) http://english.unc.edu/graphics/newspage/coffeecup.jpg From j.w.r.degoede at hhs.nl Thu Jul 27 09:34:53 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 27 Jul 2006 11:34:53 +0200 Subject: FE Package Status of Jul 26, 2006 In-Reply-To: <20060727091820.GC2535@free.fr> References: <200607261637.k6QGbWeC019543@ludwig-alpha.unil.ch> <20060727091820.GC2535@free.fr> Message-ID: <44C888BD.40206@hhs.nl> Patrice Dumas wrote: > On Wed, Jul 26, 2006 at 06:37:32PM +0200, Christian.Iseli at licr.org wrote: >> Hi folks, >> >> I checked the .xml.in files... The .xml seem a bit out of sync. >> I'm happy to sync them, but I'd like a go ahead first... >> >> The comps.xml seems in pretty poor shape ATM... Also, some things are not >> completely clear to me: > > I searched in the wiki, but I didn't found anything relevant, however > I remember that once a message was sent to a list explaining what should > go in comps. Maybe this should be added to the wiki. > > What I remember is that package and subpackages goes into comps, not > SRPM names. In comps there should only appear packages that are directly > usefull, so no library, no perl or python module (except when they > are associated with a usefull script). > > There seems to be exceptions to these exceptions since devel packages > appears in Development groups, and there are libs in > 'Engineering and Scientific'. > Yes, I thought the rule was only packages directly usefull to end users should go in. Can we have some guidelines on this? (Maybe a point for todays FESco meeting?) Regards, Hans From pertusus at free.fr Thu Jul 27 09:47:53 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 27 Jul 2006 11:47:53 +0200 Subject: FE Package Status of Jul 26, 2006 In-Reply-To: <44C888BD.40206@hhs.nl> References: <200607261637.k6QGbWeC019543@ludwig-alpha.unil.ch> <20060727091820.GC2535@free.fr> <44C888BD.40206@hhs.nl> Message-ID: <20060727094753.GD2535@free.fr> > > I thought the rule was only packages directly usefull to end users > should go in. Can we have some guidelines on this? (Maybe a point for > todays FESco meeting?) I always had questions about comps file, but I don't know where to submit them. Where is the comp file discussed? -- Pat From paul at all-the-johnsons.co.uk Thu Jul 27 12:29:19 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 27 Jul 2006 13:29:19 +0100 Subject: Changing the mod of an entire directory Message-ID: <1154003359.2905.44.camel@localhost.localdomain> Hi, I'm packaging vsn 0.7 of XaraLX and have hit a problem. While running rpmlint over the debug package, I'm getting a pile of warnings that the wxOil directory has the majority (if not all) of the files with incorrect permissions set. Is there a way to chmod an entire directory within a spec file and should it go into %prep? TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From paul at city-fan.org Thu Jul 27 12:34:00 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 27 Jul 2006 13:34:00 +0100 Subject: Changing the mod of an entire directory In-Reply-To: <1154003359.2905.44.camel@localhost.localdomain> References: <1154003359.2905.44.camel@localhost.localdomain> Message-ID: <44C8B2B8.6060608@city-fan.org> PFJ wrote: > Hi, > > I'm packaging vsn 0.7 of XaraLX and have hit a problem. While running > rpmlint over the debug package, I'm getting a pile of warnings that the > wxOil directory has the majority (if not all) of the files with > incorrect permissions set. > > Is there a way to chmod an entire directory within a spec file and > should it go into %prep? You probably want something like this in %prep: find . -name '*.[ch]' | xargs chmod -x Paul. From snecklifter at gmail.com Thu Jul 27 14:54:12 2006 From: snecklifter at gmail.com (Chris Brown) Date: Thu, 27 Jul 2006 15:54:12 +0100 Subject: Package review request - Jokosher Message-ID: <364d303b0607270754q5904add3ke432469e591bbdb0@mail.gmail.com> Hi folks, The subject says it all. This one's low hanging fruit that I'm sure can be accepted pretty quickly. If you have a moment I need someone to sponsor: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199029 which is Jokosher, a non-linear audio editor written in python and utilising gstreamer libraries. I cant see any reason for this to be held back but then again, you might. :) Thanks in advance, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Thu Jul 27 15:11:49 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 27 Jul 2006 16:11:49 +0100 Subject: Package review request - Jokosher In-Reply-To: <364d303b0607270754q5904add3ke432469e591bbdb0@mail.gmail.com> References: <364d303b0607270754q5904add3ke432469e591bbdb0@mail.gmail.com> Message-ID: <44C8D7B5.9050808@city-fan.org> Chris Brown wrote: > Hi folks, > > The subject says it all. This one's low hanging fruit that I'm sure can be > accepted pretty quickly. If you have a moment I need someone to sponsor: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199029 > > which is Jokosher, a non-linear audio editor written in python and > utilising > gstreamer libraries. I cant see any reason for this to be held back but > then > again, you might. :) It's people that are sponsored, not packages. You need to convince a potential sponsor that you're a competent packager *and* you know your way around the Fedora Extras processes. See: http://fedoraproject.org/wiki/Extras/HowToGetSponsored Paul. From sundaram at fedoraproject.org Thu Jul 27 15:16:54 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 27 Jul 2006 20:46:54 +0530 Subject: Package review request - Jokosher In-Reply-To: <44C8D7B5.9050808@city-fan.org> References: <364d303b0607270754q5904add3ke432469e591bbdb0@mail.gmail.com> <44C8D7B5.9050808@city-fan.org> Message-ID: <44C8D8E6.9080507@fedoraproject.org> Paul Howarth wrote: > Chris Brown wrote: >> Hi folks, >> >> The subject says it all. This one's low hanging fruit that I'm sure >> can be >> accepted pretty quickly. If you have a moment I need someone to sponsor: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199029 >> >> which is Jokosher, a non-linear audio editor written in python and >> utilising >> gstreamer libraries. I cant see any reason for this to be held back >> but then >> again, you might. :) > > It's people that are sponsored, not packages. You need to convince a > potential sponsor that you're a competent packager *and* you know your > way around the Fedora Extras processes. > > See: http://fedoraproject.org/wiki/Extras/HowToGetSponsored > So how is this different from http://fedoraproject.org/wiki/Extras/HowToGetSponsored? The Extras page only links to this one and not what you provided. Rahul From paul at all-the-johnsons.co.uk Thu Jul 27 15:24:35 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Thu, 27 Jul 2006 16:24:35 +0100 Subject: Package review request - Jokosher In-Reply-To: <364d303b0607270754q5904add3ke432469e591bbdb0@mail.gmail.com> References: <364d303b0607270754q5904add3ke432469e591bbdb0@mail.gmail.com> Message-ID: <1154013875.2568.5.camel@localhost.localdomain> Hi, > I cant see any reason for this to be held back I did. Quite a few of them. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From paul at city-fan.org Thu Jul 27 15:35:37 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 27 Jul 2006 16:35:37 +0100 Subject: Package review request - Jokosher In-Reply-To: <44C8D8E6.9080507@fedoraproject.org> References: <364d303b0607270754q5904add3ke432469e591bbdb0@mail.gmail.com> <44C8D7B5.9050808@city-fan.org> <44C8D8E6.9080507@fedoraproject.org> Message-ID: <44C8DD49.3090603@city-fan.org> Rahul wrote: > Paul Howarth wrote: >> Chris Brown wrote: >>> Hi folks, >>> >>> The subject says it all. This one's low hanging fruit that I'm sure >>> can be >>> accepted pretty quickly. If you have a moment I need someone to sponsor: >>> >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199029 >>> >>> which is Jokosher, a non-linear audio editor written in python and >>> utilising >>> gstreamer libraries. I cant see any reason for this to be held back >>> but then >>> again, you might. :) >> >> It's people that are sponsored, not packages. You need to convince a >> potential sponsor that you're a competent packager *and* you know your >> way around the Fedora Extras processes. >> >> See: http://fedoraproject.org/wiki/Extras/HowToGetSponsored >> > So how is this different from > http://fedoraproject.org/wiki/Extras/HowToGetSponsored? > > The Extras page only links to this one and not what you provided. Sorry, I can't parse that comment. The URL in your response is exactly the same as the URL I quoted. Paul. From Christian.Iseli at licr.org Thu Jul 27 15:40:36 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Thu, 27 Jul 2006 17:40:36 +0200 Subject: Future FESCo Elections In-Reply-To: Your message of "Mon, 24 Jul 2006 12:12:35 PDT." <1153768355.3209.48.camel@localhost> Message-ID: <200607271540.k6RFeaWs006558@ludwig-alpha.unil.ch> toshio at tiki-lounge.com said: > So in this case the perfect world needs and the political needs of the > community coincided. A new question would then be: how do we balance voter > burnout (why do we vote all the time?) with feeling of community control (why > haven't we voted in a long time?) and the efficiency of FESCo (replace people > too often and they spend all their time trying to get elected rather than > running the project) with burnout (replace them infrequently and they begin > to have more important things to work on and stop participating.) Just an idea: why not have elections when at least 2-3 non FESCo members express interest into becoming FESCo members ? We could have a wiki page where people could express their interest and intentions if elected We could send emails to appropriate lists after each FC release reminding interested people to register on the page. A couple weeks after the reminding email, we look at the page and if enough people are registered, we start the election process Christian From sundaram at fedoraproject.org Thu Jul 27 15:45:12 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 27 Jul 2006 21:15:12 +0530 Subject: Package review request - Jokosher In-Reply-To: <44C8DD49.3090603@city-fan.org> References: <364d303b0607270754q5904add3ke432469e591bbdb0@mail.gmail.com> <44C8D7B5.9050808@city-fan.org> <44C8D8E6.9080507@fedoraproject.org> <44C8DD49.3090603@city-fan.org> Message-ID: <44C8DF88.6030106@fedoraproject.org> Paul Howarth wrote: > Rahul wrote: >> Paul Howarth wrote: >>> Chris Brown wrote: >>>> Hi folks, >>>> >>>> The subject says it all. This one's low hanging fruit that I'm sure >>>> can be >>>> accepted pretty quickly. If you have a moment I need someone to >>>> sponsor: >>>> >>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199029 >>>> >>>> which is Jokosher, a non-linear audio editor written in python and >>>> utilising >>>> gstreamer libraries. I cant see any reason for this to be held back >>>> but then >>>> again, you might. :) >>> >>> It's people that are sponsored, not packages. You need to convince a >>> potential sponsor that you're a competent packager *and* you know >>> your way around the Fedora Extras processes. >>> >>> See: http://fedoraproject.org/wiki/Extras/HowToGetSponsored >>> >> So how is this different from >> http://fedoraproject.org/wiki/Extras/HowToGetSponsored? >> >> The Extras page only links to this one and not what you provided. > > Sorry, I can't parse that comment. The URL in your response is exactly > the same as the URL I quoted. Ugh. Sorry. Wrong copy and paste. http://fedoraproject.org/wiki/Extras/SponsorProcess Rahul From paul at city-fan.org Thu Jul 27 15:49:40 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 27 Jul 2006 16:49:40 +0100 Subject: Package review request - Jokosher In-Reply-To: <44C8DF88.6030106@fedoraproject.org> References: <364d303b0607270754q5904add3ke432469e591bbdb0@mail.gmail.com> <44C8D7B5.9050808@city-fan.org> <44C8D8E6.9080507@fedoraproject.org> <44C8DD49.3090603@city-fan.org> <44C8DF88.6030106@fedoraproject.org> Message-ID: <44C8E094.6030007@city-fan.org> Rahul wrote: > Paul Howarth wrote: >> Rahul wrote: >>> Paul Howarth wrote: >>>> Chris Brown wrote: >>>>> Hi folks, >>>>> >>>>> The subject says it all. This one's low hanging fruit that I'm sure >>>>> can be >>>>> accepted pretty quickly. If you have a moment I need someone to >>>>> sponsor: >>>>> >>>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199029 >>>>> >>>>> which is Jokosher, a non-linear audio editor written in python and >>>>> utilising >>>>> gstreamer libraries. I cant see any reason for this to be held back >>>>> but then >>>>> again, you might. :) >>>> >>>> It's people that are sponsored, not packages. You need to convince a >>>> potential sponsor that you're a competent packager *and* you know >>>> your way around the Fedora Extras processes. >>>> >>>> See: http://fedoraproject.org/wiki/Extras/HowToGetSponsored >>>> >>> So how is this different from >>> http://fedoraproject.org/wiki/Extras/HowToGetSponsored? >>> >>> The Extras page only links to this one and not what you provided. >> >> Sorry, I can't parse that comment. The URL in your response is exactly >> the same as the URL I quoted. > > Ugh. Sorry. Wrong copy and paste. > > http://fedoraproject.org/wiki/Extras/SponsorProcess http://fedoraproject.org/wiki/Extras/SponsorProcess This one seems to be written for sponsors (or potential sponsors). http://fedoraproject.org/wiki/Extras/HowToGetSponsored This one is written for people that are trying to get sponsored. Paul. From sundaram at fedoraproject.org Thu Jul 27 15:59:17 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 27 Jul 2006 21:29:17 +0530 Subject: Package review request - Jokosher In-Reply-To: <44C8E094.6030007@city-fan.org> References: <364d303b0607270754q5904add3ke432469e591bbdb0@mail.gmail.com> <44C8D7B5.9050808@city-fan.org> <44C8D8E6.9080507@fedoraproject.org> <44C8DD49.3090603@city-fan.org> <44C8DF88.6030106@fedoraproject.org> <44C8E094.6030007@city-fan.org> Message-ID: <44C8E2D5.1040707@fedoraproject.org> Paul Howarth wrote: > Rahul wrote: >> Paul Howarth wrote: >>> Rahul wrote: >>>> Paul Howarth wrote: >>>>> Chris Brown wrote: >>>>>> Hi folks, >>>>>> >>>>>> The subject says it all. This one's low hanging fruit that I'm >>>>>> sure can be >>>>>> accepted pretty quickly. If you have a moment I need someone to >>>>>> sponsor: >>>>>> >>>>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199029 >>>>>> >>>>>> which is Jokosher, a non-linear audio editor written in python and >>>>>> utilising >>>>>> gstreamer libraries. I cant see any reason for this to be held >>>>>> back but then >>>>>> again, you might. :) >>>>> >>>>> It's people that are sponsored, not packages. You need to convince >>>>> a potential sponsor that you're a competent packager *and* you know >>>>> your way around the Fedora Extras processes. >>>>> >>>>> See: http://fedoraproject.org/wiki/Extras/HowToGetSponsored >>>>> >>>> So how is this different from >>>> http://fedoraproject.org/wiki/Extras/HowToGetSponsored? >>>> >>>> The Extras page only links to this one and not what you provided. >>> >>> Sorry, I can't parse that comment. The URL in your response is >>> exactly the same as the URL I quoted. >> >> Ugh. Sorry. Wrong copy and paste. >> >> http://fedoraproject.org/wiki/Extras/SponsorProcess > > http://fedoraproject.org/wiki/Extras/SponsorProcess > This one seems to be written for sponsors (or potential sponsors). > > http://fedoraproject.org/wiki/Extras/HowToGetSponsored > This one is written for people that are trying to get sponsored. > Ok. That makes sense. Crosslinked both pages and from the Extras main page too. Rahul From orion at cora.nwra.com Thu Jul 27 17:36:58 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 27 Jul 2006 11:36:58 -0600 Subject: Buildsys status pages down Message-ID: <44C8F9BA.3050101@cora.nwra.com> Get: Error was: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Thu Jul 27 17:38:27 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 27 Jul 2006 11:38:27 -0600 Subject: admin site package In-Reply-To: References: <668bb39a0607251327t2f532a7di64a81bda9f57d756@mail.gmail.com> Message-ID: <44C8FA13.1020505@cora.nwra.com> Rex Dieter wrote: > Micha? Bentkowski wrote: > >> When I took a look on buildsys site today, I saw one package is >> building for over one day. > > I already reported it to http://admin.fedoraproject.org/tickets/ this > morning. > > -- Rex > What username/password are we supposed to use for this? I'm afraid I've forgotten mine (assuming I have one...) -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Thu Jul 27 17:47:19 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 27 Jul 2006 11:47:19 -0600 Subject: Buildsys status pages down In-Reply-To: <44C8F9BA.3050101@cora.nwra.com> References: <44C8F9BA.3050101@cora.nwra.com> Message-ID: <44C8FC27.3090708@cora.nwra.com> Orion Poplawski wrote: > Get: > > Error was: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > handshake failure')] > > plague-client list appears to be returning a large and unwieldy SQL query string as well instead of build requests. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From toshio at tiki-lounge.com Thu Jul 27 19:43:29 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 27 Jul 2006 12:43:29 -0700 Subject: Future FESCo Elections In-Reply-To: <200607271540.k6RFeaWs006558@ludwig-alpha.unil.ch> References: <200607271540.k6RFeaWs006558@ludwig-alpha.unil.ch> Message-ID: <1154029409.3162.19.camel@localhost> On Thu, 2006-07-27 at 17:40 +0200, Christian.Iseli at licr.org wrote: > Just an idea: why not have elections when at least 2-3 non FESCo members > express interest into becoming FESCo members ? > > We could have a wiki page where people could express their interest and > intentions if elected > > We could send emails to appropriate lists after each FC release reminding > interested people to register on the page. > > A couple weeks after the reminding email, we look at the page and if enough > people are registered, we start the election process That's an intriguing idea. It means we'll know who our pool of motivated individuals are. But it doesn't give people who are on FESCo a definite timeframe for their commitments, though. It also doesn't give people the incentive of, uh oh: only five people are signing up for seven slots, maybe I should step up and do my part. Maybe there needs to be two pieces of this: people who want to be candidates for the next FESCo election and FESCo members who don't want to be on FESCo next time. Any one else have ideas about how well this would work? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Thu Jul 27 21:00:01 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 27 Jul 2006 23:00:01 +0200 Subject: Future FESCo Elections In-Reply-To: <200607271540.k6RFeaWs006558@ludwig-alpha.unil.ch> References: <1153768355.3209.48.camel@localhost> <200607271540.k6RFeaWs006558@ludwig-alpha.unil.ch> Message-ID: <20060727230001.0cfd7e05.bugs.michael@gmx.net> On Thu, 27 Jul 2006 17:40:36 +0200, Christian.Iseli at licr.xxx wrote: > Just an idea: why not have elections when at least 2-3 non FESCo members > express interest into becoming FESCo members ? This approaches "the problem" from the wrong side. First of all, there should be no need "to be in FESCo" to get something done. It ought to be the opposite. Get something done first, probably multiple times, and then it may turn out as useful to let the same person take over more things as they come up. E.g. fill well-defined positions in FESCo, so it is ensured that FESCo always has somebody who communicates with the contributor community in satisfactory ways (announcements etc.) Second, if current members of FESCo are working on something which takes some time (also longer non-public and possibly controversial discussions), it would be a disruptive action to let the community decide on whom to replace at an unfortunate point of time. Third, in a project of volunteers, there is no command hierarchy, so for many "tasks" or policies FESCo needs to meet the community's requirements and pick up ideas/input from the community anyway. Wrong decisions coming out of FESCo could lead to uproar, unhappy contributors. It doesn't help if FESCo consists of people with the wrong focus, who are elected with the help of lobbyism or by nature of a bigger target-group among the contributors. Why don't you come up with explanations on how FESCo works and what we need FESCo for? How is a FESCo member's activity measured? How is FESCo's contributor community's acceptance measured? And how exactly does FESCo work in conjunction with the the Packaging Committee (or whatever it is called officially)? I'm talking about veto powers, quorum and things like that. From bugs.michael at gmx.net Thu Jul 27 21:04:05 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 27 Jul 2006 23:04:05 +0200 Subject: Extras Wiki - [was: Re: Package review request - Jokosher] In-Reply-To: <44C8E2D5.1040707@fedoraproject.org> References: <364d303b0607270754q5904add3ke432469e591bbdb0@mail.gmail.com> <44C8D7B5.9050808@city-fan.org> <44C8D8E6.9080507@fedoraproject.org> <44C8DD49.3090603@city-fan.org> <44C8DF88.6030106@fedoraproject.org> <44C8E094.6030007@city-fan.org> <44C8E2D5.1040707@fedoraproject.org> Message-ID: <20060727230405.c6f123af.bugs.michael@gmx.net> On Thu, 27 Jul 2006 21:29:17 +0530, Rahul wrote: > > http://fedoraproject.org/wiki/Extras/SponsorProcess > > This one seems to be written for sponsors (or potential sponsors). > > > > http://fedoraproject.org/wiki/Extras/HowToGetSponsored > > This one is written for people that are trying to get sponsored. > > > > Ok. That makes sense. Crosslinked both pages and from the Extras main > page too. I'm not sure who has been working on the Extras main page recently, but it has become a lot less readable with all the sections and even an empty section for developers. It is no longer an index that's nice to the eyes. It looks a lot like splitting it up into separate pages would be very useful. From buildsys at fedoraproject.org Thu Jul 27 21:16:21 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 27 Jul 2006 17:16:21 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-27 Message-ID: <20060727211621.D052F152160@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 6 CCfits-1.5-1.fc5 clanbomber-1.05-2.fc5 dumb-0.9.3-4.fc5 fbida-2.03-12.fc5 kadu-0.5.0-0.5.20060727svn.fc5 kdesvn-0.9.1-1.fc5 Packages built and released for Fedora Extras 4: 3 CCfits-1.5-1.fc4 fbida-2.03-8.fc4 kdesvn-0.9.1-1.fc4 Packages built and released for Fedora Extras 3: 2 CCfits-1.5-1.fc3 fbida-2.03-8.fc3 Packages built and released for Fedora Extras development: 19 CCfits-1.5-1.fc6 PyQt-qscintilla-3.16-4.fc6 aplus-fsf-4.20.2-5.fc6 cvs2svn-1.4.0-0.4.rc1.fc6 dumb-0.9.3-4.fc6 exim-4.62-6.fc6 galago-daemon-0.5.0-5.fc6 ip6sic-0.1-2.fc6 kadu-0.5.0-0.4.20060716svn.fc6 kdesvn-0.9.1-1.fc6 libgalago-0.5.1-6.fc6 mercator-0.2.4-2.fc6 perl-POE-Wheel-Null-0.01-1.fc6 python-dateutil-1.1-3.fc6 sage-0.1.2-4.fc6 udftools-1.0.0b3-6.fc6 vips-7.10.20-2.fc6 wfmath-0.3.4-4.fc6 xdg-utils-1.0-0.4.20060721 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Jul 27 21:16:46 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 27 Jul 2006 17:16:46 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-27 Message-ID: <20060727211646.37EE6152160@buildsys.fedoraproject.org> azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) fbida: 5: 0:2.03-12.fc5 (FE5) 6: 0:2.03-11.fc6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gcdmaster: 4: 0:1.2.1-5.fc4 (FE4) 5: 0:1.2.1-4.fc5 (FE5) 6: 0:1.2.1-4.fc5 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) inkscape: 4: 0:0.44-3.fc4 (FE4) 5: 0:0.44-2.fc5 (FE5) 6: 0:0.44-2.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) kadu: 5: 0:0.5.0-0.5.20060727svn.fc5 (FE5) 6: 0:0.5.0-0.4.20060716svn.fc6 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-1.2.1 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-14.fc6 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) quagga: 4: 0:0.98.6-1.fc4 (FC4-updates) 5: 0:0.98.6-1.FC5 (FC5-updates) 6: 0:0.98.6-2.1 (FC6) regexxer: 4: 0:0.8-5.fc4 (FE4) 5: 0:0.8-4.fc5 (FE5) 6: 0:0.8-4.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) xorg-x11-drv-nv: 5: 0:1.2.0-3.fc5 (FC5-updates) 6: 0:1.2.0-2.fc6 (FC6) From buildsys at fedoraproject.org Thu Jul 27 21:36:46 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 27 Jul 2006 21:36:46 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-27 Message-ID: <20060727213646.26535.62854@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 (12 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc (12 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 (12 days) mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 (8 days) libvisual-plugins - 0.2.0-3.fc5.ppc (8 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (8 days) oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (71 days) syck-php - 0.55-7.fc5.ppc (71 days) syck-php - 0.55-7.fc5.x86_64 (71 days) spr AT astrax.fis.ucm.es CCfits-docs - 1.5-1.fc5.i386 CCfits-docs - 1.5-1.fc5.ppc CCfits-docs - 1.5-1.fc5.x86_64 Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc5.i386 requires /usr1/local/bin/perl5 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.i386 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc5.ppc requires /usr1/local/bin/perl5 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.ppc requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc5.x86_64 requires /usr1/local/bin/perl5 libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc5.x86_64 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 ====================================================================== New report for: spr AT astrax.fis.ucm.es package: CCfits-docs - 1.5-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: /usr1/local/bin/perl5 package: CCfits-docs - 1.5-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: /usr1/local/bin/perl5 package: CCfits-docs - 1.5-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: /usr1/local/bin/perl5 From buildsys at fedoraproject.org Thu Jul 27 21:36:46 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 27 Jul 2006 21:36:46 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-27 Message-ID: <20060727213646.26517.53598@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 (112 days) fluxbox - 0.9.15.1-1.fc3.x86_64 (112 days) spr AT astrax.fis.ucm.es CCfits-docs - 1.5-1.fc3.i386 CCfits-docs - 1.5-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc3.i386 requires /usr1/local/bin/perl5 fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc3.x86_64 requires /usr1/local/bin/perl5 fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg ====================================================================== New report for: spr AT astrax.fis.ucm.es package: CCfits-docs - 1.5-1.fc3.i386 from fedora-extras-3-i386 unresolved deps: /usr1/local/bin/perl5 package: CCfits-docs - 1.5-1.fc3.x86_64 from fedora-extras-3-x86_64 unresolved deps: /usr1/local/bin/perl5 From buildsys at fedoraproject.org Thu Jul 27 21:36:46 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 27 Jul 2006 21:36:46 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-27 Message-ID: <20060727213646.26538.15246@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de pdftk - 1.12-6.fc5.i386 pdftk - 1.12-6.fc5.ppc pdftk - 1.12-6.fc5.x86_64 andreas.bierfert AT lowlatency.de wine-core - 0.9.17-1.fc6.i386 byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 (8 days) gaim-guifications - 2.12-3.fc5.ppc (8 days) gaim-guifications - 2.12-3.fc5.x86_64 (8 days) caillon AT redhat.com banshee - 0.10.8-1.i386 (8 days) banshee - 0.10.8-1.ppc (8 days) banshee - 0.10.8-1.x86_64 (8 days) libipoddevice - 0.4.5-1.fc6.i386 (7 days) libipoddevice - 0.4.5-1.fc6.ppc (7 days) libipoddevice - 0.4.5-1.fc6.x86_64 (7 days) cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 (8 days) gaim-gaym - 0.96-2.fc6.ppc (8 days) gaim-gaym - 0.96-2.fc6.x86_64 (8 days) dennis AT ausil.us knetworkmanager - 0.1-0.3.svn20060625.fc6.i386 (7 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.ppc (7 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.x86_64 (7 days) fedora AT leemhuis.info gsynaptics - 0.9.8-1.fc6.ppc (8 days) gauret AT free.fr amarok - 1.4.1-3.fc6.i386 amarok - 1.4.1-3.fc6.ppc green AT redhat.com azureus - 2.4.0.3-0.20060328cvs_5.fc6.i386 azureus - 2.4.0.3-0.20060328cvs_5.fc6.ppc azureus - 2.4.0.3-0.20060328cvs_5.fc6.x86_64 itext - 1.3-1jpp_8.fc5.i386 itext - 1.3-1jpp_8.fc5.ppc itext - 1.3-1jpp_8.fc5.x86_64 jogl - 1.1.1-14.fc5.i386 (4 days) jogl - 1.1.1-14.fc5.ppc (4 days) rssowl - 1.2-12.fc6.i386 rssowl - 1.2-12.fc6.ppc rssowl - 1.2-12.fc6.x86_64 ivazquez AT ivazquez.net gnome-applet-music - 0.9.0-1.fc6.i386 (8 days) gnome-applet-music - 0.9.0-1.fc6.ppc (8 days) gnome-applet-music - 0.9.0-1.fc6.x86_64 (8 days) nautilus-search-tool - 0.2-1.fc5.i386 (8 days) nautilus-search-tool - 0.2-1.fc5.ppc (8 days) nautilus-search-tool - 0.2-1.fc5.x86_64 (8 days) matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 (8 days) diradmin - 1.7.1-4.fc5.ppc (8 days) diradmin - 1.7.1-4.fc5.x86_64 (8 days) gtktalog - 1.0.4-7.fc5.i386 (8 days) gtktalog - 1.0.4-7.fc5.ppc (8 days) gtktalog - 1.0.4-7.fc5.x86_64 (8 days) mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 (8 days) gfontview - 0.5.0-5.fc5.ppc (8 days) gfontview - 0.5.0-5.fc5.x86_64 (8 days) gtkhtml36 - 3.6.2-5.fc6.i386 (8 days) gtkhtml36 - 3.6.2-5.fc6.ppc (8 days) gtkhtml36 - 3.6.2-5.fc6.x86_64 (8 days) libvisual-plugins - 0.2.0-3.fc5.i386 (8 days) libvisual-plugins - 0.2.0-3.fc5.ppc (8 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (8 days) oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (8 days) syck-php - 0.55-7.fc5.ppc (8 days) syck-php - 0.55-7.fc5.x86_64 (8 days) pertusus AT free.fr cernlib - 2005-21.fc6.ppc (8 days) cernlib-packlib - 2005-21.fc6.ppc (8 days) dap-hdf4_handler - 3.6.0-3.fc5.i386 (4 days) dap-hdf4_handler - 3.6.0-3.fc5.ppc (4 days) dap-hdf4_handler - 3.6.0-3.fc5.x86_64 (4 days) patchy - 2005-21.fc6.ppc (8 days) paw - 2005-21.fc6.ppc (8 days) qspencer AT ieee.org octave-forge - 2006.07.09-2.fc6.i386 (4 days) octave-forge - 2006.07.09-2.fc6.ppc (4 days) octave-forge - 2006.07.09-2.fc6.x86_64 (4 days) robert AT marcanoonline.com ganymed-ssh2 - 209-4.fc6.i386 ganymed-ssh2 - 209-4.fc6.ppc ganymed-ssh2 - 209-4.fc6.x86_64 javasvn - 1.0.6-1.fc6.i386 javasvn - 1.0.6-1.fc6.ppc javasvn - 1.0.6-1.fc6.x86_64 rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 (8 days) libibverbs - 1.0.3-1.fc6.ppc (8 days) libibverbs - 1.0.3-1.fc6.x86_64 (8 days) libibverbs-utils - 1.0.3-1.fc6.i386 (8 days) libibverbs-utils - 1.0.3-1.fc6.ppc (8 days) libibverbs-utils - 1.0.3-1.fc6.x86_64 (8 days) spr AT astrax.fis.ucm.es CCfits-docs - 1.5-1.fc6.i386 CCfits-docs - 1.5-1.fc6.ppc CCfits-docs - 1.5-1.fc6.x86_64 thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 (8 days) directfb - 0.9.24-5.fc5.ppc (8 days) directfb - 0.9.24-5.fc5.x86_64 (8 days) Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc6.i386 requires /usr1/local/bin/perl5 amarok-1.4.1-3.fc6.i386 requires HelixPlayer azureus-2.4.0.3-0.20060328cvs_5.fc6.i386 requires libgcj.so.7 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 banshee-0.10.8-1.i386 requires libdbus-1.so.2 dap-hdf4_handler-3.6.0-3.fc5.i386 requires libdap.so.4 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 ganymed-ssh2-209-4.fc6.i386 requires libgcj.so.7 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.i386 requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.i386 requires libdbus-1.so.2 gtkhtml36-3.6.2-5.fc6.i386 requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 itext-1.3-1jpp_8.fc5.i386 requires libgcj.so.7 javasvn-1.0.6-1.fc6.i386 requires libgcj.so.7 jogl-1.1.1-14.fc5.i386 requires libgcj.so.7 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-qt-1.so.1 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.i386 requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.i386 requires libgailutil.so.17 octave-forge-2006.07.09-2.fc6.i386 requires libdap.so.4 pdftk-1.12-6.fc5.i386 requires libgcj.so.7 rssowl-1.2-12.fc6.i386 requires libgcj.so.7 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc6.ppc requires /usr1/local/bin/perl5 amarok-1.4.1-3.fc6.ppc requires HelixPlayer azureus-2.4.0.3-0.20060328cvs_5.fc6.ppc requires libgcj.so.7 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 banshee-0.10.8-1.ppc requires libdbus-1.so.2 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 dap-hdf4_handler-3.6.0-3.fc5.ppc requires libdap.so.4 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 ganymed-ssh2-209-4.fc6.ppc requires libgcj.so.7 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.ppc requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.ppc requires libdbus-1.so.2 gsynaptics-0.9.8-1.fc6.ppc requires synaptics gtkhtml36-3.6.2-5.fc6.ppc requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 itext-1.3-1jpp_8.fc5.ppc requires libgcj.so.7 javasvn-1.0.6-1.fc6.ppc requires libgcj.so.7 jogl-1.1.1-14.fc5.ppc requires libgcj.so.7 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-qt-1.so.1 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.ppc requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.ppc requires libgailutil.so.17 octave-forge-2006.07.09-2.fc6.ppc requires libdap.so.4 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 pdftk-1.12-6.fc5.ppc requires libgcj.so.7 rssowl-1.2-12.fc6.ppc requires libgcj.so.7 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc6.x86_64 requires /usr1/local/bin/perl5 azureus-2.4.0.3-0.20060328cvs_5.fc6.x86_64 requires libgcj.so.7()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) banshee-0.10.8-1.x86_64 requires libdbus-1.so.2()(64bit) dap-hdf4_handler-3.6.0-3.fc5.x86_64 requires libdap.so.4()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 ganymed-ssh2-209-4.fc6.x86_64 requires libgcj.so.7()(64bit) gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libgailutil.so.17()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) gtkhtml36-3.6.2-5.fc6.x86_64 requires libgailutil.so.17()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) itext-1.3-1jpp_8.fc5.x86_64 requires libgcj.so.7()(64bit) javasvn-1.0.6-1.fc6.x86_64 requires libgcj.so.7()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-qt-1.so.1()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-1.so.2()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libipoddevice-0.4.5-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) nautilus-search-tool-0.2-1.fc5.x86_64 requires libgailutil.so.17()(64bit) octave-forge-2006.07.09-2.fc6.x86_64 requires libdap.so.4()(64bit) pdftk-1.12-6.fc5.x86_64 requires libgcj.so.7()(64bit) rssowl-1.2-12.fc6.x86_64 requires libgcj.so.7()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 wine-core-0.9.17-1.fc6.i386 requires libglut.so.3 ====================================================================== New report for: spr AT astrax.fis.ucm.es package: CCfits-docs - 1.5-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: /usr1/local/bin/perl5 package: CCfits-docs - 1.5-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: /usr1/local/bin/perl5 package: CCfits-docs - 1.5-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: /usr1/local/bin/perl5 ====================================================================== New report for: gauret AT free.fr package: amarok - 1.4.1-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: HelixPlayer package: amarok - 1.4.1-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: HelixPlayer From buildsys at fedoraproject.org Thu Jul 27 21:36:46 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 27 Jul 2006 21:36:46 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-27 Message-ID: <20060727213646.26532.20647@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 (12 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc (12 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 (12 days) spr AT astrax.fis.ucm.es CCfits-docs - 1.5-1.fc4.i386 CCfits-docs - 1.5-1.fc4.ppc CCfits-docs - 1.5-1.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc4.i386 requires /usr1/local/bin/perl5 python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc4.ppc requires /usr1/local/bin/perl5 python-ruledispatch-0.5a0-0.1.svnr2115.fc4.ppc requires python-protocols >= 0:1.0 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc4.x86_64 requires /usr1/local/bin/perl5 python-ruledispatch-0.5a0-0.1.svnr2115.fc4.x86_64 requires python-protocols >= 0:1.0 ====================================================================== New report for: spr AT astrax.fis.ucm.es package: CCfits-docs - 1.5-1.fc4.i386 from fedora-extras-4-i386 unresolved deps: /usr1/local/bin/perl5 package: CCfits-docs - 1.5-1.fc4.x86_64 from fedora-extras-4-x86_64 unresolved deps: /usr1/local/bin/perl5 package: CCfits-docs - 1.5-1.fc4.ppc from fedora-extras-4-ppc unresolved deps: /usr1/local/bin/perl5 From Christian.Iseli at licr.org Thu Jul 27 23:30:57 2006 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 28 Jul 2006 01:30:57 +0200 Subject: Future FESCo Elections In-Reply-To: Your message of "Thu, 27 Jul 2006 23:00:01 +0200." <20060727230001.0cfd7e05.bugs.michael@gmx.net> Message-ID: <200607272331.k6RNUwhb011985@mx3.redhat.com> All this is just IMHO... bugs.michael at gmx.net said: > Why don't you come up with explanations on how FESCo works FESCo meets every thursday on IRC, discusses issues raised on http://fedoraproject.org/wiki/Extras/Schedule, puts them to a vote and communicates the results on f-e-l and in http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings > and what we need FESCo for? We need a FESCo because it seems we need to get decisions on some issues on a regular (weekly) basis. > How is a FESCo member's activity measured? See how many meetings he participated in. > How is FESCo's contributor community's acceptance measured? through a vote from the community > And how exactly does FESCo work in conjunction with the the Packaging > Committee (or whatever it is called officially)? > I'm talking about veto powers, quorum and things like that. Items discussed by the Packaging Committee are reported to FESCo weekly and put to discussion within FESCo. A vote tells whether FESCo approves of the PC decisions or not. Refused items are either re-discussed within the PC, or brought to FAB. I think being in FESCo has no direct relationship with doing work within FE. Any volunteer with a signed CLA can do work within FE. Being in FESCo simply means that: a. you agreed to spend some time each week to discuss FE issues and take decisions on those issues in FE's best interest. b. you were elected to do that, i.e., a sizeable number of FE contributors think you can be trusted with a. Cheers, Christian From sundaram at fedoraproject.org Thu Jul 27 23:36:28 2006 From: sundaram at fedoraproject.org (Rahul) Date: Fri, 28 Jul 2006 05:06:28 +0530 Subject: Move Squirrelmail to Extras? In-Reply-To: <44B1CC10.8060204@redhat.com> References: <44B1CC10.8060204@redhat.com> Message-ID: <44C94DFC.1060600@fedoraproject.org> Warren Togami wrote: > I'd like to move it to Extras too. Would you like to coordinate and be > co-maintainers of squirrelmail? > > http://cvs.fedora.redhat.com/viewcvs/devel/squirrelmail/ > Beware. Red Hat's squirrelmail has a large amount of ugly looking i18n > and language specific fixes and hacks. Some of these fixes need to be > pushed upstream, but others (like the scripted mass encoding change) > might never be accepted upstream. > > I'd also prefer to keep it a single package that Provides > squirrelmail-i18n rather than split it like your upstream package. Is > this problematic? > > Aside from this sub-package difference, I made modifications to the Red > Hat package over the past years in an attempt to make it upgrade > compatible with your upstream package. > > What things would you like to do to the current fc6 package? Let's > discuss this. > What happened to this discussion? Is squirrelmail still planned to be moved over into Extras? Rahul From michael at knox.net.nz Fri Jul 28 02:36:53 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 28 Jul 2006 14:36:53 +1200 Subject: HelixPlayer Message-ID: <44C97845.7000800@knox.net.nz> So, HelixPlayer has been axed form Core. " ------- Additional Comments From alexl at redhat.com 2006-07-27 22:20 EST ------- Removed in rawhide " Has anyone offered to pick it up? Or can amarok live without it? Michael From cweyl at alumni.drew.edu Fri Jul 28 05:29:39 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 27 Jul 2006 22:29:39 -0700 Subject: hard time finding packages really for review In-Reply-To: References: <20060724220833.GA2691@free.fr> <7dd7ab490607260937k18394674ycb88e0fb010a06fb@mail.gmail.com> <20060726165005.GD2398@free.fr> <20060726185136.GE2398@free.fr> <20060726210450.GB2432@free.fr> <20060726223705.GE2432@free.fr> Message-ID: <7dd7ab490607272229q6cc4f8acvff7c989dca1694f5@mail.gmail.com> On 7/26/06, Jason L Tibbitts III wrote: > >>>>> "JLT" == Jason L Tibbitts, writes: > > JLT> Yes, you can't go back to new from any other state, > JLT> unfortunately. > > I'll see if I can get get someone in power to consider an UNASSIGNED > state. I'd propose that we just use NEEDINFO for now. +1 to NEEDINFO/NEEDINFO_REPORTER. Simple, doesn't require any bugzilla tweaks, gets the point across. -Chris -- Chris Weyl Ex astris, scientia From Christian.Iseli at licr.org Fri Jul 28 10:39:50 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 28 Jul 2006 12:39:50 +0200 Subject: owners owners.list,1.1333,1.1334 In-Reply-To: <200607280354.k6S3sUCs031148@cvs-int.fedora.redhat.com> References: <200607280354.k6S3sUCs031148@cvs-int.fedora.redhat.com> Message-ID: <20060728123950.7a0da1bd@ludwig-alpha> Hi Chris, On Thu, 27 Jul 2006 20:54:28 -0700 "Chris Weyl" (cweyl) wrote: > Author: cweyl > > Update of /cvs/extras/owners > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv31131 > > Modified Files: > owners.list > Log Message: > added perl-POE-Component-Client-HTTP > > > Index: owners.list > =================================================================== > RCS file: /cvs/extras/owners/owners.list,v > retrieving revision 1.1333 > retrieving revision 1.1334 > diff -u -r1.1333 -r1.1334 > --- owners.list 27 Jul 2006 19:40:44 -0000 1.1333 > +++ owners.list 28 Jul 2006 03:54:28 -0000 1.1334 > @@ -548,7 +548,6 @@ > Fedora Extras|gwenview|Simple image viewer for KDE|gauret at free.fr|extras-qa at fedoraproject.org| > Fedora Extras|gwget|GUI Download manager using wget|fedora at christoph-wickert.de|extras-qa at fedoraproject.org| > Fedora Extras|gxemul|Instruction-level machine emulator|tcallawa at redhat.com|extras-qa at fedoraproject.org| > -Fedora Extras|ht2html|The www.python.org Web site generator|ifoox at redhat.com|extras-qa at fedoraproject.org| > Fedora Extras|hackedbox|The bastard son of Blackbox, a small and fast Window Manager|matthias at rpmforge.net|extras-qa at fedoraproject.org| > Fedora Extras|haddock|Documentation tool for annotated Haskell source code|petersen at redhat.com|extras-qa at fedoraproject.org| > Fedora Extras|hamlib|Run-time library to control radio transceivers and receivers|ivazquez at ivazquez.net|extras-qa at fedoraproject.org| Uh oh, you just zapped ht2html ... Please add it back Thanks, Christian From rdieter at math.unl.edu Fri Jul 28 11:41:32 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Jul 2006 06:41:32 -0500 Subject: HelixPlayer References: <44C97845.7000800@knox.net.nz> Message-ID: Michael J. Knox wrote: > So, HelixPlayer has been axed form Core. ... > Has anyone offered to pick it up? not yet. > >Or can amarok live without it? Sorta kinda, it has hacked-in gstreamer support (atm). This support should get better/official over time. -- Rex From rdieter at math.unl.edu Fri Jul 28 13:17:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Jul 2006 08:17:59 -0500 Subject: interest in qt-4.2.0(tp1)? Message-ID: For Extras/devel, is there any interest in upgrading qt4-4.1 to qt-4.2.0-tp1 (tech preview 1)? According to http://www.trolltech.com/company/newsroom/announcements/press.2006-06-26.0683224314/ (and qt4-4.2.0-tp1's README), "We plan to enter the beta phase in Q3, 2006 and release the final Qt 4.2 in early Q4, 2006." The final release matches *pretty* close to fc6 final release date of Early October (according to http://fedoraproject.org/wiki/Core/Schedule ) Opinions? AFAIC, I'm leaning toward doing it especially since qt4-4.2 includes some new/nice features including dbus bindings. -- Rex From laurent.rineau__fedora_extras at normalesup.org Fri Jul 28 13:37:09 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 28 Jul 2006 15:37:09 +0200 Subject: interest in qt-4.2.0(tp1)? In-Reply-To: References: Message-ID: <200607281537.09095@rineau.schtroumpfette> On Friday 28 July 2006 15:17, Rex Dieter wrote: > For Extras/devel, is there any interest in upgrading qt4-4.1 to > qt-4.2.0-tp1 (tech preview 1)? According to > http://www.trolltech.com/company/newsroom/announcements/press.2006-06-26.06 >83224314/ (and qt4-4.2.0-tp1's README), > "We plan to enter the beta phase in Q3, 2006 and release the final Qt 4.2 > in early Q4, 2006." > > The final release matches *pretty* close to fc6 final release date of Early > October (according to http://fedoraproject.org/wiki/Core/Schedule ) > > Opinions? IMHO, qt-4.2.0-tp1 can be a good candidate for FE-devel. I hope you will even publish versions for FC-4 and FC-5 in some testing repo of kde-redhat.sf.net. ... What about snapshots of KDE-4, too? :-) You could also even package the daily qt snapshots from ftp://ftp.trolltech.com/qt/snapshots/ Once Qt-4.2.0 is released, as it will be binary compatible with previous (and future) Qt-4 version, I would find no objection to push it into FC-5 and FC-6. From rdieter at math.unl.edu Fri Jul 28 14:29:07 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Jul 2006 09:29:07 -0500 Subject: interest in qt-4.2.0(tp1)? References: <200607281537.09095@rineau.schtroumpfette> Message-ID: Laurent Rineau wrote: > IMHO, qt-4.2.0-tp1 can be a good candidate for FE-devel. Good. > >I hope you will > even publish versions for FC-4 and FC-5 in some testing repo of > kde-redhat.sf.net. ... It's in "unstable" (and has been for a little while). > What about snapshots of KDE-4, too? :-) First things first... > You could also even package the daily qt snapshots from > ftp://ftp.trolltech.com/qt/snapshots/ I thought about that, and rejected the idea. Those are potentially untested and almost certainly unstable from time-to-time... and I don't have the time/interest to respin this sucker every few days. -- Rex From Matt_Domsch at dell.com Fri Jul 28 14:41:10 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 28 Jul 2006 09:41:10 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-28 Message-ID: <20060728094110.A26816@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Fri Jul 28 07:54:31 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: argus-2.0.6.fixes.1-11.fc6 197215 NEW bidiv-1.5-3.fc5 197224 NEW flow-tools-0.68-10.fc6 197706 NEW gazpacho-0.6.6-1.fc6 197793 NEW Number failed to build: 101 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 90 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 64 ---------------------------------- atitvout-0.4-5 andreas.bierfert at lowlatency.de azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com camstream-0.26.3-9.fc5 nomis80 at nomis80.org contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net ddskk-12.2.0-7.fc5 petersen at redhat.com diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com epiphany-extensions-2.14.1-1 caillon at redhat.com exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com flim-1.14.7-3 petersen at redhat.com foobillard-3.0a-4 mitr at redhat.com freenx-0.5.0-2.fc6 zipsonic at gmail.com gambas-1.0.14-2.fc5 tcallawa at redhat.com gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de gobby-0.4.0-6.rc2.fc6 lmacken at redhat.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org GtkAda-2.4.0-11.fc5 gemi at bluewin.ch ifplugd-0.24-6 aaron.bennett at olin.edu john-1.6-4 ghenry at suretecsystems.com kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu ladspa-1.12-5 thomas at apestaart.org libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Macaulay2-0.9.8-0.3.cvs20060327.fc6 rdieter at math.unl.edu MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mhonarc-2.6.16-1.fc6 gauret at free.fr mlton-20051202-8.fc6 adam at spicenitz.org new-1.3.7-2 redhat at flyn.org nx-2.0.0-3.fc6 zipsonic at gmail.com opencv-0.9.7-15.fc5 nomis80 at nomis80.org pam_keyring-0.0.7-2 redhat at flyn.org perl-Unicode-Map8-0.12-8.fc5 gauret at free.fr perl-Unicode-MapUTF8-1.09-6.fc5 gauret at free.fr php-pear-DB-1.7.6-6 rpm at timj.co.uk pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.16-1.fc6 gemi at bluewin.ch python-goopy-0.1-1 pjones at redhat.com python-reportlab-1.20-5.fc5 bdpepple at ameritech.net python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net q-7.1-2.fc6 gemi at bluewin.ch quarry-0.1.16-2.fc5 michel.salim at gmail.com rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rssowl-1.2-12.fc6 green at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-7.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net stratagus-2.1-5.fc6 lemenkov at newmail.ru synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com uqm-0.5.0-1.fc5 icon at fedoraproject.org WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com xsp-1.1.15-6.fc6 paul at all-the-johnsons.co.uk xsupplicant-1.2.6-1.fc6 tcallawa at redhat.com z88dk-1.6-8.fc5 paul at all-the-johnsons.co.uk With bugs filed: 26 ---------------------------------- alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com cowbell-0.2.7.1-2.fc6 ['197366 CLOSED'] foolish at guezz.net dillo-0.8.6-2.fc6 ['197370 CLOSED'] andreas.bierfert at lowlatency.de fish-1.12.0-1.fc5 ['179296 NEW'] oliver at linux-kernel.at gdesklets-0.35.3-8.fc6 ['197799 NEW'] luya256 at yahoo.com gnome-applet-music-0.9.0-1.fc6 ['197924 NEW'] ivazquez at ivazquez.net gnome-schedule-1.0.0-1 ['197927 NEW'] frank at scirocco-5v-turbo.de grhino-0.15.0-5.fc5 ['197950 NEW'] michel.salim at gmail.com gtktalog-1.0.4-7.fc5 ['198897 NEW'] matthias at rpmforge.net jam-2.5-3.fc5 ['198924 NEW'] tcallawa at redhat.com kanatest-0.3.6-4.fc5 ['200076 NEW'] robert at marcanoonline.com leafpad-0.8.9-1.fc6 ['200088 NEW'] ivazquez at ivazquez.net libtabe-0.2.6-14 ['200104 NEW'] llch at redhat.com linkchecker-3.3-3 ['200282 NEW'] redhat at flyn.org logjam-4.5.3-4.fc6 ['200387 NEW'] tcallawa at redhat.com multisync-0.90.18-5.fc5 ['200399 NEW'] andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 ['200406 NEW'] dennis at ausil.us nautilus-search-tool-0.2-1.fc5 ['200420 NEW'] ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 ['200423 NEW'] andreas.bierfert at lowlatency.de nco-3.1.2-1.fc6 ['193541 NEW'] ed at eh3.com NetworkManager-vpnc-0.7.0-0.cvs20060529.1.fc6 ['200424 NEW'] davidz at redhat.com ngrep-1.44-4.fc5 ['200429 NEW'] oliver at linux-kernel.at openal-0.0.9-0.5.20060204cvs.fc5 ['200439 NEW'] andreas.bierfert at lowlatency.de xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Fri Jul 28 14:41:43 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 28 Jul 2006 09:41:43 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-07-28 Message-ID: <20060728094143.A26832@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Fri Jul 28 07:58:39 CDT 2006 Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Open Bugs which now build, and can be marked CLOSED RAWHIDE: argus-2.0.6.fixes.1-11.fc6 197215 NEW bidiv-1.5-3.fc5 197224 NEW flow-tools-0.68-10.fc6 197706 NEW gazpacho-0.6.6-1.fc6 197793 NEW Number failed to build: 78 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 77 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 49 ---------------------------------- azureus-2.4.0.3-0.20060328cvs_5.fc6 green at redhat.com camstream-0.26.3-9.fc5 nomis80 at nomis80.org contact-lookup-applet-0.14-3.fc6 bdpepple at ameritech.net ddskk-12.2.0-7.fc5 petersen at redhat.com diradmin-1.7.1-4.fc5 matthias at rpmforge.net directfb-0.9.24-5.fc5 thomas at apestaart.org ebtables-2.0.8-0.5.rc1.fc6 tcallawa at redhat.com epiphany-extensions-2.14.1-1 caillon at redhat.com exo-0.3.0-12.fc5 kevin-redhat-bugzilla at tummy.com flim-1.14.7-3 petersen at redhat.com gif2png-2.5.1-2.fc5 enrico.scholz at informatik.tu-chemnitz.de gobby-0.4.0-6.rc2.fc6 lmacken at redhat.com gstreamer08-python-0.8.4-1.fc5 thomas at apestaart.org GtkAda-2.4.0-11.fc5 gemi at bluewin.ch ifplugd-0.24-6 aaron.bennett at olin.edu john-1.6-4 ghenry at suretecsystems.com kmymoney2-0.8.4-1.fc6 rdieter at math.unl.edu ladspa-1.12-5 thomas at apestaart.org MagicPoint-1.11b-2.fc5 byte at fedoraproject.org mfstools-2.0-9.snapshot050221.fc5 tcallawa at redhat.com opencv-0.9.7-15.fc5 nomis80 at nomis80.org orange-0.3-1.cvs20051118.fc6 andreas.bierfert at lowlatency.de pam_keyring-0.0.7-2 redhat at flyn.org pitivi-0.9.9.2-3 redhat at flyn.org pl-5.6.16-1.fc6 gemi at bluewin.ch python-goopy-0.1-1 pjones at redhat.com python-TestGears-0.2-1.fc5 ivazquez at ivazquez.net quarry-0.1.16-2.fc5 michel.salim at gmail.com rpmDirectoryCheck-0.8-2 enrico.scholz at informatik.tu-chemnitz.de rssowl-1.2-12.fc6 green at redhat.com scanssh-2.1-6.fc5 oliver at linux-kernel.at SDL_ttf-2.0.7-4.fc5 bdpepple at ameritech.net ser-0.9.6-7.fc6 andreas at bawue.net serpentine-0.7-1.fc6 foolish at guezz.net stratagus-2.1-5.fc6 lemenkov at newmail.ru syck-0.55-7.fc5 oliver at linux-kernel.at synce-0.9.1-7.fc5 andreas.bierfert at lowlatency.de synce-software-manager-0.9.0-5.fc5 andreas.bierfert at lowlatency.de synce-trayicon-0.9.0-6.fc5 andreas.bierfert at lowlatency.de Terminal-0.2.4-8.fc6 kevin-redhat-bugzilla at tummy.com WindowMaker-0.92.0-8.fc5 andreas.bierfert at lowlatency.de wlassistant-0.5.5-1.fc5 tcallawa at redhat.com wv2-0.2.3-1.fc6 andreas.bierfert at lowlatency.de xaos-3.2.1-3.fc6 gemi at bluewin.ch xbsql-0.11-6.fc6 tcallawa at redhat.com xcin-2.5.3.pre3-27 llch at redhat.com xplanet-1.0.1-7 jylitalo at iki.fi xprobe2-0.3-5.fc5 lmacken at redhat.com xsupplicant-1.2.6-1.fc6 tcallawa at redhat.com With bugs filed: 28 ---------------------------------- alacarte-0.8-7.fc5 ['194250 NEW'] jpmahowald at gmail.com amaya-9.5-1.fc6 ['195652 NEW'] paul at all-the-johnsons.co.uk banshee-0.10.8-1 ['194505 NEW'] caillon at redhat.com cowbell-0.2.7.1-2.fc6 ['197366 CLOSED'] foolish at guezz.net dillo-0.8.6-2.fc6 ['197370 CLOSED'] andreas.bierfert at lowlatency.de fish-1.12.0-1.fc5 ['179296 NEW'] oliver at linux-kernel.at gdesklets-0.35.3-8.fc6 ['197799 NEW'] luya256 at yahoo.com gnome-applet-music-0.9.0-1.fc6 ['197924 NEW'] ivazquez at ivazquez.net gnome-schedule-1.0.0-1 ['197927 NEW'] frank at scirocco-5v-turbo.de grhino-0.15.0-5.fc5 ['197950 NEW'] michel.salim at gmail.com gtktalog-1.0.4-7.fc5 ['198897 NEW'] matthias at rpmforge.net jam-2.5-3.fc5 ['198924 NEW'] tcallawa at redhat.com kanatest-0.3.6-4.fc5 ['200076 NEW'] robert at marcanoonline.com kdissert-1.0.6-1.fc6 ['200078 NEW'] icon at fedoraproject.org leafpad-0.8.9-1.fc6 ['200088 NEW'] ivazquez at ivazquez.net librx-1.5-6.fc5 ['200090 NEW'] tcallawa at redhat.com libtabe-0.2.6-14 ['200104 NEW'] llch at redhat.com linkchecker-3.3-3 ['200282 NEW'] redhat at flyn.org logjam-4.5.3-4.fc6 ['200387 NEW'] tcallawa at redhat.com multisync-0.90.18-5.fc5 ['200399 NEW'] andreas.bierfert at lowlatency.de mysql-administrator-1.1.10-1.fc6 ['200406 NEW'] dennis at ausil.us nautilus-search-tool-0.2-1.fc5 ['200420 NEW'] ivazquez at ivazquez.net ncmpc-0.11.1-5.fc5 ['200423 NEW'] andreas.bierfert at lowlatency.de nco-3.1.2-1.fc6 ['193541 NEW'] ed at eh3.com NetworkManager-vpnc-0.7.0-0.cvs20060529.1.fc6 ['200424 NEW'] davidz at redhat.com ngrep-1.44-4.fc5 ['200429 NEW'] oliver at linux-kernel.at openal-0.0.9-0.5.20060204cvs.fc5 ['200439 NEW'] andreas.bierfert at lowlatency.de xfce4-weather-plugin-0.4.9-5.fc5 ['193973 ASSIGNED'] fedora at christoph-wickert.de Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From andreas at bawue.net Fri Jul 28 15:08:58 2006 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 28 Jul 2006 17:08:58 +0200 (CEST) Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-28 In-Reply-To: <20060728094110.A26816@humbolt.us.dell.com> References: <20060728094110.A26816@humbolt.us.dell.com> Message-ID: On Fri, 28 Jul 2006, Matt Domsch wrote: Could you integrate some BuildSys checks into your script? Maybe just polling "plague-client status success" and doing string-matching? Your list shows > ser-0.9.6-7.fc6 andreas at bawue.net while the buildsys has the following success entry: 12977: ser (ser-0_9_6-7_fc6) andreas at bawue.net needsign/success hammer3.fedora.redhat.com(x86_64): 7c5b130a91bc232e53d9ad285ef67c9b1491dbfc done/done hammer1.fedora.redhat.com(i386): 6827357be10bc554e8342610d4c1d2a1479cd875 done/done ppc3.fedora.redhat.com(ppc): bf10990b92164c078106b747d9dfb0fb1537ab69 done/done However, that entry must be in there for about a week or so now. bye, andreas From Matt_Domsch at dell.com Fri Jul 28 15:20:48 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 28 Jul 2006 10:20:48 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-28 In-Reply-To: References: <20060728094110.A26816@humbolt.us.dell.com> Message-ID: <20060728152047.GA6855@lists.us.dell.com> On Fri, Jul 28, 2006 at 05:08:58PM +0200, Andreas Thienemann wrote: > On Fri, 28 Jul 2006, Matt Domsch wrote: > > Could you integrate some BuildSys checks into your script? > Maybe just polling "plague-client status success" and doing > string-matching? > > Your list shows > > ser-0.9.6-7.fc6 andreas at bawue.net > > while the buildsys has the following success entry: > 12977: ser (ser-0_9_6-7_fc6) andreas at bawue.net needsign/success > hammer3.fedora.redhat.com(x86_64): 7c5b130a91bc232e53d9ad285ef67c9b1491dbfc done/done > hammer1.fedora.redhat.com(i386): 6827357be10bc554e8342610d4c1d2a1479cd875 done/done > ppc3.fedora.redhat.com(ppc): bf10990b92164c078106b747d9dfb0fb1537ab69 done/done > > However, that entry must be in there for about a week or so now. I build whatever is in the public development tree as of when the build happens. The builders haven't yet been updated to the reduced chroots, so your build succeeded there, but will very soon start to fail (which is what my builds are intended to show). My build of ser shows that BuildRequires: flex is missing from your spec (at a minimum). build.log says: flex cfg.lex make: flex: Command not found make: *** [lex.yy.c] Error 127 error: Bad exit status from /var/tmp/rpm-tmp.6968 (%build) Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From ellson at research.att.com Fri Jul 28 15:21:48 2006 From: ellson at research.att.com (John Ellson) Date: Fri, 28 Jul 2006 11:21:48 -0400 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-28 In-Reply-To: <20060728094110.A26816@humbolt.us.dell.com> References: <20060728094110.A26816@humbolt.us.dell.com> Message-ID: <44CA2B8C.6070407@research.att.com> Matt Domsch wrote: > Extras Rawhide-in-Mock Build Results for x86_64 Fri Jul 28 07:54:31 CDT 2006 > Matt, I don't fully understand what your daily reports are telling me. I work on the graphviz package, which is in extras, but I never see graphviz listed in your reports. What should I conclude? That it worked OK in mock, or that you haven't tried? John From Matt_Domsch at dell.com Fri Jul 28 15:26:39 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 28 Jul 2006 10:26:39 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-07-28 In-Reply-To: <44CA2B8C.6070407@research.att.com> References: <20060728094110.A26816@humbolt.us.dell.com> <44CA2B8C.6070407@research.att.com> Message-ID: <20060728152639.GB6855@lists.us.dell.com> On Fri, Jul 28, 2006 at 11:21:48AM -0400, John Ellson wrote: > Matt Domsch wrote: > >Extras Rawhide-in-Mock Build Results for x86_64 Fri Jul 28 07:54:31 CDT > >2006 > > > Matt, > > I don't fully understand what your daily reports are telling me. I > work on the graphviz package, which is in extras, > but I never see graphviz listed in your reports. What should I > conclude? That it worked OK in mock, or that you haven't tried? That it succeeded. I've only been reporting packages that fail to build in the reduced chroot (the list of successes is quite long :-). Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From cweyl at alumni.drew.edu Fri Jul 28 15:38:29 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 28 Jul 2006 08:38:29 -0700 Subject: owners owners.list,1.1333,1.1334 In-Reply-To: <20060728123950.7a0da1bd@ludwig-alpha> References: <200607280354.k6S3sUCs031148@cvs-int.fedora.redhat.com> <20060728123950.7a0da1bd@ludwig-alpha> Message-ID: <7dd7ab490607280838q4ace3982p8675d3facfa2a2d7@mail.gmail.com> On 7/28/06, Christian Iseli wrote: Hi Christian! > Uh oh, you just zapped ht2html ... > > Please add it back Apparently ht2html was out of alphabetical order; it was sorted back in the "right" place further down in the commit: ... Fedora Extras|hspell|A Hebrew spell checker|danken at cs.technion.ac.il|extras-qa at fedoraproject.org| +Fedora Extras|ht2html|The www.python.org Web site generator|ifoox at redhat.com|extras-qa at fedoraproject.org| Fedora Extras|htb-util|Another tool to make your life easier with HTB|extras-orphan at fedoraproject.org|extras-qa at fedoraproject.org| ... I use a script to automatically add new packages to owners.list; a side effect is that the entire list is resorted. Normally this doesn't vary the order, but it has corrected a couple sorting errors recently... -Chris -- Chris Weyl Ex astris, scientia From Christian.Iseli at licr.org Fri Jul 28 16:19:41 2006 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 28 Jul 2006 18:19:41 +0200 Subject: owners owners.list,1.1333,1.1334 In-Reply-To: <7dd7ab490607280838q4ace3982p8675d3facfa2a2d7@mail.gmail.com> References: <200607280354.k6S3sUCs031148@cvs-int.fedora.redhat.com> <20060728123950.7a0da1bd@ludwig-alpha> <7dd7ab490607280838q4ace3982p8675d3facfa2a2d7@mail.gmail.com> Message-ID: <20060728181941.0d591fee@ludwig-alpha> On Fri, 28 Jul 2006 08:38:29 -0700 "Chris Weyl" wrote: > Apparently ht2html was out of alphabetical order; it was sorted back > in the "right" place further down in the commit: Oh, me and my big mouth... Sorry for the noise. Cheers, Christian From bugs.michael at gmx.net Fri Jul 28 18:39:00 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 28 Jul 2006 20:39:00 +0200 Subject: Future FESCo Elections In-Reply-To: <200607272331.k6RNUwhb011985@mx3.redhat.com> References: <20060727230001.0cfd7e05.bugs.michael@gmx.net> <200607272331.k6RNUwhb011985@mx3.redhat.com> Message-ID: <20060728203900.b1609db2.bugs.michael@gmx.net> On Fri, 28 Jul 2006 01:30:57 +0200, Christian.Iseli at licr.xxx wrote: > All this is just IMHO... > > > Why don't you come up with explanations on how FESCo works > > FESCo meets every thursday on IRC, discusses issues raised on > http://fedoraproject.org/wiki/Extras/Schedule, puts them to a vote and > communicates the results on f-e-l and in > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings > > > and what we need FESCo for? > > We need a FESCo because it seems we need to get decisions on some issues on a > regular (weekly) basis. > > > How is a FESCo member's activity measured? > > See how many meetings he participated in. That cannot be all. Surely FESCo members need to promise a certain commitment/activity beyond those IRC meetings. For instance, it needs someone to create policy documents or drafts thereof, take over action items, know what can be achieved (infrastructure-wise and possibly only by RH employees), be the liaison man for Core<->Extras coordination, communicate with the community. It is still pretty vague how FESCo works, what sort of members are needed in FESCo, and whether maybe there are only a number of vacant and redundant seats to fill with arbitrary contributors, who give their +1/-1 in IRC meetings. Looking at the current FESCo Schedule page, there are even more items with nobody assigned to them. So, meetings are not everything. > > How is FESCo's contributor community's acceptance measured? > > through a vote from the community No, that can't be true. Look at the last election. It was not possible to vote against individuals. People with less than 50% of the possible votes entered FESCo nevertheless. Btw, with "community acceptance" I mean the community's happiness with what FESCo decides, how/whether FESCo drives things forward, whether pending issues are prioritised in a satisfactory way. From ngompa13 at gmail.com Fri Jul 28 19:51:29 2006 From: ngompa13 at gmail.com (Neal Gompa) Date: Fri, 28 Jul 2006 14:51:29 -0500 Subject: HelixPlayer In-Reply-To: References: <44C97845.7000800@knox.net.nz> Message-ID: <8278b1b0607281251t1a6862c4r1bf21b6502b3790a@mail.gmail.com> HelixPlayer messes with downloading RPMs, and it tries to play them, I'm hoping that it is fixed so that *.rpm isn't considered a RealMedia thing since RealMedia doesn't use that extension anymore... I think.... On 7/28/06, Rex Dieter wrote: > > Michael J. Knox wrote: > > > So, HelixPlayer has been axed form Core. > ... > > Has anyone offered to pick it up? > > not yet. > > > >Or can amarok live without it? > > Sorta kinda, it has hacked-in gstreamer support (atm). This support > should > get better/official over time. > > -- Rex > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugs.michael at gmx.net Fri Jul 28 20:09:25 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 28 Jul 2006 22:09:25 +0200 Subject: FESCo, hello? - [was: Re: Buildsys status pages down] In-Reply-To: <44C8F9BA.3050101@cora.nwra.com> References: <44C8F9BA.3050101@cora.nwra.com> Message-ID: <20060728220925.c65be643.bugs.michael@gmx.net> On Thu, 27 Jul 2006 11:36:58 -0600, Orion Poplawski wrote: > Get: > > Error was: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > handshake failure')] So, would anyone please give a short introduction on when the OTRS ticketing system ought to be used instead of bugzilla? I've seen it being mentioned before. What I'm still missing is the announcement for everyone. Which system do we use when? From bugs.michael at gmx.net Fri Jul 28 20:09:30 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 28 Jul 2006 22:09:30 +0200 Subject: Buildsys status pages down In-Reply-To: <44C8F9BA.3050101@cora.nwra.com> References: <44C8F9BA.3050101@cora.nwra.com> Message-ID: <20060728220930.404ea068.bugs.michael@gmx.net> On Thu, 27 Jul 2006 11:36:58 -0600, Orion Poplawski wrote: > Get: > > Error was: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > handshake failure')] > > -- Michael Schwendt Fedora Core release 5.91 (FC6 Test2) - Linux 2.6.17-1.2449.fc6 loadavg: 1.44 1.24 1.16 From fedora at leemhuis.info Fri Jul 28 20:26:21 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 28 Jul 2006 22:26:21 +0200 Subject: Future FESCo Elections In-Reply-To: <20060727230001.0cfd7e05.bugs.michael@gmx.net> References: <1153768355.3209.48.camel@localhost> <200607271540.k6RFeaWs006558@ludwig-alpha.unil.ch> <20060727230001.0cfd7e05.bugs.michael@gmx.net> Message-ID: <44CA72ED.4000106@leemhuis.info> Michael Schwendt schrieb: > On Thu, 27 Jul 2006 17:40:36 +0200, Christian.Iseli at licr.xxx wrote: >> Just an idea: why not have elections when at least 2-3 non FESCo members >> express interest into becoming FESCo members ? > This approaches "the problem" from the wrong side. First of all, there > should be no need "to be in FESCo" to get something done. Strongly agreed. > [...] > Second, if current members of FESCo are working on something which takes > some time (also longer non-public I try to keep most stuff of public lists. > and possibly controversial discussions), > it would be a disruptive action to let the community decide on whom to > replace at an unfortunate point of time. Agreed. > Third, in a project of volunteers, there is no command hierarchy, so for > many "tasks" or policies FESCo needs to meet the community's requirements > and pick up ideas/input from the community anyway. Wrong decisions coming > out of FESCo could lead to uproar, unhappy contributors. It doesn't help > if FESCo consists of people with the wrong focus, who are elected with the > help of lobbyism or by nature of a bigger target-group among the > contributors. Agreed. > Why don't you come up with explanations on how FESCo works and what we > need FESCo for? Why don't you come up with explanations? You were in FESCo for long, you know Fedora Extras in deep and how things work. BTW, I agree that we need explanations, but I think we have more important things to do than working on self-organization/documentation ATM so I put other things higher on my the ToDo-List. But if others think differently: go for it! [..] > And how exactly does FESCo > work in conjunction with the the Packaging Committee (or whatever it is > called officially)? [...] This was initially discussed in the last meeting. CU thl From tibbs at math.uh.edu Fri Jul 28 20:28:05 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 28 Jul 2006 15:28:05 -0500 Subject: FESCo, hello? - [was: Re: Buildsys status pages down] In-Reply-To: <20060728220925.c65be643.bugs.michael@gmx.net> (Michael Schwendt's message of "Fri, 28 Jul 2006 22:09:25 +0200") References: <44C8F9BA.3050101@cora.nwra.com> <20060728220925.c65be643.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> So, would anyone please give a short introduction on when the OTRS MS> ticketing system ought to be used instead of bugzilla? This isn't really FESCo's bailiwick; I don't recall the infrastructure folks telling us any more more than they've told anyone else. Until they get fully documented, why not let common sense dictate? Report problems with systems (hung machines in buildsys, certificate errors, unreachable machines, etc.) in the ticketing system and leave bugzilla to reporting issues with packaged software and tracking reviews and such. - J< From fedora at leemhuis.info Fri Jul 28 20:33:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 28 Jul 2006 22:33:28 +0200 Subject: when to use OTRS (Was: Re: FESCo, hello? - [was: Re: Buildsys status pages down]) In-Reply-To: <20060728220925.c65be643.bugs.michael@gmx.net> References: <44C8F9BA.3050101@cora.nwra.com> <20060728220925.c65be643.bugs.michael@gmx.net> Message-ID: <44CA7498.4020609@leemhuis.info> Michael Schwendt schrieb: > On Thu, 27 Jul 2006 11:36:58 -0600, Orion Poplawski wrote: >> Error was: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert >> certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl >> handshake failure')] > > So, would anyone please give a short introduction on when the OTRS > ticketing system ought to be used instead of bugzilla? > [...] > What I'm still missing is the announcement for everyone. Which system do > we use when? Well, don't ask FESCO, let's ask and kick the proper people: fedora-infrastructure at redhat.com (CCed) I'd be interested in the answers, too. I don't really like having two systems and would have prepared if we (people outside of the infrastructure group) stick to bugzilla. CU thl From bugs.michael at gmx.net Fri Jul 28 20:39:33 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 28 Jul 2006 22:39:33 +0200 Subject: FESCo, hello? - [was: Re: Buildsys status pages down] In-Reply-To: References: <44C8F9BA.3050101@cora.nwra.com> <20060728220925.c65be643.bugs.michael@gmx.net> Message-ID: <20060728223933.6561c73a.bugs.michael@gmx.net> On Fri, 28 Jul 2006 15:28:05 -0500, Jason L Tibbitts III wrote: > MS> So, would anyone please give a short introduction on when the OTRS > MS> ticketing system ought to be used instead of bugzilla? > > This isn't really FESCo's bailiwick; I don't recall the infrastructure > folks telling us any more more than they've told anyone else. > > Until they get fully documented, why not let common sense dictate? Trial-and-error guess-work is NOT common sense. Should packagers guess where to report a problem? Fact is, I (and many others) simply do not know which of the two systems to use. Some point to OTRS, some to bugzilla. This is frustrating lack of communication. > Report problems with systems (hung machines in buildsys, certificate > errors, unreachable machines, etc.) in the ticketing system and leave > bugzilla to reporting issues with packaged software and tracking > reviews and such. Well, we have a non-working Fedora Extras build system, so that is FESCo's domain. From mmcgrath at fedoraproject.org Fri Jul 28 20:42:29 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 28 Jul 2006 15:42:29 -0500 Subject: [Fedora-infrastructure-list] when to use OTRS (Was: Re: FESCo, hello? - [was: Re: Buildsys status pages down]) In-Reply-To: <44CA7498.4020609@leemhuis.info> References: <44C8F9BA.3050101@cora.nwra.com> <20060728220925.c65be643.bugs.michael@gmx.net> <44CA7498.4020609@leemhuis.info> Message-ID: <3237e4410607281342t7839ef39pdfb8b4c3cf0d342c@mail.gmail.com> Bugzilla is a bug tracking tool which is mostly to be used for development related issues. OTRS is more for trouble tickets and feature requests relating to Fedora's support infrastructure. -Mike On 7/28/06, Thorsten Leemhuis wrote: > > > Michael Schwendt schrieb: > > On Thu, 27 Jul 2006 11:36:58 -0600, Orion Poplawski wrote: > >> Error was: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > >> certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > >> handshake failure')] > > > > So, would anyone please give a short introduction on when the OTRS > > ticketing system ought to be used instead of bugzilla? > > [...] > > What I'm still missing is the announcement for everyone. Which system do > > we use when? > > Well, don't ask FESCO, let's ask and kick the proper people: > fedora-infrastructure at redhat.com (CCed) > > I'd be interested in the answers, too. I don't really like having two > systems and would have prepared if we (people outside of the > infrastructure group) stick to bugzilla. > > CU > thl From skvidal at linux.duke.edu Fri Jul 28 21:38:35 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 28 Jul 2006 17:38:35 -0400 Subject: when to use OTRS (Was: Re: FESCo, hello? - [was: Re: Buildsys status pages down]) In-Reply-To: <44CA7498.4020609@leemhuis.info> References: <44C8F9BA.3050101@cora.nwra.com> <20060728220925.c65be643.bugs.michael@gmx.net> <44CA7498.4020609@leemhuis.info> Message-ID: <1154122716.3951.39.camel@cutter> On Fri, 2006-07-28 at 22:33 +0200, Thorsten Leemhuis wrote: > > Michael Schwendt schrieb: > > On Thu, 27 Jul 2006 11:36:58 -0600, Orion Poplawski wrote: > >> Error was: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > >> certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > >> handshake failure')] > > > > So, would anyone please give a short introduction on when the OTRS > > ticketing system ought to be used instead of bugzilla? > > [...] > > What I'm still missing is the announcement for everyone. Which system do > > we use when? > > Well, don't ask FESCO, let's ask and kick the proper people: > fedora-infrastructure at redhat.com (CCed) > > I'd be interested in the answers, too. I don't really like having two > systems and would have prepared if we (people outside of the > infrastructure group) stick to bugzilla. > If you're curious what happened it was this: hammer1, hammer2, hammer3 and ppc1 all expired their ssl certs for their builder instances. I fixed them up and closed the ticket saying that's what I did. afaik that was all that was wrong. sorry for not saying more earlier - been a busy day at work. -sv From orion at cora.nwra.com Fri Jul 28 22:02:00 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 28 Jul 2006 16:02:00 -0600 Subject: HelixPlayer In-Reply-To: <8278b1b0607281251t1a6862c4r1bf21b6502b3790a@mail.gmail.com> References: <44C97845.7000800@knox.net.nz> <8278b1b0607281251t1a6862c4r1bf21b6502b3790a@mail.gmail.com> Message-ID: <44CA8958.2070305@cora.nwra.com> Neal Gompa wrote: > HelixPlayer messes with downloading RPMs, and it tries to play them, I'm > hoping that it is fixed so that *.rpm isn't considered a RealMedia thing > since RealMedia doesn't use that extension anymore... I think.... I thought this was being done on the webserver side, returning a mime type of x-application/realplayer or some such. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Fri Jul 28 22:02:46 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 28 Jul 2006 16:02:46 -0600 Subject: Need help with python noarch package In-Reply-To: <1153865076.2769.525.camel@localhost.localdomain> References: <44C652C3.4090600@cora.nwra.com> <1153865076.2769.525.camel@localhost.localdomain> Message-ID: <44CA8986.2010703@cora.nwra.com> Ville Skytt? wrote: > If the stuff is really noarch, one probably wants to add plat_specific=0 > to the arguments to get_python_lib(). On the other hand, it could be > better off defined just as: > > PYTHONLIB = get_python_lib(prefix='') > Thanks Ville! Submitted upstream... -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From sundaram at fedoraproject.org Fri Jul 28 22:08:55 2006 From: sundaram at fedoraproject.org (Rahul) Date: Sat, 29 Jul 2006 03:38:55 +0530 Subject: HelixPlayer In-Reply-To: <44CA8958.2070305@cora.nwra.com> References: <44C97845.7000800@knox.net.nz> <8278b1b0607281251t1a6862c4r1bf21b6502b3790a@mail.gmail.com> <44CA8958.2070305@cora.nwra.com> Message-ID: <44CA8AF7.40007@fedoraproject.org> Orion Poplawski wrote: > Neal Gompa wrote: >> HelixPlayer messes with downloading RPMs, and it tries to play them, I'm >> hoping that it is fixed so that *.rpm isn't considered a RealMedia thing >> since RealMedia doesn't use that extension anymore... I think.... > > I thought this was being done on the webserver side, returning a mime > type of x-application/realplayer or some such. Yes. Its the server side setup thats not appropriately done but there is almost zero chances of .rpm files being Real media ones and we can make things work better by not associating Helix Player (or Real Player for that matter) with the extension at all regardless of the mimetype. Rahul From bugs.michael at gmx.net Fri Jul 28 22:13:52 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 29 Jul 2006 00:13:52 +0200 Subject: Future FESCo Elections In-Reply-To: <44CA72ED.4000106@leemhuis.info> References: <1153768355.3209.48.camel@localhost> <200607271540.k6RFeaWs006558@ludwig-alpha.unil.ch> <20060727230001.0cfd7e05.bugs.michael@gmx.net> <44CA72ED.4000106@leemhuis.info> Message-ID: <20060729001352.e1c75efe.bugs.michael@gmx.net> On Fri, 28 Jul 2006 22:26:21 +0200, Thorsten Leemhuis wrote: > > Why don't you come up with explanations on how FESCo works and what we > > need FESCo for? > > Why don't you come up with explanations? You were in FESCo for long, you > know Fedora Extras in deep and how things work. Simply because I haven't found out the answers to the questions. ;) Maybe if I had hung out on IRC for a long time, maybe then I would have collected better information on "who does what?" and other questions everybody in FESCo should be interested in. A few more examples: "Kicking" build servers: It has never been clear to me who besides Dan Williams (dcbw) has special access to the build server master and clients and where reporting about temporary problems would be preferred. Recently, OTRS has been mentioned multiple times (and even suggested by a FESCo/FPB member) without information on who exactly can be reached there. Why do we need to guess? Why the confusion? Somebody at fedora.us once wrote something like "I felt like a 5 year old boy at X-mas when I read that -- when has that been decided?", referring to lack of communication between decision makers and contributors. And indeed, I am reminded of that whenever I see something relevant and think "why hasn't this been announced anywhere?" and "am I expected to monitor many more mailing-lists to stay informed about things that affect us?". Packages dropped from FC: There are package inter-dependencies between Extras and Core. Still it happens that communication about removal of packages from Core is sparse or non-existant. Same applies to ABI/API upgrades. We do have fedora-maintainers list. Post short warnings there, please. FE roadmap: FC6 comes nearer. But while on fedora-maintainers list there are topics about Core mass rebuilds, there is silence (or hard to find information?) about how/when to bring Extras in shape. The Schedule page contains a tiny comment, vague plans. Talking about quorum: Whenever I attended a FESCO meeting on IRC, there were only half of the members present or less thereof. And whenever I didn't find the time, there were also only at most half of the members present. Apart from such examples, FESCo's mailing list appeared to me like /dev/null [1] several times as well as /dev/zero (whenever input has come in from unknown sources - IRC? - and entered the Schedule page without notice, so at the beginning of a meeting I learned about topics I haven't seen before). I didn't know whether I was expected to monitor the Wiki page instead of proper communication on-list. [1] e.g. "Subject: ExcludeArch for noarch (was: Re: nx requires and provides)" and if somebody with the proper privileges could visit "Subject: [PATCH] Re: cvs-import.sh fails to resurrect dead branches" thanks in advance. From mmcgrath at fedoraproject.org Fri Jul 28 22:18:52 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 28 Jul 2006 17:18:52 -0500 Subject: [Fedora-infrastructure-list] Re: when to use OTRS (Was: Re: FESCo, hello? - [was: Re: Buildsys status pages down]) In-Reply-To: <1154122716.3951.39.camel@cutter> References: <44C8F9BA.3050101@cora.nwra.com> <20060728220925.c65be643.bugs.michael@gmx.net> <44CA7498.4020609@leemhuis.info> <1154122716.3951.39.camel@cutter> Message-ID: <3237e4410607281518g39de414csc0feb57001f7a29f@mail.gmail.com> On 7/28/06, seth vidal wrote: > > afaik that was all that was wrong. > > sorry for not saying more earlier - been a busy day at work. > > -sv The http://buildsys.fedoraproject.org/build-status/index.psp site is showing expired certs too :-D -Mike From michael at knox.net.nz Fri Jul 28 22:23:50 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 29 Jul 2006 10:23:50 +1200 Subject: HelixPlayer In-Reply-To: References: <44C97845.7000800@knox.net.nz> Message-ID: <44CA8E76.9030700@knox.net.nz> Rex Dieter wrote: > Michael J. Knox wrote: > >> So, HelixPlayer has been axed form Core. > ... >> Has anyone offered to pick it up? > > not yet. > >>> Or can amarok live without it? > > Sorta kinda, it has hacked-in gstreamer support (atm). This support should > get better/official over time. > Do we want to see HelixPlayer maintained until the amarok gst support is ready for human consumption? Michael From tibbs at math.uh.edu Fri Jul 28 22:37:18 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 28 Jul 2006 17:37:18 -0500 Subject: FESCo, hello? - In-Reply-To: <20060728223933.6561c73a.bugs.michael@gmx.net> (Michael Schwendt's message of "Fri, 28 Jul 2006 22:39:33 +0200") References: <44C8F9BA.3050101@cora.nwra.com> <20060728220925.c65be643.bugs.michael@gmx.net> <20060728223933.6561c73a.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Trial-and-error guess-work is NOT common sense. Indeed it isn't. Of course, I never mentioned trial-and-error guesswork. MS> Fact is, I (and many others) simply do not know which of the two MS> systems to use. Some point to OTRS, some to bugzilla. And that's unfortunate; I don't know any of the answers and I apologize for making any suggestions. - J< From nman64 at n-man.com Sat Jul 29 06:39:42 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sat, 29 Jul 2006 01:39:42 -0500 Subject: HelixPlayer In-Reply-To: <44CA8E76.9030700@knox.net.nz> References: <44C97845.7000800@knox.net.nz> <44CA8E76.9030700@knox.net.nz> Message-ID: <200607290139.45198.nman64@n-man.com> On Friday 28 July 2006 17:23, "Michael J. Knox" wrote: > Rex Dieter wrote: > > Michael J. Knox wrote: > >> So, HelixPlayer has been axed form Core. > > > > ... > > > >> Has anyone offered to pick it up? > > > > not yet. > > > >>> Or can amarok live without it? > > > > Sorta kinda, it has hacked-in gstreamer support (atm). This support > > should get better/official over time. > > Do we want to see HelixPlayer maintained until the amarok gst support is > ready for human consumption? > If you're willing to maintain it, I'm sure some people will use it. I wouldn't imagine it would be too hard to maintain, and perhaps you could tackle some of the most common complaints against it. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nman64 at n-man.com Sat Jul 29 06:56:49 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sat, 29 Jul 2006 01:56:49 -0500 Subject: Fedora Ticket System (OTRS) Message-ID: <200607290156.52408.nman64@n-man.com> I've seen questions pop up about the Fedora Ticket System in a few threads recently, so here's some basic information relevant to Fedora Extras. == When to use the Ticket System == Any issue that requires direct work on Fedora's infrastructure should be reported using the Ticket System. This would include frozen or failing build systems. Any issues within packages should be reported using Bugzilla. This would include typical build errors. Any questions about policy or processes should be reported to this mailing list. This would include questions of spec design, naming conventions or review concerns. If ever you are unsure about which system to use, feel free to report to whichever seems best. Your report can be redirected as needed. == How to use the Ticket System == The Ticket System is configured to pick up authentication details from the Fedora Account System, so your username and password should match your regular Fedora account. The ticket system features assorted queues, and some of them allow tickets to be created through email. New tickets can be opened through the web interface for any queue. The "Buildsys" queue should be used for reporting issues with the Fedora Extras builders. This queue does not currently allow new tickets to be created by email, so new issues must be reported using the web interface. Once a ticket has been created, further action on the ticket can be carried out through the web interface or by email. If you have problems with the Ticket System, report them to admin at fedoraproject.org or through the Ticket System itself. Open tickets online: https://admin.fedoraproject.org/tickets/customer.pl -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michael at knox.net.nz Sat Jul 29 07:03:01 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sat, 29 Jul 2006 19:03:01 +1200 Subject: HelixPlayer In-Reply-To: <200607290139.45198.nman64@n-man.com> References: <44C97845.7000800@knox.net.nz> <44CA8E76.9030700@knox.net.nz> <200607290139.45198.nman64@n-man.com> Message-ID: <44CB0825.1030209@knox.net.nz> Patrick W. Barnes wrote: > On Friday 28 July 2006 17:23, "Michael J. Knox" wrote: >> Rex Dieter wrote: >>> Michael J. Knox wrote: >>>> So, HelixPlayer has been axed form Core. >>> ... >>> >>>> Has anyone offered to pick it up? >>> not yet. >>> >>>>> Or can amarok live without it? >>> Sorta kinda, it has hacked-in gstreamer support (atm). This support >>> should get better/official over time. >> Do we want to see HelixPlayer maintained until the amarok gst support is >> ready for human consumption? >> > > If you're willing to maintain it, I'm sure some people will use it. I > wouldn't imagine it would be too hard to maintain, and perhaps you could > tackle some of the most common complaints against it. Well, I will be happy to take it on. Will prep up a review for it. Michael From toshio at tiki-lounge.com Sat Jul 29 07:11:17 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 29 Jul 2006 00:11:17 -0700 Subject: FESCo Meeting Minutes 2006-07-27 Message-ID: <1154157077.4720.6.camel@localhost> 2006 July, 27 FESCo Meeting =========================== Meeting Summaries are posted on the wiki at: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings Attending --------- * thl * c4chris * dgilmore * bpepple * scop * rdieter * warren * tibbs * abadger1999 * jeremy Summary ------- * Mass Rebuild is waiting to reinstall the builders with FC5 and the minimal buildroot this weekend (Infrastructure will have someone at the colo in case of problems next week.) - Still on schedule to rebuild for FC5T3. * Control-C problem still occuring. - Let infrastructure have another go at finding a solution - Otherwise try an async notification method to make it work * Co-maintainership: thl will send an email this week to start discussion. * Packaging Committee Report: - PHP Guidelines at:: http://www.fedoraproject.org/wiki/PackagingDrafts/PHP were approved with the caveat that the macros mentioned in the draft don't exist in FC5 or less (so they can only apply to FC6). - http://www.fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets was ratified. * mjk- was accepted as a sponsor. * comps update: - Pushing comps automatically is good. Core does this right now. - The script that generates the comps needs to validate the xml and check that the packages are already in the repository. - Mailing list discussion of comps files:: https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00956.html https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01029.html * Elections: - An email soliciting comments went out but didn't gather many comments. - Toshio will take the few comments and make a solid proposal that people can decide what they like about it. * Stalled reviews: tibbs is going to write up a proposal and send to the list regarding how long a review should wait for more input from either submitter or reviewer before someone else can take over/bug closed. * Bugzilla enhancements - Branching: warren proposes either using blocker bugs or bugzilla flags to indicate a package that has been reviewed should be branched for other releases. This would be better than the CVSSync needed that currently exists. Consensus built up that blocker bugs had several features that made them better than flags. - warren will get a nobody at fedoraproject.org mail alias that can be used for unassigned package reviews and tasks that no one is working on. - tibbs requested having an UNASSIGNED bugzilla state that we could move review bugs to once they were already in another state (right now our unassigned state is NEW which cannot be assigned to.) Log --- :: (09:59:55) thl: k, my clock says it's time for the meeting (10:00:05) ***c4chris is here (10:00:08) thl has changed the topic to: FESCo meeting in progress (10:00:13) ***dgilmore is here (10:00:14) thl: who's around? (10:00:17) ***bpepple is here. (10:00:17) nirik: jcollie[work]: any chance for asterisk 1.2.10 and zaptel 1.2.7 updates? I guess you might wait and see if the kmod gets approved first tho (10:00:21) thl: packaging comitee finished? (10:00:24) ***scop is here (10:00:25) ***rdieter is here (10:00:30) ***cweyl is here (rabble) (10:00:38) ***nirik goes and sits in the rabble seats. (10:00:39) ***warren here (10:00:54) jcollie[work]: nirik, yeah i have asterisk 1.2.10 packaged already and on my web site, i just haven't updated bugzilla (10:00:55) tibbs: Packaging committee is done at this point. (10:01:39) c4chris: abadger1999, you around? (10:01:43) thl has changed the topic to: FESCo meeting in progress -- M[ae]ss-Rebuild (10:01:48) thl: dgilmore, status? (10:01:50) abadger1999: Yep. I'm here. (10:02:02) c4chris: cool (10:02:18) dgilmore: thl: we need to rebuild the builders (10:02:32) c4chris: huh? (10:02:34) dgilmore: the hammers we dont have acces to the bios via serial cable (10:03:02) che [n=che] entered the room. (10:03:10) dgilmore: i think im going to attempt upgrades using grup to boot installer this weekend (10:03:13) thl: dgilmore, who do we need to ask to make that happen? (10:03:21) thl: ahh, okay (10:03:30) dgilmore: if it messes up some how there will be someone onsite next week to fix them (10:03:46) warren: dgilmore, I'll assist (10:03:47) dgilmore: we need to setup netboot for the ppc builders (10:03:49) thl: dgilmore, just out of interest: does that mean that we update the builders to mock one at a time? (10:04:05) thl: dgilmore, e.g. some pacakges get build with the reduced set of default packages (10:04:11) thl: and some others with the old set? (10:04:14) dgilmore: thl: it means ill upgrade the os from fc3 to fc5 one at a time for the hammers (10:04:24) ***nirik wonders if it was decided to go with RHEL or CentOS or fc5 on the builders? (10:04:26) dgilmore: thl: yeah (10:04:35) warren: dgilmore, RHEL4 is unsuitable for builders? (10:04:39) tibbs: It's all fun and games until someone has to drive to the colo at 3AM. (10:04:49) jima: tibbs: ugh, don't remind me. (10:04:55) warren: tibbs, there is a scheduled visit next week (10:04:56) dgilmore: warren: we can use a slightly newer yum with fc5 (10:05:01) warren: dgilmore, ah (10:05:08) scop: RHEL4's rpm is too old -- affects "make srpm" (10:05:12) dgilmore: no one spoke up to my postings saying i was going to install fc5 on the builders (10:05:18) warren: FC5 is fine (10:05:34) warren: upgrading that into RHEL5 should also be safe later (10:05:35) rdieter: then at least, we're eating our own dog food. (: (10:05:49) f13: scop: erm. (10:05:54) dgilmore: scop: rhel's rpm needs patched so that we can build more than one chroot at a time also (10:05:54) f13: scop: whats too old about it? (10:06:19) scop: f13, breaks for example with new valid constructs like %bcond_with (10:06:27) f13: hrm. (10:06:34) f13: Red Hat's buildsystems are RHEL4 based. (10:06:43) scop: but that's really not RHEL's fault (10:06:50) f13: so COre packages are getting srpm built w/ a slightly updated RHEL4 rpm (10:06:58) scop: it's a fundamental problem in the buildsys (10:07:18) nirik: plague vs brew diffrences to? (10:07:20) scop: make srpm should be run in the target distro config (10:07:28) f13: %bcond_with makes a difference when building the intial srpm ? (10:07:45) scop: f13, yes, rhel4's rpmbuild chokes on it (10:08:03) scop: while parsing the specfile (10:08:08) f13: in Brew land, if passed a CVS url we make an srpm outside the buildroot, pass that srpm into the buildroot and remake the srpm (10:08:19) f13: perhaps we shouldn't allow that construct for now. (10:08:30) dgilmore: so all 6 builders will get upgraded to fc5 and will have mock 0.6 and plague 0.4 (10:08:40) dgilmore: they will be done one at a time (10:08:53) warren: http://buildsys.fedoraproject.org/build-status/index.psp (10:08:57) warren: is this error message known? (10:09:03) dgilmore: if one of the hammers gets messed up it will be out of commision until next week (10:09:10) slack_ [n=slack] entered the room. (10:09:23) rdieter: warren: it's been reported already (this morning) at least. (10:09:27) scop: f13, no need to specifically rule it out IMO; if it doesn't work, the packages just won't build (10:09:28) dgilmore: warren: the cert for the web client must have expired (10:09:56) jima: yeah, someone needs to download a new client certificate for the web front-end (10:10:00) jima: (i think) (10:10:11) warren: hmmm (10:10:28) thl: warren, somebody should file a ticket it the otrs system (10:10:31) f13: scop: this could be an ongoing problem though. mock doesn't take CVS urls, it takes an srpm, so the srpm has to be generated via CVS somewhere before being handed to mock. (10:10:41) rdieter: thl: tickets' been filed already. (10:10:46) thl: rdieter, k (10:10:51) thl: then let's move on (10:10:52) scop: f13, yep (10:11:06) thl: anything else we need to discuss now regarding mass rebuild? (10:11:15) warren: If you're interested in the details of buildsys reinstalls, attend the infrastructure meeting later today. (10:11:16) thl: shall we start earlier then FC6T3? (10:11:19) scop: schedule? (10:11:41) thl: f13, current state of libtool/binutils/gcc stuff? (10:11:47) dgilmore: thl: I really hope that everything is in place for start of next week (10:11:50) f13: toolset is looking good (10:12:02) f13: there was a large backport to gcc for java stuff. (10:12:12) warren: http://fedoraproject.org/wiki/Core/Schedule (10:12:14) f13: and a lot of java packages were rebuilt (again) (10:12:17) thl: k, then let's see how FC6T2 works out when released (10:12:19) warren: schedule hasn't been updated for our latest delays (10:12:26) thl: and start soon when everything looks fine (10:12:29) f13: warren: because we don't knwo what to update it too (10:12:31) thl: that okay for everybody? (10:12:37) warren: f13, nod (10:12:39) f13: OUTLOOK HAZY, TRY AGAIN LATER (10:12:57) c4chris: thl, k (10:12:58) scop: thl, why not stick with the T3 plan? (10:13:10) thl: scop, more time for maintainers to rebuild stuff? (10:13:10) warren: I think T3 is a good plan (10:13:20) dgilmore: i do have one thing the macros scop wanted added to check the buildroot if we pull rpmdevtools we add 2 deps wget and rpm-python does anyone object? (10:13:22) thl: scop, more time to find orphans and AWOL maintainers? (10:13:46) thl: scop, but let's wait for FC6T2 (10:13:57) thl: we can decide then when and how to proceed (10:13:57) scop: thl, larger window for "something" to happen which requires another mass rebuild? ;) (10:14:08) thl: scop, yeah, possible ;) (10:14:16) warren: dgilmore, I think those two are fine. (10:14:24) thl: well, let's move on now (10:14:37) dgilmore: warren: i do too. (10:14:39) thl has changed the topic to: FESCo meeting in progress -- CTRL-C problem (10:14:47) thl: scop, ? (10:15:00) scop: regarding Ctrl-C? no news (10:15:39) tibbs: I think this is going to end up unfixed until we get a new SCM. (10:15:50) warren: *or* mail sending should be handled async (10:16:04) abadger1999: warren: I think async is the way to go. (10:16:05) thl: tibbs, we should at least try once more to get it fixed (10:16:25) thl: warren, abadger1999, can you poke the infrastructure guys again? (10:16:30) warren: thl, yup (10:16:33) drpixel [n=drpixel] entered the room. (10:16:36) thl: warren, k, thx (10:16:43) tibbs: thl: You're right, of course, but I think it's a lack of time among those with access. (10:16:50) thl has changed the topic to: FESCo meeting in progress -- Co-maintainership (10:17:03) thl: I hope to send a mail to the list this weekend (10:17:09) abadger1999: Sopwith is going on an extended vacation though, we'll have to get someone new to pick up where he left off. (10:17:11) thl: so I'll moving on now (10:17:21) thl has changed the topic to: FESCo meeting in progress -- IPv6 Support in Extras (10:17:30) thl: skipping as well -- jwb still on vacation (10:17:39) thl has changed the topic to: FESCo meeting in progress -- Packaging Committee Report (10:17:48) thl: scop ? (10:17:55) tibbs: spot is away at the moment. (10:18:11) scop: not very productive packaging meeting today (10:18:11) tibbs: We took up two issues: (10:18:20) scop: tibbs, go ahead ;) (10:18:31) tibbs: sorry, I get spot and scop mixed up for some reason. (10:18:59) tibbs: We voted on PHP guidelines and agreed on the current draft. (10:19:15) tibbs: http://fedoraproject.org/wiki/PackagingDrafts/PHP (10:19:43) tibbs: So it's passed to FESCo and FAB for ratification. (10:20:20) scop: open issue: macros specified in the draft do not exist yet in FC5 (10:20:38) warren: I don't know much about PHP, but I trust the judgement of the package committee members, so +1. (10:21:02) c4chris: Is the %build section required ? (10:21:12) ***thl didn't ready the PHP stuff yet, but trusts the package committee members, too, so +1 as well (10:21:15) tibbs: Yes, the macros are currently in updates-testing. The draft will get some info about targeting releases that don't have the necessary macros so that FC4 and RHEL don't get left out. (10:21:30) dgilmore: +1 also (10:22:10) thl: tibbs, scop, anything else? (10:22:11) tibbs: c4chris: The guidelines don't cover the necessity of a %build section. (Nor did they ever.) (10:22:14) c4chris: Is the "php >= current" resolved ? (10:22:19) abadger1999: c4chris: %build is not mentioned yay or nay in the Draft (10:22:35) tibbs: We also took up the issue of the ScriptletSnippets page. (10:22:51) thl: tibbs, scop, btw I think we don't need to vote here on things the package committee decided (10:22:55) scop: %build is not at all specific to PHP (10:22:56) c4chris: tibbs, abadger1999: k, no biggie, just curious (10:23:11) thl: I think you guys should announce here what happened (10:23:16) c4chris: scop, right (10:23:19) tibbs: Which was accepted as a guideline; the TODO bits have been removed and the guideline will be further revised to flesh it out a bit. (10:23:30) thl: and as long as no one yells in the next 7 days they are approved by fesco (10:23:34) thl: that okay for everybody? (10:23:38) bpepple: thl: +1 (10:23:38) scop: right (10:23:48) c4chris: thl, +1 (10:24:01) abadger1999: thl: +1 (10:24:04) cweyl: thl: and if someone yells, then ratification is formally taken up at the next fesco meeting? (10:24:24) scop: there's no process for that ;) (10:24:32) thl: cweyl, yes, that how it should work IMHO (10:24:38) warren: who is "someone"? (10:24:40) cweyl: scop: now there is ;) (10:24:42) warren: *anybody* out there? (10:24:47) warren: or a cvsextras member? (10:24:47) thl: warren, someone from FESCo (10:24:48) warren: oh (10:24:49) scop: cweyl, but it doesn't work :) (10:24:57) cweyl: scop: why not? (10:25:02) thl: warren, eyerbody can yell on fedora-packaging in any case (10:25:05) scop: because fesco is not the only interest group (10:25:07) thl: if he wants to (10:25:32) cweyl: scop: right. but just because others have interest too doesn't diminish fesco's interest (10:26:08) c4chris: what was the second issue? (10:26:09) thl: scop, so what do you suggest? (10:26:14) scop: cweyl, right, but if someone from fedora advisory board or rh(el) engineering yells, there's no point even trying to take that up in fesco (10:26:36) rdieter: c4chris: ScriptletSnippets (10:26:43) tibbs: The second issue was the ratification of ScriptletSnippets as a guideline. (10:27:03) cweyl: scop: right, but that's not what I was suggesting :) if someone on fesco sees a reason to discuss it, then fesco should... right? other people have other orgs to yell at :) (10:27:04) c4chris: oh right (10:27:10) ***thl will be afk for some minutes in round about 5-10 minutes from now (10:27:55) dgilmore: tibbs: some of the current scriptlets are wrong (10:28:07) scop: well, shrug (10:28:17) dgilmore: namely they are ok for gnopme gtk apps but wrong for kde ones (10:28:27) tibbs: dgilmore: Please do provide details. (10:28:49) scop: I think resolving the results of potential yelling is the job of the fedora board (10:29:05) thl: dgilmore, please bring that to fedora-packaging-list (10:29:11) rdieter: dgilmore: they're not wrong, just useless extra work. (: (10:29:14) thl: otherwise we'll run out of time here (10:29:21) dgilmore: rdieter: yeah (10:29:32) scop: (plus a dependency on gtk2?) (10:29:34) thl: scop, only where there are realy problems that can't get solved by a normal discussion (10:29:39) abadger1999: c4chris, tibbs: Hmm... versioned php was not resolved. (Left open in the guideline. Probably need to resolve that in the next packaging meeting.) (10:29:47) thl: I don#t think such "real problems" will show up to often (10:29:48) rdieter: scop: yep. (: (10:30:31) tibbs: That is pretty much it for the packaging committee. (10:30:53) thl: Do we want to discuss this further now or simply move on for today and discuss and find a solution on the lists (or in the next meeting)? (10:31:04) rdieter: scop: I take that back (no deps are added now) (10:31:13) dgilmore: thl: move on (10:31:19) rdieter: thl: move on, lists... (10:31:23) dgilmore: tibbs: ill ping you about it latter (10:31:33) thl has changed the topic to: FESCo meeting in progress -- Weekly sponsorship nomination (10:31:43) thl: mjk- was nominated (10:31:46) warren: +1 (10:31:48) bpepple: +1 (10:31:51) tibbs: +1 (10:31:52) c4chris: +1 (10:31:52) scop: +1 (10:31:52) thl: sevewral sponsors voted +1 (10:31:53) rdieter: +1 (10:32:03) abadger1999: abadger1999: Already voted +1 on cvsextras (10:32:03) thl: there are a lot of +1 here, too :) (10:32:10) warren: OK, so done. (10:32:15) thl: so mjk- is accepted (10:32:29) thl: any other nominations we want to discuss now? (10:32:34) jima: man, progress here is _slow_. ;) (10:32:55) c4chris: I think Nodoid is also candidate (10:33:17) c4chris: (if I got the IRC nick right) (10:33:29) thl: well, I agree with what was discussed on the lists (10:33:36) warren: I think Nodoid's intentions are in the right place, but his first review was not too long ago, and this is a little premature. (10:33:44) thl: we'd like to see some more work for him before we make him a sponsor (10:33:46) bpepple: warren: +1 (10:34:01) ***thl afk now (10:34:07) abadger1999: warren: +1 (10:34:19) thl: can you guys please at least discuss comps and elections? (10:34:23) warren: ok (10:34:31) dgilmore: +1 (10:34:31) thl: warren, can you take care of the meeting from now on? (10:34:42) thl: I'll skim in now and then (10:34:44) warren: Let's re-evaluate this candidate again in a few weeks after more review examples. (10:34:53) c4chris: warren, k (10:35:12) bpepple: sounds good. (10:35:25) warren: what did he mean by comps? (10:35:40) warren: http://fedoraproject.org/wiki/Extras/Schedule unclear based on our agenda (10:35:53) c4chris: we need some guidelines what to put in comps.xml (10:36:02) c4chris: all packages ? (10:36:10) warren: scop, would it be appropriate to discuss kmod approval now, or we don't have enough people? (10:36:11) tibbs has changed the topic to: FESCo meeting in progress -- Comps (10:36:12) _wart_: ...and automate the pushing of the comps files (10:36:15) c4chris: all sub-packages ? (10:36:41) bpepple: c4chris: Is there anything on the wiki about the comps.xml? (10:36:43) scop: warren, I'm not quite up to date what's queued and ready for discussion (10:36:48) warren: why is comps not listed here? I don't know the full context of this problem. (10:36:52) warren: scop, ok, next week then? (10:36:57) scop: warren, works4me (10:37:00) c4chris: bpepple, well, that's the problem: I don't think so... (10:37:03) dgilmore: warren: currenlt its manually updated (10:37:18) abadger1999: _wart_: Did you get any work done with comps this week? (10:37:19) tibbs: Can we agree that it should be automated if possible? (10:37:21) dgilmore: we want to set something up so that it gets pushed automatially when its updated (10:37:25) warren: dgilmore, that's how Core comps is done too. (10:37:32) warren: oh (10:37:33) warren: hm (10:37:55) _wart_: abadger1999: I talked with jkatz about the process of generating the comps file. (10:38:14) warren: Core comps is updated manually, then put through the script to expand with all translations, and that is used to build trees and put in repodata. (10:38:23) _wart_: It's pretty straightforward, but I still need to figure out the best way to tie it into the push script (10:38:43) warren: We also need to be sure that the automated process validates it, so it does'nt break stuff. (10:38:48) dgilmore: we were thinking either a cron job that checks daily or hourly and updates if need be or add it to the push process if needed but would rather do it seperate so as to not extend the time taken to do a push (10:39:02) scop: _wart_, ping me if you need opinions or help, I know the scripts pretty well (10:39:04) _wart_: warren: Right. we can use xmlwf to validate it. (10:39:21) _wart_: scop: Will do, probably in the next couple of days. (10:39:24) spot [n=spot] entered the room. (10:39:25) warren: Does it need to be in the push script? (10:39:37) dgilmore: warren: i think its better not (10:39:41) warren: can it be async, and send out e-mail if validation fails? (10:39:46) warren: better async, I think. (10:39:50) dgilmore: just so that it doesnt extend push window (10:39:52) scop: well, personally I would love it if repoview and comps and stuff like that would be run completely outside of the scripts (10:40:19) warren: If possible we should keep things outside of the push script that would slow it down, especially if it can be done async. (10:40:31) scop: but I suppose comps is a matter of seconds so that's a non-issue (10:40:33) _wart_: The comps file generation takes seconds to finish. (10:40:35) tibbs: Do we know what should go into comps? SRPM name or list out all of the subpackages? (10:40:35) dgilmore: scop: we could quite easily do that have a say 6 hourly cron job that does a check for update if there is it runs if not its done (10:40:50) abadger1999: bpepple, c4chris: comps discussion from mailing lists (Put this on the wiki?): (10:40:50) abadger1999: https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00956.html (10:40:50) abadger1999: https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01029.html (10:40:55) scop: dgilmore, yes, and we're already doing that in other projects (10:41:15) tibbs: Is there a possibility that comps would be updated before the packages have been pushed? If so, what breaks when that happens? (10:41:16) scop: (that == repoview there) (10:41:16) _wart_: Or we could try to tie it into a cvs commit script to validate and generate the comps files. (10:41:35) dgilmore: it just might mean that packages are not in repodata for a few hours after a package push (10:41:51) scop: dgilmore, s/repodata/repoview/ (10:42:05) dgilmore: scop: yah (10:42:25) c4chris: abadger1999, yes, that'd be a start... (10:42:26) scop: but it could be cron'd every 10 minutes (10:42:31) tibbs: Won't that break installations, if you select a group where a package is not available? I recall a time when that was the case. (10:42:42) scop: it takes seconds to determine if rebuilding it is needed or not (10:43:58) dgilmore: tibbs: a package will always be available (10:44:48) dgilmore: tibbs: my bad maybe not always (10:45:31) tibbs: dgilmore: I build a new package and add it to comps. Comps gets updated by cron but the package push doesn't happen for another 12 hours. What does the installer do? (10:45:58) devrimgunduz left the room (quit: "Leaving"). (10:45:59) dgilmore: but we could put a check in the scipt that checks the time of the comps compared to the repodata if comps is newer then we dont rebuild (10:46:27) tibbs: At that point we might as well just do it as part of the push. (10:46:46) _wart_: tibbs: +1, especially since it's a pretty quick process anyway (10:47:15) _wart_: The push script could avoid generating the comps file if any validation tests fail on it. (10:47:22) abadger1999: tibbs: Won't we still have possible race conditions? (10:47:25) _wart_: and email a notice to (10:47:35) abadger1999: I submit the build and update comps at the same time. (10:48:07) abadger1999: Build fails or push is made before the job completes? (10:48:32) ***Sopwith returns. (10:48:36) xris [n=xris] entered the room. (10:49:07) tibbs: abadger1999: In that case, I could just typo something in comps. (10:49:19) tibbs: So the real question is, what breaks when this happens? (10:49:37) dgilmore: so the scipt should check the additions and see if its in the tree (10:49:39) tibbs: I think we need to talk to the installer people. And the yum devs. (10:49:44) scop: how about just generating comps.xml from the Group tags of packages being pushed? ;) (10:49:44) dgilmore: if not no comps built (10:49:56) abadger1999: dgilmore: Yep. (10:49:57) c4chris: scop, argh :) (10:50:12) skvidal: tibbs: talk to us about what? (10:50:15) abadger1999: scop: Been proposed before! :-) (10:50:24) dgilmore: scop: cause a package could be in more than one group in comps (10:50:41) dgilmore: but only has one group in spec (10:50:45) scop: (in case everyone didn't notice, the smiley was there for a reason) (10:51:15) dgilmore: bbs need lunch (10:51:39) tibbs: skvidal: Does yum care if comps lists packages that don't exist? (10:51:54) skvidal: no, it doesn't (10:52:31) tibbs: So that leaves the installer. (10:52:39) _wart_: tibbs: In fact, for a while there were several packages in comps that didn't exist. (10:52:59) scop: hm (10:53:13) scop: "the installer"? (10:53:21) scop: anaconda handles FE too? (10:53:31) tibbs: In FC6 it does. (10:53:37) scop: woo (10:53:41) c4chris: Jeremy Katz said: "the primary use is with a GUI, selecting a lot of text-mode things make little sense." (10:53:55) c4chris: is this still true? (10:54:07) ***thl back for some minutes (10:54:14) c4chris: or is comps.xml used for more things now? (10:54:39) thl: warren, sorry, comps was not really on the schedule yet but I knew at least someone (tibbs?) wanted to talk abouti t (10:54:48) thl: and it should be on the schedule (10:54:55) jeremy: yes, it's still true (I'm halfway here, see!) (10:54:59) thl: or was it c4chris? well, not important (10:55:03) tibbs: thl: 't wasn't me. (10:55:12) c4chris: 'was me :) (10:55:27) tibbs: The games SIG for one tries to keep comps updated. (10:55:40) thl: a lot of people ignore it (10:55:51) thl: I for example never touched it (10:55:53) ***thl hides (10:55:55) tibbs: We want people to be able to install the Games group and have loads of games pop in. (10:56:22) c4chris: ok, but what's the plan for the future? (10:56:24) ***nirik has used it for 'groupinstall XFCE' (10:56:34) thl: c4chris, someone should probably work out a plan (10:56:37) cweyl: yeah, the groupinstall bit is nice (10:56:46) thl: c4chris, can you handle that? (10:56:54) thl: c4chris, dgilmore probably will help with the scripts (10:57:02) c4chris: my understanding was that the Group tag should be deprecated (10:57:19) skvidal: s/deprecated/obliterated/ (10:57:24) c4chris: and that we put all bits that people *want* to install in comps somewhere (10:57:39) tibbs: No argument here. (10:57:44) thl: c4chris, I though all packages must be in comps for anaconda/pirut? (10:57:45) c4chris: preferably in well thought out groups (10:58:11) c4chris: thl, that's teh part I don't know and am trying to find info about... (10:58:27) thl: jeremy, f13 ? (10:58:39) thl: do all packages need to be in comps now? (10:58:39) tibbs: Yes, I recall hearing that you couldn't install something from anaconda unless the package shows up in comps or you're using a kickstart file. (10:58:53) Seg: The media production SIG is going to have to take on comps eventually. I'm waiting until we get more applications in personally. (10:58:55) jeremy: thl: not all packages... if it's a package that's "interesting" to be visible, then you want it in comps, yes (10:59:55) thl: jeremy, well, then probably nearly all extras packages need to be in comps (11:00:01) c4chris: jeremy, so in short: what people *want* must be in comps, all the deps need not (11:01:21) c4chris: tis going to be interesting to script a definition of "interesting" ... :) (11:01:40) thl: well, can sombody work out a rough plan until the next meeting? (11:01:42) thl: c4chris ? (11:01:54) c4chris: thl, k I'll work out something (11:02:08) thl: c4chris, tia (11:02:17) dgilmore: c4chris: ill give you a hand if you need it (11:02:19) thl: do we want to talk about the election? (11:02:24) thl: got late... (11:02:26) c4chris: dgilmore, k, thanks (11:02:29) jeremy: c4chris: right. and I don't think that comps can be scripts (11:02:31) thl: abadger1999, do you need further input? (11:02:33) jeremy: scripted (11:02:44) jeremy: thl: libraries don't need to be. -devel subpackages don't generally need to be (11:02:54) thl: jeremy, ahh, okay (11:02:56) abadger1999: Well, the mail went out. Not many comments. (11:03:25) abadger1999: Sopwith's comments about not over democracising things I think have merit. (11:03:43) c4chris: jeremy, I kinda agree, but I think some rough checks can be automated (11:03:46) abadger1999: But are balanced against needing to bring in new blood. (11:04:02) drpixel left the room (quit: Read error: 104 (Connection reset by peer)). (11:04:19) drpixel [n=drpixel] entered the room. (11:04:25) thl has changed the topic to: FESCo meeting in progress -- elections (11:04:41) abadger1999: Since there weren't many comments, I tend to think people aren't too concerned with the current direction. (11:04:46) c4chris: new blood is good, when it's found... (11:04:58) thl: abadger1999, you probably should work out a proposal and send it to the list (11:05:03) thl: if no one yells (11:05:10) thl: and if is seems okay for FESCo (11:05:13) thl: we'll go for it (11:05:29) thl: abadger1999, decide things just how you thing they should work (11:05:35) abadger1999: Yep. I'll take my questions from the email and just pretend I have answers :-) (11:05:41) thl: if there are things you don't want to decide mention them in the proposal (11:05:52) thl: abadger1999, great :-) (11:05:57) thl: k, moving on (11:06:03) warren: abadger1999, which email was this? (11:06:04) thl has changed the topic to: FESCo meeting in progress -- free discussions (11:06:15) thl: anything else that needs to be discussed? (11:06:15) tibbs: Did we want to talk about kernel modules? (11:06:18) abadger1999: Sent to fedora extras on Monday. Let me scan the archives. (11:06:37) thl: tibbs, no, I didn#t get any request for modules... (11:06:37) warren: tibbs, scop wanted to defer that for next week, he's behind on study. (11:06:40) abadger1999: warren: https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00769.html (11:06:43) tibbs: There was an update on the zaptel module. (11:07:09) thl: tibbs, k, I'll look at it and forward it to fesco list for discussions (11:07:19) tibbs: OK, then I'd like to discuss a policy for dealing with stalled reviews. (11:07:25) scop: I didn't *want* to defer it, but I don't have much to contribute to that right now (11:07:54) thl has changed the topic to: FESCo meeting in progress -- stalled reviews (tibbs) (11:08:03) tibbs: Note that I wasn't talking about packaging standards, just the usual voting on acceptability of particular kernel modules. (11:08:07) tibbs: About reviews. (11:08:27) tibbs: I was just thinking of a quick policy for how long to wait on stalled things. (11:08:47) tibbs: If the reviewer doesn't respond for N weeks, ping and after a week someone else can take over. (11:08:59) tibbs: If the submitter doesn't respond for N weeks, ping and after a week the bug gets closed. (11:09:03) tibbs: That kind of thing. (11:09:04) ***scop needs to go now, ttyl (11:09:14) c4chris: N=8 should be plenty (11:09:14) bpepple: Doesn't sound like a bad idea. (11:09:17) thl: tibbs, just work out a proposal and post to the list for discussion (11:09:27) thl: N=6 would be okay for me, too (11:09:35) tibbs: thl: that's the plan but I figured I'd get a soinding. (11:09:40) tibbs: sounding. (11:09:43) scop left the room ("Leaving"). (11:09:52) c4chris: good vibrations here :) (11:09:55) tibbs: I was thinking about N=4, personally. (11:10:04) thl: N=4 would be okay for me, too (11:10:14) c4chris: sure (11:10:19) tibbs: Honestly if I don't see a comment from a package submitter for a month, I'm not sure I want them maintaining packages. (11:10:27) tibbs: Unless they're on vacation, of course; that's reasonable. (11:10:49) abadger1999: Vacation of 1 month plus catching up on email afterwards... (11:10:56) thl: tibbs, sounds okay (11:10:59) tibbs: But it would still be nice if they indicated that they're going away. It's good practise for actually being a maintainer. (11:11:08) c4chris: abadger1999, wow I'd like that :) (11:11:12) tibbs: Anyway, I'll write something up and send it to extras-list for discussion. (11:11:17) thl: tibbs, tia (11:11:20) bpepple: abadger1999: Yeah, I agree since I just got back from a 3 week vacation. (11:11:35) abadger1999: c4chris: I'd like that too except for the email part ;-) (11:11:39) thl has changed the topic to: FESCo meeting in progress -- free discussion around extras (11:11:55) c4chris: precisely :) (11:11:58) thl: k, anything else? (11:11:59) warren: heh (11:12:18) warren: oh! (11:12:24) warren: I had an idea about CVS branching (11:12:28) warren: to streamline the system (11:12:41) dgilmore: bpepple: I had 3 weeks earlier this year (11:13:12) bpepple: dgilmore: Yeah, it's real hard to get caught up on all the activities that went on in FE while your gone. (11:13:27) warren: Basically, I think Bugzilla flags would be a better way of doing it. (11:13:44) thl: warren, yeah, sounds like a good idea (11:14:17) warren: It would be a field to change in the bugzilla form of the review itself (11:14:24) warren: and a query can show all branches that need doing (11:14:31) c4chris: warren, you mean: tick a few checkboxes when you close the accepted review request ? (11:14:40) tibbs: warren, FE-BRANCH-FC5 ? (11:14:45) warren: no, bugzilla flags (11:14:50) warren: oh (11:14:57) warren: I hadn't considered a blocker bug, that would work too (11:15:00) warren: hmm (11:15:04) warren: blocker bug might be better actually (11:15:27) cweyl: warren: everything else being equal, it's how we track just about everything else in BZ... (11:15:35) warren: anyway I'll analyze both options and post to extras list soon about it. (11:15:36) thl: FE-ACCEPT-BRANCHPLEASE ;-) (11:15:40) tibbs: It does have the bonus of not needing any changes to any infrastructure. (11:15:47) _wart_: Will the bugzilla-branch-request allow a developer to add these requests after the bug has been closed? (11:15:49) thl: warren, k, thx (11:16:00) _wart_: ie: Sometimes I don't want to request a new branch until after it's imported and built on devel. (11:16:02) warren: _wart_, good point (11:16:12) tibbs: But if we have the power to get new things into bugzilla, it would be nice to consider an UNASSIGNED state. (11:16:16) warren: blocker bug would allow that, flags would make it ambigous (11:16:18) warren: ambiguous (11:16:30) warren: Oh, another thought. (11:16:36) tibbs: You can add blockers to closed bugs no problems. And you get email notification for free. (11:16:42) warren: Mozilla Bugzilla has a nobody at mozilla.org (11:16:56) warren: if something is clearly orphaned and nobody is working on a problem, it is assigned there. (11:17:05) warren: I think that would be useful for us. (11:17:11) warren: for both Core and Extras (11:17:17) warren: hmm... probably best for FAB? (11:17:26) thl: reviews could be assigned to that users initially, too (11:17:36) thl: s/users/user/ (11:17:39) tibbs: I don't see why it doesn't just happen. (11:17:44) warren: more appropriate than the Thorsten blackhole =) (11:17:57) thl: warren, yes, really :-) (11:18:12) tibbs: The thl blackhole has done like 13 reviews. (11:18:18) warren: OK, should we just create a nobody at fedoraproject.org account? (11:18:22) thl: warren, +1 (11:18:26) warren: +1 (11:18:27) bpepple: warren: +1 (11:18:31) c4chris: warren, +1 (11:18:40) tibbs: +1 Please just do it. (11:18:47) abadger1999: +1 (11:18:51) warren: Who runs the MTA of fedoraproject.org? (11:19:04) thl: don't know -- skvidal ? (11:19:11) warren: I'll follow up on this (11:19:12) warren: k (11:19:15) warren: that's all (11:19:26) thl: k, then let's clode the meeting for today (11:19:31) thl: if no one objects (11:19:38) ***thl will close the meeting in 20 (11:19:46) drpixel left the room (quit: Read error: 104 (Connection reset by peer)). (11:19:48) ***thl will close the meeting in 10 (11:19:59) thl: -- MARK -- Meeting end (11:20:04) thl: thx everyone! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Sat Jul 29 09:41:47 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 29 Jul 2006 11:41:47 +0200 Subject: questions about comps files Message-ID: <20060729093041.GA2701@free.fr> Hello, Since it seems that that discussion should happen here, let's do it. I have the following questions about the comps files: * the 'Authoring and Publishing' seems to be only for docbook from the description. So where things like latex based packages, script converter for other formats and so on (in my case, there is BibTool, tetex-tex4ht and ooo2txt). And should script converters be in comps at all? * where should wxWidgets based applications go (I maintain xchm). * should what is an end-user be dependent on the category? For example I think that 'Engineering and Scientific' end users care about numerical libraries, so it makes sense to have some libraries often used in models or the like in that category. There is allready blas and lapack, for example. * does it makes sense to have some packages in more than one group? For example I put grads is in 'Graphics', I think it also could be in 'Engineering and Scientific'. * where should things like esmtp (a relay-only Mail Transfer Agent) go? There doesn't seems to be a category for that program, although it may be interesting for some (advanced) end-users? -- Pat From mattdm at mattdm.org Sat Jul 29 10:47:48 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 29 Jul 2006 06:47:48 -0400 Subject: questions about comps files In-Reply-To: <20060729093041.GA2701@free.fr> References: <20060729093041.GA2701@free.fr> Message-ID: <20060729104748.GA5399@jadzia.bu.edu> On Sat, Jul 29, 2006 at 11:41:47AM +0200, Patrice Dumas wrote: > * where should wxWidgets based applications go (I maintain xchm). The toolkit used to make it shouldn't matter. > * should what is an end-user be dependent on the category? For example I > think that 'Engineering and Scientific' end users care about numerical > libraries, so it makes sense to have some libraries often used in > models or the like in that category. There is allready blas and lapack, > for example. For what it's worth, locally I change that group to "Engineering, Math, and Science". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jamatos at fc.up.pt Sat Jul 29 10:58:34 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Sat, 29 Jul 2006 11:58:34 +0100 Subject: questions about comps files In-Reply-To: <20060729104748.GA5399@jadzia.bu.edu> References: <20060729093041.GA2701@free.fr> <20060729104748.GA5399@jadzia.bu.edu> Message-ID: <200607291158.34968.jamatos@fc.up.pt> On Saturday 29 July 2006 11:47, Matthew Miller wrote: > For what it's worth, locally I change that group to "Engineering, Math, and > Science". The question is really this, the relation between comps files and Groups. Groups seems to be obsolete and never had (AFAIK) very clear rules. We ship several libraries that have other dependencies, and are interesting in themselves, why should not them be referred in comps? > -- > Matthew Miller ? ? ? ? ? mattdm at mattdm.org ? ? ? ? ? > Boston University Linux ? ? ?------> ? ? ? ? ? ? ? -- Jos? Ab?lio From fedora at leemhuis.info Sat Jul 29 11:01:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 29 Jul 2006 13:01:28 +0200 Subject: Fedora Ticket System (OTRS) In-Reply-To: <200607290156.52408.nman64@n-man.com> References: <200607290156.52408.nman64@n-man.com> Message-ID: <44CB4008.6070500@leemhuis.info> Patrick W. Barnes schrieb: > I've seen questions pop up about the Fedora Ticket System in a few threads > recently, so here's some basic information relevant to Fedora Extras. > [...] Patrick, thx for you mail. It was a lot more helpful than the mails from Sopwhith and mmcgrath. It clears things up mostly afaics. To members of fedora-extras-list: If there are any open questions please ask now. To Patrick: You probably should add this informations to a proper place in the wiki somewhere (if they aren't there yet). Otherwise everything will get forgotten soon. CU thl From mattdm at mattdm.org Sat Jul 29 11:08:19 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 29 Jul 2006 07:08:19 -0400 Subject: questions about comps files In-Reply-To: <200607291158.34968.jamatos@fc.up.pt> References: <20060729093041.GA2701@free.fr> <20060729104748.GA5399@jadzia.bu.edu> <200607291158.34968.jamatos@fc.up.pt> Message-ID: <20060729110819.GA6215@jadzia.bu.edu> On Sat, Jul 29, 2006 at 11:58:34AM +0100, Jose' Matos wrote: > > For what it's worth, locally I change that group to "Engineering, Math, and > > Science". > The question is really this, the relation between comps files and Groups. > Groups seems to be obsolete and never had (AFAIK) very clear rules. I mean I change that component; I leave the groups alone. > We ship several libraries that have other dependencies, and are interesting > in themselves, why should not them be referred in comps? Yes, this is kind of messy in the area of scientific computation. Also, development libraries. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From christoph.wickert at nurfuerspam.de Sat Jul 29 12:35:39 2006 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Sat, 29 Jul 2006 14:35:39 +0200 Subject: admin site package In-Reply-To: <44C8FA13.1020505@cora.nwra.com> References: <668bb39a0607251327t2f532a7di64a81bda9f57d756@mail.gmail.com> <44C8FA13.1020505@cora.nwra.com> Message-ID: <1154176539.2920.4.camel@hal9000.local.lan> Am Donnerstag, den 27.07.2006, 11:38 -0600 schrieb Orion Poplawski: > Rex Dieter wrote: > > Micha? Bentkowski wrote: > > > >> When I took a look on buildsys site today, I saw one package is > >> building for over one day. > > > > I already reported it to http://admin.fedoraproject.org/tickets/ this > > morning. > > > > -- Rex > > > > What username/password are we supposed to use for this? I'm afraid I've > forgotten mine (assuming I have one...) Same username & password as you are using for the accounts system at admin.fedoraproject.org too. Chris -- Please do not sent private messages to this address, it is not beeing monitored. Bitte keine pers?nlichen Nachrchten an diese Adresse senden, sie wird nicht ?berwacht. From bugs.michael at gmx.net Sat Jul 29 12:59:42 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 29 Jul 2006 14:59:42 +0200 Subject: Fedora Ticket System (OTRS) In-Reply-To: <44CB4008.6070500@leemhuis.info> References: <200607290156.52408.nman64@n-man.com> <44CB4008.6070500@leemhuis.info> Message-ID: <20060729145942.05bd3b3b.bugs.michael@gmx.net> On Sat, 29 Jul 2006 13:01:28 +0200, Thorsten Leemhuis wrote: > > > Patrick W. Barnes schrieb: > > I've seen questions pop up about the Fedora Ticket System in a few threads > > recently, so here's some basic information relevant to Fedora Extras. > > [...] > > Patrick, thx for you mail. It was a lot more helpful than the mails from > Sopwhith and mmcgrath. Exactly. > It clears things up mostly afaics. Agreed. Thanks, Patrick! > To members of > fedora-extras-list: If there are any open questions please ask now. > > To Patrick: You probably should add this informations to a proper place > in the wiki somewhere (if they aren't there yet). Otherwise everything > will get forgotten soon. > > CU > thl > From fedora at leemhuis.info Sat Jul 29 13:52:26 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 29 Jul 2006 15:52:26 +0200 Subject: Ideas for Co-maintainership in Extras Message-ID: <44CB681A.8030709@leemhuis.info> Hi all! Welcome everybody to my brain dump of ideas around co-maintainership for Fedora Extras. == Why we need it == * co-maintainership could be the main new enter path for new Extras contributors -- people could start their "Extras maintainer life" with co-maintaining packages when they don#t know what to package (a lot of/most interesting stuff is already packages so the traditional enter path doesn#t scale anymore). Experienced maintainer could watch, help and teach the new contributor. If the new contributor showed that he understands everything well he gets more permissions in Extras -- he for example could take over a package as primary maintainer * upstream maintainers could co-maintain their packages. They could import the updates and the main fedora-maintainers watches their doings and checks that everything stays compatible to Fedora Core and the Fedora packaging guidelines * Someone has to fix security stuff during those time periods if a problems went public but everybody is offline now and then for some time, take for example vacations or traveling to conferences. I suspect that a lot of contributors probably are far away from a computer at least once a year for for one, two, three, four or even more weeks -- co-maintainers could fix stuff in those timeframes. * people get when distracted by other projects/work areas/schedules/real life and can't watch their packages closely to fix/update stuff * people use packages sometimes differently -- one maintainer might be more interested in feature foo while the other might be more interested in bar -- let them work together and the package is better maintained and the quality improved for users that need both foo and bar * all maintainers of one package could watch and check each others commits * we support multiple releases (and will probably support even more in the future) -- one packager might be interested in devel and FC-current only while another might be interested in FC-current -1 or -2, but has no interest in FC-current or devel * some people maintain more then 50 (one even more then 100) packages -- we should make sure they don't burn out. And the package quality probably is better if one maintainer only maintains a smaller number of packages * sponsors might be interested -- they could act as primary-maintainer for a new package from a new contributor in the beginning if they are unsure if the new contributor is worth sponsoring. The new contributor could do all the work in cvs while being watched by the sponsor. Only the sponsor would have permission to request the build of a package. * Reviewers could automatically be made temporary comaintainers of the packages they review so they see that the packager is doing the right things to get it to build in the build system for the first time, etc. * co-maintainership maybe could be used in Core, too -- e.g. the primary maintainer with access to the buildsys could be someone from Red Hat, while the co-maintainers are from inside and outside of Red Hat. That probably would help get load of the shoulders from Red Hat maintainers and increase package quality. * Packaging-SIGs (like the Extras Games SIG) or their primary members could act as co-maintainers for all packages that fall into the SIGs working area There are probably even more reasons a that don't come to my mind now. == What we need to make all that happen == * we need limited access in the VCS -- e.g. new contributors that start as co-maintainers get only access to the packages they co-maintain, but not to the buildsys or to other packages * per repo maintainers should be possible -- we probably need a proper the package database for this * primary- and other co-maintainers need to get mails directly into their inbox for everything other maintainers do with a package (commit changes, updates, upload of new files, build requests, pushes). * rules need to be written, e.g. * responsibilities between co-maitainer and primary maintainer * Bug responsiveness * do we need a primary maintainer at all? * can N (N=4?) co-maintainers outvote the primary maintainer in case of disputes? * can there be takeovers ("I'm doing all the work and my primary maintainer never does anything; I want to take the package over") * probably a lot more... * "new contributors have to actively co-maintain one package for at least X months before they can take over this or other packages completely (they of course can also take the traditional route with a new package and sponsoring) == Action plan == === Short term === * Fix bugzilla auto-CC in owners.list -- see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198109 * evaluate in detail the technical groundwork we need for proper co-maintainership -- especially package database, VCS, the accounts system and everywhere else === Middle term === * Wait for the new package database to finish and make sure it offers everything we need (maintainers per dist, ...) * encourage co-maintainership in general -- I'd say that 95% of Extras packages should have co-maintainers (the other 5% are packages for special interest areas where only one of the current contributors might bne interested in) * especially encourage co-maintainership or even a package hand-over to those people that maintain a lot of or important packages * work out detailed rules for co-maintainership (see above) === Long term === * make sure co-maintainers get mails when one of their packages is changed in CVS or build (people can set up local filters to get something like that but it's often forgotten and likely to break; a feature like this is also interesting for sponsors that want to watch people they sponsored closely) * make co-maintainership possible in core, too. == EOF == Comments? CU thl From buildsys at fedoraproject.org Sat Jul 29 14:05:48 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 29 Jul 2006 10:05:48 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-29 Message-ID: <20060729140548.516FF152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 32 BackupPC-2.1.2-6.fc5 CCfits-1.5-2.fc5 boo-0.7.6.2237-7.fc5 clisp-2.39-3.fc5 conman-0.1.9.2-4.fc5 cvs2svn-1.4.0-0.4.rc1.fc5 eric-3.9.1-2.fc5 gdmap-0.7.5-4.fc5 glipper-0.89-3.fc5 gtksourceview-sharp-2.0-13.fc5 ip6sic-0.1-3.fc5 kanatest-0.3.6-5.fc5 liferea-1.0.18-2.fc5 manaworld-0.0.20-1.fc5 monsterz-0.7.0-6.fc5 mysql-administrator-1.1.10-2.fc5 nant-0.85-6.fc5 perl-Class-InsideOut-1.01-1.fc5 perl-Email-Simple-1.96-1.fc5 perl-MailTools-1.74-2.fc5 perl-PAR-Dist-0.15-1.fc5 perl-POE-Component-Client-HTTP-0.77-2.fc5 perl-POE-Component-Client-LDAP-0.04-2.fc5 perl-POE-Component-SNMP-1.05-2.fc5 perl-POE-Filter-IRCD-1.8-1.fc5 perl-POE-Wheel-Null-0.01-1.fc5 plt-scheme-352-1.fc5 serpentine-0.7-4.fc5 shorewall-3.2.1-1.fc5 tetex-IEEEtran-1.6.3-1.fc5 vips-7.10.20-3.fc5 xdg-utils-1.0-0.5.20060721.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From tibbs at math.uh.edu Sat Jul 29 18:08:55 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 29 Jul 2006 13:08:55 -0500 Subject: Stalled review policy proposal Message-ID: As discussed at the recent FESCo meeting, I've drawn up a quick policy for dealing with stalled reviews. It's not intended to be comprehensive; the idea is to address two main issues that have been causing problems in the review process: unresponsive reviewers and unresponsive package submitters. The draft is at http://fedoraproject.org/wiki/JasonTibbitts/StalledReviewPolicy; I will include a copy below and keep the draft updated with comments I receive. A primary item of discussion is now long we should wait before taking action on a stalled review. I have proposed one month but at the FESCo meeting time periods of six and eight weeks were also proposed. ---- Policy for dealing with Stalled Package Reviews Occasionally package reviews fail to make forward progress due to lack of response from one of the parties involved in the review. This policy addresses two classes of reviews: those stalled because the review submitter is not responding, and those which have been assigned to a reviewer and are stalled because that reviewer is not responding. The idea is to move the ticket to a state where other interested parties can submit the package or take over the review. Of course there is no intent to punish anyone, and tickets can always be assigned back to the same reviewer or reopened. Note: I have chosen below a period of one month of inactivity as the threshold beyond which a review is considered stalled, and a final period of one week between notification and action. These are matters for discussion. Reviews stalled due to lack of reviewer response When a review ticket has been assigned to a reviewer and that reviewer has not responded to comments for one month: * A comment should be added to the ticket indicating that the review is stalled and that a response is needed soon. * If there is no response within one week: o The FE-REVIEW blocker is removed and FE-NEW replaces it o The ticket is reassigned to [MAILTO] nobody at fedoraproject.org. (Currently there is no UNASSIGNED state to move the ticket to. This also assumes that the nobody at fedorapeoject.org address is actually created.) The intent is to move the ticket back to a state where another reviewer can work on it. The original reviewer can of course take the ticket again, but they should be urged to respond in a more timely manner or Reviews stalled due to lack of submitter response When the submitter of a review ticket has not responded to comments for one month: * A comment should be added to the ticket indicating that the review is stalled and that a response is needed soon. * If there is no response within one week: o The ticket is closed with resolution NOTABUG. o The FE-NEW blocker is removed. The intent is to close the bug so that it can be submitted by someone else in a separate bug. If the bug is resubmitted by someone else, it is also reasonable to change the resolution on the closed bug to DUPLICATE and mark it as a duplicate of the new bug so that reviewers of the new ticket can easily find the work that was done on the old one. From nman64 at n-man.com Sat Jul 29 18:21:10 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sat, 29 Jul 2006 13:21:10 -0500 Subject: Fedora Ticket System (OTRS) In-Reply-To: <44CB4008.6070500@leemhuis.info> References: <200607290156.52408.nman64@n-man.com> <44CB4008.6070500@leemhuis.info> Message-ID: <200607291321.14831.nman64@n-man.com> On Saturday 29 July 2006 06:01, Thorsten Leemhuis wrote: > Patrick W. Barnes schrieb: > > I've seen questions pop up about the Fedora Ticket System in a few > > threads recently, so here's some basic information relevant to Fedora > > Extras. [...] > > Patrick, thx for you mail. It was a lot more helpful than the mails from > Sopwhith and mmcgrath. It clears things up mostly afaics. To members of > fedora-extras-list: If there are any open questions please ask now. > > To Patrick: You probably should add this informations to a proper place > in the wiki somewhere (if they aren't there yet). Otherwise everything > will get forgotten soon. > http://fedoraproject.org/wiki/Extras/ReportingIssues (Link added to Extras main page.) -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at cypherpunks.ca Sat Jul 29 19:16:56 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Sat, 29 Jul 2006 21:16:56 +0200 (CEST) Subject: devel not properly generating ./configure with autoconf? Message-ID: Hi, I am having troubles with gaim-otr on the devel branch. It seems the calls to autoconf are not generating a configure file. As I do not have access to an FC6test or rawhide server, it's hard for me to figure out what is going on. Did anyone else have similar problems with autoconf? Or does anyone have a throwaway xenu of fc6test1 I can abuse for a day or two? Paul -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 From buildsys at fedoraproject.org Sat Jul 29 19:20:00 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 29 Jul 2006 15:20:00 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-29 Message-ID: <20060729192000.45313152169@buildsys.fedoraproject.org> azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) CCfits: 5: 0:1.5-2.fc5 (FE5) 6: 0:1.5-1.fc6 (FE6) clisp: 5: 0:2.39-3.fc5 (FE5) 6: 0:2.39-2.fc6 (FE6) conman: 5: 0:0.1.9.2-4.fc5 (FE5) 6: 0:0.1.9.2-3.fc6 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) fbida: 5: 0:2.03-12.fc5 (FE5) 6: 0:2.03-11.fc6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gcdmaster: 4: 0:1.2.1-5.fc4 (FE4) 5: 0:1.2.1-4.fc5 (FE5) 6: 0:1.2.1-4.fc5 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) gdmap: 5: 0:0.7.5-4.fc5 (FE5) 6: 0:0.7.5-3.fc6 (FE6) glipper: 5: 0:0.89-3.fc5 (FE5) 6: 0:0.89-2.fc6 (FE6) inkscape: 4: 0:0.44-3.fc4 (FE4) 5: 0:0.44-2.fc5 (FE5) 6: 0:0.44-2.fc6 (FE6) ip6sic: 5: 0:0.1-3.fc5 (FE5) 6: 0:0.1-2.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) kadu: 5: 0:0.5.0-0.5.20060727svn.fc5 (FE5) 6: 0:0.5.0-0.4.20060716svn.fc6 (FE6) kanatest: 5: 0:0.3.6-5.fc5 (FE5) 6: 0:0.3.6-4.fc5 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) liferea: 5: 0:1.0.18-2.fc5 (FE5) 6: 0:1.0.16-4.fc6 (FE6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-2 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-14.fc6 (FC6) manaworld: 5: 0:0.0.20-1.fc5 (FE5) 6: 0:0.0.19-1.fc6 (FE6) mysql-administrator: 5: 0:1.1.10-2.fc5 (FE5) 6: 0:1.1.10-1.fc6 (FE6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-Class-InsideOut: 5: 0:1.01-1.fc5 (FE5) 6: 0:1.00-1.fc6 (FE6) perl-Email-Simple: 5: 0:1.96-1.fc5 (FE5) 6: 0:1.95-1.fc6 (FE6) perl-MailTools: 5: 0:1.74-2.fc5 (FE5) 6: 0:1.74-1.fc5 (FE6) perl-PAR-Dist: 5: 0:0.15-1.fc5 (FE5) 6: 0:0.14-1.fc6 (FE6) perl-POE-Filter-IRCD: 5: 0:1.8-1.fc5 (FE5) 6: 0:1.7-1.fc6 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) plt-scheme: 5: 0:352-1.fc5 (FE5) 6: 0:351-1.fc6 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) quagga: 4: 0:0.98.6-1.fc4 (FC4-updates) 5: 0:0.98.6-1.FC5 (FC5-updates) 6: 0:0.98.6-2.1 (FC6) regexxer: 4: 0:0.8-5.fc4 (FE4) 5: 0:0.8-4.fc5 (FE5) 6: 0:0.8-4.fc5 (FE6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) serpentine: 5: 0:0.7-4.fc5 (FE5) 6: 0:0.7-1.fc6 (FE6) shorewall: 5: 0:3.2.1-1.fc5 (FE5) 6: 0:3.2.0-0.1.RC4.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) tetex-IEEEtran: 5: 0:1.6.3-1.fc5 (FE5) 6: 0:1.6c-3.fc6 (FE6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) vips: 5: 0:7.10.20-3.fc5 (FE5) 6: 0:7.10.20-2.fc6 (FE6) xdg-utils: 5: 0:1.0-0.5.20060721.fc5 (FE5) 6: 0:1.0-0.4.20060721 (FE6) xorg-x11-drv-nv: 5: 0:1.2.0-3.fc5 (FC5-updates) 6: 0:1.2.0-2.fc6 (FC6) From buildsys at fedoraproject.org Sat Jul 29 19:38:23 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 29 Jul 2006 19:38:23 -0000 Subject: Summary - Broken dependencies in Fedora Extras 3 - 2006-07-29 Message-ID: <20060729193823.24655.94938@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 (114 days) fluxbox - 0.9.15.1-1.fc3.x86_64 (114 days) spr AT astrax.fis.ucm.es CCfits-docs - 1.5-1.fc3.i386 CCfits-docs - 1.5-1.fc3.x86_64 Summary of broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc3.i386 requires /usr1/local/bin/perl5 fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Summary of broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc3.x86_64 requires /usr1/local/bin/perl5 fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg From buildsys at fedoraproject.org Sat Jul 29 19:38:23 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 29 Jul 2006 19:38:23 -0000 Subject: Summary - Broken dependencies in Fedora Extras 4 - 2006-07-29 Message-ID: <20060729193823.24663.8603@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 (14 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc (14 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 (14 days) spr AT astrax.fis.ucm.es CCfits-docs - 1.5-1.fc4.i386 CCfits-docs - 1.5-1.fc4.ppc CCfits-docs - 1.5-1.fc4.x86_64 Summary of broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc4.i386 requires /usr1/local/bin/perl5 python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 Summary of broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc4.ppc requires /usr1/local/bin/perl5 python-ruledispatch-0.5a0-0.1.svnr2115.fc4.ppc requires python-protocols >= 0:1.0 Summary of broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc4.x86_64 requires /usr1/local/bin/perl5 python-ruledispatch-0.5a0-0.1.svnr2115.fc4.x86_64 requires python-protocols >= 0:1.0 From buildsys at fedoraproject.org Sat Jul 29 19:38:23 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 29 Jul 2006 19:38:23 -0000 Subject: Summary - Broken dependencies in Fedora Extras 5 - 2006-07-29 Message-ID: <20060729193823.24674.99528@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 (14 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc (14 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 (14 days) mpeters AT mac.com libvisual-plugins - 0.2.0-3.fc5.i386 (10 days) libvisual-plugins - 0.2.0-3.fc5.ppc (10 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (10 days) oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (73 days) syck-php - 0.55-7.fc5.ppc (73 days) syck-php - 0.55-7.fc5.x86_64 (73 days) Summary of broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.i386 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.ppc requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc5.x86_64 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 From buildsys at fedoraproject.org Sat Jul 29 19:38:23 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 29 Jul 2006 19:38:23 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2006-07-29 Message-ID: <20060729193823.24685.99778@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de pdftk - 1.12-6.fc5.i386 (3 days) pdftk - 1.12-6.fc5.ppc (3 days) pdftk - 1.12-6.fc5.x86_64 (3 days) andreas.bierfert AT lowlatency.de wine-core - 0.9.17-1.fc6.i386 (3 days) byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 (10 days) gaim-guifications - 2.12-3.fc5.ppc (10 days) gaim-guifications - 2.12-3.fc5.x86_64 (10 days) caillon AT redhat.com banshee - 0.10.8-1.i386 (10 days) banshee - 0.10.8-1.ppc (10 days) banshee - 0.10.8-1.x86_64 (10 days) libipoddevice - 0.4.5-1.fc6.i386 (9 days) libipoddevice - 0.4.5-1.fc6.ppc (9 days) libipoddevice - 0.4.5-1.fc6.x86_64 (9 days) cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 (10 days) gaim-gaym - 0.96-2.fc6.ppc (10 days) gaim-gaym - 0.96-2.fc6.x86_64 (10 days) dennis AT ausil.us knetworkmanager - 0.1-0.3.svn20060625.fc6.i386 (9 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.ppc (9 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.x86_64 (9 days) fedora AT leemhuis.info gsynaptics - 0.9.8-1.fc6.ppc (10 days) gauret AT free.fr amarok - 1.4.1-3.fc6.i386 amarok - 1.4.1-3.fc6.ppc green AT redhat.com azureus - 2.4.0.3-0.20060328cvs_5.fc6.i386 (3 days) azureus - 2.4.0.3-0.20060328cvs_5.fc6.ppc (3 days) azureus - 2.4.0.3-0.20060328cvs_5.fc6.x86_64 (3 days) itext - 1.3-1jpp_8.fc5.i386 (3 days) itext - 1.3-1jpp_8.fc5.ppc (3 days) itext - 1.3-1jpp_8.fc5.x86_64 (3 days) jogl - 1.1.1-14.fc5.i386 (6 days) jogl - 1.1.1-14.fc5.ppc (6 days) rssowl - 1.2-12.fc6.i386 (3 days) rssowl - 1.2-12.fc6.ppc (3 days) rssowl - 1.2-12.fc6.x86_64 (3 days) ivazquez AT ivazquez.net gnome-applet-music - 0.9.0-1.fc6.i386 (10 days) gnome-applet-music - 0.9.0-1.fc6.ppc (10 days) gnome-applet-music - 0.9.0-1.fc6.x86_64 (10 days) nautilus-search-tool - 0.2-1.fc5.i386 (10 days) nautilus-search-tool - 0.2-1.fc5.ppc (10 days) nautilus-search-tool - 0.2-1.fc5.x86_64 (10 days) matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 (10 days) diradmin - 1.7.1-4.fc5.ppc (10 days) diradmin - 1.7.1-4.fc5.x86_64 (10 days) gtktalog - 1.0.4-7.fc5.i386 (10 days) gtktalog - 1.0.4-7.fc5.ppc (10 days) gtktalog - 1.0.4-7.fc5.x86_64 (10 days) mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 (10 days) gfontview - 0.5.0-5.fc5.ppc (10 days) gfontview - 0.5.0-5.fc5.x86_64 (10 days) gtkhtml36 - 3.6.2-5.fc6.i386 (10 days) gtkhtml36 - 3.6.2-5.fc6.ppc (10 days) gtkhtml36 - 3.6.2-5.fc6.x86_64 (10 days) libvisual-plugins - 0.2.0-3.fc5.i386 (10 days) libvisual-plugins - 0.2.0-3.fc5.ppc (10 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (10 days) oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (10 days) syck-php - 0.55-7.fc5.ppc (10 days) syck-php - 0.55-7.fc5.x86_64 (10 days) pertusus AT free.fr cernlib - 2005-21.fc6.ppc (10 days) cernlib-packlib - 2005-21.fc6.ppc (10 days) dap-hdf4_handler - 3.6.0-3.fc5.i386 (6 days) dap-hdf4_handler - 3.6.0-3.fc5.ppc (6 days) dap-hdf4_handler - 3.6.0-3.fc5.x86_64 (6 days) patchy - 2005-21.fc6.ppc (10 days) paw - 2005-21.fc6.ppc (10 days) qspencer AT ieee.org octave-forge - 2006.07.09-2.fc6.i386 (6 days) octave-forge - 2006.07.09-2.fc6.ppc (6 days) octave-forge - 2006.07.09-2.fc6.x86_64 (6 days) robert AT marcanoonline.com ganymed-ssh2 - 209-4.fc6.i386 (3 days) ganymed-ssh2 - 209-4.fc6.ppc (3 days) ganymed-ssh2 - 209-4.fc6.x86_64 (3 days) javasvn - 1.0.6-1.fc6.i386 (3 days) javasvn - 1.0.6-1.fc6.ppc (3 days) javasvn - 1.0.6-1.fc6.x86_64 (3 days) rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 (10 days) libibverbs - 1.0.3-1.fc6.ppc (10 days) libibverbs - 1.0.3-1.fc6.x86_64 (10 days) libibverbs-utils - 1.0.3-1.fc6.i386 (10 days) libibverbs-utils - 1.0.3-1.fc6.ppc (10 days) libibverbs-utils - 1.0.3-1.fc6.x86_64 (10 days) spr AT astrax.fis.ucm.es CCfits-docs - 1.5-1.fc6.i386 CCfits-docs - 1.5-1.fc6.ppc CCfits-docs - 1.5-1.fc6.x86_64 thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 (10 days) directfb - 0.9.24-5.fc5.ppc (10 days) directfb - 0.9.24-5.fc5.x86_64 (10 days) Summary of broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc6.i386 requires /usr1/local/bin/perl5 amarok-1.4.1-3.fc6.i386 requires HelixPlayer azureus-2.4.0.3-0.20060328cvs_5.fc6.i386 requires libgcj.so.7 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 banshee-0.10.8-1.i386 requires libdbus-1.so.2 dap-hdf4_handler-3.6.0-3.fc5.i386 requires libdap.so.4 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 ganymed-ssh2-209-4.fc6.i386 requires libgcj.so.7 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.i386 requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.i386 requires libdbus-1.so.2 gtkhtml36-3.6.2-5.fc6.i386 requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 itext-1.3-1jpp_8.fc5.i386 requires libgcj.so.7 javasvn-1.0.6-1.fc6.i386 requires libgcj.so.7 jogl-1.1.1-14.fc5.i386 requires libgcj.so.7 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-qt-1.so.1 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.i386 requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.i386 requires libgailutil.so.17 octave-forge-2006.07.09-2.fc6.i386 requires libdap.so.4 pdftk-1.12-6.fc5.i386 requires libgcj.so.7 rssowl-1.2-12.fc6.i386 requires libgcj.so.7 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc6.ppc requires /usr1/local/bin/perl5 amarok-1.4.1-3.fc6.ppc requires HelixPlayer azureus-2.4.0.3-0.20060328cvs_5.fc6.ppc requires libgcj.so.7 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 banshee-0.10.8-1.ppc requires libdbus-1.so.2 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 dap-hdf4_handler-3.6.0-3.fc5.ppc requires libdap.so.4 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 ganymed-ssh2-209-4.fc6.ppc requires libgcj.so.7 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.ppc requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.ppc requires libdbus-1.so.2 gsynaptics-0.9.8-1.fc6.ppc requires synaptics gtkhtml36-3.6.2-5.fc6.ppc requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 itext-1.3-1jpp_8.fc5.ppc requires libgcj.so.7 javasvn-1.0.6-1.fc6.ppc requires libgcj.so.7 jogl-1.1.1-14.fc5.ppc requires libgcj.so.7 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-qt-1.so.1 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.ppc requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.ppc requires libgailutil.so.17 octave-forge-2006.07.09-2.fc6.ppc requires libdap.so.4 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 pdftk-1.12-6.fc5.ppc requires libgcj.so.7 rssowl-1.2-12.fc6.ppc requires libgcj.so.7 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Summary of broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- CCfits-docs-1.5-1.fc6.x86_64 requires /usr1/local/bin/perl5 azureus-2.4.0.3-0.20060328cvs_5.fc6.x86_64 requires libgcj.so.7()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) banshee-0.10.8-1.x86_64 requires libdbus-1.so.2()(64bit) dap-hdf4_handler-3.6.0-3.fc5.x86_64 requires libdap.so.4()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 ganymed-ssh2-209-4.fc6.x86_64 requires libgcj.so.7()(64bit) gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libgailutil.so.17()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) gtkhtml36-3.6.2-5.fc6.x86_64 requires libgailutil.so.17()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) itext-1.3-1jpp_8.fc5.x86_64 requires libgcj.so.7()(64bit) javasvn-1.0.6-1.fc6.x86_64 requires libgcj.so.7()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-qt-1.so.1()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-1.so.2()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libipoddevice-0.4.5-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) nautilus-search-tool-0.2-1.fc5.x86_64 requires libgailutil.so.17()(64bit) octave-forge-2006.07.09-2.fc6.x86_64 requires libdap.so.4()(64bit) pdftk-1.12-6.fc5.x86_64 requires libgcj.so.7()(64bit) rssowl-1.2-12.fc6.x86_64 requires libgcj.so.7()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 wine-core-0.9.17-1.fc6.i386 requires libglut.so.3 From jkeating at redhat.com Sat Jul 29 19:47:48 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 29 Jul 2006 15:47:48 -0400 Subject: repodata for extras 5 x86_64 b0rked Message-ID: <200607291547.52358.jkeating@redhat.com> Well incomplete. No xml files, just some incomplete repoview content. Has been this way since at least yesterday evening. Can somebody fix this please? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sat Jul 29 20:41:19 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 29 Jul 2006 22:41:19 +0200 Subject: repodata for extras 5 x86_64 b0rked In-Reply-To: <200607291547.52358.jkeating@redhat.com> References: <200607291547.52358.jkeating@redhat.com> Message-ID: <20060729224119.b5d46706.bugs.michael@gmx.net> On Sat, 29 Jul 2006 15:47:48 -0400, Jesse Keating wrote: > Well incomplete. No xml files, just some incomplete repoview content. Has > been this way since at least yesterday evening. > > Can somebody fix this please? Cannot confirm. The build master repository looks fine. It's likely that Warren's earlier push of '5' has fixed this already. Can you reproduce with http://fedoraproject.org/extras/5/x86_64/ ? Would have been interesting to know what kind of damage we've had here. From jkeating at redhat.com Sat Jul 29 20:58:16 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 29 Jul 2006 16:58:16 -0400 Subject: repodata for extras 5 x86_64 b0rked In-Reply-To: <20060729224119.b5d46706.bugs.michael@gmx.net> References: <200607291547.52358.jkeating@redhat.com> <20060729224119.b5d46706.bugs.michael@gmx.net> Message-ID: <200607291658.16970.jkeating@redhat.com> On Saturday 29 July 2006 16:41, Michael Schwendt wrote: > Cannot confirm. The build master repository looks fine. It's likely that > Warren's earlier push of '5' has fixed this already. Can you reproduce > with http://fedoraproject.org/extras/5/x86_64/ ? > > Would have been interesting to know what kind of damage we've had here. Forgive me. Error on my end. When I was originally testing a push was happening and I was getting 404s. I was using lftp to look at it to debug, forgetting that lftp will process the html pages and show links. Silly me (: -- 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 paul at all-the-johnsons.co.uk Sat Jul 29 22:04:05 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 29 Jul 2006 23:04:05 +0100 Subject: FESCo Meeting Minutes 2006-07-27 In-Reply-To: <1154157077.4720.6.camel@localhost> References: <1154157077.4720.6.camel@localhost> Message-ID: <1154210645.5101.5.camel@T7.Linux> Hi, > (10:32:55) c4chris: I think Nodoid is also candidate > (10:33:17) c4chris: (if I got the IRC nick right) You have and did. In case you're interested, a nodoid is a shape. If you lick you thumb and finger, press them together and pull them apart *really* slowly, you'll see what's known as a liquid bridge. The shape of said bridge is a called a nodoid. I did my MPhil on it and simulating it in software. http://www.all-the-johnsons.co.uk/nodoid/front-cover.shtml TTFN Paul -- Wenn sie denken, dass die bildung teuer ist, versuchen sie ignoranz -------------- 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 frank-buettner at gmx.net Sun Jul 30 09:00:03 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Sun, 30 Jul 2006 11:00:03 +0200 Subject: Modify package of other owners Message-ID: <44CC7513.8010207@gmx.net> Is this the new develop kind on Fedora Extra that owners change the packages of other owners without discuss about it??? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature URL: From michael at knox.net.nz Sun Jul 30 09:04:19 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sun, 30 Jul 2006 21:04:19 +1200 Subject: Modify package of other owners In-Reply-To: <44CC7513.8010207@gmx.net> References: <44CC7513.8010207@gmx.net> Message-ID: <44CC7613.5060003@knox.net.nz> Frank B?ttner wrote: > Is this the new develop kind on Fedora Extra that owners change the > packages of other owners without discuss about it??? Nope. So you might want to elaborate a little more. If someone has modified a package of yours, there could be a good reason (maybe for not letting you know). Michael From michael at knox.net.nz Sun Jul 30 09:07:59 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sun, 30 Jul 2006 21:07:59 +1200 Subject: FESCo Meeting Minutes 2006-07-27 In-Reply-To: <1154157077.4720.6.camel@localhost> References: <1154157077.4720.6.camel@localhost> Message-ID: <44CC76EF.3090605@knox.net.nz> Toshio Kuratomi wrote: > * mjk- was accepted as a sponsor. sweet :) Ok, so I tried upgrading my cvsextras status in the accounts system from user to sponsor, but them seemed to do a whole heap not much. The wiki pages are not overly enlightening to how I "claim" my sponsor status, so if someone who knows what I need to do could let me know how, I would much appreciate it. Michael From j.w.r.degoede at hhs.nl Sun Jul 30 09:19:30 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 30 Jul 2006 11:19:30 +0200 Subject: FESCo Meeting Minutes 2006-07-27 In-Reply-To: <44CC76EF.3090605@knox.net.nz> References: <1154157077.4720.6.camel@localhost> <44CC76EF.3090605@knox.net.nz> Message-ID: <44CC79A2.50000@hhs.nl> Michael J. Knox wrote: > Toshio Kuratomi wrote: >> * mjk- was accepted as a sponsor. > > sweet :) > > Ok, so I tried upgrading my cvsextras status in the accounts system from > user to sponsor, but them seemed to do a whole heap not much. > > The wiki pages are not overly enlightening to how I "claim" my sponsor > status, so if someone who knows what I need to do could let me know how, > I would much appreciate it. > Someone with the nescesarry magic powers should change your status to sponsor, thats how it went for me :) Regards, Hans From fedora at leemhuis.info Sun Jul 30 09:34:00 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 30 Jul 2006 11:34:00 +0200 Subject: FESCo Meeting Minutes 2006-07-27 In-Reply-To: <44CC79A2.50000@hhs.nl> References: <1154157077.4720.6.camel@localhost> <44CC76EF.3090605@knox.net.nz> <44CC79A2.50000@hhs.nl> Message-ID: <44CC7D08.1030409@leemhuis.info> Hans de Goede schrieb: > > Michael J. Knox wrote: >> Toshio Kuratomi wrote: >>> * mjk- was accepted as a sponsor. >> sweet :) >> >> Ok, so I tried upgrading my cvsextras status in the accounts system from >> user to sponsor, but them seemed to do a whole heap not much. >> >> The wiki pages are not overly enlightening to how I "claim" my sponsor >> status, so if someone who knows what I need to do could let me know how, >> I would much appreciate it. > Someone with the nescesarry magic powers should change your status to > sponsor, [...] Done; sorry for the delay. Cu thl From frank-buettner at gmx.net Sun Jul 30 09:32:42 2006 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Sun, 30 Jul 2006 11:32:42 +0200 Subject: Modify package of other owners In-Reply-To: <44CC7613.5060003@knox.net.nz> References: <44CC7513.8010207@gmx.net> <44CC7613.5060003@knox.net.nz> Message-ID: <44CC7CBA.4090109@gmx.net> > Nope. So you might want to elaborate a little more. If someone has > modified a package of yours, there could be a good reason (maybe for not > letting you know). > But without notice it will disturb the internal develop of the package before it will be sent to the CVS system. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature URL: From michael at knox.net.nz Sun Jul 30 09:34:55 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Sun, 30 Jul 2006 21:34:55 +1200 Subject: FESCo Meeting Minutes 2006-07-27 In-Reply-To: <44CC7D08.1030409@leemhuis.info> References: <1154157077.4720.6.camel@localhost> <44CC76EF.3090605@knox.net.nz> <44CC79A2.50000@hhs.nl> <44CC7D08.1030409@leemhuis.info> Message-ID: <44CC7D3F.6080101@knox.net.nz> Thorsten Leemhuis wrote: > > Hans de Goede schrieb: >> Michael J. Knox wrote: >>> Toshio Kuratomi wrote: >>>> * mjk- was accepted as a sponsor. >>> sweet :) >>> >>> Ok, so I tried upgrading my cvsextras status in the accounts system from >>> user to sponsor, but them seemed to do a whole heap not much. >>> >>> The wiki pages are not overly enlightening to how I "claim" my sponsor >>> status, so if someone who knows what I need to do could let me know how, >>> I would much appreciate it. >> Someone with the nescesarry magic powers should change your status to >> sponsor, [...] > > Done; sorry for the delay. No need to apologize :) Thanks! Michael From bugs.michael at gmx.net Sun Jul 30 09:44:03 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 30 Jul 2006 11:44:03 +0200 Subject: Modify package of other owners In-Reply-To: <44CC7613.5060003@knox.net.nz> References: <44CC7513.8010207@gmx.net> <44CC7613.5060003@knox.net.nz> Message-ID: <20060730114403.58a2b0a9.bugs.michael@gmx.net> On Sun, 30 Jul 2006 21:04:19 +1200, Michael J. Knox wrote: > Frank B?ttner wrote: > > Is this the new develop kind on Fedora Extra that owners change the > > packages of other owners without discuss about it??? > > Nope. So you might want to elaborate a little more. If someone has > modified a package of yours, there could be a good reason (maybe for not > letting you know). I think he refers to the "qt4-qsa" package and Rex Dieter's changes in them. I don't know the background, just looked at the cvs log. From frank-buettner at gmx.net Sun Jul 30 09:52:24 2006 From: frank-buettner at gmx.net (=?ISO-8859-1?Q?Frank_B=FCttner?=) Date: Sun, 30 Jul 2006 11:52:24 +0200 Subject: Modify package of other owners In-Reply-To: <20060730114403.58a2b0a9.bugs.michael@gmx.net> References: <44CC7513.8010207@gmx.net> <44CC7613.5060003@knox.net.nz> <20060730114403.58a2b0a9.bugs.michael@gmx.net> Message-ID: <44CC8158.8080102@gmx.net> > I think he refers to the "qt4-qsa" package and Rex Dieter's changes > in them. I don't know the background, just looked at the cvs log. > Yes this is it. You have won 100 point's. He has change something. But first he not discuss the changes with me and second not written why he do it. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature URL: From rdieter at math.unl.edu Sun Jul 30 13:48:15 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 30 Jul 2006 08:48:15 -0500 Subject: Modify package of other owners In-Reply-To: <44CC8158.8080102@gmx.net> References: <44CC7513.8010207@gmx.net> <44CC7613.5060003@knox.net.nz> <20060730114403.58a2b0a9.bugs.michael@gmx.net> <44CC8158.8080102@gmx.net> Message-ID: Frank B?ttner wrote: >> I think he refers to the "qt4-qsa" package and Rex Dieter's changes >> in them. I don't know the background, just looked at the cvs log. >> > Yes this is it. You have won 100 point's. > He has change something. But first he not discuss the changes with me > and second not written why he do it. I figured since it was I that caused the breakage and it was an innocuous change, I just went ahead and fixed it myself. My apologies, it won't happen again. -- Rex From frank-buettner at gmx.net Sun Jul 30 14:14:05 2006 From: frank-buettner at gmx.net (=?ISO-8859-1?Q?Frank_B=FCttner?=) Date: Sun, 30 Jul 2006 16:14:05 +0200 Subject: Modify package of other owners In-Reply-To: References: <44CC7513.8010207@gmx.net> <44CC7613.5060003@knox.net.nz> <20060730114403.58a2b0a9.bugs.michael@gmx.net> <44CC8158.8080102@gmx.net> Message-ID: <44CCBEAD.7060109@gmx.net> > I figured since it was I that caused the breakage and it was an > innocuous change, I just went ahead and fixed it myself. My apologies, > it won't happen again. > > -- Rex > When you found an problem in an package it is good. But call the maintainer is better then modify it self. Because it is not very nice when my local working copy lost it synchrony with the CVS. And then I must fix it via hand. OK I will accept your excuse. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1747 bytes Desc: S/MIME Cryptographic Signature URL: From bugs.michael at gmx.net Sun Jul 30 17:37:40 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 30 Jul 2006 19:37:40 +0200 Subject: ppc2 builder error : Job failed on arch ppc: couldn't download result files from builder Message-ID: <20060730193740.06622249.bugs.michael@gmx.net> Second try. Still failing. Build server status pages are still failing, too, because of expired certs (I've opened a ticket for that). But what is this now? [...] Begin forwarded message: Date: Sun, 30 Jul 2006 11:58:21 -0400 (EDT) From: buildsys at fedoraproject.org To: bugs.michael at gmx.net Subject: Build Error (Job 13369): sylpheed-2_2_6-4_fc6 on fedora-development-extras Job failed on arch ppc: couldn't download result files from builder 'https://ppc2.fedora.redhat.com:8888'. Please contact the build system administrator. Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/13369-sylpheed-2.2.6-4.fc6/ ------------------------------------------------- From dennis at ausil.us Sun Jul 30 18:00:44 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 30 Jul 2006 13:00:44 -0500 Subject: ppc2 builder error : Job failed on arch ppc: couldn't download result files from builder In-Reply-To: <20060730193740.06622249.bugs.michael@gmx.net> References: <20060730193740.06622249.bugs.michael@gmx.net> Message-ID: <200607301300.47110.dennis@ausil.us> On Sunday 30 July 2006 12:37 pm, Michael Schwendt wrote: > Second try. Still failing. Build server status pages are still failing, > too, because of expired certs (I've opened a ticket for that). But what is > this now? I have rebuilt ppc1 and ppc2 and the build server was trying to download the files from the wrong domain name. please requeue your builds that failed because of this things should be ok now. a couple of packages have been downloaded from the ppc builders. -- Dennis Gilmore, RHCE Proud Australian From fedora at camperquake.de Sun Jul 30 18:01:48 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 30 Jul 2006 20:01:48 +0200 Subject: ppc2 builder error : Job failed on arch ppc: couldn't download result files from builder In-Reply-To: <20060730193740.06622249.bugs.michael@gmx.net> References: <20060730193740.06622249.bugs.michael@gmx.net> Message-ID: <20060730200148.1c9621c8@nausicaa.camperquake.de> Hi. Michael Schwendt wrote: > Build logs may be found at > http://buildsys.fedoraproject.org/logs/fedora-development-extras/13369-sylpheed-2.2.6-4.fc6/ FWIW, I just pushed 13378 (audacious on devel) through the buildsys, and the job succeeded (ppc is built). -- 500 EHOH not implemented From buildsys at fedoraproject.org Sun Jul 30 19:30:56 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 30 Jul 2006 15:30:56 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-30 Message-ID: <20060730193056.1F79A152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 4 regexxer-0.8-5.fc5 rssowl-1.2.1-2.fc5 s3switch-0.0-7.20020912.fc5 xfce4-weather-plugin-0.4.9-6.fc5 Packages built and released for Fedora Extras 4: 18 BackupPC-2.1.2-6.fc4 CCfits-1.5-2.fc4 clisp-2.39-3.fc4 conman-0.1.9.2-4.fc4 kanatest-0.3.6-5.fc4 krusader-1.70.1-1.fc4 manaworld-0.0.20-1.fc4 monsterz-0.7.0-6.fc4 mysql-administrator-1.1.10-2.fc4 perl-Class-InsideOut-1.01-1.fc4 perl-Email-Simple-1.96-1.fc4 perl-MailTools-1.74-2.fc4 perl-POE-Filter-IRCD-1.8-1.fc4 plt-scheme-352-1.fc4 shorewall-3.2.1-1.fc4 tetex-IEEEtran-1.6.3-1.fc4 vips-7.10.20-3.fc4 xdg-utils-1.0-0.5.20060721.fc4 Packages built and released for Fedora Extras 3: 4 CCfits-1.5-2.fc3 clisp-2.39-3.fc3 krusader-1.70.1-1.fc3 plt-scheme-352-1.fc3 Packages built and released for Fedora Extras development: 46 BackupPC-2.1.2-6.fc6 CCfits-1.5-2.fc6 audacious-1.1.1-1.fc6 clisp-2.39-3.fc6 conman-0.1.9.2-4.fc6 eris-1.3.11-6.fc6 fbida-2.05-1.fc6 ganymed-ssh2-209-5.fc6 gdmap-0.7.5-4.fc6 glipper-0.89-3.fc6 gnupg2-1.9.22-1.fc6 ip6sic-0.1-3.fc6 itext-1.3-1jpp_9.fc6 javasvn-1.0.6-2.fc6 kadu-0.5.0-0.5.20060727svn.fc6 kanatest-0.3.6-5.fc6 liferea-1.0.18-3.fc6 linkchecker-3.3-7.fc6 lzo-2.02-1.fc6 manaworld-0.0.20-1.fc6 monsterz-0.7.0-6.fc6 mysql-administrator-1.1.10-2.fc6 octave-2.9.7-1.fc6 octave-forge-2006.07.09-3.fc6 perl-Class-InsideOut-1.01-1.fc6 perl-Email-Simple-1.96-1.fc6 perl-MailTools-1.74-2.fc6 perl-Module-Build-0.2804-1.fc6 perl-PAR-Dist-0.15-1.fc6 perl-POE-Component-Client-HTTP-0.77-2.fc6 perl-POE-Component-Client-LDAP-0.04-2.fc6 perl-POE-Component-SNMP-1.05-2.fc6 perl-POE-Filter-IRCD-1.8-1.fc6 pessulus-2.15.90-1.fc6 plt-scheme-352-1.fc6 python-basemap-0.9.1-1.fc6 regexxer-0.8-5.fc6 sabayon-2.12.4-2.fc6 serpentine-0.7-3.fc6 shorewall-3.2.1-1.fc6 tetex-IEEEtran-1.6.3-1.fc6 vips-7.10.20-3.fc6 xdg-utils-1.0-0.5.20060721.fc6 xfce4-weather-plugin-0.4.9-6.fc6 xscreensaver-5.00-15.fc6 yum-utils-0.6-4.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sun Jul 30 19:31:23 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 30 Jul 2006 15:31:23 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-30 Message-ID: <20060730193123.6C845152169@buildsys.fedoraproject.org> azureus: 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) firestarter: 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gcdmaster: 4: 0:1.2.1-5.fc4 (FE4) 5: 0:1.2.1-4.fc5 (FE5) 6: 0:1.2.1-4.fc5 (FE6) gdesklets: 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) inkscape: 4: 0:0.44-3.fc4 (FE4) 5: 0:0.44-2.fc5 (FE5) 6: 0:0.44-2.fc6 (FE6) istanbul: 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) krusader: 4: 0:1.70.1-1.fc4 (FE4) 5: 0:1.70.0-1.fc5 (FE5) 6: 0:1.70.0-1.fc5 (FE6) libnasl: 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-2 (FC6) m17n-db: 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-14.fc6 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) opencv: 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-String-CRC32: 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) php-pear-DB: 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) python-myghty: 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) quagga: 4: 0:0.98.6-1.fc4 (FC4-updates) 5: 0:0.98.6-1.FC5 (FC5-updates) 6: 0:0.98.6-2.1 (FC6) rssowl: 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-tomoe: 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) serpentine: 5: 0:0.7-4.fc5 (FE5) 6: 0:0.7-3.fc6 (FE6) smart: 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) TeXmacs: 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) valknut: 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) xorg-x11-drv-nv: 5: 0:1.2.0-3.fc5 (FC5-updates) 6: 0:1.2.0-2.fc6 (FC6) From buildsys at fedoraproject.org Sun Jul 30 19:49:19 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 30 Jul 2006 19:49:19 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-07-30 Message-ID: <20060730194919.20275.67081@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de pdftk - 1.12-6.fc5.i386 (4 days) pdftk - 1.12-6.fc5.ppc (4 days) pdftk - 1.12-6.fc5.x86_64 (4 days) andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 (115 days) fluxbox - 0.9.15.1-1.fc3.x86_64 (115 days) wine-core - 0.9.17-1.fc6.i386 (4 days) byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 (11 days) gaim-guifications - 2.12-3.fc5.ppc (11 days) gaim-guifications - 2.12-3.fc5.x86_64 (11 days) caillon AT redhat.com banshee - 0.10.8-1.i386 (11 days) banshee - 0.10.8-1.ppc (11 days) banshee - 0.10.8-1.x86_64 (11 days) libipoddevice - 0.4.5-1.fc6.i386 (10 days) libipoddevice - 0.4.5-1.fc6.ppc (10 days) libipoddevice - 0.4.5-1.fc6.x86_64 (10 days) cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 (11 days) gaim-gaym - 0.96-2.fc6.ppc (11 days) gaim-gaym - 0.96-2.fc6.x86_64 (11 days) dennis AT ausil.us knetworkmanager - 0.1-0.3.svn20060625.fc6.i386 (10 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.ppc (10 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.x86_64 (10 days) extras-orphan AT fedoraproject.org dxpc - 3.8.2-3.fc5.2.i386 dxpc - 3.8.2-3.fc5.2.ppc dxpc - 3.8.2-3.fc5.2.x86_64 fedora AT leemhuis.info gsynaptics - 0.9.8-1.fc6.ppc (11 days) gauret AT free.fr amarok - 1.4.1-3.fc6.i386 (3 days) amarok - 1.4.1-3.fc6.ppc (3 days) green AT redhat.com azureus - 2.4.0.3-0.20060328cvs_5.fc6.i386 (4 days) azureus - 2.4.0.3-0.20060328cvs_5.fc6.ppc (4 days) azureus - 2.4.0.3-0.20060328cvs_5.fc6.x86_64 (4 days) jogl - 1.1.1-14.fc5.i386 (7 days) jogl - 1.1.1-14.fc5.ppc (7 days) rssowl - 1.2-12.fc6.i386 (4 days) rssowl - 1.2-12.fc6.ppc (4 days) rssowl - 1.2-12.fc6.x86_64 (4 days) ivazquez AT ivazquez.net gnome-applet-music - 0.9.0-1.fc6.i386 (11 days) gnome-applet-music - 0.9.0-1.fc6.ppc (11 days) gnome-applet-music - 0.9.0-1.fc6.x86_64 (11 days) nautilus-search-tool - 0.2-1.fc5.i386 (11 days) nautilus-search-tool - 0.2-1.fc5.ppc (11 days) nautilus-search-tool - 0.2-1.fc5.x86_64 (11 days) lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 (15 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc (15 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 (15 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 (15 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc (15 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 (15 days) matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 (11 days) diradmin - 1.7.1-4.fc5.ppc (11 days) diradmin - 1.7.1-4.fc5.x86_64 (11 days) gtktalog - 1.0.4-7.fc5.i386 (11 days) gtktalog - 1.0.4-7.fc5.ppc (11 days) gtktalog - 1.0.4-7.fc5.x86_64 (11 days) mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 (11 days) gfontview - 0.5.0-5.fc5.ppc (11 days) gfontview - 0.5.0-5.fc5.x86_64 (11 days) gtkhtml36 - 3.6.2-5.fc6.i386 (11 days) gtkhtml36 - 3.6.2-5.fc6.ppc (11 days) gtkhtml36 - 3.6.2-5.fc6.x86_64 (11 days) libvisual-plugins - 0.2.0-3.fc5.i386 (11 days) libvisual-plugins - 0.2.0-3.fc5.i386 (11 days) libvisual-plugins - 0.2.0-3.fc5.ppc (11 days) libvisual-plugins - 0.2.0-3.fc5.ppc (11 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (11 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (11 days) nicolas.mailhot AT laposte.net lzop - 1.02-0.2.fc5.i386 lzop - 1.02-0.2.fc5.ppc lzop - 1.02-0.2.fc5.x86_64 oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (11 days) syck-php - 0.55-7.fc5.i386 (11 days) syck-php - 0.55-7.fc5.ppc (11 days) syck-php - 0.55-7.fc5.ppc (11 days) syck-php - 0.55-7.fc5.x86_64 (11 days) syck-php - 0.55-7.fc5.x86_64 (11 days) pertusus AT free.fr cernlib - 2005-21.fc6.ppc (11 days) cernlib-packlib - 2005-21.fc6.ppc (11 days) dap-hdf4_handler - 3.6.0-3.fc5.i386 (7 days) dap-hdf4_handler - 3.6.0-3.fc5.ppc (7 days) dap-hdf4_handler - 3.6.0-3.fc5.x86_64 (7 days) patchy - 2005-21.fc6.ppc (11 days) paw - 2005-21.fc6.ppc (11 days) rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 (11 days) libibverbs - 1.0.3-1.fc6.ppc (11 days) libibverbs - 1.0.3-1.fc6.x86_64 (11 days) libibverbs-utils - 1.0.3-1.fc6.i386 (11 days) libibverbs-utils - 1.0.3-1.fc6.ppc (11 days) libibverbs-utils - 1.0.3-1.fc6.x86_64 (11 days) steve AT silug.org openvpn - 2.1-0.10.beta14.fc6.i386 openvpn - 2.1-0.10.beta14.fc6.ppc openvpn - 2.1-0.10.beta14.fc6.x86_64 thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 (11 days) directfb - 0.9.24-5.fc5.ppc (11 days) directfb - 0.9.24-5.fc5.x86_64 (11 days) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.i386 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc5.x86_64 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.ppc requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.x86_64 requires python-protocols >= 0:1.0 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.ppc requires python-protocols >= 0:1.0 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok-1.4.1-3.fc6.i386 requires HelixPlayer azureus-2.4.0.3-0.20060328cvs_5.fc6.i386 requires libgcj.so.7 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 banshee-0.10.8-1.i386 requires libdbus-1.so.2 dap-hdf4_handler-3.6.0-3.fc5.i386 requires libdap.so.4 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 dxpc-3.8.2-3.fc5.2.i386 requires liblzo.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.i386 requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.i386 requires libdbus-1.so.2 gtkhtml36-3.6.2-5.fc6.i386 requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 jogl-1.1.1-14.fc5.i386 requires libgcj.so.7 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-qt-1.so.1 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.i386 requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 lzop-1.02-0.2.fc5.i386 requires liblzo.so.1 nautilus-search-tool-0.2-1.fc5.i386 requires libgailutil.so.17 openvpn-2.1-0.10.beta14.fc6.i386 requires liblzo.so.1 pdftk-1.12-6.fc5.i386 requires libgcj.so.7 rssowl-1.2-12.fc6.i386 requires libgcj.so.7 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- azureus-2.4.0.3-0.20060328cvs_5.fc6.x86_64 requires libgcj.so.7()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) banshee-0.10.8-1.x86_64 requires libdbus-1.so.2()(64bit) dap-hdf4_handler-3.6.0-3.fc5.x86_64 requires libdap.so.4()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) dxpc-3.8.2-3.fc5.2.x86_64 requires liblzo.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libgailutil.so.17()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) gtkhtml36-3.6.2-5.fc6.x86_64 requires libgailutil.so.17()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-qt-1.so.1()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-1.so.2()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libipoddevice-0.4.5-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) lzop-1.02-0.2.fc5.x86_64 requires liblzo.so.1()(64bit) nautilus-search-tool-0.2-1.fc5.x86_64 requires libgailutil.so.17()(64bit) openvpn-2.1-0.10.beta14.fc6.x86_64 requires liblzo.so.1()(64bit) pdftk-1.12-6.fc5.x86_64 requires libgcj.so.7()(64bit) rssowl-1.2-12.fc6.x86_64 requires libgcj.so.7()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 wine-core-0.9.17-1.fc6.i386 requires libglut.so.3 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok-1.4.1-3.fc6.ppc requires HelixPlayer azureus-2.4.0.3-0.20060328cvs_5.fc6.ppc requires libgcj.so.7 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 banshee-0.10.8-1.ppc requires libdbus-1.so.2 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 dap-hdf4_handler-3.6.0-3.fc5.ppc requires libdap.so.4 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 dxpc-3.8.2-3.fc5.2.ppc requires liblzo.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.ppc requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.ppc requires libdbus-1.so.2 gsynaptics-0.9.8-1.fc6.ppc requires synaptics gtkhtml36-3.6.2-5.fc6.ppc requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 jogl-1.1.1-14.fc5.ppc requires libgcj.so.7 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-qt-1.so.1 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.ppc requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 lzop-1.02-0.2.fc5.ppc requires liblzo.so.1 nautilus-search-tool-0.2-1.fc5.ppc requires libgailutil.so.17 openvpn-2.1-0.10.beta14.fc6.ppc requires liblzo.so.1 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 pdftk-1.12-6.fc5.ppc requires libgcj.so.7 rssowl-1.2-12.fc6.ppc requires libgcj.so.7 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 ====================================================================== New report for: extras-orphan AT fedoraproject.org package: dxpc - 3.8.2-3.fc5.2.i386 from fedora-extras-development-i386 unresolved deps: liblzo.so.1 package: dxpc - 3.8.2-3.fc5.2.x86_64 from fedora-extras-development-x86_64 unresolved deps: liblzo.so.1()(64bit) package: dxpc - 3.8.2-3.fc5.2.ppc from fedora-extras-development-ppc unresolved deps: liblzo.so.1 ====================================================================== New report for: steve AT silug.org package: openvpn - 2.1-0.10.beta14.fc6.i386 from fedora-extras-development-i386 unresolved deps: liblzo.so.1 package: openvpn - 2.1-0.10.beta14.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: liblzo.so.1()(64bit) package: openvpn - 2.1-0.10.beta14.fc6.ppc from fedora-extras-development-ppc unresolved deps: liblzo.so.1 ====================================================================== New report for: nicolas.mailhot AT laposte.net package: lzop - 1.02-0.2.fc5.i386 from fedora-extras-development-i386 unresolved deps: liblzo.so.1 package: lzop - 1.02-0.2.fc5.x86_64 from fedora-extras-development-x86_64 unresolved deps: liblzo.so.1()(64bit) package: lzop - 1.02-0.2.fc5.ppc from fedora-extras-development-ppc unresolved deps: liblzo.so.1 From wart at kobold.org Mon Jul 31 06:15:09 2006 From: wart at kobold.org (Wart) Date: Sun, 30 Jul 2006 23:15:09 -0700 Subject: desktop icons Message-ID: <44CD9FED.1050903@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What is the preferred directory for storing desktop icons? I've seen some packages use %{_datadir}/icons/hicolor/, while others put them in %{_datadir}/pixmaps. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEzZ/qDeYlPfs40g8RAjfNAJ9Y9hvsbw6Jy5XalubkikEh4rZcMACfajyE 3KD1zKUqYZLhW04hBgUM64Q= =K9Z/ -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Mon Jul 31 06:32:35 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 31 Jul 2006 08:32:35 +0200 Subject: desktop icons In-Reply-To: <44CD9FED.1050903@kobold.org> References: <44CD9FED.1050903@kobold.org> Message-ID: <44CDA403.8010107@hhs.nl> Wart wrote: > What is the preferred directory for storing desktop icons? I've seen > some packages use %{_datadir}/icons/hicolor/, while others put > them in %{_datadir}/pixmaps. > > --Mike According to the freedesktop.org icon standard it is %{_datadir}/icons/hicolor/, this is where all my packages put them and I've even blocked reviews on poluting /usr/share/pixmaps with icons (which will work too to support legacy apps). Regards, Hans From katzj at redhat.com Mon Jul 31 14:24:44 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 31 Jul 2006 10:24:44 -0400 Subject: questions about comps files In-Reply-To: <20060729093041.GA2701@free.fr> References: <20060729093041.GA2701@free.fr> Message-ID: <1154355884.20753.5.camel@orodruin.boston.redhat.com> On Sat, 2006-07-29 at 11:41 +0200, Patrice Dumas wrote: > Since it seems that that discussion should happen here, let's do it. > I have the following questions about the comps files: > > * the 'Authoring and Publishing' seems to be only for docbook from the > description. So where things like latex based packages, script converter > for other formats and so on (in my case, there is BibTool, tetex-tex4ht > and ooo2txt). And should script converters be in comps at all? LaTeX things have traditionally been in the Authoring and Publishing group as well. If there's a desire to get the description changed, propose something and I'm more than willing to make it more generic :) By script converters do you mean things like ooo2txt? I think if they're for common formats, having them in Authoring and Publishing could be okay... I'm not sure I'd put a Word Perfect 5.1 converter in there :-) > * where should wxWidgets based applications go (I maintain xchm). Look more at what the application does as opposed to what widget set it uses. > * should what is an end-user be dependent on the category? For example I > think that 'Engineering and Scientific' end users care about numerical > libraries, so it makes sense to have some libraries often used in > models or the like in that category. There is allready blas and lapack, > for example. Yeah, that isn't unreasonable > * does it makes sense to have some packages in more than one group? For > example I put grads is in 'Graphics', I think it also could be in > 'Engineering and Scientific'. The problem with doing so is that it can lead to a confusing UI in some cases. We've tried (hard) to get to where packages are only listed for one component. I'd like to try to stay there. > * where should things like esmtp (a relay-only Mail Transfer Agent) go? > There doesn't seems to be a category for that program, although it may > be interesting for some (advanced) end-users? There's the mail-server group :) Jeremy From katzj at redhat.com Mon Jul 31 14:25:07 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 31 Jul 2006 10:25:07 -0400 Subject: questions about comps files In-Reply-To: <20060729104748.GA5399@jadzia.bu.edu> References: <20060729093041.GA2701@free.fr> <20060729104748.GA5399@jadzia.bu.edu> Message-ID: <1154355908.20753.6.camel@orodruin.boston.redhat.com> On Sat, 2006-07-29 at 06:47 -0400, Matthew Miller wrote: > On Sat, Jul 29, 2006 at 11:41:47AM +0200, Patrice Dumas wrote: > > * should what is an end-user be dependent on the category? For example I > > think that 'Engineering and Scientific' end users care about numerical > > libraries, so it makes sense to have some libraries often used in > > models or the like in that category. There is allready blas and lapack, > > for example. > > For what it's worth, locally I change that group to "Engineering, Math, and > Science". The group could be changed... bugzilla is only a url away ;-) Jeremy From mattdm at mattdm.org Mon Jul 31 14:28:59 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 31 Jul 2006 10:28:59 -0400 Subject: questions about comps files In-Reply-To: <1154355884.20753.5.camel@orodruin.boston.redhat.com> References: <20060729093041.GA2701@free.fr> <1154355884.20753.5.camel@orodruin.boston.redhat.com> Message-ID: <20060731142859.GA8610@jadzia.bu.edu> On Mon, Jul 31, 2006 at 10:24:44AM -0400, Jeremy Katz wrote: > > Since it seems that that discussion should happen here, let's do it. > > I have the following questions about the comps files: > > * the 'Authoring and Publishing' seems to be only for docbook from the > > description. So where things like latex based packages, script converter > > for other formats and so on (in my case, there is BibTool, tetex-tex4ht > > and ooo2txt). And should script converters be in comps at all? > LaTeX things have traditionally been in the Authoring and Publishing > group as well. If there's a desire to get the description changed, > propose something and I'm more than willing to make it more generic :) "Text Processing?" I dunno. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nicolas.mailhot at laposte.net Mon Jul 31 14:43:41 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 31 Jul 2006 16:43:41 +0200 Subject: questions about comps files In-Reply-To: <20060731142859.GA8610@jadzia.bu.edu> References: <20060729093041.GA2701@free.fr> <1154355884.20753.5.camel@orodruin.boston.redhat.com> <20060731142859.GA8610@jadzia.bu.edu> Message-ID: <1154357021.24248.1.camel@rousalka.dyndns.org> Le lundi 31 juillet 2006 ? 10:28 -0400, Matthew Miller a ?crit : > On Mon, Jul 31, 2006 at 10:24:44AM -0400, Jeremy Katz wrote: > > LaTeX things have traditionally been in the Authoring and Publishing > > group as well. If there's a desire to get the description changed, > > propose something and I'm more than willing to make it more generic :) > > "Text Processing?" I dunno. Vade retro Satanas! Another one which has been subverted by the Word processing crowd Publishing >> Word processing :) -- 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 cweyl at alumni.drew.edu Mon Jul 31 15:15:05 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 31 Jul 2006 08:15:05 -0700 Subject: When to use perl(:WITH_...) requires? In-Reply-To: <7dd7ab490607290826q1edf8743n53d64909fd30f7f1@mail.gmail.com> References: <7dd7ab490607290826q1edf8743n53d64909fd30f7f1@mail.gmail.com> Message-ID: <7dd7ab490607310815w1aa3e160w21467dbdc8ec3a8d@mail.gmail.com> Hey all -- Perl provides a number of provides flags, e.g.: perl(:WITH_ITHREADS) perl(:WITH_LARGEFILES) perl(:WITH_PERLIO) perl(:WITH_THREADS) Most perl module spec files only deal with perl(:MODULE_COMPAT_5.8.8), etc. But I see a number of them (arch-specific, typically), do use these flags, along the lines of: Requires: %(perl -MConfig -le 'if (defined $Config{useithreads}) { print "perl(:WITH_ITHREADS)" } else { print "perl(:WITHOUT_ITHREADS)" }') etc, etc. So, when should a packager use these? Should lines along the one above be included for all flags in an arch-specific spec file? What's a good rule of thumb here? (And, are these flags documented anywhere? A cursory search of the wiki isn't turning up anything for me.) -Chris -- Chris Weyl Ex astris, scientia -- Chris Weyl Ex astris, scientia From buildsys at fedoraproject.org Mon Jul 31 15:38:32 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 31 Jul 2006 11:38:32 -0400 (EDT) Subject: Fedora Extras Package Build Report 2006-07-31 Message-ID: <20060731153832.3BD68152169@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 14 conntrack-1.0-0.1.beta2.fc5 ganymed-ssh2-209-5.fc5 gnupg2-1.9.22-1.fc5 gsynaptics-0.9.8-1.fc5 htop-0.6.3-1.fc5 javasvn-1.0.6-2.fc5 kadu-0.5.0-0.6.20060730svn.fc5 krusader-1.70.1-1.fc5 nomarch-1.4-1.fc5 perl-Font-TTF-0.38.1-1.fc5 perl-Net-Server-0.94-1.fc5 pgadmin3-1.4.3-2.fc5 plotmm-0.1.2-4.fc5 rbldnsd-0.996a-1.fc5 Packages built and released for Fedora Extras 4: 10 gnupg2-1.9.22-1.fc4 htop-0.6.3-1.fc4 octave-2.9.7-1.fc4 octave-forge-2006.07.09-3.fc4 perl-Image-Info-1.22-1.fc4 pgadmin3-1.4.3-2.fc4 rbldnsd-0.996a-1.fc4 scim-anthy-1.2.0-1.fc4 workrave-1.8.3-1.fc4.2 xfce4-weather-plugin-0.4.9-6.fc4 Packages built and released for Fedora Extras development: 20 audacious-1.1.1-3.fc6 dejavu-fonts-2.8.0-2.fc6 dxpc-3.9.0-1.fc6 eric-3.9.1-2.fc6 htop-0.6.3-1.fc6 jogl-1.0.0-5.0.beta5.fc6 kadu-0.5.0-0.6.20060730svn.fc6 kanatest-0.3.6-5.fc6 krusader-1.70.1-1.fc6 lzop-1.02-0.3.rc1.fc6 nomarch-1.4-1.fc6 perl-Font-TTF-0.40.0-1.fc6 perl-Net-Server-0.94-1.fc6 plotmm-0.1.2-4.fc6 prboom-2.4.4-1.fc6 python-formencode-0.5.1-2.fc6 rbldnsd-0.996a-1.fc6 sylpheed-2.2.7-1.fc6 sysconftool-0.15-2.fc6 yum-utils-0.6-4.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Jul 31 15:39:04 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 31 Jul 2006 11:39:04 -0400 (EDT) Subject: Broken upgrade paths in FC+FE 2006-07-31 Message-ID: <20060731153904.2D1BD152169@buildsys.fedoraproject.org> azureus: green AT redhat.com 5: 0:2.4.0.3-0.20060529cvs_1.fc5 (FE5) 6: 0:2.4.0.3-0.20060328cvs_5.fc6 (FE6) banshee: caillon AT redhat.com 5: 0:0.10.9-1..fc5 (FE5) 6: 0:0.10.8-1 (FE6) camE: matthias AT rpmforge.net 5: 0:1.9-6.fc5 (FE5) 6: 0:1.9-5.fc5 (FE6) camstream: nomis80 AT nomis80.org 5: 0:0.26.3-10.fc5 (FE5) 6: 0:0.26.3-9.fc5 (FE6) dclib: lmacken AT redhat.com 5: 0:0.3.7-8.fc5 (FE5) 6: 0:0.3.7-7.fc6 (FE6) device-mapper: 4: 0:1.02.07-2.0 (FC4-updates) 5: 0:1.02.02-3.2 (FC5) 6: 0:1.02.07-1.1 (FC6) dillo: andreas.bierfert AT lowlatency.de 4: 0:0.8.6-2.fc4 (FE4) 5: 0:0.8.6-1.fc5 (FE5) 6: 0:0.8.6-2.fc6 (FE6) firestarter: mpeters AT mac.com 5: 0:1.0.3-11.fc5 (FE5) 6: 0:1.0.3-10.fc6 (FE6) fish: oliver AT linux-kernel.at 4: 0:1.14.0-1.fc4 (FE4) 5: 0:1.12.0-1.fc5 (FE5) 6: 0:1.12.0-1.fc5 (FE6) flumotion: thomas AT apestaart.org 5: 0:0.2.1-2.fc5 (FE5) 6: 0:0.2.0-1.fc5 (FE6) fortune-firefly: meme AT daughtersoftiresias.org 5: 0:2.1.1-2.fc5 (FE5) 6: 0:2.1.1-1.fc6 (FE6) fuse-encfs: lemenkov AT newmail.ru 5: 0:1.3.1-1.fc5 (FE5) 6: 0:1.3.0-1.fc6 (FE6) fuse-sshfs: lemenkov AT newmail.ru 5: 0:1.6-3.fc5 (FE5) 6: 0:1.6-2.fc6 (FE6) gaim-gaym: cweyl AT alumni.drew.edu 5: 0:0.96-3.fc5 (FE5) 6: 0:0.96-2.fc6 (FE6) gauche-gl: gemi AT bluewin.ch 5: 0:0.4.1-5.fc5 (FE5) 6: 0:0.4.1-4.fc6 (FE6) gcdmaster: denis AT poolshark.org 4: 0:1.2.1-5.fc4 (FE4) 5: 0:1.2.1-4.fc5 (FE5) 6: 0:1.2.1-4.fc5 (FE6) gdesklets: luya256 AT yahoo.com 4: 0:0.35.3-8.1.fc4 (FE4) 5: 0:0.35.3-8.fc5 (FE5) 6: 0:0.35.3-8.fc6 (FE6) git: chrisw AT redhat.com 3: 0:1.4.1-1.fc3 (FE3) 4: 0:1.4.0-1.fc4 (FE4) 5: 0:1.4.0-1.fc5 (FE5) 6: 0:1.4.1-1.fc6 (FE6) inkscape: denis AT poolshark.org 4: 0:0.44-3.fc4 (FE4) 5: 0:0.44-2.fc5 (FE5) 6: 0:0.44-2.fc6 (FE6) istanbul: jspaleta AT gmail.com 5: 0:0.1.1-9.fc5 (FE5) 6: 0:0.1.1-9 (FE6) libnasl: andreas.bierfert AT lowlatency.de 5: 0:2.2.8-1.fc5 (FE5) 6: 0:2.2.7-1.fc6 (FE6) libopensync-plugin-evolution2: andreas.bierfert AT lowlatency.de 5: 0:0.18-7.fc5 (FE5) 6: 0:0.18-6.fc5 (FE6) lvm2: 4: 0:2.02.06-1.0.fc4 (FC4-updates) 5: 0:2.02.01-1.2.1 (FC5) 6: 0:2.02.06-2 (FC6) m17n-db: petersen AT redhat.com 4: 0:1.3.3-1.fc4 (FE4) 5: 0:1.3.3-1 (FC5) 6: 0:1.3.3-14.fc6 (FC6) mozilla: 3: 37:1.7.13-1.3.1.legacy (FL3-updates) 4: 37:1.7.13-1.1.fc4 (FC4-updates) 5: 37:1.7.13-1.1.fc5 (FC5-updates) 6: 37:1.7.13-1.1.fc5 (FC6) octave: qspencer AT ieee.org 4: 6:2.9.7-1.fc4 (FE4) 5: 6:2.9.6-1.fc5 (FE5) 6: 6:2.9.7-1.fc6 (FE6) octave-forge: qspencer AT ieee.org 4: 0:2006.07.09-3.fc4 (FE4) 5: 0:2006.07.09-2.fc5 (FE5) 6: 0:2006.07.09-3.fc6 (FE6) opencv: nomis80 AT nomis80.org 5: 0:0.9.7-16.fc5 (FE5) 6: 0:0.9.7-15.fc5 (FE6) perl-String-CRC32: paul AT city-fan.org 4: 0:1.4-1.fc4 (FE4) 5: 0:1.4-1.FC5 (FC5-updates) 6: 0:1.4-1.FC6.1 (FC6) pgadmin3: ghenry AT suretecsystems.com 5: 0:1.4.3-2.fc5 (FE5) 6: 0:1.4.1-2.fc5 (FE6) php-pear-DB: rpm AT timj.co.uk 5: 0:1.7.6-6.fc5 (FE5) 6: 0:1.7.6-6 (FE6) python-myghty: lmacken AT redhat.com 5: 0:1.0.1-2.fc5 (FE5) 6: 0:1.0.1-1.fc5 (FE6) quagga: 4: 0:0.98.6-1.fc4 (FC4-updates) 5: 0:0.98.6-1.FC5 (FC5-updates) 6: 0:0.98.6-2.1 (FC6) rssowl: green AT redhat.com 5: 0:1.2.1-2.fc5 (FE5) 6: 0:1.2-12.fc6 (FE6) scim-anthy: tagoh AT redhat.com 4: 0:1.2.0-1.fc4 (FE4) 5: 0:1.0.0-1.fc5.1 (FC5-updates) 6: 0:1.0.0-4.fc6 (FC6) scim-tomoe: ryo-dairiki AT users.sourceforge.net 5: 0:0.2.0-6.fc5 (FE5) 6: 0:0.2.0-4.fc6 (FE6) scons: gemi AT bluewin.ch 5: 0:0.96.1-2.fc5 (FE5) 6: 0:0.96.1-1.fc6 (FE6) serpentine: foolish AT guezz.net 5: 0:0.7-4.fc5 (FE5) 6: 0:0.7-3.fc6 (FE6) smart: Axel.Thimm AT ATrpms.net 5: 0:0.42-34.fc5 (FE5) 6: 0:0.41-31.fc6 (FE6) stratagus: lemenkov AT newmail.ru 5: 0:2.1-6.fc5 (FE5) 6: 0:2.1-5.fc6 (FE6) TeXmacs: gemi AT bluewin.ch 5: 0:1.0.6.4-1.fc5 (FE5) 6: 0:1.0.6.3-1.fc6 (FE6) valknut: lmacken AT redhat.com 5: 0:0.3.7-9.fc5 (FE5) 6: 0:0.3.7-8.fc6 (FE6) wine-docs: andreas.bierfert AT lowlatency.de 3: 0:0.9.17-1.fc3 (FE3) 4: 0:0.9.17-0.1.fc4 (FE4) 5: 0:0.9.17-1.fc5 (FE5) 6: 0:0.9.17-1.fc6 (FE6) xorg-x11-drv-nv: 5: 0:1.2.0-3.fc5 (FC5-updates) 6: 0:1.2.0-2.fc6 (FC6) From liljencrantz at gmail.com Mon Jul 31 15:41:51 2006 From: liljencrantz at gmail.com (Axel Liljencrantz) Date: Mon, 31 Jul 2006 17:41:51 +0200 Subject: Update of the fish package Message-ID: <7dad0d770607310841y221983adoc26bde09b3088013@mail.gmail.com> Hi The version of fish in Fedora extras is pretty out of date. To make things worse, fedora 4 has a more recent fish version than fedora 5/6, causing upgrade troubles. There are source rpms for fish available at the main fish site, http://roo.no-ip.org/fish. Specifically, the latest fish version is http://roo.no-ip.org/fish/files/1.21.10/fish-1.21.10-0.src.rpm. This source rpm compiles under both fedora 4 and fedora 5, and fixes various bugs in the fish versions available in extras today. Would someone with commit rights consider uploading this to Extras? -- Axel From paul at city-fan.org Mon Jul 31 15:52:25 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 31 Jul 2006 16:52:25 +0100 Subject: Broken upgrade paths in FC+FE 2006-07-31 In-Reply-To: <20060731153904.2D1BD152169@buildsys.fedoraproject.org> References: <20060731153904.2D1BD152169@buildsys.fedoraproject.org> Message-ID: <44CE2739.8080805@city-fan.org> buildsys at fedoraproject.org wrote: > perl-String-CRC32: paul AT city-fan.org > 4: 0:1.4-1.fc4 (FE4) > 5: 0:1.4-1.FC5 (FC5-updates) > 6: 0:1.4-1.FC6.1 (FC6) Shouldn't the email address attached to the report be the one for the person that needs to do something to fix this (in this case, the maintainer of the package for FC5-updates and FC6) rather than the person that caused the breakage (i.e. me, maintainer for FE4 :-( )? Paul. From buildsys at fedoraproject.org Mon Jul 31 15:56:46 2006 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 31 Jul 2006 15:56:46 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2006-07-31 Message-ID: <20060731155646.21625.57459@extras64.linux.duke.edu> Summary of broken packages (by owner): ---------------------------------------------------------------------- Jochen AT herr-schmitt.de pdftk - 1.12-6.fc5.i386 (5 days) pdftk - 1.12-6.fc5.ppc (5 days) pdftk - 1.12-6.fc5.x86_64 (5 days) andreas.bierfert AT lowlatency.de fluxbox - 0.9.15.1-1.fc3.i386 (116 days) fluxbox - 0.9.15.1-1.fc3.x86_64 (116 days) wine-core - 0.9.17-1.fc6.i386 (5 days) byte AT fedoraproject.org gaim-guifications - 2.12-3.fc5.i386 (12 days) gaim-guifications - 2.12-3.fc5.ppc (12 days) gaim-guifications - 2.12-3.fc5.x86_64 (12 days) caillon AT redhat.com banshee - 0.10.8-1.i386 (12 days) banshee - 0.10.8-1.ppc (12 days) banshee - 0.10.8-1.x86_64 (12 days) libipoddevice - 0.4.5-1.fc6.i386 (11 days) libipoddevice - 0.4.5-1.fc6.ppc (11 days) libipoddevice - 0.4.5-1.fc6.x86_64 (11 days) cweyl AT alumni.drew.edu gaim-gaym - 0.96-2.fc6.i386 (12 days) gaim-gaym - 0.96-2.fc6.ppc (12 days) gaim-gaym - 0.96-2.fc6.x86_64 (12 days) dennis AT ausil.us knetworkmanager - 0.1-0.3.svn20060625.fc6.i386 (11 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.ppc (11 days) knetworkmanager - 0.1-0.3.svn20060625.fc6.x86_64 (11 days) fedora AT leemhuis.info gsynaptics - 0.9.8-1.fc6.ppc (12 days) gauret AT free.fr amarok - 1.4.1-3.fc6.i386 (4 days) amarok - 1.4.1-3.fc6.ppc (4 days) green AT redhat.com azureus - 2.4.0.3-0.20060328cvs_5.fc6.i386 (5 days) azureus - 2.4.0.3-0.20060328cvs_5.fc6.ppc (5 days) azureus - 2.4.0.3-0.20060328cvs_5.fc6.x86_64 (5 days) jogl - 1.1.1-14.fc5.ppc (8 days) rssowl - 1.2-12.fc6.i386 (5 days) rssowl - 1.2-12.fc6.ppc (5 days) rssowl - 1.2-12.fc6.x86_64 (5 days) ivazquez AT ivazquez.net gnome-applet-music - 0.9.0-1.fc6.i386 (12 days) gnome-applet-music - 0.9.0-1.fc6.ppc (12 days) gnome-applet-music - 0.9.0-1.fc6.x86_64 (12 days) nautilus-search-tool - 0.2-1.fc5.i386 (12 days) nautilus-search-tool - 0.2-1.fc5.ppc (12 days) nautilus-search-tool - 0.2-1.fc5.x86_64 (12 days) lmacken AT redhat.com python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.i386 (16 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.ppc (16 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc4.x86_64 (16 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.i386 (16 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.ppc (16 days) python-ruledispatch - 0.5a0-0.1.svnr2115.fc5.x86_64 (16 days) matthias AT rpmforge.net diradmin - 1.7.1-4.fc5.i386 (12 days) diradmin - 1.7.1-4.fc5.ppc (12 days) diradmin - 1.7.1-4.fc5.x86_64 (12 days) gtktalog - 1.0.4-7.fc5.i386 (12 days) gtktalog - 1.0.4-7.fc5.ppc (12 days) gtktalog - 1.0.4-7.fc5.x86_64 (12 days) mpeters AT mac.com gfontview - 0.5.0-5.fc5.i386 (12 days) gfontview - 0.5.0-5.fc5.ppc (12 days) gfontview - 0.5.0-5.fc5.x86_64 (12 days) gtkhtml36 - 3.6.2-5.fc6.i386 (12 days) gtkhtml36 - 3.6.2-5.fc6.ppc (12 days) gtkhtml36 - 3.6.2-5.fc6.x86_64 (12 days) libvisual-plugins - 0.2.0-3.fc5.i386 (12 days) libvisual-plugins - 0.2.0-3.fc5.i386 (12 days) libvisual-plugins - 0.2.0-3.fc5.ppc (12 days) libvisual-plugins - 0.2.0-3.fc5.ppc (12 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (12 days) libvisual-plugins - 0.2.0-3.fc5.x86_64 (12 days) oliver AT linux-kernel.at syck-php - 0.55-7.fc5.i386 (12 days) syck-php - 0.55-7.fc5.i386 (12 days) syck-php - 0.55-7.fc5.ppc (12 days) syck-php - 0.55-7.fc5.ppc (12 days) syck-php - 0.55-7.fc5.x86_64 (12 days) syck-php - 0.55-7.fc5.x86_64 (12 days) pertusus AT free.fr cernlib - 2005-21.fc6.ppc (12 days) cernlib-packlib - 2005-21.fc6.ppc (12 days) dap-hdf4_handler - 3.6.0-3.fc5.i386 (8 days) dap-hdf4_handler - 3.6.0-3.fc5.ppc (8 days) dap-hdf4_handler - 3.6.0-3.fc5.x86_64 (8 days) patchy - 2005-21.fc6.ppc (12 days) paw - 2005-21.fc6.ppc (12 days) rolandd AT cisco.com libibverbs - 1.0.3-1.fc6.i386 (12 days) libibverbs - 1.0.3-1.fc6.ppc (12 days) libibverbs - 1.0.3-1.fc6.x86_64 (12 days) libibverbs-utils - 1.0.3-1.fc6.i386 (12 days) libibverbs-utils - 1.0.3-1.fc6.ppc (12 days) libibverbs-utils - 1.0.3-1.fc6.x86_64 (12 days) steve AT silug.org openvpn - 2.1-0.10.beta14.fc6.i386 openvpn - 2.1-0.10.beta14.fc6.ppc openvpn - 2.1-0.10.beta14.fc6.x86_64 thomas AT apestaart.org directfb - 0.9.24-5.fc5.i386 (12 days) directfb - 0.9.24-5.fc5.ppc (12 days) directfb - 0.9.24-5.fc5.x86_64 (12 days) Broken packages in fedora-extras-5-i386: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.i386 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Broken packages in fedora-extras-5-x86_64: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) python-ruledispatch-0.5a0-0.1.svnr2115.fc5.x86_64 requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 Broken packages in fedora-extras-5-ppc: ---------------------------------------------------------------------- libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 python-ruledispatch-0.5a0-0.1.svnr2115.fc5.ppc requires python-protocols >= 0:1.0 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 Broken packages in fedora-extras-4-i386: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 Broken packages in fedora-extras-4-x86_64: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.x86_64 requires python-protocols >= 0:1.0 Broken packages in fedora-extras-4-ppc: ---------------------------------------------------------------------- python-ruledispatch-0.5a0-0.1.svnr2115.fc4.ppc requires python-protocols >= 0:1.0 Broken packages in fedora-extras-3-i386: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.i386 requires pyxdg Broken packages in fedora-extras-3-x86_64: ---------------------------------------------------------------------- fluxbox-0.9.15.1-1.fc3.x86_64 requires pyxdg Broken packages in fedora-extras-development-i386: ---------------------------------------------------------------------- amarok-1.4.1-3.fc6.i386 requires HelixPlayer azureus-2.4.0.3-0.20060328cvs_5.fc6.i386 requires libgcj.so.7 banshee-0.10.8-1.i386 requires libnautilus-burn.so.3 banshee-0.10.8-1.i386 requires libdbus-1.so.2 dap-hdf4_handler-3.6.0-3.fc5.i386 requires libdap.so.4 diradmin-1.7.1-4.fc5.i386 requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.i386 requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.i386 requires libgnome.so.32 diradmin-1.7.1-4.fc5.i386 requires libgnomeui.so.32 directfb-0.9.24-5.fc5.i386 requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.i386 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.i386 requires gaim < 1:2 gfontview-0.5.0-5.fc5.i386 requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.i386 requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.i386 requires libdbus-1.so.2 gtkhtml36-3.6.2-5.fc6.i386 requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.i386 requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.i386 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.i386 requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.i386 requires libgnome.so.32 gtktalog-1.0.4-7.fc5.i386 requires libgnomeui.so.32 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.i386 requires libdbus-qt-1.so.1 libibverbs-1.0.3-1.fc6.i386 requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.i386 requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.i386 requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.i386 requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.i386 requires libgailutil.so.17 openvpn-2.1-0.10.beta14.fc6.i386 requires liblzo.so.1 pdftk-1.12-6.fc5.i386 requires libgcj.so.7 rssowl-1.2-12.fc6.i386 requires libgcj.so.7 syck-php-0.55-7.fc5.i386 requires php = 0:5.1.2 Broken packages in fedora-extras-development-x86_64: ---------------------------------------------------------------------- azureus-2.4.0.3-0.20060328cvs_5.fc6.x86_64 requires libgcj.so.7()(64bit) banshee-0.10.8-1.x86_64 requires libnautilus-burn.so.3()(64bit) banshee-0.10.8-1.x86_64 requires libdbus-1.so.2()(64bit) dap-hdf4_handler-3.6.0-3.fc5.x86_64 requires libdap.so.4()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomesupport.so.0()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libart_lgpl.so.2()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnome.so.32()(64bit) diradmin-1.7.1-4.fc5.x86_64 requires libgnomeui.so.32()(64bit) directfb-0.9.24-5.fc5.x86_64 requires libsysfs.so.1()(64bit) gaim-gaym-0.96-2.fc6.x86_64 requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.x86_64 requires gaim < 1:2 gfontview-0.5.0-5.fc5.x86_64 requires libttf.so.2()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libgailutil.so.17()(64bit) gnome-applet-music-0.9.0-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) gtkhtml36-3.6.2-5.fc6.x86_64 requires libgailutil.so.17()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomesupport.so.0()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.x86_64 requires libart_lgpl.so.2()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnome.so.32()(64bit) gtktalog-1.0.4-7.fc5.x86_64 requires libgnomeui.so.32()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-qt-1.so.1()(64bit) knetworkmanager-0.1-0.3.svn20060625.fc6.x86_64 requires libdbus-1.so.2()(64bit) libibverbs-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libibverbs-utils-1.0.3-1.fc6.x86_64 requires libsysfs.so.1()(64bit) libipoddevice-0.4.5-1.fc6.x86_64 requires libdbus-1.so.2()(64bit) libvisual-plugins-0.2.0-3.fc5.x86_64 requires libvisual.so.0()(64bit) nautilus-search-tool-0.2-1.fc5.x86_64 requires libgailutil.so.17()(64bit) openvpn-2.1-0.10.beta14.fc6.x86_64 requires liblzo.so.1()(64bit) pdftk-1.12-6.fc5.x86_64 requires libgcj.so.7()(64bit) rssowl-1.2-12.fc6.x86_64 requires libgcj.so.7()(64bit) syck-php-0.55-7.fc5.x86_64 requires php = 0:5.1.2 wine-core-0.9.17-1.fc6.i386 requires libglut.so.3 Broken packages in fedora-extras-development-ppc: ---------------------------------------------------------------------- amarok-1.4.1-3.fc6.ppc requires HelixPlayer azureus-2.4.0.3-0.20060328cvs_5.fc6.ppc requires libgcj.so.7 banshee-0.10.8-1.ppc requires libnautilus-burn.so.3 banshee-0.10.8-1.ppc requires libdbus-1.so.2 cernlib-2005-21.fc6.ppc requires libg2c.so.0 cernlib-packlib-2005-21.fc6.ppc requires libg2c.so.0 dap-hdf4_handler-3.6.0-3.fc5.ppc requires libdap.so.4 diradmin-1.7.1-4.fc5.ppc requires libgnomesupport.so.0 diradmin-1.7.1-4.fc5.ppc requires libart_lgpl.so.2 diradmin-1.7.1-4.fc5.ppc requires libgnome.so.32 diradmin-1.7.1-4.fc5.ppc requires libgnomeui.so.32 directfb-0.9.24-5.fc5.ppc requires libsysfs.so.1 gaim-gaym-0.96-2.fc6.ppc requires gaim < 1:2.0.0 gaim-guifications-2.12-3.fc5.ppc requires gaim < 1:2 gfontview-0.5.0-5.fc5.ppc requires libttf.so.2 gnome-applet-music-0.9.0-1.fc6.ppc requires libgailutil.so.17 gnome-applet-music-0.9.0-1.fc6.ppc requires libdbus-1.so.2 gsynaptics-0.9.8-1.fc6.ppc requires synaptics gtkhtml36-3.6.2-5.fc6.ppc requires libgailutil.so.17 gtktalog-1.0.4-7.fc5.ppc requires libart_lgpl.so.2 gtktalog-1.0.4-7.fc5.ppc requires gnome-libs >= 0:1.2 gtktalog-1.0.4-7.fc5.ppc requires libgnomesupport.so.0 gtktalog-1.0.4-7.fc5.ppc requires libgnome.so.32 gtktalog-1.0.4-7.fc5.ppc requires libgnomeui.so.32 jogl-1.1.1-14.fc5.ppc requires libgcj.so.7 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-1.so.2 knetworkmanager-0.1-0.3.svn20060625.fc6.ppc requires libdbus-qt-1.so.1 libibverbs-1.0.3-1.fc6.ppc requires libsysfs.so.1 libibverbs-utils-1.0.3-1.fc6.ppc requires libsysfs.so.1 libipoddevice-0.4.5-1.fc6.ppc requires libdbus-1.so.2 libvisual-plugins-0.2.0-3.fc5.ppc requires libvisual.so.0 nautilus-search-tool-0.2-1.fc5.ppc requires libgailutil.so.17 openvpn-2.1-0.10.beta14.fc6.ppc requires liblzo.so.1 patchy-2005-21.fc6.ppc requires libg2c.so.0 paw-2005-21.fc6.ppc requires libg2c.so.0 pdftk-1.12-6.fc5.ppc requires libgcj.so.7 rssowl-1.2-12.fc6.ppc requires libgcj.so.7 syck-php-0.55-7.fc5.ppc requires php = 0:5.1.2 From notting at redhat.com Mon Jul 31 15:59:16 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 31 Jul 2006 11:59:16 -0400 Subject: questions about comps files In-Reply-To: <20060729093041.GA2701@free.fr> References: <20060729093041.GA2701@free.fr> Message-ID: <20060731155916.GA31165@localhost.localdomain> Patrice Dumas (pertusus at free.fr) said: > Since it seems that that discussion should happen here, let's do it. > I have the following questions about the comps files: > > * the 'Authoring and Publishing' seems to be only for docbook from the > description. So where things like latex based packages, script converter > for other formats and so on (in my case, there is BibTool, tetex-tex4ht > and ooo2txt). And should script converters be in comps at all? Generally, it dependns on what they're used for. I could see TeX based stuff in Authoring & Publishing, although there's an overlap with office suites there, depending on how you're using TeX. > * where should wxWidgets based applications go (I maintain xchm). wxWidgets (should be) irrelevant - it's what the app does, not what it's built against. > * does it makes sense to have some packages in more than one group? For > example I put grads is in 'Graphics', I think it also could be in > 'Engineering and Scientific'. Probably best to keep them in single groups - Graphics is more for drawing things & photos (gimp, inkspace, etc.) > * where should things like esmtp (a relay-only Mail Transfer Agent) go? > There doesn't seems to be a category for that program, although it may > be interesting for some (advanced) end-users? Mail servers? Bill From paul at city-fan.org Mon Jul 31 16:10:07 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 31 Jul 2006 17:10:07 +0100 Subject: Update of the fish package In-Reply-To: <7dad0d770607310841y221983adoc26bde09b3088013@mail.gmail.com> References: <7dad0d770607310841y221983adoc26bde09b3088013@mail.gmail.com> Message-ID: <44CE2B5F.6010405@city-fan.org> Axel Liljencrantz wrote: > Hi > > The version of fish in Fedora extras is pretty out of date. To make > things worse, fedora 4 has a more recent fish version than fedora 5/6, > causing upgrade troubles. There are source rpms for fish available at > the main fish site, http://roo.no-ip.org/fish. Specifically, the > latest fish version is > http://roo.no-ip.org/fish/files/1.21.10/fish-1.21.10-0.src.rpm. This > source rpm compiles under both fedora 4 and fedora 5, and fixes > various bugs in the fish versions available in extras today. > > Would someone with commit rights consider uploading this to Extras? You might want to be the first to try out the AWOL maintainers procedure: http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers Paul. From bugs.michael at gmx.net Mon Jul 31 16:38:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 31 Jul 2006 18:38:24 +0200 Subject: Broken upgrade paths in FC+FE 2006-07-31 In-Reply-To: <44CE2739.8080805@city-fan.org> References: <20060731153904.2D1BD152169@buildsys.fedoraproject.org> <44CE2739.8080805@city-fan.org> Message-ID: <20060731183824.83930498.bugs.michael@gmx.net> On Mon, 31 Jul 2006 16:52:25 +0100, Paul Howarth wrote: > buildsys at fedoraproject.org wrote: > > perl-String-CRC32: paul AT city-fan.org > > 4: 0:1.4-1.fc4 (FE4) > > 5: 0:1.4-1.FC5 (FC5-updates) > > 6: 0:1.4-1.FC6.1 (FC6) > > Shouldn't the email address attached to the report be the one for the > person that needs to do something to fix this (in this case, the > maintainer of the package for FC5-updates and FC6) rather than the > person that caused the breakage (i.e. me, maintainer for FE4 :-( )? Even with a complete package database (which we could query on "package owner(s) per package _per dist_", it would not be bullet-proof either and would require additional logic in its implementation. In above case: 1.4-1.FC5 is lower than 1.4-1.fc4 Maybe the package was moved from Extras into Core, and the Core packager chose an incompatible dist tag. The script cannot know that. Compare with the following scenario: 4: 0:1.4-2.fc4 (FE4) 5: 0:1.4-1.fc5 (FC5-updates) 6: 0:1.4-1.fc6 (FC6) Who is to blame now? The FE4 package owner for releasing something that's higher than FC5/FC6? Or the FC5/FC6 package owner for a missing update? The script could only guess. The script could report to all package owners involved. Anyway, we cannot do much about it without a complete package database. Extracting package owners from Core bugzilla (Components list) returns also some mailing-lists. From bugs.michael at gmx.net Mon Jul 31 16:41:23 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 31 Jul 2006 18:41:23 +0200 Subject: Update of the fish package In-Reply-To: <44CE2B5F.6010405@city-fan.org> References: <7dad0d770607310841y221983adoc26bde09b3088013@mail.gmail.com> <44CE2B5F.6010405@city-fan.org> Message-ID: <20060731184123.21c5a5d3.bugs.michael@gmx.net> On Mon, 31 Jul 2006 17:10:07 +0100, Paul Howarth wrote: > Axel Liljencrantz wrote: > > Hi > > > > The version of fish in Fedora extras is pretty out of date. To make > > things worse, fedora 4 has a more recent fish version than fedora 5/6, > > causing upgrade troubles. There are source rpms for fish available at > > the main fish site, http://roo.no-ip.org/fish. Specifically, the > > latest fish version is > > http://roo.no-ip.org/fish/files/1.21.10/fish-1.21.10-0.src.rpm. This > > source rpm compiles under both fedora 4 and fedora 5, and fixes > > various bugs in the fish versions available in extras today. > > > > Would someone with commit rights consider uploading this to Extras? > > You might want to be the first to try out the AWOL maintainers procedure: > > http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers Actually, Axel and Oliver are supposed to be working together, since if my memory serves correctly, Oliver only served as a proxy into FE CVS for Axel. But this is not the first time this method has failed. I don't know, however, how both have decided to communicate about updates. How about signing up as a Fedora Extras Contributor? From paul at city-fan.org Mon Jul 31 16:50:14 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 31 Jul 2006 17:50:14 +0100 Subject: Broken upgrade paths in FC+FE 2006-07-31 In-Reply-To: <20060731183824.83930498.bugs.michael@gmx.net> References: <20060731153904.2D1BD152169@buildsys.fedoraproject.org> <44CE2739.8080805@city-fan.org> <20060731183824.83930498.bugs.michael@gmx.net> Message-ID: <44CE34C6.8010709@city-fan.org> Michael Schwendt wrote: > On Mon, 31 Jul 2006 16:52:25 +0100, Paul Howarth wrote: > >> buildsys at fedoraproject.org wrote: >>> perl-String-CRC32: paul AT city-fan.org >>> 4: 0:1.4-1.fc4 (FE4) >>> 5: 0:1.4-1.FC5 (FC5-updates) >>> 6: 0:1.4-1.FC6.1 (FC6) >> Shouldn't the email address attached to the report be the one for the >> person that needs to do something to fix this (in this case, the >> maintainer of the package for FC5-updates and FC6) rather than the >> person that caused the breakage (i.e. me, maintainer for FE4 :-( )? > > Even with a complete package database (which we could query on "package > owner(s) per package _per dist_", it would not be bullet-proof either and > would require additional logic in its implementation. > > In above case: > > 1.4-1.FC5 is lower than 1.4-1.fc4 > > Maybe the package was moved from Extras into Core, and the Core packager > chose an incompatible dist tag. The script cannot know that. That's quite close to what actually happened, though in fact the package was in FC5 before it was in FE4. > Compare with the following scenario: > > 4: 0:1.4-2.fc4 (FE4) > 5: 0:1.4-1.fc5 (FC5-updates) > 6: 0:1.4-1.fc6 (FC6) > > Who is to blame now? The FE4 package owner for releasing something that's > higher than FC5/FC6? Or the FC5/FC6 package owner for a missing update? > > The script could only guess. I don't think it's a "blame" thing, it's a "who needs to do something to fix it" thing. So that would be the maintainer for each version for which there is a version with a higher EVR for an older distro. > The script could report to all package owners involved. Anyway, we > cannot do much about it without a complete package database. Extracting > package owners from Core bugzilla (Components list) returns also some > mailing-lists. Roll on the package database then. Paul. From sundaram at fedoraproject.org Mon Jul 31 17:30:26 2006 From: sundaram at fedoraproject.org (Rahul) Date: Mon, 31 Jul 2006 23:00:26 +0530 Subject: Update of the fish package In-Reply-To: <7dad0d770607310841y221983adoc26bde09b3088013@mail.gmail.com> References: <7dad0d770607310841y221983adoc26bde09b3088013@mail.gmail.com> Message-ID: <44CE3E32.1010408@fedoraproject.org> Axel Liljencrantz wrote: > Hi > > The version of fish in Fedora extras is pretty out of date. To make > things worse, fedora 4 has a more recent fish version than fedora 5/6, > causing upgrade troubles. There are source rpms for fish available at > the main fish site, http://roo.no-ip.org/fish. Specifically, the > latest fish version is > http://roo.no-ip.org/fish/files/1.21.10/fish-1.21.10-0.src.rpm. This > source rpm compiles under both fedora 4 and fedora 5, and fixes > various bugs in the fish versions available in extras today. > > Would someone with commit rights consider uploading this to Extras? > We cant just build a random package into extras. It would be better to file a request to update in http://bugzilla.redhat.com against the specific package in Fedora Extras. Rahul From denis at poolshark.org Mon Jul 31 17:34:44 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 31 Jul 2006 19:34:44 +0200 Subject: wp_tray ownership Message-ID: <44CE3F34.1060005@poolshark.org> As per the AWOL guidelines, and since this has been over 3 weeks now, I'd like to formally request a takeover of this package. I have not been able to contact the maintainer. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196911 The next step is: "If atleast one FESco member approves the take over and no one objects within 3 days, you may take over the package." -denis From jwboyer at jdub.homelinux.org Mon Jul 31 17:53:37 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 31 Jul 2006 12:53:37 -0500 Subject: wp_tray ownership In-Reply-To: <44CE3F34.1060005@poolshark.org> References: <44CE3F34.1060005@poolshark.org> Message-ID: <1154368417.29112.2.camel@weaponx.rchland.ibm.com> On Mon, 2006-07-31 at 19:34 +0200, Denis Leroy wrote: > As per the AWOL guidelines, and since this has been over 3 weeks now, > I'd like to formally request a takeover of this package. I have not been > able to contact the maintainer. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196911 > > The next step is: > > "If atleast one FESco member approves the take over and no one objects > within 3 days, you may take over the package." Have you emailed the maintainer directly? I've been told that Ignacio has had some personal life stuff going on and that he plans on returning soon. In light of that news, I'm going to NAK this for now. I'll try and ping Ignacio myself as well and see what's up. josh From sander at hoentjen.eu Mon Jul 31 18:35:06 2006 From: sander at hoentjen.eu (Sander Hoentjen) Date: Mon, 31 Jul 2006 20:35:06 +0200 Subject: aMSN and BWidget Message-ID: <1154370906.2886.13.camel@peecee.hoentjen.eu> Hi, I am the maintainer of aMSN in Extras, and there is currently a bug in the FE version of aMSN. This bug occurs because upstream aMSN uses it's own modified version of BWidget. Most of the changes are minor so that is why it was decided to use the already packaged bwidget version for FE amsn. It turns out however that one of the changes is really needed. I reported this change to upstream and I hope they will incorporate it but i haven't had a reply yet (only 2 days since i reported, so it can still come). In the meantime the bug is still there, and there are a few possible fixes: 1) I put the modified bwidget in the amsn package and use that 2) I modify amsn so it can work with the bwidget that is in extras (it will result in a bit reduced functionality (not being able to choose chat font color anymore) 3) a small patch is applied to bwidget (which is 100% backwards compatible, it only adds an optional option) My hope is the change will be in upstream bwidget in the future, and if that would happen option 3 seems the nicest one, but if it won't happen i would prefer option 1. What are others (wart?) opinions about this? Sander From robert at marcanoonline.com Mon Jul 31 18:37:04 2006 From: robert at marcanoonline.com (Robert Marcano) Date: Mon, 31 Jul 2006 14:37:04 -0400 Subject: Problem building on i386 arch with 64bit dependencies Message-ID: <1154371024.3039.4.camel@localhost.localdomain> Something rare is happening when I request a build for javasvn on devel branch, the build fails with errors related to 64bit dependencies not resolved Error: Missing Dependency: libgcc_s.so.1()(64bit) is needed by package ganymed-ssh2 Error: Missing Dependency: libgcj_bc.so.1()(64bit) is needed by package ganymed-ssh2 Error: Missing Dependency: libc.so.6(GLIBC_2.2.5)(64bit) is needed by package ganymed-ssh2 Error: Missing Dependency: libm.so.6()(64bit) is needed by package ganymed-ssh2 Error: Missing Dependency: libgcc_s.so.1(GCC_3.0)(64bit) is needed by package ganymed-ssh2 Error: Missing Dependency: libpthread.so.0()(64bit) is needed by package ganymed-ssh2 Error: Missing Dependency: libc.so.6()(64bit) is needed by package ganymed-ssh2 Error: Missing Dependency: libz.so.1()(64bit) is needed by package ganymed-ssh2 Error: Missing Dependency: libdl.so.2()(64bit) is needed by package ganymed-ssh2 Error: Missing Dependency: librt.so.1()(64bit) is needed by package ganymed-ssh2 Log file at: http://buildsys.fedoraproject.org/logs/fedora-development-extras/13460-javasvn-1.1.0-0.beta4.fc6/i386/root.log Any help is appreciated ________________________________________ Robert Marcano ????????????????? web: http://www.marcanoonline.com/ gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD From wart at kobold.org Mon Jul 31 18:43:14 2006 From: wart at kobold.org (Wart) Date: Mon, 31 Jul 2006 11:43:14 -0700 Subject: aMSN and BWidget In-Reply-To: <1154370906.2886.13.camel@peecee.hoentjen.eu> References: <1154370906.2886.13.camel@peecee.hoentjen.eu> Message-ID: <44CE4F42.2020203@kobold.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sander Hoentjen wrote: > Hi, > > I am the maintainer of aMSN in Extras, and there is currently a bug in > the FE version of aMSN. Do you have a bugzilla #? This bug occurs because upstream aMSN uses it's > own modified version of BWidget. Most of the changes are minor so that > is why it was decided to use the already packaged bwidget version for FE > amsn. It turns out however that one of the changes is really needed. I > reported this change to upstream and I hope they will incorporate it but > i haven't had a reply yet (only 2 days since i reported, so it can still > come). > In the meantime the bug is still there, and there are a few possible > fixes: > 1) I put the modified bwidget in the amsn package and use that Ick. Please no. > 2) I modify amsn so it can work with the bwidget that is in extras (it > will result in a bit reduced functionality (not being able to choose > chat font color anymore) Doesn't amsn already work around these private bwidget changes? I seem to recall that amsn redefines some of the bwidget procs after bwidgets has been loaded. Can a similar thing be done here? > 3) a small patch is applied to bwidget (which is 100% backwards > compatible, it only adds an optional option) As the FE maintainer of bwidget, I'd be willing to add this patch to the FE package. File a bug against bwidget in bugzilla.redhat.com and attach your patch. > My hope is the change will be in upstream bwidget in the future, and if > that would happen option 3 seems the nicest one, but if it won't happen > i would prefer option 1. What are others (wart?) opinions about this? Upstream bwidgets seems to be a bit slow about making new releases (the last one was in 2003), so the best option seems to be to patch bwidget in FE. - --Wart -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEzk8/DeYlPfs40g8RAvDiAJ9VL7ZN/eTWr7fF1XJB3T+wbA28VgCeP9Aw X68YZESQTcG3mrtIt1rBvnA= =Ci6L -----END PGP SIGNATURE----- From denis at poolshark.org Mon Jul 31 18:41:45 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 31 Jul 2006 20:41:45 +0200 Subject: Summary - Broken dependencies in Fedora Extras - 2006-07-31 In-Reply-To: <20060731155646.21625.57459@extras64.linux.duke.edu> References: <20060731155646.21625.57459@extras64.linux.duke.edu> Message-ID: <44CE4EE9.70104@poolshark.org> Fedora Extras repoclosure wrote: > Broken packages in fedora-extras-4-i386: > ---------------------------------------------------------------------- > python-ruledispatch-0.5a0-0.1.svnr2115.fc4.i386 requires python-protocols >= 0:1.0 I belive wp_tray is still broken, is the script missing it somehow ? Or is it because the boost update is still in updates-testing ? : > sudo yum -y install wp_tray Setting up Install Process Setting up repositories Reading repository metadata in from local files Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package wp_tray.i386 0:0.5.1-1.fc4 set to be updated --> Running transaction check --> Processing Dependency: libboost_filesystem.so.1 for package: wp_tray --> Processing Dependency: libboost_regex.so.1 for package: wp_tray --> Finished Dependency Resolution Error: Missing Dependency: libboost_filesystem.so.1 is needed by package wp_tray Error: Missing Dependency: libboost_regex.so.1 is needed by package wp_tray From listbc at newnanutilities.org Mon Jul 31 18:48:12 2006 From: listbc at newnanutilities.org (Brian Collins) Date: Mon, 31 Jul 2006 14:48:12 -0400 Subject: extras on mirror.newnanutilities.org Message-ID: <000c01c6b4d1$e010f4d0$010f12ac@nu.local> Hello folks. We maintain mirror.newnanutilities.org and I recently noticed a reference that our mirror of Fedora Extras was out of date. I do appreciate whoever pointed that out. I'm not sure how it got outdated, but the responsible cron job has been duly reprimanded. I apologize for the lag in keeping it current. We're re-syncing now and I'll try to keep a better eye on it. Thanks! --Brian From ville.skytta at iki.fi Mon Jul 31 18:54:10 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 31 Jul 2006 21:54:10 +0300 Subject: Update of the fish package In-Reply-To: <44CE3E32.1010408@fedoraproject.org> References: <7dad0d770607310841y221983adoc26bde09b3088013@mail.gmail.com> <44CE3E32.1010408@fedoraproject.org> Message-ID: <1154372050.2748.98.camel@localhost.localdomain> On Mon, 2006-07-31 at 23:00 +0530, Rahul wrote: in extras today. > > > > Would someone with commit rights consider uploading this to Extras? > > We cant just build a random package into extras. It would be better to > file a request to update in http://bugzilla.redhat.com against the > specific package in Fedora Extras. https://bugzilla.redhat.com/193617 (2 months) https://bugzilla.redhat.com/179296 (6 months) From denis at poolshark.org Mon Jul 31 18:53:46 2006 From: denis at poolshark.org (Denis Leroy) Date: Mon, 31 Jul 2006 20:53:46 +0200 Subject: Broken upgrade paths in FC+FE 2006-07-31 In-Reply-To: <20060731153904.2D1BD152169@buildsys.fedoraproject.org> References: <20060731153904.2D1BD152169@buildsys.fedoraproject.org> Message-ID: <44CE51BA.6010107@poolshark.org> buildsys at fedoraproject.org wrote: > gcdmaster: denis AT poolshark.org > 4: 0:1.2.1-5.fc4 (FE4) > 5: 0:1.2.1-4.fc5 (FE5) > 6: 0:1.2.1-4.fc5 (FE6) > inkscape: denis AT poolshark.org > 4: 0:0.44-3.fc4 (FE4) > 5: 0:0.44-2.fc5 (FE5) > 6: 0:0.44-2.fc6 (FE6) so the FC-4 gtkmm issues are not all resolved yet and I will push an update asap (the last one). Still, if one expect more FC-4 updates to come, is it ok to bump the FC-5 and devel release by more than 1, say by 5, to minimize the number of unnecessary rebuilds ? -denis From ville.skytta at iki.fi Mon Jul 31 19:15:29 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 31 Jul 2006 22:15:29 +0300 Subject: Broken upgrade paths in FC+FE 2006-07-31 In-Reply-To: <44CE51BA.6010107@poolshark.org> References: <20060731153904.2D1BD152169@buildsys.fedoraproject.org> <44CE51BA.6010107@poolshark.org> Message-ID: <1154373329.2748.106.camel@localhost.localdomain> On Mon, 2006-07-31 at 20:53 +0200, Denis Leroy wrote: > Still, if one expect more FC-4 updates to > come, is it ok to bump the FC-5 and devel release by more than 1, say by > 5, to minimize the number of unnecessary rebuilds ? I suppose so, but the recommended recipe for cases like this is to add a digit to the very right of the release (after %{?dist}) and start bumping it in old distros as needed (and drop the extra digit in the future if it becomes possible), no need for guesswork that way. https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html From sander at hoentjen.eu Mon Jul 31 19:19:12 2006 From: sander at hoentjen.eu (Sander Hoentjen) Date: Mon, 31 Jul 2006 21:19:12 +0200 Subject: aMSN and BWidget In-Reply-To: <44CE4F42.2020203@kobold.org> References: <1154370906.2886.13.camel@peecee.hoentjen.eu> <44CE4F42.2020203@kobold.org> Message-ID: <1154373552.2886.22.camel@peecee.hoentjen.eu> On Mon, 2006-07-31 at 11:43 -0700, Wart wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sander Hoentjen wrote: > > Hi, > > > > I am the maintainer of aMSN in Extras, and there is currently a bug in > > the FE version of aMSN. > > Do you have a bugzilla #? no but i do have: http://amsn.sourceforge.net/bugs/admin/index.php?show=bug&id=49 > > This bug occurs because upstream aMSN uses it's > > own modified version of BWidget. Most of the changes are minor so that > > is why it was decided to use the already packaged bwidget version for FE > > amsn. It turns out however that one of the changes is really needed. I > > reported this change to upstream and I hope they will incorporate it but > > i haven't had a reply yet (only 2 days since i reported, so it can still > > come). > > In the meantime the bug is still there, and there are a few possible > > fixes: > > 1) I put the modified bwidget in the amsn package and use that > > Ick. Please no. > > > 2) I modify amsn so it can work with the bwidget that is in extras (it > > will result in a bit reduced functionality (not being able to choose > > chat font color anymore) > > Doesn't amsn already work around these private bwidget changes? I seem > to recall that amsn redefines some of the bwidget procs after bwidgets > has been loaded. Can a similar thing be done here? not easily, but if the change is not accepted upstream i might put myself to doing that anyway. > > > 3) a small patch is applied to bwidget (which is 100% backwards > > compatible, it only adds an optional option) > > As the FE maintainer of bwidget, I'd be willing to add this patch to the > FE package. File a bug against bwidget in bugzilla.redhat.com and > attach your patch. ok, #200809 > > > My hope is the change will be in upstream bwidget in the future, and if > > that would happen option 3 seems the nicest one, but if it won't happen > > i would prefer option 1. What are others (wart?) opinions about this? > > Upstream bwidgets seems to be a bit slow about making new releases (the > last one was in 2003), so the best option seems to be to patch bwidget > in FE. > Yes but if the change is at least in their cvs it "feels better" to me. From liljencrantz at gmail.com Mon Jul 31 19:43:34 2006 From: liljencrantz at gmail.com (Axel Liljencrantz) Date: Mon, 31 Jul 2006 21:43:34 +0200 Subject: Update of the fish package In-Reply-To: <20060731184123.21c5a5d3.bugs.michael@gmx.net> References: <7dad0d770607310841y221983adoc26bde09b3088013@mail.gmail.com> <44CE2B5F.6010405@city-fan.org> <20060731184123.21c5a5d3.bugs.michael@gmx.net> Message-ID: <7dad0d770607311243n7f0b6cedr54febe4c6af3f28e@mail.gmail.com> On 7/31/06, Michael Schwendt wrote: > On Mon, 31 Jul 2006 17:10:07 +0100, Paul Howarth wrote: > > > Axel Liljencrantz wrote: > > > Hi > > > > > > The version of fish in Fedora extras is pretty out of date. To make > > > things worse, fedora 4 has a more recent fish version than fedora 5/6, > > > causing upgrade troubles. There are source rpms for fish available at > > > the main fish site, http://roo.no-ip.org/fish. Specifically, the > > > latest fish version is > > > http://roo.no-ip.org/fish/files/1.21.10/fish-1.21.10-0.src.rpm. This > > > source rpm compiles under both fedora 4 and fedora 5, and fixes > > > various bugs in the fish versions available in extras today. > > > > > > Would someone with commit rights consider uploading this to Extras? > > > > You might want to be the first to try out the AWOL maintainers procedure: > > > > http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers > > Actually, Axel and Oliver are supposed to be working together, since if my > memory serves correctly, Oliver only served as a proxy into FE CVS for > Axel. But this is not the first time this method has failed. I don't > know, however, how both have decided to communicate about updates. You are correct, Oliver has been kind enough to upload previous releases. Unfortunately, my last 2 emails (sent in June) to him have been unanswered, I supposed he felt he didn't have time to babysit me any more(Perfectly understandable, this is a volunteer effort), or it might possibly be email trouble. As such I thought I'd go on list and ask how to proceed. > > How about signing up as a Fedora Extras Contributor? I could do that. I have a bugzilla account, (liljencrantz at gmail.com), and I belive I have performed all steps outlined on http://fedoraproject.org/wiki/Extras/Contributors up until 'Get Sponsored' except 'Make review request', but that should be superflous, since the package I want to become a contributor for is already in extras, was originally created by me, put through a review process, etc. Anyone willing to sponsor me? That said, the package has a kludge in it that didn't exist at the time of the original review. A utility shipped with fish needs various X headers to compile, and the name of the package providing X headers has changed from fc3 to fc4, and the file location has changed from fc4 to fc5, to work around that and make a single package that builds on all fedoras, I had to do a semi-ugly hack using a %define in the spec: %define xinclude %( if test -d /usr/X11R6/include; then echo /usr/X11R6/include; else echo /usr/include; fi ) I asked on the main rpm mailing list how to do this and used the pointers I got, but if anyone has a better suggestion, I'd be happy to listen. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Axel From liljencrantz at gmail.com Mon Jul 31 21:27:59 2006 From: liljencrantz at gmail.com (Axel Liljencrantz) Date: Mon, 31 Jul 2006 23:27:59 +0200 Subject: Update of the fish package In-Reply-To: <1154372050.2748.98.camel@localhost.localdomain> References: <7dad0d770607310841y221983adoc26bde09b3088013@mail.gmail.com> <44CE3E32.1010408@fedoraproject.org> <1154372050.2748.98.camel@localhost.localdomain> Message-ID: <7dad0d770607311427i48d1c3dcr79a44674dadeadfd@mail.gmail.com> On 7/31/06, Ville Skytt? wrote: > On Mon, 2006-07-31 at 23:00 +0530, Rahul wrote: in extras today. > > > > > > Would someone with commit rights consider uploading this to Extras? > > > > We cant just build a random package into extras. It would be better to > > file a request to update in http://bugzilla.redhat.com against the > > specific package in Fedora Extras. > > https://bugzilla.redhat.com/193617 (2 months) > https://bugzilla.redhat.com/179296 (6 months) I hadn't seen that patch, my bad. (Wasn't CC:ed) I'll add the altered dependencies and spelling corrections to the fish spec file. (Can't simply add the patch, since the spec file has changed since that patch was written, e.g. fish doesn't need doxygen to build anymore, since the tarball ships with prebuilt documentation. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Axel From bugs.michael at gmx.net Mon Jul 31 21:57:14 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 31 Jul 2006 23:57:14 +0200 Subject: Summary - Broken dependencies in Fedora Extras - 2006-07-31 In-Reply-To: <44CE4EE9.70104@poolshark.org> References: <20060731155646.21625.57459@extras64.linux.duke.edu> <44CE4EE9.70104@poolshark.org> Message-ID: <20060731235714.58813113.bugs.michael@gmx.net> On Mon, 31 Jul 2006 20:41:45 +0200, Denis Leroy wrote: > > Broken packages in fedora-extras-4-i386: > I belive wp_tray is still broken, is the script missing it somehow ? It is no longer detected as broken since 2006-07-26 when a gtkmm24 update/rebuild reintroduced the missing libatkmm-1.6.so.1 > Or is it because the boost update is still in updates-testing ? : This would need a decision at a higher level of the Fedora Project. There is no documentation on updates-testing release habits or policies. It is not possible to build Extras against updates-testing. Hence running repoclosure against updates-testing would report breakage which probably never becomes reality if test updates are not released or are withdrawn. From bugs.michael at gmx.net Mon Jul 31 22:02:47 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 1 Aug 2006 00:02:47 +0200 Subject: Problem building on i386 arch with 64bit dependencies In-Reply-To: <1154371024.3039.4.camel@localhost.localdomain> References: <1154371024.3039.4.camel@localhost.localdomain> Message-ID: <20060801000247.aac8b487.bugs.michael@gmx.net> On Mon, 31 Jul 2006 14:37:04 -0400, Robert Marcano wrote: > Something rare is happening when I request a build for javasvn on devel > branch, the build fails with errors related to 64bit dependencies not > resolved > > Error: Missing Dependency: libgcc_s.so.1()(64bit) is needed by package ganymed-ssh2 > Error: Missing Dependency: libgcj_bc.so.1()(64bit) is needed by package ganymed-ssh2 > Error: Missing Dependency: libc.so.6(GLIBC_2.2.5)(64bit) is needed by package ganymed-ssh2 > Error: Missing Dependency: libm.so.6()(64bit) is needed by package ganymed-ssh2 > Error: Missing Dependency: libgcc_s.so.1(GCC_3.0)(64bit) is needed by package ganymed-ssh2 > Error: Missing Dependency: libpthread.so.0()(64bit) is needed by package ganymed-ssh2 > Error: Missing Dependency: libc.so.6()(64bit) is needed by package ganymed-ssh2 > Error: Missing Dependency: libz.so.1()(64bit) is needed by package ganymed-ssh2 > Error: Missing Dependency: libdl.so.2()(64bit) is needed by package ganymed-ssh2 > Error: Missing Dependency: librt.so.1()(64bit) is needed by package ganymed-ssh2 > > Log file at: > http://buildsys.fedoraproject.org/logs/fedora-development-extras/13460-javasvn-1.1.0-0.beta4.fc6/i386/root.log > > Any help is appreciated The error is some lines above in the "resolvedep" step (there is no x86_64 ganymed-ssh2 in the i386 repo, so resolvedep is mistaken): Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core-c657822928dcb19e6dd6547c2206a957014585ee/root resolvedep 'gcc-java >= 4.0.2' 'ganymed-ssh2 >= 209' 'ant' 'coreutils' 'java-gcj-compat-devel >= 1.0.33' 'jpackage-utils >= 0:1.6' 0:gcc-java-4.1.1-13.i386 0:ganymed-ssh2-209-5.fc6.x86_64 (<---- !) 0:ant-1.6.5-1jpp_11fc.i386 0:coreutils-5.97-6.i386 0:java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_98rh.i386 0:jpackage-utils-1.6.6-1jpp_5rh.noarch From bugs.michael at gmx.net Mon Jul 31 22:28:19 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 1 Aug 2006 00:28:19 +0200 Subject: Update of the fish package In-Reply-To: <7dad0d770607311243n7f0b6cedr54febe4c6af3f28e@mail.gmail.com> References: <7dad0d770607310841y221983adoc26bde09b3088013@mail.gmail.com> <44CE2B5F.6010405@city-fan.org> <20060731184123.21c5a5d3.bugs.michael@gmx.net> <7dad0d770607311243n7f0b6cedr54febe4c6af3f28e@mail.gmail.com> Message-ID: <20060801002819.2e53a49d.bugs.michael@gmx.net> On Mon, 31 Jul 2006 21:43:34 +0200, Axel Liljencrantz wrote: > > How about signing up as a Fedora Extras Contributor? > > I could do that. I have a bugzilla account, (liljencrantz at gmail.com), > and I belive I have performed all steps outlined on > http://fedoraproject.org/wiki/Extras/Contributors up until 'Get > Sponsored' except 'Make review request', but that should be > superflous, since the package I want to become a contributor for is > already in extras, was originally created by me, put through a review > process, etc. Anyone willing to sponsor me? Yes, go ahead, and I'll sponsor you. > That said, the package has a kludge in it that didn't exist at the > time of the original review. A utility shipped with fish needs various > X headers to compile, and the name of the package providing X headers > has changed from fc3 to fc4, and the file location has changed from > fc4 to fc5, to work around that and make a single package that builds > on all fedoras, I had to do a semi-ugly hack using a %define in the > spec: > > %define xinclude %( if test -d /usr/X11R6/include; then echo > /usr/X11R6/include; else echo /usr/include; fi ) > > I asked on the main rpm mailing list how to do this and used the > pointers I got, but if anyone has a better suggestion, I'd be happy to > listen. Since the X11 header package names have changed, you need a hack also for the BuildRequires. And in that area it becomes dangerous, since run-time detected "BuildRequires" package names become "Requires" of the src.rpm, and you cannot rely on that the src.rpm is built on the target platform. The least painful way is to create distribution specific spec files which work only for one distribution until package names change. In Fedora Extras CVS you have a separate branch directory for every distribution release. Another way is to evaluate the Fedora specific %fedora macro, which is set inside the build system, and set it in the spec file to a good default _if_ it is not defined: %{!?fedora: %define fedora 6} Your src.rpm then defaults to Fedora Core 6, and you can use conditionals like this: %if "%fedora" >= "5" BuildRequires: libXfoo-devel %define something /usr/include %else BuildRequires: foo-devel %define something /usr/X11R6/include %endif %if "%fedora" = "3" rm -f $RPM_BUILD_ROOT%{_bindir}/dont-want-that-file %endif and so on. More about this and the %{?dist} tag can be found here: http://fedoraproject.org/wiki/Packaging/DistTag From liljencrantz at gmail.com Mon Jul 31 23:59:04 2006 From: liljencrantz at gmail.com (Axel Liljencrantz) Date: Tue, 1 Aug 2006 01:59:04 +0200 Subject: Update of the fish package In-Reply-To: <20060801002819.2e53a49d.bugs.michael@gmx.net> References: <7dad0d770607310841y221983adoc26bde09b3088013@mail.gmail.com> <44CE2B5F.6010405@city-fan.org> <20060731184123.21c5a5d3.bugs.michael@gmx.net> <7dad0d770607311243n7f0b6cedr54febe4c6af3f28e@mail.gmail.com> <20060801002819.2e53a49d.bugs.michael@gmx.net> Message-ID: <7dad0d770607311659m5c1e5100o3bb06927535f53d1@mail.gmail.com> On 8/1/06, Michael Schwendt wrote: > On Mon, 31 Jul 2006 21:43:34 +0200, Axel Liljencrantz wrote: > > > > How about signing up as a Fedora Extras Contributor? > > > > I could do that. I have a bugzilla account, (liljencrantz at gmail.com), > > and I belive I have performed all steps outlined on > > http://fedoraproject.org/wiki/Extras/Contributors up until 'Get > > Sponsored' except 'Make review request', but that should be > > superflous, since the package I want to become a contributor for is > > already in extras, was originally created by me, put through a review > > process, etc. Anyone willing to sponsor me? > > Yes, go ahead, and I'll sponsor you. Thank you. The account name 'Liljencrantz' was too long, so I chose 'ascii'. > > > That said, the package has a kludge in it that didn't exist at the > > time of the original review. A utility shipped with fish needs various > > X headers to compile, and the name of the package providing X headers > > has changed from fc3 to fc4, and the file location has changed from > > fc4 to fc5, to work around that and make a single package that builds > > on all fedoras, I had to do a semi-ugly hack using a %define in the > > spec: > > > > %define xinclude %( if test -d /usr/X11R6/include; then echo > > /usr/X11R6/include; else echo /usr/include; fi ) > > > > I asked on the main rpm mailing list how to do this and used the > > pointers I got, but if anyone has a better suggestion, I'd be happy to > > listen. > > Since the X11 header package names have changed, you need a hack also for > the BuildRequires. And in that area it becomes dangerous, since run-time > detected "BuildRequires" package names become "Requires" of the src.rpm, > and you cannot rely on that the src.rpm is built on the target platform. > > The least painful way is to create distribution specific spec files which > work only for one distribution until package names change. In Fedora > Extras CVS you have a separate branch directory for every distribution > release. Least painful is always relative. The benefits I see of using a single spec file: * When changes are made to the spec, you only have to edit one file, which reduces the amount of typing, and given my clumsy fingers, the error rate goes way down. * I can test the spec file locally on my box and catch most errors. I don't have e.g. a core 3 system available, so I can't test its spec file before uploading it. On the other hand, if using a single spec file means creating ahuge hairy mess of a file, that disadvantage outweighs the advantage. > > Another way is to evaluate the Fedora specific %fedora macro, which is set > inside the build system, and set it in the spec file to a good default > _if_ it is not defined: > > %{!?fedora: %define fedora 6} > > Your src.rpm then defaults to Fedora Core 6, and you can use conditionals > like this: > > %if "%fedora" >= "5" > BuildRequires: libXfoo-devel > %define something /usr/include > %else > BuildRequires: foo-devel > %define something /usr/X11R6/include > %endif > > %if "%fedora" = "3" > rm -f $RPM_BUILD_ROOT%{_bindir}/dont-want-that-file > %endif > > and so on. More about this and the %{?dist} tag can be found here: Thank you. So the following %{!?fedora: %define fedora 6} %if "%fedora" >= "5" BuildRequires: xorg-x11-proto-devel libX11-devel libXt-devel %else BuildRequires: xorg-x11-devel %endif would be considered nicer than the original spec? I guess I'd agree. The main downside is that it will not work on non-fedora systems which do not use the same package names as fedora 5, which should be all pre X.org-7.0 systems. But I guess I can accept having a fedora specific spec file for the fedora extras rpm and use a different spec file for the 'generic' rpm provided on the fish download page. > > http://fedoraproject.org/wiki/Packaging/DistTag > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Axel